i18n対応が中途半端？globalize.nowが触れる部分・触れない部分を解説します。

あなたのリポジトリにすでにnext-intl、react-i18next、i18next、Linguiのいずれかが組み込まれている――ディスク上にロケールフォルダがあり、package.jsonに依存関係が入っていて、ミドルウェアや設定ファイルもある――のであれば、ゼロからのスタートを前提とする別のツールは必要ありません。globalize.nowはAI駆動のローカライゼーション基盤です。L1（すでに国際化済み）モードでは、破壊的なセットアップ用のスキャフォールドをスキップし、同期モードにとどまります。すなわち、ソース言語を読み取り、プッシュのたびに他のロケールとの差分を取り、補完内容を含むプルリクエストを開きます。この記事では、このモードが触れる範囲、触れない範囲、そして検出結果が誤っていた場合の対処法について説明します。

なぜ、ほとんどのi18nに関するアドバイスは「ゼロからのスタート」を前提としているのでしょうか？

i18nツールのマーケティング資料は、いまだに「グリーンフィールド」――ライブラリ未導入、ロケールファイルなし、抽出作業も未着手――というケースを前提に語られがちです。しかし、ほとんどの本番コードベースはそのような状態ではありません。

ここ数週間、無関係な3件の初回相談セッションで、まったく同じパターンが見られました。チームは一度i18nに挑戦し、中途半端に動く状態まで作ったところで手が止まっていた――一度取り除いてやり直すことのほうが、いまの混乱を抱えたまま使い続けるより大変に思えたからです。

もし思い当たるなら、この記事はまさにあなたのために書かれています。

「半分だけ国際化されたコードベース」とは、実際どのようなものでしょうか？

次のようなパターンが繰り返し見られます（詳細は匿名化しています）。

• Next.js + next-intlのアプリで、ほとんどのコンポーネントはt()を使っているものの、古いルートには最初の移行が終わらなかったせいで英語のハードコードされた文字列がまだ残っている、というケース。
• React + i18nextのプロジェクトで、ロケールファイル自体は存在するものの中身が英語のままになっている――翻訳作業は常に「来四半期にやる予定」だった、というケース。
• messages/のツリーで、en.jsonの中身は充実しているのにes.jsonはほぼ空、というケース。
• レイアウトに言語切替スイッチャーが組み込まれているものの、ルーティングが半分しか移行されていないせいで、時々404エラーになってしまうというケース。

これらのプロジェクトはどれも、globalize.nowによる「やり直し」を必要としているわけではありません。必要なのは、作業を完了させることです。

globalize.nowは初回実行時、どのようなシグナルをスキャンするのでしょうか？

検出処理は1段階ではなく、2段階で行われます。

まず、globalize.nowをリポジトリに向けて実行します。アプリ内で接続すれば、検出と一回限りの変換処理が自動的に行われます。エージェントにこの処理をローカルで実行させたい場合は、スキルをインストールしてください。これにより、.claude/skills/にいくつかのプレイブックファイルが追加されるだけで、リポジトリの他の部分には一切変更が加わりません。

npx skills add globalize-now/globalize-skills

Then prompt your agent — Claude Code, Cursor, or Codex. The agent reads the installed skills and uses them to scan your repo:

Set up localization for my project

実際に検出処理が行われるのは、この2番目のステップです。エージェントは以下を確認します。

• package.jsonの依存関係： next-intl、react-i18next、i18next、@lingui/core、@lingui/react、@lingui/macro、または任意のi18next-*プラグイン。
• ロケールフォルダ： リポジトリのルートにあるmessages/、locales/フォルダ、あるいはロケールごとのサブフォルダを持つsrc/i18n/。
• 既存のロケールファイル： en.json、en.po、en.yml、en.yaml、あるいはお使いのライブラリがすでに想定しているデフォルトロケールのファイル。
• フレームワーク固有の設定： i18n.config.ts、next-intlのミドルウェア、lingui.config.js、あるいはそれらに相当するもの。

これらのシグナルのうち少なくとも2つが確認できれば、そのプロジェクトはすでに国際化済みのL1として扱われ、フルセットのグリーンフィールド用スキャフォールドを実行する代わりに、セットアップフローが分岐します。詳細は既存i18nに関するヘルプセンターの記事をご覧ください。

L1モードでは、何を変更しないのでしょうか？

ここが皆さんが気にする部分です。L1モードでは、globalize.nowは次のことを行いません。

• コンポーネントをスキャンしてハードコードされたリテラルを探す、広範な文字列抽出処理の実行。
• 新しい翻訳キーの生成や、すでに採用済みのキー構造の並べ替え。
• まだ設定していない言語のロケールファイルのスキャフォールド生成。
• 言語切替スイッチャーの挿入。すでにお持ちであればそのまま残し、なければ新たに追加することもありません。
• ルーティング、ミドルウェア、フレームワーク設定の書き換え。

既存のi18nセットアップはそのままあなたのものです。このモードでは、私たちがそれをリファクタリングすることはありません。

検出処理の後、L1同期モードは何を行うのでしょうか？

