Claude Code 日本語化を調べると、検索で出てくる手順の多くは「ロケールを日本語にする」「LANG を設定する」と書いています。しかし v2.1.241 で実際に測ると、ロケールを日本語にしても応答は1バイトも変わりません。そもそも Claude Code には言語設定が存在せず、claude --help が並べる62個のオプションのうち言語に関わるものは0個でした。本記事では、Claude Code 日本語化に実際は何が効くのか、文字化けの原因はどこにあるのか、そして日本語で使うとトークンが1.57倍かかるという実測値までを、すべて手元での検証つきで示します。

Claude Codeの日本語利用に関する実測サマリ。CLIオプション62個中に言語設定は0個、ロケール変更では応答が変わらず、CLAUDE.mdとシステムプロンプトだけが応答言語を切り替え、日本語はトークンを1.57倍消費することを示す図。
v2.1.241 を実際に動かして測った結果。「設定で日本語にする」という発想がそもそも空振りする。

30秒でわかる Claude Code の日本語利用

・言語設定は存在しない。CLIオプション62個中0個、実行バイナリに ja-JP / ja_JP は0件（対照の en-US は40件）
・LANG=ja_JP.UTF-8 は効かない。同じ英語プロンプトでロケールだけ変えたA/Bで、返答は1文字違わず同一
・効くのは CLAUDE.md と --append-system-prompt の2つ。どちらも英語で質問しても日本語で返る
・文字化けはCLIの問題ではない。LC_ALL=C でも出力バイト列はUTF-8のまま ja_JP.UTF-8 と完全一致
・日本語はトークン1.57倍。文字数は4割少ないのに、1トークンあたり英語3.38文字／日本語1.26文字

Claude Code そのものの導入・設定・運用の全体像は、Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとめてあります。本記事はそこから「日本語で使う」という一点だけを切り出して掘り下げます。

Claude Code 日本語化に「言語設定」は存在しない——62オプションを全数確認した

まず最初に潰しておくべき前提があります。Claude Code には言語を切り替える設定が用意されていません。

claude --help が出力するオプションを数えると、v2.1.241 では62個ありました。そのうち lang / locale / i18n / japanese のいずれかを含む行は0行です。

# 実行して確かめられます（v2.1.241 で確認）
claude --help | grep -cE '^  (-|--)'                    # → 62
claude --help | grep -ciE 'lang|locale|i18n|japanese'   # → 0

「オプションに無いだけで内部には持っているのでは」という疑いも潰しておきます。Claude Code の実体は単一のネイティブ実行ファイル（macOS arm64 で310MB）なので、埋め込み文字列を直接検索できます。

検索した文字列 ヒット数 意味
en-US 40 英語ロケールの識別子は存在する
ja-JP 0 日本語ロケールの識別子は無い
ja_JP 0 同上（POSIX表記でも無い）
Auto-compact（UI文言・対照群） 20 英語のUI文言は当然ある
esc to interrupt（UI文言・対照群） 2 同上
自動コンパクト（上記の和訳） 0 UI文言の日本語版は存在しない
中断するには（同上） 0 同上

対照群として英語のUI文言が確実にヒットすること、そして en-US はあるのに ja-JP だけが0件であることを同時に確認しています。「検索方法が悪くて見つからない」のではなく、日本語ロケールが最初から入っていないという結論です。

つまり、ステータスラインの Auto-compact、入力欄下の esc to interrupt、権限ダイアログの英文といったTUIの文言は、どう設定しても英語のままです。日本語化できるのは「Claudeの応答」だけで、「アプリの画面」ではありません。ここを混同したまま設定をいじると、いつまでも「日本語化できない」ことになります。

Claude Codeの表示を3層に分けた図。TUIの枠やステータス表示は英語固定で変更不可、Claudeの応答本文はCLAUDE.mdやシステムプロンプトで日本語に切り替え可能、ファイル内容やコマンド出力はそのまま通過することを示す。
日本語化の対象になるのは真ん中の層だけ。上下2層は言語設定の管轄外にある。

Claude Code 日本語化で実際に効く3つの方法と、その効き方

では何が効くのか。候補を4つ立てて、同じ質問を投げるA/Bで1つずつ確かめました。質問は In one sentence, what does 'git commit' do?（英語）で固定し、claude -p の非対話モードで実行しています。

