# General Translation Knowledge Base: General Translation と Paraglide JS：どちらを使うべきか
URL: https://generaltranslation.com/ja/kb/general-translation-vs-paraglide.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: コピーをインラインで記述したまま、React コンポーネントの構造、共有の用語集、ダッシュボード でのレビューを活かして翻訳を生成したいなら General Translation を選びましょう。コンパイル済みの型付きメッセージ関数と、メッセージ単位のツリーシェイキングを重視するなら Paraglide JS が適しています。Paraglide はカタログをレンダリングするライブラリであり、General Translation は翻訳元のコピーを翻訳の生成から継続的な更新までつなげます。
Category: 国際化
Last updated: 2026-10-16
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-16

Paraglide JS は、inlang が開発したコンパイラファーストの i18nライブラリです。メッセージは `messages/en.json` のような JSON ファイルで管理し、コンパイラが各メッセージを型付きの関数に変換します。この関数は `m.greeting({ name })` のように呼び出す形になるため、バンドラーはページで使われないメッセージを除外できます。ただし、翻訳作業そのものは利用者に委ねられます。すべての言語のすべてのメッセージは、あなた自身や翻訳者が用意するか、ファイルに対して機械翻訳コマンドを実行して作成しなければなりません。General Translation のライブラリも翻訳をレンダリングしますが、それに加えて、コンポーネント内にインラインで一度書いたコピーから翻訳を生成することもできます。

## Paraglide JS の強み

