【2026】国際化i18n対応をClaude Codeで進める実践ガイド

結論：i18n対応は「文言の外部化」と「翻訳の人間レビュー」をClaude Codeで分業すると速い

Webアプリやサービスの国際化（i18n / internationalization）は、地味に時間を食う作業の代表格です。ボタンのラベル、エラーメッセージ、メール文面……アプリのあちこちに直書きされた文言を一つずつ外部ファイルへ移し、翻訳キーを設計し、複数形や日付の表記まで気を配る。手作業でやると数日、規模が大きければ数週間かかります。

ここでClaude Codeが効くのは、「ハードコードされた文言の機械的な洗い出し」と「翻訳キーへの置き換え」という、量が多くて単調だけれどミスが許されない作業です。一方で翻訳の品質判断は人間が握るのが鉄則。この記事では、現状把握から実装、翻訳管理、そして落とし穴までを、具体的な指示例とコード例つきで解説します。

• 要点1：直書き文言の洗い出しはClaude Codeに任せ、ライブラリと翻訳キー設計の方針は人間が決める
• 要点2：複数形・日付・通貨は Intl API と CLDR の枠組みに乗せ、自前の文字列連結を避ける
• 要点3：機械翻訳・LLM翻訳の出力は必ず人がレビューする。文脈依存の訳とレイアウト崩れが最大のリスク

対象読者：既存のフロントエンド／バックエンドを多言語対応させたいエンジニア・PM。今日できること：自分のリポジトリで「文言の棚卸し」をClaude Codeに依頼し、i18n化の見積もりを取るところまで進められます。なお本記事の機能・コマンドは2026年6月時点のものです。

i18nとは何か：l10nとの違いと、対応の全体像

用語を最初に整理しておきます。i18n（internationalization・国際化）は、ソフトウェアを「複数の言語・地域に対応できる設計」にすること。文言をコードから切り離し、言語を差し替え可能にする土台づくりを指します。i18nの「18」は international の i と n の間に18文字あることに由来する略記です。

一方l10n（localization・地域化）は、その土台の上で「特定の言語・地域向けに実際に翻訳・調整する」作業を指します。日本語訳を入れる、日付を「2026/06/07」形式にする、といった具体作業がl10nです。

順番としてはi18n（設計）→ l10n（翻訳・調整）。設計が雑なまま翻訳に進むと、あとから文言を外部化する作業が二度手間になります。Claude Codeを使う場合も、まずi18nの土台を整える工程に時間を割くのが結果的に近道です。

i18n対応の全体像は、おおむね次の5工程に分けられます。

1. 現状把握：ハードコードされた文言を洗い出す
2. 方式の選択：i18nライブラリと翻訳キーの設計方針を決める
3. 実装：文言を外部ファイルへ移し、キーで参照するよう書き換える
4. 翻訳の管理と確認：翻訳ファイルを言語ごとに整備し、抜け漏れをチェックする
5. 検証：実画面で表示崩れ・文脈ズレを確認する

以降、この5工程をClaude Codeでどう進めるかを順に見ていきます。

工程1：ハードコードされた文言を洗い出す（現状把握）

最初の関門は「どこに何個、直書きの文言が散らばっているか」を把握することです。grepで日本語や英語の文字列を探すだけでも数百〜数千ヒットすることがあり、手で数えるのは現実的ではありません。ここはClaude Codeの探索力が活きる場面です。

Claude Codeはリポジトリ全体を読み込み、文脈を踏まえてUI文言とそれ以外（ログ出力やデバッグ文字列など）を切り分けられます。たとえば次のように指示します。

このリポジトリの src/ 配下から、UIに表示されるハードコードされた文言を洗い出してください。
条件:
- JSXのテキストノード、button/label/placeholder/title 属性の文字列
- alert/toast/エラーメッセージなどユーザー向けの文字列
- ログ出力やデバッグ用 console.log の文字列は除外
出力は「ファイルパス・行番号・文言・推奨する翻訳キー案」の表形式にしてください。
まだコードは書き換えないでください。まず棚卸しだけお願いします。

ポイントは「まだ書き換えないで」と明示すること。いきなり全置換させると、除外すべきログ文字列まで巻き込んだり、レビュー前に大量の差分が生まれて収拾がつかなくなります。最初は読み取り専用の棚卸しに限定し、人間が方針を固めてから実装へ進むのが安全です。

洗い出しの結果は、CSVやMarkdownの表で受け取っておくと、後でライブラリ選定や工数見積もりの根拠資料になります。Claude CodeにはCLAUDE.mdというプロジェクトメモリ機構があり、i18nの方針（採用ライブラリ、キー命名規則など）をそこに書いておくと、以降のセッションでも一貫した提案が得られます（詳細は公式ドキュメントのMemory参照）。