方法 実測結果 判定
LANG / LC_ALL を ja_JP.UTF-8 にする 英語で返答（en_US.UTF-8 の返答と1文字も違わない） ❌ 効かない
プロンプトを日本語で書く 日本語で返答 ⭕ 効く（ただし追随なので不安定）
CLAUDE.md に「応答は必ず日本語で書くこと」と記載 英語の質問でも日本語で返答 ◎ 確実
--append-system-prompt "Always respond in Japanese." 英語の質問でも日本語で返答 ◎ 確実

ロケール変更が効かないことの確認

いちばん誤解が多いのがこれなので、実測の生データを置きます。

# 同じプロンプトを、ロケールだけ変えて2回実行する
LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 \
  claude -p "In one sentence, what does 'git commit' do?"
LANG=ja_JP.UTF-8 LC_ALL=ja_JP.UTF-8 \
  claude -p "In one sentence, what does 'git commit' do?"

返ってきた文章は両方とも git commit saves the currently staged changes as a new snapshot in the repository's history, along with a message describing them. で、完全に同一でした。ロケール環境変数は応答言語に一切関与していません。

一方、同じ内容を日本語で聞くと日本語で返ってきます（ロケールは英語のまま）。

git commit は、ステージング済みの変更をローカルリポジトリの履歴に記録するコマンドです。

応答言語を決めているのはロケールではなく、文脈に含まれる言語です。これが分かると、なぜ「最初は日本語だったのに途中から英語になった」が起きるのかも説明できます。英語のスタックトレースやREADMEを読ませた瞬間、文脈の言語比率が英語に傾くからです。

CLAUDE.md に書くのが最も安定する

恒久的に日本語で使いたいなら、プロジェクトの CLAUDE.md に指示を書きます。実測では、これだけで英語の質問に対しても日本語で返ってきました。

# プロジェクト規約

- 応答は必ず日本語で書くこと。

CLAUDE.md はセッション開始時に読み込まれ、以降のやり取り全体に効きます。ファイルの置き場所（プロジェクト直下・~/.claude/CLAUDE.md・親ディレクトリ）による読み込み順の違いや、他のAIツールとの AGENTS.md 共通化については、AI mdファイルとは｜CLAUDE.md・AGENTS.md・.cursorrules・GEMINI.mdの違いと書き方に整理があります。

単発のコマンド実行や、CLAUDE.md を汚したくない場合は --append-system-prompt を使います。

claude --append-system-prompt "Always respond in Japanese." \
  -p "In one sentence, what does 'git commit' do?"

こちらも実測で日本語の返答になりました。CI やスクリプトから叩く用途ではこちらが扱いやすいです。

なお、同じ「日本語化」という言葉でも Cursor はUIそのものに日本語表示の経路があり、事情が異なります。エディタ側の手順はCursor 日本語化の完全手順｜UI・AI応答・初期設定と日本語にできない時の対処を参照してください。Claude Code はUIの日本語化経路が存在しない点が決定的な違いです。

文字化けの本当の原因——出力は常にUTF-8だった

「Claude Code 文字化け」で検索すると、ロケールを設定して直す手順が並びます。これも実測で否定できます。

非UTF-8ロケールである LC_ALL=C を明示して日本語を出力させ、バイト列を直接見ました。

LANG=C LC_ALL=C claude -p "「こんにちは」とだけ出力してください" | xxd | head -1

結果は e381 93e3 8293 e381 abe3 81a1 e381 af0a でした。これは「こんにちは」のUTF-8そのものです。参考に LANG=ja_JP.UTF-8 で同じことをすると、バイト列は完全に一致しました。

結論：Claude Code はロケールに関係なく常にUTF-8を出力する。

したがって画面が文字化けして見えるなら、原因は次のいずれかです。
・端末エミュレータの文字エンコーディング設定がUTF-8になっていない
・使用中のフォントに日本語グリフが無い（□や豆腐になる）
・端末のGPUアクセラレーションによるグリフ崩れ（Claude Code 自身が「Corrupted terminal glyphs? Disable terminal GPU acceleration in settings」という案内文を持っています）
・SSH越しで、接続先ではなく手元の端末側の設定が古い

対策はすべて端末側にあります。CLI にロケール環境変数を渡しても、渡す前と1バイトも変わらないものは直しようがありません。

日本語のファイル名も検証しました。日本語ファイル.txt を作り、LC_ALL=C の環境で Read ツールに読ませたところ、中身の「これはテストです」がそのまま返ってきました。ファイル名・ファイル内容ともに日本語の取り扱いに問題はありません。

