AIコーディングの消費、97.7%はキャッシュ読み込みだった — 65稼働日の実測ログ

結論

4ヶ月・65稼働日ぶんの利用ログを集計したら、トークン消費の 97.7% がキャッシュ読み込み だった。出力生成ではない。

その結果、こうなった。

• モデルを安いものに切り替える対策は、実測ではほぼ効かなかった
• 効いたのは「会話を短く切る」という運用変更だけだった
• しかもその運用変更は、1ヶ月で元に戻った

「AI利用料が高い」と感じている人がまず手を出すのはモデルの切り替えだと思う。自分もそうした。でも測ってみたら、それは効く場所ではなかった。

以下、実データを全部出す。

先に前提と、この記事の限界

盛らずに書きたいので、最初に条件を明示しておく。

1. 定額プランでの利用である

期間中はMaxプラン（定額）を使っていた。したがって記事中の「$」は請求額ではなく、API従量課金に換算した場合の相当額である。実際に支払った金額ではない。

ではなぜ金額で測っていたかというと、当初は「消費量の目安」として見ていたから。後述するが、この指標選択自体が間違いだったというのが本記事の裏テーマでもある。

2. 計測はセッション単位のスナップショット

自作スクリプトで日次のトークン量とモデル別内訳を記録している。同一日に複数回の記録がある日は最大値を採用した。

3. モデル帰属に欠損がある

後述の7月のデータで、合計額に対してモデル別内訳の合計が一致しない期間がある（未分類分が存在する）。計測側の取りこぼしで、原因は特定していない。該当箇所では明示する。

4. n=1 である

個人の1環境の記録であって、統計的な一般化はできない。「こういう実例がある」以上のことは主張しない。

何が起きたか

発端：ある日の消費が突出した

ある日、日次の消費がAPI換算で $4,262 に達した。それまでの中央値が$161だったので、20倍以上の突出である。

内訳を見ると、その日のセッションは7本すべてがOpusだった。上位モデルが100%。

原因調査で分かったのは、こういうことだった。

• 自作のスキル（定型作業を登録しておく仕組み）が20個、モデル指定なしで存在していた
• モデル指定がない場合、デフォルトで上位モデルにフォールバックする
• つまり「ファイルコピー」「SQL実行して集計」レベルの機械作業まで、全部上位モデルが処理していた

これは明確に無駄である。そこで対策を打った。

対策：機械的な処理を下位モデルに降格

判断や議論の要素がなく、実行・集計・整形が中心の10個を選び、設定ファイルに下位モデル指定を追記した。

そのとき見積もった効果は、こうだった。

上位モデル比率 100% → 30〜50% に低下する見込み。
日次消費は $4,011 → $2,000 前後（理論値）。

もっともらしい。実際、対策としての方向は間違っていないと今でも思う。

ただし、実測は違った。

実測：効かなかった

対策の前後を含む全期間の月別集計がこれである。

※5月中旬に対策を実施。7月は前述のモデル帰属欠損がある月で、比率の精度は低い。

対策の翌月である6月を見てほしい。

• 下位モデルの比率：0.0%
• 日次中央値：$472 → $916 へ倍増

減るどころか倍になっている。

さらに、下位モデルが金額として現れた日を数えたら、65稼働日のうち8日しかなかった。しかもそのうち6日が7月に集中している。

つまり、設定ファイルに下位モデルを指定するという対策は、集計上ほとんど何も動かさなかった。

なぜ効かなかったのか

トークンの内訳を出して、理由が分かった。

全期間のトークン内訳（65稼働日）

  入力            8,178,739
  出力           78,954,707
  キャッシュ書き   365,978,356
  キャッシュ読み 19,158,813,183   ← 全体の 97.7%

消費のほぼ全部がキャッシュ読み込みだった。

191億トークン。出力の79Mに対して、240倍以上ある。

キャッシュ読み込みというのは、平たく言えば 「これまでの会話を、毎ターン読み直している分」 である。会話が長くなるほど、1ターンあたりの読み直し量が増える。

ここが肝心なところで、

キャッシュ読み込み量は「どのモデルが答えるか」ではなく「会話がどれだけ長いか」で決まる。

モデルを安いものに変えても、読み直す文脈の量は1バイトも減らない。だから降格対策は効かなかった。効く場所を間違えていた。

「キャッシュは安いから関係ない」ではない

ここは反論が来そうなので先に潰しておく。