* **型安全性。** メッセージのキーとパラメータは型として生成されます。バージョン 2.29.0 では、`m.greting()` のようなスペルミスも、`name` パラメータを渡さずに `m.greeting({})` を呼び出すことも、どちらも TypeScript のエラーになります。
* **バンドルサイズ。** メッセージは ES モジュールにコンパイルされるため、未使用のものはツリーシェイキングで除去されます。Paraglide の[公開ベンチマーク](https://paraglidejs.com/benchmark)では、5 つのロケールで 200 件中 100 件のメッセージを使用するページの転送量は、Paraglide が 47 KB、i18next が 205 KB でした。
* **複数形とバリアント。** デフォルトのメッセージ形式では[複数形セレクタを宣言](https://paraglidejs.com/variants)し、`one`、`few`、`many` などの CLDR カテゴリでマッチングします。[プラグイン](https://paraglidejs.com/file-formats)を使えば ICU MessageFormat 1 や i18next のファイルにも対応でき、フォーマッタは `Intl` を通じて数値、日付、相対時間の書式設定に対応しています。
* **ロケール戦略。** 順序付きの [`strategy` リスト](https://paraglidejs.com/strategy)に従い、URL、クッキー、`localStorage`、ブラウザの優先言語、グローバル変数、カスタム戦略、または `baseLocale` からロケールを解決します。2.29.0 の[デフォルト](https://github.com/opral/paraglide-js/blob/main/src/compiler/compiler-options.ts)は `cookie`、`globalVariable`、`baseLocale` の順です。ローカライズされたルートは[サーバーミドルウェア](https://paraglidejs.com/middleware)と `localizeUrl` で処理します。
* **幅広いフレームワーク対応。** Paraglide は[あらゆる Vite アプリで動作](https://paraglidejs.com/vite)し、React、Vue、Solid、SvelteKit、TanStack Start、React Router、Astro、Next.js 向けのガイドが用意されています。Svelte CLI の [`npx sv add paraglide` で導入されるアドオン](https://paraglidejs.com/sveltekit)も Paraglide です。[Next.js ガイド](https://paraglidejs.com/next-js)では、webpack プラグインを使って App Router に対応する方法を解説しており、`--webpack` フラグを付けて実行します。
* **無料のオープンなツール群。** ライブラリは [MIT ライセンス](https://github.com/opral/paraglide-js/blob/main/LICENSE)です。[inlang CLI](https://inlang.com/m/2qj2w8pu/app-inlang-cli) で CI 上のプロジェクトチェックができ、[Sherlock](https://inlang.com/m/r7kp499g/app-inlang-ideExtension) は VS Code 上で翻訳をインライン表示します。[Fink](https://fink.inlang.com/) は、翻訳者の変更を GitHub リポジトリにコミットできる無料のブラウザエディタです。

## Paraglide JS が開発者に任せていること

inlang プロジェクトの実体は `project.inlang` フォルダで、その中の `settings.json` にロケール、プラグイン、メッセージファイルへのパスを記述します。以下は、通常のメッセージ、パラメータ付きのメッセージ、複数形のメッセージを含む受信トレイの例です。

```json title="messages/en.json"
{
  "inbox_title": "Inbox",
  "greeting": "Hello {name}!",
  "unread_messages": [
    {
      "declarations": ["input count", "local countPlural = count: plural"],
      "selectors": ["countPlural"],
      "match": {
        "countPlural=one": "You have {count} unread message.",
        "countPlural=*": "You have {count} unread messages."
      }
    }
  ]
}
```

```tsx title="Inbox.tsx"
import { m } from './paraglide/messages.js';

export function Inbox({ name, count }: { name: string; count: number }) {
  return (
    <section>
      <h1>{m.inbox_title()}</h1>
      <p>{m.greeting({ name })}</p>
      <p>{m.unread_messages({ count })}</p>
    </section>
  );
}
```

ほかのロケールにも、それぞれ同じキーと、その言語に必要なバリアントを持つファイルを用意する必要があります。たとえばポーランド語では `one`、`few`、`many`、`*` に一致させます。`messages/pl.json` にキーが存在しない場合、コンパイルされた関数は警告を出さずにベースロケールにフォールバックします。以下は、`greeting` を含まないポーランド語ファイルでコンポーネントをレンダリングした結果です：

```text title="Output"
pl  <h1>Skrzynka odbiorcza</h1><p>Hello Ada!</p><p>Masz 2 nieprzeczytane wiadomości.</p>
```

`npx @inlang/cli check` はこれを検出し、`greeting` にポーランド語の翻訳がないことを報告して終了コード 1 で終了するため、CI でこの抜けをブロックできます。とはいえ、抜けを埋めるのはあくまで開発者自身の仕事です。`inlang machine translate` は、不足しているメッセージを、デフォルトではコミュニティが運営する無料サービスで、または自前の Google Cloud Translation や DeepL の API キーを使って翻訳します。ただし、メッセージは 1 件ずつ、使われているコンポーネントから切り離された状態で翻訳されます。inlang CLI の公式ドキュメントでも、製品やコードの文脈を把握したコーディングエージェントのほうが、汎用的な機械翻訳よりも質の高い下書きを作成できると述べられています。

## 翻訳は General Translation が作成します

General Translation のライブラリも、レンダリングという役割は同じです。違うのは、文言をどこで管理し、誰が翻訳するかという点です。同じ受信トレイを `gt-react` で実装すると、次のようになります：

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

export function Inbox({ name, count }: { name: string; count: number }) {
  return (
    <T>
      <section>
        <h1>Inbox</h1>
        <p>Hello <Var>{name}</Var>!</p>
        <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 に送信し、すべての対象ロケールの翻訳を書き出します。そのため、新しく追加した文も英語にフォールバックすることなく、ビルド前に翻訳されます。[`<Var>`](/docs/react/reference/components/var) 内の値が API に送信されることはありません。また、[`<Plural>`](/docs/react/reference/components/plural) は読者のロケールの複数形規則に基づいて分岐を選択します。[`npx gt validate`](/docs/cli/reference/commands/validate) は API を呼び出さずにプロジェクトを検証し、[`gt generate`](/docs/cli/reference/commands/generate) は手作業で翻訳するチーム向けにテンプレートファイルを書き出します。

このブロック内の見出し、挨拶文、複数形の分岐は、ひとまとまりで翻訳に送られます。General Translation はプロジェクトに割り当てられた[用語集とカスタムプロンプト](/docs/platform/dashboard/guides/defining-context-for-translations)も適用し、レビュアーはダッシュボードで翻訳結果を編集できます。CLI を CI に組み込むか、[Locadex](/docs/platform/locadex/quickstart) を設定して、コードの変更時に翻訳のプルリクエストを自動で作成させましょう。

General Translation の JavaScript ライブラリは MIT ライセンスで提供されており、翻訳を自前で用意すればアカウントなしでも動作します。翻訳をアプリにバンドルすれば、レンダリングがホスト型サービスに左右されなくなります。CDN 配信を使えば、アプリケーションのリリースとは切り離して翻訳の修正を公開できます。セットアップ方法については[翻訳の保存](/docs/react/guides/storing-translations)を参照してください。

Sierra は General Translation を活用し、Web コンテンツや市場投入向けコンテンツで 7 つ以上のロケールを提供しています。 ([本番環境での導入事例](https://generaltranslation.com/enterprise)をご覧ください。)

## Paraglide JS と General Translation の比較一覧

| 機能         | Paraglide JS                                                                           | General Translation                                                                                                        |
| ---------- | -------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| 文言の書き方     | ロケールごとの JSON ファイルにキーを記述し、`m.key()` として呼び出す                                             | [`<T>`](/docs/react/reference/components/t) 内に JSX を記述、[`useGT`](/docs/react/reference/hooks/use-gt) で文字列を扱う、またはキー付きの辞書を使用 |
| コンテンツの翻訳   | なし。`inlang machine translate` でコミュニティサービス、Google、DeepL のいずれかを利用                        | あり。[`npx gt translate`](/docs/cli/reference/commands/translate) で翻訳                                                        |
| 翻訳者が参照する情報 | 選択した翻訳ツールに渡されるメッセージ内容                                                                  | マークされた JSX ブロック、開発者向けの注記、割り当てられた用語集とカスタムプロンプト                                                                              |
| 型安全性       | すべてのキーとパラメータの型を生成                                                                      | JSX をインラインで記述するため、メッセージキーの入力ミスが起こらない                                                                                       |
| バンドル       | メッセージ単位でツリーシェイキング                                                                      | 翻訳をロケール単位で読み込み                                                                                                             |
| 翻訳の欠落      | ベースロケールにフォールバックし、`inlang check` で検出                                                    | [`npx gt translate`](/docs/cli/reference/commands/translate) で生成。未翻訳のコンテンツは翻訳元の言語でレンダリング                                   |
| フレームワーク    | Vite アプリ、React、Vue、Solid、SvelteKit、Astro、TanStack Start、React Router、Next.js (webpack) | React、Next.js、Vue、Node.js、および[その他の SDK](/docs/overview/get-started)                                                        |
| 費用         | 無料のオープンソース                                                                             | JavaScript ライブラリは無料、[翻訳は従量課金](https://generaltranslation.com/pricing)                                                      |

SvelteKit、Astro、Solid で開発している場合、メッセージ単位のツリーシェイキングや型付きメッセージ関数を何より重視する場合、あるいはチームですでに翻訳を自前で用意したり外注したりしている場合は、Paraglide JS を引き続き使うのがよいでしょう。コンポーネント内で文言をそのまま読める形にしつつ、ビルドのたびにコードの文脈を踏まえて全言語の翻訳を生成したい場合は、General Translation をお使いください。

## コンポーネント単位でGeneral Translationに移行する

コンポーネント単位で段階的に移行することも可能です。Paraglideのメッセージは単なる関数で、プロバイダーを必要としません。そのため、ルートを順に移行している間も、`m.*`の呼び出しと[`<T>`](/docs/react/reference/components/t)ブロックを並べてレンダリングできます。具体的な手順は[i18nライブラリの移行](/docs/react/guides/migrating-i18n-libraries)で解説しています。[Reactクイックスタート](/docs/react/react-quickstart)または[Next.jsクイックスタート](/docs/react/nextjs-quickstart)から始めてください。

## 重要なポイント

* Paraglide JS はカタログを、型付きで ツリーシェイキング可能な関数にコンパイルします。これらのカタログの翻訳は、inlang の別ツールで生成できます。
* General Translation では、テキストを [`<T>`](/docs/react/reference/components/t) 内にインラインで記述し、コード、用語集、カスタムプロンプトから得られる文脈をもとに翻訳を生成します。翻訳のレビューはダッシュボードで行えます。
* コンポーネントを General Translation へ移行している間も、Paraglide の既存のメッセージはそのまま動かし続けられます。移行済みのコンポーネントでは、原文と翻訳用の文脈がそれぞれ JSX 内に保持されます。

## 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 と Intlayer の比較：どちらを使うべきか](https://generaltranslation.com/ja/kb/general-translation-vs-intlayer.mdx): Intlayer は各コンポーネントのコンテンツを、その隣に置いた型付きの宣言ファイルで管理し、すべての言語を並べて記述します。不足している言語は、設定した AI プロバイダーで補完できます。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 と nestjs-i18n：どちらを使うべきか？](https://generaltranslation.com/ja/kb/general-translation-vs-nestjs-i18n.mdx)
- Next question: [General Translation と Rails I18n：両方必要か？](https://generaltranslation.com/ja/kb/general-translation-vs-rails-i18n.mdx)

## Sitemap

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