はじめに
「i18nの実装を後から追加しようとしたらコードが複雑になりすぎた」
「翻訳ファイルの管理が煩雑で、追加のたびに手間がかかる」
「日付・数値・複数形の対応が言語ごとに違って実装が難しい」
多言語対応は後から追加しようとすると大規模なリファクタリングが必要になります。Claude Codeを使えば、初期設計から翻訳ファイルの生成・ロケール対応の実装まで効率的に進められます。
目次
- i18nとl10nの設計方針
- Next.jsでのi18n実装(next-intl)
- 翻訳ファイルの管理
- 日付・数値・複数形の対応
- 既存コードへのi18n追加
- RTLレイアウトの対応
- 翻訳の自動化と品質管理
- まとめ
1. i18nとl10nの設計方針
設計の相談
> このWebアプリの多言語対応設計をしてください。
対応言語:日本語(デフォルト)・英語・中国語(簡体字)・韓国語
フレームワーク:Next.js 14(App Router)
設計の判断材料:
- URLでロケールを管理する方法(/ja/・/en/)vs Acceptヘッダー
- クライアントサイド vs サーバーサイドでの翻訳
- 翻訳ファイルのフォーマット(JSON・YAML・PO)
- 翻訳管理サービスの利用(Crowdin・Phrase・Transifex)
推奨アーキテクチャと理由を説明してください。
2. Next.jsでのi18n実装(next-intl)
next-intlの設定
> next-intlを使ってNext.js App RouterのアプリにI18nを実装してください。
設定内容:
- middleware.tsによるルーティング設定
- ロケールプレフィックスのURL設定(/ja/・/en/)
- サーバーコンポーネントでの翻訳取得
- クライアントコンポーネントでの翻訳取得
- 言語切り替えコンポーネント
- デフォルト言語のリダイレクト
ロケール検出の優先順位:
1. URLパス(/ja/・/en/)
2. Cookieに保存されたユーザー設定
3. Accept-Languageヘッダー
4. デフォルト(日本語)
翻訳キーの設計
> このアプリの翻訳ファイル構造を設計してください。
設計方針:
- 画面ごとにファイルを分ける(pages/home.json・pages/checkout.json)
- 共通UIは別ファイル(common/buttons.json・common/errors.json)
- ネストは最大2階層まで
現在のJSX内のハードコードされた日本語テキストを
すべて翻訳キーに置き換えてください。
[JSXファイルを貼り付け]
3. 翻訳ファイルの管理
翻訳ファイルの自動生成
> 日本語の翻訳ファイルをベースに、
以下の言語の翻訳ファイルを自動生成してください。
対象言語:英語・中国語(簡体字)・韓国語
生成方法:
- Claude Codeが直接翻訳(機械翻訳として)
- 文化的に適切な表現に調整
- 翻訳メモリとして過去の翻訳を再利用
ネイティブスピーカーによる確認が必要な箇所を
コメントでマークしてください。
[messages/ja.jsonを貼り付け]
翻訳の欠落検出
> 翻訳ファイルの品質チェックスクリプトを作成してください。
チェック内容:
- 日本語ファイルにあるキーが他言語に存在するか
- 翻訳されていない(日本語そのままの)値の検出
- 変数プレースホルダー({name}等)の整合性チェック
- CI/CDで自動実行できるようにする
4. 日付・数値・複数形の対応
ロケール対応の実装
> 以下のロケール依存の表示をIntl APIを使って実装してください。
日付のフォーマット:
- 日本語:2026年6月7日(土)
- 英語:Saturday, June 7, 2026
- 中国語:2026年6月7日 星期六
数値のフォーマット:
- 通貨:¥1,234(日本)・$12.34(米国)・¥12(中国)
- パーセント:50.5%(日本)・50.5%(英語)
- 大きな数値:1,234,567(英語)・1,234,567(日本)
next-intlのuseFormatter・useTranslationsを使って実装してください。
複数形(Plural Rules)の実装
> 複数形の対応を実装してください。
例:
- 英語:1 item / 2 items
- 日本語:1件 / 2件(複数形なし)
- アラビア語:6種類の複数形がある
next-intlのICUメッセージ形式を使って、
以下のケースを実装してください:
- アイテム数の表示
- 残り日数の表示
- 人数の表示
5. 既存コードへのi18n追加
ハードコードされたテキストの一括抽出
> このNext.jsアプリのすべてのJSX・TSXファイルから
ハードコードされた日本語テキストを抽出して、
翻訳ファイルとi18n対応コードに変換してください。
変換の方針:
- テキストを適切な翻訳キーに変換(button.submit・error.notFound等)
- useTranslations・getTranslationsへの置き換え
- 変数を含む文字列のICUメッセージ形式への変換
- messages/ja.jsonへの追加
変換後はビルドが通ることを確認してください。
6. RTLレイアウトの対応
アラビア語・ヘブライ語向けRTL対応
> このアプリにRTL(右から左)言語のサポートを追加してください。
対応言語:アラビア語・ヘブライ語
実装内容:
- HTML dir属性の動的設定
- TailwindのRTLプラグイン設定
- RTL対応が必要なCSSプロパティの修正
(margin-left → margin-inline-start等)
- アイコン・矢印の反転
- フォームの入力方向の設定
既存のLTRデザインを崩さずにRTLを追加してください。
7. 翻訳の自動化と品質管理
CI/CDへの翻訳チェック組み込み
> PRごとに翻訳ファイルの品質をチェックする
GitHub Actionsを設定してください。
チェック内容:
- 新しく追加した翻訳キーがすべての言語ファイルに存在するか
- プレースホルダーの整合性
- JSONの構文エラー
- 翻訳が欠落している場合はPRコメントで警告
翻訳サービス(Crowdin)との自動同期設定も含めてください。
8. まとめ
Claude Codeでのi18n実装の効率化ポイント:
- 既存コードからハードコードテキストを一括抽出・翻訳ファイルに変換
- 日本語ベースの翻訳ファイルから他言語版を自動生成
- 日付・数値・複数形のロケール対応を正確に実装
- RTLレイアウトの追加を既存デザインを崩さずに実施
i18n導入のベストプラクティス:
- 最初からi18n設計で開発する(後付けは大変)
- 翻訳キーはドット記法で階層化する
- 翻訳ファイルはGitで管理してCIでチェックする
- ネイティブスピーカーによる最終確認は省略しない
次回の第48回:gRPCを実装する方法では、Protocol Buffersからサービス間通信まで自動構築する手順を解説します。
よくある質問(FAQ)
Q. 機械翻訳(Claude)の品質はどの程度使えますか?
A. 一般的なUIテキスト(ボタン・エラーメッセージ・ラベル)は実用レベルです。マーケティングコピーや法的文書はネイティブスピーカーによる確認を推奨します。Claude Codeに「翻訳後にネイティブによる確認が特に必要な箇所にコメントをつけてください」と依頼できます。
この記事はClaude Code入門シリーズ(第5部)の第47回です。← 第46回:メール配信システム | 第48回:gRPC →
ご質問はお問い合わせページからお気軽にどうぞ。