コピードリフトとは何か：その原因と防止方法

コピードリフトとは、ユーザーの目に触れるテキストが、承認された原本から時間の経過とともに、また画面ごとにずれていく現象です。しかもそもそも「原本」と呼べる唯一の情報源が存在しません。文字列は消えていないし壊れてもいません。文言そのものが変わってしまい、誰もそれを望んだわけではないのに、マーケティングページとランディングページとプロダクト画面がそれぞれ微妙に違う言い方で同じ機能を説明している、という状態です。globalize.nowはローカリゼーション機能を内蔵したコードネイティブなコピー管理システムであり、まさにこのドリフトを防ぐために存在します。

コピードリフトとは何か？

コピードリフトとは、ユーザーの目に触れるテキストが、承認された原本から時間の経過とともに、また画面ごとにずれていく現象です。しかもそもそも「原本」と呼べる唯一の情報源が存在しません。

この定義には二つの要素があります。「承認された原本からずれる」というのは、かつて誰かがこの文言はこう書くべきだと合意していたことを意味します。「唯一の情報源が存在しない」というのは、その合意を保持している成果物がもうどこにも残っていないということ、つまり照合できる基準そのものが存在しないということです。だからこそ、誰も「いつからずれ始めたのか」を指し示せないのです。

ドリフトは例外的な現象ではなく、むしろ普通に起こることです。複数の画面があり、複数の人が編集に関わるプロダクトであれば、構造的にそれを防ぐ仕組みがない限り、必ずドリフトは発生します。

コピードリフトではないもの

3つの異なる問題が一括りにされがちですが、それぞれ必要な対処法は違います。ここを取り違えると、チームは見当違いの問題を追いかけることになります。

ハードコードされた文字列とは、カタログではなくコンポーネントに直接書き込まれたテキストのことです。ツールにも翻訳作業にも見えない存在ですが、文言自体は正しいこともあります。これは別の問題であり、AIコーディングツールがハードコードされた文字列を生み続ける理由で取り上げています。

同期が取れていない翻訳ファイルとは、存在はしているものの互いにずれてしまったカタログのことです。原本自体は問題なく、そこから派生したコピーが古くなっているだけです。

コピードリフトはそのどちらでもありません。文字列がキー化されていても、ファイルが同期していても、プロダクトはある場所では「無料トライアルを開始」、別の場所では「無料で試す」、実際に処理を実行するボタンには「始める」と、それぞれ違う言い方をしてしまうことがあります。

この3つは同時に起こり得ますし、互いに解決し合うこともありません。

コピードリフトの原因は何か

影響の大きい順に、3つの要因があります。

画面ごとに担当者もツールも異なること。 マーケティングのコピーはCMSで管理されています。ランディングページは常に実験が行われているため最も頻繁に更新されます。プロダクトの文字列はコンポーネントの中に書かれています。それぞれの画面単体では整合性が取れていても、プロダクト全体で見ると一貫性がなく、しかも3つすべてを一度に見渡せる人は誰もいません。

誰もコピー編集だと認識しない小さな修正。 モバイルのブレークポイントに収めるためにラベルを短くする人がいます。隣の画面と揃えるために見出しの表記を文章体に直す人もいます。それぞれ単体では正当な変更に見えます。しかしツールから見ればJSXの属性内の単なる文字列リテラルなので、コピーレビューらしきものを一切通りません。

コーディングエージェント。 ローディング状態の追加を依頼されたエージェントが、そのファイルを開いたついでにラベルまで書き換えてしまうことがあります。文字列を整えることは、コードを整えることとまったく同じように見えてしまうのです。今のところコミュニティの答えはルールファイルです: AGENTS.md、.cursorrules、プロンプト内のUIコピーに関するポリシーブロック。これらは役に立ちますし、用意しておく価値もあります。しかし規約はチェックではありません。コピーが書き換えられる頻度を減らすことはできても、いつ書き換わったのかを教えてはくれないのです。

なぜコピードリフトは誰にも気づかれないのか

何も壊れないからです。

変更されたラベルはコンパイルも通ります。画面にも表示されます。型チェッカーは有効な文字列だと判断し、リンターも構文として正しいと見なします。スナップショットテストが失敗しても、たいていの対応はスナップショットを更新することであり、それはドリフトを検知するどころか記録として固定してしまうだけです。ビルドが赤くなることもなければ、アラートが鳴ることも、ダッシュボードが黄色く変わることもありません。

ドリフトが見えるのは、承認された文言が何であったかを知っている存在だけです。ほとんどのツールチェーンにはそのような記録がないため、最初に気づくのは大抵の場合、人間です。UI表示とは違う言葉を引用したサポート返信だったり、「ワークスペース」と「プロジェクト」は同じものなのかと尋ねる顧客だったり、あるいは3通りの英語の言い回しのうちどれを訳せばよいのかと尋ねる翻訳者だったりします。

