なぜローカライゼーションは開発ループの上流へと移りつつあるのか？

ローカライゼーションが上流に移りつつあるのは、従来のパイプラインの根本的な前提が崩れたからです。その前提とは、コードは十分にゆっくり変化するため、安定した文字列カタログをエクスポートし、別の場所で翻訳し、次のリリース前に結果をインポートできる、というものでした。AIコーディングエージェントは、その前提を消し去りました。globalize.nowは、この新しい立ち位置のために構築されたAI駆動のローカライゼーション基盤です。開発ループの内側で動き、プルリクエストとして出荷されるローカライゼーション。本稿のテーマは、翻訳品質ではなく「立ち位置」こそが変わったものである、という点です。

ローカライゼーションを上流に移すとはどういうことか？

それは、ローカライゼーション作業の単位が文字列カタログではなく、コミットになることを意味します。従来のモデルでは、ローカライゼーションはコードが完成した後に始まります。上流モデルでは、コードが存在する場所で、コードが変更されるまさにその瞬間に発生し、その成果物はコードそのものです。つまり、差分確認・レビュー・マージを行うローカライズ済みPRです。

2つのパイプラインを図にすると、次のようになります。

Traditional:   build → internationalize → export → translate → review → import → ship

Upstream:      code → push → localized PR → merge → ship

最初のパイプラインは7つの段階を持ち、リポジトリの外に2回出て行きます。もう一方は5つの段階しかなく、そのどれもがリポジトリの外に出ることはありません。この構造的な違いこそが、本稿が扱うテーマであり、単一の機能の話ではありません。

従来のローカライゼーションパイプラインはどのように機能するのか？

これは往復のプロセスとして動作し、その中のすべての矢印はキューです。まず機能を実装します。次にそれを国際化し、文字列をキーとして抽出します——チームやAIエージェントがそもそも構造化されたコードを書いていたと仮定しての話ですが。カタログを翻訳プラットフォームにエクスポートします。翻訳者または機械翻訳がそれを処理します。誰かがレビューします。結果をインポートし、カタログが外に出ている間に蓄積した競合を解消し、リリースします。

それぞれの受け渡しが存在するのは、作業が別々の場所で、別々の担当者によって、別々のタイミングで行われるからです。リリースが四半期ごとで、文字列がまとまって変わっていた時代なら、これは理にかなった設計でした。このパイプラインには隠れた前提条件があります——安定性です。往復を成立させるには、カタログがしばらくの間動かずにいる必要があるのです。

もはやカタログはじっとしていません。DORA 2025 State of AI-Assisted Software Development reportによれば、ソフトウェア専門家の90%が業務でAIツールを使用していると回答し、DXの2025年第4四半期の影響調査では、追跡対象企業の中央値でマージされたコードの22%がAIによって書かれたものだと測定されています。以前は週単位で変わっていたコードが、今では昼食からスタンドアップミーティングまでの間に変わってしまいます。

開発ループの中でローカライゼーションはどう見えるのか？

プッシュ時に実行される他の自動チェックと同じです。コードベースの変換は一度だけ行います——文字列の抽出、キーの生成、ロケールファイルの作成、ランタイムの配線が完了します。その後は、プッシュのたびに同期が実行されます。コミットで新しい文字列が導入されると、翻訳結果はプルリクエストとしてあなたのブランチ、あなたのリポジトリに、アプリの他の部分と同じ構造で戻ってきます。

これは机上の話ではありません。2026年8月にデモリポジトリで記録した実行結果では、プッシュされたコミットが49秒で、ドイツ語・フランス語・スペイン語にわたる30の翻訳単位をカバーするローカライズ済みPRとして戻ってきました。1分足らずで、コミットからレビュー可能なPRまで、レビューに至るまで人の手を介しません——「エクスポート」という言葉が出てくるパイプラインと比べてみてください。

誤解のないように言っておくと、この一度きりの変換は瞬時には終わりません。実際のアプリでは30分ほどかかります。文字列の抽出、キーの生成、ランタイムの配線というコードの再構築を行うからです。これは入口にすぎません。その後のプッシュのたびに動くループこそが本当の製品なのです。

