deadline）¶

このダイヤルは何か¶

予算上限は、エージェントが1つのタスクに費やすことができるリソースの上限を制御するダイヤルです。リソースには3つの次元があります。ステップ数（max_steps）、コスト（USD/トークン上限）、そして時間（deadline）です。これらのいずれか1つでも上限に達した時点でエージェントは停止し、部分結果を返すか人間にエスカレーションします。

AIエージェントシステムでは、1リクエストが高コスト（F2）であり、自己ループ（F13）によって計画-反省-再帰のサイクルが無限に繰り返される可能性があります。予算上限が無ければ、エージェントは「もう少し改善できるかもしれない」と判断して際限なくLLMを呼び出し続け、1リクエストで数十ドルの請求が発生する「請求事故」を引き起こしかねません。

このダイヤルの核心は「有用な作業を途中で切る害」と「暴走による請求事故の害」のバランスです。予算を厳しくしすぎると価値ある作業が中断されますが、緩くしすぎると1つの暴走リクエストが月間予算の大部分を食い潰します。重要なのは、予算上限は単にルートのエージェントに設定するだけでなく、サブタスクへの委譲時に残り枠を差し引いて伝播する（カスケードする）ことです。

効かなすぎる害 ⇔ 効きすぎる害¶

効かなすぎる害（予算上限が低すぎる）¶

予算上限を低く設定しすぎると、エージェントが有用な作業を完遂できません。

調査タスクで10本の文書を分析する必要があるのに、max_steps=5で打ち切られ、不完全な結論を返します
複雑な推論問題で、あと1ステップで正解に到達できたのに、コスト上限のためにタイムアウトします
サブタスクに予算を分配した結果、各子タスクの予算が少なすぎてどれも有意義な結果を出せず、全体として使い物にならない出力になります
ユーザーの期待する品質に達する前に処理が止まり、「もっとやらせたい」のにシステム側の都合で中断されます

効きすぎる害（予算上限が高すぎる/設定なし）¶

予算上限が無いか高すぎると、暴走のリスクが制御できません。

請求事故 — 無限ループに陥ったエージェントが数百回のLLM呼び出しを繰り返し、1リクエストで$50を超える請求が発生します
ループ暴走 — 自己修正のサイクルが収束せず、「修正→失敗→修正→失敗」を延々と繰り返します
リソース独占 — 1つの暴走タスクがGPUやAPI枠を長時間占有し、他のリクエストが処理できなくなります
UX悪化 — ユーザーが10秒で完了を期待しているのに、バックグラウンドで5分間処理が続き、最終的にタイムアウトします

決め方¶

このダイヤルは [cost_sensitivity] と [request_value] の2つの駆動変数で決めます。1リクエストにどれだけの投資価値があるか、コスト超過がどれだけ痛いかのバランスです。

3次元の予算を組み合わせる¶

ステップ数・コスト・時間の3つの制約を同時に設定し、いずれか1つでも上限に達したら停止します。1次元だけの制約では抜け穴が生じます。たとえばステップ数だけ制限しても、1ステップが大量のトークンを消費すれば請求事故は防げません。

タスク種別ごとに設定する¶

すべてのタスクに同じ予算を適用するのは合理的ではありません。対話型の応答（短く速い）、調査・分析タスク（長く深い）、自動化ワークフロー（定型で予測可能）では適切な予算が大きく異なります。

枯渇時の振る舞いを事前に設計する¶

予算が尽きた時に「例外を投げて終わり」では不十分です。以下の3つの選択肢を事前に決めておきます。

部分結果を返す — 途中までの作業成果をユーザーに返します。「10件中7件の分析が完了しました」のような形式です
人間にエスカレーション — 予算を追加するか、方針を変更するかをユーザーに判断してもらいます
縮退モデルに切替 — 高性能モデルから軽量モデルに切り替えて、残り予算内で処理を続行します

カスケード伝播¶

サブタスクに予算を渡す際は、残り予算から自身の集約コスト（予備枠）を差し引いた値を渡します。予備枠の目安はルート予算の10〜20%です。

目安値（出発点）¶

