# General Translation Knowledge Base: General Translation と Locize：どちらを使うべきか？
URL: https://generaltranslation.com/ja/kb/general-translation-vs-locize.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: Locize は i18next の開発者が手がける翻訳管理システムで、CDN から翻訳を配信し、稼働中のアプリから新しいキーを収集できるほか、AI 翻訳やインコンテキストエディターも備えています。ただし、i18nライブラリとそのキーは引き続き自分たちで管理する必要があります。General Translation は、i18nライブラリそのものとして翻訳まで担うことも、既存の i18next ファイルを翻訳することもできます。
Category: ワークフローツール
Last updated: 2026-10-16
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-16

Locize は、i18next の開発チームが構築した翻訳管理システム (TMS) です。アプリでは引き続き i18next (または別の i18nライブラリ) を使い、キーとその翻訳は Locize に保存されます。各言語の翻訳は AI や翻訳者が埋め、アプリは Locize の CDN から結果を読み込むため、翻訳を修正すれば再デプロイなしで反映されます。Locize は i18nライブラリを置き換えるものではなく、組み合わせて使うものです。そのため、ライブラリのセットアップやキー、連携部分の管理は引き続きエンジニアが担うことになります。一方、General Translation はその両方を担えます。独自のオープンソース i18nライブラリと翻訳をまとめて提供することも、既存の i18next ファイルの翻訳だけを任せることも可能です。

## Locize の強み

