【ITニュース解説】The Agent Loop Is a Runtime: Budgets, Cancellation, and Idempotency

AIエージェントは、まるで人間のように一連の思考や行動を繰り返し、特定の目標を達成しようと試みるソフトウェアである。しかし、このようなエージェントを本番環境で実際に運用する際、デモンストレーション段階では見えなかった多くの問題に直面することがある。例えば、エージェントが意図せず長時間動き続けたり、返金処理を二重に行ったり、キャンセルボタンを押しても裏側の処理が止まらなかったりといった具合だ。これらの問題は、AIモデルの賢さそのものというよりも、エージェントが動作する環境（エージェントループ）の管理が不十分であることに起因することが多い。

この記事では、この「エージェントループ」を、まるでオペレーティングシステムや仮想マシン（VM）のような、独立した「ランタイム」として捉えるべきだと主張している。AIモデル自体は、このランタイムの中で動く一つの部品に過ぎず、ランタイム全体ではない。ランタイムとして管理するということは、タスクの受け入れ制限（受付制御）、処理時間の上限（デッドライン）、実行中の処理を適切に停止させる仕組み（協調的なキャンセル）、そして外部システムへの影響が意図せず複数回発生しないようにする（多くて一度の副作用）といった、システム運用上の基本的な懸念事項を考慮に入れることを意味する。

エージェントの安定した実行を保証するためには、適切な「予算」設定が不可欠である。単一の予算では不十分で、少なくとも四つの独立した制限を設けるべきだと提言されている。一つ目は「ステップ数」で、エージェントループが何回繰り返せるかの上限を設ける。これは、無限ループのような明らかな問題を早期に検出するためのシンプルなガードレールとなる。二つ目は「経過時間（ウォールクロック）」で、エージェントの実行開始から終了までにかかる総時間の上限を設定する。ユーザーは個々のステップの速度よりも、タスク全体の完了までの時間を気にするため、この制限が特に重要となる。三つ目は「ツール呼び出し回数」で、エージェントが外部ツール（データベースへの問い合わせやAPI呼び出しなど）を何回利用できるかを制限する。一つのステップ内で複数のツール呼び出しが行われる可能性を考慮すると、ステップ数とは別に設定するのが望ましい。

そして最も重要な四つ目は「費用またはトークン数」である。これは暴走したエージェントを実際に止めるための最終的な制限となる。AIモデルへの入力として、過去の会話履歴やツールからの出力も送信されるため、ステップが進むにつれて入力トークン数が増加し、一回のステップにかかる費用も線形に、あるいはそれ以上に増加する。このため、累積のトークン数や費用に対して上限を設けることで、予期せぬ高額請求を防ぐことができる。これらの予算は、実行されるタスクの種類によって最適な値が異なるため、実際にシステムを監視し、成功した実行の99パーセンタイル値を目安に設定することが推奨される。厳格な上限は、成功する可能性があった遅い処理を、素早い失敗に変えるというトレードオフを伴う。対話型リクエストでは素早い失敗が望ましいが、バッチ処理では多少時間がかかっても完了することが重要となるため、この設定は固定値ではなくパラメータとして柔軟に調整できるようにすべきだ。

次に重要な課題は「キャンセル」の仕組みである。単にエージェントループ自体を止めるだけでは不十分で、ループの中から呼び出された外部ツール（例えば、データベースへのクエリやHTTPリクエストなど）の実行も停止させる必要がある。もしツールがタイムアウト設定なしで実行されたり、キャンセルを受け付けない作りになっていたりすると、UI上でキャンセルボタンが押されても、裏側では処理が続き、意図しない副作用や費用が発生し続けることになる。この問題を解決するためには二つのアプローチが示されている。一つは、ループに残された「残り時間（デッドライン）」をツールに伝達することである。ツールの呼び出し時に、エージェント全体に残された時間（デッドライン）を渡し、ツールはその残り時間に基づいて自身のタイムアウトを計算する。もう一つは、すべての外部へのブロッキング呼び出し（AIモデルへの問い合わせ、HTTP通信、データベース操作など）に明示的なタイムアウトを設定することである。そして、タイムアウトが発生した場合は、プログラムのクラッシュとしてではなく、エラー情報としてAIモデルにフィードバックするべきだと述べている。キャンセル後には、ツールが中途半端な状態で終了している可能性があり、システムが「不明な状態」にあることを認識することが重要である。外部システムの状態を変化させるような処理を行った場合は、必ずその後の整合性を確認・調整する仕組みを用意する必要がある。

