# General Translation Knowledge Base: Reactアプリに最適なi18nライブラリは？
URL: https://generaltranslation.com/ja/kb/best-react-i18n-library.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: React向けの主要なi18nライブラリは、General Translationのgt-react、react-i18next、Lingui、React Intlの4つです。いずれも翻訳のレンダリングと書式設定に対応していますが、JSXにインラインで記述したテキストから翻訳の生成まで行えるのはgt-reactだけです。i18nextのカタログやプラグインを引き続き使いたい場合はreact-i18next、メッセージを抽出してコンパイル済みカタログを生成したい場合はLingui、FormatJSとICU MessageFormatを使いたい場合はReact Intlを選びましょう。
Category: ワークフローツール
Last updated: 2026-10-16
Authors: Jackie Chen
Published: 2026-10-16

React向けi18nライブラリの最適な選択は、テキストをどこで管理したいか、そして誰が翻訳を用意するかによって決まります。gt-reactはテキストをJSX内にインラインで保持し、今回紹介する中で唯一、翻訳の生成まで行います。react-i18next、Lingui、React Intlは、開発者がカタログファイルで用意した翻訳をレンダリングするライブラリで、記述スタイルやツールチェーンはそれぞれ異なります。

まずはレンダリングモデルを確認しましょう。ブラウザのみで動作するReactアプリ、サーバーサイドレンダリングされた React アプリ、Next.js App Routerアプリでは、セットアップの要件がそれぞれ異なり、各ライブラリのドキュメントでもそれぞれ個別に解説されています。

## 主要な React i18nライブラリの比較

