技術概要：構造的カバレッジ基準を用いたエージェントワークフローのテスト

問題定義

マルチエージェントシステムは、エージェント、ツール、アクセス規則、委任パスが明示的に定義された構造化されたワークフローとして、ますます展開されるようになっている。しかし、現在の評価慣行は、エンドツーエンドのタスク成功、ベンチマークスコア、最終応答の品質に大きく依存している。これらの指標は、宣言された調整構造が実際に行使されたかどうかについて、限られた証拠しか提供しない。ワークフローは特定のツールが呼び出されない、制限されたアクセス規則がテストされない、または委任パスが探索されないまま、タスクを正常に完了する可能性がある。その結果、テストスイートの適切性を評価したり、ツールアクセスやエージェント間委任における構造的な回帰を検出したりすることが困難である。本論文は、特にワークフローが変化し、小さな定義変更が即座のタスク失敗を引き起こさずに構造的義務を変更する可能性がある場合、エンドツーエンドの成功はマルチエージェントシステムにおける構造的カバレッジの信頼性の低い代理指標であると主張している。

手法

著者らは、マルチエージェントワークフローの仕様を主要なテスト対象アーティファクトとして扱う構造的テスト手法を提案している。この手法は、以下の 5 段階のパイプラインに従う。

1. 仕様の抽出: ソースコード（具体的には OpenAI Agents SDK 風のワークフロー）から、正規化されたマルチエージェントワークフロー仕様（$S$）が抽出される。この仕様は、到達可能なエージェント、許可されたツールエッジ、制限されたツールエッジ、および委任エッジを定義する。
2. グラフ構築: 仕様は、typed 協調グラフ $G(S)$ に変換される。ここで、ノードはエージェントとツールを表し、エッジは許可されたアクセス、制限されたアクセス、および委任関係を表す。
3. 義務の導出: 構造的義務がグラフから導出され、4 つのセットに分類される。
   • 到達可能なエージェント（$A_{reach}$）
   • 許可されたツールエッジ（$T_{allow}$）
   • 制限されたツールエッジ（$T_{restrict}$）
   • 委任エッジ（$D$）
4. カバレッジ駆動型生成: システムは、義務セットから「typed 証人目標（typed witness objectives）」を合成する。これらの目標は、言語モデルパイプラインのための宣言的フレームワークであるDSPyを用いて、自然言語のテストシナリオとして実現される。重要なのは、DSPy はカバレッジの定義には使用されず、シナリオの実現にのみ使用される点である。生成器は、ランタイムアダプタに対して候補プロンプトを実行する、$N=5$ 回までのバウンドされた改良ループを採用する。このループは、実行が目標が要求する特定の構造的証拠（例えば、特定のツール呼び出しまたは委任のハンドオフ）を生成するまで終了しない。
5. ランタイム観測と測定: テストは、構造的トレースを記録するランタイムアダプタを介して実行される。カバレッジは、観測されたトレースが各義務の証人述語を満たすかどうかを確認することで測定される。

カバレッジ基準

本論文は、4 つの構造的カバレッジ基準を定義している。

• C1（エージェントカバレッジ）: 到達可能なすべてのエージェントが観測される。
• C2（許可されたツールカバレッジ）: 許可されたすべてのエージェント - ツールエッジが行使される。
• C3（制限されたツールカバレッジ）: 制限されたすべてのエージェント - ツールエッジが、呼び出しの欠如ではなく、明示的な制限アクセス観測（例えば、拒否または却下イベント）を通じて行使される。これは敵対的テストとして扱われる。
• C4（委任カバレッジ）: 到達可能なすべての委任エッジが観測される。

主要な貢献

本論文は、4 つの主要な貢献を行っている。

