AIエージェントのコスト監視入門｜トークン可視化と暴走対策【2026年8月】

Q: 観測ツールは自前ログとどちらを選ぶべきですか？

エージェントが1〜2体で呼び出しの浅いうちは、レスポンスのusageフィールドを自前ログに記録するだけで十分です。エージェントが増え、ネストした呼び出しやマルチステップのトレースを追う必要が出てきたら、Langfuseのような観測ツールに移行する価値があります。オープンソースでセルフホストできるため、まず開発環境で試すのが低リスクです。

2026.08.03 公開 17分で読める

この記事の結論

AIエージェントのAPI費用が読めない方向けに、Usage API・Langfuseでのトークン消費の可視化、LiteLLMの予算上限、キャッシュとモデル振り分け、暴走ループ対策までコード付きで解説します。

「AIエージェントを本番に載せたら、月のAPI請求額が想定の3倍になっていた…」

AIエージェントのコスト監視で今すぐやるべきことは3つです。(1) Usage APIや観測ツールでトークン消費を日次で可視化する、(2) LiteLLMなどのゲートウェイでキー単位の予算上限を設定する、(3) プロンプトキャッシュとモデル振り分けで単価そのものを下げる。この3層を入れるだけで、「請求書が来るまで費用が分からない」状態からは確実に抜け出せます。

チャットボットと違い、エージェントは1つのタスクで何十回もLLMを呼びます。ツール呼び出しのたびに会話履歴が膨らみ、失敗するとリトライし、設計を誤ると無限ループします。つまりコストが「リクエスト数」ではなく「エージェントの挙動」で決まるため、従来の感覚では費用が読めません。

この記事では、実際にエージェントを運用する中で固めてきたコスト監視の実装を、可視化 → 上限設定 → 削減 → 暴走対策の順に、コピペ可能なコード付きで解説します。5分で試せるものから順に紹介していきますので、ぜひ今日から実践してみてください。

関連：本記事は「運用時の監視・暴走対策」編です。そもそものAPI従量とサブスクの選び方・料金比較は姉妹記事 AIエージェントのコスト管理｜API従量とサブスク徹底比較をご覧ください。

AIエージェントのコストが読めない3つの理由

対策の前に、なぜエージェントの費用は見積もりから外れるのかを整理しておきましょう。原因は大きく3つです。

理由1：1タスク＝N回のLLM呼び出し

エージェントは「考える → ツールを呼ぶ → 結果を読む → また考える」のループで動きます。単純な質問応答なら1回で済む処理が、エージェントでは5回、10回、複雑なタスクでは数十回のAPI呼び出しになります。しかも呼び出し回数はタスクの難易度とモデルの判断に依存するため、事前に正確な回数を見積もることがそもそもできません。

理由2：コンテキストが雪だるま式に膨らむ

ループの各ステップでは、それまでの会話履歴・ツール定義・ツール実行結果をすべて入力トークンとして再送信します。10ステップ目の呼び出しは1ステップ目の何倍もの入力トークンを消費するのが普通です。さらにツール定義自体もトークンを消費します。たとえばAnthropicの公式ドキュメントによると、ツールを1つでも定義するとモデルごとに数百トークンのシステムプロンプトが自動付加され、bashツールなら追加で244〜325トークンが乗ります。

理由3：失敗時のリトライと暴走ループ

ツール呼び出しが失敗したとき、エージェントは自律的にリトライします。これ自体は正しい挙動ですが、「失敗 → 同じ方法で再試行 → また失敗」を延々と繰り返す暴走ループに入ると、1タスクで数ドル〜数十ドルを溶かすことがあります。停止条件を実装していないエージェントは、コスト面では上限のない金融商品を持っているのと同じです。

レイヤー1：トークン消費を可視化する

最初にやるべきは現状把握です。「どのモデルに」「どの機能が」「1日いくら」使っているかが分からなければ、削減も上限設定も的外れになります。

OpenAI Usage API・Costs APIで日次消費を取得する

OpenAIは組織のトークン消費を取得するUsage APIと、請求額ベースのCosts APIを提供しています。ダッシュボードを毎日見に行く運用は続かないので、APIで取得してSlack通知やスプレッドシートに流すのが現実的です。以下は直近7日間のトークン消費をモデル別に取得する例です。

