LiveMCP-101: MCP対応エージェントのストレステストと診断

Posted by MktFeed.ai | 作成日時: | 更新日時:

LiveMCP-101: MCP対応エージェントのストレステストと診断

1. はじめに

外部ツールやサービスとインタラクトする能力は、自律型AIエージェントの基盤であり、静的な知識を超えた能力の拡張と、現実世界との動的なエンゲージメントを可能にします。ツール統合フレームワーク、特にモデルコンテキストプロトコル（MCP）の最近の進歩により、ウェブ検索やデータ分析からAPIインタラクションやファイル操作まで、様々な分野におけるモデルによるツールの発見、呼び出し、および調整方法が標準化されました。これらの進歩は、最小限の人間の介入で複雑な複数ステップのタスクを実行できるAIエージェントの新しい世代を約束しています。

しかし、現実世界の展開における主要な障壁として、信頼性が残っています。プロトタイプでは良好なパフォーマンスを示すシステムでも、多様なユーザークエリや実際の運用環境では失敗することが多いためです。現実的で時間的に変化する運用環境におけるエージェントの失敗を理解することは、対応するモデルとシステムアーキテクチャを改善するための貴重な洞察を提供します。

しかし、既存のベンチマークは、単一ステップのツール呼び出し、合成環境（通常はモックデータベース）、または限定されたツールセットのみに焦点を当てており、現実世界のシナリオの複雑さとダイナミズムを捉えられていません。実際には、エージェントは、時間とともに異なる応答を生成し、全く異なるドメインにまたがる実用的なツールとインタラクトする必要があります。さらに、ユーザークエリは微妙なコンテキストと具体的な制約を伴うことがあり、タスクを完了するには数十ものツール呼び出しにわたる正確な推論が必要です。その結果、現在のベンチマークでは、実際の運用環境に展開された場合の現在のエージェントシステムのギャップを完全に明らかにすることはできません。

本研究では、現実的で困難なシナリオにおいて最先端のLLMとエージェントのストレステストを行うという目標に基づき、LiveMCP-101を導入します。これは、様々なMCP対応ツール（例：ウェブブラウジング、ファイル操作、数学的推論、データ分析）の協調的な使用を必要とする101個の注意深く設計されたタスクからなるベンチマークです。特に、ユーザークエリは、LLMの書き換えと手動レビューの複数回の反復を通じて洗練されており、複雑さを高めながら実用性を維持することで、最先端のエージェントモデルとシステムがどこで不十分であるかを明らかにすることができます。MCP対応ツールは時間とともに同じAPI呼び出しに対して異なる応答を返す可能性があるため、堅牢な評価を確保するために、正解実行計画に従うエージェントと自律的に動作するエージェントの2つを並列に実行し、リアルタイムの出力に基づいてスコアを計算する新しい設定を提案します。

2. 関連研究

（関連研究のセクションは、原文の参考文献リストを元に、より詳細で分かりやすい日本語で記述する必要があります。簡潔にするため、ここでは概要のみ記述します。）

関連研究のセクションでは、Chain-of-Thought (CoT) プロンプティング、ReActフレームワーク、LLMエージェントにおける様々な自律的なツール使用戦略、そしてMCPの登場とその影響について解説しています。既存のベンチマークについても触れ、LiveMCP-101がそれらと比べてどのように優れているかを説明しています。特に、LiveMCP-101はタスクの複雑さ、多様なツールセット、動的な環境への対応、そして詳細な正解実行計画の利用において、既存のベンチマークを上回っています。

3. LiveMCP-101

3.1 作成

