effort を途中で変えるとキャッシュはどうなる？ Fable 5.1 と Opus 5 で実測した

前回の記事（BlogFable 5.1 は『low で旧 max 超え』なのか｜公式グラフ5枚をベンチ別に正直に読むClaude Fable 5.1 の公式グラフ5枚をベンチ別に読み、low が旧 Fable 5 の max を超えたベンチと超えなかったベンチを表にしました。常用 effort の決め方と Pro/Max の課金条件も整理します。→）で、Fable 5.1 は価格据え置きなのに実利用コストが「典型ワークロードで約25%減、エージェント型で約45%減」と紹介しました。値下げされたのはキャッシュ読み取り（cache read）だけで、$1.00 → $0.25 per MTok です。入力 $10、出力 $50、キャッシュ書き込み（5分 $12.5／1時間 $20）は変わっていません。

なぜ1項目の値下げで総額が25〜45%も動くのか。Claude Code は毎ターン、システムプロンプト・プロジェクト設定・過去の会話全部を API に送り直します。会話が長くなるほど「前回と同じ部分」が増え、それは全部キャッシュ読みで課金されます。公式グラフでは、典型ワークロードのコストの約40%、エージェント型では約65%がキャッシュ読みでした。その部分が4分の1になるので、40%×(1−0.25)=30%減（表示は約25%減）、65%×0.75≈49%減（表示は約45%減）という計算です。

裏返すと、キャッシュが効いていない使い方では値下げの恩恵はゼロです。この記事は「キャッシュを効かせ続ける」ための Claude Code の仕組みと、壊す操作・壊さない操作、そして effort 切替の実測を扱います。

キャッシュには有効期限（TTL）があり、API には5分と1時間の2種類があります。1時間は書き込み単価が高い（$12.5 → $20）代わりに、席を外しても消えません。Claude Code はリクエストを2つのバケツに分けて TTL を決めます。

ポイントは3つです。

1. サブスクの枠内なら、何もしなくてもメイン会話は1時間キャッシュ。手元でも claude -p "hello" --output-format json の usage.cache_creation が ephemeral_1h_input_tokens: 23997 / ephemeral_5m_input_tokens: 0 と返り、1時間側に書かれていることを確認しました
2. 枠を使い切って使用クレジットに入ると、5分に落ちる。課金が発生し始めるので、書き込みの安い5分に切り替わります。1時間を維持したいなら promptCacheTtl: "1h" を settings に書きます（v2.1.242 以降）
3. サブエージェントや workflow は常に5分。subagentPromptCacheTtl で1時間にできますが、書き込み単価が上がるので、fan-out の合間が5分を超える場合だけ有効です

優先順位は、環境変数 FORCE_PROMPT_CACHING_5M=1（両バケツを強制5分。比較実験用）→ バケツ別の環境変数 → settings → サブエージェント定義の cacheTtl → ENABLE_PROMPT_CACHING_1H=1 → 既定、の順です。

公式 docs の一覧を、体感の「高いターン」の原因順に並べ直しました。

壊す（次のターンが遅く・高くなる）

• /model でのモデル切替（モデルごとに別キャッシュ。安全装置による自動フォールバックも同じ）
• /effort での effort 切替（後述の実測）
• fast mode をオンにする最初のターン（ヘッダーがキャッシュキーに入る。オフに戻すのは無料）
• MCP サーバーの接続・切断（ツール定義をプレフィックスに載せている場合。既定の deferred ならセーフ）
• ツール丸ごとの deny ルール追加（Bash 等の裸のツール名）
• /compact（会話層を要約に置き換える。ただし温かいうちなら要約リクエスト自体はキャッシュを読む）
• Claude Code のアップグレード後の resume（システムプロンプトが変わるので履歴全部が再読）

壊さない

• リポジトリのファイル編集（変更通知が末尾に追記されるだけ）
• CLAUDE.md の編集（壊さない代わりに反映もされない。次の /clear か再起動まで旧版のまま）
• output style の変更（同上）
• 権限モードの切替（opusplan だけはモデル切替になる）
• スキル・コマンドの呼び出し（末尾にユーザーメッセージとして追記）
• /rewind（既にキャッシュ済みの地点に戻るので、むしろ得）
• サブエージェントの起動（親のプレフィックスは無傷）

API 側には、Fable 5.1 と Opus 5 向けに「会話の途中で effort だけ変えてもキャッシュを壊さない」ベータ（mid-conversation-output-config-2026-07-01）が存在します。しかし Claude Code の docs は今も「effort 切替＝履歴を全部読み直す」と書いています。どちらが実態か、usage の数値で確かめました。

手順: 対話セッションで短い返答（「OK」）を数ターン繰り返し、途中で /effort を low → high → low → xhigh と切り替え、各ターンの cache_read_input_tokens と cache_creation_input_tokens をセッション記録から集計。比較のため Opus 5 でも -p --resume で同じことをしました。

結果1: Claude Code は切替時に確認ダイアログを出す

Change effort level?
Your next response will be slower and use more tokens
This conversation is cached for the current effort level. Switching to high
means the full history gets re-read on your next message.
  1. Yes, switch to high
  2. No, go back

