はじめに
AIエージェントは、質問に回答するだけの生成AIとは異なり、目的に応じて推論し、外部ツールを呼び出し、その結果を確認しながら次の行動を選択する。業務を自動化できる一方で、処理の繰り返しや予期しないツール連鎖により、API利用料やクラウド費用が短時間で膨らむ可能性がある。
特に注意したいのは、クラウド事業者やAIサービスの「予算設定」を行えば、設定額に達した時点で自動停止すると考えてしまうことである。実際には、予算機能の多くは支出状況を知らせるための仕組みであり、即時の利用停止を保証するものではない。
AIエージェントを安全に運用するには、月次予算だけでなく、リクエスト前のコスト判定、実行回数の制限、異常時の遮断、外部操作前の人による承認までを一体として設計する必要がある。
AIエージェントでコストが膨らみやすい理由
推論とツール実行が連鎖する
通常のチャット型AIでは、1回の入力に対して1回の回答が返るため、コストの見通しは比較的立てやすい。これに対してAIエージェントは、「考える」「検索する」「結果を読み込む」「再び考える」といった処理を複数回繰り返す。
会話履歴や過去のツール実行結果を毎回コンテキストに含める構成では、後半の処理ほど入力トークンが増える。無限ループに至らなくても、ステップ数、検索回数、取得データ量が増えるだけで、1件の業務に必要なコストが想定を上回ることがある。
OWASPのAI Agent Security Cheat Sheetでも、無制限のエージェントループによってAPI・計算費用が膨らむ「Denial of Wallet」が主要リスクとして挙げられている。
LLM以外にも「隠れコスト」がある
運用費はLLMの入出力トークンだけではない。検索インデックス、ベクトルデータベース、ログ保存、監視基盤、外部検索API、サーバーレス処理、ネットワーク転送なども費用を発生させる。
したがって、1回のタスク原価を把握するには、モデル利用料だけを見るのではなく、エージェントが経由したサービス全体を同じ実行IDで追跡する必要がある。
「予算上限」と「ハード停止」は別の機能
各サービスの予算機能には、通知を目的とするものと、実際に利用を制限するものがある。名称だけで判断せず、どの時点のデータを使い、何を止められるのかを確認することが重要である。
| 管理機能 | 主な役割 | 注意点 |
|---|---|---|
| 月次予算・支出アラート | 支出傾向の把握、管理者への通知 | 課金データの反映に時間差があり、通知後も利用が続く場合がある |
| APIレート制限 | 一定時間内のリクエスト数やトークン量を抑える | 月間予算ではなく、短時間の負荷制御が中心 |
| エージェント内の実行制限 | 反復回数、ツール回数、処理時間を制限する | アプリケーション側での実装が必要 |
| AI Gatewayの事前判定 | 送信前に残予算や権限を確認する | エージェントを必ずGateway経由にする必要がある |
| 承認フロー | 高リスク操作を人が確認してから実行する | 状態保存、本人確認、二重実行防止が必要 |
OpenAIのプロジェクト月次予算はソフトな支出しきい値であり、超過後もAPIリクエストは継続する。Google Cloudも、アラート専用の予算は利用や支出を自動的に上限で止めるものではないと明記している。
AWS Budgetsも、利用発生から請求・通知までの遅延によって、通知しきい値を超えた追加費用が生じ得る。
つまり、請求情報を基にした予算アラートは「経営管理のための検知層」であり、数秒単位で暴走を止める「実行制御層」ではない。両者を分けて設計することが、最初の重要な判断となる。
実務で必要な予算統制の5段階
1．原価を識別できるタグを付ける
すべての推論やツール呼び出しに、エージェントID、利用者ID、部署・テナント、ワークフロー、実行セッション、モデル、ツール名などの識別情報を付与する。
これにより、「どの部門の、どの業務が、何に費用を使ったか」を集計できる。
個人単位の監視が目的ではなく、業務別の採算性と異常の発見が目的である。個人情報をログへ残しすぎないよう、IDの仮名化や保存期間も同時に定める。
2．複数段階のアラートを設ける
アラートは「超過してから知らせる」だけでは遅い。予算消化の早さ、通常時からの乖離、単一セッションの急増など、複数の条件で検知する。
例えば、注意段階では担当者へ通知し、警戒段階では高性能モデルの利用を制限し、危険段階では新規実行を停止する、といった段階的運用が考えられる。
しきい値は一律の正解を求めず、業務の重要度、停止による損失、復旧に必要な時間から決める。
3．AI Gatewayで実行前に判定する
プロバイダーAPIの手前にAI Gatewayを配置し、リクエスト送信前に予想コスト、残予算、利用者権限、対象モデル、ツール種別を確認する。
残予算が不足する場合は、APIを呼び出さずに拒否するか、安価なモデルへ切り替える。
同じ質問や定型処理ではキャッシュを利用し、不要な再推論を減らすことも有効である。ただし、回答の鮮度や権限が関係する業務では、キャッシュの利用範囲と有効期限を明確にする。
4．エージェント内部にサーキットブレーカーを設ける
エージェントの実行ルールには、次の上限を設定する。
- 最大反復回数
- 最大トークン数
- ツールごとの呼び出し回数
- 処理時間
- 同時実行数
- APIの再試行回数
外部APIが失敗した場合は無制限に再試行せず、再試行間隔を段階的に延ばす「指数バックオフ」と再試行上限を組み合わせる。
重要なのは、月次予算を使い切るまで動かすのではなく、1セッション単位で異常を閉じ込めることである。小さな単位で停止できれば、障害や誤判断の影響範囲も小さくできる。
5．停止後の復旧手順まで決める
ハード停止だけでは業務が止まったままになる。停止理由、対象セッション、消費額、最後に成功した処理、未実行の操作を記録し、誰がどの条件で再開できるかを定める。
また、全面停止だけでなく、次のような縮退運転も用意する。
- 読み取り専用へ切り替える
- 外部への送信だけを停止する
- 安価なモデルへ切り替える
- 高額な外部ツールを停止する
- 人による手動処理へ戻す
これにより、安全性と業務継続性を両立しやすくなる。
人による承認フローをどう設計するか
承認が必要な操作を先に分類する
メール送信、決済、契約、データベース更新、ファイル削除、権限変更、外部公開など、実行後に取り消しにくい操作は、人の承認を挟む対象とする。
一方、社内情報の検索や下書き作成など、影響が限定的な処理まで毎回承認制にすると、運用負荷が高まり自動化の効果が薄れる。
承認には、高リスクツールの直前で必ず停止する「固定承認」と、金額、信頼度、対象データ、操作範囲などの条件で停止する「動的承認」がある。両者を組み合わせ、危険度に応じて人の関与を変えることが現実的である。
承認画面に必要な情報
承認者には、単に「実行してよいですか」と尋ねるのではなく、次の情報を提示する。
- 実行しようとしている操作
- 対象となる相手、データ、金額、システム
- 操作を選んだ理由と根拠
- 想定コストと残予算
- 実行後に取り消せるかどうか
- 承認期限と未回答時の処理
承認内容には操作IDやツール呼び出しIDを付け、承認した操作と実際に実行される操作が一致することを検証する。
承認者の権限確認も必要であり、URLを知っているだけで他人の申請を承認できる設計は避けなければならない。
中断状態を安全に保存する
人の回答を待つ間、エージェントは実行状態を保存して停止する必要がある。
LangGraphのinterrupt機能は、グラフの状態を永続化して処理を中断し、外部入力を受けて再開するHuman-in-the-Loopを実装できる。
再開時には、承認前の処理が重複実行されないよう冪等性を確保する。例えば、外部送信や決済には一意の実行キーを付け、同じ操作が二度実行されないようにする。
状態保存先は単一サーバーのメモリに依存せず、アクセス制御された永続ストレージを利用する。
多層防御で考えるAIエージェント運用
ネットワーク・Gateway層
予想コストの事前計算、残予算の確認、ユーザー別・部署別レート制限、モデルの切り替え、キャッシュ、緊急遮断を担当する。
プロバイダーへ到達する前に止められることが重要である。
アプリケーション・ランタイム層
最大反復回数、ツール回数、タイムアウト、再試行回数、承認ゲート、二重実行防止を担当する。
エージェントの判断が誤っても、許可された範囲を超えて動作できない設計にする。
クラウド・プロバイダー層
月次予算、利用状況の可視化、請求アラート、APIクォータ、IAMによる権限制御を担当する。
ここは全体傾向の監視と最終的な安全弁として位置づける。
導入前に確認したいチェックリスト
- 1件のタスクに必要なモデル・検索・外部APIの原価を把握しているか
- 部署、ユーザー、エージェント、セッション単位で費用を追跡できるか
- 予算通知と実行停止の違いを運用担当者が理解しているか
- 最大反復回数、ツール回数、時間、再試行回数を設定しているか
- 予算超過時に拒否、縮退、停止のどれを行うか決めているか
- 外部送信、決済、削除、権限変更に承認ゲートがあるか
- 承認対象と実行対象を一意のIDで照合できるか
- 中断状態を安全に保存し、二重実行せず再開できるか
- 緊急停止と復旧の責任者、連絡先、判断基準が明確か
- コストだけでなく、成功率、処理時間、差し戻し率も継続評価しているか
まとめ
AIエージェントの予算管理は、月次上限を設定して終わるものではない。予算アラートには課金データの反映遅延があり、超過時にAPIを即時停止しないサービスもある。
そのため、実行前に判断するAI Gateway、エージェント内部のサーキットブレーカー、クラウド側の予算・権限制御を重ねる必要がある。
さらに、メール送信や決済、データ更新などの不可逆な操作には、人が内容を確認してから再開する承認フローが欠かせない。
費用の暴走と誤操作を別々の問題として扱うのではなく、「観測する・知らせる・制限する・承認する・安全に再開する」という一連の運用として設計することが、AIエージェントを企業の実務へ定着させる基盤となる。
コメント