動作環境: curl / OpenAI Admin APIキー（通常のAPIキーではなく、組織設定で発行するAdminキーが必要です）

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# 直近7日間のトークン消費をモデル別・日次バケットで取得
curl -s "https://api.openai.com/v1/organization/usage/completions?start_time=$(date -d '7 days ago' +%s)&bucket_width=1d&group_by=model" 
  -H "Authorization: Bearer $OPENAI_ADMIN_KEY"

# 請求額ベースの集計はCosts APIを使う（月次の請求書と一致する値が返る）
curl -s "https://api.openai.com/v1/organization/costs?start_time=$(date -d '7 days ago' +%s)" 
  -H "Authorization: Bearer $OPENAI_ADMIN_KEY"

ポイントは次の3つです。

group_byにはmodelのほかproject_id、api_key_id、user_id、service_tier、batchが指定でき、組み合わせも可能です。エージェントごとにAPIキーやプロジェクトを分けておくと、この時点で「どのエージェントがいくら使ったか」が分解できます。
bucket_widthは1m／1h／1dから選べます（デフォルトは1d）。異常検知には1h、日次レポートには1dが使いやすいです。
金額の正としてはCosts APIを使ってください。トークン数×単価の自前計算は、キャッシュ割引やBatch割引を考慮し忘れてズレがちです。

レスポンスのusageフィールドをアプリ側で記録する

Usage APIは組織全体の集計には便利ですが、「このタスクの、このステップで何トークン使ったか」までは分かりません。そこで各API呼び出しのレスポンスに含まれるusageフィールドを、エージェントのログに毎回記録します。AnthropicのAPIならinput_tokens、output_tokensに加えてcache_creation_input_tokens（キャッシュ書き込み）とcache_read_input_tokens（キャッシュ読み取り）が返るので、キャッシュが効いているかどうかもここで判定できます。

Langfuseなどの観測ツールでトレース単位に分解する

自前ログでも始められますが、エージェントの呼び出しはネストが深く、集計・可視化を自作すると意外と工数がかかります。オープンソースのLLM観測ツールLangfuseを使うと、OpenAI SDK・LangChainなどの主要な統合でトークン数が自動キャプチャされ、OpenAI・Anthropicの主要モデルはモデル名からコストを自動計算してくれます。コストと遅延をユーザー別・セッション別・モデル別・プロンプトバージョン別に分解できるので、「どの機能の、どのプロンプト改修でコストが跳ねたか」の特定が一気に楽になります。セルフホストも可能なので、ログを外部に出せない環境でも導入できます。

レイヤー2：予算アラートと上限を設定する

可視化は「気づく」ための仕組みですが、気づいたときには使ってしまっています。次は「そもそも使えなくする」上限の設定です。

プロバイダ側の予算設定を最初に入れる

OpenAIは組織の課金設定で予算アラートとハードリミットを設定できます。まずはここで月額の上限を入れておくのが最低限の保険です。ただしプロバイダ側の上限は組織単位の粗い制御なので、「エージェントAは月50ドルまで、実験用キーは10ドルまで」のような細かい制御は次のゲートウェイ層で行います。

LiteLLMゲートウェイでキー・チーム単位の予算を強制する

オープンソースのLLMゲートウェイLiteLLM Proxyを挟むと、仮想APIキーごと・ユーザーごと・チームごとにmax_budget（USD建ての予算上限）とbudget_duration(リセット周期)を設定でき、予算を超えた呼び出しはゲートウェイがブロックします。TPM（トークン/分）・RPM（リクエスト/分）の制限も併用できるため、暴走ループの被害半径を「1キーの予算まで」に閉じ込められます。

動作環境: LiteLLM Proxy（Docker または pip）、PostgreSQL（キー管理に必要）

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
# config.yaml — プロキシ全体の設定
model_list:
  - model_name: gpt-5.5
    litellm_params:
      model: openai/gpt-5.5
      api_key: os.environ/OPENAI_API_KEY

# エージェント用の仮想キーを予算付きで発行する
# max_budget: 上限額（USD） / budget_duration: リセット周期
curl -s "http://localhost:4000/key/generate" 
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" 
  -H "Content-Type: application/json" 
  -d '{
    "key_alias": "research-agent-prod",
    "max_budget": 50.0,
    "budget_duration": "30d",
    "tpm_limit": 200000,
    "rpm_limit": 100
  }'

ポイントは以下の通りです。

エージェント1体につき仮想キー1本を発行し、キー単位で予算を切るのが基本形です。上限に達したエージェントだけが止まり、他のワークロードは動き続けます。
予算はキー → ユーザー → チーム → 組織の階層で設定でき、どこかの階層で超過すればブロックされます。
tpm_limit／rpm_limitは暴走ループの「速度制限」として機能します。予算上限が月次の保険なら、レート制限は分単位の保険です。