キャッシュが温かい間だけ出る確認で、Claude Code 自身が「effort 切替＝全再読」として扱っていることが分かります。つまり、Claude Code は現時点で mid-conversation effort ベータを使っていません。

結果2: Opus 5 では約7割が再書き込み

effort を変えたターンは、システムプロンプト冒頭の約11k だけがキャッシュから読まれ、残り約24k が書き直されました。変えなければ書き直しは40トークンです。「全部」ではなく「ほぼ全部」が正確な表現です。

結果3: Fable 5.1 では effort 切替の影響を分離できなかった

Fable 5.1 の短いテストセッションでは、effort を変えていないターンでも毎回約44kトークンが再書き込みされ（read 32,644 / creation 44,300〜45,300）、切替の有無で差が出ませんでした。一方、同じ日に数時間動かした実作業セッションでは read 200k超・creation 1k未満と正常に増分キャッシュが効いています。短い試験セッション特有の何かがプレフィックスを毎回変えていると見ていますが、原因は未特定です。「Fable 5.1 なら effort 切替が無料」とは言えず、確認ダイアログの文言どおり有料と考えておくのが安全です。

実務上の結論: effort とモデルはセッションの頭で決め、途中で変えるなら /compact のような区切りのタイミングに寄せる。1〜2ターンだけ深く考えさせたいなら、切替ではなくプロンプトの「ultrathink」（BlogClaude Code の新effortモード徹底解説｜max・ultracode・autoと『呪文ultrathink』の正体Claude Code の /effort に増えた max・ultracode・auto と、プロンプトに紛れ込ませる呪文 ultrathink を、公式が明言した『ultracode は API の effort レベルではない』を起点に解剖。overthinking・自律ワークフロー・永続性と優先順位の罠まで、誤解されやすい論点を一次情報で正します。→）の方がキャッシュを壊しません。

「ultracode は max effort」と誤解されがちですが、公式定義は「xhigh の effort ＋ 自動ワークフロー編成」です。/effort ultracode を有効にすると、実質的な作業ごとに Claude が複数エージェントを走らせる workflow を組みます。

キャッシュの観点では、workflow で起動されるエージェントは「メイン会話以外」のバケツなので TTL は5分です。同じモデル・effort・ツール・作業ディレクトリのエージェント同士はプレフィックスを共有でき、Claude Code は最初のエージェントの応答が始まるまで他を最大5秒待たせて（CLAUDE_CODE_WORKFLOW_PREFIX_STAGGER_MS）、キャッシュを読ませます。fan-out が大きいほど、この共有が効きます。

• /usage: v2.1.251 以降、Session ブロックに Prompt cache (main) 行が出ます。ヒット率・ミス回数・再キャッシュしたトークン数・いま温かいか（warm/cold）が並びます
• statusline: current_usage.cache_read_input_tokens / cache_creation_input_tokens と prompt_cache オブジェクトが渡されるので、スクリプトで常時表示できます
• セッション記録: ~/.claude/projects/<プロジェクト>/<セッションID>.jsonl の各 assistant メッセージに usage が入っています。本記事の集計はこれを Python で読んだものです

見方は単純で、creation がターンごとに高いまま続いたら、プレフィックスの何かが毎回変わっているサインです。上の「壊す操作」一覧から犯人を探してください。

• Claude Code のプロンプトキャッシュ: https://code.claude.com/docs/en/prompt-caching
• Claude Code changelog（2.1.243 / 2.1.251 / 2.1.257）: https://code.claude.com/docs/en/changelog
• Dynamic workflows（ultracode の定義）: https://code.claude.com/docs/en/workflows
• API プロンプトキャッシュ（価格・mid-conversation effort）: https://platform.claude.com/docs/en/build-with-claude/prompt-caching

検証日: 2026-09-02〜03。Claude Code v2.1.258、Max プラン（枠内）、Fable 5.1（claude-fable-5-1）と Opus 5（claude-opus-5）。数値はセッション記録の usage を集計したもので、環境やバージョンで変わります。

• BlogClaude Code の新effortモード徹底解説｜max・ultracode・autoと『呪文ultrathink』の正体Claude Code の /effort に増えた max・ultracode・auto と、プロンプトに紛れ込ませる呪文 ultrathink を、公式が明言した『ultracode は API の effort レベルではない』を起点に解剖。overthinking・自律ワークフロー・永続性と優先順位の罠まで、誤解されやすい論点を一次情報で正します。→
• BlogClaude Code の /effort 完全ガイド｜low〜maxの使い分けと『コストが増える本当の理由』Claude Code の /effort（low〜max・ultracode・auto）は「賢さ」ではなく「トークンの気前よさ」のレバー。モデル別の推奨スタートと、Opus 4.8 でコストが増えた気がする原因を『トークナイザ』と『effort』の2軸に切り分ける考え方を、公式一次情報と v2.1.156 の実機確認で解説します。→
• BlogAnthropicリーク2連発：Claude MythosとClaude Code流出で見えたKAIROS、BUDDY、Undercover Modeの正体Anthropicの2週間で2回のリークを整理。Claude Mythosの位置づけ、Claude Code流出の中身、KAIROS/BUDDY/Undercover Modeの意味を分けて読む。→

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です！エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします！