エージェント基盤・プロトコル

エージェントのコスト制御|40往復で費用が4.3倍になり、入力の93%が過去の履歴だった

エージェントの費用は何で決まるのか会話が長くなると費用はどう増えるのか何から手を付ければ費用が下がるのか

AIエージェントを作って動かしてみたら、思ったより請求額が大きかった。よくある話です。原因は1回あたりの単価ではなく、会話のたびに過去のやり取りを全部送り直していることにあります。

今回は計算しました。往復を重ねたときのトークン量を出しています。結果を先に言うと、40往復で費用が4.3倍になり、送っている内容の93%が過去の履歴でした

この記事の要点

  • 費用は1回の単価ではなく会話の長さで決まる。履歴は毎回送り直される
  • 実測では40往復で費用4.3倍・入力の93%が履歴だった
  • 履歴を圧縮するだけで$3.891 → $0.899に下がった
  • 毎回同じ部分はキャッシュで通常入力の0.1倍になる

エージェントの費用は何で決まるのか

1回の応答の単価ではなく、会話全体の長さで決まります。やり取りのたびに、それまでの履歴を丸ごと送り直しているためです。

エージェントのコスト制御を考えるとき、費用は送った量と返ってきた量で計算されます。ここまでは単純なのですが、見落とされやすいのが「送った量」に過去のやり取りが全部含まれる点です。

AIは前回の会話を覚えていません。そのため、続きを話すにはこれまでのやり取りを毎回添えて送る必要があります。会話が長くなるほど、1回あたりに送る量が増えていきます。

毎回送っているものの内訳

エージェントの場合、送る内容は4つに分かれます。役割を指示するシステムプロンプト、使えるツールの定義、これまでの履歴、そして今回の発話です。前の3つは会話が続く限り毎回送られます

同じ部分は割引される仕組みがある

毎回同じ内容を送るなら、そこを保存しておいて再利用する仕組みがあります。プロンプトキャッシュと呼ばれるもので、公式の価格表によればキャッシュから読み出す場合は通常の入力価格の10%になります。

操作通常の入力価格に対する倍率有効期間
5分キャッシュへの書き込み1.25倍5分間
1時間キャッシュへの書き込み2倍1時間
キャッシュからの読み出し0.1倍直前の書き込みと同じ
表1 ── プロンプトキャッシュの価格倍率(出典: platform.claude.com、2026-08-17取得)
余談 単価表だけを見ても判断できない

モデルの価格表を比べて安い方を選ぶ、という判断をしがちです。ただ実際の請求額は「何トークン送ったか」で決まります。次の節で見るとおり、送る量の設計の方が単価より大きく効く場合があると編集部は考えています。

出典Claude Docs「Pricing」2026-08-17 確認
A cache hit costs 10% of the standard input price
原文Claude Docs「Pricing」 この内容の有効期限2026-11-17

40往復で4.3倍になり、入力の93%が履歴だった

会話の往復を重ねたときのトークン量を計算しました。履歴をそのまま積む場合と圧縮する場合で、費用に4.3倍の差が出ました。

エージェントのコスト制御は、言葉で説明するより数字を見た方が早いので計算しました。往復のたびに増えていくトークン量を出しています。

条件は次のとおりです。システムプロンプト1,200・ツール定義800・利用者の発話150・応答400・ツールの実行結果900トークン。価格は入力100万トークンあたり3ドル、出力15ドルと仮定しています。

text
1会話あたりのトークンと費用(入力$3 / 出力$15 per 1M と仮定)

往復数   履歴そのまま            履歴を圧縮
   5回   25,250tok $0.106       25,250tok $0.106
  10回   86,750tok $0.320       51,800tok $0.215
  20回   318,500tok $1.075      109,250tok $0.448
  40回   1,217,000tok $3.891    219,800tok $0.899

40往復での差: 4.3倍
入力トークンの内訳(40往復・履歴そのまま): 履歴が全体の 93%

開きました。40往復で$3.891と$0.899、4.3倍の差です。5往復の時点では差がありません。会話が短いうちは問題にならず、長くなってから効いてきます。

なぜ加速度的に増えるのか

1回あたりに送る量が毎回増えるからです。往復ごとに履歴が伸び、その伸びた履歴を次の回でまた送ります。増え方が足し算ではなく累積になります

送っている内容の93%が履歴だった

40往復時点の内訳を見ると、送っている入力の93%が過去の履歴でした。システムプロンプトもツール定義も今回の発話も、合わせて7%しかありません。

5往復では差がない。20往復を超えたあたりから開きが大きくなる。

単位: セント40往復(履歴そのまま)389セント20往復(履歴そのまま)108セント40往復(履歴を圧縮)90セント10往復(履歴そのまま)32セント5往復(履歴そのまま)11セントセント表示。実測値をもとにした計算結果で、価格は入力$3・出力$15 per 1M と仮定している。
図1 ── 往復数ごとの費用(1会話あたり・ドル)