アラートの閾値は「日割り予算の2倍」から始める

事例区分: 自社検証
以下は社内のエージェント運用で実際に使っている運用ルールです。

アラート閾値の設計で迷ったら、まず「月予算 ÷ 30 × 2」を日次の警告ラインにしてみてください。エージェントの消費は日によって波があるので、日割りちょうどで警告すると誤報だらけになります。2倍を超えた日だけ通知し、通知が来たらLangfuse等でどのトレースが原因かを確認する、という運用が続けやすいバランスでした。

レイヤー3：コスト自体を下げる3つの実装

可視化と上限で「事故」は防げます。次は平常時のコストを構造的に下げていきましょう。

プロンプトキャッシュ：同じ文脈の再送信を9割引にする

エージェントのコスト構造で最大の割合を占めるのが、ループのたびに再送信されるシステムプロンプト・ツール定義・会話履歴です。Anthropicのプロンプトキャッシュを使うと、キャッシュ書き込みは基本入力単価の1.25倍（5分TTL）または2倍（1時間TTL）かかるものの、キャッシュヒット時の読み取りは基本入力単価の0.1倍になります。5分TTLなら1回ヒットした時点で元が取れる計算です。

動作環境: Python 3.10以上、anthropic SDK（最新版）

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
import anthropic

client = anthropic.Anthropic()  # APIキーは環境変数 ANTHROPIC_API_KEY から読む

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": LONG_SYSTEM_PROMPT,  # ツール定義や長い指示など毎回同じ部分
            "cache_control": {"type": "ephemeral"},  # ここまでをキャッシュ
        }
    ],
    messages=[{"role": "user", "content": "今日のタスクを開始してください"}],
)

# キャッシュが効いたかは usage で必ず確認する
print("cache write:", response.usage.cache_creation_input_tokens)
print("cache read :", response.usage.cache_read_input_tokens)

注意点として、キャッシュには最低トークン数があります。モデルによって512〜4,096トークンと幅があり、これより短いプロンプトはcache_controlを付けてもキャッシュされません。書き込みと読み取りが両方0のままなら、最低長を満たしていない可能性が高いです。OpenAI側もキャッシュ済み入力は割引され、GPT-5.5では通常入力5ドル/100万トークンに対してキャッシュ済み入力は0.50ドル/100万トークンです。

各社のキャッシュ仕様の違いはプロンプトキャッシュ比較2026｜3大LLMのコスト最適化戦略で詳しく比較しているので、あわせて参考にしてください。

モデル振り分け：全ステップに最上位モデルを使わない

エージェントのステップには難易度の差があります。計画立案には高性能モデルが必要でも、ツール結果の要約やフォーマット変換は小型モデルで十分です。主要モデルの単価差を見てみましょう（2026年8月3日時点、100万トークンあたり・USD）。

モデル	入力	出力	キャッシュ済み入力（読み取り）
GPT-5.5	5.00ドル	30.00ドル	0.50ドル
GPT-5.4-mini	0.75ドル	4.50ドル	—
Claude Opus 5	5.00ドル	25.00ドル	0.50ドル
Claude Sonnet 4.6	3.00ドル	15.00ドル	0.30ドル
Claude Haiku 4.5	1.00ドル	5.00ドル	0.10ドル

出典は各社の公式料金ページです（記事末の参考・出典を参照）。GPT-5.5とGPT-5.4-miniでは入力単価に6.7倍、Claude Opus 5とHaiku 4.5では5倍の差があります。「計画と最終判断は上位モデル、定型処理は小型モデル」に振り分けるだけで、タスク全体のコストは体感で半分以下になります。振り分けの設計パターンはマルチエージェントの設計パターン3選｜失敗例と実装ガイド【2026】も参考になります。

Batch API：急がない処理は50%引きで流す

夜間バッチでのデータ整形、大量ドキュメントの要約など、リアルタイム性が不要な処理はBatch APIに逃がしましょう。OpenAI・Anthropicともに、Batch経由の処理は入力・出力とも標準料金の50%引きです。Anthropicではプロンプトキャッシュの割引とBatch割引は併用可能と公式に明記されており、組み合わせると割引率はさらに大きくなります。

暴走対策：エージェントに「止まる条件」を実装する

最後が本丸の暴走対策です。予算上限は最後の砦であって、本来はエージェント自身が異常時に止まるべきです。実装すべきガードは3つあります。