タスク種別	max_steps	cost上限	deadline
対話系（チャット応答）	5〜10	$0.05〜$0.50	10〜30秒
調査・分析系	20〜50	$1〜$5	5〜30分
高価値タスク（契約書生成、コード生成等）	30〜100	$5〜$20	10〜60分
定型バッチ処理	タスクに固定	タスクに固定	SLAに準拠

コスト上限の出発点は「1リクエストの価値の数%以下」です。たとえばリクエスト1件あたり$100の売上を生む場合、コスト上限は$1〜$5が妥当な出発点になります。[cost_sensitivity] が高い（利益率が低い、スケールが大きい）場合は上限を絞り、[request_value] が高い場合は上限を広げます。

具体的なシナリオ¶

シナリオ1：カスタマーサポートチャットボット¶

ユーザーの質問に対して検索・回答を行うチャットボットです。1回の応答にかかるコストは低く、短時間で完了すべきです。

max_steps: 5〜10（質問分析→検索→回答生成の基本フロー）
cost上限: $0.05〜$0.20（薄利多売のため1リクエストあたりのコストは低く抑える）
deadline: 10〜30秒（ユーザーは即座の応答を期待する）
枯渇時: 「ご質問にお答えできませんでした。サポート担当者にお繋ぎします」のフォールバック

シナリオ2：法的文書の調査・分析¶

複数の法的文書を検索・分析し、レポートを生成するエージェントです。高い品質が求められ、時間に余裕があります。

max_steps: 50〜100（多数の文書検索、各文書の分析、クロスリファレンス）
cost上限: $10〜$50（1件のレポートが数十万円の価値を持つため）
deadline: 30〜60分（品質重視、バックグラウンド実行）
枯渇時: 部分結果を返し、「以下の文書は未分析です」と明示する

シナリオ3：コード生成・リファクタリング¶

大規模なコードベースに対する変更を生成するエージェントです。

max_steps: 20〜50（ファイル読み込み→分析→変更生成→テスト実行）
cost上限: $1〜$5（開発者の時間節約が価値）
deadline: 5〜15分
枯渇時: 変更済みファイルのdiffを返し、残りの作業は手動で行ってもらう

シナリオ4：並列サブタスクの予算管理¶

親エージェントが3つの子エージェントに調査を並列委譲する場合の予算配分です。

親の予算: deadline=300秒, cost=$3.00, steps=30

各子エージェント: deadline=250秒（同一）, cost=$0.80（1/3強）, steps=8（1/3弱）
親の予備枠: deadline=50秒, cost=$0.60, steps=6（集約処理に使用）

並列実行ではdeadlineは全子共通ですが、costは合算されるため各子に1/3を渡します。予備枠を残すことで、子の結果を集約・フォーマットする時間とコストを確保します。

実践的なアドバイス¶

ステップ数だけでなくコスト上限を必ず設定してください。max_steps=20でも、各ステップで高性能モデルに大量のコンテキストを送れば1リクエスト$20になりえます。コスト上限はステップ数上限では防げない請求事故を防ぐ最後の砦です。
deadlineは絶対時刻で伝播してください。「あと60秒」のような相対秒を渡すと、伝播のたびに処理時間分のズレが蓄積します。代わりに「2026-05-29T12:01:00Z」のような絶対時刻をdeadlineとして渡し、各ノードが now() と比較して残り時間を計算します。gRPCの grpc-timeout ヘッダと同じ設計原則です。
予算消費率をリアルタイムで監視してください。消費済み/上限の比率をG1 二層観測でメトリクスとして記録し、概ね80%に達した時点でアラートを出します。これにより、上限到達前に縮退戦略に移行する猶予が生まれます。
並列サブタスクの予算管理に注意してください。並列実行ではコストは各子の合算ですが、deadlineは最も遅い子で決まります。3つの子タスクを並列実行する場合、各子にコスト上限の1/3を渡しつつ、deadlineは同一の値を渡します。
予算上限は運用を通じて調整してください。初期値は保守的（低め）に設定し、実際のタスク完了率と枯渇率を見ながら徐々に広げます。最初から潤沢な予算を設定すると、暴走時のダメージが大きくなります。