文字化けの原因を切り分ける図。Claude Code側の出力は常にUTF-8で固定されており、化けて見える原因は端末のエンコーディング設定・フォントの日本語グリフ不足・GPUアクセラレーションによるグリフ崩れのいずれかであることを示す。
出力バイト列がロケールに依存しない以上、切り分けの起点は常に端末側になる。

日本語で使うと何が変わるか——トークン1.57倍の実測

ここからが、日本語で使うことの実質的なコストです。

日本語は文字数が短くなる代わりに、トークンあたりの情報密度が英語より大幅に低い言語です。これを Anthropic の count_tokens エンドポイントで実測しました。同じ意味の英文と和文を4組用意し、それぞれのトークン数を数えています（メッセージ構造分のオーバーヘッド6トークンは差し引き済み）。

# 内容 英語トークン 日本語トークン 比 英語文字数 日本語文字数
1 短い指示文 10 15 1.50 27 17
2 リポジトリ運用ルール（3文） 61 89 1.46 190 120
3 git commit の説明 36 71 1.97 149 87
4 テスト失敗時の手順 43 61 1.42 141 73
— 合計 150 236 1.57 507 297

読み取れることは3つあります。

1つ目。日本語は文字数で41%短いのに、トークンは1.57倍かかります。 「日本語のほうが短いから安い」という直感は逆です。

2つ目。1トークンあたりの文字数は英語3.38文字・日本語1.26文字で、およそ2.7倍の差があります。日本語はほぼ1文字1トークンに近い消費の仕方をします。

3つ目。比率は文章によって1.42〜1.97とばらつきます。 英語の技術用語（git commit、snapshot）をそのまま含む文ほど英語側が有利になり、比が開きます。逆に固有名詞やコマンド名が多い文では差が縮まります。「日本語は一律1.6倍」と覚えるのではなく、1.4〜2.0の帯で考えるのが実態に近いです。

英語と日本語の1トークンあたり文字数を比較した棒グラフ。英語は入力3.38文字・出力3.30文字、日本語は入力1.26文字・出力1.13文字で、入力側と出力側で同じ密度差が再現していることを示す。
入力側（count_tokens API）と出力側（応答の実使用量）を別々に測っても、同じ密度差が出た。

日本語 CLAUDE.md の固定費は 44,036 トークンだった

この差が最も効いてくるのが CLAUDE.md です。CLAUDE.md はセッションのたびに全文が読み込まれる固定費なので、言語の選択がそのままコンテキストの目減りになります。

当サイトのリポジトリの CLAUDE.md（日本語）を実測しました。

項目 実測値
文字数 57,952 文字
かな・漢字の割合 44.6%（25,844文字）
トークン数 44,036 トークン
1トークンあたり 1.32 文字

セッションを開いた瞬間に44,036トークンが埋まるという意味です。上の1.57倍という比率をそのまま当てると、同じ内容を英語で書いた場合はおよそ28,000トークン相当になります。差の約16,000トークンは、丸ごとコンテキストの余白として使えたはずのものです。

ただしこれは「英語で書け」という結論ではありません。

CLAUDE.md は人間が読んで保守するファイルです。日本語チームが英語で規約を書けば、読み違いと更新漏れというトークンでは測れないコストが発生します。実際に効くのは言語の切り替えではなく、冗長な説明を削って規約だけを残すことです。トークン削減そのものの手法はClaude Code トークン節約プラグイン比較｜削減率と導入コストで選ぶ5ツールに別途まとめています。

出力側でも同じ密度差が出る

ここまでは入力（プロンプトやCLAUDE.md）の話でしたが、Claudeが返す文章にも同じ性質が効きます。応答トークンは課金対象であり、かつ会話履歴としてコンテキストにも積まれるので、こちらも実測しました。

同じ質問（Explain what a git rebase does and when to prefer it over merge.）に「ちょうど3文で答える」という制約をかけ、応答言語だけを切り替えて --output-format json で使用量を取得しています。

応答言語 出力トークン 応答の文字数 1トークンあたり
英語 229 755 文字 3.30 文字
日本語 228 257 文字 1.13 文字

出力トークン数はほぼ同じ（229 対 228）なのに、書かれた分量は英語が約2.9倍という結果です。1トークンあたりの文字数 3.30／1.13 は、入力側で測った 3.38／1.26 とほぼ一致しました。入力でも出力でも、日本語は同じ密度差を負うことになります。