コピードリフトの実際のコストは？

正直に言うと、誰もそれを計測していません。私たちも含めてです。そして数字をでっち上げるつもりもありません。

これははっきり言っておく価値があります。というのも、この分野には出所をたどると成り立たなくなる数字があふれているからです。ブランディングと売上に関するアンケート数値、チケット1件あたりのサポートコスト、ドキュメントの不整合に起因するとされるチケットの割合。私たちも社内でそうした数字をいくつも却下してきました、繰り返すくらいなら。この問いに実際に答えられる測定——実際のコードベースにどれほどのドリフトが存在し、それが下流にどう影響するか——は、誰も行っていません。

数字なしでも説明できるのはそのメカニズムであり、そのメカニズムは複利のように積み重なっていくというものです:

• 高くつくようになるまで見えない。 修正コストが低いうちにドリフトが表面化することはありません。表面化するのは、誰かが「言葉を揃える必要がある」と気づいたとき、しかもたいてい時間の余裕がないときです。
• 画面が変わるたびに、修正も別作業になる。 言い回しを変えるということは、それが言い換えられている場所をすべて見つけ出すことを意味しますが、そうした場所を網羅したリストは存在しません。
• ローカリゼーションがそれを増幅させる。 ここが一番の急所です。同じアイデアの3通りの言い回しを翻訳に出せば、3通りの翻訳が、しかもすべての言語で生まれます。英語の中では収まっていた不整合が、対応言語の数だけ複製され、ネイティブスピーカーの目には3つの別々の機能に見えてしまいます。

最後のこの点こそ、コピーの一貫性とローカリゼーションが別々のプロジェクトではない理由です。どの言い回しが承認されているのか分からなければ、そのどれも正しく翻訳することはできません——翻訳者の目に触れる前から、原文自体が曖昧だったのです。両方を解決するアーキテクチャは同じものであり、それはコードネイティブなプロダクトコピーで説明した内容です。

コピードリフトをどのように防げばいいですか？

文言に唯一の置き場所を与え、その変更をレビュー可能にすること。それさえできれば、あとは自然についてきます。

カタログをひとつに。 ユーザーの目に触れるすべての文字列が、コンポーネントに分散して埋め込まれるのではなく、ひとつの場所に集約されます。これで初めて「何と一貫させるべきか」という基準ができます。

リテラルではなくキーを。 コンポーネントは言葉そのものを書く代わりにキーを参照します。同じ言い回しが2箇所に存在してこっそりずれていく、ということが起こり得なくなります。なぜなら、それはただ一箇所にしか存在しないからです。

変更が差分（diff）に現れる。 コピーの変更は、他のあらゆる変更と同じようにレビューの中に表れます。これこそが本当に効いてくるステップです:一貫性を保つことが、誰かがスタイルガイドを覚えているかどうかに依存する状態から抜け出し、実際に人が確実に目を通しているその瞬間に見える状態へと変わるのです。

プロダクトの外側にある画面——マーケティングやランディングページ——は、より難しい半分です。ここは正直にお伝えしておきます:マーケティング、ランディング、プロダクトを横断してコピーをひとつのシステムとして標準化することは、globalize.nowが目指して構築中のものであり、今日すぐに使える機能ではありません。仕組み自体はこれまで説明してきたものと同じで、アプリの境界を越えて拡張したものです:すべての画面が言葉をそのまま書き直す代わりに承認済みの文字列をキーで参照するようになれば、言い回しを変えることは3回の判断ではなく、たった1回の判断で済むようになります。

AIコーディングツールを使って開発を進めるチームほど、この問題に早くぶつかります。だからこそ私たちは開発者向けにも、AIツールで開発する人たち向けにもこのテーマについて書いています。

スタイルガイドでコピードリフトは解決できるのか

いいえ——スタイルガイドと信頼できる唯一の情報源（ソース・オブ・トゥルース）はまったく別の問題を解決するものであり、チームは前者を買って後者の効果を期待してしまいがちです。

スタイルガイドは、良いコピーとはどのようなものかを説明します:トーン、大文字小文字の使い方、用語、「削除する」と言うべきか「消す」と言うべきかといったことです。これは本当に有用で、どのチームも持つべきものです。しかしスタイルガイドにできないのは、「文字列が変わった」という事実を教えることです。以前の文言の記録も持っていなければ、変更の瞬間に反応する仕組みもありません。だから、たまたま正しい画面を見ている人がいて初めて適用され得るものなのです。

ドリフトは好みの問題ではなく、状態管理の問題です。修正策は、その状態が存在する場所に置かれなければなりません。

ドリフトは、同じ言葉が2箇所に存在した瞬間から始まります。globalize.nowは、接続したリポジトリの中でそれらを唯一の情報源に統合し、そのひとつのコピーからすべての言語を導き出します。