react-Intl VS react-i18next VS intlayer

本ガイドでは、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などと連携可能です。

これらのライブラリがどのように生まれたのかを知るには、JavaScript i18n の歴史をご覧ください。

機能マトリックス（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: 未使用の辞書をツリーシェイクし、辞書単位・ロケール単位の遅延読み込みを標準でサポートします。

なぜ重要か: バンドルサイズが小さくなり、未使用の文字列が減ることで、起動時間やナビゲーションのパフォーマンスが向上します。

以下のグラフは、1〜10ページを1〜10言語に翻訳した理論上のアプリ（1ページあたり約30KBのテキスト）のコンテンツ量を推定したものです。ロケールごとの動的読み込みは言語の軸を取り除き、コンポーネントやルート単位でコンテンツをスコープすることはページの軸を取り除きます。両方を組み合わせた場合のみ、コンテンツ量は一定に保たれます。

React でのベンチマーク結果（TanStack Start / Vite）

TanStack Start 上の標準的な React 実装を計測した Benchmark Bloom の数値：

完全な表は TanStack Start ベンチマークレポート と i18n ベンチマーク概要 を参照してください。

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 は react-intl や react-i18next の namespace の管理にも役立ちます。

intlayer を使えば、お気に入りの i18n ライブラリの形式でコンテンツを宣言でき、intlayer が任意の場所に namespace を生成します（例：/messages/{{locale}}/{{namespace}}.json）。

関連資料とベンチマーク

ベンチマークレポート：

GitHub STARs

GitHub スターはプロジェクトの人気度、コミュニティからの信頼、長期的な関連性の強い指標です。技術的な品質の直接的な測定ではありませんが、多くの開発者がプロジェクトを有用であると判断し、その進捗をフォローし、採用する可能性があることを反映しています。プロジェクトの価値を見積もるために、スターは代替案間での牽引力を比較し、エコシステムの成長に関する洞察を提供するのに役立ちます。

コミット数

スター数は人気を示し、コミット数はプロジェクトに注がれた作業量を示します。執筆時点で Intlayer のコミット数は約 7,500 件で、ここで比較している多くのライブラリを上回り、next-intl や next-i18next の約 5 倍です。

Intlayer はモノレポのため、この数には各フレームワーク向けパッケージ、CLI、ドキュメントがすべて含まれます。コミット数は品質ではなく活動量の指標として捉えてください。

npm ダウンロード数

ダウンロード数が評価するのは最良のソリューションではなく、最も古いソリューションです。何年も前に公開されたライブラリは、当時それを選んだすべてのプロジェクト、すべての CI 実行、それに依存するすべてのパッケージによって今もインストールされ続けます。この数値は新たな選択よりも惰性を表しています。

AI アシスタントはこの効果をさらに強めます。next-intl、i18next、vue-i18n は学習元のコードに大量に含まれているため、AI は代替手段を比較することなく、それらをデフォルトで提案します。提案のたびにダウンロード数が増え、それが次の提案を後押しします。ダウンロード数ではなく、ベンチマークで比較してください。

結論

3つのライブラリはすべてReactのローカライズを効果的に行います。差別化のポイントは、安全でスケーラブルなセットアップを実現するためにどれだけのインフラストラクチャを構築する必要があるかです。

• Intlayerでは、モジュラーコンテンツ、厳格なTS型付け、ビルド時の安全性、ツリーシェイクされたバンドル、そして編集ツールがデフォルトであり、手間ではありません。
• チームが多言語対応でコンポーネント駆動のReactアプリにおいて、保守性と速度を重視するなら、Intlayerは今日最も完全な開発者およびコンテンツワークフローを提供します。

詳細は「なぜ Intlayer なのか？」ドキュメントを参照してください。