はじめに
フロントエンドの実装（frontend記事）でも、ドキュメント自動生成でもない。「Saveボタンの日本語訳を入れ忘れた」という問題が、コミット前に自動で検知されてPRに修正が入る——そんな国際化ワークフローをClaude Codeで作る話だ。
「まず英語で作って、後で多言語対応する」という開発フローを多くのチームが取る。しかし「後で」のコストは高い。コンポーネントをさかのぼってハードコード文字列を探し出し、翻訳キーに変換し、全言語の翻訳ファイルを更新する——この作業は単調で時間がかかる。スプリントが進むにつれてi18n負債が蓄積する。
Claude Codeのカスタムスキルと自動化で、このフローは大幅に短縮できる。
5つのi18nスキルと日常ワークフロー——実装から検証まで
intlpull.com（翻訳管理SaaSベンダー）の報告によると、Claude Codeのカスタムスキルとして以下の5コマンドでi18nのライフサイクル全体をカバーできる。ベンダー自社サービスの紹介であるため数値は独立検証がない点を留意した上で、スキルの設計思想は参考になる。
| スキルコマンド | 用途 |
|---|---|
| **`/i18n-scan`** | ファイル内のハードコード文字列を特定 |
| **`/i18n-extract`** | 文字列を抽出し翻訳キーを生成・コンポーネントを更新 |
| **`/i18n-translate`** | missing翻訳をAI生成（人間レビュー要フラグ付き） |
| **`/i18n-status`** | 言語別の翻訳カバレッジレポートを生成 |
| **`/i18n-validate`** | デプロイ前に翻訳問題を検知（エラー/警告分類） |
日常的なワークフローはこう設計できる。
1. ハードコード文字列を含む機能を実装（英語のまま）
↓
2. /i18n-extract を変更ファイルに対して実行
→ コンポーネントを自動更新 + 翻訳キーを生成
↓
3. /i18n-translate で不足している翻訳をAI生成（[NEEDS_REVIEW]フラグ付き）
↓
4. /i18n-validate で構造的・内容的な問題を検知
↓
5. 全変更をアトミックにコミット（機能 + i18n変更が一つのコミットに）翻訳キーの命名規則はnamespace.section.element形式が推奨される（intlpull.comの報告）。
checkout.form.submit_button
navigation.header.home
error.payment.card_declinedバラバラな命名（「checkout_submit」「submit_button_checkout」「button_submit」）が混在すると翻訳管理が混乱する。CLAUDE.mdに命名規則を定義しておくと、Claude Codeが一貫した形式で生成する。
コンテキスト理解による翻訳品質
/i18n-translateの実行後、翻訳管理システム（TMS）とのMCP連携（IntlPull MCP等）で翻訳をpush/pullできる設計もある。ここで重要なのはコンテキスト理解だ。
- 「Save」→ フォームのボタンなら「保存」（「Guardar」/「Sauvegarder」）
- 「Save」→ 金銭節約の文脈なら「節約する」
コンポーネントのコードを読んでいるClaude Codeは、この文脈の違いを判断できる。単純な機械翻訳との品質差がここに出る。ただし、文化的なニュアンス・法的表現・医療用語はAI翻訳が不十分なことがある。[NEEDS_REVIEW]フラグを付けた上で必ず人間翻訳者のレビューを挟むこと。
CLAUDE.mdでi18nポリシーを定義する——チームの「翻訳しない」を防ぐ
CLAUDE.mdにi18nルールを定義することで、コーディング中にClaude Codeが自動的にポリシー違反を指摘するようになる。
# CLAUDE.md（i18nルール）
## Internationalization Policy
### ハードコード禁止ルール
- UI文字列は必ず翻訳キーを使用（日本語・英語を問わず）
- 日付・時刻・通貨は必ずlocale-awareなフォーマット関数を使用
- 複数形はi18n-pluralizationを使用（言語によって複数形ルールが異なる）
### 翻訳キー命名規則
- namespace.section.element 形式（例: checkout.form.submit）
### 翻訳品質ルール
- AI生成翻訳は必ず [NEEDS_REVIEW] フラグを付ける
- 法的・医療・金融コンテンツは必ず人間翻訳者がレビュー
- RTL（右から左）言語（アラビア語・ヘブライ語）はレイアウトテストを必須とする
### NG表現
- ジェンダーニュートラルでない表現（英語の "he/she" 問題）
- 文化固有の慣用句（直訳すると意味が通じない）
- 仮定の文字列長（日本語は英語の1/2〜1/3の文字数）CLAUDE.mdに使用しているi18nライブラリを明記するとさらに精度が上がる（intlpull.comの報告）。
- Next.js: next-intl / next-i18next
- React Native: i18n-js / i18next（Bitscorpのブログでは、React NativeとClaude Codeを組み合わせたi18n実装のガイドが公開されている）
DEV Communityで公開されているdev.to/myougatheaxoの記事「Internationalization with Claude Code: next-intl, Type-Safe Translations, and RTL Support」では、Next.jsとnext-intlを使った型安全なuseTranslationsフックの実装と、RTL対応のCSS logical propertiesの活用が詳述されている。コードベース特有の型定義とClaude Codeの組み合わせで、missing keyをコンパイル時に検知できる設計だ。
RTL言語とローカライゼーションの複雑さ
アラビア語・ヘブライ語などのRTL（右から左）言語は、翻訳だけでなくUIレイアウトが左右反転する。CLAUDE.mdにRTLテスト必須のポリシーを定義しておくと、コーディング段階でClaude Codeが「このコンポーネントはRTLテストが必要です」と指摘するようになる。
ポーランド語やアラビア語は英語とは異なる複数形ルールを持つ点も考慮が必要だ。i18nライブラリのpluralizationサポートを確認してからClaude Codeに生成させること。
git diff監視 × pre-commitフック——「書いたそばから自動i18n化」
pre-commitフックへの統合
# .git/hooks/pre-commit または Lefthookの設定
claude -p "ステージングされた変更に新しいハードコード文字列がないか確認して。
あれば /i18n-extract を実行して翻訳キーに変換して" \
--allowedTools Bash,Edit,Readコミット時に自動でi18n漏れを検知し、その場で修正するフックだ。「書き忘れをコミット前に防ぐ」防衛ラインになる。
intlpull.comの報告によると、git diffを監視して新規文字列が追加されると自動でi18n化するバックグラウンドエージェントパターンも登場している。「コミット前に防ぐ」から「書いたそばから自動変換される」へのシフトだ。
`.claude/commands/`のgit管理でチーム配布
git add .claude/commands/i18n-extract.md
git add .claude/commands/i18n-validate.md
git commit -m "chore: add i18n Claude Code skills".claude/commands/ディレクトリをgitで管理することで、チームメンバー全員が同じi18nスキルを使える。新メンバーがjoinした瞬間に、i18n対応のツールセットが手に入る。「チームに配布する手間」が不要になる。
まとめ
i18n負債の問題は「やる気がない」のではなく「フローがない」ことで起きる。/i18n-extractを機能実装のたびに実行するフローをCLAUDE.mdとpre-commitフックで仕組み化すれば、負債が蓄積しない状態を作れる。
「スプリントの最後にi18n対応スプリントを設ける」という後処理モデルから、「実装と同時にi18n化が完了する」都度処理モデルへの転換——それを実現するのに必要なのは、CLAUDE.mdに数行書いて.claude/commands/に数ファイル追加することだ。
コメント