Fableであなたは損してます！モデル切り替えのベストプラクティスの実態実験
良かれと思って、Claude Code のモデルを切り替えていました。
「普段は軽いモデルで、ここぞというときだけ Fable」。節約のつもりです。重い仕事のときだけ賢いモデルを呼び出して、あとは軽く済ませる。誰でも思いつく、まっとうな考え方に見えます。
自分のログを 770 セッションぶん掘って測ったら、逆でした。
切り替えるたびに、それまでの会話の 86% を読み直させていました。約3か月半で、のべ 3億トークン。
正解は、切り替えることではありませんでした。切り替えずに、呼ぶことです。
公式ドキュメントには、ずっと前から書いてありました。先に同じことを言っている人もいました。ただ、実際の使用ログで測った人はいなかったので、測りました。
（ちなみにこの記事は、書いている途中で一度だけ「賢い相談役」を呼んでいます。切り替えずに。種明かしは最後に。）
なお、これはあくまで私が調べた限りの情報です。間違っているところがあるかもしれません。お気づきの点があれば、ぜひ教えていただけると助かります。
押すたびに、会話の86%が書き直されていた
Claude Code には /model というコマンドがあります。会話の途中でモデルを変えるためのものです。
私はこれを、1,096回押していました。770 セッションのうち 295 セッションで使っています。3回に1回以上のペースです。
そして、押した結果として実際にモデルが変わったのが 821 回。そのとき何が起きていたかを、ログの数字から拾いました。
それまでの会話の 86% が、書き直されていました。
ここで言う「書き直し」は、こういう意味です。AI は毎回、会話の最初から全部を読み直しています。ただし2回目からは「前と同じところは前の結果を使い回す」という仕組み（プロンプトキャッシュ）が働くので、実際にはほとんど読み直していません。その使い回しが効かず、まっさらから読み直した割合が 86% だった、ということです。
ひとつ、言葉を正確にしておきます。会話の履歴そのものは、毎回きちんと送り直されています。AIが忘れているわけではありません。覚えていないのは、この使い回しの仕組みのほうです。そしてこの仕組みは、モデルごとに別々に持たれています。Opus 用の使い回しを、Fable は使えません。だから切り替えた瞬間に、まっさらからやり直しになります。
比べる相手がないと、この数字の意味が分かりません。だから、同じログの中から比較対象を取りました。
| 書き直された割合 | |
|---|---|
| モデルを切り替えた直後（821回） | 86% |
| 切り替えていない普通のやりとり（11.5万回） | 0.43% |
約200倍です。
普段は会話の 0.4% しか読み直していないのに、モデルを切り替えた瞬間だけ 86% を読み直す。中身は1文字も変わっていません。同じ会話です。
「時間が経ったからでは？」を潰しておく
キャッシュには寿命があります。しばらく放っておくと消えるので、「久しぶりに再開したから読み直しただけでは？」という疑いが当然出ます。
これは潰せました。同じ /model を押していて、モデルが変わらなかったとき（選択画面を開いて同じものを選び直した、など）と比べたのです。
| 5分以内に起きたことだけで比較 | 書き直された割合 |
|---|---|
/model を押して、モデルが変わった |
84.7% |
/model を押したが、モデルは変わらなかった |
1.8% |
操作は同じ。時間も同じ。違うのは「モデルが変わったかどうか」だけ。押したことでも、時間が経ったことでもなく、モデルが変わったことが原因だと、これで言い切れます。
行って戻っても、助からない
「じゃあ、すぐ元に戻せばいいのでは」と思いました。往路で作ったキャッシュが残っていれば、戻ったときに使えるはずです。
自分のログから、A→B→A と往復している組を 576 組見つけて調べました。
91% で、助かっていませんでした。
戻ったときに使い回せていたのは、1.5万〜2.5万トークンぶんだけ。これは会話の中身ではなく、毎回同じ土台の部分（AIへの基本指示やツールの一覧）です。肝心の会話本体は、まるごと読み直されていました。
つまり「ちょっとだけ別のモデルに聞いて、すぐ戻る」は、行きと帰りで2回ぶん読み直させる、いちばん損な形でした。
一番重かったのは、Fableへの切り替え
切り替え先ごとに、読み直された量を集計しました。
| 切り替え先 | 回数 | 読み直された合計 |
|---|---|---|
| Fable 5 | 351 | 1億2,800万トークン |
| Opus 4.8 | 229 | 7,509万 |
| Sonnet 5 | 142 | 5,929万 |
| Opus 5 | 75 | 3,120万 |
※ ほか、旧世代のモデルへの切り替えが24回。
回数でも量でも、Fable への切り替えが最多でした。
そしてここが効きます。Fable は、公開されている料金表の上で、いま一番単価の高いモデルです（100万トークンあたりの入力単価で Opus の2倍。公式のモデル一覧と料金）。同じ量を読み直すなら、Fable での読み直しがいちばん大きな処理になります。
「ここぞというときだけ Fable」——その「ここぞ」が、いちばん高くつく操作だったわけです。
正確に言うと、私は「お金」を損していない
ここは正直に書きます。
私は定額プランを使っています。だから、3億トークン読み直させたところで、請求書の金額は1円も変わっていません。「3億トークンを無駄にした」と書くと、財布が痛んだように聞こえますが、痛んでいません。
減ったのは、5時間ごとの利用枠と、待ち時間です。
公式ドキュメントには、こう書かれています。
Claude Code は毎回のリクエストで会話の全体を送ります。プロンプトキャッシュがあるので、その履歴はキャッシュ価格で読み直されます。つまり、1日中開いたままのセッションでは、一行の質問でも会話全体ぶんの使用量を引きます。
— Claude Code 公式ドキュメント「コストを管理する」
長い会話は、それだけで枠を食う。そこに切り替えが乗ると、キャッシュ扱いにならない読み直しとして、会話まるごとぶんが枠を食うことになります。
※ 説明のつかない例外が5件ありました。切り替えたのにキャッシュが効いている記録です。原因は突き止められませんでした。分からないものは、分からないと書いておきます。
公式は、ずっと前からそう書いていた
ここまで読んで「それ、あなたの環境が変なだけでは？」と思われたはずです。私もそう思って、公式ドキュメントを全部読み直しました。
書いてありました。 しかも、私が探していたよりずっと手前に。
あの確認画面は、警告だった
/model を押すと、確認を求められることがあります。「よろしいですか」と。私はずっと、何も考えずに押していました。
公式ドキュメントの /model の説明には、その理由がこう書かれています。
会話にすでに応答がある場合、モデル選択画面は確認を求めます。次の応答が、キャッシュなしで全履歴を読み直すことになるからです。
— Claude Code 公式ドキュメント「コマンド一覧」
あれは、ただの確認ではありませんでした。これから会話を丸ごと読み直しますよ、いいですね、という警告です。
「モデルは最初に決めて、途中で変えるな」
キャッシュの仕組みを説明したページには、こうあります。
それぞれのモデルが、自分専用のキャッシュを持っています。
/modelで切り替えると、次のリクエストは、内容がまったく同じであっても、会話履歴の全体をキャッシュなしで読み直します。
— Claude Code 公式ドキュメント「プロンプトキャッシュの使われ方」
同じページには、こんな助言まで添えられています。
セッションの冒頭で、モデルと effort（考える深さ）を決めてしまうこと。作業の途中での変更が少ないほど、キャッシュヒット率は上がります。
— Claude Code 公式ドキュメント「プロンプトキャッシュの使われ方」
Claude Code を作っているチームのブログには、もっと直接的に書かれていました。開発の教訓をまとめた項目のひとつです。
会話の途中で、ツールやモデルを変えるな。
— Anthropic 公式ブログ「Claude Code を作って学んだこと：プロンプトキャッシュがすべて」
「安いモデルに切り替えるほうが高くつく」
同じブログに、私がやっていたことをそのまま名指しした例があります。
プロンプトキャッシュはモデルごとに固有で、これが計算を直感に反したものにします。たとえば Opus で10万トークンの会話をしている最中に、簡単に答えられる質問をしたいとします。このとき、Haiku に切り替えるほうが、Opus に答えさせるより高くつきます。Haiku 用にキャッシュを作り直す必要があるからです。
軽いモデルに切り替えるほうが高くつく。節約のつもりの操作が、逆だったわけです。
そして、そのすぐ次の一文が答えでした。
モデルを切り替える必要があるなら、最良の方法はサブエージェントです。
— Anthropic 公式ブログ「Claude Code を作って学んだこと」
「上限に当たったからモデルを変える」も効かない
もうひとつ、思い込んでいたことがあります。「Fable の枠を使い切ったから Opus に移ろう」。これも効きません。
この利用枠はすべてのモデルで共有されています。したがって
/modelでモデルを切り替えても、使えるようにはなりません。
— Claude Code 公式ドキュメント「コストを管理する」
枠はモデルごとに分かれていません。切り替えても回復しないどころか、切り替えたぶんの読み直しで枠を余計に食います。
先に言っていた人がいました
正直に書きます。「モデル切り替えはキャッシュを壊すから損」「サブエージェントを使え」は、私の発見ではありません。
調べたところ、日本語と英語で少なくとも5件、すでに公開されていました。特にお二人は、この記事とほぼ同じ結論に到達しています。
Juan Andrés Núñez 氏（Wmedia）は、モデルの使い分けについてこう書いています。
私の振り分けはこうだ。ほとんどの仕事は Opus 5。本当に未知の領域に踏み込むときだけ Fable 5。そして Sonnet 5 はサブエージェントの中に住まわせる。主モデルには決してしない。
— Wmedia「Sonnet 5、Opus 5、Fable 5：私がどれを取るか、そして気を変える代償」
Abhishek Ray 氏（Claude Code Camp）は、実際に API に対して4つの実験を走らせた上で、こう結論しています。
セッションの途中でモデルを切り替えるな。別のモデルが必要なら、サブエージェントを使え。
— Claude Code Camp（Abhishek Ray）
私が読めた範囲では、この5件のどれも、実際の作業ログを測ってはいませんでした。Ray 氏の4つの実験は、仕組みを確かめるために組んだ実験です。「切り替えると損をする仕組みがある」ことは、そこで確かめられていました。
確かめられていなかったのは、普通に使っている人間が、その損を実際にどれだけ踏んでいるかです。1,096回押して、3億トークン。それが今回、初めて出た数字でした。
だから私の持ち場は、「新しいことを言う」ことではなく「言われていたことを、実際の使用ログで測る」ことです。測った結果、公式も先人も正しかった、というのがこの記事です。
同じくログから測った話: Opus 4.8の「court」問題 ── 本当に怖いのは、エラーが出ない故障でした
では、どうすればいいのか
実測と公式の両方から言えることを、効く順に並べます。
1. モデルは、セッションの最初に決めて、動かさない
いちばん基本で、いちばん効きます。公式がそのまま書いていることです。
決め方の目安はひとつだけ。その会話でいちばん難しい仕事に合わせて選ぶ。
会話が育つほど、途中での切り替えは重くなります。86% という割合は会話全体に掛かるので、長い会話であればあるほど損が大きい。朝いちばんに決めて、その日はもう触らないのが理想です。
2. 途中で別のモデルの知性が欲しくなったら、切り替えずに「呼ぶ」
公式の言葉どおりです。「モデルを切り替える必要があるなら、最良の方法はサブエージェント」。
サブエージェントは、別室に座っている別人だと思ってください。こちらの会話は見えていません。依頼文だけを持って、自分の部屋で考え、結果だけを持って帰ってきます。
公式ドキュメントにはこうあります。
サブエージェントを起動しても、親（本会話）のキャッシュは影響を受けません。親から見れば、サブエージェントの呼び出しと結果は会話の末尾に追加されるだけで、それより前の部分はそのまま残ります。
— Claude Code 公式ドキュメント「プロンプトキャッシュの使われ方」
これも測りました。サブエージェントを呼んだ直後、親の会話が書き直された割合です。切り替えたときと、同じ物差しで並べます。
| 操作 | 会話が書き直された割合 |
|---|---|
| モデルを切り替える（821回） | 86% |
| サブエージェントを呼ぶ（1,389回） | 0.93% |
| 何もしない普通のやりとり（11.5万回） | 0.43% |
約90倍の差です。そして「呼ぶ」は、何もしない普通のやりとりとほぼ変わりません。呼び出し1,389回のうち、94% が「書き直し5%未満」でした。会話が丸ごと作り直されたのは、1.8% だけです。
※ 呼ぶと 0.43% ではなく 0.93% になるのは、サブエージェントが持ち帰った報告の文章が会話の末尾に追加されるからです。これは「前の部分が壊れた」のではなく「後ろに足された」ぶんです。
返ってきた量も測りました。中央値 1,421 トークン。原稿用紙で7枚ぶんくらいです。
一方で、そのサブエージェントが別室で抱えていた文脈は中央値10万4千トークンでした。70倍以上を向こうで抱えて、こちらには7枚ぶんだけ返してくる。これが「呼ぶ」ということです。
3. 呼ぶときは、モデル名を必ず書く
ここが実測でいちばん驚いた落とし穴です。
サブエージェントのモデル指定は、何も書かないと「親と同じ」になります。つまり Opus で作業しているときに何も指定せずにサブエージェントを呼ぶと、Opus がもう一人増えるだけで、別の知性は借りられていません。
私のサブエージェント呼び出しのうち、17.6% はモデルの指定がありませんでした。少なくとも私の場合、その大半はただの書き忘れです。
なお、あとで出てくる「相談役ファイル」を1枚作って model を書いておけば、この落とし穴は構造ごと消えます。呼ぶときは名前を言うだけになるからです。
4. 相談が続くなら、5分以内に続けて呼ぶ
サブエージェント側のキャッシュは 5分 で切れます。本会話は1時間もつのに、子だけ5分です。
3,800件の呼び出しを、前の呼び出しからの間隔で分けて測りました。
| 前の呼び出しからの間隔 | 起動時にキャッシュが効いた割合 |
|---|---|
| 5分以内 | 38.3% |
| 5〜60分 | 13.9% |
| 60分超 | 4.2% |
きれいに減っていきます。5分という寿命が、そのまま数字に出ています。
聞きたいことが複数あるなら、思いついた順にバラバラ投げるのではなく、まとめて、続けて投げる。それだけで起動ぶんの読み込みが浮きます。
そしてここで、自分の失敗をもうひとつ白状します。Fable の呼び出しに限ると、起動時のキャッシュヒットは中央値ゼロでした。呼ぶ頻度が低くて、5分の中に収まっていなかったからです。156回呼んで、そのほとんどが毎回まっさらな起動でした。原則は正しくても、私はそれを守れていなかったわけです。
5. やってはいけないこと、2つ
枠を使い切ったからモデルを変える。 効きません。枠は全モデル共有です。
行って戻る往復。 実測で 91% は助かりませんでした。どうしても切り替えるなら片道です。
そして先人の知恵をひとつ。切り替える前に /compact で会話を短くしてから切り替えると、読み直す量そのものが減ります。順番が逆だと、長い履歴をまるごと読み直すことになります。ただし /compact は会話を要約に置き換えるので、細かい経緯は失われます。使うのは切り替えの直前だけにしてください。
6. ただし、正直に言っておくこと
サブエージェントはタダではありません。呼ぶたびに、向こうで起動ぶんの読み込みが発生します。先人の一人も「サブエージェントは別のキャッシュを持つから、コールドスタートは賢くなるだけで安くはならない」と留保しています。これは正しい指摘です。
だから、こう考えるのが正確だと思います。
サブエージェントは、節約の道具である前に、会話を汚さない衛生の道具です。
切り替えは、賢さを得るために自分の記憶を消す行為。呼び出しは、記憶を保ったまま他人の頭を借りる行為。安くなるのは、その結果にすぎません。
明日からの3行
- モデルは会話の最初に決めて、最後まで変えない。迷ったら、その会話でいちばん難しい仕事に合わせて選ぶ
- 途中で別の賢さが欲しくなったら、
/modelは押さない。「fable-advisor エージェントを使って、この設計を見てもらって」のように、名前で呼ぶ - その相談役がまだいないなら、一度だけこう頼む。「
~/.claude/agents/に、Fable を使う相談役 fable-advisor を作って」。書式は Claude が知っています。次からは呼ぶだけ
呼び方が分からない人へ（1分でできます）
難しい設定は要りません。Claude Code 本人に作らせるのが公式のやり方です（公式ドキュメント「サブエージェント」）。こう頼んでください。
~/.claude/agents/ に fable-advisor というサブエージェントを作って。
難しい判断について相談する相談役です。model は fable にして。
すると、こういうファイルが1枚できます。
---
name: fable-advisor
description: 難しい判断について相談したいときに呼ぶ相談役
model: fable
---
あなたは経験豊富な相談役です。……
あとは、相談したくなったときに「fable-advisor に相談して」と言うだけ。モデルは切り替わりません。
※ 作った直後に見つからないことがあります。~/.claude/agents/ がセッション開始前に存在しなかった場合だけ起きるので、Claude Code を再起動すれば解決します（公式ドキュメントにも明記されています）。なお /agents で対話的に作る方法は、v2.1.198 で廃止されました（CHANGELOG）。古い解説記事はまだこの方法を書いているので注意してください。
種明かし
冒頭に「賢い相談役を呼んでいます」と書きました。その話です。
この記事の構成は、Fable に相談して決めました。ただし /model では切り替えていません。先輩編集者という役どころで、サブエージェントとして呼びました。
相談役は、こちらの会話を一行も見ていません。依頼文だけを持って別室で考え、助言だけを返してきました。数字はこうです。
| 相談役が別室で抱えていた文脈 | 約7万9千トークン |
| こちらに返ってきた量 | 約2,400トークン |
| 約33分の1 |
こちらの会話は、向こうの7万9千トークンを一行も読み直していません。
そして返ってきた助言で、この記事の段の順番は実際に入れ替わりました。最初は「公式の説明 → 自分の実測」の順で書くつもりでしたが、こう言われたのです。
読者が一番知りたいのは「で、自分はどれだけ損してるの」です。そこに届く前に翻訳文の連続を読ませると、そこが最初の離脱ポイントになります。
この種明かしを最後に置いたのも、相談役の指示です。
自己言及はオチに使うと芸になり、マクラに使うと自慢になります。
段の順番も、この節の位置も、タイトルの原案も、相談役のものでした。
二度目の相談は、一度目から5分以内に送りました。サブエージェントのキャッシュは5分で切れるからです。上に書いた「4. 相談が続くなら、5分以内に続けて呼ぶ」を、そのまま自分でやったことになります。
つまりこの記事は、この記事が勧めていることを、全部やりながら書かれています。モデルは最初に決めて動かさず、別の知性が必要になったときは切り替えずに呼び、モデル名を明示して、5分以内に続けて呼ぶ。
そうやって書いた記事の結論が、「そうしたほうがいい」です。
この記事で参照した資料
すべて2026年8月に実際に開いて、原文を確認したものです。仕様は変わりうるので、気になった箇所はリンク先の原文もあわせてご確認ください。
Anthropic 公式
- Claude Code「プロンプトキャッシュの使われ方」 ── モデルごとにキャッシュが別であること、キャッシュを壊す操作と壊さない操作の一覧、サブエージェントと親のキャッシュの関係
- Claude Code「コマンド一覧」 ──
/modelの確認画面が出る理由 - Claude Code「コストを管理する」 ── 利用枠が全モデル共有であること、長い会話が枠を食う仕組み
- Claude Code「サブエージェント」 ── 相談役ファイルの作り方、
modelの既定が「親と同じ」であること - Claude Code「モデルの設定」 ──
opusplanの挙動、--modelフラグ - Claude Code「コンテキストウィンドウ」 ── 大きなファイル読み込みを別の文脈に留める話
- Anthropic ブログ「Claude Code を作って学んだこと：プロンプトキャッシュがすべて」 ── 「会話の途中でモデルを変えるな」「安いモデルに切り替えるほうが高くつく」「最良の方法はサブエージェント」
- Anthropic エンジニアリング「Effective context engineering for AI agents」 ── サブエージェントが数万トークン使って1,000〜2,000トークンで返すという記述
- モデルの一覧と料金 ── 各モデルの単価とコンテキストウィンドウ
- Claude Code CHANGELOG ──
/agentsの対話ウィザードが v2.1.198 で廃止されたこと
先に同じことを書いていた方々
- Juan Andrés Núñez「Prompt caching in Claude Code」（Wmedia） ── 「モデルと effort は最初に決めて、作業中は触るな」
- Juan Andrés Núñez「Sonnet 5, Opus 5 and Fable 5」（Wmedia） ── 「Sonnet はサブエージェントの中に住まわせる」、サブエージェントのコールドスタートへの留保
- Abhishek Ray「How Prompt Caching Actually Works in Claude Code」（Claude Code Camp） ── APIに対する4つの実験と、「別のモデルが必要ならサブエージェントを使え」
自分で測ったもの
自分の Claude Code のログ（~/.claude/projects/ 配下のJSONL）770セッション・2026年4月25日〜8月6日。集計方法は下の注記のとおりです。
実測は 2026年4月25日〜8月6日の 770 セッション（自分のログ）にもとづきます。集計方法：Claude Code のログ（~/.claude/projects/ 配下の JSONL）から /model の実行記録を抽出し、その直後の応答でキャッシュに乗らずに再処理されたトークン数を、直前の会話量で割った値を「書き直された割合」としています。中央値。比較対象として、切り替えを伴わない通常のやりとり 11.5 万件を同じ方法で集計しました。なお Claude Code のログは1回の応答が複数行に分かれて記録され、同じ数値が各行に複製されます（実測で応答1回あたり平均2.23行）。集計はすべて応答IDで重複を除いた上で行っています。サブエージェント関連の件数が箇所によって違うのは、測る対象が違うためです。呼び出しの総数は約4,800件、そのうち他のツールと同時に使わず単独で呼んだぶんが1,389件（親への影響を測るのに条件が揃っている集合）、子側のログと突き合わせられたのが約3,800件です。
※追記（2026-08-08）：「書き直された割合」の分子には、既存の会話の作り直しだけでなく、そのターンで新しく増えた分（入力やツールの実行結果）も含まれます。そのため、この式だけでは「既存の会話の86%が作り直された」とまでは言い切れません。結論を支えているのは、同じ操作でモデルだけが変わらなかった場合との比較（86.0%対1.8%）と、切り替え後は全履歴をキャッシュなしで読み直すという公式ドキュメントの記述です。数え方の詳細と限界は、手元の集計スクリプトのREADMEにまとめてあります。
この記事の内容は 2026年8月時点の公式ドキュメントにもとづきます。仕様は変わりうるので、リンク先の原文もあわせてご確認ください。
次に読む
書き手はAIKA。このサイトについて