Claude Codeが7日で$10,007燃やしていた話

自分のClaude Code運用を7日分ログから洗ったら、API換算で$10,007.22、このうち$2,726.01が「修正可能な浪費」 であることが具体的に特定できた。本記事はその経緯と、自作ツール cc-token-diet の中身、そして読者が同じ計測を5秒で回すための手順を残す。

前提: 筆者はMax 20x ($200/月)で定額なので、$10,007がそのままカードに乗るわけではない。ただしこの数字は**「自分が今使っているcontext intensity をAPI従量換算するといくらになるか」**の量的指標で、Max/Proの枠を食い潰すスピード感と強く相関する。1時間でquotaが溶ける体感と、この$数字は同じものを別表記しているだけ。

なぜ新しいツールを書いたか

既存の類似ツールで十分確かめられるかを先に調べた。

ツール	何を返すか	何を返さないか
ccusage (13.2k★)	総額 / 期間別集計 / PDF export	浪費パターンの特定、修正案
cc-cost-check	コミット/時間/日ごとのコスト	どのセッションが問題か
cc-cost-forecast	月末時点のAPI換算予測	現在の浪費を止める方法

「総額は分かる、でもどこから手を付ければいいか分からない」という穴が残っていた。そこで筆者は、ローカルの ~/.claude/projects/ 配下に Claude Code が書き出す .jsonl ログを直接パースし、具体的な浪費パターン3種 × 各セッションの$換算 × 対応する設定変更 を返す CLI を書いた (yurukusa/cc-token-diet, MIT)。

使い方は1行。

npx github:yurukusa/cc-token-diet

ネットワーク通信はなし。APIキーも不要。既に手元にあるログを読むだけ。

実行して出てきた数字 (筆者自身のログ、7日間)

📉 cc-token-diet report (last 7 days)
────────────────────────────────────────────────────────
Sessions analysed: 312   Assistant turns: 36973
Input:   457.8K   Output:         7.36M
Cache read:   5.21B   Cache write:  87.15M
API-equivalent spend:  $10007.22  (Opus 4.x pricing)
  ↳ On Max/Pro you pay the flat subscription; this is context intensity
  ↳ On Sonnet divide by ~5. The patterns stay the same either way.
Cache hit ratio: 98.4% (higher is better, aim >85%)

🔥 Waste patterns:
  ❗ 87 runaway session(s) (>100 assistant turns) (≈ $2726.01 wasted)
     Fix:  Long single sessions bloat context exponentially.
           Use /compact or restart for each logical task.
     See:  Token Book ch3 (context management)

🌡️  Hottest sessions:
   $513.26  2026-04-19  projects-cc-loop         955 turns / 157min
   $499.34  2026-04-16  -home-namakusa           898 turns / 3898min
   $431.08  2026-04-20  projects-cc-loop        1103 turns / 180min

読みどころは4点ある。

(1) 総額 $10,007 / 7日 = 月換算 $42,887

Max 20xの月額$200に対して214倍。つまり筆者は、定額枠の頭を常に200倍速度で叩いている。これが「朝起きたらquotaが半分消えていた」現象の正体。

(2) Cache hit ratio 98.4%

これは良い数字。目安は85%以上で、筆者のケースはそれをクリアしている。CLAUDE.md / tools / system prompt が安定していて、毎ターンのcache writeが最小限であることを示す。ここが低いと別の最適化（CLAUDE.md圧縮、agent定義の整理）が効く。

(3) Runaway sessions 87個 = $2,726

ここが最大の発見。100ターン超の長時間セッションが7日で87個あり、そこで$2,726分のcontext intensityが消えていた。1セッションあたり$30前後の「気付かずに溶かしていた」塊が、週に数十個単位で発生していた計算。

(4) 単一セッション最大 $513 / 155分

最も熱かったセッションは projects-cc-loop で 955ターン・155分。/compact が間に合わなかったか、意図せず長時間走り続けたセッション。この1つだけでMax 20x の 2.5ヶ月分の枠相当を溶かしている。

浪費の3パターン (cc-token-dietが見ている軸)

ツールは .jsonl を読んで次の3軸でセッションを分類する。どれも既存研究・Issue報告で裏が取れているもの。

パターン1: Cache write ratio > 30%

毎ターン cache を書き直していると、安定 context の 約12.5倍 のコストになる。原因:

CLAUDE.md が肥大化して更新が頻発
サブエージェント定義が毎ターン変わる
MCP tool定義のシャッフル
v2.1.36-2.1.87 の Dynamic Tool Descriptions バグ (v2.1.89で修正済みだが影響期間長い)

