React/Next.jsプロジェクトで多言語対応（i18n）を実装する際、ライブラリ選びは最初の大きな分岐点です。選択を誤ると、後から移行するコストが膨大になります。

この記事では、2026年時点で最も広く使われている3つのi18nライブラリ――react-intl、next-intl、i18next（react-i18next）――を機能・パフォーマンス・学習コストの観点から徹底比較します。

i18nライブラリの役割と基本概念

i18nライブラリが解決する課題

i18n（Internationalization、国際化）ライブラリは、アプリケーションを複数の言語・地域に対応させるための基盤を提供します。具体的には以下の機能を担います。

ICU MessageFormatとは

i18nライブラリを比較する上で重要なのが、ICU（International Components for Unicode）MessageFormat への対応です。ICU MessageFormatは、複数形や性別による文の変化、ネストされた条件分岐を表現できる国際標準のフォーマットです。 

{count, plural,
  =0 {商品はありません}
  one {商品が{count}件あります}
  other {商品が{count}件あります}
}

3ライブラリの詳細比較

機能比較表

機能 react-intl next-intl i18next
フレームワーク React Next.js専用 フレームワーク非依存
ICU MessageFormat 完全対応 完全対応 プラグインで対応
複数形 ICU準拠 ICU準拠 独自 + ICUプラグイン
日付・数値フォーマット Intl API統合 Intl API統合 プラグインで対応
SSR/SSG対応 手動設定 ネイティブ next-i18nextで対応
App Router対応 手動設定 ネイティブ 設定が複雑
Server Components 非対応 対応 限定的
TypeScript型安全性 良い 優秀 良い
翻訳キーの補完 なし あり プラグインで対応
エコシステム FormatJS Next.js 巨大（200+プラグイン）
GitHubスター数 14k+ 3k+ 7k+（react-i18next）
npm週間DL数 1.5M+ 500k+ 4M+（i18next本体）

react-intlの特徴

react-intl（FormatJSの一部）は、ICU MessageFormatを完全にサポートする老舗のi18nライブラリです。

next-intlの特徴

next-intlは、Next.js専用に設計されたi18nライブラリです。App RouterとServer Componentsにネイティブ対応しています。

i18next（react-i18next）の特徴

i18nextは、フレームワーク非依存の汎用i18nライブラリです。react-i18nextでReactに対応し、next-i18nextでNext.jsにも対応します。

セットアップ手順の比較

react-intlのセットアップ

npm install react-intl
// messages/ja.json
{
  "greeting": "こんにちは、{name}さん",
  "items": "{count, plural, =0 {アイテムなし} other {{count}件のアイテム}}"
}

// App.tsx
import { IntlProvider, FormattedMessage } from 'react-intl';
import messages from './messages/ja.json';

function App() {
  return (
    <IntlProvider locale="ja" messages={messages}>
      <FormattedMessage id="greeting" values={{ name: 'ユーザー' }} />
    </IntlProvider>
  );
}

next-intlのセットアップ

npm install next-intl
// messages/ja.json
{
  "greeting": "こんにちは、{name}さん",
  "items": "{count, plural, =0 {アイテムなし} other {{count}件のアイテム}}"
}

// app/[locale]/layout.tsx
import { NextIntlClientProvider } from 'next-intl';

export default async function Layout({ children, params }) {
  const messages = (await import(`../../messages/${params.locale}.json`)).default;
  return (
    <NextIntlClientProvider locale={params.locale} messages={messages}>
      {children}
    </NextIntlClientProvider>
  );
}

// コンポーネントでの使用
import { useTranslations } from 'next-intl';

function MyComponent() {
  const t = useTranslations();
  return <p>{t('greeting', { name: 'ユーザー' })}</p>;
}

i18nextのセットアップ

npm install i18next react-i18next
// i18n.js
import i18n from 'i18next';
import { initReactI18next } from 'react-i18next';

i18n.use(initReactI18next).init({
  resources: {
    ja: {
      translation: {
        greeting: 'こんにちは、{{name}}さん',
        items_zero: 'アイテムなし',
        items_other: '{{count}}件のアイテム'
      }
    }
  },
  lng: 'ja',
  interpolation: { escapeValue: false }
});