1. 定式化: エージェントフレームワークのソースコードから導出された typed 協調グラフにおける構造的充足性問題として、マルチエージェントワークフローのテストを定式化する。
2. カバレッジモデル: 到達可能なエージェント、許可されたツールエッジ、制限されたツールエッジ、および委任エッジに対するグラフ派生のカバレッジ基準を定義する。特に、制限されたツールのカバレッジを、明示的な否定的観測義務として扱う。
3. 生成パイプライン: ワークフローマニフェストを typed 証人目標に変換し、DSPy ベースのランタイム接地型実現を用いて自然言語のテストシナリオを生成する、カバレッジ駆動型のテスト生成パイプラインを提示する。
4. 実証的評価: 49 の到達可能なエージェント、47 のツール、および 403 の構造的義務（oai_customer_service ワークフローの詳細な分析を含む）を合計する、OpenAI Agents SDK 派生の 10 のワークフローに対してアプローチを評価する。

実験結果

評価は、実行者とテスト対象エージェントの両方に gpt-4.1-mini を使用した固定構成で、10 のベンチマークに対して行われた。

• 抽出（RQ1）: パイプラインは、すべての 10 のワークフローに対して、手動介入なしで形式正しい協調グラフを正常に抽出し、構造的義務を導出した。
• 許可されたツールおよび委任の証人（RQ2）:
  • 生成されたシナリオは、許可されたツールの義務の54/75（72%）を証人した（ベンチマーク全体で集計。論文は表 II で 45/65 と記載しているが、アブストラクトでは 54/75 と述べている。本文の結果セクションでは 45/65 と明確化されている）。
  • 生成されたシナリオは、委任の義務の36/48（75%）を証人した（集計値。表 II では 31/41）。
  • 単一ホップのターゲットは均一に通過した。見逃しは、主にマルチホップワークフロー、または意味的重なりがコーディネータを異なるスペシャリストへルーティングさせた場合に発生した。
• 制限されたツールの敵対的証人（RQ3）:
  • 敵対的プロービングは、23/248（9.3%）の制限付き呼び出し違反を誘発した。
  • 4 つのベンチマークは標的とした違反を生成しなかったが、6 つは具体的な誤ルーティングの失敗を生成した。これは、堅牢な制限を持つワークフローと、悪用可能な境界を持つワークフローを区別するこの基準の能力を示している。
• フォルト注入（RQ4）: oai_customer_service ベンチマークにおいて、構造的ハーネスは注入されたツールフォルト（エラーおよび不正なペイロード）下での堅牢性を正常にテストし、エージェントがツールを試行し、クラッシュしたり生のエラーペイロードを漏洩したりしなかったことを確認したが、意味的正確性は検証しなかった。

意義と主張

本論文は、構造的カバレッジがマルチエージェントワークフローのテストにとって有用な充足性レイヤーを提供すると主張している。これは、意味的評価やエンドツーエンドのベンチマークを置き換えるものではないが、宣言されたエージェント、ツールアクセス規則、制限、および委任パスが実際に行使されたことを示す明示的な証拠を提供する。

• 診断的価値: このアプローチは、「未テストの構造」を明らかにする。見逃された義務は、行使が困難な特定の調整パスを特定し、開発者がルーティングプロンプトやワークフローの強化を改善するよう導く。
• 否定的義務: 制限されたツールエッジを明示的にテストすることで、この手法は、許可リストのみの評価では見えない脆弱性（制限を回避する具体的なプロンプト）を暴露する。
• 限界: 著者らは主張について控えめであり、結果は統計的に裏付けられた推定値ではなく、単一実行の実証的証拠であると指摘している。高い構造的カバレッジが意味的正確性、ユーザー満足度、または事実の正確性を保証するわけではないことを認めている。この手法は現在、OpenAI Agents SDK 風のワークフローに特化しており、バウンドされた改良ループは、試行予算内で複雑なマルチホップ義務を証人できない場合がある。

本論文は、構造的テストが「タスクは成功したか？」から「宣言されたワークフローのどの部分が実際にテストされたか？」へと焦点を移すことで、既存のエージェント評価を補完すると結論付けている。