L1は同期優先で動作します。検出処理が確定した後は――

1. 既存のロケールファイルを読み込み、現在のキー構造と、どの言語がソースオブトゥルース（正となる言語）かを把握します。
2. globalize.nowのCLIまたはWebアプリを通じて、GitHubリポジトリを接続します。
3. mainブランチへのプッシュのたびに、ソース言語のファイルと他のロケールファイルとの差分を取ります。不足している翻訳は、あなたが設定した用語集とスタイルガイドに準拠したAI出力によって補完されます。
4. 更新されたロケールファイルを含むプルリクエストが作成されます。レビューとマージはあなたが行います。私たちが代わりにマージすることはありません。

これがひとつのループです。面倒を見る必要のある翻訳ダッシュボードもなければ、手動でのエクスポートも、ファイル形式のあれこれの調整も必要ありません。

これを、Cursorで構築したNext.jsアプリに15分でi18nを追加するには？で紹介しているL0の手順と比べてみてください。同じプロダクトでも、入り口となる経路が異なります。

UIの一部だけが翻訳呼び出しを使っている場合はどうすればよいですか？

それは移行途中のよくある形です。新しい画面はt()を使い、古い画面にはまだリテラルが残っている、という状態です。同期モード以外では、スキルによる処理フローはすでにキー化された文字列をロックされたものとして扱います。まだ組み込まれていないリテラルにのみ着目し、既存のキーはそのまま維持します。移行の途中でも毎週リリースを続けているチームこそ、私たちのログにおける典型的な「混在型L1」ユーザーです。

複雑なツリーに対してエージェントがフルで変換を行った事例については、AIエージェントが実際のモノレポを国際化するとどうなるか？をご覧ください。

セットアップフローがとにかくすべてをスキャフォールドしてしまった場合、どうすればよいですか？

検出ロジックは現在改善を進めており、誤った分岐が発生しにくくなるようにしていますが、もしnpx skills add globalize-now/globalize-skillsがすでにロケールフォルダを書き換える100件以上のファイル差分を生成してしまったり、頼んでもいないスイッチャーを追加したり、ルーティングを作り変えてしまったりした場合は、それをコミットしないでください。右下のフィードバックウィジェットから、package.jsonの依存関係リストと、ロケールフォルダの構成についての簡単なメモを送ってください。こちらでリポジトリを手動でL1に振り分けることができます。セルフサーブの--existing-i18n CLIフラグも近日提供予定です。

お使いの環境での復旧作業は、必要に応じてgit restore .とgit clean -fdを実行するだけです。何もプッシュされておらず、本番環境に影響が及ぶこともなく、エージェントが触れたのはあなたのローカルブランチだけです。詳しい経緯はglobalize_skillsが変更しすぎてしまった――何が起きたのか？にまとめています。

なぜ「i18nに挑戦したものの、途中で止まってしまった」が今や定番のストーリーになっているのでしょうか？

これはスローガンではなく、実際によく見られるパターンです。6週間のうちに3件の独立した初回相談セッションがあり、いずれも「ええ、あれは一度試したんですが、今は使いづらい状態になっています」という似た内容でした。数万人規模のユーザーを抱えるあるChrome拡張機能は、韓国からのアクセス急増をきっかけに、中途半端に終わっていたnext-intlへの移行が表面化しました。Lovableで構築されたあるアプリは、多言語対応を追加しようとして自らビルドを壊してしまい、変更が取り消されました。バイブコーディングで作られたReact + Vite製のリポジトリでは、i18nextを組み込んだものの、キーの約3分の1だけ埋めたところで作業が止まっていました。

ライブラリ選定を待つだけの、完全にきれいなL0のコードベースというものも確かに存在しますが、それはボトルネックではありません。本当のボトルネックは、すでに一度この作業に挑戦していて、その後始末を誰も引き受けたがらないコードベースのほうです。

L1モードは、まさにそのようなコードベースのために存在します。

料金はいくらですか？

月額20ユーロで、プランはひとつだけです。含まれる語数はおよそ16,000語（アプリの標準的な画面にしておよそ80画面分程度）です。登録時には5ユーロ分の翻訳クレジットが付与されます。きれいなL0のグリーンフィールドから始めた場合でも、3年分のロケール負債を抱えたL1の状態から始めた場合でも、料金は同じです。私たちが計測しているのはスループットと自動化の度合いであり、最初のコミットがどれだけ乱雑だったかではありません。

次に読むべき記事やヘルプセンターのドキュメントはどれですか？

• CursorのNext.jsアプリ向けL0セットアップ手順
• モノレポの事例紹介――エージェントが実際に触れた範囲
• 従来型TMSツールが現代的なGitネイティブスタックにうまく対応できない理由
• ヘルプセンター：すでにi18nを導入済みです――globalize.nowは何をしてくれますか？
• ヘルプセンター：globalize_skillsによって変更が多すぎた件について

すでにトラフィックが求めている言語を先に届けましょう――globalize.nowでリポジトリを接続するか、Gitプッシュによる自動化が既存のチームのワークフローにどう組み込まれるかをお読みください。