エージェントがさまざまなドメインのツールを活用することを必要とする困難なクエリを生成するために、まず、41個のMCPサーバーと260個のツールに及ぶMCPツールの全体的なプールから、GPT-4.1を使用して多様なアプリケーションドメインをサンプリングしました。次のステップとして、ドメインコンテキストと詳細なツール仕様（名前、説明、パラメーター）を条件として、OpenAI o3モデルを使用してさまざまな複雑さのクエリを生成します。しかし、注意深く調整されたプロンプトを使用しても、生成されたクエリの一部は、提供されたツールでは解決できないか、結果が容易に検証できない最終状態を持つ場合があります。データセットがきれいで厳密であることを保証するために、LLMの書き換えと手動修正の複数ラウンドを実行して、明確性、バランスのとれた難易度、与えられたツールでの解決可能性、客観的に検証可能な結果を保証します。すべてのクエリは、簡単（30）、中級（30）、難しい（41）の3つの難易度レベルに分類されます。図2は、各レベルの代表的な例を示しています。タスクはライブで時間的に変化するMCPサービスとやり取りするため、回答は時間とともに変化する可能性があります。したがって、固定された正解結果を持つことは、テスト時にエージェントの結果を評価する信頼できる方法とはなりません。この問題を解決するために、キュレーションされた各クエリについて、クエリとツール仕様を指定してo3を使用して実行計画を作成します。次のステップとして、参照エージェントの実行軌跡と出力を用いてそれを修正し、LLM支援による編集と手動による調整を組み合わせて、論理、ツール選択、パラメーター、データ処理のエラーを修正します。この修正には約120人の博士号保有者の時間が必要でした。各タスクは、正解の人間による検証を含む複数の試行で検証されました。最終的な計画は、実行されると参照出力を決定的に生成します。実行計画におけるツールチェーンの長さの分布を図3に示します。

3.2 評価

各タスクについて、2つの並列実行を開始します。(1)リアルタイムの参照実行：参照エージェントは、参照出力を生成するために、そこで指定されたMCPツールのみを使用して、検証済みの実行計画を厳守します。(2)リアルタイムのテスト実行：評価対象のエージェントは、自然言語クエリとタスクごとに定義されたMCPツールプールのみを受け取り、クエリを独立して分析し、ツールを選択し、呼び出しをスケジュールし、中間結果を処理する必要があります。テスト実行は、エージェントが完了を宣言するか、最大反復回数に達するまで続きます。タスクごとのプールには、すべてのタスクに不可欠なツールと、追加のMCPツールのセット（エージェントにとってタスクをより困難にするため）が含まれています。これらの追加のツールは現実世界の選択肢の幅を近似し、妨害物下でのツールの発見と選択の評価を可能にします。この設定により、時間的なずれを軽減し、評価対象のエージェントの出力と参照との公平な比較を可能にします。さらに、参照軌跡は、評価対象のエージェントの軌跡を分析するための参照を提供し、計画、ツール選択、パラメーター、および出力処理のエラーの詳細な診断を可能にします。評価対象のエージェントの結果と軌跡の両方を、LLMジャッジが1～5のリッカート尺度で評価し、{0.00, 0.25, 0.50, 0.75, 1.00}にマッピングします。プロンプトは付録A.1と付録A.2に記載されています。

結果メトリック: タスク成功率（TSR）、スコア1.00のインスタンスの割合、および平均結果スコア（ARS）、インスタンス全体の平均スコアを使用します。TSRは、正常に解決されたタスクの割合を測定し、ARSはソリューションの全体的な品質を反映します。

軌跡メトリック: 評価対象のエージェントの平均軌跡スコア（ATS）をすべてのタスクで報告します。このメトリックは、論理的整合性、完全性、および正確さについて軌跡を評価し、結果メトリックを補完するソリューションプロセスの品質を捉えます。

平均トークン消費量: トークンの効率を測定するために、各タスクについて、すべての反復ラウンドにわたるエージェントの出力トークンを合計します。報告される値は、評価セット全体でのこれらのタスクごとの合計の平均です。

平均ツール呼び出し: 各タスクについて、完全な軌跡にわたるツールの呼び出しをカウントします。報告される値は、評価セット全体でのこれらのタスクごとのカウントの平均です。

4. 実験

4.1 実験設定

LiveMCP-101で、広く使用されている18種類のLLMを評価します。OpenAI (GPT-5、GPT-5-mini、GPT-4.1、GPT-4o、GPT-4.1-mini、GPT-4o-mini、o3、o4-mini)、Anthropic (Claude-4.1-Opus、Claude-4-Sonnet、Claude-3.7-Sonnet)、Google (Gemini-2.5-Pro、Gemini-2.5-Flash)、およびオープンソース (Qwen3-235B-A22B、Qwen3-32B、Qwen3-8B、Llama-3.3-70B-Instruct、Llama-3.1-8B-Instruct)です。OpenAIの推論モデルでは、推論の努力を中程度に設定します。Anthropicモデルでは、標準モデルと拡張思考（ET）モデルの両方についてテストします。Qwen3モデルでは、思考がデフォルトで有効になっています。各エージェントは、最大30回の反復ラウンドに制限されています。参照実行には、低レイテンシと強力な指示に従う能力により、GPT-4.1を使用し、検証済みの実行計画を厳守して参照出力を生成します。各タスクについて、タスクに不可欠なすべてのサーバーとランダムにサンプリングされたMCPサーバーを組み合わせて、タスクごとに合計15個のMCPサーバーと76～125個のツールが利用できるように、タスクごとのMCPプールを作成します。広く使用されているReActプロンプティングを採用し、GPT-4.1をLLMジャッジとして使用して、最終出力と実行軌跡の両方を評価します。評価フレームワークで説明されているように、各モデルについて、タスク成功率（TSR）、平均結果スコア（ARS）、平均軌跡スコア（ATS）、平均ツール呼び出し数、および平均トークン使用量を報告します。

