# General Translation Knowledge Base: General Translation と SimpleLocalize の比較：どちらを選ぶべきか？
URL: https://generaltranslation.com/ja/kb/general-translation-vs-simplelocalize.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: UI の文言と翻訳の文脈をコンポーネント内で管理し、変更されたメッセージをビルド前に生成し、シート料金なしで文言をレビューしたいなら General Translation がおすすめです。既存の i18next や next-intl のカタログをそのまま使い続けることもできます。SimpleLocalize は、ページ上での編集、顧客ごとの文言、ネイティブモバイル向けの OTA（Over-the-Air）アップデートに対応したキーベースの翻訳エディターを求めるチームに向いています。
Category: ワークフローツール
Last updated: 2026-11-13
Authors: Jackie Chen
Published: 2026-11-13

SimpleLocalize は、ソフトウェアチーム向けのホスト型翻訳管理システムです。アプリでは i18next や react-intl などの既存の i18n ライブラリをそのまま使い、そのライブラリが読み込むカタログを SimpleLocalize が管理します。ロケールファイルからキーをアップロードし、Web エディター上で機械翻訳や AI、あるいはチームの手で翻訳したうえで、結果をダウンロードするか CDN から配信する仕組みです。ファイルのやり取りは CLI と GitHub App で自動化できます。一方、General Translation はコードを起点とします。文言はコンポーネント内に置いたまま、翻訳はビルドの一環として実行されます。

## SimpleLocalize の強み

