# General Translation Knowledge Base: PhraseからGeneral Translationに移行するには？ URL: https://generaltranslation.com/ja/kb/migrate-from-phrase.mdx Docs index: https://generaltranslation.com/llms.txt Description: ロケールファイル、i18nライブラリ、検証済みの翻訳はそのまま引き継げます。未翻訳のキーやフォールバックを含めずにPhrase Stringsからプルし、Repo Syncを無効化したうえで、最初のnpx gt translateを実行する前にnpx gt uploadでファイルをインポートします。以降はGeneral Translationがビルド時に新規・変更された文字列を翻訳します。用語ベースはコンテキストグループとして、キーの説明はキーごとの文脈として活用されます。 Category: ワークフローツール Last updated: 2026-11-12 Authors: Kevin Wu Published: 2026-11-12 Phraseのソフトウェアローカライゼーション製品であるPhrase Stringsは、文字列をプロジェクト内のキーとして保存し、ダウンロード時にロケールファイルを生成してリポジトリと同期します。General Translationに移行しても、アプリがすでに読み込んでいるロケールファイルはそのまま使えます。`gt` CLIが既存の翻訳ごとロケールファイルをインポートし、以降はビルドやCIの中で新規・変更された文字列を翻訳します。i18nライブラリやキーを変更する必要はありません。テキストをインラインに移すかどうかは別の任意の手順です ([react-i18nextからの移行](/kb/migrate-from-react-i18next)または[next-intlからの移行](/kb/migrate-from-next-intl)を参照) 。用語ベースはコンテキストグループとなり、アプリやドキュメント、その他のプロジェクトで共有できます。このガイドはPhrase Stringsを対象としています。Phrase TMSで翻訳するドキュメントの場合は、別のワークフローになります。 ## Phrase Strings から引き継げるもの | Phrase Strings | General Translation | | ------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | `.phrase.yml` の pull ターゲット | `gt.config.json` の `files`。`` の代わりに `[locale]` を使用 | | 翻訳 | [`npx gt upload`](/docs/cli/reference/commands/upload) でインポートし、翻訳元が変更されるまで保持 | | 用語ベース | CSV からインポートした [コンテキストグループ](/docs/platform/dashboard/guides/defining-context-for-translations) の用語集 | | スタイルガイド | グローバルまたはロケールごとの [カスタムプロンプト](/docs/platform/dashboard/guides/defining-context-for-translations) | | キーの説明と文字数制限 | キーごとに `context` と `maxChars` を指定する [キーごとのメタデータ](/docs/cli/reference/keyed-metadata) ファイル (JSON および YAML に対応) | | 翻訳メモリ | アップロードした翻訳。変更のない文字列は既存の翻訳がそのまま使われ、新規または変更された文字列のみが翻訳されます。TMX ファイルはインポートできません | | Repo Sync | CI での [`npx gt translate`](/docs/cli/reference/commands/translate) の実行、または [Locadex](/docs/platform/locadex/quickstart) によるプルリクエスト | | 翻訳の検証とレビュー | [ダッシュボード](/docs/platform/dashboard/guides/reviewing-translations) での編集 (エンタープライズプランでは承認も可能) | | iOS、Android、React Native、Flutter、i18next、Rails 向けの Over-the-air (OTA) SDK | 翻訳はロケールファイルに含まれ、アプリのリリースごとに配信 | CLI は JSON、YAML、`.pot` と `.po`、iOS の `.strings`、`.stringsdict`、`.xcstrings`、Android の `strings.xml`、`.resx`、HTML、Markdown と MDX などに対応しています ([対応フォーマット](/docs/cli/reference/config#files)を参照) 。XLIFF、ARB、Java の `.properties`、CSV や XLSX のエクスポートには対応していないため、pull する際は対応しているフォーマットを選択してください。 ## ステップ 1: ロケールごとに 1 つのファイルをプルする Phrase は、ダウンロードのたびにキーからファイルを生成します。Phrase で同期したファイルがすでにリポジトリにある場合は、出力が一致するよう同じ `.phrase.yml` のターゲットを使ってプルし、インポートする前にリポジトリとの差分を確認してください。 JSON アプリのプルターゲットは次のとおりです。 ```yaml title=".phrase.yml" phrase: project_id: "YOUR_PROJECT_ID" file_format: nested_json pull: targets: - file: ./locales//app.json params: file_format: nested_json include_empty_translations: false ``` 次に、`read` スコープを持つアクセストークンを使って [`phrase pull`](https://developers.phrase.com/en/developer-tools/strings-cli) を実行します。メインブランチから取得する場合は、`--branch` を指定しないでください。アカウントが Phrase の US データセンターにある場合は、`.phrase.yml` の `phrase:` の下に `host: https://api.us.app.phrase.com/v2` を追加します。 問題なくインポートするために、次の 3 つの設定に注意してください。 * **未翻訳のキー。** CLI のデフォルト設定である `include_empty_translations: false` では、未翻訳のキーは出力されません。`fallback_locale_id` や `use_locale_fallback` は設定せず、プロジェクト設定の **Use fallback for unverified translations** がオフになっていることも確認してください。これらはいずれも未翻訳の箇所を別のロケールのテキストで補完するため、そのテキストが翻訳としてインポートされてしまいます。 * **ファイル形式。** ライブラリが現在読み込んでいる形式を使用します。具体的には、`nested_json` または `simple_json`、i18next では `i18next_4`、Rails では `yml`、iOS では `strings` と `stringsdict`、`.xcstrings` では `strings_catalog`、Android では `xml` です。Phrase の `json` 形式は Chrome 拡張機能用の JSON であり、汎用的な JSON ではありません (Phrase の[対応ファイル形式](https://support.phrase.com/hc/en-us/articles/9652464547740)を参照してください) 。 * **ロケール名。** `` は、Phrase で各ロケールに付けた名前 (`de-AT` など) に展開されます。`gt` CLI はフォルダー名を `locales` リストと完全一致で照合します。そのため、Phrase 側でロケール名を変更するか、`.phrase.yml` の `phrase:` の下で `locale_mapping` を使ってマッピングする (Phrase CLI 2.59.0 以降) か、取得したままの名前を `gt.config.json` に記載してください。 CLI を使わない場合は、プロジェクトの **Languages** タブを開いて **Download** をクリックすると、複数のロケールをまとめてダウンロードできます。その際、**Include empty translations** のチェックは外したままにしてください。 ## ステップ 2: Repo Sync と OTA を無効化する Phrase の [Repo Sync](https://support.phrase.com/hc/en-us/articles/5784125562012-GitHub-Strings) は **Automations > Repo Syncs** で設定する機能で、プッシュ時のインポートと、翻訳のプルリクエストとしてのエクスポート (デフォルトでは `phrase-translations` ブランチから) を行えます。General Translation がファイルを書き込む前に、各同期を無効化してインポートとエクスポートを停止し、オープン中の Phrase のプルリクエストをすべてクローズしたうえで、CI から `phrase push` と `phrase pull` のステップを削除してください。2 つのツールが同じファイルに書き込むと、最後に書き込んだほうの内容が優先されます。 モバイルアプリで Phrase OTA を使用している場合、インストール済みのアプリには引き続き新しい OTA リリースが配信されます。更新の配信を止めるには、リリースの作成をやめるか、ディストリビューションを削除してください。SDK は今後のアプリのリリースで削除します。 ## ステップ 3：CLI の対象ファイルを指定する `gt` CLI をインストールし、取得したファイルの情報を `gt.config.json` に記述します。 ```json title="gt.config.json" { "defaultLocale": "en", "locales": ["de", "fr", "pt-BR"], "files": { "json": { "include": ["locales/[locale]/app.json"] } } } ``` CLI は、`package.json` に `i18next` または `next-intl` が含まれている場合、JSON 内の i18next および next-intl のメッセージ構文を読み取り、それ以外の JSON の値はプレーンな文字列として扱います。 ([JSON ファイル](/docs/cli/reference/formats/json-files)を参照してください。) [`npx gt login`](/docs/cli/reference/commands/login) でサインインして `GT_PROJECT_ID` を設定するか、設定ファイルで `projectId` を指定します。CI では、**ファイル > 書き込み**、**翻訳キュー > 有効**、**文脈 > 書き込み** の権限を持つプロジェクトの APIキーを `GT_API_KEY` に設定してください。 ## ステップ 4: 用語ベースとキーの文脈を移行する Phrase Strings で **Term bases** を開き、**More > Download CSV** を選択します。出力するフィールドを選んで **Download** をクリックしてください。このファイルには `term`、`case_sensitive`、`translatable`、`description` の各列と、ロケールごとの列が含まれます ([Uploading and downloading terms](https://support.phrase.com/hc/en-us/articles/10112307427740) を参照) 。`description` を `definition` に、`de` などの各ロケール列を `translation_de` の形式にリネームし、`case_sensitive` 列と `translatable` 列を削除します。General Translation のインポーターはこのレイアウトをそのまま読み込めます。それ以外のレイアウトは AI が解釈します。ダッシュボードで [コンテキストグループ](/docs/platform/dashboard/guides/defining-context-for-translations) を作成し、**Import** をクリックしてファイルを選択します。最初の翻訳を実行する前に、そのグループをプロジェクトに割り当ててください。こうしておけば、新しい翻訳に最初から自社の用語が反映されます。 キーの説明と文字数制限によって、翻訳者は文字列の意味と許容される長さを把握できます。ソースロケール用に `file_format: strings_json` を指定した 2 つ目の pull ターゲットを追加し、出力先は `gt.config.json` で指定したフォルダの外にします (例: `./phrase-export/app.strings.json`) 。このファイルには各キーの `description` と `max_characters_allowed` が含まれています。これらを、ソースファイルと同じ場所にある [キーごとのメタデータ](/docs/cli/reference/keyed-metadata) ファイルに書き出します: ```json title="locales/en/app.metadata.json" { "checkout": { "save": { "context": "Button that saves the shipping address", "maxChars": 12 } } } ``` スタイルガイドは[カスタムプロンプト](/docs/platform/dashboard/guides/defining-context-for-translations)として作り直してください。翻訳メモリをアーカイブとして残しておく場合は、プロジェクトから各言語を TMX 形式でダウンロードしてください。 ## ステップ 5: 翻訳の前にアップロードする まず [`npx gt upload`](/docs/cli/reference/commands/upload) を実行します。このコマンドは、各ソースファイルと、それに対応する各ロケールの翻訳済みファイルを送信し、それらの翻訳を完了済みとして保存します： ```bash npx gt upload npx gt translate ``` その後、[`npx gt translate`](/docs/cli/reference/commands/translate) は、新しいロケールや翻訳のないファイルなど、不足している部分だけを翻訳し、結果を同じパスに書き込みます。[`npx gt upload`](/docs/cli/reference/commands/upload) より先に [`npx gt translate`](/docs/cli/reference/commands/translate) を実行すると、新しい翻訳が生成され、取得したファイルが上書きされてしまいます。Phrase で未翻訳のまま残っていたキーは、次にそのソースファイルが変更されたタイミングで General Translation が翻訳します。それより早くリリースしたい場合は、取得する前に Phrase で翻訳を済ませておいてください。 ## ステップ 6: 新しいテキストを自動で翻訳する 今後は、[ビルドまたは CI](/kb/translations-in-ci) で [`npx gt translate`](/docs/cli/reference/commands/translate) を実行するか、[Locadex](/docs/platform/locadex/quickstart) に翻訳を含むプルリクエストを作成させます。`gt-lock.json` もコミットしてください。このファイルには CLI が書き込み済みの翻訳が記録されるため、同じ翻訳を再度ダウンロードせずに済みます。チームでリポジトリ内の翻訳済みファイルを編集している場合は、次回の翻訳の前に [`npx gt save-local`](/docs/cli/reference/commands/save-local) を実行して、編集内容が失われないようにしてください。 ## Phrase を使い続けるべきなのはどのような場合ですか？ ソフトウェアの文字列と Phrase TMS でのドキュメント翻訳プログラムの両方を 1 つのプラットフォームで扱う必要がある場合、ネイティブモバイルアプリが OTA アップデートに依存している場合、Phrase 経由で人手による翻訳を発注している場合、あるいはパイプラインで XLIFF や ARB ファイルをやり取りしている場合は、Phrase を使い続けることをおすすめします。 ([General Translation と Phrase の比較](/kb/general-translation-vs-phrase)を参照してください。) ## よくある質問 ### 検証済みの翻訳は失われますか？ いいえ。フォールバックなしでプルし、[`npx gt translate`](/docs/cli/reference/commands/translate) の前に [`npx gt upload`](/docs/cli/reference/commands/upload) を実行すれば失われません。アップロードした翻訳は、原文が変更されるまでそのまま保持されます。また、チームは[ダッシュボード](/docs/platform/dashboard/guides/reviewing-translations)でどの翻訳でも修正できます。 ## 重要なポイント * `include_empty_translations: false` を指定し、代替ロケールは設定せずに、アプリが現在読み込んでいる形式でロケールごとに 1 つずつファイルを取得します。 * General Translation が同じファイルに書き込む前に、Repo Sync と OTA を無効にしておきます。 * 翻訳を始める前に、Phrase のロケール名を `gt.config.json` の `locales` に合わせ、用語ベースを コンテキストグループ にインポートし、キーの説明と文字数制限をキーごとの文脈として移行します。 * 最初に [`npx gt translate`](/docs/cli/reference/commands/translate) を実行する前に [`npx gt upload`](/docs/cli/reference/commands/upload) を実行し、以降はビルド時または Locadex で新しいテキストを翻訳します。 ## Related questions - [Phrase の代替ツール：General Translation と Phrase の比較](https://generaltranslation.com/ja/kb/general-translation-vs-phrase.mdx): アプリとドキュメントを同時にリリースするなら、General Translation は Phrase Strings の有力な代替となります。コードやコンテンツファイルから翻訳を生成し、共通の用語を適用したうえで、リリースワークフローの中で動作します。一方 Phrase は、ソフトウェアのローカライゼーションに加え、ドキュメント中心の TMS、ベンダー管理、幅広い翻訳エンジンの選択肢を備えています。 - [Lokalise から General Translation へ移行するには？](https://generaltranslation.com/ja/kb/migrate-from-lokalise.mdx): リソースファイル、i18nライブラリ、レビュー済みの翻訳はそのまま使えます。空の翻訳を除外して Lokalise からエクスポートし、Lokalise の GitHub 同期を無効にしたうえで、最初の npx gt translate を実行する前に npx gt upload でファイルをインポートします。以降は General Translation がビルド時に新規・変更された文字列を翻訳します。用語集は コンテキストグループ に、キーの説明はキーごとの文脈として引き継がれます。 - [CrowdinからGeneral Translationに移行するにはどうすればよいですか？](https://generaltranslation.com/ja/kb/migrate-from-crowdin.mdx): リソースファイル、i18nライブラリ、レビュー済みの翻訳はそのまま引き継げます。「Skip untranslated strings」を有効にして翻訳をダウンロードし、CrowdinのGitインテグレーションによる翻訳のプッシュを止めたうえで、最初に npx gt translate を実行する前に npx gt upload でファイルをインポートします。以降はGeneral Translationがビルド時に新規・変更された文字列を翻訳し、その際にはコンテキストグループの用語集が適用されます。 - [デプロイのたびに翻訳を最新の状態に保つにはどうすればよいですか？](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/what-is-translation-memory.mdx): 翻訳メモリ（TM）は、過去の翻訳元と訳文のセグメントのペアを蓄積したデータベースで、翻訳ツールはこれを検索して完全一致、文脈一致、ファジーマッチを見つけます。AIを使う場合でも、承認済みの訳語を再利用し、過去の翻訳を文脈として参照できるようにしておくことは重要です。General Translation は、ファイルの以前のバージョンからマッチする翻訳を再利用し、チームによる編集も保持するため、TM を別途管理する必要はありません。 ## Previous and next questions - Previous question: [Lokalise から General Translation へ移行するには？](https://generaltranslation.com/ja/kb/migrate-from-lokalise.mdx) - Next 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.