4.2 主要な結果

表1に示すように、GPT-5はLiveMCP-101で最高の全体的なパフォーマンスを達成し、すべての難易度レベルでトップを維持します。次に、o3、GPT-5-mini、Claude-4.1-Opus（ET）、Claude-4-Sonnet（ET）が続きます。これは、より強力な推論能力が、動的で複数ステップの問題解決とMCPツール呼び出しに意味のある改善をもたらすことを示唆しています。ミッドティアのプロプライエタリモデルでは、GPT-4.1、Gemini-2.5-Pro、Claude-3.7-Sonnetは比較的良好なパフォーマンスを示しますが、トップパフォーマーには遅れをとっています。オープンソースモデルは、プロプライエタリモデルに遅れをとっています。その中でも、Qwen3-235B-A22B（22.77％/42.57％）は最も強力ですが、最先端のものからは程遠いです。LlamaモデルはLiveMCP-101で顕著にパフォーマンスが低下しており、より詳細な分析はセクション5.2で提供されています。すべてのモデルで、タスクの難易度が高くなるにつれてパフォーマンスは大幅に低下します。特に、最も強力なモデルでも、困難なタスクでのTSRは39.02％に過ぎません。TSRとARSによるランキングはほぼ一貫しています。図4（a）は、TSR、ARS、およびATSの関係を視覚化しています。色分けされたATSは、ARSとTSRの両方とともに増加し、ATSの高いモデルは右上の領域に集中しています。これは、より良い軌跡は通常より良い出力を生むことを示唆しています。より高いATSは、より信頼性の高いツール選択、パラメーター化、および後処理に対応し、タスクの成功基準を満たすのに役立ちます。図4（b）は、TSR、平均トークン数、および平均ツール呼び出し数の関係を示しています。クローズドソースモデルは、トークンとともに緩やかな上昇傾向を示しますが、計画の質が依然として主要な推進要因です。オープンソースモデルは、2つの特徴的な非効率性を示します。Llamaのバリアントは、低トークン、低ツールの領域に集中し、ツールの機能を十分に活用せず、多くの場合早期に停止するため、ARSとTSRが低くなります。Qwenのバリアントは、反対の極端な傾向を示し、クローズドソースモデルと比較して同等の利得がないにもかかわらず、より長い出力を生成し、より多くのツールを呼び出します。拡張思考バリアントは、比較可能なトークン予算で一貫して効率のフロンティアを上方にシフトさせ、冗長さではなく、改善された計画とエラー回復からの利得を示唆しています。

4.3 アブレーションスタディ

