Crowdinがi18nエージェントスキルをリリースしたばかりですが、私たちは3月から同様のものを持っています。

Crowdinは8月、JavaScriptアプリをハードコード文字列の状態からCrowdinプロジェクトへ接続済みの状態まで導くエージェントスキルをリリースし、先週その解説動画を公開しました。私たちはそれを喜んでいます。globalize.nowはAI駆動のローカライゼーションインフラであり、この作業を担うエージェントスキルは3月から用意していました。2008年創業の企業が同じ設計にたどり着いたこと自体が、この問題が本物であることの何よりの証拠です。

また、両者のアプローチを正直に比較する良い機会でもあります。行き着く先がまったく異なるからです。Crowdinのアプローチは、その後あなた自身が運用しなければならない翻訳管理システムの中にファイルが収まった状態で終わります。私たちのアプローチは、すでに翻訳が含まれたプルリクエストで終わります。

Crowdinは実際に何をリリースしたのか？

4つの新しいエージェントスキル、書き直されたCLI、そしてそれらをMCPサーバーとまとめたプラグインです。9月4日に公開された8月のチェンジログには、i18n-setup、glossary-generation、crowdin-cli、github-actionが記載されています。これらは、Crowdinが2月からcrowdin/skillsに追加し続けてきたコンテキストおよびAPIクエリ用のスキルに加わるものです。

CLI 5.0は今回のリリースの中で最も優れたエンジニアリングです。JavaからTypeScriptへ移行し、単一バイナリとして配布され、エージェントが読めるようJSONを出力します。Crowdinはこれを「AIエージェント向けに構築」と称していますが、それは妥当な表現です。

目玉はi18n-setupです。9月16日、Crowdinは小規模なサンプルサイトを相手にClaude Code上でそれが動作する様子を収めた7分間の動画を公開しました。

誰が何を最初にリリースしたのか？

それは何を基準にするかによります。そこで私たちは3社すべてのリポジトリのコミット履歴を確認しました。Linguiが1月に最初のエージェントスキルを公開しました。リポジトリにi18nをセットアップし、ハードコード文字列をラップする最初のスキルは、私たちが3月29日にリリースしたものです。

公正を期すために言えば、Crowdinの MCPサーバーは私たちの会社より前から存在しており、彼らのスキルリポジトリも私たちのものより5週間早く作られています。それら初期のCrowdinスキルは、翻訳者向けコンテキストの書き方をエージェントに教えるものでした。アプリケーションコード自体に手を加えるようになったのはその後です。私たちのセットアップおよび文字列ラップのスキルは3月29日付、この一連の流れ全体を動かすオーケストレーターは4月5日付です。Crowdinの同等物は8月28日に登場しましたが、これはそれが依存するセットアップスキルをLinguiが追加してからわずか2週間後であり、検出・判断・セットアップ・ラップという同じ骨格を持っています。

私たちはこれを、模倣の証拠としてではなく、この設計に対する賛辞として受け止めています。前提を受け入れさえすれば、これは自明の形なのです。そしてその動画自体、こんな前提から始まります――「プロダクトは本番投入の準備ができているかもしれないが、それは翻訳の準備ができていることを意味しない」。私たちも3月の最初の投稿で同じ主張をしていました。

この3社以外にも、i18n対応をエージェント経由で行うベンダーは存在するため、世界初を主張するつもりはありません。

Crowdinの「i18n-setup」スキルは何をしてくれるのか？

あなた自身のコーディングエージェント内で7つのフェーズを実行し、リポジトリ内に再開可能なチェックリストを保持します。スキルファイルはよく整理されており、解説内容ともきちんと一致しています。

1. 検出。 リポジトリをスキャンし、使用フレームワークと既存のi18nライブラリの有無を確認します。
2. 決定。 対応言語と、ガイド付き／ガイドなしのどちらで進めるかを尋ねたうえで、plan.mdを書き出します。
3. セットアップ。 Linguiをインストールして設定します。既にライブラリを使っている場合は、それをそのまま活かします。
4. ラップ。 ユーザー向け文字列にマークを付け、POファイルを抽出します。
5. 接続。 CLIでCrowdinプロジェクトを作成し、ファイルをアップロードします。ここでCrowdinトークンが必要になります。
6. コンテキスト。 各文字列の周辺コードを読み取り、翻訳者向けのメモを作成します。あわせて用語集の初期案も提案します。
7. CI。 GitHubワークフローを導入し、新しい文字列がCrowdinへ送られ、翻訳結果が戻ってくる仕組みを整えます。

動画では触れられていない点があります。Crowdinのスキル自体はフェーズ3と4を実行しません。マニフェストではこれらをLingui独自のスキルに委ねており、それは別プラグインとしてインストールする必要があります。Crowdin本来の作業が始まるのはフェーズ5からです。

配慮が行き届いている部分もあります。エージェントはトークンの値を一切見ることがなく、曖昧な点があれば処理を止めて確認してきます。制限事項もファイル内に明記されています。新規インストールはLingui限定で、対象範囲はJavaScriptとTypeScriptのみです。既にi18next、next-intl、vue-i18nを使っているプロジェクトは接続のみの対応となります。Create React Appには対応しておらず、ライブラリ間の移行も行いません。

では、何が自分でやる作業として残るのか？

翻訳そのもの、そして翻訳を実現するために必要な一切です。7つのフェーズをもう一度見てみてください。どれ一つとして翻訳済み文字列を生成していません。

