ローカライズはSDKではなく、エージェントのスキルになりつつある

かつてアプリをローカライズするといえば、SDKを追加し、プロバイダーを組み込み、キーを手作業で管理することを意味していました。AIコーディングエージェントを使えば、もっと近道があります。スキルをインストールすれば、あとはエージェントが配線してくれるのです。globalize.nowは、オープンなエージェントスキルとして提供されるAI駆動のローカライズインフラです。コマンドを一つ実行すればエージェントがプレイブックを読み込み、新しい仕組みを自分でメンテナンスすることなく、コードベースが翻訳対応の構造になります。

エージェントスキルとは何か？

エージェントスキルとは、コーディングエージェントが読み取って実行する、ちょっとした指示のパッケージです。オープンなスキルエコシステムを通じて配布され、たとえばnpx skills add owner/repoのようにスキルCLIでインストールします。同じコマンドが、Claude Code、Cursor、Codex、OpenCodeをはじめ、50を超えるエージェントで動作します。

スキル自体はSKILL.mdファイルと、それに付随するサポートファイルで構成されており、エージェントがすでに参照しているディレクトリにそのまま配置されます。CLIはそれを単一の正規コピーにリンクし、インストール内容をロックファイルに記録するため、スキルはベンダーのアカウントに存在するのではなく、プロジェクトの他の部分と同様にバージョン管理されます。さらに公開レジストリもあるため、スキルは他の依存関係と同じように、見つけ、読み、バージョンを固定できるものになっています。

注目すべき変化はこうです。スキルはエージェントが「統合する」対象の製品ではありません。エージェントが「吸収」し、それをコードに適用していく知識なのです。この違いは、チームメンバーをオンボーディングした瞬間に実感できます。相手がリポジトリをクローンすれば、そこにはすでにスキルが存在していて、彼らのエージェントもあなたのものと同じ方法でローカライズを処理してくれます。

なぜi18nをSDKではなくスキルとして提供するのか？

国際化における本当の難所はリファクタリングであり、スキルはそれをエージェントに代行させる方法だからです。SDKは、コードがすでに翻訳向けに構造化されていることを前提としています。ハードコードされた文字列を見つけ、キーの命名体系を設計し、ロケールファイルを作成し、ランタイムライブラリを接続する作業は、結局自分でやらなければなりません。

AIで構築されたアプリでは、この問題はさらに悪化します。コーディングエージェントは、翻訳のしやすさではなく「画面が動くこと」を最適化するからです。出力されるコードは大抵正しく、そのままリリースできる一方で、キー呼び出しの代わりに<button>Submit order</button>のような文字列で埋め尽くされています。これがプロジェクト全体に積み重なると、ローカライズ作業は設定変更ではなく、まるごとのリファクタリングになってしまいます。

放っておくと問題は雪だるま式に膨らみます。同じラベルが微妙に違う3通りの書き方で存在するようになり、件数表示は1 messagesのまま描画され、初めて言語を追加しようとしたときには、画面の半分が英語のままになっていることに気づきます。スキルは、それが何百もの細かなチケットになる前に、一気にまとめて取り除くよう設計されています。

スキルは、そのリファクタリング作業をエージェントが実行できる指示として符号化します。使用しているフレームワークを検出し、next-intlやi18nextなどすでに使っているi18nランタイムを確認し、英語の文字列を抽出し、キーとロケールファイルを生成します。新たにバージョン管理やメンテナンスが必要なランタイムを導入する必要はありません。スキルはセットアップを済ませたら、あとは表に出てきません。

スキルはMCPサーバーとどう違うのか？

MCPサーバーはエージェントが呼び出すサービスであり、スキルは単にプロジェクト内のファイルです。Model Context Protocolは、稼働中のサーバーを通じてエージェントにライブのツールやデータを提供する良い方法です。しかしサーバーは、あなた自身か誰かのベンダーがホストしなければならないものであり、エージェントはそれが接続可能であることに依存します。

