AI エージェントが実際のモノレポを国際化するとどうなるか？

UI文字列候補28件を抽出し、複数ファイルにまたがる翻訳エントリ41件を書き換え、ミドルウェアとルーティングを設定し、5つの対象言語向けにロケールファイルを生成しました。セットアップから変換、翻訳まで、エンドツーエンドでおよそ90分かかりました。globalize.now は AI 駆動のローカライゼーション基盤であり、私たちはそれを実際の本番モノレポに投入し、何が起こるかを検証しました。用意されたデモではありません。安全網もありません。実際の複雑さを持つ、本物のコードベースです。

このコードベースは、大手翻訳管理プラットフォームでアーキテクトとして10年以上働いてきたローカライゼーション業界のベテランが所有するものでした。

モノレポの中身は？

これはチュートリアル用のプロジェクトではありませんでした。モノレポには Next.js の Web アプリケーション、Android アプリ、MCP サーバー、そしてサードパーティのサービスでレンダリングされるドキュメントが含まれていました。この開発者は日常的に Claude Code を使い、AI ツールだけでエンドツーエンドの構築を行い、このスタック全体をわずか3か月で組み上げていました。

対象は Next.js のフロントエンドでした。Android アプリ、MCP サーバー、Mintlify で構築されたドキュメントサイトには手を触れないようにする必要があります。問題は、AI エージェントが明示的な指示なしにそれを判断できるかどうかでした。

できました。エージェントはリポジトリ全体をスキャンし、Next.js アプリケーションに焦点を絞りました。実際には手動でのスコープ指定は不要でしたが、開発者は「/apps/web だけを変換する」と指定できる機能があれば安心できたと述べています。これは妥当な指摘であり、追加する価値があります。ただし、それが変換の妨げにはなりませんでした。

設定はどのように進んだのか？

開発者はプロセスを理解するために、ガイド付きモードを選択しました。設定では5つの決定事項がありました――パッケージマネージャー（レガシーな PNPM のロックファイルが存在していたにもかかわらず NPM を選択）、カタログ形式（コメント対応の観点から PO/GetText を推奨）、セットアップモード（ガイド付き）、ソース言語（英語）、そして対象言語（スペイン語、イタリア語、ハンガリー語、チェコ語、スロバキア語）です。

注目すべき点が一つあります。カタログ形式に関する質問は、深いローカライゼーションの知見を持つ人物でさえ迷わせるものでした。彼の反応は率直でした。この選択はユーザーに尋ねるほど重要なものではないはずだと考え、「自動化すべきだ」と述べています。

ルーティング戦略はパスベースでした。開発者が追加のドメインを所有していなかったため、ドメインベースのルーティングは使いませんでした。アプリは OAuth ベースの認証を使用しているため、ログインフローは意図的に英語のままにされています。エージェントはこれを正しく処理しました。

変換ステップは実際に何をするのか？

ここが肝心な部分です。エージェントは Next.js アプリ 全体からUI文字列候補28件を特定し、41件の翻訳エントリを処理しました。ファイルを再編成し、ミドルウェアを更新し、コンポーネントの import 文を修正し、5つの対象言語すべてについて PO 形式のロケールファイルを生成しました。

変換ステップ単独ではおよそ30分かかりました。それに先立つセットアップと設定、そしてその後開発者が独力で完了させた翻訳の接続作業を加えると、エンドツーエンドの全体はおよそ90分に近づきます。決して一瞬というわけではありません。参考までに、ページ数が少ないシンプルなアプリであれば、全工程は15分以内で完了します。翻訳対象の箇所が数十にのぼる複雑なアプリでは、それだけ時間がかかります。所要時間はリポジトリの規模ではなく、文字列の数に比例します。

開発者は変換ステップの実行を見守りながら、こう語りました――文字列抽出とコードの書き換えこそが本当に骨の折れる作業であり、開発者が最も嫌がる仕事だと。彼が以前勤めていた大手 TMS 企業では、リポジトリ内の翻訳ファイルは氷山の一角に過ぎませんでした。準備作業と国際化対応こそが本当の苦労だったのです。そして AI エージェントは、まさにその部分を処理しました。

これは、i18n を手作業でこなしてきたあらゆる開発者から聞く話と一致します。誰も翻訳そのものについては文句を言いません。文句が出るのは、40個のファイルに手を入れて文字列を t() 呼び出しで包み、意味の通るキーを生成し、import文を整理し直し、ミドルウェアを設定する作業についてです。それこそが、globalize.now が自動化する 仕事なのです。

実際にエンドツーエンドで機能したのか？

はい。ライブセッションが終わった後、開発者は残りの工程を独力で完了させました。globalize.now の Git ブランチを公開し、アプリを Web プラットフォームに接続し、globalize.now ブランチへの監視を設定し、ファイルが正しくアップロードされ翻訳されていることを確認しました。

彼によるチェコ語の翻訳品質の評価――ほぼ完璧。これは、キャリアを通じてローカライゼーションの成果物をプロとして評価してきた人物の言葉です。ただの好意的な評価ではありません。難易度の高い言語ペアにおいて、本番投入に耐えうる品質であることを、専門家自身が確認したということです。

