next-intl対react-i18next対Lingui：2026年にどれを使うべきか

Next.jsのApp Routerプロジェクトならnext-intlを使いましょう。ReactのSPA、あるいは将来的に一つのフレームワークを超えて成長しそうなものにはreact-i18nextを使いましょう。エコシステムの規模よりもビルド時抽出と軽量なバンドルを重視するなら、Linguiを使いましょう。3つとも実行時のi18nライブラリであり、コンポーネントへ翻訳文を配信するだけで、どれもキーやロケールファイルを自動生成してはくれません。globalize.nowはAI搭載のローカライゼーションインフラで、あなたのコードベースからそれらのキーとカタログを生成し、この3つのライブラリすべてに対応しています。

この3つのライブラリは実際には何をしてくれるのでしょうか？

どれも同じランタイム上の課題を解決しています。キーとロケールを渡せば、正しく複数形化・書式化された文字列を返す、という課題です。これには、値の埋め込み、日付や数値の書式設定、ICU形式のメッセージによる複数形ルールも含まれます。

どれもやってくれないのが、翻訳文そのものを作ることです。ランタイムライブラリは、すでに存在するカタログを消費するだけです。コンポーネント内のユーザーに見える文字列をすべて見つけ出し、キーに置き換え、言語ごとのロケールファイルを埋めていく作業は、誰かがやらなければなりません。これはスタックの中の別のレイヤーであり、この2つのレイヤーを明確に分けて考えることが、この比較を理解する一番の近道です。ランタイムライブラリはちょうど1つだけ選ぶことになり、それはカタログを埋めるツール群と競合するものではありません。詳細は開発者ドキュメントでこの区分けについて解説しています。

next-intlを使うべきなのはどんな時ですか？

Next.jsのApp Routerを使っている時です。next-intlは3つの中で唯一、App Routerのプリミティブを前提に設計されたライブラリです\：非同期Server Components、ロケール対応のナビゲーションやルーティングヘルパー、メタデータAPIです。2026年9月時点でバージョン4にあり、週間npmダウンロード数は約500万件で、理論上だけでなく実際にも、新規Next.jsプロジェクトにおけるデフォルトの答えとなっています。

メッセージはICU MessageFormatに準拠しているため、複数形、性別、値の埋め込みは業界全体で使われている同じ標準に従います。ICU構文に馴染みがない方向けに、ICU MessageFormatのわかりやすい解説も用意しています。トレードオフは結合度の高さです\：next-intlはNext.js専用のライブラリなので、Next.jsから離れる際にはi18nレイヤーも一緒に移行することになります。

react-i18nextを使うべきなのはどんな時ですか？

Next.jsを使っていない場合、あるいは最大級のエコシステムを味方につけたい場合です。react-i18nextはi18nextのReactバインディングであり、週間npmダウンロード数は約1,400万件と、圧倒的な差でもっとも使われているReact i18nライブラリです。i18nextのコアは10年以上メンテナンスされ続けており、HTTP経由でカタログを読み込むバックエンド、言語検出、キャッシュ層、React以外のフレームワークバインディングなど、ほぼあらゆる用途のプラグインが揃っています。

これは、ほとんどのAIコーディングツールがデフォルトで選ぶライブラリでもあります。CursorやLovableに「Vite + Reactアプリに翻訳機能を追加して」と頼めば、ほぼ必ずi18nextの構成が返ってきます。このデフォルトの選択には理にかなった面もあります\：どこでも動きますし、そのJSONカタログ形式はエコシステムにおける共通語に最も近い存在だからです。トレードオフは、Server Components以前の時代に作られたものであるため、App Router上ではnext-intlより多くの配線が必要になり、特に対策をしない限り翻訳作業の多くがクライアント側で行われる点です。

Linguiが正しい選択になるのはどんな時ですか？

バンドルサイズとソースコードの書きやすさを何より重視する時です。2026年9月時点でメジャーバージョン6にあるLinguiは、コンパイラを主軸に据えたアプローチを取っています\：メッセージはマクロを使ってインラインで記述し、そのCLIがビルド時にそれらをカタログへ抽出します。コンパイル済みカタログはランタイムでの解析コストなしで配信されるため、バンドルに占めるi18nのコストを低く抑えられます。

Linguiはまた、カタログ形式としてgettextのPOファイルを標準採用しており、これはプロの翻訳者が何十年も扱ってきた形式です。週間ダウンロード数は約150万件で、react-i18nextより一桁少ないため、Stack Overflowでの回答やサードパーティ製プラグインは少なめだと考えておきましょう。Next.jsに限らずReact全般で動作しますが、react-i18next同様、next-intlのようにApp Routerのプリミティブを前提に組まれてはいません。

それぞれを一目で比較すると？

AI生成のコードベースにはどれを選ぶべきですか？

上記と同じくフレームワークで選んでください——ただし、AIが作るアプリでつまずくポイントはライブラリ選定そのものではありません。Cursor、Claude Code、Lovableはいずれも、どのi18nライブラリを導入していようとデフォルトではハードコードされた英語の文字列を生成し、エージェントがコンポーネントを編集するたびに、ライブラリをセットアップした後もそうした文字列を追加し続けてしまいます。

つまり本当に必要な段取りはこうです\：まずフレームワークが求めるランタイムライブラリを選び、そのうえで抽出とカタログの保守を独立した課題として解決するのです。Next.jsのケースについては、Cursorで作られたNext.jsアプリへi18nを追加するという記事でセットアップ全体を解説しており、Next.js統合ページでは、ランタイム側の配線を行う前にglobalize.nowがnext-intl向けにキーとロケールファイルをどう準備するかを取り上げています。

ランタイムライブラリを使っていても、ローカライゼーションインフラは依然として必要ですか？

はい。なぜなら、ライブラリはカタログを読み込むだけであり、そのカタログを作り維持する作業こそが時間を消費する部分だからです。globalize.nowはまさにそのレイヤーを担います\：リポジトリを接続すれば、コードベースを一度変換し、ハードコードされた文字列をキーに置き換え、ロケールファイルを生成します。この一度きりの変換の後は、プッシュのたびに、コミットで新たに追加されたカタログエントリを翻訳していきます。

出力はJSONまたはPOです——next-intlやi18nextの構成にはJSON、Lingui本来の形式にはPOという具合に、あなたのランタイムライブラリがすでに扱っている形でカタログが生成されます。アプリがすでに部分的なi18n設定を持っている場合にも対応しています\：globalize.nowは既存のi18nと共存します、置き換えるのではなく。プランと料金体系については料金ページをご覧ください。

3つのライブラリのどれも「間違った選択」ではありません。App Routerを使うならnext-intl、最大限のエコシステムが欲しいならreact-i18next、ビルド時抽出とPOカタログが欲しいならLinguiです。1つを選び、文字列をコンポーネントから切り離しておけば、あとはカタログのレイヤーが残りをやってくれます。