サーバー側ツールは別の請求書
更新日 September 1, 2026 · 初回公開 September 1, 2026
多くの LLM 原価モデルには計測器がひとつしかありません。入力トークン、出力トークン、100 万あたりの単価。リクエストがテキストを生成するだけだった頃は正しい考え方でした。サーバー側ツールの登場で、それは成り立たなくなりました。
ウェブ検索、ウェブフェッチ、コード実行はプロバイダー側の基盤で動き、いくつかは生成するトークンとは別に利用ごとの料金が発生します。つまりエージェントの 1 ターンで二重に課金されうるのです。
積み上がるほうの費用
見落とされるのは二つ目の課金です。ツールの結果は会話に追加され、以降のターンはその全体を入力として再送します。長い実行の序盤での 10 回の検索は、10 回分の料金だけでなく、その結果本体を以降の全ターンで読み直す費用でもあります。
トークンの計算上は線形のはずのエージェント費用が非線形に感じられるのはこのためです。利用料は見える部分にすぎず、より大きいのは文脈の肥大で、それはラベルの無いまま入力トークンの行に着地します。
按分しなければ管理できない
リクエストごとに、どのツールを何回呼び、各結果が何トークン増やしたかを usage と並べて記録してください。最後の項目こそが積み上がりを可視化します。
そのうえで、API 呼び出し単位ではなくエージェント実行単位で原価を出します。利用者が起動したのは実行のほうです。
効く対策は 3 つ
実行あたりのツール呼び出しに上限を設ける。両方の費用を同時に抑えられます。
文脈に入れる内容を削る。取得したページ全体が必要になることはまれです。
安定した接頭辞をキャッシュする。システムプロンプトとツール定義は実行中変わりません。
関連記事
この方法を自社の環境にも適用しますか？ プロバイダーの請求書、ゲートウェイログ、主要なワークフローをお持ちください。コスト要因と削減策を整理します。 無料監査を予約 →