* **i18next 向けに設計。** [`i18next-locize-backend`](https://github.com/locize/i18next-locize-backend) は Locize の CDN から翻訳を読み込みます。i18next の `saveMissing` オプションを有効にすれば、開発中に追加した新しいキーが Locize へ送信されます。[`i18next-cli`](https://github.com/i18next/i18next-cli) には Locize 用の同期・ダウンロード・移行コマンドが含まれています。さらに `localize` コマンドを使えば、ハードコードされた文字列の `t()` によるラップ、キーの抽出、Locize プロジェクトへの接続、AI 翻訳のリクエストを 1 回の実行でまとめて行えます。
* **再デプロイなしで更新可能。** 翻訳は CDN に公開されます (Standard CDN は全プランで、Pro CDN は Growth プラン以上で利用可能) 。[キャッシュ期間はバージョンごとに設定](https://www.locize.com/docs/integration/cdn-types-standard-vs-pro)でき、API キーを持つ場合のみアクセスできる非公開での公開も選択できます。
* **バージョン管理。** プロジェクトには作業用の `latest` バージョンと `production` バージョンがあり、`staging` やモバイルアプリのリリースごとのバージョンなど、任意のカスタムバージョンも作成できます。これにより、コードとは切り離して翻訳を昇格・ロールバックできます。 ([Locize のバージョニング](https://www.locize.com/docs/versioning)を参照してください。) 
* **インコンテキスト編集。** [`locize` パッケージ](https://github.com/locize/locize)を導入すると、URL に `?incontext=true` が含まれる場合にサイト上にエディターのポップアップが表示されます。スクリーンショットは文字認識によってキーと自動で紐付けられます。
* **AI 翻訳と機械翻訳。** [Locize 独自の AI サービス](https://www.locize.com/ai)のほか、手持ちの OpenAI、Gemini、Mistral、DeepL の API キーも利用でき、スタイルガイド・用語集・翻訳メモリに沿って翻訳します。品質推定、AI レビュー、人手によるレビューのワークフローも備えています。
* **言語ごとの複数形キー。** i18next JSON の場合、Locize は対象言語ごとに必要な[複数形キーを生成](https://www.locize.com/docs/integration/i18n-formats/pluralization)し (ポーランド語の `_few` や `_many` など) 、エディター上ですべての形を表示します。
* **i18next 以外にも対応。** [`locize-cli`](https://github.com/locize/locize-cli) は XLIFF、Android XML、Apple `.strings`、PO、RESX、Fluent、Java properties などの形式のインポート・エクスポートに対応しています。また、Locize は react-intl、vue-i18n、Lingui 向けのサンプルも公開しています。このほか、GitHub Action、MCP サーバー、Figma プラグインも用意されています。

## Locize を導入してもエンジニアの手に残る作業

以下は、`i18next` 26.4.7 と `i18next-locize-backend` 10.0.3 で `saveMissing` を有効にし、Locize にまだ登録されていないキーをスペイン語でレンダリングする例です。request 関数は Locize のサーバーの代わりに動作し、呼び出しのたびにログを出力します：

```js title="test.mjs"
import i18next from 'i18next';
import Backend from 'i18next-locize-backend';

// 疑似CDN: 現時点では英語・スペイン語ともにキーは1つだけ
const cdn = {
  en: { inbox: { title: 'Inbox' } },
  es: { inbox: { title: 'Bandeja de entrada' } },
};

await i18next.use(Backend).init({
  lng: 'es',
  fallbackLng: 'en',
  saveMissing: true,
  backend: {
    projectId: 'demo-project',
    apiKey: 'demo-write-key', // 書き込みキー: 開発環境専用
    referenceLng: 'en',
    allowedAddOrUpdateHosts: () => true,
    reloadInterval: false,
    request: async ({ url, method, body }) => {
      console.log(method, url, body ? JSON.stringify(body) : '');
      const lng = url.match(/latest\/(\w+)\//)?.[1];
      return { status: 200, data: JSON.stringify(method === 'GET' ? cdn[lng] ?? {} : {}) };
    },
  },
});

// コードで追加した新しい文言（英語のデフォルト値付き）
console.log(i18next.t('inbox.title'));
console.log(i18next.t('inbox.empty', 'No messages yet.'));
await new Promise((r) => setTimeout(r, 6000)); // saveMissing はデバウンスされます
```

```text title="Output"
GET https://api.lite.locize.app/demo-project/latest/es/translation
GET https://api.lite.locize.app/demo-project/latest/en/translation
Bandeja de entrada
No messages yet.
POST https://api.lite.locize.app/missing/demo-project/latest/en/translation {"inbox.empty":"No messages yet."}
```

この例は、`saveMissing` が登録する内容、つまり英語のキーと値を示しています。翻訳と公開は登録の後に行われます。Locize のインテグレーションでは、これらのステップを次のようにつなぎます。

1. i18next をセットアップし、文字列ごとにキーを命名して、そのキーで `t()` を呼び出します。
2. 新しいキーを Locize に送信します。開発中は `saveMissing` を使い (デフォルトでは `localhost` に限定されています。また、[書き込みキーは決して本番に含めてはいけません](https://www.locize.com/docs/guides/going-to-production)) 、CI では同期コマンドを使います。
3. AI または翻訳者が翻訳し、結果をレビューしたうえで、アプリが読み込むバージョンに公開します。
4. 実行時に CDN から翻訳を読み込むか、ビルド時にダウンロードして組み込みます。また、新しい言語を追加するたびにアプリに登録します。

翻訳者や AI に届く文脈は、キー、その英語の値、文脈メモ、そして[キーに紐づけられたスクリーンショット](https://www.locize.com/docs/context)です。文字列をレンダリングするコンポーネントは含まれません。

Locize のプランは月額の基本料金制で、単語数、CDN ダウンロード数、言語数、名前空間数、バージョン数が含まれます。上位プランでは単語数とダウンロード数を追加ブロックで購入でき、AI 翻訳と機械翻訳はトークン単位または文字単位で課金されます ([Locize の料金](https://www.locize.com/pricing)を参照。2026 年 10 月時点の情報) 。

## i18next を利用しているチーム向けの General Translation

General Translation を試すのに、既存のコードを書き直す必要はありません。CLI は `package.json` 内の `i18next` を検出し、i18next の補間構文 (`i18next-icu` を使用している場合は ICU 構文) をそのまま維持して JSON ファイルを翻訳します。

```json title="gt.config.json"
{
  "defaultLocale": "en",
  "locales": [
    "es"
  ],
  "files": {
    "json": {
      "include": [
        "locales/[locale]/*.json"
      ]
    }
  }
}
```

[`npx gt translate --dry-run`](/docs/cli/reference/commands/translate) は `locales/en/translation.json` を検出し、[`npx gt translate`](/docs/cli/reference/commands/translate) は `locales/es/translation.json` を書き出します。翻訳元とターゲットでキー構造が一致するメッセージには、このファイルベースのワークフローを使用してください。補助メタデータファイルを使えば、任意のキーに `context` のメモや `maxChars` の上限を付与できます。詳しくは[キーごとのメタデータ](/docs/cli/reference/keyed-metadata)を参照してください。

さらに一歩進めて、ライブラリにも General Translation を使うこともできます。[`<T>`](/docs/react/reference/components/t) は JSX をラップしてインプレースで翻訳し、[`useGT`](/docs/react/reference/hooks/use-gt) は文字列を翻訳するため、キーの名前を考える必要はありません。キー付きの辞書を使いたいチームには、[`useTranslations`](/docs/react/reference/hooks/use-translations) も用意されています。`gt-next`、`gt-react`、`gt-vue` は MIT ライセンスで、内部で i18next に依存しておらず、General Translation のアカウントがなくても動作します。

## Locize と General Translation の比較概要

| 機能           | Locize                                             | General Translation                                                                                                          |
| ------------ | -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| 概要           | i18next などのi18nライブラリと組み合わせて使う TMS                  | オープンソースのi18nライブラリと AI 翻訳の組み合わせ、または既存ファイルの翻訳                                                                                  |
| 文字列の保存場所     | キーはコード内、値は Locize 上                                | コード内の [`<T>`](/docs/react/reference/components/t) の中、または既存のリソースファイル内                                                         |
| 新しい文言の取り込み方法 | 開発中の `saveMissing`、または CI での同期コマンド                 | ビルド時の [`npx gt translate`](/docs/cli/reference/commands/translate)、または [Locadex](/docs/platform/locadex/quickstart) のプルリクエスト |
| 翻訳の担い手       | Locize の AI、自前の AI・機械翻訳の API キー、または自社の翻訳者          | コード、用語集、カスタムプロンプトの文脈を活用する AI (ダッシュボード上でチームがレビュー)                                                                             |
| 各文字列の文脈      | キー、英語の値、文脈メモ、スクリーンショット、用語集、スタイルガイド                 | インラインライブラリではマークされた JSX 構造、カタログではキーごとのメタデータ、加えて共通の用語集とカスタムプロンプト                                                               |
| 配信           | デフォルトはバージョン管理付きの CDN、またはビルドにダウンロード                 | バンドルされたファイル、または General Translation の CDN 経由で公開する更新 (アプリの再デプロイ不要)                                                            |
| 料金           | 単語数、CDN ダウンロード数、言語数、バージョン数に応じたプラン制。AI 翻訳と機械翻訳は追加購入 | [従量課金制の翻訳](https://generaltranslation.com/pricing)                                                                           |

## チームが Locize ではなく General Translation を選ぶ理由

General Translation なら、i18next を使うチームはまず翻訳生成とダッシュボードでのレビューから導入し、キーの管理もなくしたくなった段階でインラインのテキストへ移行できます。

* **より速く。** ビルド前に翻訳を実行すれば、新しいテキストをサポート対象のすべての言語でリリースできます。CLI は既存の翻訳を再利用し、新規または変更されたコンテンツだけを翻訳します。言語の追加も `gt.config.json` に 1 行加えるだけです。
* **運用コストを抑える。** すでに管理している i18next ファイルをそのまま使って始められます。さらに機能を [`<T>`](/docs/react/reference/components/t) に移行すれば、キーの命名や、翻訳元の辞書をコンポーネントと同期させ続ける手間がなくなります。
* **より高い品質。** カタログのキーに文脈メモを追加したり、インラインの [`<T>`](/docs/react/reference/components/t) ブロックで文の JSX 構造や複数形の分岐を翻訳に渡したりできます。共有の[コンテキストグループ](/docs/platform/dashboard/guides/defining-context-for-translations)を使えば、アプリとドキュメントのプロジェクト間で製品用語を統一でき、レビュアーはダッシュボード上で翻訳結果を編集できます。
* **リスクを抑える。** General Translation を評価している間も、i18next とレビュー済みの翻訳はそのまま使い続けられます。バンドルされた翻訳ファイルは、ランタイムに General Translation を呼び出すことはありません。また、MIT ライセンスの JavaScript ライブラリは、翻訳を自前で用意すればアカウントなしでも動作します。

Cursor は General Translation を使って、Web とドキュメントで 14 以上のロケールを提供しています。 ([本番環境での導入事例](https://generaltranslation.com/enterprise)をご覧ください。)

## Locize のほうが適しているケース

翻訳者が本番サイト上で直接編集したい場合、モバイルアプリのリリースごとに翻訳バージョンを分けて管理したい場合、あるいは XLIFF、Fluent、Java properties ファイルをやり取りする場合は、Locize を選びましょう。コンポーネント内に読みやすい翻訳元テキストを記述し、マークアップした JSX 構造も含めて翻訳したい場合は、General Translation のインラインライブラリが適しています。ライブラリを切り替える前に翻訳やダッシュボードでのレビューを評価したい場合は、既存のカタログのまま General Translation の CLI を試してみてください。

## LocizeからGeneral Translationへの移行

`locize-cli`で現在の翻訳をダウンロードしてリポジトリに保存し、`gt.config.json`で英語のファイルを指定したうえで[`npx gt upload`](/docs/cli/reference/commands/upload)を実行すると、翻訳元と既存の翻訳がプラットフォームにアップロードされます。その後は、i18nextを使い続けながら新しいキーの翻訳をCLIに任せることも、機能単位で[`<T>`](/docs/react/reference/components/t)へ段階的に移行することもできます ([i18nライブラリの移行](/docs/react/guides/migrating-i18n-libraries)を参照) 。用語集の用語も引き継げます。コンテキストグループのインポートは、CSV、TSV、JSON、テキストファイルに対応しています。

## 重要なポイント

* Locize は i18next の開発元が手がける、i18next アプリ向けの強力な TMS です。CDN 配信、`saveMissing`、バージョン管理、インコンテキスト編集、AI 翻訳を備えています。
* Locize は i18nライブラリおよびそのキーベースのカタログと組み合わせて使います。翻訳、レビュー、公開は、これらのカタログを軸に設定します。
* General Translation は、既存の i18next ファイルを翻訳することも、i18nライブラリと翻訳の両方を一手に担うこともできます。コードの文脈を踏まえて翻訳し、リリースのたびにすべての言語を揃えて提供します。

## Related questions

- [General Translation vs. i18next、react-intl、next-intl：どのi18nライブラリを使うべきか？](https://generaltranslation.com/ja/kb/general-translation-vs-i18n-libraries.mdx): i18next、react-intl、next-intlなどのオープンソースライブラリ自体は、翻訳を一切行いません。これらが行うのは、あなた自身や翻訳者、あるいは別のサービスが作成し、言語ごとのカタログファイルに用意した翻訳を表示することだけです。General Translationのライブラリも同じくオープンソースで同じ役割を果たしますが、General Translationはさらに、コードを文脈として活用しながら翻訳そのものも行います。
- [TMS（Smartling、Lokalise、Phrase、Crowdin、Transifex）ではなく General Translation を使う理由](https://generaltranslation.com/ja/kb/general-translation-vs-tms.mdx): Smartling、Lokalise、Phrase、Crowdin、Transifex などの翻訳管理システム（TMS）は翻訳者間の作業を取りまとめますが、文字列の抽出、送信、翻訳待ち、プロダクトへの再組み込みは依然としてエンジニアの仕事です。General Translation はコード内のコンテンツを文脈ごと翻訳し、リリースのたびに全言語をまとめて提供します。ロックインのないオープンソースのライブラリ上で動作します。
- [General Translation と Tolgee の比較：どちらを使うべきか？](https://generaltranslation.com/ja/kb/general-translation-vs-tolgee.mdx): Tolgee は、キーベースのメッセージ、インコンテキスト編集、AI 翻訳を、セルフホスト可能な 1 つのプラットフォームで提供します。General Translation は読みやすい文言をコンポーネント内に直接記述し、マークされた JSX から翻訳を生成します。そのため、メッセージキーを管理しなくても、新しい文言をすべての言語でリリースできます。
- [General Translation と Weblate の比較：どちらを使うべきか](https://generaltranslation.com/ja/kb/general-translation-vs-weblate.mdx): Weblate は、コミュニティやチームでリポジトリ内のファイルを翻訳するために作られた、セルフホスト可能な Git ベースのローカライゼーションプラットフォームです。General Translation は、マークされた JSX と共有されたプロダクトの文脈を用いて、翻訳の生成を開発とリリースに組み込みます。既存の gettext ファイルをそのまま使い続けることも、インライン記述を導入して翻訳元カタログの保守そのものをなくすこともできます。
- [翻訳ファイルなしで i18n はできますか？](https://generaltranslation.com/ja/kb/i18n-without-translation-files.mdx): はい。gt-react または gt-next を使えば、コンテンツは `<T>` コンポーネントで囲んだままコンポーネント内にインラインで記述でき、翻訳はビルド時に出力として生成されます。そのため、キーやロケールごとの JSON ファイルを作成したり、同期を保ったりする必要はありません。

## Previous and next questions

- Previous question: [General Translation と Lingui：どちらを使うべきか？](https://generaltranslation.com/ja/kb/general-translation-vs-lingui.mdx)
- Next question: [General Translation と Mobility：どちらを使うべきか？](https://generaltranslation.com/ja/kb/general-translation-vs-mobility.mdx)

## Sitemap

See the [Knowledge Base sitemap](https://generaltranslation.com/ja/kb/sitemap.md) for every article.