これは意図的な設計です。スキルファイルには自動翻訳がアドオン扱いとして記載されており、デフォルトではオフになっています。「求められていないのに新規プロジェクトを機械翻訳してはならない」という指示もあります。オプトインした場合でも、エージェントが適用できるのは翻訳メモリのみで、新規プロジェクトにはそもそもメモリがありません。機械翻訳やAI翻訳が許可されるのは、Crowdinアカウント内に既にエンジンやプロンプトが用意されている場合に限られます。

スキルの処理が終わると、手元にはCrowdinプロジェクトが残り、そこから先はCrowdinの知識が必要になります。AI翻訳を利用するには、プロフィール画面を開き、自分のAPIキーを使うかCrowdinの残高にチャージするかしてプロバイダーを有効化し、プロンプトを作成します。そのうえで、エディタから事前翻訳を実行するか、作成したプロンプトIDを使ってCLIから実行するか、あるいはプロジェクト単位の自動翻訳設定をオンにします。その後には承認作業、ビルド、ダウンロードといった工程も控えています。

これらの設定場所を既に把握している人であれば、すべて自動化できるでしょう。ただし、そこが落とし穴です。エージェントが担ったのは開発者にとって理解しやすい部分だけで、その先はローカライゼーションマネージャー向けに作られた製品へと引き渡されます。Crowdin自身の解説動画でも、発表者は最終的にエディタを開き、機械翻訳をクリックし、CLIで結果を取得することで中国語の文字列を手に入れています。

CrowdinのMCPサーバーも、このギャップを埋めてはくれません。ドキュメントに記載されているツール群は既存プロジェクト内での操作を前提としており、事前翻訳やプロジェクト作成用のツールはドキュメント上で見当たりませんでした。これはあくまでドキュメントを読んだ範囲での確認であり、すべてのツールを実際に検証したわけではありません。

globalize.nowはどこが違うのか？

i18n変換と翻訳は同じ処理として扱われ、結果はプルリクエストとして出力されます。別途設定するプロジェクトはありません。そもそも「別の場所」が存在しないからです。

標準的な流れはアプリ内で完結します。サインアップし、GitHubまたはGitLabを接続し、リポジトリを選ぶだけです。スキャン結果によって次のステップが決まります。まだi18n対応がなければ、基盤部分を整えます。既にnext-intl、react-i18next、i18next、Linguiのいずれかを使っている場合は、その構成に接続し、ファイル構造には手を加えません。プランを承認すると、変換と翻訳がリポジトリの複製上でクラウド内で並行して実行され、専用ブランチとして出力されます。マージするまでデフォルトブランチには一切影響しません。

この最初の変換は一度きりの処理です。それ以降、新しいソース文字列をプッシュすると、プッシュジョブがそれらを翻訳し、結果をプルリクエストとして開きます。

エディタから離れたくない場合は、同じ処理をプロンプトから開始できます。Claude Code連携とその背後にあるスキル群が、リポジトリの接続を代行してくれます。SDKではなくスキルとして提供している理由については、以前の記事でも解説しています。

Crowdinの7フェーズはあなたのエージェント上で実行されるため、あなたのトークンを消費します。一方、私たちの変換処理はこちら側で実行されます。また、Lovableでアプリを作り、ターミナルを一度も開いたことがない人でも私たちのフローは完結できますが、環境変数のエクスポートから始まる仕組みではそうはいきません。

瞬時に終わるわけではありません。小規模なリポジトリなら数分、大規模なコードベースでは1時間以上かかることもあります。それでもプランには目を通しますし、PRのレビューも行います。当然のことです。

Crowdinのi18n-setup対globalize.now：ステップごとの比較

どんなときにCrowdinを選ぶべきか？

人が翻訳作業を担う場合です。社内の言語スペシャリスト、翻訳会社、あるいはボランティアコミュニティを抱えているなら、翻訳メモリ、用語集、コンテキスト内エディタ、レビュー工程、ベンダー管理といった機能が必要になります。それはまさに翻訳管理システム（TMS）の領域であり、Crowdinは2008年からその構築を続けてきました。私たちはそこを目指してはいません。

CrowdinはXLIFF、ARB、.xcstrings、Android XMLなど、現時点で私たちが対応していない形式にも対応しており、そのスキルはvue-i18nプロジェクトの接続もサポートしています。あなたの主力製品がネイティブモバイルアプリなら、まずそこを確認してください。

料金モデルやチームとの適合性については、比較ページ全体でさらに詳しく解説しています。

業界の大手がこれを打ち出したことにはどんな意味があるのか？

それは、ある議論に決着がついたことを意味するからです。Lingui、Crowdin、そして私たちの間で、コードの準備はエージェントが担い、実際の作業をこなすのではなく開発者はプランを承認する立場にあり、この一連の流れはアプリが実際に書かれているエディタの中で完結すべきだ、という点で意見が一致しています。

それでも意見が分かれるのは、その先の話です。Crowdinの答えは、より優れたダッシュボードへの導線です。私たちの答えは違います。Cursor、Claude Code、Lovableで開発している大半のチームはダッシュボードなど求めていません。彼らが欲しいのは、その日のうちにドイツ語対応したアプリと、ボタンを一つ追加するたびに届くPRです。

エージェントを謳うベンダーに投げかけるべき質問はシンプルです。「エージェントの作業が終わったあと、次にどこへ行く必要があるのか？」。答えが「新しく学ぶべき別の製品」なら、そのエージェントはただの入口にすぎません。答えが「あなたのプルリクエストタブ」であれば、それこそが本質そのものです。

自分のリポジトリで試してみる

Crowdinが行ったのと同じテストを試してみてください。ハードコードされた文字列を含む小さなアプリを用意し、1時間後にどうなっているか確認します。リポジトリを接続し、プランを承認し、プルリクエストを読む。トライアルにクレジットカードは不要です。先に確認したい場合は料金ページはこちら。