Bench2Robustが9種類のツール障害を注入、70組中69組のエージェントテストで性能が低下

ツールエージェントがベンチマークで利用するAPIは、通常、常に成功し、正しい形式で最新のデータを返す。しかし実際のサービスでは、タイムアウトやレート制限、schemaの変更が発生し、一見正常に見える古いデータや誤ったデータが返されることさえある。Amazonのチームが提案した[Bench2Robust](https://arxiv.org/abs/2608.11977)は、エージェントとツールの間に障害レイヤーを挿入し、各episodeの解決可能性を3種類に明確に分類する。S1では元の経路が維持され、再試行によって復旧できる。S2では主要経路が継続的に遮断されるため、同等のツールへ切り替える必要がある。S3では実行可能なすべての経路が遮断され、停止してエスカレーションすることが理想的な挙動となる。

このフレームワークは60%の確率で正常な結果を返し、残りの確率を9種類の障害に割り当てる。障害には、タイムアウト、レート制限、検証失敗、不正形式のレスポンス、schema driftのほか、明確なエラーシグナルを伴わない不完全なデータ、古い値、事実誤認が含まれる。研究チームはこれを[τ²-bench](https://github.com/sierra-research/tau2-bench)とBerkeley Function-Calling Leaderboardのマルチターンタスクに接続した。7モデル、4つのモデルファミリー、10のタスクスライスによる計70組の比較のうち、障害注入後に69組で性能が低下し、最大低下幅は46.7ポイントに達した。Qwen3-235Bでさえ、τ²-retailでは15.8ポイント低下した。

チームはさらに、Qwen3-4B-Thinking-2507向けにBayesian Tool Memory（BTM）を提供した。これは、代替ツールの対応関係、検証上の制約、rolloutから推定したBeta事後分布に基づく復旧率を推論コンテキストへ書き込む仕組みだ。留保された402件の小売タスクでは、再訓練していないモデルにBTMを追加すると、代替ツールなしの設定で合格率が20.1%から36.9%へ上昇した。さらにDAPO強化学習と組み合わせると、2種類の障害設定でそれぞれ40.8%と45.5%に達した。ただし、アブレーション分析によると、主な効果は事後分布の数値そのものではなく、人手で構成した代替経路グラフとルールから得られていた。

エンジニアリング上の示唆は、エージェントruntimeでは、代替可能なツール、再試行可能なエラー、不可逆な操作の前に必要な検証要件を明示的に記述すべきであり、汎用的な「エラー時は再試行」というpromptだけに頼るべきではないということだ。一方で注意も必要だ。論文はBench2Robustの実装を公開しておらず、S3の解決不能タスクには正の評価も与えていない。そのため、結果が裏付けるのは再試行と切り替えによる改善までであり、モデルが確実な棄権を学習したことまでは証明できない。