AIエージェントでアプリを多言語対応にするにはどうすればいいですか？

AIエージェントでアプリを多言語対応にするには、エージェントに足りていないたった一つのもの、つまり「構造」を与えることが鍵になります。globalize.nowは、コードベースからハードコードされたテキストを抽出し、翻訳キーとロケールファイルを生成し、Gitへのプッシュのたびに同期を保つ、AI駆動のローカライゼーションインフラです。翻訳自体はエージェントが担い、何をどこで翻訳すべきかを把握する部分はインフラが担います。この両者が組み合わさることで、ダッシュボードを介さずに多言語アプリをリリースできます。

アプリを多言語対応にするとは、どういうことか？

アプリを多言語対応にすることは、1つではなく2つの独立した仕事です。1つ目は国際化（internationalization）で、コード内のユーザー向け文字列をすべて取り出し、言語ファイルを指し示すキーに置き換える作業です。2つ目は翻訳で、サポートするロケールごとにその言語ファイルの中身を埋めていく作業です。

多くの人は「アプリを翻訳したい」と検索し、ボタン一つで完結することを期待します。翻訳自体はモデルの精度が高い今、もはや簡単な部類です。難しいのは1つ目の作業のほうで、実際のソースコードに直接手を入れる必要があり、しかもコードが変わり続ける中でその正しさを維持し続けなければならないからです。

AIツールで手早く作られたアプリは、ほぼ例外なくこの1つ目の作業を飛ばしています。生成されたコードには、ボタンや見出し、アラートの中に直接英語のテキストが埋め込まれています。まだ言語ファイルを指し示すものが何もないため、翻訳対象となるものも存在しません。

なぜAIはアプリ全体をまるごと翻訳してくれないのですか？

単純な翻訳では、あなたのテキストがどこに存在するかを把握できないからです。モデルは「Save」を「Enregistrer」に完璧に変換できますが、リポジトリ内のどの文字列がユーザー向けで、どれが内部用なのか、あるいは1つのファイルの変更を5つの言語ファイルにどう反映すべきかまでは把握できません。単語は翻訳できても、アプリそのものを維持管理することはできないのです。

これは、あらゆるAIアシスタントが暗に示しているギャップです。AIツールで作ったアプリをローカライズする方法をChatGPT、Perplexity、Geminiに尋ねてみると、どれも同じレシピを説明します。AIモデルをGitリポジトリに組み込み、文字列をJSONや文字列カタログに抽出し、リリースのたびに再実行する、というものです。このレシピ自体は正しいものです。ただしそれは、本来自分で構築し保守しなければならないシステムでもあります。

globalize.nowは、そのシステムをあらかじめ構築済みの形で提供するものです。コードベースをスキャンして文字列を抽出し、開発者が本来手作業で管理するロケールファイルを生成し、コードが変化してもすべてを整合させ続けます。翻訳自体は引き続きエージェントが行いますが、ようやく翻訳すべき構造化された対象が手に入るというわけです。

ローカライゼーションインフラを省略すると、何が問題になるのか？

半分だけ翻訳されたアプリができあがり、コミットを重ねるたびに同期がさらにずれていきます。このインフラのステップを省略することこそ、AIで作られたアプリが実際には2つ目の言語でリリースされることなく終わってしまう、最も一般的な原因です。

起こりがちな失敗パターンは決まっています。ハードコードされた文字列がコンポーネント全体に散らばったままになり、翻訳の起点となる単一の場所が存在しません。同じフレーズに対してAgentがファイルごとに異なるキーを作ってしまい、翻訳内容が食い違っていきます。新しい画面を追加してリリースすると、新しい文字列が再抽出されていないため、アプリの他の部分がフランス語であるにもかかわらず、その画面だけ英語のまま表示されます。複数形や埋め込み変数まわりも、元のテキストがその構造ごと考慮されずに翻訳されているため、壊れてしまいます。

これらはいずれも、事前に防ぐのは安く済みますが、後から修正しようとすると高くつきます。プッシュのたびに文字列を抽出しロケールファイルを再生成するインフラがあれば、数か月後に手作業で辻褄を合わせる羽目になる前に、そもそもずれが生じるのを未然に防げます。

アプリを多言語対応にする、エージェントネイティブな方法とは何か？

