Claude Codeのプロンプトキャッシュが壊れると、トークン消費が数倍に跳ね上がる。
「昨日まで普通に使えていたのに、今日は5時間制限の16%が一瞬で消えた」——#47108の報告だ。原因はキャッシュの仕組みにある。
プロンプトキャッシュとは
Claude Codeは毎ターン、システムプロンプト(CLAUDE.md、skills、設定情報)をAPIに送信する。キャッシュが効いていれば、前回と同じ部分は再計算されない。効いていなければ、全文が新規トークンとして課金される。
キャッシュが効いている状態では1ターンの消費が軽い。壊れると同じ操作でも消費が2〜5倍になる。
原因1: git statusがシステムプロンプトに含まれる
#47107で指摘された問題。Claude Codeはシステムプロンプトに現在のgit statusを含める。つまり:
- ファイルを1つ変更するとgit statusが変わる
- git statusが変わるとシステムプロンプトが変わる
- システムプロンプトが変わるとキャッシュが壊れる
コードを書くたびにキャッシュが壊れる。
回避策
環境変数で無効化できる:
export CLAUDE_CODE_DISABLE_GIT_INSTRUCTIONS=1
claude
ただしgit関連の指示がなくなるため、gitを多用するワークフローでは注意が必要。
原因2: skills + CLAUDE.mdが毎回キャッシュを再生成する
#47098の発見。新しいセッションを開始すると、skills・CLAUDE.md・設定情報(約6,500トークン)がキャッシュなしで送信される。
これは仕様上避けられない——新セッションには前回のキャッシュがない。問題は、この6,500トークンのキャッシュ作成がセッションを開始するたびに発生すること。
セッションを頻繁に切り替える使い方だと、毎回6,500トークンのオーバーヘッドが積み重なる。
回避策
- セッションを安易に切り替えない。1セッション=1テーマで、テーマが完了するまで続ける
- CLAUDE.mdを短くする。長いCLAUDE.mdはキャッシュ再生成コストを増やす。100行→35行に凝縮するとキャッシュ効率が改善する
- skillsを整理する。使わないskillsは無効化する
原因3: Cache TTLが1時間→5分にサイレント変更された
#46829で報告された問題。2026年3月初旬、Anthropicはプロンプトキャッシュの有効期間(TTL)を1時間から5分に短縮した。事前の告知なし。
何が起きるか:
- 以前は1時間以内の操作ならキャッシュが効いていた
- 5分に短縮されたため、少し考えたり休憩したりするとキャッシュが切れる
- キャッシュミス → 全文再送信 → トークン消費が20-32%増加
5分間操作しないだけでキャッシュが消える。 コードを読んで考える時間、ドキュメントを確認する時間——人間にとって普通のペースがキャッシュを壊す。
回避策
- 作業を中断しない。5分以内に次の操作を行う
- 長考が必要なら新セッションを前提にする。--resumeは使わない(#42338でキャッシュ完全無効化が報告されている)
- hookでキャッシュ効率を監視する(下記参照)
hookでキャッシュ破壊を検知する
settings.jsonのhookで、キャッシュ効率の低下を自動検知できる:
#!/bin/bash
# cache-efficiency-monitor.sh (PostToolUse hook)
# セッション中のトークン消費を記録し、急増を警告
SESSION_LOG="/tmp/cc-token-session-$(date +%Y%m%d).log"
INPUT=$(cat)
TOKENS=$(echo "$INPUT" | jq -r '.session_tokens // empty' 2>/dev/null)
[ -z "$TOKENS" ] && exit 0
echo "$(date +%H:%M:%S) $TOKENS" >> "$SESSION_LOG"
exit 0
まとめ
キャッシュ破壊の3大原因:
-
git statusの変更(ファイル編集のたびに発生)→
CLAUDE_CODE_DISABLE_GIT_INSTRUCTIONS=1で回避 - セッション切り替え時の再生成(6,500トークン/回)→ セッション頻度を減らす + CLAUDE.mdを短く
- Cache TTLサイレント短縮(1h→5min、2026年3月)→ 5分以上の中断でキャッシュ消失。コスト20-32%増
自分のキャッシュ効率を確認したい方へ
Token Checkupで5つの質問に答えるだけでトークン消費パターンを診断できる(無料)。
📖 トークン消費に困っているなら → Claude Codeのトークン消費を半分にする——800時間の運用データから見つけた実践テクニック(¥2,500・はじめに+第1章 無料)
関連記事: Claude Codeのトークン消費を減らす5つの方法——Opus 4.7対応
:::note info
📖 AIで事業を回す実体験を全記録 → Claude Code×個人事業 800時間の全記録(¥800・第2章まで無料)
:::
⚠️ Opus 4.7緊急情報(2026年4月17日)
Opus 4.7のauto mode安全分類器がOpus 4.6にハードコードされている問題が発覚。3日間で23件以上のデータ損失。さらにv2.1.100以降、APIコールごとに約20,000トークンが見えない場所で追加課金されている問題も判明(#46917、GitHub上196件のリアクション)(50GB永久消失含む)。4倍のトークン消費も報告されている。対策: npx cc-safe-setup --opus47(Opus 4.7 Survival Guide / 設定の危険度スキャナ)
📄 同じ症状が自分の環境で起きているかを、自分のログで確かめる
この記事の3つの原因(git status の混入、skills の段の波打ち、TTL の沈黙の変更)は、私の環境で測った話です。同じことがあなたの環境で起きているかどうかは、あなたのログを見ないと分かりません。
/cost の出力とセッションの記録を読んで、浪費の上位3件と直し方を48時間でお返しするトークン監査(¥3,980)をやっています。ただ、消費額を数えたいだけなら /cost と ccusage で足りるので、その場合は要りません。
見本の報告書(無料・日本語)は買う前に全部読めます。私自身の156セッション(21,770往復)に当てた本物で、いちばん大きかった浪費が自分の本の56症状のどれにも当てはまらなかったことも、そのまま書いてあります。
📚 関連の参考資料 (2026年5月28日追加)
本記事の内容と関連する整理を、 公開済の素材で articulate しています。
-
6月15日に予定された課金分離(当日に一時停止・再実施に備える)の判定の枠組み: Migration Playbook v2 (Gumroad、 $19) ——14日後の決定の整理、 9集積の文脈、 130件の claim-verify divergence の事例。 60秒の購入判定の道具で事前判定が可能
-
月次の追補の継続: Claude Code 事故まとめ(無料・月次) ——5月から12月の8ヶ月の章本文 (cache_control / 副の作業者 / AGENTS.md / Pro Max / 権限 / Skills / v2.1.150 / AUP false-positive)
-
9集積の枠組みの英語の長編 Gist: The 9-Cluster Framework: Mapping the Structural Failure Surface of Claude Code Operator Defense ——約3,300単語、 全件の集積の mechanism / symptom family / defense path の整理。 cluster 9 (Usage Policy classifier over-trigger on Opus、 25+件の起票) の対話型診断道具: 4問の質問→推奨経路の道具
-
約800件の MIT ライセンスの hook: cc-safe-setup (GitHub) ——9集積に対応する hook を整備した累計
800時間の Claude Code 運用データから、トークン消費の削減・複数ベンダー(Claude / Codex / Gemini / Copilot)の並行運用・事故の検知と復旧・サブエージェントの沈黙の失敗対策など、主題別の手引きを公開しています。気になる人は著者の本の一覧から、価格と評価を見て選べます。