言い換えると、同じトークン予算で受け取れる情報量は日本語のほうが少ないわけではなく、「同じ分量の日本語を受け取るには約2.9倍のトークンを払う」という関係です。長い設計方針の説明を毎回日本語で出力させると、その分だけ会話履歴が早く膨らみ、自動コンパクトの発火も早まります。

この計測の限界（n=1）

出力側の計測は各1回ずつで、応答内容は完全に同一ではありません（3文という制約は揃えていますが、書かれる情報の粒度までは統制していません）。入力側の4組の計測と数値が一致したことをもって「同じ傾向が出力側にも現れる」と述べていますが、倍率を小数第2位まで信頼できる精度の測定ではありません。 桁として2〜3倍の差がある、という読み方が安全です。

flowchart TD A["日本語で使いたい"] --> B{"何を日本語にしたいか"} B -->|"TUIの文言
（Auto-compact など）"| C["不可能
ja-JP ロケールが存在しない"] B -->|"Claudeの応答"| D{"恒久的に固定したい？"} D -->|"はい"| E["CLAUDE.md に
「応答は日本語で」と記載"] D -->|"単発でよい"| F["--append-system-prompt
で指定"] B -->|"画面の文字化けを直したい"| G["端末側の問題
エンコーディング/フォント/GPU"] E --> H["固定費 44,036トークンの例
日本語は英語比 1.57倍"] F --> H

Claude Codeの日本語利用でよくある詰まりどころ

実測で確認できた範囲の落とし穴を、原因のレイヤーごとに整理します。

症状 実際の原因 対処
設定したのにUIが英語のまま 日本語ロケールが存在しない（ja-JP 0件） 仕様。応答だけが日本語化の対象
途中から英語に戻る 英語のログ・READMEを読ませて文脈が英語に傾いた CLAUDE.md に応答言語を明記して固定する
LANG を変えても何も起きない ロケールは応答言語に関与していない CLAUDE.md か --append-system-prompt を使う
日本語が □ や ? になる 端末のフォント／エンコーディング 端末側を修正。CLI 側の出力は常にUTF-8
枠線やグリフが崩れる 端末のGPUアクセラレーション 端末設定で無効化（CLI自身が案内文を持つ）
変換確定のEnterで送信されてしまう IMEの確定Enterと送信Enterが同じバイト（CR） 改行キーを別に割り当てる

最後の項目だけは端末設定でもCLAUDE.mdでも解けません。日本語入力で文章を打っているとき、変換を確定するEnterがそのまま送信になってしまう問題です。これは Claude Code から見るとIMEの確定Enterも送信Enterも同じ \r の1バイトで、区別する手段が原理的に無いことに起因します。実際にPTY越しにバイト列を送って確認したところ、日本語の直後に \r を送った場合も通常どおり送信が発火しました。

対処は「Enter以外のキーを改行に割り当てて、送信と入力を別のキーに分ける」ことになります。どのキーがどのバイト列を送り、Claude Code がそれをどう解釈するかは実測で表にできるので、Claude Codeで改行する方法｜Shift+Enterが効かない原因をバイト列で特定し端末別に対処するに分離してまとめました。

まとめ——「設定で日本語にする」という発想を捨てる

実測の結論を並べ直します。

・Claude Code に言語設定は無い。 CLIオプション62個中0個、バイナリに ja-JP / ja_JP は0件（en-US は40件）
・ロケール環境変数は応答言語に関与しない。 同一プロンプトのA/Bで返答が1文字も変わらなかった
・効くのは CLAUDE.md と --append-system-prompt の2つだけ。 どちらも英語の質問に対して日本語で返る
・文字化けはCLI側の問題ではない。 LC_ALL=C でも出力バイト列はUTF-8で、ja_JP.UTF-8 と完全一致
・日本語はトークンを1.57倍消費する。 文字数は4割少ないのに逆転する。当サイトの日本語CLAUDE.mdは44,036トークンの固定費
・IMEの確定Enterによる誤送信だけは別問題。 バイト列が送信Enterと同一で、キー割り当てでしか解けない

日本語で使うこと自体には何の障害もありません。ただし「アプリの設定画面で言語を切り替える」というモデルは Claude Code には当てはまらず、指示として渡すのが唯一の経路です。そしてその指示を含む文脈は、英語で同じことを書くより1.5倍前後のトークンを食う——このコストを見込んだうえで、CLAUDE.md を短く保つのが実務上の落としどころになります。

参照ソース