技術要約：サイレントなツール失敗に対するアウトカム・モニター（Outcome Monitors）

問題定義

外部ツール呼び出しを統合する言語エージェントは、**サイレントな失敗（silent failures）**という重大な脆弱性に直面している。タイムアウトのような明示的なエラーは容易に検出できるが、エージェントが期待される形式ではあるものの、意味的に不正確、古い、あるいは物理的に不可能なデータ（例：キャッシュされたエラーページや負の価格）を受け取ることがある。このような場合、エージェントはその誤ったデータを事実として消費してしまい、「自信に満ちた捏造（confident fabrication）」とタスク失敗を招く。

現在のエージェントのループは、生の観測結果から不整合を推論することを言語モデル（LLM）に依存しているが、このプロセスはしばしば失敗する。一方で、修復を強制する厳格なランタイム・ガードは、改善された挙動が推論によるものか、あるいはガードによる介入によるものかを不明瞭にする。エージェントのアクション空間を制限したり、リカバリー自体を行ったりすることなく、違反を検出するメカニズムが必要とされている。

メソドロジー

著者らは、**検出（detection）とリカバリー（recovery）を分離する決定論的なシステムであるアウトカム・モニター（Outcome Monitors）**を導入する。

コア・コンポーネント

1. アウトカム・コントラクト（Outcome Contracts）: ツール呼び出しとその結果の間の期待される関係性を定義する不変量。これらは以下の2つのソースから導出される：
   • マイニングされたコントラクト（Mined Contracts）: 保守的な受容アルゴリズム（例：正値性、カテゴリドメイン、アフィン保存関係のチェック）を用いて、定常的（クリーン）なタスク分離トレースから抽出されたもの。
   • 公開スキーマ（Public Schemas）: 公開APIレスポンススキーマから派生したもの（AppWorldで使用）。
2. デテクター（The Detector）: ツール結果 $(y_t)$ を関連するコントラクトに対して評価するランタイム・チェッカー。違反が見つかった場合、一連の違反レコード $V_t$ を生成する。
3. アドバイザリー・レシート（The Advisory Receipt）: 違反が発生した際、システムはエージェントのコンテキストに非拘束的なレシートを付加する。このレシートには以下が含まれる：
   • 診断的証拠（diagnostic witness）（例：「$\ge 0$ を期待したが、$-3$ が観測された」）。
   • **リカバリー・アフォーダンス（recovery affordances）**のリスト（エージェントが利用可能な公開リカバリーツール、すなわち代替パスや代用手段）。
   • 極めて重要な点として、レシートはアクションを制限せず、修復を実行せず、ベンチマークのラベルを明かし、あるいは評価者に照会することもしない。エージェントはレシートを無視するか、あるいは任意の行動を選択する自由を保持する。

システム・アーキテクチャ

インターフェースは「検出と助言（Detect and Advise）」パターンに従う（図1）。

• 入力: ツール呼び出し $a_t$、結果 $y_t$。
• プロセス: チェッカー $C$ が $(a_t, y_t)$ を違反 $V_t$ にマッピングする。$V_t$ が空でない場合、エンコーダー $E_s$ が $V_t$ とリカバリーツール $R_t$（タスクの解法ではなく、公開ツール・マッピングから派生）を含むレシート $\rho_t$ を生成する。
• 出力: エージェントは、元の結果 $y_t$ に $\rho_t$ が付加されたものを受け取る。アクション集合 $A_t$ は変更されない。

主な貢献

1. 新しいインターフェース設計: 本論文は、特定の修復を強制したり実行をブロックしたりするのではなく、リカバリー・アフォーダンスを含むアドバイザリー・レシートを通じて違反を通知するインターフェースを提案する。これにより、エージェントの主体性を維持しつつ、構造化されたガイダンスを提供する。
2. 非オラクル構成（Non-Oracle Construction）: コントラクトは、タスクの解法や隠されたリカバリーパスに依存しない、分離されたクリーンなトレースまたは公開スキーマからマイニングされる。これにより、構築時および実行時の整合性を確保している。
3. 実証的検証: 本研究は、凍結されたタスク分離ワークフローを用いて、3つのプロバイダー・ファミリー（DeepSeek, Qwen, MiniMax）および2つの環境（ToolMaze, $\tau$-bench）にわたってアプローチを評価している。

