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にフォーカス）

---

詳細比較

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は今日最も完全な開発者およびコンテンツワークフローを提供します。