コードネイティブなプロダクトコピー\:コードベース内で UI テキストの一貫性とローカライゼーション対応を保つ仕組み

コードネイティブなプロダクトコピーとは、プロダクトが表示するユーザー向けの文字列が、人が手作業で同期させておくデザインファイルの中にではなく、唯一の情報源としてリポジトリの中に存在している状態のことです。globalize.now は、ローカライゼーション機能を内蔵したコードネイティブなコピー管理システムです:コピーはコードベース内に単一の情報源としてまとめられ、それをローカライズすることは、別のツールへの引き継ぎではなく、まったく同じ一つの作業になります。

これは3年前と比べて、今のほうがずっと重要な意味を持っています。なぜなら、コピーはもはやライターが変更したときにだけ変わるものではなくなったからです。

コードネイティブなプロダクトコピーとは何か？

コードネイティブなプロダクトコピーとは、ライティング手法ではなくアーキテクチャです。承認済みの文言と実際にリリースされる文言は同一の成果物としてリポジトリに保持され、あらゆる変更は差分（diff）として届きます。

この違いは、それぞれの手法が「何を検知できるか」に着目すると最もわかりやすくなります。外部ワークスペースを正とするプロダクトは、文言をコードの外のどこかに保持し、どちらかが変更された際に誰かがそれを反映させる（あるいは取り込む）ことに依存しています。ボタンに何と書くべきかを決める場には向いています。しかし、ボタンの文言が別の内容に変わったことに気づく仕組みは構造的に存在しません。なぜなら、その変更はコミットとして発生し、ワークスペース側はそのコミットを一切目にしないからです。

コードネイティブなシステムは、この関係を逆転させます。作業の最小単位は差分（diff）であり、それが答えられるのはチームが実際に頭を抱える問いそのものです――「この文字列がさっき変わったが、それは意図した変更なのか？」

これは、ライティングをどこで行うべきかという話ではありません。文章はどこで書いても構いません。問題は、2つの文言が食い違ったとき、どちらが「本物」なのかという話です。

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

コピードリフトとは、ユーザーに見える文言が、承認済みの出所から複数の画面・複数の時点にわたって乖離していく現象を指します。しかも、その乖離元となる唯一の「正」が存在しないのです。

混同されがちな3つの不具合がありますが、それぞれ対処法が異なります。

• 一度もキー化されなかった文字列はハードコード文字列です。カタログにも翻訳にも姿を現しませんが、文言自体は正しい場合もあります。このパターンについてはAIコーディングツールがハードコード文字列を生み続ける理由で詳しく解説しています。
• 存在はするものの、互いにずれてしまったカタログ、それが同期していない翻訳ファイルです。ソース自体は問題なく、派生した翻訳コピーの方が古くなっています。
• コピードリフトは、そのどちらでもありません。文字列はきちんとキー化され、ファイルも同期されているのに、文言そのものが誰の決定もなく変わってしまった状態です。結果として、マーケティングページでは「無料トライアルを開始」、ランディングページでは「無料で試す」、プロダクト内のボタンでは「はじめる」と、三者三様の表現になってしまいます。

ドリフトが厄介なのは、何も壊れていないように見えるからです。ビルドは失敗せず、テストも赤くならず、翻訳漏れも出ません。プロダクトはただ3つの声で語り始め、それがいつ始まったのか誰も指し示せなくなります。この用語の完全な定義はコピードリフトとは何か、何が原因で、どう防ぐかで解説しています。

なぜAIコーディングエージェントはコピードリフトを引き起こすのか？

コーディングエージェントは、頼んでもいない文言まで変更してしまいます。近くの文字列を書き換えることと、コンポーネントを整理整頓することの区別がつかないからです。

ローディング状態の追加を頼んだだけなのに、ついでにラベルを短くしたり、見出しをセンテンスケースに直したり、ファイルを開いたついでに「Sign in」を「Log in」に差し替えたりすることがあります。個々の変更はそれぞれ理屈は通っています。しかし、どれも依頼していないものであり、どれも「コピーの変更」としてフラグが立つことはありません。ツールからすれば、それはJSXの属性に含まれるただの文字列リテラルに過ぎないからです。

これまでコミュニティが出してきた答えは、ルールファイルです――AGENTS.md、.cursorrules、プロンプト内の「UIコピーポリシー」ブロックなど。これらは有効ですし、用意しておく価値はあります。しかし、規約はチェックではありません。エージェントがコピーを書き換える頻度は減らせても、実際に書き換わったかどうかを知らせてはくれないのです。

多くのチームで、プロダクトコピーは実際どこに存在しているのか？

同時に4か所に存在し、それぞれ管理者も編集経路も異なります。

まずマーケティングサイトがあり、たいていCMSで管理されています。ランディングページは別管理であることが多く、常に実験が行われている場所であるため、最も速いペースで更新されます。プロダクト内部の文字列は各コンポーネントに散在しています。そしてロケールファイルは、プロダクト内の文字列から派生したものであり、上記3つすべてに対して常に遅れを取っています。