最先端とミッドティアのクローズドソースモデルとオープンソースモデルを含む、GPT-5、Claude-4.1-Opus（ET）、GPT-4.1、Gemini-2.5-Pro、Qwen3-235B-A22B、およびQwen3-8Bについてアブレーションを実施します。LiveMCP-101では、最長の検証済み実行計画は15回のツール呼び出しを必要とします。デフォルトでは、各エージェントは最大30回の反復ラウンドに制限されており、各ラウンドには1つ以上のツールの呼び出しが含まれる場合があります。反復予算に対する感度を調べるために、この制限を15、20、30、および50ラウンドに変更します。図5（a）と（b）の結果は、2つの主要な現象を強調しています。まず、最大反復制限を15ラウンドから約25ラウンドに増やすと、追加の予算により、より徹底的なツールの探索とエラー回復が可能になるため、タスクの成功率が常に向上します。特に、最長の検証済み実行計画は15回のツール呼び出し（平均5.4回）で構成されていますが、ラウンド制限を15から約25に上げることで継続的に利得が得られることは、エージェントが正しく解決されたインスタンスでも、エラー回復や冗長な熟考に余分なラウンドを費やすことが多く、実行効率の大きな余地があることを示しています。第二に、25ラウンドを超えると、利益は飽和します。パフォーマンスは、反復容量ではなく、モデルの能力、特に計画の質とツールの使用能力によって制限されるようになります。追加のラウンドは、収益の減少をもたらし、ノイズを導入したり、エラーを複合化したりすることさえあり、パフォーマンスは本質的にフラットなままになります。デフォルトの設定では、最も要求の厳しいタスクは最大6つのMCPサーバーを必要とし、評価対象のエージェントには15個のサーバーのプールを公開します。MCPサーバーの幅に対する感度を調べるために、プールのサイズを6、10、12、および15に変更します。API制限（例：リクエストあたりの128個のツール）に達したり、コンテキストの長さを超えたりする可能性があるため、15を上限として設定します。この選択により、設定を現実的で、現実世界の展開と比較可能に保ちます。プールが増加するにつれて、拡張されたツールの検索とツールの呼び出し空間は、選択のオーバーヘッドと、スパリアスツールの使用の可能性を増大させます。弱いモデルとミッドティアモデルはこの効果により敏感であり、ノイズが蓄積し、計画帯域幅が希釈されると、多くの場合低下することがわかります。対照的に、トップティアシステム（例：GPT-5、Claude-4.1-Opus（ET））はほぼ安定したままです。より強力な計画とツールのスクリーニングにより、妨害物が軽減されるため、パフォーマンスの変化は無視できます。

4.4 LLM as a Judge の分析

最終出力と実行軌跡の両方を評価するために、LLM as a Judge を適用します。信頼性を評価するために、6つの代表的なモデル（GPT-5、Claude-4.1-Opus（ET）、GPT-4.1、Gemini-2.5-Pro、Qwen3-235B-A22B、およびQwen3-32B）について、層化されたタスクのサブセットでブラインド人間専門家研究を実施します。専門家は同じルブリックに従い、プロンプトを判断します。インスタンスレベルで人間とLLMジャッジの決定を比較し、コーエンのκを使用してインターレーターの合意を報告します。合計30個のタスクのサンプルセットを評価し、難易度レベル（簡単、中級、困難）ごとに10個ずつ評価します。6つのモデルすべてで、人間とLLMジャッジの合意（二次加重コーエンのκ）は、結果評価で85％を超え、軌跡評価でそれぞれ78％を超えており、LLMジャッジは一貫性のある、人間と整合性の取れた評価を提供することを示しています。

5. 考察

5.1 トークンの効率

クローズドソースモデルは、驚くべき対数形状のパターンを示すことを観察しました。タスク成功率（TSR）は、小さいトークン予算で急速に上昇し、その後プラトーに達します（図4（b））。直感的には、初期のトークンは、計画、ツールのプロービング、制約のチェックなど、高価値の行動を推進し、大きな利得をもたらします。しかし、予算が増えるにつれて、追加のトークンはほとんどが冗長性（より長い説明、繰り返し自己チェック）を追加するだけであり、新しい証拠を追加するわけではなく、収益は減少します。この曲線は、モデルのトークンの効率性を反映しています。最強のモデルでさえ、ある時点を超えた追加のトークンを効果的に使用することに苦労しています。トークンあたり、またはドルあたり、どのように知性を最大化するかという問題は、MCPベースのエージェントにとって興味深い未解決の課題です。対照的に、オープンソースモデルはこのトレンドを破ります。同等またはそれ以上のトークンを使用しているにもかかわらず、TSRはほとんど改善されず、トークンを信頼できる証拠に変換できないことを明らかにし、トークンの効率が低くなります。

5.2 エラー分析

MCPベースのツール使用における失敗モードを診断するために、さまざまなモデル全体の実行ログを注意深く分析し、7つのサブタイプを含む3つのエラーカテゴリを特定します。ツール計画とオーケストレーションエラー（1〜4）、パラメーターエラー（5〜6）、および出力処理エラー（7）。

(1) 要求の無視: エージェントは明示的に述べられた要求を見逃し、関連するツールを選択しません。典型的な兆候には、対応する思考プロセスとツールの呼び出しがないこと、早期終了、または要求に対処しない一般的な最終的な回答などがあります。これは、エージェントがプロンプトから主要な要求を抽出できなかったり、実行中にそれらを追跡できなくなったりした場合によく発生します。

