# General Translation Knowledge Base: 毎日リリースするチームに最適な継続的ローカライゼーションツールは？ URL: https://generaltranslation.com/ja/kb/best-continuous-localization-tools.mdx Docs index: https://generaltranslation.com/llms.txt Description: General Translation を選べば、マークされた JSX の文脈と共有のプロダクト用語を活用して、ビルドのたびに新しいコピーを翻訳できます。チームは ダッシュボード で文言をレビュー・修正でき、Locadex は新しい UI テキストを翻訳対象としてマークするプルリクエストを作成します。既存の i18next や next-intl のセットアップはそのままで、このワークフローを導入できます。 Category: ワークフローツール Last updated: 2026-11-12 Authors: Jackie Chen Published: 2026-11-12 1 日に何度もデプロイするチームが継続的ローカライゼーションツールに求めるものは 2 つあります。1 つは、コピーを追加したそのリリースに翻訳が間に合うことです。これは、継続的インテグレーション (CI) の翻訳ステップをビルド前に完了させれば実現できます。もう 1 つは、新しいコピーを追加する際の開発者の負担がほぼゼロであることです。新しいコピーは週に何十件も発生するからです。現在では CI で翻訳できるツールがいくつもあるため、選定の決め手になるのはたいてい 2 つ目の要件、つまり新しい文字列が増えるたびに各ツールが開発者にどれだけの作業を求めるかです。キーやリソースファイルのエントリの追加から、同期ルールの設定、レビューまでがこれに含まれます。 ## 継続的ローカライゼーションツールの比較 | ツールと経路 | 起動のきっかけ | 翻訳の格納先 | 新しい文言を追加するデプロイに間に合うか | 開発者が新しい文言を提供する方法 | | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | -------------------------------------- | -------------------------------------------- | ------------------------------------------------------------------------------------------------ | | General Translation CLI | ビルド前の [`npx gt translate`](/docs/cli/reference/commands/translate) | ローカルファイル、または GT の CDN 上の公開済み翻訳 | はい。ビルドは翻訳の完了を待ちます | [``](/docs/react/reference/components/t) でラップした JSX (ネストした要素も含む、キー不要) 、または対応済みの既存カタログ | | General Translation の [Locadex](/kb/ai-coding-agent-vs-translation-pipeline#where-does-locadex-fit) | 設定したプルリクエスト、プッシュ、または手動トリガー | Locadex のプルリクエスト (Auto-merge は任意) | はい (デプロイ前にそのプルリクエストがマージされる場合) | 不要。**コードを生成** が新しい UI テキストをプルリクエスト内でラップします | | CI での [Crowdin CLI](https://crowdin.github.io/crowdin-cli/commands/crowdin-auto-translate) | 原文をアップロードし、設定した AI または機械翻訳で自動翻訳、ダウンロードしてからビルド | ビルドワークスペース内のファイル | はい (ジョブが AI または機械翻訳の完了を待って結果をダウンロードする場合) | リソースファイルとその `crowdin.yml` マッピング。抽出でエントリを自動化することも可能 | | [Crowdin GitHub連携](https://support.crowdin.com/github-integration/) | リポジトリの同期 (デフォルトは1時間ごと、スケジュールは変更可能) | `l10n_` サービスブランチからのプルリクエスト | 同期のプルリクエストがマージされるまでリリースを保留する場合のみ | マッピングされたリポジトリパス内のソースファイル | | [Lingo.dev](https://lingo.dev/en/docs/workflows) CLI または GitHub App | CI での `lingo push --wait`、または設定したリポジトリイベント | ビルドファイル、翻訳用プルリクエスト、または元の PR ブランチへのコミット | CI でははい。GitHub App の場合は、そのコミットがリリースに含まれていれば可 | ロケールファイル、または個別のキーを必要としない抽出済みの [React インライン呼び出し](https://lingo.dev/en/docs/react/i18n/quickstart) | | [Lokalise GitHub app](https://docs.lokalise.com/en/articles/1684090-github) | オンデマンドまたはプッシュ時のファイルインポート | エクスポートによるプルリクエスト | エクスポートのプルリクエストがマージされるまでリリースを保留する場合のみ | 原文のリソースファイルとインポート/エクスポート設定 | | [Phrase Strings Repo Sync](https://support.phrase.com/hc/en-us/articles/5784125562012-GitHub-Strings) | 監視対象ブランチからのインポート | Repo Sync のエクスポートによるプルリクエスト | エクスポートのプルリクエストがマージされるまでリリースを保留する場合のみ | リソースファイルと `.phrase.yml` マッピング | ファイルのやり取りを自動化していても、リポジトリ同期ではプロジェクト、ソースパス、エクスポートルール、リリース順序を設定し、アプリの成長に合わせて常に最新の状態に保つ必要があります。 翻訳会社が CAT (コンピューター支援翻訳) エディターで翻訳する場合や XLIFF ファイルをやり取りする場合、同じプラットフォーム上でプロの翻訳者による人手による翻訳を発注する場合、あるいはネイティブモバイルアプリでアプリストアのリリースを経ずに文字列を OTA (Over-the-Air) で更新したい場合は、Crowdin、Lokalise、Phrase などの翻訳管理システム (TMS) が適しています。言語ペアごとにモデルを選びたい場合は Lingo.dev が適しています。マークしたコンポーネント構造、共有の製品用語、翻訳生成、チームでのレビューをリリースと連携させたい場合は General Translation をお使いください。すでに next-intl や react-i18next を使用している場合は、ライブラリとレビュー済みの翻訳をそのまま活かしつつ、CLI で[それらのカタログを翻訳](/docs/cli/guides/generating-translations)できます。インライン JSX への移行は後からでも検討できます。 ## CI での翻訳に加えて、General Translation は何を提供するのか? 日々のコストを左右するのは、新しい文字列が増えるたびに発生する周辺作業です。General Translation は、まさにその部分で異なる設計を採用しています。 * **文字列単位ではなく、JSX ブロック全体を扱う。** 新しい文は、それをレンダリングするコンポーネント内で [``](/docs/react/reference/components/t) に囲まれた JSX として記述します。リンクやフォーマットもそのまま含められ、翻訳元のキーを作成する必要もありません。開発者はコンポーネントを編集するだけです。あとは CLI がコンテンツを抽出し、サービス経由で翻訳を生成して、SDK がレンダリングするロケール出力を更新します。 * **コードから文脈を取得。** CLI はマークされた JSX を、要素構造や `context` メモとともに 1 つの単位として送信します。そのため、ドキュメントのボタンの「Save」と料金バッジの「Save 20%」は、それぞれ異なる周辺情報付きで届きます。[コンテキストグループ](/docs/platform/dashboard/guides/defining-context-for-translations)(製品用語の用語集とトーンを指定するカスタムプロンプト)は、アプリ、ドキュメント、マーケティングの各プロジェクト間で共有できるため、すべてのプロジェクトで用語を統一できます。 * **新しい UI テキストのマーク付けを自動化。** Locadex の **コードを生成** 自動化は、ラップされていないユーザー向けテキストを検出し、それをラップするプルリクエストを作成します。これにより、パイプラインには常に翻訳対象が供給されます。 * **完了した翻訳を再利用。** 翻訳元のバージョンに変更がなければ、完了済みの翻訳がそのまま再利用されます。対応フォーマットでは、変更されたファイル内でも一致するコンテンツが再利用されます。作業が増えるのは、新しい言語を追加した場合や、意図的に再翻訳する場合です。セットアップについては [CI での翻訳ガイド](/kb/translations-in-ci) を参照してください。 * **シート料金なし。** 請求はリクエストした翻訳作業量に応じて発生し、Starter プランではユーザー数が無制限です。そのため、レビュー担当者やプロダクトマネージャーを追加しても費用は一切増えません。[料金比較](/kb/translation-pricing-without-seat-fees) では、Crowdin、Lokalise、Weblate について、シート料金、カタログ容量、翻訳使用量を項目ごとに分けて比較しています。 [Cursor は、Web サイトとドキュメントの 14 以上のロケールで General Translation を活用しています](https://generaltranslation.com/enterprise)。 ## GitHub Actions や Vercel でビルドのたびに実行するにはどうすればよいですか？ [CLI クイックスタート](/docs/cli/quickstart)でプロジェクトとローカルの翻訳ローダーを設定したら、ビルドコマンドに翻訳処理を組み込みます。Vercel の場合は、プロジェクトの **Build Command** を次のように設定します。 ```bash npx gt translate && next build ``` 次に、`GT_API_KEY` (**ファイル** を **書き込み**、**Translation queue** を有効、**Context** を **書き込み** に設定したプロジェクトキー) と `GT_PROJECT_ID` を環境変数として追加します。GitHub Actions では、キーをリポジトリのシークレットとして保存し、依存関係のインストール後に同じコマンドを実行します。翻訳に失敗した場合、ビルドは停止します。生成の前に [`npx gt validate`](/docs/cli/reference/commands/validate) を実行して、マーク済みのコンテンツをチェックしてください。マークされていないテキストは、各画面をテストして見つけてください。CDN 配信を利用する場合は、[翻訳ステップで公開を有効にしてください](/kb/build-time-vs-runtime-translation#how-does-general-translation-deliver-translations)。 プレビューブランチごとに個別の翻訳履歴が必要な場合は、[ブランチ追跡](/docs/cli/guides/branching) ([`npx gt translate --enable-branching`](/docs/cli/reference/commands/translate)) を使用してください。CLI は Vercel 上を含めてブランチを自動検出するため、並行する作業ごとにそれぞれ独自の翻訳を使用できます。 ## リリースを遅らせずに翻訳をチェックするには？ レビュー担当者は[ダッシュボード](/kb/review-translations)で翻訳を比較・編集します。リリースに欠かせない文言は、リリース前にレビューしてください。リリース後に手直しする文言については、保存した修正を次回のビルドにバンドルするか、[CDN に公開](/kb/build-time-vs-runtime-translation)します。CDN から翻訳を読み込むページでは、翻訳キャッシュとページキャッシュが更新された時点で修正が反映されます。エンタープライズの承認ワークフローでは、ロケールごとにレビュー担当者のグループを割り当て、期限やレビュー対象のブランチを指定できます。これにより、言語ごとに責任者を明確にできます。 ## 重要なポイント * ビルド前に翻訳を実行すれば、リリースを予定どおりに進められます。Crowdin の CLI、Lingo.dev、General Translation はいずれもこれに対応しています。一方、リポジトリ同期では翻訳がプルリクエストとして返ってくるため、デプロイ前にマージしなければなりません。 * 継続的なローカライゼーションにかかる日々のコストは、新しい文字列ごとに必要な作業量で決まります。General Translation なら、JSX を [``](/docs/react/reference/components/t) でラップするだけで済み、Locadex にラップを任せれば作業は不要です。さらに、コンテキストグループによってアプリとドキュメント全体で用語の一貫性を保てます。既存のカタログにも対応しているため、ライブラリを置き換えずに導入できます。 * CAT エディターを使った翻訳会社とのワークフロー、人手による翻訳の購入、ネイティブモバイルアプリでの OTA (over-the-air) アップデートが必要な場合は、Crowdin、Lokalise、Phrase が適しています。 * General Translation は従量課金制で、シート料金はかかりません。まずは [CLI クイックスタート](/docs/cli/quickstart) から始めましょう。 ## Related questions - [デプロイのたびに翻訳を最新の状態に保つにはどうすればよいですか？](https://generaltranslation.com/ja/kb/translations-in-ci.mdx): 本番環境のビルド前に、翻訳をパイプラインのステップとして毎回実行します。こうすることで、新しいテキストは追加されたデプロイと同時に翻訳済みの状態でリリースされます。General Translation の gt CLI では、CI シークレットとして保存したプロジェクトの APIキーとプロジェクトIDを使い、npx gt translate でこれを実現します。 - [AIコーディングエージェントと翻訳パイプライン：ローカライゼーションの自動化にはどちらを使うべきか](https://generaltranslation.com/ja/kb/ai-coding-agent-vs-translation-pipeline.mdx): 国際化のセットアップにはコーディングエージェントを、アプリの変更に合わせてすべての言語を最新の状態に保つには翻訳パイプラインを使いましょう。General Translation は新規および変更されたテキストを翻訳し、完了した翻訳を再利用するとともに、チームで共有できる用語管理とダッシュボードでのレビュー機能を提供します。Locadex は、コードの変更と翻訳をプルリクエストとして用意することで、この2種類の作業を結び付けます。 - [ビルド時、実行時、翻訳プロキシ：翻訳はどう配信すべきか？](https://generaltranslation.com/ja/kb/build-time-vs-runtime-translation.mdx): General Translation を使えば、リリース前にアプリの既知の翻訳を生成し、コードにバンドルするか CDN から読み込めます。バンドルでは文言がリリースに紐づきますが、CDN 上で公開した修正はコードをデプロイしなくても新たなレンダリングに反映されます。訪問者がすぐに必要とするコンテンツにはリクエスト時の翻訳を、サイトのコードを変更できない場合はプロキシを使いましょう。 - [General Translation と TMS（Crowdin、Lokalise、Phrase）の比較](https://generaltranslation.com/ja/kb/general-translation-vs-tms.mdx): 翻訳の生成、コードから導出した文脈、レビューをプロダクトのリリースと連動させたい開発チームには General Translation が適しています。既存のカタログとレンダリングライブラリをそのまま使うことも、翻訳キーを使わずにインライン JSX を記述することもできます。TMS は、言語ベンダー、CAT エディター、XLIFF でのやり取りを中心とした翻訳プログラムに適しており、そのインテグレーションを使えばファイル転送を自動化できます。 - [シート数ではなく使用量に応じて課金する翻訳ツールはどれですか？](https://generaltranslation.com/ja/kb/translation-pricing-without-seat-fees.mdx): 翻訳コストを依頼した作業量に連動させたい場合は、ユーザー数無制限で Starter のプラットフォーム利用料が $0 の General Translation を選びましょう。Crowdin と Lokalise は有料プランで翻訳関連のロールを無制限に利用できますが、それ以外の一部のロールは課金対象です。Hosted Weblate は翻訳者を無制限に追加でき、ホストする文字列の容量に応じて課金されます。 ## Previous and next questions - Previous question: [ビルド時、実行時、翻訳プロキシ：翻訳はどう配信すべきか？](https://generaltranslation.com/ja/kb/build-time-vs-runtime-translation.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/ja/kb/sitemap.md) for every article.