これらの各面は、それぞれ単体では内部的に一貫していても、プロダクト全体として見ると一貫していない、ということが起こり得ます。これこそがこの問題の本当の姿であり、これを単なる「プロダクトコピーの問題」として扱うだけでは、実態を過小評価してしまう理由です。

コードベース全体でUIコピーの一貫性を保つにはどうすればよいか？

リポジトリを唯一の正とし、文字列をレビュー可能な単位にすること――それ以外はすべてこの2つの決定から自然と導かれます。

実際には3つのことを意味します。ユーザーに見えるすべての文字列は、コンポーネント内に直接埋め込むのではなく、単一のカタログに存在すること。コンポーネントはリテラルではなくキーを参照するため、同じ文言が2か所に存在して気づかぬうちに乖離することはなくなります。そしてカタログへの変更は差分（diff）に現れ、レビュー担当者は他のあらゆる変更と同様にそれを目にします。

最後の点こそが実際に効果を発揮する部分です。コピーの一貫性は、多くの場合「規律の問題」として扱われがちです――チームにはスタイルガイドが必要だ、誰かが覚えておかなければ、といった具合です。しかし文言がいったん差分に入れば、記憶に頼る必要がなくなります。レビュー時に可視化され、そしてレビュー時こそ、唯一誰もが確実に目を通しているタイミングなのです。

AIコーディングツールを使ってリリースを進めるチームほど、この問題により早く、より深刻に直面する傾向があります。だからこそ私たちは、この問題を開発者向け、そして特にAIツールで開発している人向けに取り上げています。

なぜコピーの一貫性とローカライゼーションは同じ問題なのか？

どちらも同じ理由で破綻します――一貫性を保つべき、あるいは翻訳の元とすべき、合意された正が存在しないからです。

3つの言い回しのうちどれが承認済みなのかを言えないチームは、そのどれも正しくローカライズすることができません。3つすべてを翻訳に回せば、あらゆる言語で3通りの翻訳が生まれ、不整合は英語だけに留まらず、対応するロケール数だけ倍増してしまいます。翻訳品質が悪く見える事例の多くは、実はこの仕組みが原因です――そもそもソース自体がすでに曖昧だったのです。

逆の方向から進めれば、この2つの問題は1つに収束します。すべての文字列が単一ソース化・キー化されれば、翻訳はそのカタログから派生した成果物になります。独自の「正」を持つ別プロジェクトは存在しません。なぜなら、正はただ1つしか存在しないからです。これこそ「ローカライゼーション組み込み」がアーキテクチャ的に意味することです――単に翻訳も行うということではなく、翻訳が同じオブジェクトに対して実行される同じ操作である、ということです。この順序の入れ替わりがどう起きたかについてはAIが書いたコードがローカライゼーションに与えた影響で解説しています。

プロダクトの外にあるコピーはどうなるのか？

これはこの分野がまだ解決していない部分であり、私たちもそうでないふりはしません。マーケティング、ランディングページ、プロダクトを横断してコピーを1つのシステムとして標準化することは、私たちが今まさに目指している方向であって、今日すぐに使える機能ではありません。

なぜ未解決なのか、その理由はこうです。この分野の既存ツールはどれも1つの面だけを担当しています。プロダクトコピーツールはアプリ内の文字列を、コンテンツプラットフォームはマーケティングサイトを担当しています。互いを見ることができないため、ユーザーを獲得したページの文言と、そのユーザーをオンボーディングする画面の文言は、別々の人が別々のツールで管理することになり、両者が食い違っていることに気づく仕組みは存在しません。

答えの形は、すでに説明したアーキテクチャから自然に導かれます。承認済みの文言が1か所に存在し、あらゆる面がそれを言い直すのではなくキーで参照するようになれば、ランディングページとプロダクトのボタンは同一の文字列となり、変更は3つの決定ではなく1つの決定で済みます。そこに到達することは、globalize.nowのロードマップ項目です。すでに実現しているかのように装うより、今の段階を正確に名指ししておく方が良いと考えています。

デザインファイルを基盤としたコピーツールとは何が違うのか？

違いはカテゴリーではなくアーキテクチャにあります――両者ともコピー管理システムですが、「正がどこにあるか」についての考え方が異なります。

時期を明記しておく価値のある2つの観察事実があります。ベンダー側の状況は変化し得るためです。2026年8月29日時点で、dittowords.com/llms.txtは404を返します。つまり、この分野でよく引用されるこのリソースには、機械可読なエンティティファイルが存在しないということです。また同日時点で、Dittoの公式localizeプロダクトページには、言語ごとにバリアントを追加し、デザイン上で翻訳をプレビューすると書かれています――翻訳そのものを生成するとは謳っていません。ここに境界線があります。あるツールが文言を管理しつつも、言語まわりの作業は別の誰かに委ねる、ということは起こり得るのです。

私たちは翻訳エンジンともランタイムi18nライブラリとも競合していません。それらは別のレイヤーであり、それぞれの持ち場に留まり続けます。