背景: 日本語の「言語税」をどこで払うか

先日の記事で、日本語入出力が英語比 1.48 倍のトークンを消費すること、Claude では最大 1.94 倍にもなることを取り上げた。

しかし現実問題、ブログ記事本文・コミットメッセージ・GitHub PR の説明・許可プロンプトなど、最終アウトプットが日本語であること自体が要求であるケースは避けられない。Claude Code を使い続ける限り、日本語コストはゼロにはならない。

問いを言い換えると、こうなる:

「日本語境界を保ったまま、実トークン消費を構造的に減らせる場所はどこか？」

検討した 5 案

案仕組み効く場面弱点
A. 翻訳プロキシ (Ollama)ユーザー入力 ja→en、Claude 応答 en→ja を中間 LLM が翻訳「思考・指示が日本語で出来ればよい」用途ツール結果・ファイル内容・git diff まで翻訳経路に入り破綻
B. 部分英語化思考・指示は英語、最終成果物は日本語のまま大半の開発作業削減率は応答側ほど効かない
C. Prompt Caching 徹底CLAUDE.md・Skills・MCP 出力をキャッシュ日本語のまま実コストを大幅削減設計工数が必要
D. Caveman プロンプト「原始人みたいに喋れ」で日本語応答を圧縮既存実績手法（最大 80% 削減）文体が崩れるので公開記事には不向き
E. モデル切替Gemini など日本語効率の良いモデルへ部分委譲翻訳・要約などコモディティ作業Claude のハーネス連携を捨てる

翻訳プロキシ案 (A) が筋悪な理由

「ローカル LLM で Claude Code の入出力を翻訳する」というアイデアは一見魅力的だが、Claude Code は対話 AI ではなく エージェント環境 であることを思い出す必要がある。

LLM への入力には以下が全部含まれる:

  • ユーザーのテキスト入力（少量）
  • システムプロンプト（CLAUDE.md, Skills）
  • ツール定義
  • ツール実行結果（ファイル内容、git diff、gh pr view の JSON など）
  • 過去の会話履歴

翻訳プロキシで効果を出すには、これらすべての言語を統一する必要がある。しかし git diff を翻訳すれば差分が壊れ、JSON を翻訳すれば構造が壊れる。「テキスト本文だけ翻訳」では選別ロジックが LLM 並みに賢くないと成立しない — つまりもう 1 段 LLM が要る。

結論はシンプル: ハーネスの外側で翻訳するのではなく、ハーネスの内側のテキストを最初から英語で書いた方が筋がよい。これが C + B の組み合わせに帰着する理由だ。

採用した方針: CLAUDE.md の部分英語化

CLAUDE.md は毎セッションの先頭で読み込まれる固定資産。prompt caching の効きが最大化される場所だ。これを英語化すれば、入力トークン側のコストを構造的に削減できる。

ただし「全部英語」では実用性を損なうので、境界を明示的に分ける。

翻訳の方針マトリクス

要素扱い理由
見出し・規約・説明文英語化キャッシュヒット対象。固定資産化
許可プロンプト文言ルール英語ルールで「日本語で説明せよ」と明記ユーザー境界は日本語のまま
ブログ記事本文英語ルールで「日本語で書け」と明記最終アウトプット側は触らない
カテゴリ名日本語のままscripts/categorize.py が文字列マッチに使う実値
コミット/PR タイトルテンプレ英語、可変部分は日本語タイトル既存履歴との一貫性
alt テキスト「日本語で書け」と英語で指示SEO・アクセシビリティ要件

「英語で書かれた、日本語を使えという指示」

直感に反するが、実装するとこんな形になる:

1
2
3
4
5
6
7
8
9

## Permission-prompt language rule

- When asking the user to approve a tool call (Bash, file ops, etc.),
  the prompt explanation MUST be written in **Japanese**.
- Always include a security risk estimate (%) for each of:
  - Risk of leaking passwords or private keys
  - Risk of sending data to an external server
  - Risk of executing malicious code
  - Risk of overwriting PC configuration

「英語のルール文」に「日本語で出力せよ」と書く入れ子構造になる。LLM はこれを正しく解釈する。重要なのは、長く繰り返し読まれるルール文が英語側にあること。

カテゴリ名は日本語を残す

scripts/categorize.py は "AI/LLM"・"セキュリティ" などの文字列リテラルでマッチングしている。ここを英語化すると既存記事のフロントマターと整合しなくなる。「コードが参照している実値」は外部仕様として日本語を保つ。

トレードオフ

メリット

  • CLAUDE.md（毎セッション読み込み）の入力トークンを構造的に削減
  • Claude が指示を読む際の精度向上（英語の方が安定する傾向）
  • prompt caching とのシナジー（同じ英語ルール文がキャッシュにヒットし続ける）

デメリット

  • 日本語ルールと英語ルールが混在し、人間の可読性が落ちる
  • Skills (.claude/skills/*/SKILL.md) も同じ方針で英語化しないと中途半端になる
  • 英語表現のミスで意図がズレるリスク（特にニュアンス重視のルール）

実装

この記事と同じ PR で CLAUDE.md を英語版に差し替える。

保持したもの:

  • カテゴリ名（日本語リテラル）
  • 「許可プロンプトは日本語」ルール（英語で書かれた指示として）
  • 「記事本文・PR タイトル・alt テキストは日本語」ルール（同上）
  • Bash 規約・PR 規約の構造

変更したもの:

  • 見出し・本文・注釈をすべて英語化
  • Rationale を明示（なぜこの部分は日本語のままか）

詳細は本 PR の diff を参照。

次のステップ

  1. Skills の英語化 — .claude/skills/blog/SKILL.md, .claude/skills/wiki-ingest/SKILL.md は CLAUDE.md より長く、キャッシュ効果も大きい
  2. MCP サーバー応答の最適化 — aegis_fetch の応答フォーマットなど、頻出する固定構造のキャッシュ化
  3. 実測 — 同一タスク（記事 1 本作成）の入力トークン数を Before/After で計測

まとめ

日本語の言語税は「日本語で何を書くか」より「どこで日本語を使うか」の問題だ。

ハーネスの内側（CLAUDE.md, Skills）は人間が読まないので英語化してキャッシュを効かせ、ハーネスの外側（記事本文・PR タイトル・許可プロンプト）は日本語のまま残す。翻訳プロキシでハーネスの外側に翻訳層を作るより、ハーネス自体を英語で書く方が、副作用がなく実装も簡単だ。

「LLM とのインターフェースは英語、人間とのインターフェースは日本語」— この境界線を CLAUDE.md の中に明示的に書き込むのが今回のパターンの本質だ。

関連記事