(2) 過信した自己解決: エージェントは要求を認識しますが、必要なツールを呼び出すことなく、独自の知識や独自の推論と能力を使用して回答しようとします。症状には、対応するツールの呼び出しがないこと、一般的な回答または幻覚された回答、早期終了などがあります。

(3) 生産性のない思考: エージェントはツールが必要であることを認識しており、計画またはパラメーターについて話し合う可能性がありますが、呼び出しを開始せず、要求に対処するソリューションを提案しません。生産性のない、または冗長な思考にループし、最終的にタイムアウトするか、諦めます。症状には、実行のない計画の繰り返し書き換え、トークン消費の多い思考、要求に対する呼び出しゼロでラウンド制限に達することなどがあります。

(4) ツールの誤った選択: エージェントはツールを呼び出しますが、不適切なツールを選択するため、誤った中間状態または最終出力が生成されます。これは、単一の誤った選択または予算が使い果たされるまで繰り返し誤った呼び出しとして発生する可能性があります。症状には、無関係な応答、繰り返しの間違い、出力に必要なフィールドの欠落などがあります。

(5) 構文エラー: ツールに提供されるパラメーターは、不適切な型、欠落しているフィールド名、または無効なスキーマなど、形式が正しくありません。これらのエラーにより、MCPサーバーは要求を正しく解析できず、失敗します。

(6) セマンティックエラー: パラメーターは形式が正しいですが、タスクの意図と一致しません。一般的なケースには、範囲外のクエリ文字列、誤った識別子またはエンティティ参照、不正確なコンテキスト制約などがあります。これらのエラーは、パラメーターを生成するために使用される中間推論における間違いから発生することがよくあります。

(7) 出力の構文解析エラー: ツールは正しい結果を返しますが、エージェントは構文解析中にそれを誤って処理するため、誤った中間状態または最終的な回答が生成されます。さらに、さまざまな機能を備えたいくつかの一般的なモデルを評価し、そのコアエラータイプの分布を図7に示します。結果からいくつかの興味深い観察を推測できます。セマンティックエラーが優勢です。強力なモデルでさえ、16〜25％の割合を示すのに対し、小さいモデルでは40％を超えています（例：GPT-4.1-mini）。これは、ライブツール使用における主要なボトルネックとして、コンテンツのグラウンディングと制約の施行を指摘しています。構文エラーは最先端モデルでは無視できますが、Llama-3.3-70B-Instructでは壊滅的です（約48％）。考えられる原因は、MCP固有のトレーニングが限られていることです。Llama-3のリリース後、MCPの採用が急増したため、MCP関数呼び出しスキーマに関するターゲット型のファインチューニングにより、このようなエラーを大幅に削減し、全体的なパフォーマンスを向上させることができます。過信した自己解決は、ミッドティアモデルでは一般的です。計画とスクリーニングは、大規模なツールプールと長いコンテキストでは依然として脆弱であるため、内部知識に依存する方が、不確実なツールの選択とパラメーター化を試みるよりも安全に見えるためです。

6. まとめ

本研究では、モデルコンテキストプロトコル（MCP）を介して、現実的で動的な環境での複数ステップのツール使用を計画および実行するAIエージェントの能力を評価するための、困難なユーザークエリのベンチマークであるLiveMCP-101を紹介します。このベンチマークは、反復的なLLMベースの書き換えと手動レビューを通じて洗練された101個の多様なタスクで構成されており、ウェブ検索、ファイル操作、数学的推論、データ分析などのドメインに及びます。さらに、正解実行計画に基づいた評価方法論を提案し、進化する環境におけるエージェントのパフォーマンスのより信頼性の高い測定値を提供します。実験の結果、最先端のLLMでも成功率は60％を下回り、ツールのオーケストレーション、適応型推論、トークンの効率性における主要な課題を強調しています。詳細なアブレーションとエラー分析により、明確な失敗モードが明らかになり、改善の機会が強調されています。LiveMCP-101をリリースすることにより、より有能な自律型AIエージェントの開発をベンチマークし、推進するための厳格でスケーラブルなフレームワークを確立します。

(付録A：プロンプトは、原文の記述を元に、日本語で記述する必要があります。ここでは省略します。)

Original URL: https://arxiv.org/html/2508.15760v1