最大ステップ数：ループ回数に上限を設ける。上限に達したら結果を返して終了する
タスク単位のコスト上限：累積トークンコストを毎ステップ計算し、閾値超過で中断する
同一ツール呼び出しの反復検知：同じツールを同じ引数で連続して呼んでいたら、ループとみなして打ち切る

動作環境: Python 3.10以上（フレームワーク非依存の擬似的な骨格として書いています）

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
MAX_STEPS = 20          # 1タスクあたりの最大ループ回数
MAX_COST_USD = 1.00     # 1タスクあたりのコスト上限
REPEAT_LIMIT = 3        # 同一ツール呼び出しの連続許容回数

def run_agent(task):
    total_cost = 0.0
    recent_calls = []

    for step in range(MAX_STEPS):
        response = call_llm(task.context)  # usage付きのレスポンスを返す想定

        # 1. 累積コストを毎ステップ更新（単価は設定ファイルで一元管理する）
        total_cost += estimate_cost(response.usage)
        if total_cost > MAX_COST_USD:
            return task.abort(reason=f"cost limit exceeded: ${total_cost:.2f}")

        # 2. 同一ツール呼び出しの反復を検知
        call_sig = (response.tool_name, response.tool_args_hash)
        recent_calls.append(call_sig)
        if recent_calls[-REPEAT_LIMIT:].count(call_sig) >= REPEAT_LIMIT:
            return task.abort(reason="repeated identical tool call")

        if response.is_final:
            return task.complete(response)
        task.context.append(execute_tool(response))

    return task.abort(reason="max steps reached")  # 3. ステップ数上限

ポイントは、中断時に「なぜ止めたか」を必ずログとトレースに残すことです。暴走の中断ログはそのままプロンプト改善の材料になります。無限ループやツール誤呼び出しの診断手順はAIエージェント本番デバッグ完全ガイド2026で深掘りしています。

【要注意】よくある失敗パターンと回避策

失敗1：請求ダッシュボードだけ見て「監視している」と思い込む

❌ 月末に請求額を見て一喜一憂する
⭕ 日次でモデル別・エージェント別の消費を取得し、閾値超過を自動通知する

なぜこれが重要か：エージェントの暴走は数時間単位で起きます。月次の確認では、気づいた時点で被害が確定しています。可視化の粒度は「請求サイクル」ではなく「事故に気づきたい速さ」で決めてください。

失敗2：全エージェントで1本のAPIキーを共有する

❌ 組織のAPIキー1本を全サービスに配る
⭕ エージェント・環境（本番/開発）ごとにキーやプロジェクトを分離する

なぜこれが重要か：キーが1本だと、コストが跳ねたときに犯人を特定できません。Usage APIのgroup_by=api_key_idやLiteLLMのキー別予算は、キーが分かれていて初めて意味を持ちます。

失敗3：トークン数×単価の自前計算を金額の正とする

❌ ログのトークン数から自前計算した金額で予算管理する
⭕ 自前計算は速報値とし、金額の正はプロバイダのCosts API・請求書に置く

なぜこれが重要か：キャッシュ割引・Batch割引・ツール利用の追加課金（Anthropicのweb検索は1,000回あたり10ドル等）を自前計算に反映し漏れると、実請求とズレます。ズレた数字で予算会議をすると信頼を失います。

失敗4：コスト削減を優先してすべて小型モデルにする

❌ 単価の安さだけで全ステップを小型モデルに置き換える
⭕ 計画・判断ステップの品質を評価しながら段階的に振り分ける

なぜこれが重要か：小型モデルで計画品質が落ちると、リトライやループが増えて呼び出し回数が膨らみ、単価は下がったのに総額が上がる逆転が起きます。モデル振り分けは必ず「タスク成功率×総コスト」で評価してください。

よくある質問

Q1. 最初の1歩として何から始めればいいですか？

プロバイダ側の予算アラート設定です。5分で終わるうえ、最悪の事故を防ぐ保険になります。その次にUsage API（またはコンソールのダッシュボード）で現状の消費内訳を確認し、消費が大きい箇所からキャッシュ・モデル振り分けを入れていくのが効率的です。

Q2. 観測ツールは自前ログとどちらを選ぶべきですか？

エージェントが1〜2体で呼び出しの浅いうちは、レスポンスのusageフィールドを自前ログに記録するだけで十分です。エージェントが増え、ネストした呼び出しやマルチステップのトレースを追う必要が出てきたら、Langfuseのような観測ツールに移行する価値があります。オープンソースでセルフホストできるため、まず開発環境で試すのが低リスクです。

