Next.jsはReactベースのフレームワークとして、多くの企業サイトやWebアプリで採用されています。Next.jsサイトを多言語化するにはいくつかのアプローチがあり、プロジェクトの規模や要件によって最適な方法が異なります。
この記事では、Next.jsの多言語化における3つの主要なアプローチを比較し、それぞれのメリット・デメリットを解説します。
Next.jsの多言語化が必要なケース
- 海外ユーザー向けにサービスを展開したい
- インバウンド集客のためにコーポレートサイトを英語化したい
- SaaSプロダクトを国際展開したい
- 多言語ECサイトを構築したい
アプローチ1: next-intl / next-i18next(i18nライブラリ)
Next.js専用のi18nライブラリを使って、アプリケーション内部で多言語対応する方法です。
仕組み
- 各言語の翻訳ファイル(JSONまたはYAML)を用意
- コンポーネント内で翻訳関数を呼び出してテキストを表示
- App RouterまたはPages Routerのルーティングと統合
実装イメージ
// messages/ja.json
{
"hero.title": "Webサイトを瞬時に多言語化",
"hero.subtitle": "JavaScript1行で導入可能"
}
// messages/en.json
{
"hero.title": "Instantly multilingualize your website",
"hero.subtitle": "Deploy with a single line of JavaScript"
}
// コンポーネント内
const t = useTranslations('hero');
return <h1>{t('title')}</h1>;
メリット
- SSR/SSGで完全な多言語ページを生成 — SEOに最も強い
- 型安全 — TypeScriptとの統合が充実
-
ルーティング統合 —
/en/about,/ja/aboutが自動的に生成 - hreflangタグの自動生成 が可能
デメリット
- 全テキストの翻訳ファイルを手動で管理 する必要がある
- 開発コストが高い — 全コンポーネントにi18n対応が必要
- 翻訳ファイルの同期 — 日本語を更新したら翻訳ファイルも更新が必要
- 既存サイトへの導入が大変 — コードベース全体の改修が必要
向いているケース
- 新規開発のプロジェクト
- SaaSプロダクトの国際展開
- 開発リソースが十分にある場合
アプローチ2: App Routerのi18nルーティング
Next.js 13以降のApp Routerを使い、ルーティングレベルで多言語対応する方法です。
仕組み
app/[locale]/ディレクトリで言語別ルートを定義- ミドルウェアでロケール検出とリダイレクト
- Server Componentsで翻訳テキストをレンダリング
実装イメージ
app/
[locale]/
page.tsx
about/
page.tsx
layout.tsx
middleware.ts
メリット
- Next.jsのネイティブ機能 を活用できる
- Server Components対応 — クライアントバンドルを増やさない
- 柔軟なルーティング — 言語ごとにURLパスをカスタマイズ可能
デメリット
- 設定が複雑 — ミドルウェア、レイアウト、翻訳ロジックの統合が必要
- 翻訳テキストの管理 は別途必要
- 既存のPages Routerからの移行コスト が大きい
向いているケース
- Next.js 13+で新規開発する場合
- App Routerを既に使っている場合
アプローチ3: JavaScript埋め込み型翻訳(blaid)
Next.jsのコードを変更せず、JavaScriptを1行追加するだけで多言語化する方法です。
仕組み
_document.tsxまたはlayout.tsxに翻訳スクリプトを追加- ページ上のテキストをAIが自動検出・翻訳
- 翻訳結果はクラウドで管理、手動編集も可能
実装イメージ
// app/layout.tsx
export default function RootLayout({ children }) {
return (
<html lang="ja">
<head>
<script
dangerouslySetInnerHTML={{
__html: `
window.blaidTranslatorConfig = {
apiKey: 'your-api-key',
apiUrl: 'https://blaid.jp',
targetLanguages: ['en', 'ko', 'zh-CN'],
defaultLanguage: 'ja'
};
`
}}
/>
</head>
<body>
{children}
<script src="https://blaid.jp/js/blaid-translator.js" />
</body>
</html>
);
}
メリット
- 導入が最も簡単 — 既存コードの改修不要
- 翻訳の自動化 — テキスト検出から翻訳まで自動
- 手動編集可能 — AI翻訳の結果を修正できる
- 用語集機能 — 固有名詞や専門用語を統一管理
- 既存サイトにすぐ導入可能 — 新規・既存問わず
デメリット
- SEOはエクスポート方式 — SSR/SSGのような静的HTMLではなく、エクスポート機能で対応(多言語SEOの基本を参照)
- クライアントサイドレンダリング — 初回表示は日本語、その後翻訳に切り替わる
- 翻訳のカスタマイズ深度 — コンポーネント単位の細かい制御はi18nライブラリに劣る
向いているケース
- 既存のNext.jsサイトを素早く多言語化したい
- 開発リソースが限られている
- まず効果を検証してから本格導入を判断したい
3つのアプローチ比較表
| 比較項目 | next-intl | App Router i18n | blaid |
|---|---|---|---|
| 導入の手軽さ | 難しい | 難しい | 非常に簡単 |
| 既存サイトへの導入 | 大改修が必要 | 大改修が必要 | コード追加のみ |
| SEO対応 | 最強(SSR/SSG) | 最強(SSR/SSG) | エクスポート機能 |
| 翻訳方式 | 手動(JSONファイル) | 手動 | AI自動 + 手動修正 |
| 翻訳管理 | コードベース内 | コードベース内 | クラウドCMS |
| 開発コスト | 高 | 高 | 低 |
| 型安全性 | TypeScript対応 | TypeScript対応 | - |
| 初回表示 | 翻訳済みHTML | 翻訳済みHTML | 日本語→翻訳切替 |
| 用語集 | 手動管理 | 手動管理 | 機能あり |
選び方のガイド
Q: 新規開発で、開発リソースが十分にある? → next-intl または App Router i18n がベスト
Q: 既存のNext.jsサイトを素早く多言語化したい? → blaid がベスト。コード改修不要で即日導入可能
Q: まず効果を検証してから判断したい? → blaid の無料プランで試し、効果が確認できたらi18nライブラリへの移行も検討
Q: SaaSプロダクトで本格的な国際展開? → next-intl がベスト。長期的にはi18nライブラリの方がメンテナブル
まとめ
Next.jsの多言語化は、プロジェクトの状況によって最適解が異なります。
- 新規開発・十分な開発リソース → next-intl / App Router i18n
- 既存サイト・素早く多言語化 → blaid
- 効果検証フェーズ → blaid → 検証後にi18nライブラリへ移行
blaidなら無料プランでNext.jsサイトの多言語化をすぐに試せます。まずは効果を確認してから、本格的なi18n対応を判断するのが最も合理的なアプローチです。