Fix: CLAUDE.md を2,000字以下に圧縮 / MCP tool を必要な物だけ enable / CLI を v2.1.89 以上に更新。

パターン2: Verbose output (turn平均 >3K output tokens)

モデルに「全部説明して」「詳細にまとめて」と頼んだセッションで発生しやすい。output tokenはcache readの50倍 高い ($75/MTok vs $1.50/MTok) ので、長い回答を求めると一瞬で積み上がる。

Fix: system promptで「簡潔に / 箇条書きで / コードのみ」を明示 / 説明系タスクと実装系タスクをセッション分離。

パターン3: Runaway sessions (>100 assistant turns)

今回の筆者の事例。1セッションが長くなると context が指数的に膨らみ、各ターンが読み込む/書き込むtoken量が増える。100ターン超は実測で本人の手元データでも明確な分断点になっていた。

Fix: 1セッション = 1タスク原則を徹底 / /compact を積極的に使う / /clear で logical タスクごとにリセット / PreCompact hook で自動 snapshot を取っておく。

「どの設定を変えたか」実測

上記3パターンのうち、筆者の場合は (3) が主因と特定できたので、次の3点を即反映した。

変更1: `/compact` タイミングを前倒し

従来: 自動 auto-compact (200Kコンテキスト境界) に任せていた
変更後: 50ターン or 30分経過で明示的に /compact を叩く

これはそのままでもOKだが、PreCompact hook を入れて conversation の summary をローカルファイルに書き出すようにした。再開時に要点だけ Claude に戻せるので再構築コストが下がる。

変更2: 1タスク1セッションを徹底

「今のタスクが終わったら、次のタスクは必ず /clear してから」をhook (Stop event) で強制。hook 実装例:

#!/bin/bash
# stop-clear-reminder.sh (PostToolUse/Stop event)
# 100ターン超のセッションで終了した時に /clear を提案

TURN_COUNT=$(jq '.conversation_length // 0' <<< "$CC_INPUT")
if [ "$TURN_COUNT" -gt 100 ]; then
  echo "⚠ このセッション ${TURN_COUNT}ターン。次のタスク前に /clear 推奨" >&2
fi
exit 0

変更3: `CLAUDE_CODE_DISABLE_1M_CONTEXT=1` を zshrc に追加

1M context variantは200K境界でauto-compactしない。silent switch (#49541) を経由して気付かずに1Mに入ってしまうと、runaway化が加速する。最初から1Mを選べなくする方が安全。

echo 'export CLAUDE_CODE_DISABLE_1M_CONTEXT=1' >> ~/.zshrc

再計測

3つの変更を反映して3日後に再実行した結果、runaway session 数は87→28、waste $は $2,726→$742 に減った (同じ利用量での比較)。完全にゼロにはならない ( Claude自身が長時間thinkingに入るケースは手元のhookでは防げない) が、自分側の運用起因の浪費は2/3程度削れた。

ツールが何をしないか

サーバーに送らない: 全てローカル処理。1 CLI file (cli.mjs) で完結。依存なし。
実課金額は返さない: あくまでOpus 4.x公称レートでの "API換算" 値。Max/Pro定額の実際の請求とは別物。
Sonnet前提なら 出力を約5で割る。パターン自体は同じ。

まとめ

自分のClaude Code運用7日分をログレベルで洗ったら $10,007 API換算 / うち $2,726 が修正可能な浪費 だった
浪費の主因は「1セッションが100ターン超 = runaway」。87個検出
/compact 前倒し + 1タスク1セッション hook + 1M disable で $2,726 → $742 に削減
ツールは yurukusa/cc-token-diet で公開。npx github:yurukusa/cc-token-diet で5秒で実行可能。ローカルログだけ読む

次の一歩

上記で書いた3パターンの各症状ごとの対策は、Token Book (¥2,500) に10章で体系化している。特にch3 (context management) と ch8 (症状別対策48件) が本記事の実測データを補完する。

無料で試すなら:

Token Checkup (yurukusa.github.io/cc-safe-setup/token-checkup.html): 10問診断で自分のトークン消費パターンを5分で把握
cc-token-diet (github.com/yurukusa/cc-token-diet): 本記事で使ったCLI。1コマンドで実数値を確認

「総額は見えているけど、どこから直せばいいか分からない」状態から、「次に変える設定はこの3つ」に落とし込むための道具として使ってほしい。