LLM API でエージェントを動かすと、請求額が直感より大きくなります。入力と出力のトークン単価から見積もったはずが、合わない。その差の正体を数字で示した記事が出ていました。犯人は、料金を安くするはずのプロンプトキャッシュの読み取り課金です。
キャッシュは「安くする仕組み」のはず
プロンプトキャッシュは、会話の先頭から変わらない部分（システムプロンプトやツール定義、過去のやり取り）をキャッシュしておき、次のターンでは割引価格で読み込む仕組みです。新規入力の何分の一かの単価なので、使えば安くなる、と説明されます。
割引自体は本当です。問題は、割引価格で読む量が、ターンを重ねるごとに増えていくことです。
実測。100ターンで費用の76%がキャッシュ読み取りになる
記事は、ツールを呼びながら100ターン進むエージェントのセッションを試算しています。Claude Opus 5 の場合はこうです。
- 20ターン時点: 合計の内訳は、キャッシュ読み取り $1.04（44.9%）、新規入力 $1.03（44.3%）、出力 $0.25（10.8%）。まだ拮抗しています
- 100ターン時点: キャッシュ読み取り $16.31（76.4%）、新規入力 $3.78、出力 $1.25。読み取りが支配的になります
入力と出力だけを見て立てた見積もりは、このセッションでは実際の4分の1程度になる計算です。安いモデルとの差も開きます。同じ100ターンを DeepSeek V4-Flash で回した試算は合計 $0.19 で、2桁違います。
なぜ二次関数的に増えるのか
構造は単純です。エージェントは1ターンごとに、それまでの文脈全体を読み直します。ツールの呼び出し結果が積み上がるほど、次のターンで読む量が増える。nターン目のコストがほぼnに比例するので、セッション合計はnの2乗に比例して伸びます。
キャッシュの割引は、この読み直しの単価を下げてくれますが、読み直しの量そのものは減らしません。単価の割引と量の増加が掛け合わさった結果が、費用の76%という数字です。長く走るエージェントほど、料金表のどの行より「何回読み直すか」が効きます。
削るならターン数。効果は増幅される
記事には設計側への示唆がひとつ書かれています。ツールの呼び出しを10%減らすと、実行コストは約16%減る。コストがターン数の2乗で伸びるので、ターン削減の効果は割合以上に返ってきます。
ここから判断の順番が決まります。
- 最初にやるのはターン数の削減 — 1回で済む問い合わせを分割しない。複数の情報を1つのツールでまとめて返す。モデルを安いものに替えるより先に、ここを見る
- ツール定義を重くしない — 会話の先頭に載るツール定義は、毎ターン読み直される固定費になる。使われていないツールを外すことが、そのまま料金の削減になる
- 長いセッションを設計で切る — 100ターン走る前に、要約して新しいセッションに引き継ぐ設計は、文脈の質だけでなく費用の面でも効果がある
前に「AIエージェントに渡すトークンは、減らせば良いわけではない」という記事で、道具の数と呼び出し段数を減らすことが精度を上げる、と書きました。今回の試算は同じ結論に料金の側から到達しています。選択肢とターンを減らすことは、精度と費用の両方に、同じ向きに効きます。精度のためにやった設計が請求書でも報われる、という珍しく気持ちのいい一致です。