工程2：i18nライブラリと翻訳キーを設計する（方式の選択）

洗い出しが終わったら、どの仕組みに乗せるかを決めます。ここは人間が判断すべき領域です。Claude Codeに「おすすめは？」と聞くと一般論は返ってきますが、既存スタックとの相性やチームの運用方針はプロジェクト固有なので、最終決定は自分で下します。

ライブラリの選び方の観点

フロントエンドであれば、React系なら react-i18next や FormatJS（react-intl）、Vue系なら vue-i18n、フレームワーク非依存なら i18next 単体、といった選択肢があります。判断軸は次のあたりです。

• 既存フレームワークとの統合のしやすさ（公式プラグインの有無）
• 複数形・補間（変数埋め込み）・日付/数値整形の対応
• 翻訳ファイルの形式（JSON / YAML / PO など）と翻訳者の編集しやすさ
• 遅延ロード（言語別の分割読み込み）への対応

採用ライブラリのバージョンと基本的な使い方は、必ず各ライブラリの公式ドキュメントで2026年6月時点の最新仕様を確認してください。Claude Codeに実装させる前に、自分が一次情報を押さえておくことで、生成コードが古いAPIを使っていないかを判断できます。

翻訳キーの命名規則を先に決める

翻訳キーの設計は、後からの修正コストが大きいので最初に固めます。代表的な流派は2つです。

• 階層・名前空間型：login.button.submit のように、画面・機能で名前空間を切る。構造が把握しやすく、画面単位での分割ロードに向く
• 原文ベース型：英語原文そのものをキーにする（"Sign in"）。原文を見れば意味がわかる反面、原文を直すとキーが変わる弱点がある

どちらを選ぶにせよ、命名規則を文章で言語化してClaude Codeに渡すと、置き換え時のキー案が一貫します。たとえば次のように指示します。

翻訳キーは以下の規則で命名してください。
- 形式: 画面名.要素種別.内容（例: login.button.submit, common.error.network）
- 画面名は src/pages/ のディレクトリ名に合わせる
- 共通文言（OK/キャンセル/エラー等）は common 名前空間にまとめる
- 変数を含む文言は {name} のように補間プレースホルダで表現する
この規則で、工程1の棚卸し表にキー列を埋めた版を作ってください。

命名規則を「コードではなく日本語のルール」として明文化しておくのがコツです。これをCLAUDE.mdに残しておけば、別の担当者やセッションでも同じキー設計が再現できます。

工程3：文言を外部化してキー参照に書き換える（実装の進め方）

設計が固まったら、いよいよ実装です。ここでもClaude Codeに丸投げするのではなく、小さな単位で区切って進めるのが事故を防ぐ最大のコツです。一気に全ファイルを書き換えさせると、レビューが追いつかず、壊れた箇所の特定が難しくなります。

初期セットアップと1画面だけの試験導入

まずi18nライブラリの初期化と、翻訳ファイルの置き場所を決めます。次のような指示で、最小構成を1画面分だけ作らせます。

i18next と react-i18next を導入し、以下を実装してください。
1. src/i18n/ に初期化コード（i18n.ts）を作成。対応言語は ja, en。デフォルトは ja
2. 翻訳ファイルは src/i18n/locales/{lang}/{namespace}.json に配置
3. まず src/pages/Login だけを対象に、ハードコード文言を t('キー') 形式へ置き換え
4. ja と en の翻訳ファイルを作成し、ja には現在の日本語、en は未訳のまま英語キーを TODO コメントで残す
他の画面はまだ触らないでください。差分を小さく保ちたいです。

1画面で動作確認が取れたら、同じ手順を画面単位で横展開します。Claude Codeに「Loginと同じ方針でSettings画面も対応して」と頼めば、確立したパターンを反復してくれます。

変数を含む文言（補間）の扱い

「田中さん、こんにちは」のように変数を埋め込む文言は、文字列連結で組み立てると言語ごとの語順に対応できません。必ずライブラリの補間機構を使います。

// NG: 文字列連結（語順が固定されてしまう）
const msg = userName + 'さん、こんにちは';

// OK: 補間プレースホルダを使う
// 翻訳ファイル ja: { "greeting": "{{name}}さん、こんにちは" }
// 翻訳ファイル en: { "greeting": "Hello, {{name}}" }
const msg = t('greeting', { name: userName });

このような書き換えは、Claude Codeに「連結で組み立てている文言を補間形式に直して」と指示すると一括で拾ってくれます。ただし置き換え後は、変数名（name など）が翻訳ファイル側のプレースホルダと一致しているかを必ず人がレビューしてください。

工程4：複数形・日付・数値を正しく扱う（Intl と CLDR）