彼は、フローを独力で完了させた後、Web アプリに関する2つの問題を指摘しました。まず、翻訳ジョブは実際にはバックグラウンドで実行されていたにもかかわらず、リポジトリを再スキャンすると「i18n ファイルが検出されません」と表示されました。これは実際の失敗ではなく、誤解を招くUI表示の問題です。次に、翻訳ジョブが明示的な同意なしに開始されてしまいました。クレジットを消費するアクションには確認を必須にすべきです。どちらも正当な UX の課題であり、現在対応が進められています。

うまくいかなかった点は？

実際にトラブルは起きました。これは本物のテストだったので、正直にお伝えします。

インストールコマンド（npx skills add globalize-now/globalize-skills）は Windows の PowerShell では失敗しました。このツールが Windows でテストされたのはこれが初めてでした。Google がメール添付をブロックしたため、スキルファイルは Swiss Transfer 経由で zip ファイルとして送る必要がありました。実際のフローが始まるまでの、セットアップ時のもたつきの合計はおよそ15分でした。

変換の途中で、ES モジュールと CommonJS の間の不整合が表面化しました。このプロジェクトは CommonJS を使用していましたが、エージェントの出力の一箇所は ES モジュールを前提としていました。作業を止めるほどの問題ではありませんが、セットアップ時に検出し、事前に対処できるようにすべき点です。

セッションの最後に、globalize.nowのWebアプリでGitHubリポジトリを接続したところ、白紙のページが返ってきました。開発者が使用していたのはOperaでした。ログイン画面もエラーも表示されず、何のコンテンツも出てきません。この問題は解決しないままセッションが終了しました。

バグは3件。すべて実在するもので、すべて修正済みか対応中です。

なぜ文字列抽出こそが本当のボトルネックなのか？

i18n関連のコンテンツの多くは、翻訳品質やフレームワークの設定、TMS機能の比較に焦点を当てています。しかし、それでは開発者が実際に時間を浪費しているポイントを見落としてしまいます。

既存のコードベースに国際化を導入するということは、すべてのコンポーネントをスキャンしてハードコードされた文字列を探し出し、どの文字列を翻訳対象にするか判断し、意味の通る翻訳キーを生成し、各文字列を適切なt()または<Trans>呼び出しでラップし、ファイルツリー全体でインポートを更新し、初期のロケールファイルを作成し、ルーティングミドルウェアを設定することを意味します。モノレポの場合は、そもそもコードベースのどの部分にi18nが必要なのかを見極める複雑さも加わります。

これは地道で、ミスが起きやすく、まさにAIエージェントが得意とする類いの作業です。この様子を見ていた開発者は率直にこう表現しました――開発者の視点から見れば、これこそが一番きつい力仕事だ、と。これは大きな救いです。AIツールで開発するバイブコーダーたちは、グローバル展開における最も厄介な部分を、丸ごとスキップできるようになりました。

モノレポのスコープ設定について何が分かったか？

エージェントはモノレポのスコープ設定を暗黙のうちに適切に処理しました。Next.js製のWebアプリに焦点を絞り、指示していないにもかかわらずAndroidのコードやMCPサーバー、Mintlifyのドキュメントは対象外としました。ほとんどのケースにおいて、これは正しい挙動です。

しかし、暗黙のスコープ設定と明示的なスコープ設定は同じではありません。開発者が求めていたのは、「私のNext.jsアプリだけを変換して」と設定ステップとして指定できる機能でした。複数のWebフロントエンド――例えば顧客向けアプリと管理者用ダッシュボード――を持つモノレポでは、どのフロントエンドから先に国際化するかを精密にコントロールできることが望まれます。

これは現在私たちが解消に取り組んでいるプロダクト上のギャップです。今のところ、エージェントは実運用上は正しく判断できています。とはいえ、変換対象が数十ファイルに及ぶ場合は特に、明示的なスコープ指定は設定ステップとして用意されるべきです。

手動でのi18nセットアップと比べてどうなのか？

これほど複雑なコードベースに対して手動でi18nをセットアップすると、数日かかります。どの工程も単体で見れば難しいわけではありませんが、手順が数十もあり、そのひとつひとつに注意を払う必要があるからです。文字列を1つ見落とせば、中途半端に翻訳されたページを本番にリリースしてしまいます。キー名を間違えれば、重複エントリが生まれ、何カ月も後を引きずります。ミドルウェアの更新を忘れれば、ロケールのルーティングが静かに壊れます。

AIエージェントは、これと同等の作業を端から端まで約90分でやり遂げました。何千ものi18n実装をプロフェッショナルとして見てきたこの開発者は、それを「エレガントだ」と評しました。

AIツールで開発する開発者にとって、これは言語対応をいつ始めるかという計算そのものを変えます。i18nのセットアップに1週間かかるなら、プロダクトマーケットフィットが証明されるまで後回しにするでしょう。しかし90分で済むなら、初日から多言語対応でリリースできます。

globalize.nowはこれを解決します。リポジトリを接続すれば、変換はアプリ内で一度だけ実行され、その後の工程はnpx skills add globalize-now/globalize-skillsスキルがエディタ上でカバーします。仕組みの詳細はglobalize.nowでご確認ください。