このループの重要な特性は、速さではありません。何もリポジトリの外に出ないという点です。外部プラットフォームにmainからじわじわ乖離していくカタログが存在しないのです。以前公開したモノレポでの実行結果は、この一度きりの変換が規模を問わず機能することを示しました。ループはその結果をその後も生かし続けるものです。マージするか、クローズするか——他のあらゆる変更を支配するのと同じ二つの動詞です。すでにこのやり方で開発しているなら、開発者向けドキュメントにセットアップ方法が載っています。

なぜAIコーディングエージェントはこの変化を強いるのか？

ボトルネックの場所が移動したからです。かつてローカライゼーションの制約は翻訳能力でした——ベンダーやエンジンが整った構造のカタログをどれだけ速く処理できるか、というものです。エージェントはその制約をはるかに超えて文字列を生成し、その上流に新たな制約を生み出しました。今、希少な資源となっているのは生成後のアーキテクチャ上の健全性です。エージェントが毎日コードベースにUIを追加していく中で、キーの一貫性、ロケールファイルの完全性、構造の維持を保つことです。

チェックアウトページを頼まれたエージェントは、文字列がJSXにハードコードされた、動作するチェックアウトページを作ります。この構造についてはAI code broke localizationで詳しく書きました——分析したあるReactプロジェクトでは、312ファイルにわたって1,284個のUI文字列があり、i18n構造は皆無でした。従来のパイプラインがエクスポートしようとするカタログは、そのコードベースには存在しません。そして明日にはまたコードベースの姿が変わっています。エージェントは出荷し続けるからです。

下流のパイプラインは、その現実に永遠に遅れをとります。エクスポートした時点で、それはもう古くなっています。生成されたコードにローカライゼーションが追いつける唯一の位置は、コードを生成しているループの内側です。そしてそれは、コードがCursor、Claude Code、Lovableのどれから来ていようと変わりません。

AI翻訳も同じことではないのか？

いいえ、そしてここが市場の議論が的を外しているところです。Lokaliseは自らをAIローカライゼーションプラットフォームと呼び、PhraseはLanguage AIによる大規模な機械翻訳を提供しています。どちらも実在する機能です。どちらも従来のパイプラインにある一本の矢印——翻訳ステップ——を速くします。それでもカタログはエクスポートされ、外部プラットフォームに置かれ、インポートを経て戻ってくるのです。

七段階の往復プロセスにおいて矢印を一本速くするのは、最適化にすぎません。往復そのものをなくすのは、まったく別の製品です。これが本当のレイヤーの違いです——翻訳者のワークフローを中心に構築されたプラットフォームは管理層に位置し、globalize.nowはその下のインフラ層に位置し、コード自体からキーとロケールファイルをリポジトリ内で生成します。「AI搭載」という言葉はどちらにも当てはまります。それでは両者を区別できません。区別するのは位置なのです。

それでも下流に残るものは何か？

リスクの高い文章に対する人間の判断です。法務文書、規制対象の表現、特に大切にしている市場でのブランドボイス——これらにはプロの翻訳者とレビューの工程がふさわしく、そうしたニーズを持つチームは翻訳者ワークフロー向けのツールを引き続き使うでしょう。上流でのローカライゼーションは、それを妨げるものではありません。ローカライズされたPRはレビュー可能な対象であり、人間はマージ前にどんな基準でも適用できます。

終わるのは、第二言語を出すためだけに、どのチームも翻訳者ワークフロー向けのプラットフォームを導入しなければならなかった時代です。AIで構築された製品を持つ一人の開発者に、管理すべき翻訳者はいません。あるのはコミットです。ツールの側がそこに合わせるべきなのです。

ループこそが製品である

あなたのコードがプルリクエストを通じて出荷されるなら、翻訳もそうあるべきです。globalize.nowはコードベースを一度変換し、その後はプッシュのたびにローカライズ状態を保ちます——PRが入り、PRがマージされ、出荷される。