結果

研究では、アウトカム・モニターが有効な場合に、特に故障がベースラインの完了を阻害するシナリオにおいて、タスク完了率が大幅に向上することが報告されている。

• ToolMazeでの確認: 4つのモデル（DeepSeek V4 Flash/Pro, Qwen 3.7 Plus/Max）において、完了率は10.9%（ベースライン）から28.1%（アドバイザリー）へと増加し、+17.2パーセントポイントの向上（$p < .00001$）を記録した。MiniMax M3を用いた別の再現実験でも、同様の向上（+18.75ポイント）が見られた。
• $\tau$-bench Retail: ステートフルな小売環境において、完了率はDeepSeek V4 Flashで**+14.0ポイント**、DeepSeek V4 Proで**+12.0ポイント**向上した。向上はカテゴリの状態違反（+28.0ポイント）に集中しており、アフィン保存違反においてベースラインの完了率が既に高かった場合には有意な効果は見られなかった。
• 作用メカニズム: アブレーション研究により、リカバリーツールのリストこそが向上を駆動する能動的なコンポーネントであることが明らかになった。ツールリストを削除すると改善が見られなくなり、ツールリストなしで一般的な警告や診断詳細のみを追加しても、測定可能な利益は得られなかった。
• レビュアーとの比較: アウトカム・モニターは、メカニズムに忠実な「強化エージェント（Reinforced Agent）」（別のLLMレビュアーを使用）の移植版と比較して、完了率およびコストの両面で優れていた（レビュアーの使用によるコスト増は約498%であるのに対し、本手法は約7%のコスト増にとどまる）。
• 検出の限界:
  • 語彙の境界: コントラクトの語彙を知らない状態で作成されたインシデント由来の故障に対してテストしたところ、特に妥当な文字列内の破損については、検出率が**46%**に低下した。
  • クリーンなトラフィック: クリーン（摂動なし）のワークフローにおいて、システムはトラフィックの約1.4%で偽陽性のレシートを発行したが、ネットでの効果はゼロであった（救済による利得と、弊害による損失が相殺された）。
  • 高ベースラインのシナリオ: 故障があってもベースラインがほとんどのタスクを完了できる環境（例：AppWorldのホールドアウトテスト）では、純増分は微々たるものであった。

意義と主張

本論文は、アウトカム・モニターがサイレントな失敗のリカバリーを**観測可能性の問題（observability problem）**として捉えることを主張している。結果は、実行可能なリカバリーアクションは、明示的なシグナリングがなければモデルにとって「判読不能」であるものの、エージェントのツール・レパートリー内に既に存在していることが多いことを示唆している。

• 控えめな主張: 著者らは、本システムは非拘束的であることを強調している。これは安全性を保証したり、あらゆる危害を防いだりするものではない（ペア損失が観察されている）。また、利得は故障が完了を能動的に阻害する箇所に集中しており、あらゆる文脈で普遍的に有益であるわけではない。
• オープンな課題: 本論文は、検出をマイニングされたコントラクトの語彙以上に拡張することは、依然として未解決の課題であると明記している。現在のシステムは、注入された故障とマイニングされた不変量との間の整合性に依存しており、自然発生した予期せぬ失敗からのリカバリーはまだ解決されていない。
• 設計思想: 検出とリカバリーを分離することで、本アプローチは、言語エージェントが硬直的なランタイム・ガードに頼ることなく、自らの推論能力を活用して最適なリカバリーパスを選択することを可能にする。

要約すると、アウトカム・モニターは、コントラクト違反と利用可能なリカバリーツールを提示することにより、エージェントの自律性を損なうことなく、サイレントなツール失敗に対するエージェントの堅牢性を向上させる、トレーニング不要で決定論的なメカニズムを提供する。