Creation:2025-01-02Last update:2025-06-29
このドキュメントをあなたの好きなAIアシスタントに参照してくださいChatGPTClaudeDeepSeekGoogle AI modeGeminiPerplexityMistralGrok
このページとあなたの好きなAIアシスタントを使ってドキュメントを要約します
このページのコンテンツはAIを使用して翻訳されました。
英語の元のコンテンツの最新バージョンを見るEdit this doc
If you have an idea for improving this documentation, please feel free to contribute by submitting a pull request on GitHub.
GitHub link to the documentationCopy
Copy doc Markdown to clipboard
react-Intl VS react-i18next VS intlayer | Reactの国際化（i18n）
本ガイドでは、React向けの3つの確立されたi18nオプション、react-intl（FormatJS）、react-i18next（i18next）、およびIntlayerを比較します。
対象はプレーンなReactアプリケーション（例：Vite、CRA、SPA）です。Next.jsを使用している場合は、専用のNext.js比較をご覧ください。
評価項目：
- アーキテクチャとコンテンツの構成
- TypeScriptと安全性
- 翻訳漏れの処理
- リッチコンテンツとフォーマット機能
- パフォーマンスと読み込み動作
- 開発者体験（DX）、ツールおよびメンテナンス
- SEO／ルーティング（フレームワーク依存）
要約：3つともReactアプリのローカライズが可能です。もしコンポーネント単位のコンテンツ管理、厳格なTypeScript型、ビルド時の未翻訳キー検出、ツリーシェイク可能な辞書、そして組み込みの編集ツール（ビジュアルエディター／CMS＋オプションのAI翻訳）を求めるなら、Intlayerがモジュール化されたReactコードベースに最も適した選択肢です。
ハイレベルな位置づけ
- react-intl - ICU優先で、標準に準拠したフォーマット（日付／数値／複数形）を持つ成熟したAPI。カタログは通常集中管理され、キーの安全性やビルド時の検証は主にユーザーの責任です。
- react-i18next - 非常に人気があり柔軟性が高い。ネームスペース、検出器、多数のプラグイン（ICU、バックエンドなど）を備えています。強力ですが、プロジェクトの規模が大きくなると設定が複雑化することがあります。
- Intlayer - React向けのコンポーネント中心のコンテンツモデル、厳格なTS型付け、ビルド時チェック、ツリーシェイク、さらにビジュアルエディター／CMSとAI支援翻訳を備えています。React Router、Vite、CRAなどと連携可能です。
機能マトリックス（Reactにフォーカス）
テーブルのすべての内容を表示
テーブルをモーダルで開き、すべてのデータを明確に表示
| 機能 | react-intlayer (Intlayer) | react-i18next (i18next) | react-intl (FormatJS) |
|---|---|---|---|
| コンポーネント近くの翻訳 | ✅ はい、各コンポーネントにコンテンツが配置されています | ❌ いいえ | ❌ いいえ |
| TypeScript 統合 | ✅ 高度、厳密な型が自動生成されます | ⚠️ 基本的なもの；安全性のために追加設定が必要 | ✅ 良好ですが、厳密さはやや劣ります |
| 翻訳漏れ検出 | ✅ TypeScriptのエラー強調表示およびビルド時のエラー/警告 | ⚠️ 実行時に主にフォールバック文字列を使用 | ⚠️ フォールバック文字列 |
| リッチコンテンツ（JSX/Markdown/コンポーネント） | ✅ 直接サポート | ⚠️ 制限あり / 補間のみ | ⚠️ ICU構文、実際のJSXではない |
| AI搭載翻訳 | ✅ はい、複数のAIプロバイダーをサポート。自身のAPIキーを使用可能。アプリケーションのコンテキストとコンテンツの範囲を考慮します。 | ❌ いいえ | ❌ いいえ |
| ビジュアルエディター | ✅ はい、ローカルのビジュアルエディター＋オプションのCMS；コードベースのコンテンツを外部化可能；埋め込み可能 | ❌ いいえ / 外部のローカリゼーションプラットフォームで利用可能 | ❌ いいえ / 外部のローカリゼーションプラットフォームで利用可能 |
| ローカライズされたルーティング | ✅ はい、ローカライズされたパスを標準でサポート（Next.js & Viteで動作） | ⚠️ 組み込みなし、プラグイン（例：next-i18next）やカスタムルーター設定が必要 | ❌ いいえ、メッセージフォーマットのみで、ルーティングは手動 |
| 動的ルート生成 | ✅ はい | ⚠️ プラグイン/エコシステムまたは手動設定 | ❌ 提供されていません |
| 複数形対応 | ✅ 列挙ベースのパターン | ✅ 設定可能（i18next-icuのようなプラグイン） | ✅ （ICU） |
| フォーマット（日時、数値、通貨） | ✅ 最適化されたフォーマッター（内部でIntlを使用） | ⚠️ プラグインまたはカスタムIntlの使用による | ✅ ICUフォーマッター |
| コンテンツフォーマット | ✅ .tsx, .ts, .js, .json, .md, .txt, (.yaml 作業中) | ⚠️ .json | ✅ .json, .js |
| ICUサポート | ⚠️ 作業中 | ⚠️ プラグイン経由 (i18next-icu) | ✅ はい |
| SEOヘルパー（hreflang、サイトマップ） | ✅ 組み込みツール：サイトマップ、robots.txt、メタデータのヘルパー | ⚠️ コミュニティプラグイン／マニュアル | ❌ コア機能ではない |
| エコシステム／コミュニティ | ⚠️ 小規模だが急速に成長し反応が良い | ✅ 最大かつ成熟 | ✅ 大規模 |
| サーバーサイドレンダリング & サーバーコンポーネント | ✅ はい、SSR / React サーバーコンポーネント向けに最適化されています | ⚠️ ページレベルでサポートされていますが、子のサーバーコンポーネントに対して t 関数をコンポーネントツリーで渡す必要があります | ❌ サポートされていません。子のサーバーコンポーネントに対して t 関数をコンポーネントツリーで渡す必要があります |
| ツリーシェイキング（使用されるコンテンツのみ読み込み） | ✅ はい、Babel/SWC プラグインを使ったビルド時のコンポーネント単位で実施 | ⚠️ 通常はすべて読み込みます（名前空間やコード分割で改善可能） | ⚠️ 通常はすべて読み込みます |
| 遅延読み込み | ✅ はい、ロケールごと / 辞書ごとに対応 | ✅ はい（例：バックエンドや名前空間をオンデマンドで） | ✅ はい（ロケールバンドルを分割） |
| 未使用コンテンツの削除 | ✅ はい、ビルド時に辞書ごとに対応 | ❌ いいえ、手動で名前空間を分割する方法のみ対応 | ❌ いいえ、宣言されたすべてのメッセージがバンドルされる |
| 大規模プロジェクトの管理 | ✅ モジュール化を促進し、デザインシステムに適している | ⚠️ ファイル管理の規律が必要 | ⚠️ 中央カタログが大きくなる可能性がある |
詳細比較
1) アーキテクチャとスケーラビリティ
- react-intl / react-i18next: 多くのセットアップでは、言語ごとに集中管理されたロケールフォルダを維持し、場合によってはネームスペース（i18next）で分割しています。初期段階ではうまく機能しますが、アプリが成長するにつれて共有の作業領域となります。
- Intlayer: UIと共に配置されたコンポーネント単位（または機能単位）の辞書を推奨します。これにより所有権が明確になり、コンポーネントの複製や移行が容易になり、チーム間でのキーの混乱が減少します。未使用のコンテンツも特定しやすく、削除が簡単です。
重要な理由: モジュール化されたコンテンツはモジュール化されたUIを反映します。大規模なReactコードベースでは、翻訳が所属するコンポーネントと共に存在することでコードがよりクリーンに保たれます。
2) TypeScriptと安全性
- react-intl: 安定した型定義がありますが、自動的なキーの型付けはありません。安全性のパターンは自分で強制する必要があります。
- react-i18next: フックに対する強力な型定義がありますが、厳密なキーの型付けには通常、追加の設定やジェネレーターが必要です。
- Intlayer: コンテンツから厳密な型を自動生成します。IDEのオートコンプリートやコンパイル時エラーにより、実行前にタイプミスやキーの欠落を検出します。
なぜ重要か: 失敗を左側（ビルド/CI段階）に移すことで、本番環境の問題を減らし、開発者のフィードバックループを高速化します。
3) 翻訳欠落の取り扱い
- react-intl / react-i18next: デフォルトは実行時のフォールバック（キーのエコーやデフォルトロケール）。リンティングやプラグインを追加可能ですが、ビルド時の保証はありません。
- Intlayer: 必須のロケールやキーが欠落している場合、ビルド時に検出し、警告またはエラーを出します。
なぜ重要か: CIで欠落文字列を検出し失敗させることで、非英語UIに「謎の英語」が混入するのを防ぎます。
4) リッチコンテンツとフォーマット
- react-intl: 複数形、選択、日付/数値、メッセージ構成に対する優れた ICU サポート。JSX を使用可能ですが、メンタルモデルはメッセージ中心のままです。
- react-i18next: 柔軟な補間と要素/コンポーネントを埋め込むための
<Trans>コンポーネント；ICU はプラグイン経由で利用可能です。 - Intlayer: コンテンツファイルは リッチノード（JSX/Markdown/コンポーネント）や メタデータ を含めることができます。フォーマットは内部的に Intl を使用し、複数形パターンは使いやすく設計されています。
重要な理由: 複雑なUIテキスト（リンク、太字部分、インラインコンポーネント）が、ライブラリがReactノードをきれいに扱うことでより簡単になります。
5) パフォーマンスと読み込み動作
- react-intl / react-i18next: 通常、カタログの分割や遅延読み込みは手動で管理します（名前空間や動的インポート）。効果的ですが、規律が必要です。
- Intlayer: 未使用の辞書をツリーシェイクし、辞書単位・ロケール単位の遅延読み込みを標準でサポートします。
なぜ重要か: バンドルサイズが小さくなり、未使用の文字列が減ることで、起動時間やナビゲーションのパフォーマンスが向上します。
6) DX、ツール＆メンテナンス
- react-intl / react-i18next: 幅広いコミュニティエコシステムがあり、編集ワークフローには通常、外部のローカリゼーションプラットフォームを採用します。
- Intlayer: 無料のビジュアルエディターとオプションのCMS（コンテンツをGitに保持するか外部化するか選択可能）を提供します。また、コンテンツ作成用のVSCode拡張機能や、独自のプロバイダーキーを使ったAI支援翻訳も利用可能です。
重要な理由: 組み込みのツールにより、開発者とコンテンツ作成者間のやり取りが短縮され、接着コードが減り、ベンダー依存も少なくなります。
どれを選ぶべきか？
- react-intlを選ぶ場合は、シンプルで標準に準拠したAPIを持つICU優先のメッセージフォーマットを求め、チームがカタログや安全チェックを手動で管理することに慣れている場合です。
- react-i18nextを選ぶ場合は、i18nextのエコシステムの幅広さ（検出器、バックエンド、ICUプラグイン、統合など）が必要で、柔軟性を得るためにより多くの設定を受け入れられる場合です。
- Intlayerを選ぶべき場合：コンポーネント単位のコンテンツ管理、厳格なTypeScript、ビルド時の保証、ツリーシェイキング、そして充実した編集ツールを重視する場合、特に大規模でモジュール化されたReactアプリに最適です。
実践的な移行ノート（react-intl / react-i18next → Intlayer）
- 段階的に移行する：まずは一つの機能やルートから始め、移行期間中は旧カタログを並行して維持します。
- コンポーネントごとの辞書を採用する：コンテンツをコンポーネントと共に配置し、結合度を下げます。
- 厳格なチェックを有効にする：ビルド時のエラーで欠落したキーやロケールをCIの早い段階で検出します。
- バンドルサイズを測定する：未使用の文字列が削除されることでサイズ削減が期待できます。
結論
3つのライブラリはすべてReactのローカライズを効果的に行います。差別化のポイントは、安全でスケーラブルなセットアップを実現するためにどれだけのインフラストラクチャを構築する必要があるかです。
- Intlayerでは、モジュラーコンテンツ、厳格なTS型付け、ビルド時の安全性、ツリーシェイクされたバンドル、そして編集ツールがデフォルトであり、手間ではありません。
- チームが多言語対応でコンポーネント駆動のReactアプリにおいて、保守性と速度を重視するなら、Intlayerは今日最も完全な開発者およびコンテンツワークフローを提供します。