i18nで最も間違えやすいのが、複数形・日付・数値・通貨の扱いです。言語によって複数形のルールはまったく異なります。英語は単数/複数の2形ですが、ロシア語やアラビア語は3〜6形のルールを持ち、日本語には複数形の概念がありません。自前で「件数が2以上なら s を付ける」といった処理を書くと、英語以外で破綻します。

複数形は Intl.PluralRules / ライブラリのプルーラル機能に任せる

JavaScriptには標準で Intl.PluralRules があり、言語ごとの複数形カテゴリ（one / few / many / other など）を判定できます。i18nライブラリもこの仕組みを内部で利用しており、翻訳ファイル側で複数形を分けて書けます。

// 翻訳ファイル en（i18next のプルーラル記法の例）
// { "items_one": "{{count}} item", "items_other": "{{count}} items" }
t('items', { count: 1 }); // → "1 item"
t('items', { count: 5 }); // → "5 items"

// 標準APIで言語ごとの複数形カテゴリを確認することもできる
const pr = new Intl.PluralRules('en-US');
pr.select(1); // → "one"
pr.select(5); // → "other"

Claude Codeに「件数を表示している文言を複数形対応にして」と頼むときは、「自前のif分岐ではなくライブラリのプルーラル機能を使うこと」と明示します。指示しないと、英語前提のif文を書いてしまうことがあるためです。

日付・数値・通貨は Intl.DateTimeFormat / Intl.NumberFormat

日付の「2026/06/07」か「06/07/2026」か「7 June 2026」かは地域で変わります。これも Intl.DateTimeFormat と Intl.NumberFormat に任せれば、ロケールを渡すだけで適切な書式になります。

const date = new Date('2026-06-07');
new Intl.DateTimeFormat('ja-JP').format(date);  // → "2026/6/7"
new Intl.DateTimeFormat('en-US').format(date);  // → "6/7/2026"

new Intl.NumberFormat('ja-JP', { style: 'currency', currency: 'JPY' }).format(1980); // → "￥1,980"
new Intl.NumberFormat('en-US', { style: 'currency', currency: 'USD' }).format(19.8); // → "$19.80"

これらの整形ルールはUnicodeのCLDR（Common Locale Data Repository）として標準化されており、各ブラウザ・ランタイムの Intl 実装がそれに従います。つまり「自前で書式を組まず標準APIに寄せる」のが、地域差を最小コストで吸収する正攻法です。Claude Codeにも、日付や金額のフォーマット処理を見つけたら Intl へ寄せるよう依頼するとよいでしょう。

工程5：翻訳の管理と確認（人間レビューが主役）

文言の外部化が終わると、言語ごとの翻訳ファイル（ja.json / en.json など）が並びます。ここからが翻訳の管理フェーズです。

翻訳の抜け漏れを機械的にチェックする

翻訳作業で最も起きやすい事故が、キーの抜け漏れです。日本語ファイルには存在するキーが英語ファイルにない、あるいはその逆。これは実画面で「キー名がそのまま表示される」という見た目で露見します。

この突合はClaude Codeに任せると確実です。次のように指示します。

src/i18n/locales/ 配下の ja と en の翻訳ファイルを比較してください。
- ja にあって en にないキー（未翻訳の漏れ）
- en にあって ja にないキー（不要キーまたは ja の漏れ）
- 値が空文字のキー
- 補間プレースホルダ（{{name}} 等）が原文と訳文で一致していないキー
を一覧にしてください。可能なら、差分を埋めるチェック用スクリプトも提案してください。

特に補間プレースホルダの不一致（日本語は {{name}} なのに英語は {{user}} になっている、など）は実行時エラーや変数が表示されない不具合につながるため、必ず潰しておきます。CI（継続的インテグレーション）にこのチェックを組み込めば、未訳のままマージされる事故を防げます。

機械翻訳・LLM翻訳の品質は人が確認する

未訳のキーを埋めるとき、機械翻訳やLLMで一次案を作るのは効率的です。ただしその出力をそのまま採用してはいけません。ここがi18nで最も強調したい注意点です。

• 文脈依存の訳が外れる：たとえば「ホーム」はトップ画面の意味かもしれないし、住宅の意味かもしれない。短いUI文言ほど文脈が抜け、機械翻訳は誤訳しやすい
• 敬語・トーンが揺れる：ですます調とである調が混ざる、製品名やブランド用語が訳されてしまう、といった一貫性の崩れが起きる
• 専門用語・固有名詞：自社サービス独自の用語は、機械翻訳では一般語に置き換わってしまうことがある

Claude Codeに一次翻訳を作らせる場合も、「これは一次案であり、人間レビューを前提とする」という位置づけを崩さないでください。用語集（このサービスでは「アカウント」は account、「プラン」は plan とする等）をCLAUDE.mdや指示に含めると、訳のブレを減らせます。それでも最終確認は、できればその言語のネイティブまたは熟練者が行うのが理想です。

