なぜマルチ言語？
私はNBAユニフォームに関するニッチなコンテンツサイトを運営しています。バスケットボールはグローバルです――中国、日本、韓国、そしてラテンアメリカのファンが、同じユニフォームをそれぞれの言語で検索します。さらに4つのロケールを追加したことで、アクセス可能な検索トラフィックが一晩で5倍になりました。
しかし、60本以上の記事を4言語に手作業で翻訳する？ そんなことはできません。
スタック
- Next.js 16 App Router
- next-intl v4 ルーティングとメッセージ処理用
- MDX コンテンツ用
- Claude API 翻訳用
- カスタムパイプライン バッチ処理用
アーキテクチャ：ロケール優先のファイル構造
content/
├── en/
│ └── jerseys/
│ └── michael-jordan/
│ └── bulls-pinstripe.mdx
├── zh/
├── ja/
├── ko/
└── es/
各ロケールには独自のコンテンツディレクトリを用意します。英語版が正（source of truth）です。
next-intl によるルーティング
export const locales = ['en', 'zh', 'ja', 'ko', 'es'] as const;
export const routing = defineRouting({
locales,
defaultLocale: 'en',
localePrefix: 'as-needed',
});
as-needed プレフィックスは、英語のURLはきれいなままにしつつ、他のロケールにはそのプレフィックスを付けるという意味です。
翻訳パイプライン
私は、英語のMDXを読み取り、不足している翻訳を確認し、Claude APIに送信して、フロントマターを保持しながら翻訳済みファイルを書き込むバッチ翻訳ツールを作りました。
Hreflang：決定的に重要なSEOパーツ
各ページには、その翻訳先を指す alternates が必要です。ページのメタデータ内だけでなく、サイトマップにも両方で設定します。
コンテンツのフォールバック戦略
翻訳が欠けている場合は、適切に英語へフォールバックします。404は発生しません。
結果
- 英語の元記事 63本 → 5ロケールで合計267ページ
- 手作業の翻訳作業ゼロ
- ビルド時間：約45秒（全267ページ）
サイト：JerseyToMe