スキルの背後にはサービスが存在しません。リポジトリに含まれるテキストとコードであり、ネットワーク接続なしで動作し、他の変更と同様にプルリクエストにも現れます。コードベースの国際化のような一度きりのセットアップ作業には、稼働させ続けなければならないサービスよりも、ファイルの方が優れています。スキルが何をするかを事前に読んで、実行し、差分をレビューできます。

スキルは重ねて使うこともできます。それぞれが単なる指示であり、稼働させたり料金を払ったりする必要のある別プロセスではないため、複数インストールしても互いに共存できます。

globalize.nowはどのようにエージェントスキルとしてインストールされるのか？

コマンド一つで、あとはエージェントが引き継いでくれます。

npx skills add globalize-now/globalize-skills --all

--allフラグを付けると、手元のマシン上にあるすべてのエージェント向けのスキルが一括インストールされるため、どのエージェントを使っているか分からない場合でも安全な既定の選択肢になります。CLIは、エージェントがスキルを探す場所にglobalize.nowのスキルを配置します。Claude CodeやCursorを含む、すでに使っているエージェントでそのまま動作します。

あとはエージェントにi18nのセットアップを依頼するだけで、フレームワークの検出、ランタイムライブラリの確認、ユーザー向け英語文字列の検出、キーとロケールファイルの生成というプレイブックに沿って進みます。開発者が実感するのは、この「導入前後」の違いです。

// before
<button>Submit order</button>

// after
<button>{t("checkout.submit_order")}</button>

生成されたキーは、スキルが作成・保守してくれるロケールファイルに収まります。

/locales
  en.json
  de.json
  es.json
  fr.json

英語ファイルは、エージェントが見つけた文字列で自動的に埋められます。他の言語は生成され、プッシュのたびに最新状態が保たれるため、新しい市場への展開はスプリントではなく、ロケールファイル1つで済みます。

セットアップ後は、Gitへのプッシュのたびに翻訳が自動同期されます。何かをエクスポートする必要もなければ、クリアすべきキューもありません。vibeコーディングでアプリを作っているなら、これで作業は完結です。詳細を知りたい開発者であっても、同じスキルがリファクタリングをきれいに実行し、標準的なロケールファイルだけを残してくれます。

翻訳データは自分のリポジトリに残り続けますか？

はい。スキルが生成するロケールファイルは、他のソースファイルと同様に自分のリポジトリにコミットされます。これは、ロックインを避ける上で最も重要なポイントです。

一部のアプローチでは、翻訳済みの文字列をビルドステップやホスト型ダッシュボードに移してしまうため、そのサービスから離れる日が来れば、翻訳レイヤーごと持っていかれてしまいます。リポジトリに直接置かれるロケールファイルの場合、en.jsonやde.jsonなどはプロジェクト内のただのファイルです。仮にこのスキルが明日消え去ったとしても、アプリはすでに対応しているすべての言語をそのまま配信し続けます。離れるときは、単にスキルを再インストールしないだけで済み、何かを移行する必要もありません。なぜなら、あなたのものはそもそも他の場所には一切存在していなかったからです。だからこそglobalize.nowは、アプリを覆い尽くすラッパーとしてではなく、キーとロケールファイルを生成するインフラ層としてスタックの中に収まっているのです。

このスキルモデルは特定のベンダーに縛られることになるのか？

いいえ、むしろロックインを避けられることこそが、このモデルを選ぶ理由です。スキルは、閉じたプラグインストアではなく、対応するどのエージェントからでも読み取れるオープンなレジストリからインストールされます。出力される成果物も、後から解きほぐす必要のある独自形式ではなく、すでに選択済みのランタイムライブラリ向けの標準的なロケールファイルです。

スキルは単なるファイルなので、実行する前にそれが何をするのか正確に確認できます。理屈より実際の手順を丸ごと知りたい場合は、AI生成アプリのローカライズ方法ガイドで同じセットアップを最初から最後まで解説しています。