キャッシュ読み込みの単価は、公式ドキュメントによれば通常の入力トークンの0.1倍（キャッシュ書き込みは5分TTLで1.25倍、1時間TTLで2倍）。たしかに1トークンあたりは安い。

だが、量が桁違いに多い。Claude Opus 5 の公表単価（入力 $5 / 出力 $25 / キャッシュ読み $0.50 per MTok）で換算すると、こうなる。

単価が1/10でも、量が240倍あれば、コストでも最大項目になる。 「キャッシュは安い」は1トークン単位の話であって、総額の話ではない。

※この換算は現行の公表単価を当てはめた参考値で、実際の課金は前述のとおり定額プランである。

消費上位の日を見ると、さらにはっきりする。

注目すべきは最下行で、セッション1本だけで8.2億トークンのキャッシュ読み込みが発生している。

そして6/22は22セッションで10.4億、5/18は7セッションで15.9億。セッションの本数と消費は対応していない。効いているのは1本あたりの長さのほうである。

長い会話を1本引き延ばすほうが、短い会話を何本も回すより高くつく。

唯一効いた対策

前掲の表で、7月だけ中央値が$272.6に落ちている。6月の$916.7に対して1/3以下である。

このとき何をしたかというと、モデル設定はいじっていない。運用ルールを変えた。

• 重い実装作業は、その場で延々と続けず、別のセッションに切り出して委譲する
• 扱う対象システムごとにセッションを分ける

要は会話を長く引き延ばさないというだけの運用である。

キャッシュ読み込みの中央値で見ると、こうなる。

約 1/3.7。 金額の減り方（$916 → $272、約1/3.4）とほぼ一致する。

つまり7月の改善は、モデル構成ではなく文脈量そのものが減ったことで説明できる。仮説と実測が噛み合っている。

そして元に戻った

8月の中央値は $903.2、下位モデル比率は 0.0%。

6月の水準に戻っている。

7月に効いた運用は、設定ではなく人間の習慣に依存していた。だから意識が薄れた時点で戻った。一方、5月に入れた設定変更のほうは今も残っているが、そもそも効いていない。

ここが個人的には一番の学びだった。

恒久化された対策は効かないもので、効いた対策は恒久化されていなかった。

きれいに逆をやっていた。

実務的な結論

同じことをやろうとしている人向けに、実測から言えることだけ書く。

1. 定額プランなら、金額で測ってはいけない

定額なのだから、$表示は請求と無関係である。実際に効いてくるのはレート制限や利用枠のほうで、それを規定するのはトークン量。金額をKPIにすると、この記事の前半のような的外れな最適化に向かう。測るならキャッシュ読み込み量。

2. モデル切り替えは、効く範囲が思ったより狭い

無駄ではない。機械作業を上位モデルにやらせる必要はない。ただし全体消費に対するインパクトは小さい。ここを主対策にすると、労力の割に何も変わらない。

3. 一番効くのは、会話を切ること

同じ話題を1本のセッションで引き延ばすほど、毎ターンの読み直しが積み上がる。対象ごと・作業ごとにセッションを分けるのが、実測上いちばん効いた。

4. 習慣に依存する対策は、必ず戻る

7月の改善は再現できたが、維持できなかった。運用ルールを人間の意識に置いた時点で減衰は確定する。設定・自動化・強制ゲートのどれかに落とさないと残らない。

おわりに

「モデルを安くすれば安くなる」という直感は、少なくとも自分の環境では外れていた。

消費の97.7%は、賢さの対価ではなく文脈を運び直すコストだった。

もし同じように利用枠を使い切っている人がいたら、モデル構成をいじる前に、自分のキャッシュ読み込み量を一度測ってみることを勧めたい。効く場所が違うかもしれない。

自分の環境ではそうだった。

参考

• Prompt caching — Claude Docs — キャッシュの仕組みと価格倍率（cache read 0.1x / cache write 1.25x・2x）。本記事の単価はここから
• Pricing — Claude Docs — モデル別のトークン単価
• Claude Code — Overview — 本記事で使っているツール。CLAUDE.md・skills・hooks もここ
• Store instructions and memories (CLAUDE.md) — 記事中の「設定に落とす」対策の実体
• 「Claude Code か Codex か」の争点は"賢さ"じゃなかった — 移行議論の争点がコスパ・レート制限だという整理

計測は自作の日次スナップショットスクリプトによる。n=1の実測記録であり、環境や使い方によって傾向は変わりうる。