AIエージェントのコストはなぜ膨らむ？1タスク原価の測り方

結論：安い呼び出しより、少ない手戻りで完了できるか

1回あたりの生成料金を半分にしても、必要な呼び出し数が3倍になればモデル費用は増えます。さらに検索や外部API、実行環境の料金が加わるなら、トークン単価だけでは採算を判断できません。エージェントの費用管理は、仕事の開始から完了までを1つの単位として捉えるところから始まります。

まず『成功』を業務の言葉で決めてください。問い合わせなら正しい回答で解決した件数、請求書処理なら必要項目が正しく登録された件数、調査なら担当者が採用できた成果物の件数です。HTTPの成功応答や、文章を最後まで生成できたことだけを成功と扱うと、実際の価値と指標がずれます。

Anthropicはエージェントの設計で、複雑さを増やす前にシンプルな構成を検討し、費用と遅延のトレードオフを評価する考え方を示しています。すべての段階をAIの自律判断へ任せず、定型処理は決まった手順にすることも比較対象になります。

この節の一次情報：Anthropic公式：Building effective agents

図解：1件の依頼が、複数の課金へ分岐する

たとえば企業調査レポートの作成を考えます。計画を立てるモデル呼び出し、複数の情報源の検索、取得した内容の整理、回答の検証が発生します。検証で根拠不足が見つかれば追加調査が走り、同じ依頼の内部で費用が積み上がります。下の図は構造を説明する模式図で、特定製品の実測トレースではありません。

並列化は待ち時間を短くできますが、呼び出しが無料になるわけではありません。各枝の費用は合算し、応答時間とは別に管理します。親タスクに子処理の集計値を載せる場合、その親の集計値と子の実費を再度足して二重計上しないようにします。

費用が増える、見落としやすい5つの理由

第1は履歴の増大です。各ステップで過去の会話やツール結果を入力し直す構成では、後半ほど入力が長くなります。第2は検索結果やツール定義の肥大化です。必要のない項目まで渡すと、利用者には見えない入力が増えます。削る際は、正しく判断するための根拠も消していないかを評価します。

第3は再試行とやり直しです。一時的な失敗から復旧する再試行と、計画の誤りを修正する再実行は分けて記録します。第4は多重の検証です。複数モデルで毎回評価する構成は有効な場合もありますが、簡単な形式チェックまで生成AIへ依頼すると、確認の費用が本処理を上回る可能性があります。

第5は外部サービス料金です。検索、文書解析、ブラウザ実行、保存、ベクトル検索などは、モデルとは異なる課金単位を持ちます。ツール呼び出しの命令や戻り値にモデル料金がかかり、別途ツール料金もかかるケースを区別します。『ツール1回だから1料金』とは限りません。

成功タスク原価を計算する

基本式は『対象業務で発生した費用の合計÷成功タスク数』です。モデル利用料には成功に至らなかった呼び出しも含めます。外部ツールと実行基盤の従量費を足せば変動原価、人の確認費や共通基盤の配賦まで含めれば、より広い総原価を表せます。どの範囲の数字かを指標名に明記することが重要です。

以下は実測ではない説明用の試算です。月1,000件の依頼、成功800件、モデル費用24,000円、外部ツール8,000円、基盤従量費4,000円と仮定します。依頼1件あたりは36円ですが、成功1件あたりは45円です。もし失敗した200件の費用を除外すれば、サービスの採算を実態より良く見せてしまいます。

人の確認が100件に必要で、1件5分、社内計算用の時間単価を3,000円と仮定すると、確認費は25,000円です。これを含めた成功1件あたりの費用は76.25円になります。時間単価は説明用の仮定で、実際には自社の計算方針へ置き換えます。自動処理が安く見えても、人への差し戻しが増えると総原価は上がります。

安いモデルが、本当に安いとは限らない

同じ1,000件を処理するA案とB案を比較します。A案は変動費36,000円で成功800件、B案は変動費30,000円で成功600件という仮定なら、成功原価はA案45円、B案50円です。B案は総額が低くても、完了した仕事の単位では割高です。

逆に、高性能モデルを使って少ない手順で終える方が、再試行や人の確認を減らせる場合もあります。どちらが有利かはタスク次第なので、モデル名や単価だけで結論を出さず、同じ難易度の評価データで比較します。難しい案件だけ片方へ回した数字を直接比べないことも重要です。

成功の判定が後日になる業務では、完了が確定した同じ依頼群で比較します。月末に大量の処理を開始すると、費用だけ当月に入り成果が翌月へずれることがあります。月次の請求管理に加えて、依頼開始週ごとに結果を追うと、施策の効果を読み違えにくくなります。

計測設計：タスクIDとトレースを結び付ける

OpenTelemetryのトレースは、複数サービスをまたぐ処理の流れを追う考え方です。1つの処理単位をスパンとして記録し、親子関係でつなぎます。エージェントでは業務タスクとトレースを対応させ、計画、モデル生成、検索、ツール実行、検証を区別すると、どこで費用が増えたかを追いやすくなります。

