TL;DR
- 日本語は英語より LLM のトークン効率が悪い（同じ内容で概ね 2〜3 倍。論文あり）
- そこで「日本語の指示を最軽量モデルで英訳し、以降の作業を英語で行い、最終回答だけ日本語で返す」スキル work-in-english を作って Claude Code に組み込んだ
- 条件を揃えた A/B 実測の結果:
- 短タスク（1分程度）では効果なし。むしろスキル起動のオーバーヘッドで逆に消費が増える（出力トークン +60%）
- 長タスク（数分・多ファイル調査＋長文レポート）では総トークン約 16% 削減（キャッシュ読み取りは −38%）
背景
Anthropic から Claude 5 ファミリーの最上位モデル Claude Fable 5 が出ました。Opus より上の Mythos クラスという位置づけで、賢い分、トークンをどう節約するかがこれまで以上に効いてきます。
多くの日本人エンジニアは Claude Code を日本語で使っています。ここで気になるのが、日本語は英語よりトークンを多く消費するという問題です。
日本語はどれだけ「割高」なのか（文献）
これは体感ではなく、研究として確認されている現象です。
- Petrov et al., "Language Model Tokenizers Introduce Unfairness Between Languages" (NeurIPS 2023, arXiv:2305.15425)
同じ内容のテキストでも言語によってトークン化後の長さが大きく異なり、その差は最大で 15 倍に達すること、多言語対応を意図して訓練されたトークナイザーでも格差が残ること、結果として一部の言語話者は英語話者の 2.5 倍以上のコストを払っていることを示しています。言語ごとの「トークンプレミアム」を可視化したインタラクティブなデモサイトもあります。 - Ahia et al., "Do All Languages Cost the Same? Tokenization in the Era of Commercial Language Models" (EMNLP 2023, arXiv:2305.13707)
API が「トークン数課金」であることの言語間不公平を分析した論文。英語は平均して 1 トークンあたり約 4 文字を表現できる一方、日本語は 1 トークンあたり数文字程度しか表現できず、同じ情報量に対して英語より多くのトークンを要することを示しています。 - zephel01 さんの note 記事 「LLMで日本語を使うと『言語税』を払ってるって本当？同じ文章なのに最大1.94倍のトークン消費…衝撃のデータが公開されました」
同一文章（Sutton の "The Bitter Lesson" を 9 言語に翻訳）を主要 6 モデルのトークナイザーで比較した検証の日本語解説。日本語は英語比で平均約 1.48 倍、モデルによっては 2 倍近いトークンを消費するという具体的な数字が紹介されています。
ざっくり言うと、日本語で考えさせ、日本語でメモを書かせると、英語の 1.5〜3 倍のトークンを払っている可能性があるわけです。
対策: work-in-english スキル
そこで作ったのが work-in-english という Claude Code スキルです。発想は単純で、タスクの「作業言語」だけ英語に切り替えるというものです。
ユーザー（日本語で依頼）
│
▼
Haiku サブエージェントが日本語プロンプトを英訳 ← 翻訳は最軽量モデルで安く
│ （固有名詞・コード識別子・インフラ名/ID は原文保持）
▼
メインの Claude は英訳版を「作業言語」としてタスク遂行
│ （思考・ツール操作・中間メモはすべて英語）
▼
最終回答だけ日本語で返す ← ユーザー体験は変わらない
ポイントは 2 つ。
- 翻訳は必ず最軽量モデル（Haiku）のサブエージェントに任せる。メインモデルに翻訳させたらコスト削減になりません。
- 最初の日本語入力分の入力トークンは減らない（スキルはプロンプトがコンテキストに入った後に動くため）。節約できるのは「以降の思考・中間メモ・マルチターンが英語になる分」です。
Skillの内容は以下の通りです。
---
name: work-in-english
description: MUST USE（長めのタスク限定）— ユーザーのプロンプトが日本語で、かつ長め・複数ステップのタスク（複数ファイルにまたがる調査・実装・リファクタ、長文レポートや設計書の作成、マルチターンに及ぶ作業など、中間生成物が多く数分以上かかる依頼）なら、最初のツール呼び出しの前に必ずこのスキルを起動する。他のスキル（brainstorming 等）と併用する場合も、このスキルを最初に実行する。動作: 最軽量モデル（Haiku）のサブエージェントで日本語プロンプトを英訳し（固有名詞・コード識別子・ファイルパス・インフラ名/ID・専門用語は原文保持）、以降の思考・ツール操作・中間メモをすべて英語で行いトークン消費を抑える。最終応答は日本語。起動しない: 短い質問・雑談・一言確認・既に英語の入力に加え、数分で終わる単発の小タスク（1〜2ファイルの読解・小修正・単純調査）— 実測で翻訳・スキル読込のオーバーヘッドが節約を上回る。効果の実測値: 長タスクで総トークン約15〜16%削減、短タスクでは逆にオーバーヘッドで増加。
when_to_use: 日本語で長め・複数ステップのタスク（多ファイル調査・実装・長文レポート作成・マルチターン作業）を受けた直後、作業開始前。数分で終わる小タスク・短い質問・英語入力では使わない。
allowed-tools:
- "Agent(*)"
---
name work-in-english
description MUST USE (long tasks only) — When the user's prompt is in Japanese AND the task is long and multi-step (investigation, implementation, or refactoring spanning multiple files; writing long reports or design docs; multi-turn work — anything producing substantial intermediate output and taking several minutes or more), invoke this skill BEFORE the first tool call. When combining with other skills (e.g. brainstorming), run this one first. Behavior — a subagent on the lightest model (Haiku) translates the Japanese prompt into English (names of people/companies/products, code identifiers, file paths, infra names/IDs, and technical terms are kept verbatim), then all subsequent thinking, tool use, and intermediate notes are written in English to reduce token consumption. The final response to the user stays in Japanese. Do NOT invoke for short questions, casual chat, one-line confirmations, input already in English, or small one-off tasks finishing within a few minutes (reading 1-2 files, small fixes, simple lookups) — measured overhead of translation + skill loading exceeds the savings there. Measured effect - roughly 15-16% total token reduction on long tasks; a net increase on short tasks.
when_to_use Immediately after receiving a long, multi-step task instruction in Japanese (multi-file investigation, implementation, long report writing, multi-turn work), before starting work. Do not use for small tasks that finish in minutes, short questions, or English input.
allowed-tools
Agent(*)
work-in-english
Translate a Japanese task instruction into English using the lightest model, then have the main Claude work in English to reduce token consumption. The final response stays in Japanese.
Why this skill
Japanese tokenizes poorly: thinking, interpreting tool results, and multi-turn exchanges all consume more tokens than in English (roughly 1.5-3x for the same content). Switching the task's working language to English cuts everything downstream. The translation itself is delegated to the cheapest model.
Scope of savings: This skill runs after the Japanese prompt has already entered the main context, so the input tokens of the original Japanese prompt are not reduced. The savings come from (a) all subsequent thinking / tool-result interpretation / multi-turn exchanges happening in English, and (b) the translation being done cheaply on the lightest model. Measured on real tasks: ~15-16% total token reduction on long tasks (cache reads −38%, because Japanese intermediate notes otherwise accumulate in context and are re-read every turn); a net increase on short tasks due to overhead.
Execution Contract (non-negotiable)
MUST
Translation MUST be performed by a subagent running model: "haiku" (the lightest model) via the Agent tool. Never translate with the main model or any other model.
The translation subagent MUST be strictly instructed to keep the following verbatim (no translation, no alteration):
Names of people, companies, organizations, products, services
Code identifiers, variable/function names, file names, paths, commands, code blocks
Infra/host names, unique IDs, ARNs, endpoints, URLs (e.g. prod-baito-pc-web211)
Technical jargon (use the standard English term if one exists; otherwise keep as-is)
Anything the user explicitly marked as "do not translate"
The subagent MUST return only the English translation (no preamble, no notes, no commentary).
After receiving the translation, the main Claude MUST use the English version as the working language for the task (reasoning, tool calls, and intermediate notes all in English).
The final response to the user MUST be in Japanese (preserving the existing Language setting).
MUST NOT
Do not invoke this skill for short questions, casual chat, one-line confirmations, input already in English, or small one-off tasks that finish within a few minutes (reading 1-2 files, small fixes, simple lookups).
Do not use the main model or opus/sonnet for translation (violates the cost requirement).
Do not translate proper nouns, code, or IDs.
Do not stop to show the user the translation for approval (the point of this skill is "translate, then keep working"; wait for separate instructions only if the user's goal was the translation itself).
Steps
Step 1 — Decide whether to invoke
Confirm the request is a long, multi-step task instruction in Japanese. Rule of thumb: investigation/implementation/refactoring spanning multiple files, writing a long report or design doc, or work expected to span multiple turns — anything generating substantial intermediate output (notes, plans, subagent instructions). Do NOT invoke for: short questions, casual chat, one-line confirmations, input already in English, or small one-off tasks finishing within a few minutes (reading 1-2 files, small fixes, simple lookups). Measurements show overhead exceeds savings on small tasks, while long tasks see ~15-16% total token reduction.
Step 2 — Translate with the lightest model
Launch the Agent tool with model: "haiku" and a prompt like:
Translate the following Japanese task instruction into natural, concise English.
STRICT rules — keep the following VERBATIM, do NOT translate or alter them:
- Person / company / organization / product / service names
- Code identifiers, variable/function names, file names, paths, commands, code blocks
- Infra/host names, unique IDs, ARNs, endpoints, URLs (e.g. prod-baito-pc-web211)
- Technical jargon (use the standard English term if one exists; otherwise keep as-is)
Output ONLY the English translation. No preamble, no notes, no explanation.
--- Japanese input ---
<full Japanese prompt from the user>
subagent_type can be general-purpose (or claude). Use a description like "translate JP prompt to EN".
Step 3 — Work in English
Treat the returned translation as the task's working language. All subsequent investigation, implementation, tool use, and thinking notes proceed in English.
Step 4 — Respond in Japanese
When the task is done, deliver the final report/explanation to the user in Japanese (code, identifiers, and proper nouns stay as-is, naturally).
Red flags (self-check)
Thought Correct response
"I'll just translate it myself, it's faster" Violates the cost requirement. Always delegate translation to the Haiku subagent
"Let me anglicize prod-baito-... too" Proper nouns and IDs stay verbatim
"I'll show the user the translation to confirm" Don't stop unless translation itself was the goal. Keep working in English
"The final response can stay in English" Final response is Japanese (preserve the Language setting)
"I'll use it for this one-liner too" Translation overhead isn't worth it. Long, multi-step tasks only
"I'll run another skill first" For long Japanese tasks, run work-in-english first, then proceed to other skills after translation
"It's a small task but I'll use it just in case" Measurements show overhead exceeds savings on small tasks. Don't
"This investigation is long but translating feels like a detour" Long tasks are exactly where it pays off (~15-16% measured reduction). Invoke it
スキルが自動起動する
3 層で対策しました。
- SKILL.md の description を命令形に強化（「MUST USE」で始め、トリガー例を列挙）
- CLAUDE.md / AGENTS.md に必須起動ルールを明記
- UserPromptSubmit フックでリマインダーを注入
フックはこんな感じです。日本語 10 文字以上かつ全体 25 文字以上のプロンプト（slash command 除く）を検知したら、コンテキストにリマインダーを差し込みます。
#!/bin/bash
# UserPromptSubmit hook:
# 日本語のタスク指示を検知したら work-in-english の起動リマインダーを注入する
# heredoc が python の stdin を占有するため、フック入力は環境変数で渡す
HOOK_INPUT="$(cat)" export HOOK_INPUT
python3 - <<'PY'
import json, os, re, sys
try:
data = json.loads(os.environ.get("HOOK_INPUT") or "{}")
except Exception:
sys.exit(0)
prompt = (data.get("prompt") or "").strip()
if not prompt or prompt.startswith("/"):
sys.exit(0)
jp_chars = re.findall(r"[ぁ-んァ-ヶー一-龯]", prompt)
if len(jp_chars) >= 10 and len(prompt) >= 25:
print("（work-in-english 起動リマインダー本文）")
sys.exit(0)
PY
実験 1: 短タスクで条件を揃えて比較 → 効果なし
実際どれくらい減るか確かめるため、条件を揃えた A/B 比較をしました。
- タスク: 特定のスクリプト＋テストファイルを読んで分析レポートを書く（読み取り専用、約 1 分）
- 条件: ①日本語のまま作業 ②英訳済みプロンプトで英語作業 ③日本語プロンプトだけ渡す（スキルに任せる）
- 各条件 3 回、同一モデル、最終回答はすべて日本語
結果（短タスク）
| 条件 | 出力トークン平均 | 所要時間 |
|---|---|---|
| ① 日本語のまま作業 | 5,837 | 約 60 秒 |
| ② 英語で作業 | 6,402 | 約 58 秒 |
| ③ スキル経由フルフロー | 9,443 ＋ Haiku 翻訳分 | 84〜139 秒 |
日本語作業と英語作業の差はノイズ範囲内。そしてスキル経由は、SKILL.md の読み込み・翻訳サブエージェントの起動と待機・結果の解釈という往復が乗って、出力トークン +60%、時間 +40〜130% と明確に損でした。
なぜ効かないのか。有力な説明は、
- モデルは日本語プロンプトでも内部の思考をほぼ英語で行うため、プロンプトを英訳しても思考分は変わらない
- ツール結果（コード）はもともと英語
- 最終回答は両条件とも日本語
つまり短タスクには「英語に切り替わって節約になる部分」がほぼ存在しないのです。
実験 2: 長タスク × Haiku → 総トークン −16%
スキルの節約が効くとしたら、日本語の中間生成物（メモ・計画・レポート草稿）が大量に発生する長いタスクのはずです。そこで次の実験をしました。
- タスク: リポジトリの CI/CD 全体調査（ドキュメント＋ワークフロー 11 本＋設計書＋スクリプトを読み、各ステップで箇条書きメモを書きながら、5 章構成の詳細レポートを作成）。ツール使用 15〜19 回、2〜3 分の規模
- 条件: ①日本語のまま作業（スキル明示禁止） ②英語で作業（最終レポートは日本語）
- 各条件 3 回、作業モデルは Haiku
結果（長タスク）
| 指標（3 回平均） | ① 日本語作業 | ② 英語作業 | 差 |
|---|---|---|---|
| 総トークン | 99,890 | 83,842 | −16% |
| キャッシュ読み取り | 179 万 | 111 万 | −38% |
| キャッシュ作成 | 36.0 万 | 32.3 万 | −10% |
| 概算コスト（Haiku 単価換算） | 約 $0.70 | 約 $0.60 | −15% |
しかも英語作業側は成果物テキスト量が約 2.2 倍あったうえでこの数字です。分量を揃えたら差はさらに開くはずです。
なぜ長タスクだと効くのか
出力トークン単体では英語側の方が多かった（レポートを長く書いたため）のに、総消費では英語側が勝ちました。鍵はキャッシュ読み取りの −38% です。
エージェントの各ターンでは、それまでの会話全体（中間メモ含む）がコンテキストとして再読されます。日本語の中間メモはトークン数が嵩むので、一度書いた日本語メモが、以降の全ターンで「読み直しコスト」として複利的に効いてくるわけです。作業言語を英語にすると、この蓄積が最初から軽くなります。まさに論文が指摘するトークンプレミアムが、マルチターンでは掛け算になるということだと想像しています。
結論: 「長めのタスク限定」で自動起動させる
2 つの実験から、運用は次に落ち着きました。
| タスク | work-in-english |
|---|---|
| 短い質問・雑談・一言確認 | 起動しない |
| 数分で終わる単発の小タスク（1〜2 ファイルの読解・小修正） | 起動しない（オーバーヘッドが節約を上回る） |
| 複数ファイルの調査・実装・長文レポート・マルチターン作業 | 起動する（総トークン約 15〜16% 削減） |
SKILL.md の description・CLAUDE.md のルール・フックのリマインダー文言をすべて「長め・複数ステップのタスク限定」に揃え、実測値も明記しました。「迷ったら起動」という初期の攻めた文言は撤回しています。
注意点・限界
- 各条件 n=3 の小規模実験で、タスクも 2 種類だけです。傾向は明確でしたが、数字はタスクとモデルに依存します
- thinking の言語はトランスクリプトから直接確認できないため、「内部思考はもともと英語」は状況証拠からの推測です
- 短タスクの英語条件で 1 本、使用量記録が明らかに壊れている run があり、平均から除外しました
- コスト換算は Haiku の公表単価（入力/出力/キャッシュ読み書き）で機械的に計算した概算です
- 「最初の日本語入力分」は原理的に削減できません。そこまで削りたい場合はフックでの翻訳前処理（プロンプト自体の書き換え）が必要ですが、ユーザーの意図改変リスクと引き換えになるため採用していません
まとめ
- 日本語のトークンプレミアムは実在する（Petrov et al. 2023、Ahia et al. 2023）
- ただし「作業言語を英語にすれば必ず節約になる」わけではない。短タスクではスキルのオーバーヘッドが勝ち、長タスクでは中間生成物の複利効果で約 15〜16% 削減できた
- 効果測定は条件を揃えた A/B で。今回は「対照群が勝手にスキルを起動する」という、自動起動改善の成功を皮肉な形で証明する事故も起きた
- スキルの起動条件は「効くと分かっている領域」に絞るのが大事。全部に効かせようとすると、小タスクで静かに損をし続ける
参考文献
- Aleksandar Petrov, Emanuele La Malfa, Philip H.S. Torr, Adel Bibi. "Language Model Tokenizers Introduce Unfairness Between Languages." NeurIPS 2023. arXiv:2305.15425 / サイト
- Orevaoghene Ahia, Sachin Kumar, Hila Gonen, Jungo Kasai, David R. Mortensen, Noah A. Smith, Yulia Tsvetkov. "Do All Languages Cost the Same? Tokenization in the Era of Commercial Language Models." EMNLP 2023. arXiv:2305.13707
- zephel01. 「LLMで日本語を使うと『言語税』を払ってるって本当？同じ文章なのに最大1.94倍のトークン消費…衝撃のデータが公開されました」 note, 2026-04-30
- Claude Fable 5 / Mythos 5 発表