このページとあなたの好きなAIアシスタントを使ってドキュメントを要約します
バージョン履歴
- 初版v7.0.62025/11/1
このページのコンテンツはAIを使用して翻訳されました。
英語の元のコンテンツの最新バージョンを見るこのドキュメントを改善するアイデアがある場合は、GitHubでプルリクエストを送信することで自由に貢献してください。
ドキュメントへのGitHubリンクドキュメントのMarkdownをクリップボードにコピー
2025年版 next-i18nextを使ったNext.jsアプリケーションの国際化方法
目次
next-i18nextとは?
next-i18nextは、Next.jsアプリケーション向けの人気のある国際化(i18n)ソリューションです。元々のnext-i18nextパッケージはPages Router向けに設計されていましたが、本ガイドでは、最新のApp Routerでi18nextとreact-i18nextを直接使用してi18nextを実装する方法を紹介します。
このアプローチにより、以下が可能になります:
- 名前空間を使った翻訳の整理(例:
common.json、about.json)によるコンテンツ管理の向上。 - 必要な名前空間のみをページごとに読み込むことで翻訳を効率的にロードし、バンドルサイズを削減。
- サーバーコンポーネントとクライアントコンポーネントの両方をサポートし、適切なSSRとハイドレーションを実現。
- TypeScriptサポートの確保により、型安全なロケール設定と翻訳キーを実現。
- 適切なメタデータ、サイトマップ、robots.txtの国際化によりSEOを最適化。
代替として、next-intlガイドや、直接Intlayerを参照することもできます。
比較は next-i18next vs next-intl vs Intlayerをご覧ください。
これらのライブラリがどのように生まれたのかを知るには、JavaScript i18n の歴史をご覧ください。
ベンチマークから見た Next.js での next-i18next
セットアップに入る前に、i18n ライブラリがパフォーマンスと bundle に与える影響を理解しておくことが重要です。i18n ベンチマークでは、10 ページ・10 ロケールの同じ Next.js アプリケーションを主要な i18n ライブラリで実行し、実際の bundle サイズ、文字列の漏れ、ハイドレーションのオーバーヘッドを計測しています。
指標
動的な JSON 読み込み
実行時に翻訳を遅延読み込みします
スコープ付き JSON (ネームスペース)
ページごとの翻訳ネームスペース
この指標は何ですか?
国際化ライブラリバンドルの合計gzip圧縮サイズ。これには、ツリーシェイキングと縮小化(minification)後のプロバイダーとコンテンツ取得ロジックのみが含まれます。
なぜ重要なのか?
ライブラリのサイズが小さければ初期 JavaScript ペイロードが削減され、クライアント側でのダウンロードと実行が高速化されます।
表示形式
Next.js における next-i18next の主要な数値(gzip):
テーブルをモーダルで開き、すべてのデータを明確に表示
| 構成 | ライブラリサイズ | ページ JS 平均 | 他ロケールの漏れ | 他ページの漏れ |
|---|---|---|---|---|
| ベース(i18n なし) | - | 141.0 KB | 0.0% | 0.0% |
next-i18next | 19.7 KB | 169.5 KB | 50.0% | 89.8% |
@intlayer/next-i18next (compat) | 9.4 KB | 150.7 KB | 0.0% | 0.0% |
next-intlayer (ネイティブ Intlayer) | 5.5 KB | 141.3 KB | 0.0% | 0.0% |
ポイント:
- namespace の分割は必須: 単純な構成では、
next-i18nextはすべての namespace をすべてのページに送信します(ページ間の漏れ ~89.8%)。ルートごとに namespace を分割して lazy loading すればページ JS は減りますが、慎重な手動管理が必要です。 - runtime の重さ:
i18nextのクライアント runtime は各ページで ~19.7 KB gzip あります。既存の codebase では、互換アダプター@intlayer/next-i18nextが同じi18nextAPI を保ったまま runtime を 9.4 KB に縮小し、漏れをなくします。ネイティブのnext-intlayerなら 5.5 KB まで下がります。
全データはこちら: Next.js ベンチマークレポート、およびベンチマークリポジトリ。
Next.js での機能比較
Next.js App Router プロジェクトで通常必要になる機能について、next-i18next を next-intl および Intlayer と比較します:
テーブルをモーダルで開き、すべてのデータを明確に表示
| 機能 | next-intlayer (Intlayer) | next-intl | next-i18next |
|---|---|---|---|
| コンポーネントの近くに翻訳を配置 | ✅ 各コンポーネントと同じ場所にコンテンツを配置 | ❌ 集中管理された JSON | ❌ 集中管理された JSON |
| TypeScript 統合 | ✅ 自動生成される厳密な型 | ✅ 良好、AppConfig の augmentation 経由 | ⚠️ 基本的 |
| 翻訳漏れの検出 | ✅ TypeScript エラーとビルド時の警告 | ⚠️ 実行時のフォールバック | ⚠️ 実行時のフォールバック |
| リッチコンテンツ(JSX、Markdown) | ✅ 直接サポート | ⚠️ t.rich によるタグ、Markdown なし | ⚠️ <Trans> によるタグ |
| AI 翻訳 | ✅ 独自のプロバイダーと API キー、アプリのコンテキスト付き | ❌ なし | ❌ なし |
| ビジュアルエディター / CMS | ✅ ローカルのビジュアルエディター + 任意の CMS | ❌ 外部プラットフォーム経由 | ❌ 外部プラットフォーム経由 |
| ローカライズされたルーティング | ✅ 組み込み(Next.js と Vite) | ✅ 組み込みの [locale] セグメント | ✅ 組み込み |
| 複数形 | ✅ 列挙ベース | ✅ ICU | ✅ 接尾辞ベース(_one、_other) |
| フォーマット(日付、数値、通貨) | ✅ Intl ベースのフォーマッター | ✅ useFormatter | ✅ Intl ベース |
| コンテンツ形式 | ✅ .ts, .tsx, .js, .json, .md, .yaml | ✅ .json, .js, .ts | ⚠️ .json |
| ICU MessageFormat | ✅ format: "icu" 経由 | ✅ ネイティブ | ⚠️ i18next-icu 経由 |
| SEO ヘルパー(hreflang、sitemap) | ✅ metadata、sitemap、robots.txt のヘルパー | ✅ 良好 | ✅ 良好 |
| Server Components | ✅ どの Server Component でも直接アクセス | ⚠️ コンポーネントごとに t または await getTranslations() を渡す | ⚠️ コンポーネントツリーに t を渡していく |
| コンポーネント単位の tree-shaking | ✅ ビルド時(Babel / SWC) | ⚠️ 手動、ルートごとに pick() | ⚠️ 手動、ルートごとに namespace |
| Lazy loading | ✅ ロケール単位および辞書単位 | ✅ ロケール単位、namespace は手動管理 | ✅ ロケール単位、namespace は手動管理 |
| runtime サイズ(gzip、ベンチマーク) | 4.9 KB | 14.7 KB | 19.7 KB |
| CI での翻訳漏れ検出 | ✅ npx intlayer test | ⚠️ 組み込みなし | ⚠️ 組み込みなし、実行時に saveMissing |
| エコシステム / コミュニティ | ⚠️ 小規模、急成長中 | ✅ 大規模 | ✅ 非常に大規模 |
runtime サイズは Next.js ベンチマークによるものです。詳しい解説は next-i18next vs next-intl vs Intlayer をご覧ください。
実装前に守るべきプラクティス
実装に入る前に、以下のプラクティスを守ってください:
- HTMLの
langとdir属性を設定する レイアウト内で、getLocaleDirection(locale)を使用してdirを計算し、適切なアクセシビリティとSEOのために<html lang={locale} dir={dir}>を設定します。 - 名前空間ごとにメッセージを分割する
ロードする必要のあるものだけを読み込むために、ロケールと名前空間ごとにJSONファイルを整理します(例:
common.json、about.json)。 - クライアントのペイロードを最小化する
ページでは、必要な名前空間のみを
NextIntlClientProviderに送信します(例:pick(messages, ['common', 'about']))。 - 静的ページを優先する パフォーマンスとSEOの向上のために、できるだけ静的ページを使用します。
- サーバーコンポーネントでの国際化
ページや
clientとマークされていないすべてのコンポーネントのようなサーバーコンポーネントは静的であり、ビルド時にプリレンダリングできます。そのため、翻訳関数をプロップとして渡す必要があります。 - TypeScriptの型を設定する アプリケーション全体で型の安全性を確保するために、ロケール用のTypeScript型を設定します。
- リダイレクト用のプロキシ プロキシを使用してロケールの検出とルーティングを処理し、ユーザーを適切なロケール接頭辞付きURLにリダイレクトします。
- メタデータ、サイトマップ、robots.txtの国際化
Next.jsが提供する
generateMetadata関数を使用して、メタデータ、サイトマップ、robots.txtを国際化し、すべてのロケールで検索エンジンによるより良い検出を確保します。 - リンクのローカライズ
Linkコンポーネントを使ってリンクをローカライズし、ユーザーを適切なロケール接頭辞付きURLにリダイレクトします。これはすべてのロケールでページの検出を確実にするために重要です。 - テストと翻訳の自動化 テストと翻訳の自動化は、多言語アプリケーションのメンテナンスにかかる時間を削減するのに役立ちます。
国際化とSEOに関して知っておくべきすべてをまとめたドキュメントはこちらをご覧ください: next-intlによる国際化 (i18n)。
Next.jsアプリケーションでi18nextをセットアップするステップバイステップガイド
GitHubのApplication Templateをご覧ください。
これから作成するプロジェクト構成は以下の通りです:
コードをクリップボードにコピー
依存関係のインストール
必要なパッケージをnpmを使ってインストールします:
bashコードをコピーコードをクリップボードにコピー
- i18next: 翻訳の読み込みと管理を行う国際化のコアフレームワークです。
- react-i18next: i18nextのReactバインディングで、クライアントコンポーネント向けに
useTranslationのようなフックを提供します。 - i18next-resources-to-backend: 翻訳ファイルの動的読み込みを可能にするプラグインで、必要な名前空間だけをロードできます。
プロジェクトの設定
サポートするロケール、デフォルトロケール、およびURLのローカライズ用ヘルパー関数を定義する設定ファイルを作成します。このファイルはi18n設定の単一の真実の情報源として機能し、アプリケーション全体で型安全性を保証します。
ロケール設定を一元化することで不整合を防ぎ、将来的にロケールの追加や削除を容易にします。ヘルパー関数はSEOやルーティングのために一貫したURL生成を保証します。
i18n.config.tsコードをコピーコードをクリップボードにコピー
翻訳ネームスペースの集中管理
アプリケーションが公開するすべてのnamespaceの単一の真実のソースを作成します。このリストを再利用することで、サーバー、クライアント、およびツールのコードが同期され、翻訳ヘルパーの強力な型付けが可能になります。
src/i18n.namespaces.tsコードをコピーコードをクリップボードにコピー
TypeScriptで翻訳キーを強く型付けする
i18nextを拡張して、標準の言語ファイル(通常は英語)を指すようにします。これによりTypeScriptはnamespaceごとの有効なキーを推論し、t()の呼び出しがエンドツーエンドで検証されます。src/types/i18next.d.tsコードをコピーコードをクリップボードにコピー
ヒント: この宣言は
src/typesフォルダ内に保存してください(存在しない場合はフォルダを作成してください)。Next.js はすでにtsconfig.jsonにsrcを含めているため、この拡張は自動的に認識されます。もし認識されない場合は、tsconfig.jsonに以下を追加してください:tsconfig.jsonコードをコピーコードをクリップボードにコピー
これにより、オートコンプリートやコンパイル時の型チェックが利用可能になります:
tsxコードをコピーコードをクリップボードにコピー
サーバーサイドの i18n 初期化を設定する
サーバーコンポーネントのために翻訳を読み込むサーバーサイド初期化関数を作成します。この関数はサーバーサイドレンダリング用に別のi18nextインスタンスを作成し、レンダリング前に翻訳が読み込まれていることを保証します。
サーバーコンポーネントはクライアントコンポーネントとは異なるコンテキストで動作するため、独自のi18nextインスタンスが必要です。サーバーで翻訳を事前に読み込むことで、未翻訳のコンテンツが一瞬表示されるフラッシュを防ぎ、検索エンジンが翻訳済みのコンテンツを認識できるためSEOが向上します。
src/app/i18n/server.tsコードをコピーコードをクリップボードにコピー
クライアントサイドのi18nプロバイダーを作成する
i18nextコンテキストでアプリケーションをラップするクライアントコンポーネントプロバイダーを作成します。このプロバイダーはサーバーから事前に読み込まれた翻訳を受け取り、未翻訳コンテンツのフラッシュ(FOUC)を防ぎ、重複フェッチを回避します。
クライアントコンポーネントはブラウザで動作する独自のi18nextインスタンスが必要です。サーバーから事前に読み込まれたリソースを受け入れることで、シームレスなハイドレーションを保証し、コンテンツのフラッシュを防ぎます。このプロバイダーはロケールの変更や名前空間の動的読み込みも管理します。
src/components/I18nProvider.tsxコードをコピーコードをクリップボードにコピー
動的ロケールルートの定義
アプリフォルダ内に
[locale]ディレクトリを作成して、ロケールの動的ルーティングを設定します。これにより、Next.jsは各ロケールをURLのセグメントとして扱うことができるようになります(例:/en/about、/fr/about)。動的ルートを使用することで、Next.jsはビルド時にすべてのロケールの静的ページを生成でき、パフォーマンスとSEOが向上します。レイアウトコンポーネントはロケールに基づいてHTMLの
langとdir属性を設定し、アクセシビリティと検索エンジンの理解に重要な役割を果たします。src/app/[locale]/layout.tsxコードをコピーコードをクリップボードにコピー
翻訳ファイルを作成する
各ロケールと名前空間ごとにJSONファイルを作成します。この構造により、翻訳を論理的に整理し、各ページで必要なものだけを読み込むことができます。
名前空間(例:
common.json、about.json)ごとに翻訳を整理することで、コード分割が可能になり、バンドルサイズを削減できます。これにより、各ページに必要な翻訳のみを読み込むため、パフォーマンスが向上します。src/locales/en/common.jsonコードをコピーコードをクリップボードにコピー
src/locales/fr/common.jsonコードをコピーコードをクリップボードにコピー
src/locales/en/home.jsonコードをコピーコードをクリップボードにコピー
src/locales/fr/home.jsonコードをコピーコードをクリップボードにコピー
src/locales/en/about.jsonコードをコピーコードをクリップボードにコピー
src/locales/fr/about.jsonコードをコピーコードをクリップボードにコピー
ページで翻訳を利用する
i18nextをサーバー上で初期化し、翻訳をサーバーコンポーネントとクライアントコンポーネントの両方に渡すページコンポーネントを作成します。これにより、レンダリング前に翻訳が読み込まれ、コンテンツのフラッシュを防止できます。
サーバーサイドの初期化は、ページがレンダリングされる前に翻訳を読み込み、SEOの向上とFOUC(Flash of Unstyled Content)の防止に役立ちます。事前に読み込んだリソースをクライアントプロバイダーに渡すことで、重複したフェッチを避け、スムーズなハイドレーションを実現します。
src/app/[locale]/about/index.tsxコードをコピーコードをクリップボードにコピー
クライアントコンポーネントでの翻訳の使用
クライアントコンポーネントでは、
useTranslationフックを使用して翻訳にアクセスできます。このフックは翻訳関数とi18nインスタンスへのアクセスを提供し、コンテンツの翻訳やロケール情報の取得を可能にします。クライアントコンポーネントは翻訳にアクセスするためにReactフックを必要とします。
useTranslationフックはi18nextとシームレスに統合され、ロケールが変更された際にリアクティブな更新を提供します。ページやプロバイダーには必要な名前空間のみを含めるようにしてください(例:
about)。
Reactのバージョンが19未満の場合は、Intl.NumberFormatのような重いフォーマッターをメモ化してください。src/components/ClientComponent.tsxコードをコピーコードをクリップボードにコピー
サーバーコンポーネントでの翻訳の使用
サーバーコンポーネントはReactのフックを使用できないため、親コンポーネントからprops経由で翻訳を受け取ります。この方法により、サーバーコンポーネントは同期的に保たれ、クライアントコンポーネント内にネストすることが可能になります。
クライアント境界内にネストされる可能性のあるサーバーコンポーネントは同期的である必要があります。翻訳済みの文字列とロケール情報をpropsとして渡すことで、非同期操作を避け、適切なレンダリングを保証します。
src/components/ServerComponent.tsxコードをコピーコードをクリップボードにコピー
コンテンツの言語を変更する
オプションNext.jsでコンテンツの言語を変更する推奨方法は、ロケール接頭辞付きのURLとNext.jsのリンクを使用することです。以下の例では、現在のロケールをルートから読み取り、パス名からそれを取り除き、利用可能な各ロケールごとにリンクをレンダリングします。
src/components/LocaleSwitcher.tsxコードをコピーコードをクリップボードにコピー
ローカライズされたLinkコンポーネントの作成
オプションアプリ全体でローカライズされたURLを再利用することで、ナビゲーションの一貫性を保ち、SEOにも効果的です。
next/linkをラップし、内部ルートにはアクティブなロケールをプレフィックスとして付け、外部URLはそのままにする小さなヘルパーを作成しましょう。src/components/LocalizedLink.tsxコードをコピーコードをクリップボードにコピー
ヒント:
LocalizedLinkはドロップイン置換なので、インポートを差し替えてコンポーネントにロケール固有のURL処理を任せる形で段階的に移行できます。サーバーアクション内でアクティブなロケールにアクセスする
オプションサーバーアクションでは、メール送信やログ記録、サードパーティ連携のために現在のロケールが必要になることが多いです。プロキシで設定されたロケールクッキーと、フォールバックとしての
Accept-Languageヘッダーを組み合わせて使用します。src/app/actions/get-current-locale.tsコードをコピーコードをクリップボードにコピー
このヘルパーは Next.js のクッキーとヘッダーに依存しているため、Route Handlers、Server Actions、その他のサーバー専用コンテキストで動作します。
メタデータの国際化
オプションコンテンツの翻訳は重要ですが、国際化の主な目的はあなたのウェブサイトを世界により見えるようにすることです。I18n は適切な SEO を通じてウェブサイトの可視性を向上させるための強力な手段です。
適切に国際化されたメタデータは、検索エンジンがページで利用可能な言語を理解するのに役立ちます。これには、hreflang メタタグの設定、タイトルや説明の翻訳、各ロケールに対して正しいカノニカル URL の設定が含まれます。
多言語 SEO に関するベストプラクティスのリストは以下の通りです:
<head>タグ内にhreflangメタタグを設定して、検索エンジンがページで利用可能な言語を理解できるようにしますhttp://www.w3.org/1999/xhtmlXMLスキーマを使用して、sitemap.xmlにすべてのページ翻訳をリストします- プレフィックス付きページをrobots.txtから除外するのを忘れないでください(例:
/dashboard、/fr/dashboard、/es/dashboard) - カスタムLinkコンポーネントを使用して、最もローカライズされたページにリダイレクトします(例:フランス語では
<a href="/fr/about">À propos</a>)
開発者はしばしばロケール間でページを適切に参照することを忘れがちです。これを修正しましょう:
src/app/[locale]/about/layout.tsxコードをコピーコードをクリップボードにコピー
サイトマップの多言語対応
オプションすべてのロケールバージョンのページを含むサイトマップを生成します。これにより、検索エンジンがすべての言語バージョンのコンテンツを検出し、インデックス化しやすくなります。
適切に多言語対応されたサイトマップは、検索エンジンがすべての言語バージョンのページを見つけてインデックス化できるようにし、国際的な検索結果での可視性を向上させます。
src/app/sitemap.tsコードをコピーコードをクリップボードにコピー
robots.txtの多言語対応
オプション保護されたルートのすべてのロケールバージョンを適切に処理するrobots.txtファイルを作成します。これにより、検索エンジンが管理者ページやダッシュボードページをどの言語でもインデックスしないようにします。
すべてのロケールに対してrobots.txtを適切に設定することで、検索エンジンが機密ページをどの言語でもインデックスするのを防ぎます。これはセキュリティとプライバシーのために非常に重要です。
src/app/robots.tsコードをコピーコードをクリップボードにコピー
ロケールルーティングのためのミドルウェア設定
オプションユーザーの好みのロケールを自動的に検出し、適切なロケール接頭辞付きURLにリダイレクトするプロキシを作成します。これにより、ユーザーは自分の好みの言語でコンテンツを閲覧でき、ユーザー体験が向上します。
ミドルウェアは、ユーザーがサイトを訪れた際に自動的に好みの言語にリダイレクトし、さらに将来の訪問のためにその言語設定をクッキーに保存します。
src/proxy.tsコードをコピーコードをクリップボードにコピー
Intlayerを使った翻訳の自動化
オプションIntlayerは、アプリケーションのローカリゼーションプロセスを支援するために設計された無料かつオープンソースのライブラリです。i18nextが翻訳の読み込みと管理を担当する一方で、Intlayerは翻訳ワークフローの自動化を支援します。
翻訳を手動で管理することは時間がかかり、ミスが発生しやすい作業です。Intlayerは翻訳のテスト、生成、管理を自動化し、時間を節約するとともに、アプリケーション全体での一貫性を確保します。
Intlayerが可能にすること:
コードベース内の好きな場所でコンテンツを宣言する Intlayerは、
.content.{ts|js|json}ファイルを使用して、コードベース内の好きな場所でコンテンツを宣言することを可能にします。これにより、コンテンツの整理が向上し、コードベースの可読性と保守性が高まります。翻訳の欠落をテストする Intlayerは、CI/CDパイプラインやユニットテストに統合可能なテスト機能を提供します。詳細は翻訳のテストをご覧ください。
翻訳の自動化
Intlayerは翻訳を自動化するためのCLIとVSCode拡張機能を提供します。これらはCI/CDパイプラインに統合可能です。詳細は翻訳の自動化についてをご覧ください。
ご自身のAPIキーやお好みのAIプロバイダーを使用できます。また、コンテキストに応じた翻訳も提供しています。詳細はコンテンツの自動補完をご覧ください。外部コンテンツの接続
Intlayerはコンテンツを外部のコンテンツ管理システム(CMS)に接続することを可能にします。最適化された方法で取得し、JSONリソースに挿入します。詳細は外部コンテンツの取得をご覧ください。ビジュアルエディター
Intlayerは無料のビジュアルエディターを提供しており、視覚的にコンテンツを編集できます。詳細は翻訳のビジュアル編集をご覧ください。
その他にも多数の機能があります。Intlayerが提供するすべての機能については、Intlayerの利点に関するドキュメントをご参照ください。
詳細なパフォーマンスベンチマークと比較については、以下を参照してください:
コメント
まだコメントはありません。最初のコメントを共有しましょう。
