マルチエージェントシステムはどう評価するか：統合テスト設計の実践

本番移行したマルチエージェントシステムで「個別のエージェントは正常なのに、連携させると謎の障害が起きる」という問題に直面する組織は多い。オーケストレーターからサブエージェントへのタスク分配ミス、エージェント間のデータ形式不整合、上流の品質劣化が下流に波及するカスケード障害——これらはシングルエージェントを個別にテストしていても検出できない。エージェントガバナンスの観点から、マルチエージェントシステムにはコンポーネント単位とシステム全体の統合テストという2層の評価体系が必要だ。

マルチエージェント評価がシングルエージェント評価と異なる点は何か

マルチエージェントシステムでは個別エージェントが正常でも、エージェント間の委譲・データ変換・整合性でシステム全体が障害を起こす。評価は個別テストとシステムテストの2層が必要です。

シングルエージェント評価は「入力→ツール呼び出し→出力」の1スレッドを測定する。マルチエージェントシステム（MAS）では「オーケストレーター→サブエージェントA→サブエージェントB→集約」という連鎖があり、評価の複雑度は組み合わせ的に増加する。

MAESTRO（Multi-Agent Evaluation Suite for Testing, Reliability, and Observability）を用いた12フレームワークの横断研究は、MASが「構造的には安定だが時間的に変動する（structurally stable yet temporally variable）」特性を持つことを示した。同じシステムが同じ出力を返しながら、実行ごとにレイテンシとコストが大きく揺れる現象だ。また同研究は、フレームワーク・アーキテクチャの選択がモデルの選択よりもコスト・レイテンシへの影響が大きいことも明らかにしている。評価設計にはシステム構成レベルの検証が不可欠だ。

エラーの複利的波及も見落とせない。サブエージェントAが20%の確率で誤ったデータを返す場合、3段階パイプラインでの全体成功率は0.8³＝51.2%まで低下する。マルチステップ評価設計がシングルエージェントの軌跡を対象とするのに対し、MAS評価はエージェント境界を越えた連鎖を評価単位とする点が根本的な違いだ。

コンポーネントテストとシステム統合テストをどう使い分けるか

コンポーネントテストは個別エージェントをスタブで切り離して高速検証し、システム統合テストは全エージェント連携でエンドツーエンドの品質を確認します。

コンポーネントテスト（単体テスト相当）

対象エージェントだけを実行し、隣接するエージェントはスタブ（固定応答を返すモック）で代替する。高速で再現性が高く、CI/CDのコミットフックに組み込みやすい。オーケストレーターのタスク分配ロジック、各サブエージェントのツール呼び出し精度を独立して検証できる。

``python # サブエージェントBをスタブに置き換えてオーケストレーターをテスト stub_agent_b = StubAgent(responses={"検索": "固定の検索結果"}) orchestrator = Orchestrator(agents={"search": stub_agent_b, "analyze": real_agent_a}) result = orchestrator.run(task="顧客データを検索して分析せよ") assert result.status == "success"``

システム統合テスト

全エージェントを実際に連携させてエンドツーエンドで評価する。コストは高いが、コンポーネントテストでは見えない境界面の問題——A2A/MCPメッセージのスキーマ不一致、コンテキスト引き継ぎミス、エージェント間のレート制限干渉——を捕捉できる。

k-trial 信頼性評価

同じシステム入力に対してk回実行し、成功率を計測する。k＝5で4回以上成功を合格基準とする「pass^k評価」を採用すると、ランダム性に起因する不安定なエージェントを明示的に検出できる。CI/CDパイプラインへの評価統合と組み合わせ、テストピラミッド（コンポーネントテスト多数・高頻度 → システムテスト少数・低頻度）を設計する。

エージェント間整合性とカスケード障害をどうテストするか

エージェント間整合性テストは複数サブエージェントが矛盾しない回答を返すかを確認し、カスケード障害テストは意図的な障害注入でシステムの耐障害性を検証します。