落とし穴：抜け漏れ・レイアウト崩れ・文脈ズレ

最後に、i18n対応で実際にハマりがちな落とし穴を、対策とセットで挙げておきます。

1. 翻訳の抜け漏れ：キーだけ増えて訳が空のまま公開。→ 工程5の突合チェックをCIに組み込み、未訳があればビルドを止める
2. レイアウト崩れ：ドイツ語など、英語より文字数が3〜4割長くなる言語でボタンや見出しがはみ出す。→ 固定幅を避け、最長言語でも崩れないかを実画面で確認する。短い英語だけ見て「収まった」と判断しない
3. 文脈依存の誤訳：同じ単語でも画面によって意味が違う。→ 翻訳キーに文脈を含める、または翻訳者向けにコメント（コンテキスト）を添える
4. ハードコードの取り残し：動的に生成される文言や、後から追加されたコードに直書きが残る。→ 「日本語文字列が残っていないか」をlintルールやClaude Codeの定期チェックで監視する
5. 右から左に書く言語（RTL）の未考慮：アラビア語・ヘブライ語ではレイアウトの左右が反転する。→ 対応予定があるなら、CSSの論理プロパティ（margin-inline 等）を使い dir 属性に追従させる

これらはどれも「英語と日本語だけ見て動いた」と思った後に、3言語目で発覚しがちな問題です。Claude Codeで実装を速められるぶん、検証の工数を削らないこと。最低でも「最長の言語」「複数形ルールが複雑な言語」を1つずつテスト対象に入れておくと、後の手戻りが減ります。

まとめ：Claude Codeに任せる作業と、人間が握る判断を分ける

国際化（i18n）対応は、量の多い機械的作業と、品質を左右する人間の判断が混ざった工程です。整理すると、役割分担はこうなります。

• Claude Codeに任せる：ハードコード文言の洗い出し、翻訳キーへの一括置き換え、補間形式への書き換え、翻訳ファイルの抜け漏れ突合、Intl APIへのリファクタリング
• 人間が握る：ライブラリ選定、キー命名規則、翻訳の最終品質判断、レイアウト崩れと文脈ズレの検証

この線引きを最初に決めておけば、Claude Codeの速さを活かしつつ、機械翻訳由来の品質事故を避けられます。まずは自分のリポジトリで「文言の棚卸し」を依頼するところから始めてみてください。i18nに付随するフロントエンド実装やコードレビューの効率化については、関連記事のClaude Codeで爆速フロント開発｜React/Next.jsとClaude Codeでコードレビューを効率化する実践ガイドも参考になります。

自社プロダクトのi18n化やClaude Code導入の進め方で詰まったときは、Claude Code実践テクニック完全ガイドに各工程の具体例をまとめています。チームへの導入支援についてのご相談も受け付けています。

よくある質問（FAQ）

Q. 既存の大規模アプリでも、Claude Codeでi18n化を進められますか？
A. 進められますが、一度に全ファイルを書き換えさせるのは避けてください。画面単位・機能単位で区切り、1ブロックずつ差分をレビューして横展開するのが安全です。CLAUDE.mdに方針を残すと一貫性が保てます。

Q. 翻訳はClaude Codeに全部やらせてよいですか？
A. 一次案の作成までにとどめ、最終的な品質判断は人が行ってください。短いUI文言ほど文脈が抜けて誤訳が起きやすく、敬語やブランド用語の揺れも人の目でないと拾いきれません。

Q. 複数形や日付は自前で処理してはいけませんか？
A. 推奨しません。言語ごとの複数形ルールや日付書式はUnicodeのCLDRとして標準化されており、Intl APIやライブラリのプルーラル機能に任せるのが正攻法です。自前実装は英語以外で破綻しやすくなります。

参考・出典

• Claude Code overview — Anthropic 公式ドキュメント
• Manage Claude’s memory（CLAUDE.md）— Anthropic 公式ドキュメント
• Intl — MDN Web Docs
• Intl.PluralRules — MDN Web Docs
• Language tags in HTML and XML — W3C Internationalization
• Unicode Locale Data Markup Language (LDML / CLDR) — Unicode Consortium

著者プロフィール

佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を手がける。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆。

あわせて読みたい：Webアクセシビリティ対応をClaude Codeで進める実践ガイド【2026】

関連記事（自動）

• ▸ Claude Codeで依存関係を可視化・改善する実践ガイド【2026年最新】
• ▸ 印刷会社のClaude Code活用｜見積・入稿チェック・進行管理を効率化
• ▸ 【2026年版】卸売・商社の受発注をClaude Codeで効率化した事例
• ▸ 保育園・こども園のClaude Code活用事例｜おたより・書類作成を効率化
• ▸ 動物病院のClaude Code活用｜カルテ整形・飼い主案内・在庫管理の実装事例