以下の項目は編集部が提案する最小の管理項目で、特定のSDKの必須フィールド名ではありません。顧客識別子は本文と切り離し、費用分析に不要な個人情報やAPIキーを記録しない設計にします。詳細な入出力が必要な検証と、日常の費用集計では保存範囲を変えられます。

この節の一次情報：OpenTelemetry公式：Traces

正しい集計のための、3つの注意点

まず、各リクエストの利用量を優先して保存します。文字数から推定したトークン量は、画像、音声、推論、キャッシュ等の課金を十分に表せないことがあります。取得できなかった費用をゼロにせず、『未取得』や『推定』として区別し、後から明細で補完します。

次に、課金区分を重複させないことです。Langfuseの費用追跡資料も、通常入力とキャッシュ入力などを重複しない区分として扱う必要を説明しています。親タスクの合計と子スパンの実費、Gatewayの集計と提供元の明細をそのまま合算しないよう、どちらを原本にするか決めます。

最後に、トレースを間引く場合の扱いです。障害分析用のサンプリング結果だけを足しても、月間費用の全額にはなりません。費用台帳は全件の利用明細を持ち、詳細トレースの保存率とは分けます。推定集計を使うなら、その比率と推定方法をダッシュボードに明記します。

単価の更新日も残してください。過去の利用量を今日の料金で再計算した値と、当時実際に発生した費用は別の数字です。施策比較用の試算と会計上の利用実績を分離しておけば、モデルの値下げと自社の改善効果を区別できます。

この節の一次情報：Langfuse公式：Token & Cost Tracking

予算上限は、開始前・実行中・終了後の3段階で守る

開始前には顧客やタスクの残予算を確認します。実行中はモデル呼び出しだけでなく、外部ツール回数、反復回数、経過時間を確認します。終了後に実費と結果を確定し、未完了や失敗も含めて集計します。この三段階は編集部の設計例で、導入製品の標準動作を保証するものではありません。

特に並列処理では、複数の枝が同じ残予算を見て同時に開始する問題があります。費用の見積額を実行前に予約し、完了後に差額を戻すなど、同時実行を意識した仕組みが必要です。それでも課金通知の遅れや実行中の処理があるため、厳密な上限の保証範囲はシステムごとに検証します。

上限到達時は、途中結果と未確認項目を返す、人へ引き継ぐ、追加の実行許可を求めるなど、業務が理解できる終了状態を用意します。途中で止まった仕事を成功扱いしないことが重要です。返金・送信・更新のような外部への操作では、再開時に同じ操作を二度行わない仕組みも必要になります。

平均だけでなく、高額な上位5%を調べる

平均原価が安定していても、一部の依頼が延々と探索を続けている可能性があります。中央値、95パーセンタイル、最大値を並べると、多数の通常案件と少数の高額案件を分けて見られます。95パーセンタイルは、並べたデータのおおむね95%が収まる費用水準であり、全件がそこまでで終わる上限ではありません。

高額な依頼を追うときは、難しいが価値の高い仕事と、失敗して同じ操作を繰り返す仕事を分けます。前者を一律停止するとサービス価値が下がり、後者を放置すると費用だけ増えます。停止理由、成果の評価、人への引き継ぎ率を組み合わせて判断します。

週次レビューは、総費用、成功原価、成功率、遅延、高額タスクの具体例に絞ると続けやすくなります。原因が見つかったら、検索件数や反復上限など1つの条件だけを変更し、同じ種類の依頼で比較します。

導入前チェック：安くする前に、測れる状態にする

最初から大規模な分析基盤を作る必要はありません。まず1つの機能で、依頼開始から成功判定までを追い、費用の紐付けができるか確認します。集計用スプレッドシートには顧客やプロンプトの機密本文を入れず、機能別の金額・件数・成功率・課題を記録する形から始められます。

効果測定では、固定した代表タスクと少量の本番データを併用します。通常ケースだけでなく、長文、検索失敗、外部APIの遅延、上限到達を含めて検証します。予算内に収まったかだけではなく、利用者へ返す結果や再開方法が分かるかも確認してください。

• 業務上の成功条件を、HTTPの成功とは別に定義したか
• 失敗・再試行・外部ツールを含め、タスクへ費用を結び付けたか
• 推定値、未取得、請求確定値を区別できるか
• 反復回数・時間・費用それぞれに停止条件があるか
• 並列実行と途中停止の費用を検証したか
• 成功原価と品質を同じ依頼群で比較できるか

まとめ：原価の単位を、トークンから仕事へ広げる

トークン単価は重要ですが、それだけではエージェントの費用は説明できません。入力の増大、並列探索、やり直し、ツール、人の確認まで含めて、1つの仕事がどう完了したかを測ります。安いモデルの選定と、少ない手戻りで成功する設計は別の改善軸です。

最初に取り組むなら、費用の大きい機能を1つ選び、成功条件とタスクIDを決め、1週間分を集計してください。高額な失敗の理由が分かれば、単価交渉の前に改善できる部分が見えてきます。利用状況が整理できた段階で、当サイトの無料診断ではモデル構成や月額に応じた見直しの方向を相談できます。