* **翻訳に特化したエディター。** [翻訳エディター](https://simplelocalize.io/docs/)では、キーごとに翻訳、履歴、コメント、スクリーンショット、そして2種類の[説明](https://simplelocalize.io/docs/general/descriptions/)を確認できます。説明には、ファイルとともに受け渡されるコード説明と、エディター上で記述する翻訳者向け説明があります。用語集、翻訳メモリ、QAチェック、レビュー機能も標準で備わっています。
* **プロジェクトの文脈を活用した AI 自動翻訳。** [自動翻訳](https://simplelocalize.io/docs/general/auto-translation/)では、SimpleLocalize AI のほか、OpenAI、Anthropic、Gemini、DeepL、Google Translate などの対応プロバイダーであれば独自の API キーも使用できます。AI ワークフローではキーの説明、スクリーンショット、コメント、過去の翻訳を活用できますが、利用できる文脈は選択したプロバイダーによって異なります。
* **ファイル同期の自動化。** [GitHub App](https://simplelocalize.io/docs/integrations/github-app/) は、push またはプルリクエストのタイミングでソースファイルをアップロードし、新しいコンテンツを自動翻訳して、翻訳済みファイルを含むプルリクエストを作成します。さらにチェックを実行し、ハードコードされた文字列も検出します。[CLI](https://simplelocalize.io/docs/cli/get-started/) には、独自のビルドパイプラインで使えるアップロード、自動翻訳、ダウンロードのコマンドが用意されているほか、react-intl、react-i18next、Android、iOS プロジェクトからの抽出にも対応しています。
* **ホスティングと OTA アップデート。** [Translation Hosting](https://simplelocalize.io/docs/translation-hosting/get-started/) は、Latest と Production の環境を分けて翻訳を CDN に公開でき、ロールバックにも対応しています。また、モバイル SDK を使えば、アプリを再リリースすることなく [Android](https://simplelocalize.io/docs/integrations/android-ota/) と [iOS](https://simplelocalize.io/docs/integrations/ios-macos-ota/) の文字列を更新できます。
* **ページ上での編集とフィードバック。** SimpleLocalize の Chrome 拡張機能を使うと、公開中の Web サイト上で翻訳を検索、編集、レビューできます。また、公開提案機能により、ユーザーから修正案を受け付けることもできます。
* **顧客ごとの文言調整。** Customer translations を使えば、顧客ごとに文言を上書きできます。さらに、MCP サーバー、IDE 拡張機能、Figma プラグイン、Shopify および Webflow とのインテグレーションにより、エディターをスタック内の他のツールと連携できます。

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

SimpleLocalize が管理するのは、ライブラリが読み込むカタログです。原文を JSON で管理する react-i18next アプリでは、コンポーネントがキーを参照し、リッチテキスト要素をマッピングします。

```tsx title="src/TrialBanner.tsx"
import { Trans } from 'react-i18next';

export function TrialBanner({ name }: { name: string }) {
  return (
    <p>
      <Trans
        i18nKey="trial.banner"
        values={{ name }}
        components={{ planLink: <a href="/pricing" /> }}
      />
    </p>
  );
}
```

```json title="locales/en/translation.json"
{
  "trial": {
    "banner": "Welcome back, {{name}}. Your trial ends soon. <planLink>Compare plans</planLink>"
  }
}
```

GitHub Appを使えば、設定したプッシュをトリガーに、アップロード、自動翻訳、翻訳済みファイルを含むプルリクエストの作成までを実行できます。また、CLIを使ってビルド中に翻訳とダウンロードを行うことも可能です。それでも、抽出処理や翻訳元カタログの設定、メッセージやプレースホルダーとUIとの対応付け、プロジェクトのメタデータの管理はエンジニアの仕事であり、レビュー済みの翻訳をどのようにリリースへ反映するかもエンジニアが判断する必要があります。ライブラリによってはデフォルト値をインラインで記述し、IDを自動抽出できるものもありますが、カタログとアプリとの連携は引き続き保守しなければなりません。上の例では、翻訳元の文と、それが参照するReact要素が別々のファイルに置かれています。

SimpleLocalizeのプランでは、翻訳キー数がCommunityの500からBusinessの12,000までとなっており、チームメンバー数の上限と、月ごとの自動翻訳文字数の上限が設けられています。上限の調整やメンバーの追加が可能で、クラウドソーシングのコントリビューターは無制限です ([SimpleLocalizeの料金](https://simplelocalize.io/pricing/)を参照。2026年11月時点で確認) 。

## SimpleLocalize と General Translation の比較早見表

| 機能          | SimpleLocalize                                                     | General Translation                                                                                                                |
| ----------- | ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- |
| 文字列の置き場所    | i18nライブラリが読み込むロケールファイル内のキー。SimpleLocalize のエディタで管理                 | コード内の [`<T>`](/docs/react/reference/components/t) の中、または既存のリソースファイル内                                                               |
| コードとの連携方法   | プッシュ時やプルリクエスト時に動作する GitHub App、または CI で実行する CLI                    | ビルド時に実行する [`npx gt translate`](/docs/cli/reference/commands/translate)、または [Locadex](/docs/platform/locadex/quickstart) によるプルリクエスト |
| 翻訳の担い手      | 機械翻訳または AI 自動翻訳。チームやコントリビューターがレビュー                                 | コード、用語集、カスタムプロンプトの文脈を活用した AI 翻訳。チームがダッシュボードでレビュー                                                                                   |
| 各文字列の文脈     | キーの説明、スクリーンショット、コメント、翻訳履歴 (プロバイダーによって異なる)                          | マークされた JSX 構造とメモ、翻訳元のソース行 (任意) 、共有の用語集とカスタムプロンプト、既存ファイルのメタデータ                                                                      |
| 新しい UI テキスト | GitHub App がハードコードされた文字列を検出                                        | Next.js および React アプリでは、Locadex が未マークのテキストをラップするプルリクエストを作成                                                                         |
| 配信          | ファイルをダウンロード、または環境別に使える CDN 上の Translation Hosting。モバイル向けには OTA SDK | ビルドに含めるローカルファイル、または General Translation の CDN (React と Next.js 向け)                                                                 |
| 料金          | 無料プランあり。有料プランは翻訳キー数に応じた課金で、チームメンバー数に上限あり                           | [翻訳量に応じた従量課金](https://generaltranslation.com/pricing)。Starter ではユーザー数無制限                                                           |

## SimpleLocalize ではなく General Translation が選ばれる理由

General Translation はコンポーネント内のテキストをそのまま翻訳するため、キーの作成も同期の維持も不要です。以下は、[プロバイダーをセットアップ](/docs/react/react-quickstart)したうえで、同じバナーを `gt-react` で実装した例です。

```tsx title="src/TrialBanner.tsx"
import { T, Var } from 'gt-react';

export function TrialBanner({ name }: { name: string }) {
  return (
    <T>
      <p>
        Welcome back, <Var>{name}</Var>. Your trial ends soon.{' '}
        <a href="/pricing">Compare plans</a>
      </p>
    </T>
  );
}
```

文、名前、リンクはコンポーネント内にそのまま残り、[`npx gt translate`](/docs/cli/reference/commands/translate) はブロックを1つの単位として翻訳しつつ、名前は翻訳せずに保持します。

* **より速く。** 上のバナーでは、文言、変数、リンクをまとめて編集します。CLI はそのブロックを抽出し、ビルド前に変更箇所の翻訳を生成します。その際、一致する完了済みの翻訳は再利用されます。これにより、文言を変更するたびに発生していた翻訳元キーやリッチテキストのマッピング作業が不要になります。
* **従量課金。** SimpleLocalize では、メンバー数とキー数の上限があるため、カタログやレビューチームの拡大に伴って支払額が変わります。General Translation の[従量課金制の料金体系](https://generaltranslation.com/pricing)にはシート料金もキー数による料金区分もないため、レビュー担当者を追加で招待してもシート料金は増えません。
* **JSX の構造を文脈として活用。** 「Trial はソフトウェアのサブスクリプションの試用期間を意味する」といったメモをバナーのそばに残しておけます。抽出された構造には挨拶文と料金ページへのリンクがまとめて含まれ、レビュー担当者は生成された文言を[ダッシュボード](/kb/review-translations)で修正できます。周辺の翻訳元の行や共通の用語を追加する方法は、[文脈ガイド](/kb/ai-translation-context)を参照してください。
* **リスクを抑えて導入。** アプリですでにレンダリングしている i18next や next-intl のカタログから始め、レビュー済みの翻訳はそのまま保持できます。インライン JSX への移行は後からでも構いません。React および Next.js のリポジトリでは、設定済みの Locadex の **コードを生成** を実行すると、新たに追加された未マークのテキストに対するラッパーが、レビュー可能なプルリクエストとして提案されます。MIT ライセンスの `gt-react` または `gt-next` を使い、すべての翻訳をローカルから読み込むよう設定したアプリであれば、GT アカウントやランタイムでのサービス呼び出しなしで翻訳をレンダリングできます。

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

翻訳者やレビュー担当者がブラウザ拡張機能を使って本番サイト上のテキストを直接編集したい場合、ユーザーから翻訳の提案を受け付けたい場合、顧客ごとに異なる文言を使い分ける必要がある場合、ネイティブモバイルアプリで文字列を OTA (over-the-air) 更新する必要がある場合、あるいはアプリで [Flutter ARB、XLIFF、Java properties、Excel](https://simplelocalize.io/docs/file-formats/arb/) などの形式を使用している場合は、SimpleLocalize がおすすめです。

## SimpleLocalize から General Translation への移行

1. **エクスポートとバックアップ。** SimpleLocalize から、翻訳元ファイルと、それに対応する完成済み・レビュー済みのターゲットファイルのスナップショットをエクスポートし、バックアップを保管しておきます。未翻訳のエントリが翻訳としてインポートされないよう、未完成のロケールは先に仕上げておいてください。
2. **SimpleLocalize による書き込みを停止。** General Translation がファイルを書き込む前に、GitHub App を一時停止し、CI から SimpleLocalize のダウンロード手順を削除します。2 つのツールが同じファイルに書き込むと、最後に書き込んだ方の内容で上書きされます。
3. **文脈を設定。** 対象ファイルに合わせて `gt.config.json` を設定し、JSON または YAML の場合はキーの説明や文字数制限を[キーごとのメタデータ](/docs/cli/reference/keyed-metadata)に引き継ぎます。また、用語集をコンテキストグループにインポートし、最初の翻訳からこれらが反映されるようにします。
4. **アップロード。** [`npx gt upload`](/docs/cli/reference/commands/upload) を実行して、翻訳元のスナップショットに対応するターゲットファイルをインポートします。
5. **翻訳と確認。** [`npx gt translate`](/docs/cli/reference/commands/translate) を実行し、アプリ上でいずれかのロケールを確認します。i18next や next-intl を使用している場合は、既存のライブラリを使い続けたまま、CLI で[以降の翻訳を生成](/docs/cli/guides/generating-translations)できます。テキストをインラインに移行するかどうかは、後から別途検討してください。

## General Translation は SimpleLocalize の代替になりますか？

はい。レビュー済みの翻訳、キーの説明、用語集はそのまま引き継がれ、i18next や next-intl を使ったアプリは既存のライブラリを引き続き利用できます。変わるのはワークフローです。翻訳は同期されたカタログを経由せず、ビルド時にコンポーネントやファイルから直接実行されます。また、[i18n ライブラリからの移行](/docs/react/guides/migrating-i18n-libraries)で説明しているとおり、文言を機能単位で少しずつ [`<T>`](/docs/react/reference/components/t) にインラインで移行できます。一方で、ページ上での直接編集、ユーザーからの修正提案、顧客ごとの文言の出し分けといった SimpleLocalize の機能は使えなくなります。

## Related questions

- [General Translation と TMS（Crowdin、Lokalise、Phrase）の比較](https://generaltranslation.com/ja/kb/general-translation-vs-tms.mdx): 翻訳の生成、コードから導出した文脈、レビューをプロダクトのリリースと連動させたい開発チームには General Translation が適しています。既存のカタログとレンダリングライブラリをそのまま使うことも、翻訳キーを使わずにインライン JSX を記述することもできます。TMS は、言語ベンダー、CAT エディター、XLIFF でのやり取りを中心とした翻訳プログラムに適しており、そのインテグレーションを使えばファイル転送を自動化できます。
- [General Translation と Tolgee の比較：どちらを使うべきか？](https://generaltranslation.com/ja/kb/general-translation-vs-tolgee.mdx): Tolgee は、キーベースのメッセージ、インコンテキスト編集、AI 翻訳を、セルフホスト可能な 1 つのプラットフォームで提供します。General Translation は読みやすい文言をコンポーネント内に直接記述し、マークされた JSX から翻訳を生成します。そのため、メッセージキーを管理しなくても、新しい文言をすべての言語でリリースできます。
- [General Translation と Localazy の比較：どちらを選ぶべきか](https://generaltranslation.com/ja/kb/general-translation-vs-localazy.mdx): 共通の用語管理とビルドの自動化を活用して Web アプリやネイティブアプリの文言を翻訳しながら、レビュー済みのカタログをそのまま使い続けたい場合や、インラインコンポーネントを導入したい場合は General Translation が最適です。CLI がビルド時に翻訳を行い、レビュー担当者はダッシュボードで編集でき、料金はキー数ではなく使用量に応じて決まります。一方、Localazy は、より幅広いファイル形式への対応、プロの翻訳サービスの組み込み、ネイティブモバイル向けの OTA（Over-the-Air）アップデートを必要とするチームに向いています。
- [毎日リリースするチームに最適な継続的ローカライゼーションツールは？](https://generaltranslation.com/ja/kb/best-continuous-localization-tools.mdx): General Translation を選べば、マークされた JSX の文脈と共有のプロダクト用語を活用して、ビルドのたびに新しいコピーを翻訳できます。チームは ダッシュボード で文言をレビュー・修正でき、Locadex は新しい UI テキストを翻訳対象としてマークするプルリクエストを作成します。既存の i18next や next-intl のセットアップはそのままで、このワークフローを導入できます。
- [ソフトウェアの文字列をAI翻訳する際、十分な文脈を与えるにはどうすればよいですか？](https://generaltranslation.com/ja/kb/ai-translation-context.mdx): メッセージは分割せず、意味に関するメモ、プレースホルダーの役割、文字数制限、共通の用語を添えて翻訳します。General Translation の CLI は、マークされた JSX を構造化されたブロックとして抽出し、コンテキスト注記を翻訳の生成時にも引き継ぎます。既存の JSON や YAML のカタログでは、キーごとのメタデータで文字列ごとに指示を与えられます。コンテキストグループは、割り当てられたすべてのプロジェクトに用語集とカスタムプロンプトを適用し、レビュー担当者はダッシュボードで出力を修正します。

## Previous and next questions

- Previous question: [General Translation と Localazy の比較：どちらを選ぶべきか](https://generaltranslation.com/ja/kb/general-translation-vs-localazy.mdx)
- Next question: [ソフトウェアの文字列をAI翻訳する際、十分な文脈を与えるにはどうすればよいですか？](https://generaltranslation.com/ja/kb/ai-translation-context.mdx)

## Sitemap

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