整合性テスト

複数のサブエージェントが同じ知識ベースや共有コンテキストを参照する場合、それぞれが矛盾しない回答を返すかを確認する。例として在庫確認エージェントと発注エージェントが同じ在庫データから異なる数値を返す場合、個別評価では検出できない整合性欠如がシステムテストで顕在化する。

カスケード障害テスト（障害注入）

特定のサブエージェントを意図的に失敗（異常応答・タイムアウト・不正フォーマット返却）させ、オーケストレーターとシステム全体がどう反応するかを検証する。許容される挙動は「グレースフルデグレード（部分的に機能を維持しつつ失敗を報告）」か「明示的エラーの上流伝播」だ。「障害を隠蔽しながら誤った最終結果を返す」パターンは最悪の結果をもたらす。

手戻りループテスト

オーケストレーターがサブエージェントの出力を検証して再試行を要求するパターンでは、最大再試行回数を評価対象に含める。k回リトライ後に強制終了するか、別のサブエージェントにフォールバックするかを設計段階で決定し、テストで検証する。

マルチエージェント評価インフラをどう設計するか

専用MASフレームワークとOTelトレースへの評価フック追加が、マルチエージェント評価インフラの2つの主要アプローチです。自チームの技術スタックとの整合で選択する。

アプローチ1: 専用MASフレームワーク

MAESTROのような専用フレームワークは、エージェントシステムの実行・トレース収集・評価の統合APIを提供する。複数フレームワーク横断で同一評価基準を適用できる点が強みで、大規模MASのベンチマークや横断比較に向く。

アプローチ2: OTelトレース + 評価フック

既存のOpenTelemetry計装に評価フックを後付けで組み込む方法だ。エージェントの可観測性で解説したスパン構造を拡張し、エージェント境界をまたぐメッセージ受け渡しをA2Aイベントとして記録する。LLM-as-judgeの評価スコアをスパン属性として付与することで、失敗の発生エージェントをトレースレベルで特定できる。

評価の帰属問題（Credit Assignment）

MAS評価で見落とされがちな問題が「どのエージェントの失敗が最終スコアに寄与したか」の帰属だ。オーケストレーター・各サブエージェントのスコアをシステム全体スコアと分離して記録し、障害の根本原因を特定できる設計が必要だ。

規模別の留意点（SMB / エンタープライズ）

SMBの場合: 2〜3エージェントの小規模構成では、コンポーネントテストのみで開始し、システムテストはゴールデンデータセット10〜20ケースの手動確認で代替できる。評価コストが低い段階では、k-trialのkを3〜5に設定して週次で実施する運用が現実的だ。KuuのAIエージェント運用管理サービスでは評価設計の伴走支援を提供している。

エンタープライズの場合: 10〜数十エージェントが複数チームに跨がる場合、評価ハーネスをプラットフォームチームが中央管理する構成が必要だ。チームごとのコンポーネントテストをコミット毎に実行し、全社システムテストをプルリクエスト単位で実行するCI/CDパイプラインを設計する。エージェント間の評価帰属・コスト配賦・マルチテナント分離を含む大規模MAS評価基盤の設計・実装はKuuのRDE（Reinvention Deployed Engineering）サービスで支援している。

参考

まとめ

マルチエージェントシステムの評価設計は、コンポーネントテスト（スタブ活用）→システム統合テスト（全エージェント連携）→本番オンライン評価の3層で構成する。k-trial信頼性評価で確率的な品質を定量化し、障害注入によるカスケード障害テストでシステムの耐障害性を検証する。評価インフラはMAESTROや既存OTelトレースへの評価フック追加で構築でき、帰属問題を解くためにエージェント個別スコアとシステムスコアを分離して記録することが重要だ。

単体エージェントが合格しても、エージェントガバナンスの観点からはシステム全体の品質保証が要件になる。MAS評価基盤の設計・構築についてはKuuのエージェントガバナンス支援にご相談ください。