# General Translation Knowledge Base: General Translation と Intlayer の比較：どちらを使うべきか
URL: https://generaltranslation.com/ja/kb/general-translation-vs-intlayer.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: Intlayer は各コンポーネントのコンテンツを、その隣に置いた型付きの宣言ファイルで管理し、すべての言語を並べて記述します。不足している言語は、設定した AI プロバイダーで補完できます。General Translation はテキストを単一の言語でコンポーネント内にインラインで記述し、コードの文脈をもとに他の言語を生成します。
Category: 国際化
Last updated: 2026-10-16
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-16

Intlayer は[オープンソースの i18nライブラリ](https://github.com/aymericzip/intlayer)で、`inbox.content.ts` のような宣言ファイルを各コンポーネントの隣に置いてコンテンツを管理します。各文字列の翻訳は、1 つの `t({ en, es, pl })` 呼び出しの中にまとめて記述します。`useIntlayer('inbox')` のようなフックを使うと、そのコンテンツが現在のロケールで、型付きのまま返されます。Intlayer は設定した AI プロバイダーで不足している言語を補完でき、無料のビジュアルエディターやオプションのホスト型 CMS も提供しています。それでも、すべての文字列の全言語分は原文ファイル内に置かれたままで、その記述・補完・レビューは自分で行う必要があります。一方、General Translation のアプローチは異なります。テキストはソース言語で一度インラインで書くだけで、General Translation がコードの文脈をもとに他の言語を生成します。

## Intlayer の優れている点

* **コンテンツをコンポーネントの隣に配置。** コンポーネントごとに宣言ファイルを 1 つ置くため、テキストをそれをレンダリングするコードのすぐ近くに保てます。
* **型安全性。** `useIntlayer` のキーには型が付いており、バージョン 9.7.0 では `useIntlayer('inbx')` は TypeScript エラーになります。設定済みのロケールのいずれかが欠けている `t()` 呼び出しも検出されるため (9.7.0 のテストでは型エラーとなり、チェックの厳しさは `strictMode` で設定します) 、リリース前に抜け漏れに気付けます。
* **豊富なコンテンツ型。** 宣言ではロケールごとのテキストに加え、[CLDR カテゴリに基づく複数形](https://intlayer.org/doc/concept/content/plural) (`plural({ one, few, many, other })`) 、列挙、条件、性別、Markdown、HTML、ネスト、挿入をサポートしています。
* **好きなモデルを利用可能。** `intlayer fill` は、OpenAI、Anthropic、Mistral、Gemini、DeepSeek、Ollama、OpenRouter などのプロバイダーを使って不足しているロケールを翻訳します。プロバイダーは [`intlayer.config.ts` の `ai`](https://intlayer.org/doc/concept/configuration) で設定するか、`--provider` と `--api-key` で指定します。自前のキーを用意し、`@intlayer/ai` パッケージをインストールしておけば、[ローカルで実行でき](https://intlayer.org/doc/concept/cli/fill)、料金はプロバイダーに直接支払います。
* **ビジュアル編集。** `intlayer-editor` パッケージは実行中のアプリをエディターに読み込み、ライターがテキストを選択して編集すると、その変更を宣言ファイルに書き戻します。[Intlayer のドキュメントによると](https://intlayer.org/doc/concept/editor)、このエディターは Apache 2.0 ライセンスで商用利用も無料であり、開発環境およびステージング環境での利用を想定しています。
* **幅広いフレームワーク対応。** [ガイド](https://intlayer.org/doc/get-started)では、Next.js、React (Vite) 、React Router、TanStack Start、React Native、Vue と Nuxt、Svelte と SvelteKit、Solid、Preact、Astro、Angular に加え、Express、NestJS、Fastify、Hono などのサーバーフレームワークも扱っています。

## Intlayer が開発者に委ねていること

以下は、3 つのロケールに対応した受信トレイのコンテンツファイルです：

```ts title="inbox.content.ts"
import { t, plural, type Dictionary } from 'intlayer';

const inboxContent = {
  key: 'inbox',
  content: {
    title: t({
      en: 'Inbox',
      es: 'Bandeja de entrada',
      pl: 'Skrzynka odbiorcza',
    }),
    unread: t({
      en: plural({
        one: 'You have {{count}} unread message.',
        other: 'You have {{count}} unread messages.',
      }),
      es: plural({
        one: 'Tienes {{count}} mensaje sin leer.',
        other: 'Tienes {{count}} mensajes sin leer.',
      }),
      pl: plural({
        one: 'Masz {{count}} nieprzeczytaną wiadomość.',
        few: 'Masz {{count}} nieprzeczytane wiadomości.',
        many: 'Masz {{count}} nieprzeczytanych wiadomości.',
        other: 'Masz {{count}} nieprzeczytanej wiadomości.',
      }),
    }),
  },
} satisfies Dictionary;

export default inboxContent;
```

```tsx title="Inbox.tsx"
import { useIntlayer } from 'react-intlayer';

export function Inbox({ count }: { count: number }) {
  const { title, unread } = useIntlayer('inbox');
  return (
    <section>
      <h1>{title}</h1>
      <p>{unread({ count })}</p>
    </section>
  );
}
```

これはどのロケールでも正しくレンダリングされますが、ロケールを追加するたびにファイルは肥大化していきます。ロケールが 20 になれば、文字列ごとに 20 個のエントリを抱えることになります。新しい文字列を追加する場合も、そのすべてが必要です。`archive: t({ en: 'Archive' })` を追加すると、まだ不足しているロケールを示す型エラーが発生しました:

```text title="Output"
Type '{ en: string; }' is missing the following properties from type
'Required<Record<keyof __RequiredLocalesRegistry, unknown>>': es, pl
```

実行時、不足しているロケールは英語にフォールバックしていました。このギャップを埋めるには、翻訳を自分で書くか、`intlayer fill` を実行します。fill がモデルに送信するのは、辞書のコンテンツ、[その説明](https://intlayer.org/doc/concept/content)、そして設定にある `applicationContext` 文字列です。コンポーネントや、文字列を囲む JSX はモデルには渡されません。[Intlayer のコンパイラ](https://intlayer.org/doc/compiler)は、ビルド時にプレーンな JSX テキストをコンテンツファイルへ抽出できます。そのため宣言を手書きする手間は省けますが、翻訳が最終的にそれらのファイルに格納されることに変わりはありません。

## General Translation ではコードに含める言語は 1 つだけ

General Translation のライブラリも同様に、各ロケールのメッセージを選び、その複数形規則を適用して翻訳をレンダリングします。違いは、コンポーネントに記述するのがソース言語だけだという点です。以下は、同じ受信トレイを `gt-react` で実装した例です。

```tsx title="Inbox.tsx"
import { T, Plural, Num } from 'gt-react';

export function Inbox({ count }: { count: number }) {
  return (
    <T>
      <section>
        <h1>Inbox</h1>
        <Plural
          n={count}
          singular={<p>You have <Num>{count}</Num> unread message.</p>}
          plural={<p>You have <Num>{count}</Num> unread messages.</p>}
        />
      </section>
    </T>
  );
}
```

コンテンツファイルもキーも不要です。[`npx gt translate`](/docs/cli/reference/commands/translate) は各 [`<T>`](/docs/react/reference/components/t) ブロックを要素構造ごと General Translation API に送信し、すべての対象ロケールの翻訳をそれぞれ別のファイルに書き出します。そのため、ロケールを追加しても変更されるのは `gt.config.json` だけで、コンポーネントには手を加えずに済みます。英語で使う複数形を書くだけで、各対象言語に必要な形は翻訳時に生成され、[`<Plural>`](/docs/react/reference/components/plural) が読み手のロケールの規則に従って翻訳済みの分岐を選択します。[`npx gt validate`](/docs/cli/reference/commands/validate) は API を呼び出さずにプロジェクトを検証し、[`gt generate`](/docs/cli/reference/commands/generate) は手作業で翻訳するチーム向けにテンプレートを書き出します。

翻訳の質を左右するのは文脈です。General Translation は、マークされた各ブロック内のテキストと JSX 構造をまとめて翻訳し、開発者向けの注記を手がかりに意味を判断します。文書の「Save」ボタンはドイツ語で「speichern」ですが、お金を節約する提案であれば「sparen」になります。[コンテキストグループ](/docs/platform/dashboard/guides/defining-context-for-translations)を使うと、割り当てたプロジェクトに用語集とカスタムプロンプトが適用されます。レビュアーはダッシュボードで編集でき、コードの変更に伴う更新は CLI または [Locadex](/docs/platform/locadex/quickstart) が処理します。既存の JSX を自動でマークしたい場合は、[自動 JSX インジェクション](/docs/cli/guides/using-auto-jsx)を有効にしてください。

JavaScript ライブラリは MIT ライセンスで提供されており、アカウントがなくても、用意した翻訳をレンダリングできます。翻訳はビルドに含めることも、General Translation の CDN に公開することもできます。

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

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

| 機能         | Intlayer                                                                                                   | General Translation                                                                                                  |
| ---------- | ---------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| コピーの書き方    | コンポーネントごとの宣言ファイルに `t({ en, es, ... })` を記述し、`useIntlayer` で読み込む                                            | [`<T>`](/docs/react/reference/components/t) で囲んだ JSX、[`useGT`](/docs/react/reference/hooks/use-gt) で扱う文字列、またはキー付きの辞書 |
| 翻訳の保存場所    | 宣言ファイル内、またはロケールごとのコンテンツファイル                                                                                | ロケールごとの個別ファイル、または General Translation の CDN                                                                          |
| AI 翻訳      | 自前のプロバイダーキーを使った `intlayer fill`、または Intlayer のサービス経由                                                       | General Translation API を利用する [`npx gt translate`](/docs/cli/reference/commands/translate)                           |
| モデルに渡される文脈 | 辞書の内容、説明、アプリケーションの文脈を表す文字列                                                                                 | マークされた JSX の構造、開発者向けの注記、割り当てられた用語集とカスタムプロンプト                                                                         |
| 不足しているロケール | 検出される (9.7.0 のテストでは型エラーとして検出) 。[`intlayer test`](https://intlayer.org/doc/concept/cli/test) で報告される         | [`npx gt translate`](/docs/cli/reference/commands/translate) で生成される。未翻訳のコンテンツはソース言語でレンダリングされる                        |
| 編集         | 無料のローカルビジュアルエディター。ホスト型 CMS は任意                                                                             | ダッシュボードで翻訳を編集・レビュー                                                                                                   |
| フレームワーク    | React、Next.js、Vue、Svelte、Solid、Angular、Astro、React Native、Node.js サーバー                                     | React、Next.js、Vue、Node.js、および[その他の SDK](/docs/overview/get-started)                                                  |
| ライセンスと費用   | Apache 2.0。ホスト型 CMS のプランはプロジェクト数、シート数、ストレージ量に応じて変動 ([料金](https://app.intlayer.org/pricing)、2026 年 10 月確認)  | MIT ライセンスの JavaScript ライブラリ。[従量課金制の翻訳](https://generaltranslation.com/pricing)                                       |

すべての言語をコンポーネントのすぐ横で確認したい、不足しているロケールを型エラーで検出したい、ライター向けにページ上で使えるエディターがほしい、あるいは Svelte、Solid、Angular 向けのインテグレーションを使いたい、という場合は Intlayer が適しています。一方、コピーはソース言語で一度書くだけにして、他の言語はすべてコードの文脈、用語集、カスタムプロンプトを踏まえて生成したい場合は、General Translation を使いましょう。

## IntlayerからGeneral Translationへの移行

コンポーネントは1つずつ移行し、General Translation版の準備が整うまではそのコンポーネントのIntlayerの翻訳を使い続けてください。`react-intlayer` 9.7.0と`gt-react` 11.4.12を使ったサーバーレンダリングでは、`IntlayerProvider`と[`GTProvider`](/docs/react/reference/components/gt-provider)の配下で、Intlayerのコンポーネントと[`<T>`](/docs/react/reference/components/t)コンポーネントを並べてレンダリングできることを確認しています。コンポーネントの`en`の値を[`<T>`](/docs/react/reference/components/t)内のJSXにコピーし、[`npx gt translate`](/docs/cli/reference/commands/translate)で翻訳を生成したら、結果を確認してからコンポーネントを切り替えてください。まずは[Next.jsクイックスタート](/docs/react/nextjs-quickstart)または[Reactクイックスタート](/docs/react/react-quickstart)から始めましょう。移行中に2つのライブラリを併用する方法については、[i18nライブラリの移行](/docs/react/guides/migrating-i18n-libraries)を参照してください。

## 重要なポイント

* Intlayer は、各コンポーネントのコンテンツを型付きの宣言ファイルで管理し、すべての言語を並べて記述します。欠けているロケールは型エラーとして検出され、設定した AI プロバイダーによって補完されます。
* General Translation では、コンポーネント内にはソース言語のみを記述し、それ以外の言語はすべて、コード・用語集・カスタムプロンプトから得た文脈をもとに生成されます。生成結果はダッシュボードでレビューできます。
* Intlayer はより多くのフレームワークに対応しており、ページ上でのビジュアル編集機能も備えています。両ライブラリは併用してレンダリングできるため、General Translation へはコンポーネント単位で段階的に移行できます。

## 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はさらに、コードを文脈として活用しながら翻訳そのものも行います。
- [General Translation と Paraglide JS：どちらを使うべきか](https://generaltranslation.com/ja/kb/general-translation-vs-paraglide.mdx): コピーをインラインで記述したまま、React コンポーネントの構造、共有の用語集、ダッシュボード でのレビューを活かして翻訳を生成したいなら General Translation を選びましょう。コンパイル済みの型付きメッセージ関数と、メッセージ単位のツリーシェイキングを重視するなら Paraglide JS が適しています。Paraglide はカタログをレンダリングするライブラリであり、General Translation は翻訳元のコピーを翻訳の生成から継続的な更新までつなげます。
- [翻訳ファイルなしで i18n はできますか？](https://generaltranslation.com/ja/kb/i18n-without-translation-files.mdx): はい。gt-react または gt-next を使えば、コンテンツは `<T>` コンポーネントで囲んだままコンポーネント内にインラインで記述でき、翻訳はビルド時に出力として生成されます。そのため、キーやロケールごとの JSON ファイルを作成したり、同期を保ったりする必要はありません。
- [React で複数形を扱うには？](https://generaltranslation.com/ja/kb/how-to-handle-plurals-in-react.mdx): n === 1 のような条件分岐で複数形の選択ロジックをハードコードするのは避けましょう。英語のみのアプリなら小さなヘルパーで十分ですが、多言語アプリではロケール対応の複数形規則が必要になります。gt-react や gt-next の `<Plural>` のような i18n コンポーネントを使えば、あらゆる言語の複数形に対応できます。
- [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 はコード内のコンテンツを文脈ごと翻訳し、リリースのたびに全言語をまとめて提供します。ロックインのないオープンソースのライブラリ上で動作します。

## Previous and next questions

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

## Sitemap

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