Claude Code のモデルは画面に出ないまま切り替わる — 「検証は上位モデルで死守」を崩しうる設定1行を、公式仕様789行の通読で見つけた

はじめに

AIコーディングアシスタントの運用方針として、「設計判断・検証作業には上位モデルを惜しまず使う。コストを理由に格下げしない」と決めていた。この方針と、設定ファイルにずっと前から残っていた1行——モデルが混雑した時の代替先を指定する設定——が、実は正面から緊張関係にあることに、公式のモデル切替仕様を最後まで読むまで気づいていなかった。

最初にこの仕様書を開いた時は、必要そうな範囲だけをつまみ読みして切り上げていた。今回は約789行ある全文を最後まで読み、途中で切り上げていた箇所に何が書かれていたかを確認した。

部分読みで止めていた範囲

最初の通読では、モデルごとの思考の深さ（effort）の既定値と、コンテキスト窓の扱いだけを確認して終えていた。

The default effort is high on every model that supports effort, except Opus 4.7, which defaults to xhigh.

On the Anthropic API, [対応モデル群] always run with the 1M window.

ここまでは読んでいたが、組織のモデル許可リストやフォールバック連鎖の仕組み、そして環境変数やプロンプトキャッシュに関する設定の章は後回しにしていた。読んでいない範囲があることは自覚していたので、それを「未読」と明記したまま次の作業に進んだ。

残りを読んで見つかった、見えない切り替え経路

数日後、残っていた範囲を最後まで読んだ。最初に目を引いたのは、モデルが自動で切り替わる仕組みが画面に出ないという一文だった。

Claude Code doesn’t confirm the chain at startup and /status doesn’t display it. The notice shown when a switch happens is the first visible sign that a fallback is configured.

主モデルが混雑・利用不可などの理由で使えない時、代替のモデルへ自動的に切り替わる仕組みがある。だがその設定は起動時にも状態確認コマンドにも表示されず、実際に切り替わった瞬間の通知だけが、唯一の可視化手段になっている。

The switch lasts for the current turn only, so your next message tries the primary model first again.

切り替えは1回のやり取りだけで元に戻る。つまり、通知を見逃せば、そのやり取りだけ違うモデルで応答していたという事実に、後から気づく手段が無い。

もう一つの切り替え経路 ― 会話の中身だけで発火しうる

さらに読み進めると、安全のための自動判定によっても、モデルが切り替わることが分かった。

When a classifier flags a request and the flagged category has a fallback model, Claude Code re-runs the request on that model and shows a notice in the transcript.

Fallback can trigger on the first request of a session, before you send anything unusual, because the first request carries workspace context such as your CLAUDE.md content and git status. A repository that contains security or biology material can trip the classifier on that context alone.

セキュリティ関連の内容を含むリポジトリで作業しているだけで、何も変わったことを送っていないセッションの最初のやり取りから、この判定が発火しうる。しかも発火した後は、元のモデルに手動で戻すまで、そのセッションはずっと切り替わった側のモデルで動き続ける。

After a fallback, the session continues on the fallback model. To return to your original model, run /model.

この自動切り替えを止めて「その都度自分で選ぶ」に変えるための設定も、同じ仕様書に書かれていた。

To decide what happens each time a request is flagged, rather than switching automatically, run /config and turn off Switch models when a message is flagged, or set switchModelsOnFlag to false.

自分の設定を実測する

思い込みで済ませず、実際の設定ファイルの該当箇所を確認した（2026-08-24実測・実装固有の値は本題に関係ないため割愛）。

{
  "fallbackModel": ["sonnet", "haiku"],
  "switchModelsOnFlag": false,
  "autoCompactWindow": 200000
}

fallbackModel に代替先が2段構えで設定されていた。仕様書を読む前は、この設定がいつ・誰の判断で入ったのかを説明できなかった。「検証・設計判断には上位モデルを惜しまない」という方針を掲げながら、混雑時には黙って下位モデルへ切り替わる設定が同居していたことになる。switchModelsOnFlag はすでに false（自動切り替えではなく、その都度確認する側）に設定済みだったことも、この実測で確認できた。

図 ― どこで、何が、どのモデルへ切り替わるか

主モデルでやり取り中
      │
      ├─▶ 経路①: 主モデルが混雑・利用不可
      │       └─ フォールバック連鎖(設定済みの代替先)へ、そのやり取りだけ切り替え
      │             └─ 起動時にもステータス確認コマンドにも表示されない(公式)
      │                   └─ 唯一の可視化手段は「切り替わった瞬間の通知」のみ
      │                         └─(戻りエッジ)→ 次のやり取りでは主モデルへ自動的に復帰
      │
      └─▶ 経路②: 安全のための自動判定が会話の中身に反応
              └─ セッション最初のやり取り(作業ディレクトリの情報を含む)だけでも発火しうる
                    └─ 発火後は、手動で戻すまでその代替モデルのままセッションが継続
                          └─ 自動で切り替えるか・都度確認するかは設定で選べる(公式)
                                └─ 実測: 都度確認する側に設定済み

縦の流れが「主モデルでのやり取りから、切り替えが起きて元に戻るまで」、横の分岐が「混雑によるものか、安全判定によるものか」という2つの発火条件、一番下の入れ子が「自動か手動か」という制御の選択と、実際の自分の設定を突き合わせるループになっている。

分かったことと、まだ分からないこと

全789行を通読して確定したのは、次の3点だった。

確認した点	結果
モデル切り替えの通知が画面に出ないのは、観測の失敗か仕様か	仕様どおり。通知は切り替わった瞬間だけに出る設計
安全判定によるモデル切り替えが、会話の中身だけで発火するか	発火しうる（公式明記）。ただし発火の実例は未確認
自分の環境が自動切り替えか都度確認かのどちらに設定されているか	都度確認する側に設定済み（実測で確認）

一方で、混雑時のフォールバック設定がいつ・何のために入れられたのかは、今回の通読だけでは分からなかった。仕様を読むことと、自分の環境の履歴を辿ることは別の作業であり、後者はまだ手を付けていない。「検証は上位モデルで」という方針と、この設定がこれまで実際に何回衝突したのかも、通知ログを遡らない限り確定しない——これも実測してから書く。

Claude Code のオーケストレーター用サブエージェントを廃止した理由——公式harness仕様に基づく構造的な3つの制約

Claude Code の output style はサブエージェントに継承されない——公式仕様と実地検証

通読して分かったことより、通読しても分からなかったことの輪郭がはっきりしたことの方が大きかった。仕様は「何が起こりうるか」しか教えてくれない。自分の環境で実際に何回それが起きたのかは、仕様書ではなく通知ログの側にある。