| ライブラリ                          | テキストの書き方                                                                                                                          | コンテンツの翻訳                                                        | 複数形                                                       | サーバーレンダリング                                                                                            | おすすめのケース                               |
| ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- | --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | -------------------------------------- |
| gt-react (General Translation) | [`<T>`](/docs/react/reference/components/t) 内のインライン JSX、[`useGT`](/docs/react/reference/hooks/use-gt) による文字列、任意の自動ラップ、またはキーベースの辞書 | あり。[`gt translate`](/docs/cli/reference/commands/translate) で翻訳 | [`<Plural>`](/docs/react/reference/components/plural) の分岐 | [SSR セットアップ](/docs/react/react-quickstart)。App Router では [gt-next](/docs/react/nextjs-quickstart) を使用 | コンポーネント内に読みやすいテキストを書き、ビルドごとに翻訳を生成したい場合 |
| react-i18next                  | JSON リソース内のキー。リッチテキストには `Trans` を使用                                                                                               | なし。自社チームや Locize などのサービスに依頼                                     | 複数形ごとに 1 つのキー                                             | [SSR ガイド](https://react.i18next.com/latest/ssr)                                                       | すでに i18next を使っている、またはそのプラグインが必要な場合    |
| Lingui                         | インラインマクロまたは明示的な ID。PO カタログに抽出                                                                                                     | なし。カタログを翻訳者またはサービスに渡す                                           | ICU MessageFormat                                         | [RSC インテグレーション](https://lingui.dev/tutorials/react-rsc)                                               | 抽出・コンパイル型のカタログワークフローを採用したい場合           |
| React Intl (FormatJS)          | ID とデフォルトメッセージを持つメッセージ記述子                                                                                                         | なし。翻訳済みカタログを自分で用意                                               | ICU MessageFormat                                         | 使用するフレームワークのインテグレーションを確認                                                                              | チームがすでに FormatJS と ICU に慣れている場合        |

## 同じボタンを react-i18next と gt-react で実装するとどうなるか？

react-i18next では、テキストはリソースファイルで管理します。

```json title="locales/en/translation.json"
{
  "settings": {
    "save": "Save changes"
  }
}
```

コンポーネントはキーを使ってテキストを参照します：

```tsx
import { useTranslation } from 'react-i18next';

export function SaveButton() {
  const { t } = useTranslation();
  return <button type="submit">{t('settings.save')}</button>;
}
```

それ以外の言語には、それぞれ専用のリソースファイルが必要です。手作業で書くか、翻訳を外注しなければなりません。

gt-react なら、文言はコンポーネント内に書いたままで済みます：

```tsx
import { T } from 'gt-react';

export function SaveButton() {
  return (
    <T>
      <button type="submit">Save changes</button>
    </T>
  );
}
```

ビルド前に [`gt translate`](/docs/cli/reference/commands/translate) を実行すると、各 [`<T>`](/docs/react/reference/components/t) ブロックが要素構造ごと General Translation に送信され、すべての対象ロケールの翻訳が書き出されます。文言を修正すると、その変更はコンポーネントの差分に現れ、次回の実行時に改めて翻訳されます。

## 1. gt-react：テキストはJSX内に、翻訳は自動生成

gt-reactでは、翻訳元のテキストをコンポーネント内に記述します。JSXを[`<T>`](/docs/react/reference/components/t)でラップし、入力欄の`placeholder`のようにAPIが文字列を必要とする箇所では[`useGT`](/docs/react/reference/hooks/use-gt)を使用します。リッチテキストの場合は、文とそのインライン要素がまとめて翻訳されるよう、1つの[`<T>`](/docs/react/reference/components/t)ブロックに収めてください。文言だけでは意味が曖昧な場合は、[`context`プロパティ](/docs/react/reference/components/t#context)を追加します。

マークされていないJSXが多いアプリでは、[自動 JSX インジェクション](/docs/cli/guides/using-auto-jsx)を使えば、ビルド時に翻訳用のラッパーが自動で追加されます。`gt.config.json`の`files.gt.parsingFlags`で`enableAutoJsxInjection`を設定し、バンドラーに`@generaltranslation/compiler`を追加してください。React SPA、サーバーサイドレンダリングされた React アプリ、Next.jsのwebpackビルドで動作し、既存の[`<T>`](/docs/react/reference/components/t)ブロックはそのまま維持されます。アプリ全体で有効にする前に、いくつかの画面で抽出されたテキスト、動的な値、リッチテキストのまとまり方を確認してください。

gt-reactは[MITライセンス](https://github.com/generaltranslation/gt)で提供されており、他のi18nライブラリではなく、General Translation独自のICUおよびフォーマット用パッケージをベースに構築されています。General Translationのアカウントやランタイムでのリクエストがなくても、[バンドルされた翻訳](/docs/react/guides/storing-translations)をレンダリングできます。General Translationで翻訳を生成した場合は、レビュー担当者が[翻訳エディター](/docs/platform/dashboard/guides/reviewing-translations)で修正できます。

セットアップ方法はレンダリングモデルによって異なります。ブラウザのみで動作するアプリには[React SPA クイックスタート](/docs/react/react-spa-quickstart)、サーバーでレンダリングされるアプリには[Reactクイックスタート](/docs/react/react-quickstart)、Next.jsには[gt-next](/docs/react/nextjs-quickstart)を使用してください。

**gt-reactがおすすめなケース**：コンポーネントの差分でテキストをレビューしたい場合、ビルドの一環として翻訳を生成したい場合、自動ラップで既存のアプリをすばやくローカライズしたい場合。

## 2. react-i18next：i18nextエコシステム

[react-i18next](https://react.i18next.com/) は、最も広く使われているJavaScriptのi18nフレームワークであるi18nextをReactと連携させるライブラリです。フックでJSONリソースのメッセージをレンダリングし、`Trans` コンポーネントでReact要素を含むテキストを扱います。

[i18nextのプラグインエコシステム](https://www.i18next.com/overview/plugins-and-utils)には、翻訳を読み込むバックエンド、言語検出器、抽出ツールなどがそろっており、公式CLIは抽出、ロケールの同期、TypeScriptの型生成に対応しています。i18nextは[原文をキーとして使う方法](https://www.i18next.com/principles/fallback)もサポートしていますが、この方法では文言の変更と翻訳の足並みをそろえにくくなると、ドキュメントで注意喚起されています。

react-i18next自体はリソースを翻訳しません。翻訳はチームや外部サービスで用意する必要があり、i18nextチームは[Locizeを使ったワークフロー](https://react.i18next.com/guides/multiple-translation-files)を紹介しています。また、`gt` CLIを使えば、移行しなくても[react-i18nextのJSONファイルを翻訳](/docs/cli/guides/generating-translations)できます。

すでにi18nextのリソースがある場合や、読み込みや言語検出にプラグインを活用したい場合は、**react-i18nextを選びましょう**。

## 3. Lingui: カタログの抽出とコンパイル

[Lingui](https://lingui.dev/introduction) では、マクロを使ってメッセージをインラインで記述し、カタログに抽出して翻訳したうえで、アプリ向けにコンパイルできます。自動生成されたメッセージ ID と明示的なメッセージ ID の両方に対応しており、デフォルトのカタログ形式は PO です。[React チュートリアル](https://lingui.dev/tutorials/react)ではこの一連の流れを通して解説しており、サーバーコンポーネントを使うアプリ向けには[専用のインテグレーション](https://lingui.dev/tutorials/react-rsc)も用意されています。

Lingui ではテキストを UI の近くに置いておけますが、抽出以降の翻訳、レビュー、コンパイル、読み込みといった工程はすべてチーム自身で担う必要があります。抽出はあくまで新しいメッセージを検出するだけで、翻訳までは行いません。

**Lingui が適しているケース**：翻訳者や翻訳サービスが PO カタログを扱っており、Lingui の抽出機能やコンパイラのツール群を活用したい場合。

## 4. React Intl: FormatJS と ICU MessageFormat

[React Intl](https://formatjs.github.io/docs/react-intl/) は、メッセージ、複数形、日付、数値を扱う FormatJS の React 向けライブラリです。[メッセージ記述子](https://formatjs.github.io/docs/react-intl/api/)では各メッセージを ID で識別し、任意でデフォルトメッセージと翻訳者向けの説明を付けられます。[FormatJS の抽出機能](https://formatjs.github.io/docs/getting-started/message-extraction/)はこれらを収集するほか、ID を自動生成することもできます。

メッセージには [ICU MessageFormat](https://formatjs.github.io/docs/core-concepts/icu-syntax/) を使用するため、レビュアーはそのプレースホルダーや複数形の構文を読めなければなりません。また、翻訳済みのカタログはパイプライン側で用意する必要があります。サーバーレンダリングやクライアント境界の扱いはフレームワークごとに異なるため、導入前に使用するフレームワークのインテグレーションを確認してください。

**React Intl が適しているケース**：チームですでに FormatJS を使用している場合や、ICU MessageFormat で全体を統一したい場合。

## React i18nライブラリを選ぶ前に、どのようにテストすべきか？

見出し、名前付き変数、複数形のカウント、アクセシブルな入力ラベル、書式設定された価格を含む機能を1つ選びます。候補ごとにその機能を2つの言語にローカライズしたら、翻訳元の文を1つ変更し、新しいメッセージを追加してみてください。そのうえで、次の点を比較します。

1. **作成：** レビュアーは差分を見て、文言とその文脈を理解できるか？
2. **翻訳：** 新規または変更されたテキストは、翻訳担当者にどのように届くか？
3. **検証：** リリース前に、メッセージの欠落や変数の破損を検出できるか？
4. **配信：** 本番環境のアプリをレンダリングする際に、どのファイルやサービスが利用可能である必要があるか？

現在のライブラリのほうが優れているなら、そのまま使い続けましょう。`gt` CLIはreact-i18nextのカタログも翻訳できるため、文言の作成方法を選んだからといって、翻訳方法まで縛られることはありません。リリース前には、[多言語アプリのローンチチェックリスト](/kb/multilingual-app-launch-checklist)を確認してください。

General Translationは、Cursor、Ramp、Profound、Cognition、Sierra、ClickHouseの開発チームに利用されています。まずは[Reactクイックスタート](/docs/react/react-quickstart)からお試しください。

## よくある質問

### アプリを自動で翻訳してくれるReactのi18nライブラリはどれですか？

gt-reactです。react-i18next、Lingui、React Intlは、ユーザーが用意した翻訳をレンダリングするだけです。gt-reactなら、[`gt translate`](/docs/cli/reference/commands/translate) がコードを文脈として活用し、すべての対象ロケールの翻訳を生成します。

### react-i18next と React Intl はどちらが優れていますか？

一概にどちらが優れているとは言えません。react-i18next は、JSON リソースや i18next のプラグインを活用したいチームに向いています。React Intl は、FormatJS と ICU MessageFormat を標準として採用しているチームに向いています。いずれの場合も、翻訳作業そのものはチーム自身で行うか、別のサービスに任せる必要があります。

### サーバーコンポーネントに対応している React の i18nライブラリはどれですか？

Next.js App Router のアプリには、サーバーコンポーネントとクライアントコンポーネントの両方に対応した [gt-next](/docs/react/nextjs-quickstart) をおすすめします。Lingui には[専用の RSC インテグレーション](https://lingui.dev/tutorials/react-rsc)があり、next-intl も App Router 向けの選択肢の一つです。

### react-i18next から移行せずに General Translation を使用できますか？

はい。`package.json` に `i18next` が直接の依存関係として宣言されていれば、`gt` CLI がそれを検出し、react-i18next の JSON リソースを構文を保持したまま翻訳します。詳しくは[翻訳の生成](/docs/cli/guides/generating-translations)を参照してください。

### gt-react を使う場合でも JSON の翻訳ファイルは必要ですか？

原文ファイルとしては不要です。テキストはコード内にインラインで記述し、翻訳はビルド時にファイルとして生成されるか、General Translation の CDN から配信されます。詳しくは[翻訳ファイルを使わない i18n](/kb/i18n-without-translation-files) をご覧ください。

## 重要なポイント

* gt-react、react-i18next、Lingui、React Intl はいずれも、React で翻訳をレンダリングし書式設定します。ただし、翻訳そのものまで生成できるのは gt-react だけです。
* gt-react はテキストを JSX 内にインラインで記述でき、ビルド時に既存の JSX を自動的にラップすることもできます。
* react-i18next、Lingui、React Intl では、チームや翻訳サービスが翻訳を書き込むカタログが前提となります。
* react-i18next を使い続けながら、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はさらに、コードを文脈として活用しながら翻訳そのものも行います。
- [多言語アプリをローンチする前に何を確認すべきか？](https://generaltranslation.com/ja/kb/multilingual-app-launch-checklist.mdx): 多言語アプリをローンチする前に、サポート対象のすべてのロケールで次の9項目をテストしてください：エラー時を含むユーザージャーニー全体、言語検出と言語の切り替え、変数と複数形、通貨とタイムゾーン、テキストの伸長、右から左のレイアウト、アクセシビリティ、本番環境での翻訳の配信、SEOのためのクロール可能な言語別URL。各項目には明確な合格条件が必要です。
- [翻訳ファイルなしで 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 コンポーネントを使えば、あらゆる言語の複数形に対応できます。

## Previous and next questions

- Previous question: [react-intl の代替：General Translation と react-intl の比較](https://generaltranslation.com/ja/kb/general-translation-vs-react-intl.mdx)
- Next question: [Smartling の代替ツール：General Translation と Smartling の比較](https://generaltranslation.com/ja/kb/general-translation-vs-smartling.mdx)

## Sitemap

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