Skip to content

Budget Guard(実行予算ガード)

自律ループに最大反復回数・実行時間・トークン消費・ツールコール数の上限を設け、上限到達時に決定論的に実行を打ち切る。ループの暴走をモデルの賢さではなく、ミドルウェア層の構造で遮断する。

別名

呼称出典
Stopping Conditions(停止条件)Anthropic「Building Effective Agents」
Iteration Limit / Max Turns / Recursion LimitOpenAI Agents SDK、LangGraph 等の各種SDK
Circuit Breakerエージェント文脈での慣用。Azure は依存先障害への古典的な意味でも使用

問題

自律ループ型のエージェントは、エラーに直面すると同一の誤ったツール呼出を延々と繰り返すことがある。認証エラーのAPIを100回叩き続ける、存在しないファイルを探し続ける、評価に通らない出力を無限に書き直す——いずれも1回ごとにトークンを消費し、対処しなければ数分で数万円規模のコストになりうる。

問題の本質は、ループの継続判断を非決定論的なモデル自身に委ねていることにある。「もう諦めるべきだ」という判断は、まさにモデルが誤っているときには期待できない。

コンテキスト

適用する:

  • ReAct、Evaluator-Optimizer、Orchestrator-Workers など、反復・再帰を含むすべてのパターン
  • 従量課金のLLM APIを使う本番システム全般
  • 実行時間にSLAがあるシステム

適用しない(不要な)ケース:

  • 反復のないワークフロー(Prompt Chaining の1パス実行等)。ただしツール呼出のリトライ上限は別途必要
  • 上限そのものが定義できない探索的タスク——この場合も「人間にエスカレーションするまでの予算」として設定する

解決

ループ本体の外側に、決定論的なガード層を置く。ガードは毎反復の開始前に予算を検査し、いずれかの上限に達していたら実行を打ち切って、途中結果とともに上限到達を報告する。

python
budget = Budget(
    max_iterations=20,
    max_seconds=300,
    max_tokens=200_000,
    max_tool_calls=50,
)

def run_agent(task):
    state = init_state(task)
    while not state.done:
        if exceeded := budget.check(state):   # ループ外側の決定論的検査
            checkpoint.save(state)            # 途中状態を保全(Checkpoint & Resume)
            return escalate(state, reason=exceeded)
        action = llm(state.context)           # 推論はモデル、継続判断はガード
        state = apply(action, tools)
    return state.result

実装の要点:

  • ガードはループの外側に置く。 プロンプトで「20回以内にやめて」と指示するのは Budget Guard ではない。モデルが守らなくても止まる構造にする
  • 複数の軸で制限する。 反復回数だけでは、1反復が巨大なコンテキストを持つ場合の暴騰を防げない。トークン・時間・ツールコールを併用する
  • 打ち切りは失敗報告として扱う。 途中結果を成果物のように返すと、下流が壊れた出力を信頼してしまう。上限到達の理由と途中状態を明示して返す

トレードオフ

  • ✅ コストと実行時間に保証された上限が付き、暴走が事故ではなく想定内のイベントになる
  • ✅ 「異常に予算を消費するタスク」がメトリクスとして観測可能になり、プロンプトやツールの改善対象を特定できる
  • ⚠️ 正当に時間のかかるタスクも一律に遮断しうる。上限値はタスク種別ごとの計測に基づいて調整が必要
  • ⚠️ 打ち切り後の扱い(再開・エスカレーション・破棄)を設計しなければ、単に「途中で止まるシステム」になる

クラウドパターンとの対応

クラウドパターン本パターンでの再定義
Circuit Breaker「依存先の障害を検知して呼出を遮断する」から「自律ループのセマンティックな失敗の繰り返しを、予算消費として検知して遮断する」へ。遮断の判断材料が疎通の成否から資源消費量に変わった
Throttling / Rate Limiting「リクエスト流量の制限」から「1タスク内の推論資源(トークン・反復)の制限」へ。制限の単位がリクエスト数からセマンティックな作業量に変わった

関連パターン

  • Checkpoint & Resume — 打ち切り時に途中状態を保全し、上限を引き上げての再開や人間による継続を可能にする。Budget Guard とほぼ常に併用する
  • ReAct / Orchestrator-Workers — 本パターンの主な適用対象。自律ループを含むパターンには必ず併用する
  • Approval Gate — 予算の上限が「量」の制御であるのに対し、承認ゲートは「不可逆性」の制御。両者は補完関係にある

出典・参考

本文: CC BY 4.0 / コード片: MIT。GitHub で寄稿を受け付けています。