next-i18next VS next-intl VS intlayer | Next.jsの国際化（i18n）

本ガイドでは、Next.jsで広く使われている3つのi18nオプション、next-intl、next-i18next、およびIntlayerを比較します。
対象はNext.js 13+のApp Router（React Server Components対応）で、以下の点を評価します：

1. アーキテクチャとコンテンツの構成
2. TypeScriptと安全性
3. 翻訳欠落の取り扱い
4. ルーティングとミドルウェア
5. パフォーマンスと読み込み挙動
6. 開発者体験（DX）、ツールとメンテナンス
7. SEOと大規模プロジェクトのスケーラビリティ

要約: いずれのツールもNext.jsアプリのローカライズが可能です。もしコンポーネント単位のコンテンツ管理、厳格なTypeScript型、ビルド時の欠落キー検出、ツリーシェイク可能な辞書、そして一流のApp RouterとSEOヘルパーを求めるなら、Intlayerが最も包括的でモダンな選択肢です。

---

高レベルのポジショニング

• next-intl - 軽量でシンプルなメッセージフォーマットを提供し、Next.jsとの親和性が高いです。カタログは中央集権的に管理されることが多く、開発者体験はシンプルですが、安全性や大規模なメンテナンスは主にユーザーの責任となります。
• next-i18next - Next.js向けにラップされたi18next。成熟したエコシステムとプラグイン（例：ICU）による機能を備えていますが、設定が冗長になりがちで、プロジェクトが大きくなるにつれてカタログは中央集権化しやすいです。
• Intlayer - Next.js向けのコンポーネント中心のコンテンツモデル、厳格なTS型付け、ビルド時チェック、ツリーシェイク、組み込みのミドルウェアとSEOヘルパー、オプションのビジュアルエディター/CMS、およびAI支援翻訳を提供します。

---

機能の比較（Next.jsに特化）

---

詳細比較

1) アーキテクチャとスケーラビリティ

• next-intl / next-i18next: ロケールごとの集中型カタログ（i18nextではネームスペースも）をデフォルトとする。初期段階では問題なく機能するが、結合度が高まりキーの変更が頻繁になるにつれて、大きな共有領域となることが多い。
• Intlayer: コードと共に配置された コンポーネント単位（または機能単位）の辞書を推奨します。これにより認知負荷が軽減され、UIパーツの複製や移行が容易になり、チーム間の競合も減少します。未使用のコンテンツも自然に見つけやすく、削除しやすくなります。

重要な理由: 大規模なコードベースやデザインシステムのセットアップでは、モジュール化されたコンテンツの方がモノリシックなカタログよりもスケールしやすいです。

---

2) TypeScript と安全性

• next-intl: 安定した TypeScript サポートがありますが、キーはデフォルトで厳密に型付けされていません。安全性のパターンは手動で維持する必要があります。
• next-i18next: フックの基本的な型定義がありますが、厳密なキーの型付けには追加のツールや設定が必要です。
• Intlayer: コンテンツから厳密な型を生成します。IDEの自動補完やコンパイル時のエラーにより、デプロイ前にタイプミスやキーの欠落を検出します。

なぜ重要か: 強い型付けにより、失敗を右（ランタイム）ではなく左（CI/ビルド時）にシフトさせます。

---

3) 翻訳欠落の取り扱い

• next-intl / next-i18next: ランタイムのフォールバックに依存（例：キーやデフォルトロケールを表示）。ビルドは失敗しません。
• Intlayer: ビルド時検出により、ロケールやキーの欠落に対して警告/エラーを出します。

なぜ重要か: ビルド時にギャップを検出することで、本番環境での「謎の文字列」発生を防ぎ、厳格なリリースゲートに適合します。

---

4) ルーティング、ミドルウェア、URL戦略

• 3つとも、App Router上のNext.jsのローカライズルーティングに対応しています。
• Intlayer はさらに進んで、i18n ミドルウェア（ヘッダーやクッキーによるロケール検出）や、ローカライズされた URL や <link rel="alternate" hreflang="…"> タグを生成するための ヘルパー を提供します。

重要な理由: カスタムの接着層が減り、一貫した UX と クリーンな SEO をロケール間で実現します。

---

5) サーバーコンポーネント（RSC）との整合性

• すべてが Next.js 13+ をサポートしています。
• Intlayer は一貫した API と RSC 向けに設計されたプロバイダーで、サーバー/クライアントの境界 をスムーズにし、フォーマッターや t 関数をコンポーネントツリー間で渡す必要をなくします。

重要な理由: より明確なメンタルモデルと、ハイブリッドツリーにおけるエッジケースの減少を実現します。

---

6) パフォーマンスと読み込み挙動

• next-intl / next-i18next: namespacesやルートレベルの分割による部分的な制御が可能ですが、管理が甘いと未使用の文字列がバンドルされるリスクがあります。
• Intlayer: ビルド時にツリーシェイクを行い、辞書やロケールごとに遅延ロードします。未使用のコンテンツは配信されません。

なぜ重要か: 特に多言語サイトで、バンドルサイズが小さくなり、起動が速くなります。

---

7) DX（開発者体験）、ツール、メンテナンス

• next-intl / next-i18next: 通常、翻訳や編集ワークフローのために外部プラットフォームと連携します。
• Intlayer: 無料のビジュアルエディターとオプションのCMS（Git対応または外部化）を提供します。さらに、コンテンツ作成用のVSCode拡張機能や、独自のプロバイダーキーを使ったAI支援翻訳も備えています。

なぜ重要か: 運用コストを削減し、開発者とコンテンツ作成者間のフィードバックループを短縮します。

---

どのツールを選ぶべきか？

• next-intl を選ぶのは、最小限のソリューションを求めていて、集中管理されたカタログに慣れており、アプリが小規模から中規模の場合です。
• next-i18next を選ぶのは、i18nextのプラグインエコシステム（例：プラグインによる高度なICUルール）が必要で、チームがすでにi18nextを知っており、柔軟性のためにより多くの設定を受け入れられる場合です。
• Intlayer を選ぶのは、コンポーネント単位のコンテンツ管理、厳格なTypeScript、ビルド時の保証、ツリーシェイキング、およびルーティング/SEO/エディタツールが標準搭載されていることを重視し、特にNext.js App Routerや大規模でモジュール化されたコードベースに適している場合です。

---

実践的な移行ノート（next-intl / next-i18next → Intlayer）

• 機能ごとに開始：ルートやコンポーネントを一度に一つずつローカル辞書に移行します。
• 旧カタログを並行して維持：移行中の橋渡しとして使用し、一斉移行は避けます。
• 厳密なチェックを有効化：ビルド時の検出で早期にギャップを明らかにします。
• ミドルウェアとヘルパーを採用：サイト全体でロケール検出とSEOタグを標準化します。
• バンドルサイズを測定：未使用のコンテンツが削除されるため、バンドルサイズの削減が期待できます。

---

結論

3つのライブラリはすべてコアなローカリゼーションに成功しています。違いは、モダンな Next.js で堅牢でスケーラブルなセットアップを実現するためにどれだけの作業が必要かです：

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

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