さらに、エージェントシステムにおいて頻繁に問題となるのが「副作用の冪等性」の保証である。エージェントは、エラーやネットワークの問題、応答の途切れなどにより、同じツール呼び出しを繰り返し試行することがよくある。このような再試行によって、返金が二重に行われたり、注文が重複して作成されたりといった問題が発生する可能性がある。これを防ぐためには、「冪等性キー」という仕組みが不可欠である。これはウェブフック処理などで一般的に用いられる手法と同じ考え方だ。冪等性キーは、実行ID、ツール名、そして引数から「決定論的に」生成されるべきである。AIモデルが生成する自由なテキストや、実行時のタイムスタンプ、ランダムなUUIDなどからは生成してはならない。これらの情報を用いると、同じ内容のツール呼び出しでも異なるキーが生成され、冪等性が保証されなくなるためである。この冪等性キーは、副作用を実行するトランザクションと同時に保存され、ツールが実行される前にそのキーが既に存在するかどうかを確認することで、同じ処理が複数回実行されるのを防ぐことができる。もし外部のAPIが冪等性キーをサポートしていない場合は、「アウトボックスパターン」と呼ばれる分散システムで用いられる手法を使い、まずシステム内で意図を記録し、その後で外部APIを呼び出してその結果を記録することで、副作用の重複を防ぎ、整合性を保つことが可能になる。

本番環境で問題が発生した場合、午前2時に担当者が知りたいのは「元々のプロンプトは何だったか」ではなく、「なぜこの処理で二重に返金されたのか」や「なぜこれほどの費用がかかったのか」といった具体的な原因である。そのために、適切な「監視とトレース」の仕組みも不可欠となる。エージェントの各ステップごとに、そのステップのインデックス、利用したAIモデル、入出力トークン数、処理にかかった時間、呼び出したツール名、ツールの引数のハッシュ値、結果のハッシュ値、そして最終的な結果を記録した「スパン」を作成するべきだ。ログ自体には大きなデータ本体を直接含めず、ハッシュ値で参照させることでログの肥大化を防ぎつつ、必要に応じて詳細なデータ（ペイロード）を別のオブジェクトストレージから取得できるようにする。このような詳細なトレースがあれば、例えば重複した副作用が発生した場合でも、同じ引数ハッシュを持つスパンをグループ化することで、迅速に原因を特定できるようになる。

AIエージェントシステムを堅牢に運用するためには、いくつかの一般的な落とし穴を避けるべきである。例えば、アプリケーション層、SDK層、エージェント層といった複数の層でリトライ処理が重複すると、一度の障害で同じ処理が何十回も再試行され、予期せぬ結果を招く可能性があるため、リトライは単一の層で制御すべきだ。個々のステップごとに短いタイムアウトを設定するのではなく、エージェント全体の実行にデッドラインを設定しないと、全体として非常に長い時間かかってしまう可能性がある。広範な例外を捕捉してしまうと、キャンセルやデッドライン超過といった重要なシグナルが無視され、ループが意図せず続行される恐れがある。冪等性キーをタイムスタンプやUUIDから生成すると、同じ内容の呼び出しでもキーが異なり、重複を防止できなくなる。会話履歴を無制限に保持することも、コストの増加と、AIモデルが重要な指示を無視する原因となるため避けるべきだ。そして、UI上でのキャンセルが、裏で動くワーカーの停止に繋がらない場合、意図しない費用が発生し続けることになる。

結論として、AIエージェントシステムを安定して本番運用するためには、以下の原則を確認すべきである。まず、すべてのエージェント実行に、最大ステップ数、経過時間（ウォールクロック）のデッドライン、ツール呼び出し回数、トークンや費用の累積上限を明示的に設定すること。次に、すべてのブロッキング呼び出し（AIモデル、HTTP通信、サブプロセス、データベースなど）には、実行の残り予算から導出されるタイムアウトを設定すること。キャンセル処理はステップ間で確実にチェックされ、実行中のツールにまで伝播されるように設計すること。そして、状態を変化させるすべてのツール呼び出しには、決定論的に生成された冪等性キーを付与し、副作用の重複を防ぐこと。これらの原則に従うことで、AIエージェントシステムはより堅牢で信頼性の高いものとなるだろう。