はじめに
Microsoft Researchが2026年3月12日、AIエージェントの実行ログから障害の根本原因を自動特定するフレームワーク「AgentRx」をオープンソースで公開しました。本稿では、その仕組みと評価結果、9種類の失敗分類体系について解説します。
参考記事
- タイトル: Systematic debugging for AI agents: Introducing the AgentRx framework
- 著者: Shraddha Barke、Arnav Goyal、Alind Khare、Chetan Bansal
- 発行元: Microsoft Research
- 発行日: 2026年3月12日
- URL: https://www.microsoft.com/en-us/research/blog/systematic-debugging-for-ai-agents-introducing-the-agentrx-framework/
要点
- AgentRxは、AIエージェントの実行軌跡（トラジェクトリ）から「最初の回復不能な失敗ステップ」を自動特定するオープンソースフレームワークである
- τ-bench、Flash、Magentic-Oneの3領域にわたる115件の手動アノテーション済み失敗トラジェクトリを含むベンチマークデータセットが同時公開された
- 既存のLLMプロンプティングベースラインと比較して、失敗箇所の特定精度が23.6ポイント、根本原因の帰属精度が22.9ポイント向上した
- AIエージェントの失敗を9カテゴリに分類した体系（タクソノミー）が構築され、エラーの種類を体系的に把握できる
詳細解説
なぜAIエージェントのデバッグは難しいのか
AIエージェントが単純なチャットボットから自律的なシステムへと進化するなかで、新たな課題として「失敗の透明性」が浮上しています。クラウド障害への対応、複雑なWebインターフェースの操作、多段階のAPIワークフロー実行など、エージェントが担う業務の幅は広がり続けています。
Microsoft Researchによれば、AIエージェントのデバッグが困難な理由は主に3点あります。第一に、エージェントは長い時間軸で数十ものアクションを実行する「長期タスク」を処理するため、失敗箇所が深く埋もれがちです。第二に、確率的な性質を持つため、同じ入力でも異なる出力が生じ、エラーの再現が難しくなります。第三に、マルチエージェント構成では、あるエージェントの失敗が別のエージェントに引き継がれ、真の根本原因が隠蔽されます。
「タスクが完了したか否か」という従来の成功指標だけでは、これらの問題に対処するには不十分と考えられます。安全なエージェントを構築するには、軌跡が「回復不能」になった瞬間を特定し、その時点での証拠を記録する仕組みが求められます。
AgentRxの仕組み：4段階パイプライン
AgentRxは、エージェントの実行ログをシステムトレースとして扱い、体系的に検証します。単一のLLMに「エラーを推測させる」方式ではなく、4つのステージからなる構造化パイプラインを採用しているのが特徴です。
第1段階は「トラジェクトリの正規化」です。異なる領域やシステムから出力される多様な形式のログを、共通の中間表現に変換します。
第2段階は「制約の合成」で、ツールのスキーマ（例：「APIは有効なJSONを返す必要がある」）やドメインポリシー（例：「ユーザー確認なしにデータを削除しない」）に基づいて実行可能な制約を自動生成します。
第3段階の「ガード付き評価」では、各制約をその適用条件（ガード条件）が成立するステップでのみ検証し、違反の証拠をステップごとに記録した監査可能なログを生成します。
第4段階では、LLMがこの検証ログと失敗分類体系を参照しながら、「最初の回復不能なエラーが発生したステップ（クリティカル・フェイラー・ステップ）」と根本原因カテゴリを特定します。
この構造により、開発者は試行錯誤的なプロンプト調整から脱却し、証拠に基づいた体系的なデバッグが可能になると考えられます。エラーが発生したステップとその理由が監査ログとして残るため、再発防止策の検討にも役立てられます。
ベンチマークと9カテゴリの失敗分類体系
AgentRxの評価には、3つの複雑なドメインにわたる115件の手動アノテーション済み失敗トラジェクトリで構成されるベンチマークが用いられました。τ-benchは小売・サービスタスクの構造的APIワークフロー、Flashはシステム障害対応のような実世界のインシデント管理、Magentic-OneはマルチエージェントシステムによるオープンエンドなWebおよびファイル操作をそれぞれカバーしています。
これらのデータに対してグラウンデッド・セオリーアプローチ（データから帰納的に理論を構築する手法）を適用することで、ドメインを横断して汎用的に使える9カテゴリの失敗分類体系が導出されました。主なカテゴリには、必要なステップを飛ばすか不要なアクションを追加する「計画遵守の失敗（Plan Adherence Failure）」、ツール出力に基づかない事実を作り出す「新情報の捏造（Invention of New Information）」、ツール呼び出しの形式が不正な「無効な呼び出し（Invalid Invocation）」のほか、ツール出力の誤読、ユーザー意図の誤解、情報不足による続行不能、対応ツールの欠如、安全制限による実行ブロック、システム障害などが含まれます。
このような体系的な分類は、エラーの種類を特定し対策を講じる際の共通言語として機能すると思います。開発チーム内での障害分析や改善の優先度付けにも活用できると考えられます。
評価結果とオープンソース公開
Microsoft Researchの発表によれば、既存のLLMプロンプティングベースラインと比較して、失敗箇所の特定精度（ローカライゼーション精度）が23.6ポイント向上し、根本原因の帰属精度が22.9ポイント向上しました。失敗の「理由」を監査可能なログとして提示することが、精度向上の鍵になっていると言えます。
なお、Magentic-Oneのような複数エージェントが連携するシステムでは、1つのトラジェクトリに複数のエラーが含まれることもあります。AgentRxはその中から最初のクリティカルな問題に焦点を絞る設計となっており、マルチエージェント環境での実用性も考慮されています。
フレームワーク本体とベンチマークデータセットはオープンソースで公開されており、論文・コード・データすべてに無償でアクセスできます。研究者や開発者が自身のエージェントワークフローに適用したり、失敗制約のライブラリに貢献したりすることも想定されています。
まとめ
Microsoft ResearchのAgentRxは、AIエージェントの実行ログから失敗箇所と根本原因を自動特定するフレームワークです。4段階パイプラインと9カテゴリの分類体系を組み合わせ、従来手法に比べて大幅な精度向上を達成しました。エージェントの本格的な実用展開に向けて、信頼性・監査可能性を高める取り組みとして注目されます。
