結論から言うと、Claude Codeで「どのモデルで走るか」は、一度指定したら終わりの設定ではありません。既定値は更新で動き、同じ指定でも経路によって解決先が変わることがあります。だから無人運用では、モデルの指定に加えて切替そのものを検査対象にする必要がある——そのための道具が、2.1.251で追加されたPreModelSwitch / PostModelSwitchフックです。
私は日次のRoutineを複数、Claude Codeの上で無人運用しています。コマンドの実行はhooksで検査し、公開前の審査はcriticサブエージェントに分離してきましたが、「どのモデルで走っているか」だけは検査の外側にありました。8月末から9月頭のchangelogを追っていて、ここを管理下に置く必要があると考えが変わったので、その整理を書きます。
既定モデルは動く——Fable 5.1への切り替わりで起きたこと
2026-09-01リリースの2.1.257で、Claude Fable 5.1（claude-fable-5-1）が既定のFableモデルになりました。1Mコンテキストで、単価は入力$10/出力$50 per Mtok、キャッシュ読み出しは$0.25/Mtokです。
Claude Code Changelog（公式）Release notes for Claude Code, including new features, improvements, and bug fixes by version.code.claude.com
ここで注目したいのは新モデルの性能ではなく、既定値の動き方です。同じリリースノートに、gateway経由のセッションでは fable / best の指定が当面Fable 5のまま解決される、という記述があります。gateway側が未対応のため、新モデルを使うには /model での明示選択が必要とのこと。
つまりこういうことです。自分では何も変えていないのに、CLIで走るセッションとgateway経由のセッションで、同じ「fable」という指定が別のモデルに解決される期間が生まれる。既定値に乗っている限り、モデルはバージョンアップで動き、しかも経路によって動き方が揃わない。
対話で使っている分には、これは大きな問題になりません。挙動が変われば人間が気づくからです。問題は無人運用です。Routineは深夜や早朝に人が見ていない場所で走ります。モデルが変われば、出力の傾向も、トークン単価も、プロンプトキャッシュの前提も変わる。それが「気づいたら変わっていた」という形で起きるのが一番困ります。
キャッシュとコストの観測については別記事で書いたとおり、入力コストはモデル単価よりキャッシュヒット率で決まります。モデルが切り替わるということは、この観測の前提が丸ごと動くということでもあります。
Claude Codeのプロンプトキャッシュ入門｜エージェント運用のコストを観測して設計するClaude Codeを定時実行で運用するときのAPIコストを左右するプロンプトキャッシュの仕組みを解説します。キャッシュが静かに切れる箇所、2026年8月末に追加された/costのキャッシュ行やエージェント別cacheTtlなどの観測・制御手段、日次運用での設計判断をまとめます。www.tentspace.net
hooksの制御対象が「コマンド」から「モデル選択」へ広がった
その4日前、2026-08-28の2.1.251で、PreModelSwitchとPostModelSwitchというフックイベントが追加されています。モデル切替のタイミングでフックが発火し、切替をブロックする・確認を取る・注記を付けるという3つの介入ができます。
これまでのhooksが見ていたのは、主にツール呼び出しとコマンドでした。私もPreToolUseフックでBashコマンドを実行前に検査し、破ってほしくない操作をコード側でブロックする構成を運用しています。ただ、その検査対象に「どのモデルで走るか」は含まれていませんでした。含める手段がなかった、が正確です。
Claude Codeのhooksで自動運用に禁止ラインを引く｜Bashガード実装記録Claude Codeのhooksで、エージェントに破らせたくない操作をコードとして強制する実装記録。PreToolUseフックの設定、Bashコマンドを検査するガードスクリプト、exit code 2でブロックする仕組み、正規表現ルールの設計と限界まで、実運用中の構成をそのまま解説します。www.tentspace.net
PreModelSwitchの追加で、モデル選択がコマンドと同じ「実行前に検査できる対象」になりました。これは私にとって、権限設計の考え方の答え合わせでもありました。エージェントの運用ルールは、プロンプトに書いて守ってもらうのではなく、破れない仕組みとして外側に置く。「このRoutineはこのモデルで走る」という決めごとも、指示文ではなくフックで強制できるようになった、ということです。
無人運用でどう組むか——固定と検査の2段構え
ここからは私の設計判断です。方針は2段構えにしています。
- 公開系のRoutineはモデルを固定する。 記事やSNSの公開原稿を作る工程は、出力の傾向が変わると審査基準との整合が崩れるので、既定値に乗せず明示的にモデルを指定します。新モデルが出ても、公開系はすぐに乗り換えない
- 切替イベントを検査する。 固定していても、フォールバックや設定変更で切替が起きる余地はあります。PreModelSwitchフックで、意図しない切替をブロックするか、少なくとも注記としてログに残す
正直に書くと、2の実装はまだ入れていません。今の構成はモデルの指定までで、切替の検査は未実装です。次にやるのは、PreModelSwitchフックを注記モードで仕込んで、切替が実際に何回発火するかを数えること。ブロックから入らないのは、発火頻度が分からないまま止めると、正当な切替（フォールバックなど）まで殺して別の障害を作りかねないからです。まず観測、それから強制。Bashガードのときと同じ順番です。
Fable 5.1への乗り換え自体も、今はしない判断です。単価表では魅力的に見えます。特にキャッシュ読み出し$0.25/Mtokは入力単価の40分の1で、定時実行のRoutineとは相性がいいはず。ただ、自分のRoutineのキャッシュヒット率をまだ実測していない段階で単価を比べても、判断材料になりません。先にやるのは測る側。数字が出てから、自分の金額に換算して決めます。
モデル選択を「コードの外」で管理する流れ
視野を少し広げると、モデル選択をアプリケーションコードから引き剥がして、切替をゲートウェイなどの制御面で管理する構成の検討は、コーディングエージェントをチームで使う文脈でも進んでいます。
チームでcoding agentを使うためのAI Gatewayとルーターの理想形（DevelopersIO）coding agent のチーム利用に要る AI Gateway を課金経路・窓口・振り分け・実行側・観測の五層に分け、Claude Code の配備 6 経路と構成 7 パターンを比べました。LiteLLM 一台に 3 種のエージェントを通した帰属・予算・header 転送の実測も添えました。dev.classmethod.jp
個人の無人運用でゲートウェイまで立てるのは大げさですが、問われていることは同じです。どの工程をどのモデルで走らせ、切替を誰がどこで制御するか。 Claude Codeの場合、その制御点がhooksという形でエージェント本体に入った、というのが今回の変化でした。
モデルの既定値は、これからも動きます。それ自体は進化なので歓迎です。ただ、無人で走らせている側は「動くもの」として扱う設計が要ります。指定して終わりではなく、固定を宣言し、切替を観測し、必要なら止める。コマンドに対してやってきたことを、モデル選択にも広げる——今回の私の結論です。