ブログに戻る

コスト最適化詳細解説

AIエージェントのコストを見積もる方法

エージェントの請求額が入力トークンに支配される理由、エージェント実行前に計算できる式、30ステップの計算例、コストを削減する7つの方法。

投稿者: CheapTokens Team公開日 読了時間 4 分

エージェントセッションで入力トークンがステップごとに増加するグラフと、コスト計算式
このページの内容
  1. 計算式
  2. エージェントが入力中心になる理由
  3. 計算例
  4. コードで見積もる
  5. 推測ではなく測定する
  6. コストを削減する7つの方法

AIエージェントは1回のリクエストで済むわけではない。何十回ものリクエストを行い、各ステップで増え続ける会話を再送信する。だからこそエージェントの請求額は入力トークンが大部分を占め、チャットアプリで培った「回答あたりの価格」という直感が通用しない。ここでは、エージェントを実行する前にコストを見積もる方法と、お金が実際にどこへ消えるのかを説明する。

計算式#

1回のリクエストのコストは、入力トークン数×入力単価+出力トークン数×出力単価で求められる。単価は100万トークンあたりで表示される:

text
request_cost = input_tokens / 1,000,000 × input_price
             + output_tokens / 1,000,000 × output_price

タスクのコストは、エージェントがそのタスクを解く間に行う全リクエストの合計である。

エージェントが入力中心になる理由#

各ステップでエージェントはモデルに以下を送信する:

  • システムプロンプトとツール定義;
  • これまでの履歴全体 — 以前のメッセージ、モデルの過去の回答、ツールの結果(ファイル内容、コマンド出力、検索結果);
  • 新しい指示。

モデルは通常、短いメッセージかツール呼び出しで応答する。その後、ツールの結果が履歴に追加され、次のステップで再びすべてが送信される。つまり各ステップの入力は増え続けるが、出力は小さいままだ。

計算例#

条件(仮定 — 自分のエージェントの数値に置き換えること):

  • システムプロンプトとツール定義:6,000トークン;
  • 各ステップで1,500トークンのツール結果と500トークンのモデル出力が履歴に追加される;
  • タスクは30ステップかかる;
  • モデル:DeepSeek-V4-Flash、100万入力トークンあたり$0.0221、100万出力トークンあたり$0.10(現在の単価)。

ステップnの入力は6,000+(n − 1)×2,000トークン。30ステップでは:

  • 総入力:30×6,000+2,000×(0+1+…+29)=180,000+870,000=1,050,000トークン;
  • 総出力:30×500=15,000トークン;
  • コスト:1.05×$0.0221+0.015×$0.10 ≈ タスクあたり$0.0247。

入力はトークンの98.6%を占め、コストのほぼすべてを占める。入力がどれだけ支配的かはシナリオ次第だ。長い回答、生成ファイル、推論モデルは出力の割合を上げ、履歴を削減したりツール出力を短くすれば入力の割合は下がる。

同じタスクを現在の単価で各モデルで実行した場合、比較用にOpenRouterの参考価格も示す:

モデル コスト OpenRouter
GLM-5.3-Flash $0.0296 $0.0534
DeepSeek-V4-Flash $0.0247 $0.0264
MiniMax-M2.7 $0.0548 $0.333

合計 1,050,000 入力トークンと 15,000 出力トークン。100万トークンあたりの価格は現行のもので、当社の料金体系に合わせて変動します。OpenRouter 列は同じワークロードの参考価格を示しています。

コードで見積もる#

同じ計算を関数にしたもの — 仮定と単価を変更する:

python
def estimate(steps, base_tokens, tool_tokens, out_tokens, price_in, price_out):
    """Token totals and cost of one agent task. Prices: $ per 1M tokens."""
    grow = tool_tokens + out_tokens            # what each step adds to the history
    total_in = steps * base_tokens + grow * steps * (steps - 1) // 2
    total_out = steps * out_tokens
    cost = (total_in * price_in + total_out * price_out) / 1_000_000
    return total_in, total_out, round(cost, 5)

# example rates, $ per 1M tokens — put in the current ones from the pricing table below
print(estimate(30, 6_000, 1_500, 500, price_in=0.10, price_out=0.40))
# (1050000, 15000, 0.111)

二次の項に注目:ステップ数を2倍にすると入力はほぼ4倍になる。長いセッションが高くつくのは、単一のステップのせいではなく、各ステップが履歴全体を運ぶからだ。

推測ではなく測定する#

すべての応答にはusage.prompt_tokens(入力)とusage.completion_tokens(出力)が含まれる。実際のタスクの各ステップでこれらを記録し、現在の料金を掛ければ実際のコストがわかる。ダッシュボードにはモデル別・日別の使用量も表示される。

現在の料金 — 料金ページと同じデータ:

モデル コンテキスト 入力 $/1M 出力 $/1M OpenRouter 入力 OpenRouter 出力
GLM-5.3-Flash reasoning 390K $0.027 $0.08 $0.048 $0.20
DeepSeek-V4-Flash 380K $0.0221 $0.10 $0.016 $0.64
MiniMax-M2.7 200K $0.05 $0.15 $0.30 $1.20

価格は100万トークンあたりのUSD表記です。OpenRouterの数値は比較用であり、変更される可能性があります。

コストを削減する7つの方法#

  1. 無関係な作業には新しいタスクを開始する。 新しいセッションは前のセッションの履歴を引き継がない。
  2. エージェントにはファイル全体ではなく断片を渡す。 3,000行のモジュールではなく、関数とその呼び出し元を渡す。
  3. ツール出力を削減する。 長いログやコマンド出力はセッションの残りずっと履歴に残る — 例えば| tail -n 50で制限する。
  4. 長いセッションを要約する。 多くのエージェントは履歴を圧縮できる。コンテキストが長くなる前に使う。
  5. 長い回答が不要な場合はmax_tokensで回答の長さを制限する。
  6. ステップに適したモデルを使う。 定型ステップに推論モデルは不要だ。
  7. 前払い予算を維持する。 残高は前払い制だ。使い切ると、リクエストは無制限の請求が積み上がる代わりにHTTP 402で停止する。

同じワークロードをモデル間で比較したり、OpenRouterと比較したりするには、ホームページのコスト比較を使う。