Skip to content

マルチエージェントシステムの評価方法

マルチエージェント LLM システムを評価し、失敗を責任を負うエージェントとハンドオフに帰属させ、相互作用グラフをレビューし、各エージェントとチームを採点するための実践ガイド。

マルチエージェントシステムとは、1 つのタスクに協力して取り組む複数の LLM エージェント（プランナー、コーダー、レビュアーなど）のことです。これを評価するということは、最終的な回答を採点する以上のことを意味します。なぜなら、重要な失敗はエージェントの「間」で起こるからです。ハンドオフでの制約の取りこぼし、誤ったエージェントの引き継ぎ、自分の仕事を一度も検証しないチームなどです。有用な判断の単位は、どのエージェント・どのステップ・どのハンドオフかです。 Potato は、マルチエージェント実行を人手で評価するためのオープンソースツールであり、チーム構造のための専用設計されたアノテーション面の一式を備えています。

ここでいうマルチエージェントシステムとは、それぞれ役割を持つ別個のエージェントがメッセージを交換し制御をハンドオフする、LLM 駆動のワークフローを意味します。これらのシステムがなぜ失敗するのかに関する研究（MAST 分類体系, Why Do Multi-Agent LLM Systems Fail?）は、失敗の大きな割合がエージェント間のもの、つまり仕様の問題、エージェント間の不整合、検証の欠如であることを見出しています。フラットなトランスクリプトは、まさにそうした失敗を隠してしまいます。

なぜ単一エージェントの評価では不十分なのですか？

1 つのエージェントを評価するとき、あなたは思考・ツール呼び出し・観測の単一の系列を判断します。チームは、エージェントの間にしか存在しない失敗モードを追加します。

  • ハンドオフ損失：エージェント A が知っている制約を、エージェント B が一度も受け取らない。
  • 誤帰属：実行は失敗するが、責任を負うエージェントはエラーが表面化した場所よりも上流にいる。
  • 協調の失敗：各エージェントは個別には有能だが、チームはループする、停滞する、あるいは一度も検証しない。
  • リソース競合：2 つのエージェントが同じツールやファイルに同時に触れてデッドロックする。

最終出力だけを採点しても、チームが失敗したことはわかってもどこでかはわかりません。帰属こそが、デバッグや学習にとってデータを有用にするものです。

マルチエージェントの失敗をどう帰属させますか？

失敗帰属の研究文献（Zhang et al., Which Agent Causes Task Failures and When?, ICML 2025）は、ラベルを三つ組として枠付けます。責任を負うエージェント、決定的なステップ、そして理由です。Potato では failure_attribution スキーマがエージェントとステップの選択肢をトレース自体から生成するため、アノテーターは実際に発生したエージェントとステップの中から選びます。

yaml
annotation_schemes:
  - annotation_type: radio
    name: outcome
    description: "Did the system succeed?"
    labels: [success, failure]
  - annotation_type: failure_attribution
    name: attribution
    description: "If it failed: which agent, which step, and why?"
    steps_key: steps
    agent_key: agent

結果スキーマを帰属と組み合わせることで、三つ組は実際に失敗した実行に対してのみ収集されます。

トランスクリプトだけでなくチーム構造をどうレビューしますか？

2 つの面が構造を可視化します。相互作用グラフはエージェントをノードとして、ハンドオフをエッジとしてレンダリングし、アノテーターはクリティカルパスをマークして問題のあるエッジにフラグを立てます。ハンドオフレビューは、すべての制御移転をカードに変えて、不整合にフラグを立て品質を評価します。

yaml
annotation_schemes:
  - annotation_type: handoff_review
    name: handoffs
    description: "For each handoff: flag any misalignment and rate the quality."
    steps_key: steps
    agent_key: agent
    flags: [info_loss, dropped_constraint, garbling, goal_drift]
    quality_scale: 5

採点については、agent_scorecard が各エージェントを役割忠実度・貢献・協調で評価し、チームを独自の次元で採点するため、協調の悪いチームの中にいる優秀な個別エージェントが数値で可視化されます。

どの手法を使うべきですか？

  • パイプラインのデバッグ：相互作用グラフと失敗帰属から始めて、実行が壊れる場所を局在化します。
  • オーケストレーションパターンの比較：スコアカードを追加して、同じタスク上で sequential 対 hierarchical 対 group-chat の設計を採点します。
  • 学習データや報酬データの構築：MAST モードを使って（trajectory_eval 経由で）ステップ粒度で失敗をタグ付けし、ラベルが行動したエージェントとステップに結び付くようにします。
  • 並行性のバグ：ツール競合タイムラインを使って、トランスクリプトでは見えないデッドロックと競合を捉えます。

帰属についての一致度は、他のあらゆる主観的ラベルと同じように測定します。アノテーター間一致度を参照してください。

さらに読む