この記事は Zenn に投稿したものの転載です（内容は同一）。
原典: https://zenn.dev/trh/articles/540b2f9424c2ab
結論
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個を選び、設定ファイルに下位モデル指定を追記した。
| 降格したもの | 内容 |
|---|---|
| API動作確認 | curlを叩いて結果を集計するだけ |
| DBバックアップ | SQLiteファイルのコピー |
| DB状態確認 | SQLを実行して集計 |
| ドキュメント構造チェック | 見出し構造の検証 |
| Excel構造解析 | シート構成の読み取り |
| ファイル検証 | PDF/Excel/Wordの形式確認 |
| 一括チェック | 上記の並列実行と集約 |
| 監視管理 | バックグラウンドプロセスの一括管理 |
| 印刷HTML生成 | テンプレートへの流し込み |
| システム起動 | ポート確認とプロセス起動 |
そのとき見積もった効果は、こうだった。
上位モデル比率 100% → 30〜50% に低下する見込み。
日次消費は $4,011 → $2,000 前後（理論値）。
もっともらしい。実際、対策としての方向は間違っていないと今でも思う。
ただし、実測は違った。
実測：効かなかった
対策の前後を含む全期間の月別集計がこれである。
| 月 | 稼働日 | 日次中央値 | 下位モデル比率 |
|---|---|---|---|
| 4月 | 5日 | $112.4 | 5.3% |
| 5月 | 17日 | $472.2 | 0.0% |
| 6月 | 19日 | $916.7 | 0.0% |
| 7月 | 18日 | $272.6 | 4.3% |
| 8月 | 6日 | $903.2 | 0.0% |
※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）で換算すると、こうなる。
| 種別 | トークン | 単価換算 |
|---|---|---|
| 出力 | 78,954,707 | 約 $1,974 |
| キャッシュ読み込み | 19,158,813,183 | 約 $9,579 |
単価が1/10でも、量が240倍あれば、コストでも最大項目になる。 「キャッシュは安い」は1トークン単位の話であって、総額の話ではない。
※この換算は現行の公表単価を当てはめた参考値で、実際の課金は前述のとおり定額プランである。
消費上位の日を見ると、さらにはっきりする。
| 日 | キャッシュ読み | 出力 | セッション数 |
|---|---|---|---|
| 5/18 | 1,589,784,534 | 5,951,549 | 7 |
| 6/22 | 1,046,055,927 | 5,704,049 | 22 |
| 7/03 | 1,021,262,238 | 2,453,643 | 3 |
| 8/06 | 823,334,152 | 2,774,791 | 1 |
注目すべきは最下行で、セッション1本だけで8.2億トークンのキャッシュ読み込みが発生している。
そして6/22は22セッションで10.4億、5/18は7セッションで15.9億。セッションの本数と消費は対応していない。効いているのは1本あたりの長さのほうである。
長い会話を1本引き延ばすほうが、短い会話を何本も回すより高くつく。
唯一効いた対策
前掲の表で、7月だけ中央値が$272.6に落ちている。6月の$916.7に対して1/3以下である。
このとき何をしたかというと、モデル設定はいじっていない。運用ルールを変えた。
- 重い実装作業は、その場で延々と続けず、別のセッションに切り出して委譲する
- 扱う対象システムごとにセッションを分ける
要は会話を長く引き延ばさないというだけの運用である。
キャッシュ読み込みの中央値で見ると、こうなる。
| 月 | キャッシュ読み込み（日次中央値） |
|---|---|
| 6月 | 394,338,826 |
| 7月 | 107,729,309 |
約 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の実測記録であり、環境や使い方によって傾向は変わりうる。