LLM コーディングの費用は、生成ではなく「履歴の再送」で決まる

2026-08-31

コーディングエージェントの利用量を減らしたい、という話になると、たいてい最初に出るのは
「生成を軽いモデルに逃がす」「出力を短くする」だ。直感は出力側に向く。

1 か月分のセッションログを全部集計したら、支出構造の 83% は入力側だった。
生成は 17% しかない。この非対称を知らずに削減策を設計すると、必ず外す。

集計結果

ローカルに残るセッションログから、アシスタント発話 約 3 万件分の使用量を、
入力・キャッシュ書き込み・キャッシュ読み出し・出力の 4 本に分けて合計した。
費用比率は、入力の単価を 1 として出力 5 倍・キャッシュ書き 1.25 倍・キャッシュ読み 0.1 倍という
一般的な重み付けで換算している。

読み方は 2 つある。

• トークンの 96% はキャッシュ読み出し＝毎ターン、それまでの会話を丸ごと送り直している
• 出力はトークン量では 0.6% しかないのに、単価が高いので費用では 17% を占める

そのうえで支配項は依然として入力側だ。キャッシュ読み書きの合計で 83%。
つまり費用は「何を書かせたか」ではなく、「何回、どれだけ長い履歴を送ったか」で決まっている。

だから「生成の外注」は上限 17% にしかならない

生成をローカルの小さいモデルへ逃がす構成を検討したことがある。
上の表を先に見ていれば、理論上の削減幅が 17% を超えないことは計算するまでもなかった。
実際に組んで試した結果も、投下したコストのほうが上回った。

効くのは別の軸だ。

• 1 セッションを短く保つ。 履歴が伸びるほど、以降の全ターンが重くなる
• 往復の多い運用をやめる。 「1 項目 1 コミット」のような刻み方は、ターン数がそのまま効く
• 補助エージェントやワークフローの多用を抑える。 起動のたびに文脈を積み直す

いずれも「生成量を減らす」ではなく「再送の回数と長さを減らす」施策になっている。

実装上の落とし穴 ── 素の入力欄だけを見て「入力は少ない」と読む

使用量の記録には入力系の欄が 3 つある。素の入力、キャッシュ書き込み、キャッシュ読み出しだ。
このうち素の入力は「キャッシュに載らなかった残り」でしかない。

ここだけ見ると 0.04%。「入力はほぼゼロ」という結論になる。典型的な誤読で、
プロンプトの総量は 3 つの合計だ。

集計はいつでも後から再現できる

セッションログはローカルに JSON Lines で残る。
アシスタント発話の使用量オブジェクトを 4 本のフィールドで足すだけで、
過去に遡って同じ表が作れる。

しかもログはプロジェクトのディレクトリ単位で分かれる。
作業ツリーが分かれていれば記録も分かれるので、案件ごとの消費量を後から切り出せる。
「どの案件にいくらかかったか」を、事前の計測設計なしに答えられるということだ。

日別に並べると、もっと有用なことが分かる。消費は平らではない。
実測では、突出した数日が全体を押し上げていた。
平均を下げようとしても数字は動かない。その日の作業パターンを潰すのが最短になる。

削減策は「どこが重いか」を測ってから設計する。測らずに設計すると、
全体の 17% しかない項目を一生懸命に削ることになる。

定額プランなら、この換算はそのまま請求額を意味しない。
それでも消費量の物差しとしては同じように使える。

まとめ

• コーディングエージェントの支出は 83% が入力側＝会話履歴の再送で発生する
• トークン量で見ると 96% がキャッシュ読み出し。出力は 0.6% に過ぎない
• 生成量を減らす施策は、どれも上限 17%。 狙うのはターン数と履歴長
• 素の入力欄は「キャッシュに載らなかった残り」。ここだけ見て入力を過小評価しない
• ログから後追いで集計できる。案件単位の切り出しも、日別の突出も後から出せる