AIエージェントを業務に入れると、最初は「どのモデルが安いか」「どのプランを買うか」に目が行きます。けれど、現場で困るのは請求書の比較ではありません。調査 agent が巨大な context を何度も読み直す。review automation が同じ PR を何回も見に行く。subagent を増やしたら token と外部 API call が一緒に増える。MCP 経由の検索や SaaS 操作まで混ざる。こうなると、月末に初めて気付く予算管理では遅いです。
この記事では、AIエージェントの 予算ガードレール設計 を扱います。ツールごとの料金比較は AIコーディングツール料金比較 2026、稼働中の異常検知は AIエージェント本番監視設計ガイド、通常運用中の pause / cancel は AIエージェント run control 設計ガイド、承認フローは AIエージェント承認フロー設計ガイド に分けています。
今回の論点は、run を開始する前に予算単位を決め、実行中に超過しそうなら縮退・承認・停止へ分岐させることです。
先に結論: budget は月額ではなく run に持たせる
AIエージェントの費用を「月額いくらまで」にだけ寄せると、運用では使いにくいです。月額上限は経理上は必要ですが、agent が今まさに暴走しているかは分かりません。
私なら、まず次の4層で予算を分けます。
| 層 | 目的 | 例 |
|---|---|---|
| workspace budget | 組織全体の支出上限と通知 | 月額利用、credit、workspace spend |
| lane budget | 用途ごとの配分 | PR review、SEO automation、support triage |
| run budget | 1回の作業で使ってよい上限 | token、tool call、runtime、外部API費用 |
| step budget | 高コスト操作の局所制限 | deep research、subagent fan-out、MCP search |
大事なのは、workspace budget を最後の防波堤にしないことです。OpenAI の API project budget は利用状況の監視と通知に使えますが、project budget 自体は hard cap ではありません。Claude Code も token usage、team spend limit、usage breakdown を見られますが、それだけで「この run を続けてよいか」は決まりません。
つまり、請求側の budget と、agent runtime 側の budget gate は別物です。
既存テーマとの役割分担
このクラスタでは cost を少しずつ扱っています。予算ガードレールの境界を先に切ります。
| 近いテーマ | 扱うこと | 予算ガードレールで扱うこと |
|---|---|---|
| 料金比較 | どのツール・プランを選ぶか | 選んだ後に run 単位でどう使いすぎを止めるか |
| 本番監視 | cost spike を検知する | spike 前に budget を割り当て、超過時の分岐を決める |
| run control | pause / resume / cancel の状態 | cost 超過をどの状態遷移に落とすか |
| retry 設計 | 失敗後に安全にやり直す | retry ごとに追加予算を自動で積まない |
| 承認フロー | sensitive tool call を止める | 高額操作や外部課金操作を承認へ戻す |
予算ガードレールは「節約術」ではありません。節約だけを目的にすると、必要な調査まで止めて品質が落ちます。目的は、どの仕事にいくら使う価値があるかを実行前に明示し、途中で前提が崩れたら人間へ戻すことです。
最小の budget packet を作る
run を開始するとき、私は context packet とは別に budget packet を渡します。
budget_packet:
budget_id: "budget-seo-blog-20260709"
lane: "content_publish"
owner: "content-ops"
currency: "usd"
max_estimated_cost: 8.00
max_total_tokens: 350000
max_runtime_minutes: 90
max_tool_calls:
web_search: 20
github_read: 50
github_write: 3
mcp_external: 10
model_policy:
default: "standard"
escalation_requires_approval: true
stop_conditions:
- "estimated_cost >= 0.8 * max_estimated_cost"
- "same_tool_same_target_failed >= 3"
- "subagent_count > 3"
- "external_write_without_approval"ここで max_estimated_cost だけを入れても弱いです。token、tool call、runtime、external write を分けておかないと、どこで増えているか分かりません。
実務では、金額が正確でなくても構いません。最初は概算でよいです。重要なのは、run の途中で「残り予算が少ないので、深掘りを続けるか、人間に判断を戻すか」を決められることです。
token budget は input / output / cached を分ける
token cost は、単純な総 token 数だけでは見誤ります。Codex の rate card は input tokens、cached input tokens、output tokens を分けて credit 消費を示しています。OpenAI Agents SDK も run ごとの usage と per-request usage を取れるので、どの request が膨らんだかを追えます。
最低限、次のように分けます。
{
"agent_run_id": "agent-20260709-budget-001",
"usage": {
"requests": 8,
"input_tokens": 184000,
"cached_input_tokens": 92000,
"output_tokens": 21000,
"reasoning_tokens": 6000,
"estimated_cost_usd": 3.42
}
}見るべき判断は3つです。
- input が増えている: context が太い、同じ資料を読み直している
- output が増えている: 要約粒度が粗い、途中成果物を長く書きすぎている
- request が増えている: retry、handoff、subagent、tool loop が増えている
OpenTelemetry GenAI semantic conventions でも input / output / cache read / reasoning などの token usage を扱う方向が示されています。vendor 固有の dashboard だけに閉じず、自社の agent_run_id と合わせて保存しておくと、後から lane 別の予算判断に使えます。
tool budget は「回数」ではなく「種類」で切る
tool call は回数だけで制限すると失敗します。Read を100回呼ぶのと、外部 SaaS に1回書き込むのでは意味が違います。
私は tool budget を次の tier で切ります。
| tier | 例 | 既定動作 |
|---|---|---|
| inspect | file read、search、status 確認 | 広めに許可 |
| compute | build、test、local script | 回数と runtime を制限 |
| retrieve | web search、MCP search、社内 docs 検索 | source と回数を制限 |
| draft | PR body、issue draft、patch proposal | 許可 |
| write | PR作成、comment 投稿、DB update | 承認 or 小さい上限 |
| paid_external | 有料API、長時間 browser、heavy crawl | 事前承認 |
この分類は AIエージェント tool risk tier 設計ガイド とつながります。risk tier は危険度を扱いますが、budget tier は消費量と課金面を扱います。同じ tool でも、read は低リスク・低コスト、bulk search は低リスク・高コスト、write は高リスク・低回数のように分かれます。
rate limit と budget limit を混ぜない
rate limit は「短時間にどれだけ呼べるか」です。budget limit は「この仕事にどれだけ使う価値があるか」です。
OpenAI の rate limit docs では、分あたりの上限内でも短い時間単位へ量子化され、burst や長すぎる context で rate limit error が出ることがあります。つまり、rate limit error は「予算を使い切った」ではありません。
混ぜると、次のような事故が起きます。
| 事象 | 誤った解釈 | 正しい分岐 |
|---|---|---|
| 429 が出た | 予算超過だから停止 | backoff、batch 分割、max tokens 縮小 |
| 月額 alert が来た | いまの run が悪い | lane 別 usage を見て原因を切る |
| 1 run の cost が急増 | rate limit を上げる | context / retry / subagent / tool loop を調べる |
| 外部 API が高い | model を安くする | paid external tool を承認制にする |
rate limit は可用性の制御、budget は意思決定の制御です。両方必要ですが、同じ dashboard に置くだけでは不十分です。
cost overrun は状態遷移に落とす
予算超過を検知したら、単に「高いです」と通知するだけでは弱いです。run state に落とします。
budget_event:
agent_run_id: "agent-20260709-budget-001"
event: "budget_threshold_reached"
threshold: 0.8
estimated_cost_usd: 6.52
remaining_budget_usd: 1.48
recommended_transition: "waiting_approval"
options:
- id: "continue_with_same_budget"
risk: "may stop before final verification"
- id: "increase_budget_to_12_usd"
risk: "requires owner approval"
- id: "summarize_and_stop"
risk: "deliver partial result"私は、しきい値を3段階にします。
| しきい値 | 動作 | 目的 |
|---|---|---|
| 50% | log のみ | 早めに傾向を見る |
| 80% | summary を作って続行判断 | 残りで終えられるか見る |
| 100% | auto stop or approval | 無制限続行を防ぐ |
重要なのは、80% の時点で要約を作らせることです。100% で止めるだけだと、途中まで何を見たのか分からないまま終わります。80% で findings_so_far、remaining_questions、cost_driver を出させると、人間が追加予算を出す価値を判断できます。
retry に新しい予算を自動で渡さない
AIエージェントのコスト事故は、単発の高額 run より retry で起きやすいです。
1回目: test failure
2回目: 別の修正を試す
3回目: さらに依存を調べる
4回目: web search を広げる
5回目: subagent に調査を投げるそれぞれは妥当に見えても、合計では最初の依頼価値を超えます。
retry packet には、前回予算の消費量を必ず入れます。
retry_budget:
previous_run_cost_usd: 4.80
previous_token_total: 260000
retry_budget_usd: 2.00
allow_new_research: false
allow_same_tool_retry: 1
require_human_if:
- "new_dependency_needed"
- "external_write_needed"
- "third_failure_on_same_target"詳しい retry state は AIエージェント再実行設計ガイド に分けています。予算ガードレール側では、retry を「新しい作業」ではなく「残り価値の中でやる再挑戦」として扱うのがポイントです。
私が最初に入れる実装順
最初から複雑な FinOps dashboard を作る必要はありません。私は次の順で入れます。
- lane ごとに
max_cost_per_runとmax_runtime_minutesを決める - run ごとに
agent_run_idとbudget_idを持たせる - token usage、tool call count、runtime を1つの log に集める
- 80% 到達時に
findings_so_farを出させる - paid external / write / subagent fan-out を承認制にする
- retry packet に前回 cost と追加予算を入れる
- 2週間ごとに lane budget を見直す
この順なら、最初の実装は小さいです。OpenAI Agents SDK を使っているなら run usage を取り、Codex や Claude Code の場合は usage panel / /usage / trace / automation log を集めるところからで十分です。
よくある失敗
1. 月額上限だけで安心する
月額 budget alert は必要ですが、run を止める設計ではありません。通知が来た時点で、どの lane、どの run、どの tool が原因かを追えないなら、運用としては遅いです。
2. 安いモデルへ寄せるだけで解決しようとする
安いモデルに変えても、context が太い、retry が多い、subagent が増えすぎる、外部 API が高い、という問題は残ります。モデル選択は最後ではありませんが、最初の唯一のレバーでもありません。
3. subagent を無料の並列化として扱う
subagent や agent team は、別 context を持つ別 run に近いです。調査を並列化すると速く見えますが、context window と要約コストは増えます。並列数はレビュー能力だけでなく、budget packet にも入れるべきです。
4. 予算超過を失敗扱いにしない
成果物が出たから成功、では危険です。予算を2倍使ったなら、output contract に budget_overrun を残します。成功扱いにすると、次回も同じコストで走ります。
まとめ
AIエージェントの予算管理は、請求書を見る作業ではありません。run を始める前に、token、tool、runtime、外部API、retry、subagent の上限を決める運用設計です。
私なら、最初から大きな管理基盤は作りません。budget_packet を1枚足し、usage を agent_run_id に寄せ、80% 到達時に要約して止まれるようにする。ここまで入れるだけで、AIエージェントは「動いたら終わり」ではなく「価値に対して使いすぎていないか」を判断できる運用対象になります。