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

こんにちは。新学期が始まって生活のリズムが戻る頃ですが、長い作業セッションはまだまだこたえますね。今回は、その長いセッションの料金を裏で左右している「キャッシュ」の話です。

Fable 5.1 で安くなったのは、キャッシュ読み取り（前のターンと同じ部分を読み直すときの料金）だけです。なので、キャッシュを効かせ続ける使い方なら大きく安くなり、壊してばかりいると値下げの恩恵はありません。気になっていた「会話の途中で effort（AI にどれだけ考えさせるかの設定）を変えるとどうなるか」は、Claude Code では今のところキャッシュを壊す扱いでした。Opus 5 で測ると、切り替えたターンで約7割が書き直しになっています。Fable 5.1 では切替の影響をうまく切り分けられなかったので、こちらも有料と考えておくのが安全です。

以下では、値下げがなぜ25〜45%もの差になるのかから始めて、Claude Code がキャッシュの有効期限を決める仕組み、キャッシュを壊す操作と壊さない操作、そして effort 切替の実測の順に書いていきます。

前回の記事（Fable 5.1 の実力と常用 effort）で、Fable 5.1 は価格据え置きなのに、実際に使ったときのコストが「典型ワークロードで約25%減、エージェント型で約45%減」になると紹介しました。値下げされたのはキャッシュ読み取り（cache read）だけで、$1.00 → $0.25 per MTok です。入力 $10、出力 $50、キャッシュ書き込み（5分 $12.5／1時間 $20）は変わっていません。

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

裏返すと、キャッシュが効いていない使い方では値下げの恩恵はゼロです。ここから先は、キャッシュを効かせ続けるための話になります。

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

まず、サブスクの枠内なら、メイン会話は何もしなくても1時間キャッシュになります。手元でも claude -p "hello" --output-format json の usage.cache_creation が ephemeral_1h_input_tokens: 23997 / ephemeral_5m_input_tokens: 0 と返ってきて、1時間側に書かれていることを確認しました。

次に、枠を使い切って使用クレジットに入ると、5分に落ちます。課金が発生し始めるので、書き込みの安い5分に切り替わるわけです。それでも1時間を維持したいなら、settings に promptCacheTtl: "1h" を書きます（v2.1.242 以降）。

最後に、サブエージェントや 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 切替＝履歴を全部読み直す」と書いています。どちらが実態なのか、API が返す使用量の記録（usage）の数字で確かめました。

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

切り替えようとすると、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 ベータを使っていません。

Opus 5 では約7割が再書き込み

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

Fable 5.1 では、切替の影響を切り分けられなかった

Fable 5.1 の短いテストセッションでは、effort を変えていないターンでも毎回約44kトークンが再書き込みされ（read 32,644 / creation 44,300〜45,300）、切り替えたかどうかで差が出ませんでした。一方、同じ日に数時間動かした実作業セッションでは、read 200k超・creation 1k未満で、ふつうに増分キャッシュが効いています。短い試験セッション特有の何かが、毎回プレフィックスを変えていると見ていますが、原因はまだ突き止められていません。

なので「Fable 5.1 なら effort 切替が無料」とは言えません。確認ダイアログの文言どおり、有料と考えておくのが安全です。

effort とモデルは、セッションの頭で決める

実務での結論はこうです。effort とモデルはセッションの最初に決めておき、途中で変えるなら /compact のような区切りのタイミングに寄せます。1〜2ターンだけ深く考えさせたいなら、切り替えるよりも、プロンプトに「ultrathink」と書くほうがキャッシュを壊しません（新 effort モード解説）。迷いやすいのは「このターンだけ high にしたい」という場面だと思うので、そこはこちらを使ってみてください。

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

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

キャッシュが効いているかは、次の3か所で確かめられます。

• /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 を集計したもので、環境やバージョンで変わります。

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