Claude Codeの返信が急に英語になる原因と対処法
CLAUDE.mdで日本語を指定していてもClaude Codeが急に英語で返信する症状の原因と対処を、GitHub issueの報告から読み解きます。
Claude CodeのCLAUDE.md日本語指定が英語ツール出力の直後に効かなくなる
Claude Codeが急に英語で返信し始めるのは、設定ミスとは限らず、既知の報告がある挙動です。確実な修正はまだなく、英語の出力を大量に読ませた直後のツール呼び出しの合間で出やすい傾向があります。まず language の綴りと出力スタイルを確かめ、それでも出るなら英語を読む作業を切り出す手が使えます。日本語で使うための設定の全体像はClaude Codeを日本語で使う設定にまとめています。
~/.claude/CLAUDE.md や settings.json の language キーで日本語を指定していても、Claude Codeの返信が突然英語になることがあります。GitHub issue #96326には、この症状の再現報告が2026年9月23日から複数件寄せられています。多くの報告で、英語のツール出力(英語の仕様書、サブエージェントのレポート、コードレビュー結果、コミットメッセージなど)を読んだ直後に返信が英語へ切り替わっています。
起票したユーザーは、ユーザーレベルのCLAUDE.mdと会話言語の設定の両方で「必ず日本語で返信する」と指定していました。それでも長いエージェントセッションの中で、英語の仕様書やサブエージェント報告を読んだ直後の返信が繰り返し英語化しています。3回訂正しましたが、訂正の直後の返信は日本語で始まるものの、同じターンか次のターンで英語に戻りました。
同じ起票者の追記を読むと、引き金は大きな英語テキストに限りません。コミットメッセージやPythonのheredoc編集のような地味なツール出力のあとでも出ています。ユーザー自身が日本語で書いた短い依頼への返信が、全文英語になった例もあります。コンパクト(会話の圧縮)の後、権限が拒否された直後、日本語の進捗行が続いた後の最終報告でも起きたと書かれています。
報告者5人の環境と、英語化が出た場面
issueには16件以上のコメントが付き、複数のユーザーが独立に同じ挙動を報告しています。
| 報告者 | 環境 | 対象言語 | ドリフトの引き金として観測されたもの |
|---|---|---|---|
| 起票者 | 環境Linux, Opus 5.5(1Mコンテキスト) | 対象言語日本語 | ドリフトの引き金として観測されたものgit commit・Pythonのheredoc編集など、地味な英語ツール出力でも発生 |
| WSL2・Conciseの報告者 | 環境WSL2, Opus 5.5, Concise | 対象言語日本語 | ドリフトの引き金として観測されたものConciseスタイルのリマインダー文言。ただしDefaultスタイルでも英語コメント60行を読んだ後に再発 |
| Claude Desktopの報告者 | 環境Claude Desktop(macOS), Opus 5.5 | 対象言語日本語 | ドリフトの引き金として観測されたもの英語ツール出力・他セッションの英語メッセージ |
| ヘブライ語の報告者 | 環境Linux | 対象言語ヘブライ語 | ドリフトの引き金として観測されたもの英語のツール出力・長い英語のCLAUDE.md・スキル手順 |
| イタリア語の報告者 | 環境macOS, Concise | 対象言語イタリア語 | ドリフトの引き金として観測されたものツール呼び出し間の一行ステータスとサブエージェント報告の直後 |
ヘブライ語やイタリア語でも同じパターンで再現しており、日本語だけの不具合ではありません。
起票者は、英語化が出やすい場所として、ツール呼び出しの合間の一行進捗と最終サマリーを挙げています。
自分の環境で同じ症状かを切り分ける
手元で同じ挙動が出るかは、次の順に見ると絞り込めます。報告の比較に使われているのはバージョン・モデル・出力スタイルの3点なので、まずそれを控えます。
症状の切り分け手順
- 1
バージョンとモデルを控える
報告された英語化率は、Claude Codeのバージョンとモデルの組み合わせで大きく違いました。インストール済みのバージョンは、シェルで確認できます。モデルは
/modelのピッカーで確認できます。 - 2
出力スタイルが意図どおりか見る
セッション内で
/output-styleを引数なしで実行すると、選べるスタイルと現在のスタイルが表示されます。settings.jsonのoutputStyleは大文字小文字を区別するので、explanatoryと書くとDefaultスタイルになります。 - 3
languageの綴りを確かめる
languageの値は検証されず、そのままClaudeに渡ります。"japanese"の綴りを誤っても、エラーにならないまま誤った指示が届きます。 - 4
英語を読ませた直後の短い行を見る
英語の仕様書やサブエージェント報告を読ませたあと、Claude Codeが出す一行進捗の言語を確認します。長いタスクの最終サマリーも同様に見ます。
バージョンの確認は次のとおりです。出力は、この記事の確認時点で手元にインストールされていたものです。
claude --version
# 2.1.303 (Claude Code)最初の報告に載っているバージョンは2.1.280〜2.1.282です。その後も10月7日には2.1.292での報告があり、症状は2.1.280以降のバージョンをまたいで続いています。
バージョンかモデルか — 数字と報告者の見立て
WSL2の報告者とClaude Desktopの報告者は、セッションの文字起こしを数えた値を載せています。ヘブライ語とイタリア語の報告者は、モデルごとの英語化率を報告しています。いずれも各報告者の環境の観測値で、公式ベンチマークではありません。
報告された英語返信の割合
WSL2の報告者(2.1.280)
約2%
Opus 5.5。3/141
WSL2の報告者(2.1.281)
約45%
Opus 5.5。14/31
ヘブライ語の報告者
1.1% → 8.5%
Opus 5から5.5へ切り替え
イタリア語の報告者
0.3% → 15.3%
Opus 5から5.5へ切り替え
Claude Desktopの報告者の環境でも、2.1.280では5/119(約4%)、2.1.281では11/98(約11%)と、CLIを上げた後の割合が上がっています。ヘブライ語の報告者の2.1.282(22件中7件)は、サンプル数が小さい点に注意が必要です。
原因がCLIバージョンなのかモデルなのかは、報告者の間で割れています。
原因をめぐる2つの見方
バージョン起因
モデルは09-23からOpus 5.5のまま変わらず、CLIを2.1.281に上げた日から悪化しました。Claude Desktopの報告者の数字も同じ向きです。
モデル起因
Opus 5は2.1.281で0/82でしたが、Opus 5.5は2.1.280・2.1.281・2.1.282のすべてで英語化しました。ヘブライ語の報告者もモデルを切り替えた時点で急上昇しています。
ただし、モデル起因説と合わない行もあります。イタリア語の報告者の表には、claude-opus-5の2.1.278で238件中13件(5.5%)、claude-opus-5-5の2.1.281で521件中20件(3.8%)という行が並びます。報告者自身も、版ごとの数字は各セッションの作業内容で大きく振れるのだろうと書いています。
Opus 5.5が加わったのは2.1.280で、モデルの更新とCLIの更新が同じ日に重なりました。#96601の起票者(繁体字中国語を出力スタイルで指定)も、モデルとCLIが同じ日に変わったため、CLIバージョンの可能性は外せないと書いています。
イタリア語の報告者は、内訳を関連issue #96601に書いています。#96326はopenのままで、最後のコメントは10月16日です。#96601もopenのままです。
10月の追加報告 — 英語化はツール呼び出しの合間に出る
10月に入ってからは、韓国語・繁体字中国語・ドイツ語の報告者も同じ症状を書いています。日本語だけの問題ではありません。韓国語と繁体字中国語の報告では、Opus 5.5で特に多く出ています。
韓国語の報告者は、Opus 5.5で英語になったテキストブロックを、直前の項目で分けて数えました。直前がツール結果なら13.1%(194/1,484)、自分のメッセージの直後なら5.6%(10/178)です。ターンの最後の返信は1.5%(8/528)にとどまり、英語は主に途中の一行メモで出ています。
繁体字中国語の報告者(427セッション)も、ツール結果の直後のほうが英語になりやすいと書いています。ツール呼び出しが50回を超えるターンでは31%に上がっています。モデル別の英語の割合は、Opus 5.5が23.8%、Opus 5が1.7%です。
繁体字中国語の報告者は、Fable 5.1でも9月は1%未満だった英語の割合が、10月に12%まで上がったと書いています。Opus 5.5だけの現象とは言い切れません。
日本語の利用者にとっての目安は、最終回答より、作業中に流れる進捗行を見ることです。最終回答だけ確認していると、英語化に気づきにくくなります。
Conciseの注釈が原因という説は撤回された
WSL2の報告者は当初、Concise出力スタイルが有効なときにツール結果とユーザーメッセージの末尾へ毎回(1セッションで約90回)挿入される英語のリマインダー文(「Concise output style is active. Be concise: lead with the result, skip preamble and narration, keep only what the user needs.」)を引き金と考えました。同じセッションでスタイルを切り替えて数えると、Concise区間は日本語17・英語14、Default区間は日本語4・英語0だったためです。切り戻した後も向きは同じで、Conciseに戻した区間は日本語6・英語1、二度目のDefault区間は日本語4・英語0でした。合計はConciseが日本語23・英語15、Defaultが日本語8・英語0で、英語が出たのはConciseの区間だけです。ただし件数は小さな値です。同じ英語読み取りタスクを名前付きサブエージェントとフォークに渡した4回の実験でも、返信と思考ブロックはすべて日本語のままでした。フォークはConciseのシステムプロンプトを引き継ぎますが、その文字起こしにリマインダーは0回しか現れません。Defaultのメインセッションにも付きません。フォークの実行は、リマインダーを受けない条件での結果です。
ところが追記のコメントで、この仮説は本人に弱められています。Defaultスタイルでリマインダー文が付かない状態でも、英語のコメントを60行含むシェルスクリプトを読んだ直後に英語の返信が出たためです。Default区間のゼロは、長い英語を読む場面が無かっただけかもしれないと書き、「Defaultへの切り替えは確実な修正ではない」としています。
出力スタイルを使っていない環境でも、同じ症状が報告されています。台湾向け繁体字中国語の報告者は、Windows 11のClaude Desktop(Codeタブ)に同梱されたClaude Code 2.1.280・2.1.281で試しました。指示は ~/.claude/CLAUDE.md だけにあり、カスタム出力スタイルも language 設定もありません。
集計では、claude-opus-5(CLI 2.1.219〜2.1.275)が175ターン中英語0、ほかのモデルが185ターン中1、claude-opus-5-5が21ターン中10(48%)でした。英語になった10ターンは、Opus 5.5の5セッションのうち2つに集中しています。1つのセッションでは、7ターン連続で英語でした。
長さだけでも説明がつきません。ツール呼び出しが209回、コンテキストが約94.5万トークンに達した1ターンは、最後まで中国語で終わっています。ハーネスが出す Async agent launched successfully… のような定型の英語通知も、引き金になりうると報告者は書いています。
Anthropicの担当者のコメントは付いていません。原因は「直前に読んだ長い英語テキストが言語指示に勝つことがある」という利用者側の仮説の段階です。
Concise自体は、公式ドキュメントによるとDefaultに加わる4つの組み込みスタイルの一つです。応答の冒頭で結果を述べ、前置き・途中経過の説明・締めの振り返りを省きます。Conciseの利用にはv2.1.237以降が必要です。CLAUDE.mdとの役割の違いは出力スタイルとCLAUDE.md・Skillsの違いに書いています。
状況ごとに取れる手と、報告から見える限界
Anthropicから原因の説明はなく、確実な修正方法はありません。報告から拾える手を、状況別に並べます。
| 状況 | 取れる手 | 報告から見える限界 |
|---|---|---|
| 進捗行や最終報告が英語になった。英語出力を大量に読ませた直後のターン | 取れる手返信の言語を目視で確かめ、英語なら短い日本語で言い直させる | 報告から見える限界イタリア語の報告者によると、訂正が効くのは1〜2文まで |
| 英語のログ・仕様・報告を大量に読ませる作業 | 取れる手サブエージェントやフォークに切り出す | 報告から見える限界WSL2の報告者による4回の実験のみ。一般化はできない |
| Conciseを使っている | 取れる手Defaultに戻して頻度を見る | 報告から見える限界WSL2の報告者自身が、完全には止まらないと訂正している |
| 最終返信が英語のまま終わる | 取れる手Stopフックで最終メッセージを判定し、英語なら言語を指定して言い直させる | 報告から見える限界繁体字中国語の報告者の見立てでは、途中の進捗行には効かない |
| 毎ターン言語ルールをhookで注入している | 取れる手追加の注入では解決しない | 報告から見える限界Claude Desktopの報告者は注入済みでも英語化が止まらなかった |
ドイツ語の報告者は、ツール出力が英語中心のときだけ一行の言語リマインダーを注入するPostToolUseフックを追加しましたが、効果の数字は「まだ早い」として出していません。
ヘブライ語の報告者は、長い英語のCLAUDE.mdやスキル手順も英語化の引き金に挙げています。英語で書いた指示ファイルを日本語の運用に持ち込んでいる場合は、読み込まれる英語の分量そのものが影響する可能性があります。これは報告者の見立てです。
CLAUDE.mdの長さと構成は、公式ドキュメントにも手がかりがあります。長いファイルはコンテキストを多く消費し、守られる度合いも下がります。一部のコードにしか関係しない指示は、該当ファイルを扱うときだけ読み込まれるパス限定ルールへ移せます。@ によるimportは長いファイルの整理には役立ちますが、読み込まれるファイルも起動時に載るため、コンテキストの消費は減りません。
セッション内で /doctor prompt-audit を実行すると、古いモデル向けに書かれた指示、存在しないファイルやコマンドへの参照、互いに矛盾するファイルといった問題を探します。英語の指示ファイルを点検する手段になります。
languageとCLAUDE.mdは指示であって強制ではない
settings.json の language キーに "japanese" のような値を渡すと、その値がそのまま「常にその言語で応答する」という指示としてClaudeに渡ります。
{
"language": "japanese"
}応答の言語に固定リストはなく、Claudeが読める言語名であれば動作します。同じ値は、音声入力(こちらは対応言語が決まっています)とセッションタイトルの言語にも使われます。
CLAUDE.mdも位置づけは同じです。公式ドキュメントはCLAUDE.mdを「コンテキストであって、強制される設定ではない」と説明しています。指示が具体的で短いほど守られやすく、1ファイル200行未満が目安とされています。issueの報告者の多くは language とCLAUDE.mdを併用していたので、長いCLAUDE.mdを短くするだけでは足りない可能性もあります。設定の基本はClaude Codeの言語設定ガイドにあります。
フックも、言語に関しては強制手段になりません。UserPromptSubmitなどのフックが返す additionalContext は、システムリマインダーとして会話に挿入される文字列です。つまり、足されるのは指示の追加でしかありません。公式は、Claudeの判断にかかわらず動作をブロックしたいときにPreToolUseフックを案内しています。フックは動作の許可・拒否に向いた仕組みです。
フックの種類による届き方の違いも押さえておけます。UserPromptSubmitはプロンプトを置き換えられず、additionalContext を添えるだけです。Claudeは次のモデルリクエストでこのリマインダーを読みますが、チャット画面にメッセージとしては表示されません。
SessionStartの additionalContext は、最初のプロンプトより前に、会話の開始時へ1回入ります。毎プロンプトで再注入できるのはUserPromptSubmitのほうです。
注入した文字列は10,000字が上限で、フックがタイムアウトすると additionalContext を含む出力が破棄されます。注入したつもりで届いていない場合は、デバッグログで配信を確かめられます。
まとめ
Opus 5.5やFable 5.1を2.1.280以降で使う場合は、英語の長文を読ませる作業ほど返信の言語に注意が要ります。直ったかどうかは、issueの更新を待つ段階です。
参照した一次ソース
この記事の記述は、次の一次ソースと照合しています。更新時に参照先が変わった場合は一覧も更新します。