圧縮といっても複雑なことはしていません。履歴が一定量を超えたら、古い部分を短い要約に置き換えているだけです。それだけで4分の1以下になります。

出典Claude Docs「Pricing」2026-08-17 確認
Cache read tokens are charged when a subsequent request retrieves the cached content.
原文Claude Docs「Pricing」 この内容の有効期限2026-11-17

何から手を付ければ費用が下がるのか

順番があります。まず履歴の扱い、次に毎回同じ部分のキャッシュ、最後にモデルの選択です。逆順にやると効果が出ません。

エージェントのコスト制御で最初にやることは、モデルを変えることではありません。送っている量を減らすことです。順に見ていきます。

1. 履歴の扱いを決める

前の節で見たとおり、長い会話では入力の9割以上が履歴になります。ここを放置したまま単価を下げても、効果は限定的です。

  1. 会話の往復数の分布を調べる。ほとんどが5往復以内なら、そもそも問題にならない
  2. ツールの実行結果を残す量を決める。直近の1〜2回分だけ残す構成が多い
  3. 古い履歴を要約に置き換える。何を残すかは用途で変わる
  4. 上限を決める。超えたら新しい会話として始め、要約だけ引き継ぐ

2. 毎回同じ部分をキャッシュする

システムプロンプトとツール定義は、会話のあいだ変わりません。ここをキャッシュすると読み出しが通常の10%になります。

ただし注意点があります。公式が明記しているとおり、キャッシュへの書き込みは最初に保存するときに課金されます。しかも通常より割高です。1回しか読まない内容をキャッシュすると、かえって高くつきます。

キャッシュは読み出す回数で損得が変わる。書き込みが割高な分を、読み出しの割引で回収する形。

毎回まったく同じ内容を送っているかいいえキャッシュは効かないはいその内容を何度も読み出すかいいえ書き込み分が割高になり損をするはいキャッシュする。読み出しが0.1倍になるシステムプロンプトとツール定義が典型的な対象。利用者ごとに変わる部分は対象にならない。
図2 ── プロンプトキャッシュを使うかどうかの判断

3. 最後にモデルを見直す

ここまでやってからモデルの選択を考えます。送る量が最適化されていない状態で単価だけ下げても、削減幅は小さいためです。判断に必要な場面だけ高性能なモデルを使い、他は軽いモデルに振り分ける構成もあります。

実際にかかっている額を把握する方法は、エージェント可観測性の記事で扱っています。どこで費用が発生しているかが見えないと、この順番の判断もできません。

価格は変わるので、自分の環境で測るこの記事の計算は入力$3・出力$15という仮定で行っています。実際の価格はモデルと時期で変わります。倍率の関係(キャッシュ読み出しが0.1倍など)は仕組みとして安定していますが、金額そのものは公式の価格表を確認してください。
出典Claude Docs「Pricing」2026-08-17 確認
Cache write tokens are charged when content is first stored.
原文Claude Docs「Pricing」 この内容の有効期限2026-11-17

よくある質問

安いモデルに変えるのが一番効きますか?
単価は下がりますが、送る量が減るわけではありません。会話が長い場合は、まず履歴の扱いを見直す方が効果が大きくなります。この記事の実測でも、同じモデルのまま4.3倍の差が出ています。
履歴を圧縮すると精度が落ちませんか?
落ちる場合があります。古いやり取りを要約に置き換えるので、細かい経緯は失われます。何を残すかは用途次第で、直近のやり取りと確定した事実だけを残す方法がよく使われます。
プロンプトキャッシュはどんなときに効きますか?
毎回同じ内容を送る部分がある場合です。システムプロンプトやツール定義が該当します。逆に毎回変わる部分には効きません。書き込み時は割高になるため、同じ内容を何度も送る場合にだけ得になります。
上限を決めておくことはできますか?
会話の往復数やトークン量に上限を設けて、超えたら新しい会話として始める方法があります。費用が青天井になるのを防げますが、利用者からは会話が途切れて見えるため、要約の引き継ぎと組み合わせるのが一般的です。

まとめ

  • 費用を決めるのは単価ではなく会話の長さ
  • 実測では40往復で入力の93%が過去の履歴だった
  • 履歴の圧縮だけで費用が4.3分の1になった
  • 毎回同じ部分はキャッシュで0.1倍まで下がる

今日から始められること

  1. 1会話あたりの往復数の分布を調べる
  2. 入力トークンのうち履歴が占める割合を測る
  3. システムプロンプトとツール定義をキャッシュ対象にできるか確認する
  4. 会話の長さに上限を設け、超えた場合の引き継ぎ方を決める

実務で組んだエージェントのコスト制御のワークフローには、値段が付きます

同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。

出品の仕組みを見る