UndoBench：AIエージェントは完了率だけでなく復旧能力を評価すべき

導入

企業向けソフトウェアを操作するAIエージェントにとって、通常時にワークフローを完了できることは出発点にすぎない。ツール呼び出しがタイムアウトしたり、確認応答が失われたり、変更が実行済みか分からなくなったりしたとき、エージェントがどう動くかが実運用上の重要な問題になる。状態を確認せずに再試行すれば、支払い、レコード作成、権限変更などを重複して実行する可能性がある。

UndoBenchは、この差を測るためのベンチマークだ。最終的な成功・失敗だけで評価するのではなく、通常のタスク遂行能力と、障害から安全に復旧する能力を分離している。

主なポイント

• 反実仮想ペアで障害の影響を切り分ける。 8つの企業領域を対象に、36の基本ワークフローと36の障害シナリオを用意する。同じシードで正常実行と障害注入実行を対にし、ネットワーク上の効果履歴や環境状態のオラクルによって実際の変化を判定する。
• 完了できることは安全な復旧を意味しない。 確認応答の紛失を扱う実験では、12のテストワークフローについて5760回の実行、2880組のペア試験を行った。通常時の能力は83.54%だったが、条件付き復旧成功率は46.72%に低下した。単純な再試行では53.33%の試験で重複した外部効果が生じた。
• 障害が起きる段階で結果が変わる。 状態変更の前は手法間の差が小さく、能力のある実行で重複効果は見られなかった。一方、部分変更中は単純再試行、呼び出し単位の冪等性、権限のないジャーナリングが、評価対象の複合ワークフローで機能しなかった。コミット後かつ確認前の段階では、検証処理とサーバー側の冪等性が安全性を高めた。
• 復旧にはコストがある。 障害を含む実行では、遅延が29.3%、完了トークンが10.5%、ツール呼び出し回数が55.8%増加した。最終的に成功しても、追加コストが大きければ本番運用には適さない。

意義

UndoBenchの意義は、新しい成功率を提示したことだけではない。従来の評価は最終状態が正しいかを確認することが多く、途中で発生した危険な副作用を見落としやすい。決済、チケット処理、在庫、アクセス権、データ登録などでは、目に見える失敗より重複操作の方が深刻になる場合もある。

実運用では、復旧をモデルの判断だけに任せるべきではない。検証可能な状態照会、操作効果の履歴、サーバー側の冪等性キー、権限範囲に合った監査機構が必要になる。評価でも、最終的に完了したかだけでなく、重複が起きたか、復旧にどれだけ時間・トークン・ツール呼び出しが追加されたかを測る必要がある。

出典：Hugging Face Daily Papers