// コンポーネントでの使用
import { useTranslation } from 'react-i18next';

function MyComponent() {
  const { t } = useTranslation();
  return <p>{t('greeting', { name: 'ユーザー' })}</p>;
}

パフォーマンスとバンドルサイズ

バンドルサイズの比較

ライブラリ minified + gzip 備考
react-intl 約40KB ICUパーサーを含む
next-intl 約15KB Server Components時はクライアント0KB
react-i18next + i18next 約25KB プラグイン追加で増加

ランタイムパフォーマンス

パフォーマンスの観点では、next-intlがServer Componentsを活用できるため最も有利です。翻訳処理をサーバー側で完了させ、クライアントにはレンダリング済みのHTMLを送信できます。

翻訳ファイルの読み込み戦略

大量の翻訳キーを持つプロジェクトでは、翻訳ファイルの読み込み戦略がパフォーマンスに直結します。

戦略 react-intl next-intl i18next
一括読み込み 対応 対応 対応
名前空間分割 手動 対応 ネイティブ
遅延読み込み 手動 自動 i18next-http-backend
ビルド時埋め込み Babel Plugin 対応 手動

プロジェクト別の選び方

Next.jsプロジェクト（App Router）

推奨: next-intl

App RouterとServer Componentsに最も最適化されたライブラリです。Next.jsで多言語サイトを構築する具体的な方法はNext.jsで多言語サイトを構築する方法で解説しています。

React SPA（Create React App / Vite）

推奨: react-intl または i18next

ICU MessageFormatを重視するならreact-intl、プラグインの豊富さと柔軟性を重視するならi18nextが適切です。

SaaSプロダクト

推奨: i18next

SaaSプロダクトでは翻訳キーが大量になるため、名前空間分割と遅延読み込みがネイティブで使えるi18nextが有利です。SaaS i18nの詳しい戦略はSaaSプロダクトのi18nガイドをご参照ください。

マーケティングサイト・コーポレートサイト

推奨: 翻訳サービス（blaid等）

マーケティングサイトやコーポレートサイトの場合、i18nライブラリを導入してコード内にすべてのテキストを翻訳キーとして管理するのは過剰な場合があります。コンテンツの変更頻度が高く、非エンジニアが更新する必要がある場合は特にそうです。

i18nライブラリは「アプリケーションのUI文言」の多言語化に最適化されています。「Webサイトのコンテンツ」の多言語化には、翻訳サービスのほうが適しているケースが多いです。

「もっと手軽に」マーケティングサイトの多言語化

i18nライブラリの限界

i18nライブラリは強力ですが、以下のような課題があります。

blaidによるアプローチ

blaidは、既存のWebサイトにスクリプトタグを1行追加するだけで多言語化を実現するサービスです。i18nライブラリとは根本的にアプローチが異なります。

項目 i18nライブラリ blaid
導入方法 コード修正 スクリプト1行追加
翻訳データ管理 JSONファイル クラウド（自動管理）
翻訳方法 手動（翻訳者に依頼） AI自動翻訳 + 手動編集
非エンジニアの運用 困難 管理画面で簡単
既存サイトへの導入 大規模リファクタリング コード変更不要
SEO対応 自前で実装 自動（hreflangタグ等）

多言語化の方法全般についてはウェブサイト多言語化の方法と費用比較もご覧ください。

まとめ

i18nライブラリの選択は、プロジェクトの技術スタックと要件に応じて決めるのがベストです。

プロジェクト 推奨ライブラリ 理由
Next.js（App Router） next-intl Server Components対応、最小バンドル
React SPA react-intl ICU標準準拠、安定性
SaaSプロダクト i18next 名前空間分割、巨大エコシステム
マルチフレームワーク i18next フレームワーク非依存
マーケティングサイト blaid等の翻訳サービス コード変更不要、運用が楽

SaaSプロダクトやWebアプリケーションの場合はi18nライブラリが必須ですが、マーケティングサイトやコーポレートサイトの場合は、blaidのような翻訳サービスを使うことでエンジニアリング工数をゼロにできます。まずは無料プランでお試しください。