今「best localization software」で検索すると、ローカライゼーションベンダー自身が書いた記事が山ほど見つかります。どれも自社を1位に置き、機能比較表を並べ、長所と短所を列挙したうえで、結局は (案の定!) 自社を選ぶべきだと結論づけています。

私たちは、そんな話をするつもりはありません。代わりに、このカテゴリ全体がなぜ間違った問題を解こうとしているのか、そして正しい問題を解くとは実際にどういうことなのかを説明します。

ローカライゼーションスタックは3つに分断されている

2026年に多言語アプリをリリースするには、完全に独立した3つのシステムをつなぎ合わせる必要があります。

1. i18nライブラリ — コードベース内での文字列抽出、補間、複数形処理、ロケールルーティングを担います。翻訳を表示することはできますが、翻訳そのものを作るわけではありません。
2. 翻訳管理システム (TMS) — 翻訳ファイルを保存し、ワークフローを管理し、受け渡しを調整します。コードと翻訳者の間に入る存在ですが、自ら翻訳するわけではありません。
3. 言語サービスプロバイダー (LSP) — 実際に翻訳済みコンテンツを作成する人間の翻訳者、翻訳会社、または機械翻訳エンジンです。あなたのコードやTMSについては何も知りません。

ライブラリは翻訳について何も知りません。TMSはあなたのコードについて何も知りません。翻訳プロバイダーはそのどちらについても何も知りません。これらをつなぎ合わせるには、最初に数週間分のエンジニアリング工数がかかり、その後もファイルのsync、マージ競合の解消、Webhookのデバッグ、そしてそもそもひとつのパイプラインとして設計されていないものの面倒を見るのに、スプリントごとに何時間も取られ続けます。

「エンドツーエンド」が実際に意味するもの

General Translationはライブラリではありません。TMSでもありません。開発者ファーストのチームであるCursor、Cognition、Windsurf、Mintlify、ClickHouseが使っている、翻訳パイプライン全体です。

• オープンソースの開発者向けライブラリ: gt-next、gt-react、さらにReact Native/Expoにも対応。TypeScriptを完全サポートした導入しやすいSDKです。
• AIファーストの翻訳プラットフォーム: コードベース、プロダクト、用語を理解する翻訳プラットフォーム。上に載せただけの汎用的な機械翻訳ではありません。
• AIエージェントのLocadex: コードベースをスキャンし、コードを国際化し、翻訳を生成し、プッシュのたびにプルリクエストを作成する自動国際化エンジニアです。

ライブラリと翻訳エンジンを一緒に構築することで、ローカライゼーションは10倍簡単になります。JSONのエクスポート／インポートも、ファイル管理も、翻訳会社との調整も不要です。翻訳はソースコードから本番環境へ直接流れます。

従来型のTMSプラットフォームの何が問題なのか

従来の翻訳管理システムは、AI以前の時代を前提に作られています。想定しているワークフローも決まっています。コンテンツをコードベースから抽出し、ダッシュボードにアップロードし、翻訳者に割り当て、レビューし、承認し、エクスポートして、再統合するという流れです。うまくいくこともありますが、遅く、コストが高く、壊れやすいのも事実です。

管理対象がコードではなくファイルです。 TMSは翻訳ファイル (JSON、XLIFF、POなど) を取り込み、それを管理するためのツールを提供します。しかし、本当のソースオブトゥルースはコードベース、つまりコンポーネント、変数、UI階層です。コードを理解しないままファイルだけを管理していると、コンテキストは受け渡しの過程で必ず失われます。

多くのプラットフォームはここ数年でAI/MT機能を追加しましたが、たいていは文字列をサードパーティの機械翻訳エンジンに通し、どれを使うか選べるようにしているだけです。AIが見ているのは孤立した文字列だけです。コンポーネントツリーも、変数名も、周囲のUIも見えていません。だからこそ、MTの出力はいまだに大幅な修正が必要になります。

人を増やしてスケールし、作業は減らしません。 TMSのビジネスモデルは、人間の翻訳者を調整することを前提に成り立っています。ロール、権限、レビュー工程、承認ワークフローといった仕組みです。規制要件のあるエンタープライズのコンテンツには必要です。20言語でSaaSアプリを提供する開発チームにとっては、まったくのオーバーヘッドです。

では、価格設定はどうでしょうか。人気の高いプラットフォームの中には、価格を知るだけでも営業との商談が必要なものがあります。別のプラットフォームでは、チームの拡大とともに膨らんでいくユーザー単位の料金が発生します。コストが予測できないと、新しい言語向けの予算を立てるのは難しくなります。

スタンドアロンの i18n ライブラリの問題点

React や Next.js 向けの一般的な i18n ライブラリは、表示まわりの処理には優れています。補間、複数形処理、ロケールルーティング、Server Component のサポートにも対応しています。

しかし、実際には何も翻訳してくれません。

これらは、渡されたものをそのまま表示するだけです。つまり、依然として次のことが必要です。

• すべての翻訳対象文字列を JSON ファイルに抽出する
• ロケールごとに別のファイルを管理する
• それらのファイルを手作業で翻訳するか、翻訳者を雇うか、TMS を導入する
• コードベースの変更に合わせて、すべてのファイルを sync し続ける

10 言語で 500 個のキーがあれば、管理すべき項目は 5,000 件です。50 言語なら 25,000 件になります。ライブラリはそのどれも助けてくれません。渡されたものを表示するだけで、よく言っても問題の半分しか解決しません。

General Translation がループを閉じる仕組み

1. インストールしてコードを書く。 セットアップウィザードを実行し、コンテンツを <T> コンポーネントで囲みます。キーの抽出は不要。JSON ファイルも不要です。

import { T } from 'gt-next';

export default function Home() {
  return (
    <T>
      <h1>Welcome to our app</h1>
      <p>This content is translated automatically.</p>
    </T>
  );
}

2. 開発。 翻訳はon-demandに反映されます。言語を切り替えると、すぐに結果を確認できます。

3. リリース。 1つのコマンドで、build timeにすべての翻訳を生成します。翻訳は事前生成・キャッシュされ、CDN経由で配信されます。世界中で50ms未満。デプロイガイドを見る →

4. 自動化。 Locadex がリポジトリを監視します。コードをプッシュすると、変更をスキャンし、新しいコンテンツを国際化し、翻訳を生成して、PRを作成します。必要でなければ人の手は介在しません。必要な場合は、翻訳エディタで差分を左右に並べて確認し、コンテンツの公開前後を問わず編集できます。

多くの翻訳AIがうまくいかない理由

多くのローカライゼーション向けAIは、文字列を一つずつ、単独で翻訳します。"Apple" は果物のことかもしれないし、会社名かもしれません。"Cell" も、生物学上の細胞なのか、スプレッドシートのセルなのか判別できません。コンテキストがなければ、AIは推測するしかありません。

General Translation のAIは、コードベース全体のコンテキスト — コンポーネント階層、変数名、周囲のUI、製品用語集 — を見て判断します。そのため、手作業で整えなくても、最初から自然でこなれた翻訳を生成できます。さらに、曖昧になりやすいケースを明確にするために、コンポーネント内で直接 明示的なコンテキストを追加する こともできます。

利用量に応じてスケールする料金体系。人数課金ではありません

GT は従量課金制を採用しており、翻訳した分だけお支払いいただきます。チームの拡大に伴って膨らむユーザー単位の料金はありません。営業との打ち合わせも不要です。料金の詳細を見る →