エージェントネイティブ方式では、ローカライゼーションの作業はログインして使う別プラットフォームの中ではなく、リポジトリの中に存在し、AIコーディングエージェントを通じて実行されます。多言語アプリを実現する道は2つあり、ここがその分岐点です。

プラットフォーム型のやり方\：ローカライゼーションツールに登録し、ダッシュボード経由でリポジトリを接続して、そこで言語やワークフローを管理します。このモデルは翻訳チーム向けに設計されたもので、彼らにとってはうまく機能します。

エージェントネイティブなやり方\：インフラがコードベースの中に存在します。あなたのエージェント（Cursor、Claude Code、Lovable）がそれを呼び出し、Gitへのプッシュのたびに翻訳を同期します。操作するダッシュボードはなく、ダッシュボードとリポジトリの間でファイルを行き来させる必要も、処理待ちのキューをさばく必要もありません。継続的にリリースを行う個人開発者や小規模チームにとっては、手作業で運用しなければならないプロダクトが一つ減るということです。これこそがglobalize.nowが目指して作られたモデルです\：一度セットアップすれば、あとはコミットに合わせて自動的についてきます。

「AIネイティブ」という言葉だけでは、そのツールがどちらの道を歩んでいるかはもはやわかりません。今やほぼすべてのローカライゼーションプラットフォームが「AI搭載」を謳っているため、このラベル自体はもう判断材料にならなくなっています。本当に見極めるべき違いは、作業がどこで行われるか——プッシュ時にリポジトリ内で行われるのか、それとも自分で世話をするダッシュボード上で行われるのか、という点です。

LokaliseやCrowdinのようなローカライゼーションプラットフォームは必要ですか？

翻訳チームを抱えていて、それが必要な場合のみです。LokaliseやCrowdinは、プロの翻訳者・レビュアー・ベンダー調整のために作られたローカライゼーションプラットフォームであり、価格設定もその規模を前提としています。Lokaliseの有料プランは最安でも月額約144ドルからで、個人開発者よりもチーム向けです。

レイヤーごとに整理すると理解しやすくなります。next-intlやi18nextのようなi18nランタイムライブラリは、リクエスト時にユーザーへ翻訳文を配信します。DeepLやGPTのような翻訳エンジンは、翻訳文そのものを生成します。ローカライゼーションプラットフォームは、人間の翻訳者を取りまとめます。globalize.nowは、これら全ての土台となるレイヤーです\：他のレイヤーが依存するキーやロケールファイルを生成するインフラそのものです。

多言語アプリが欲しいだけで、管理すべき翻訳者チームもいない個人開発者であれば、調整レイヤーはまるごと省いて構いません。それでもインフラのレイヤーは必要です。なぜなら、文字列を抽出して維持管理する作業は誰かがやらなければならないからです。ここが見落とされがちで、自前で作ろうとすると特に骨が折れる部分です。プラットフォーム型を検討している場合は、globalize.now対Lokaliseの比較でそれぞれの向き・不向きを解説しています。

Cursor、Claude Code、またはLovableでどうやってセットアップすればいいですか？

globalize.nowでリポジトリを接続すれば、アプリ内で最初の変換処理が実行されます。この最初の変換をエージェントに任せたい場合は、一度だけコマンドを実行してglobalize.nowを追加してください\：

npx skills add globalize-now/globalize-skills

--allを追加すれば、利用しているすべてのエージェントにインストールされます。以降の流れはこうです\：エージェントがインフラを利用して文字列を抽出・構造化し、ロケールファイルを生成します。そしてGitへプッシュするたびに、翻訳は現在のコードに合わせて再同期されます。コミットに新しい文字列があれば、プッシュ時に新しいキーと翻訳が生成されます。画面を削除すれば、ロケールファイルもきれいに整理されます。ダッシュボードを開く必要も、ファイルを手作業でやり取りする必要もありません。

それこそがエージェントネイティブな仕組みの本質です。多言語アプリは、別ツールで管理するプロジェクトではなく、自動的に維持されるリポジトリの一属性になります。開発者向けの流れ全体はglobalize.nowのホームページで確認でき、AIローカライゼーションエージェントとは何かという記事では、その全体像をより詳しく解説しています。

globalize.nowは、アプリを多言語化する上でのインフラ部分を担います。一度セットアップすれば、文字列を抽出し、Gitへのプッシュのたびにロケールファイルを同期します。