Q3. プロンプトキャッシュはどんなエージェントでも効きますか？

「毎回同じ長い文脈を送る」ワークロードほど効きます。長いシステムプロンプト＋多数のツール定義を持つエージェントは好相性です。逆に、毎回文脈がまったく異なる単発処理や、キャッシュの最低トークン数（モデルにより512〜4,096トークン）に満たない短いプロンプトでは効果がありません。導入後は必ずcache_read_input_tokensでヒット率を確認してください。

参考・出典

Pricing | OpenAI API — OpenAI（参照日: 2026-08-03）
Usage | OpenAI API Reference — OpenAI（参照日: 2026-08-03）
Pricing – Claude Docs — Anthropic（参照日: 2026-08-03）
Prompt caching – Claude Docs — Anthropic（参照日: 2026-08-03）
Budgets, Rate Limits | LiteLLM — LiteLLM（参照日: 2026-08-03）
Token & Cost Tracking – Langfuse — Langfuse（参照日: 2026-08-03）

まとめ：今日から始める3つのアクション

今日やること: プロバイダの課金コンソールで予算アラートを設定し、Usage APIかダッシュボードで直近7日のモデル別消費を確認する
今週中: エージェントごとにAPIキー／プロジェクトを分離し、レスポンスのusageフィールドのログ記録を実装する
今月中: LiteLLM等でキー単位の予算上限を強制し、プロンプトキャッシュとモデル振り分けで平常時コストを削減。エージェント本体に最大ステップ数とコスト上限のガードを入れる

あわせて読みたい:

AIエージェントのコスト管理｜API従量とサブスク徹底比較 — そもそも従量APIとサブスクのどちらで運用すべきかの判断軸
プロンプトキャッシュ比較2026｜3大LLMのコスト最適化戦略 — 各社キャッシュ仕様の違いと使い分け

著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー10万人超。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』。

この記事を読んで導入イメージが固まってきた方へ

UravationではAIエージェント導入の研修・コンサルを行っています。

Need help moving from reading to rollout?

この記事を読んで導入イメージが固まってきた方へ

Uravationでは、AIエージェントの要件整理、PoC設計、社内導入、研修まで一気通貫で支援しています。

30分無料相談を予約支援実績を見る

※ 本記事の情報は2026年8月時点のものです。サービスの料金・仕様は変更される可能性があります。最新情報は各サービスの公式サイトをご確認ください。

AIエージェントのコスト監視入門｜トークン可視化と暴走対策【2026年8月】

AIエージェントのコストが読めない3つの理由

理由1：1タスク＝N回のLLM呼び出し

理由2：コンテキストが雪だるま式に膨らむ

理由3：失敗時のリトライと暴走ループ

レイヤー1：トークン消費を可視化する

OpenAI Usage API・Costs APIで日次消費を取得する

レスポンスのusageフィールドをアプリ側で記録する

Langfuseなどの観測ツールでトレース単位に分解する

レイヤー2：予算アラートと上限を設定する

プロバイダ側の予算設定を最初に入れる

LiteLLMゲートウェイでキー・チーム単位の予算を強制する

アラートの閾値は「日割り予算の2倍」から始める

レイヤー3：コスト自体を下げる3つの実装

プロンプトキャッシュ：同じ文脈の再送信を9割引にする

モデル振り分け：全ステップに最上位モデルを使わない

Batch API：急がない処理は50%引きで流す

暴走対策：エージェントに「止まる条件」を実装する

【要注意】よくある失敗パターンと回避策

失敗1：請求ダッシュボードだけ見て「監視している」と思い込む

失敗2：全エージェントで1本のAPIキーを共有する

失敗3：トークン数×単価の自前計算を金額の正とする

失敗4：コスト削減を優先してすべて小型モデルにする

よくある質問

Q1. 最初の1歩として何から始めればいいですか？

Q2. 観測ツールは自前ログとどちらを選ぶべきですか？

Q3. プロンプトキャッシュはどんなエージェントでも効きますか？

参考・出典

まとめ：今日から始める3つのアクション

この記事を読んで導入イメージが固まってきた方へ

関連記事

Gemini Managed Agents強化、予算管理と環境フックを追加

Bedrock Agents Classic新規停止とAgentCore移行

Nano Banana Proはどこで使える？できること・料金を整理【2026】