AIエージェントはどう安全に再試行すべきか

導入

ツールを利用するAIエージェントにとって、「失敗したらもう一度実行する」は単純な処理ではない。ローカル側が応答を保存できていなくても、外部サービスにはすでに要求が届いている可能性がある。さらに復旧時点では、最初の実行時に持っていた権限が変わっていることもある。こうした状態を区別せずに再試行すれば、処理の二重実行や新しい権限境界の逸脱につながる。

arXiv論文「Permission to Retry」は、言語モデルの出力能力とは切り分けて、エージェントの実行時信頼性を調べた。焦点は、モデルが正しいツール呼び出しを書けるかではない。中断や不確実な結果の後に、システムが継続、拒否、未解決状態の保持を適切に選べるかである。

主なポイント

• 四つの義務を分離する。 チェックポイントはアプリケーションが何を保存したかを示す。現在の実行権限は、今その呼び出しを許可できるかを示す。外部効果の証拠は、提供者がすでに処理したかを示す。効果が確認されても、後続の精算や完了処理まで許可されたとは限らない。
• 複数の実行条件を横断した。 事前に固定した336件の履歴を、ネイティブなLangGraphとTemporalのホスト、14種類のスケジュール、3種類の提供者契約、4種類の対応するアプリケーション方針で実行した。168のホスト比較セルでは、確認済みの結果が一致した。
• 台帳を残して照合する方式が最も完全だった。 復旧するアプリケーションには提供者の実際の効果台帳を見せず、台帳と照合して結果を評価した。各ホストの42件すべてに合格し、内訳は確認済み完了21件、拒否15件、予約を保持したままの未知結果6件だった。
• 単純な方式には不足があった。 キャッシュ再試行は30件、再試行前の権限再検証は36件、安定キーを使う再試行は31件に合格した。権限の再確認は重要だが、外部で何が起きたかを保持する仕組みの代わりにはならない。
• コンポーネント単位の確認も行った。 InfinityOSの権限、ワーカー、復旧、精算コードをリポジトリ上のフェイクで動かす16ケースの調査も実施した。これは本番環境全体の性能比較ではなく、主要部品の挙動を確認する補足的な検証である。

意義と影響

この研究は、エージェント基盤の責務を整理する。権限は「今、試行してよいか」を決め、効果の証拠は「すでに外部で実行されたか」を示し、精算権限は「その結果を後続処理として確定してよいか」を決める。これらを一つの真偽値にまとめると、復旧で最も重要な曖昧さを失ってしまう。

実装では、検証可能な観測結果を保持し、安定した冪等キーを使い、復旧時に権限を再評価することが有効だろう。また評価では成功率だけでなく、安全性、完了状況、未解決の義務を分けて報告すべきである。今回の実験は有限の適合性調査であり、InfinityOSの検証にはリポジトリ上のフェイクが使われているため、全エージェント基盤に通用する順位付けではなく、設計上の指針として読むのが適切だ。

メッセージ送信、データ変更、取引、業務フローの起動をエージェントが担うほど、重要なのは積極的に再試行することではない。証拠が足りないときに停止し、未解決の義務を明確に残せることだ。

arXiv