- 公開日
AIエージェントの処理順序は、次の作業に何が必要かという依存関係から決めます。そのうえで、時間・費用・呼出回数の上限を実行環境に設定します。次の処理が一つでも上限を超えるなら、ほかの枠に余裕があっても発行を止めます。上限に達したときは、取得済みの根拠、不足、処理中の要求を返せるようにします。プロンプトの「予算内で」という一文だけでは、この停止を強制できません。
先に、作業のつながりを確かめる
たとえば「三つの公開資料を読み、共通点と相違点をまとめる」という調査なら、対象資料の確定、資料の取得、内容の照合、回答の作成という関係があります。三つの取得が互いの結果を使わなければ、同時に進める候補になります。一方、照合には取得した本文が必要です。まだ届いていない資料を読んだことにして、照合を先に終えることはできません。
並列化とは、複数の処理を同時に進めることです。判断には依存関係のほか、共有する資源も含めます。独立した検索でも、同じアカウントの呼出枠や予算を使います。同じファイルを書き換える処理なら、結果の上書きや順序の違いも問題になります。「読取りだから全部同時に」という決め方では、取得条件や資源の競合を見落とします。
OpenAIのRate limitsは、要求数と、モデルがテキスト等を扱う単位であるトークンの数などの制限を分け、組織・プロジェクト・モデル等の適用範囲も説明しています。これは同サービスの制限の例であり、どの環境でも同じ数だけ並列化できるという意味ではありません。利用する接続先の枠を確認し、同時実行数を別に決めます。
一つの短い資料を一度読むだけなら、複雑な待ち行列や多数の分岐は省けます。それでも、時間切れや取得失敗時の回答範囲は決めておきます。同じ調査を複数の担当エージェントへ分ける場合は、担当ごとの残量表示だけでは足りず、全員が使う共通の上限が必要です。
上限には、対象と数え始めを付ける
「五分、三百円、八回」と書いても、待ち時間や再試行が別扱いなら、想定より処理が長引きます。上限値と一緒に、何を含め、いつから数え、誰が止めるかを決めます。
| 上限 | 決める内容 | 見落としやすい範囲 |
|---|---|---|
| 時間 | 受付から結果を返すまでの経過時間、各要求の待機期限 | 待ち行列、再試行待ち、回答整理に使う時間 |
| 費用 | 一業務で許容する通貨建ての総額と課金対象 | モデル生成、検索、処理中の要求、終了報告の生成 |
| 呼出回数 | 何の呼出しを一回とするか、親子間で共通か | 失敗した要求、再試行、下位の処理が追加する呼出し |
費用の計測は、使った金額を知るためのものです。通知は担当者へ知らせる仕組みで、停止とは別です。OpenAIのSpend limitsでも、通知用の設定と月次の強制上限を区別しています。ただし強制上限にも反映遅延による追加使用の可能性があります。提供者の月次上限を、そのまま一件の調査の厳密な総額保証として扱うことはできません。
業務側では、次の要求を発行する前に、支出済みと処理中に確保した金額を差し引き、残りで実行できるか判定します。二つの担当が同じ残額をそれぞれ使えると判断しないよう、残量の確認と確保を共通の管理箇所で行います。単価や一要求の最大使用量を定められない処理は、厳密な金額上限を守れる範囲が不明です。その処理を保留するか、対応する実行方式に変える判断が要ります。
架空の資料調査で、終了までの枠を置く
ここからは実行していない架空例です。依頼は「指定した公開資料A・B・Cから、三サービスのデータ保存条件を出典付きで比較する。資料にない条件は未確認とする」です。対象は指定資料だけで、購入、問い合わせ送信、アカウント設定の変更は行わない前提にします。
仮定の全体上限は、受付から300秒、モデルと検索の従量費用を合わせて300円、外部資料の取得要求を計8回です。8回には失敗と再試行も含め、モデルの呼出回数とは別に数えます。ここでの300円は、税等も含めた計上額で管理でき、ほかに課金される経路がない架空環境の値です。実サービスの料金や推奨予算ではありません。
調査開始前に、最後の整理用として60秒と最大60円を確保します。資料取得と調査中の生成には240秒、最大240円の範囲を割り当て、資料取得の同時実行は2件までとします。終了報告の生成も総額へ含めます。最終生成に失敗した場合は、保存済みの結果と状態を使って、追加の有料呼出しなしで定型報告を返す設計です。
AとBの取得を同時に始め、枠が空いてからCを取得します。照合対象、根拠の採用条件、全体予算は固定し、変えるのは取得の順番と同時実行数だけです。並列化で短縮する時間はこの例では測定していません。速くなると仮定して、期限や予算を先に小さくすることはしません。
想定する分岐は次のとおりです。
- 三資料を取得でき、残量もある：原文と比較項目を照合し、出典と適用条件を付けた回答を作ります。
- Cを取得できず、8回目の取得要求を発行済み：9回目を発行せず、応答待ちの要求を識別して、取得済みのA・Bを整理します。
- 240秒の調査期限に到達：新しい調査を止め、処理中の要求へ対応可能な停止操作を行い、残りの時間で結果と不足を返します。
- 次の要求の費用を確保できない：回数や時間に余裕があっても発行せず、予算不足を停止理由にします。
部分回答には「A・Bの指定箇所は取得済み。Cは取得未完了のため比較できない。取得要求の上限により追加取得を停止。Cを含めた結論は保留」と記します。本文を受け取っていないCの条件を、記憶や他サービスの傾向から補いません。取得済みでも根拠として照合できていない箇所は、その状態を別に示します。
止める対象を、未発行と処理中に分ける
上限到達後の新しい呼出しは、実行環境で拒否できます。一方、すでに外へ渡した要求は、停止を要求しただけで消えるとは限りません。
外部ツールとの接続規約であるMCPのCancellation（2026-07-28版）にも、処理完了との行き違いや、取り消せない要求などの扱いが示されています。取消方法は通信方式にも依存します。この違いを踏まえ、運用記録では「停止要求済み」「停止確認済み」「すでに結果あり」を分けます。取消信号を、課金や外部への変更の巻戻し保証にはできません。
この調査例なら、応答待ちの要求ID、取得済み本文、未照合の箇所を残します。費用がまだ確定していない要求は、確保額を勝手に解放して次の処理に使いません。300秒の報告期限には、停止を確認できていない要求も「結果未確認」として返します。後から結果が届いても、それを理由に停止済みの調査を自動再開しません。
再試行にも同じ上限がかかります。前掲のRate limitsでは、失敗した要求も毎分制限へ影響することが説明されています。失敗だから無料・回数外と決めず、再試行の待ち時間や接続用ライブラリの自動再試行も数える対象にします。別のエージェントへ渡す、別アカウントへ切り替えるといった方法で上限を回避してはいけません。
指示、実行環境、人の判断をつなぐ
プロンプトには、調査対象、優先する資料、不足の書き方、上限で返す内容を記します。実行環境は、時計、共有の残量、発行済み要求を管理し、新規発行を拒否します。人は、不足するCが結論に必要かを判断し、続けるなら追加範囲と新しい上限を承認します。使える予算が残っていても、送信や購入の権限が増えるわけではありません。
運用前の確認では、外部へ作用しない環境で、期限直前、残額不足、回数上限、取消未確認をそれぞれ与えます。新しい要求が出ないか、部分結果と未確認状態が残るかを確認します。停止した記録だけでは、課金の確定や処理中要求の収束まで確認したことにはなりません。どの上限で止まり、何が返せて、何が残ったかを一件の記録で追える状態にします。
費用上限の設計と予算の事前確保は「Agentの反復とツール呼び出しに費用上限を設ける方法」、依存関係・並列化・優先度から処理順序を決める方法は「AIの処理順序を、依存関係・並列化・優先度から設計する」で解説しています。
Batch・非同期処理に回せる業務の見分け方は「Batch・非同期処理に回せる業務を、締切と結果回収から判断する」で解説しています。
