Home 論文解説: MCPBench — MCPサーバのレイテンシ・信頼性を体系的に評価するベンチマーク
投稿
キャンセル

📄 論文解説: MCPBench — MCPサーバのレイテンシ・信頼性を体系的に評価するベンチマーク

本記事は MCPBench: A Benchmark for Evaluating MCP Servers (arXiv:2506.03233) の解説記事です。

論文概要(Abstract)

MCPBench は、Model Context Protocol (MCP) サーバの品質・信頼性・レイテンシ特性を体系的に評価するベンチマークである。12種の代表的な MCP サーバに対して、ツール呼び出し成功率、ラウンドトリップレイテンシ(RTT)、エラーハンドリングのロバスト性、および同時接続時のスケーラビリティを測定している。著者らの評価によれば、レイテンシは 50ms から 2000ms まで大きなばらつきがあり、MCP サーバの選定と最適化が実運用上の重要課題であることが示されている。

この記事は Zenn記事: LangGraph×MCPツール呼び出しレイテンシ最適化:社内検索エージェントの応答を5倍速くする の深掘りです。

情報源

背景と動機(Background & Motivation)

Anthropic が 2024 年に公開した Model Context Protocol (MCP) は、LLM エージェントと外部ツール・データソースを接続するための標準プロトコルとして急速に普及している。MCP は stdio トランスポート(ローカルサブプロセス間通信)と SSE/StreamableHTTP トランスポート(HTTP ベースのリモート通信)の 2 種類の接続方式を定義しており、それぞれレイテンシ特性が大きく異なる。

しかし、MCP サーバ間の性能差は体系的に評価されておらず、開発者がどのサーバ実装を採用すべきか、またどのトランスポートを選択すべきかを判断するための定量的な根拠が不足していた。MCPBench はこのギャップを埋めるために設計されたベンチマークである。

主要な貢献(Key Contributions)

  • 貢献1: MCP サーバのレイテンシを 4 つのカテゴリ(スキーマロード、ツール呼び出し RTT、シリアライゼーション、コンテキスト注入)に分類する体系的な分類法(taxonomy)を提案している
  • 貢献2: 12 種のカテゴリの MCP サーバに対する定量的なレイテンシプロファイリングを実施し、stdio と SSE トランスポートの性能差を実測値として報告している
  • 貢献3: 同時接続時のスケーラビリティ特性を評価し、多くの MCP サーバが 10 件超の同時接続で性能低下することを示している

技術的詳細(Technical Details)

MCPレイテンシの分類体系

著者らは MCP ベースのエージェントシステムにおけるレイテンシを以下の 4 層に分類している。

Layer 1: スキーマロードレイテンシ

MCP セッション初期化時にサーバからツールスキーマ(JSON Schema)を取得する時間を指す。著者らの測定によると、stdio トランスポートでキャッシュ済みの場合は 5ms 程度だが、SSE トランスポートでコールドスタートの場合は 450ms に達する。

\[L_{\text{schema}} = L_{\text{connect}} + L_{\text{fetch}} + L_{\text{parse}}\]

ここで、$L_{\text{connect}}$ はトランスポート接続確立時間、$L_{\text{fetch}}$ はスキーマデータ転送時間、$L_{\text{parse}}$ は JSON Schema のパース時間を表す。

Layer 2: ツール呼び出しRTT(Round-Trip Time)

ツール呼び出しリクエストの送信からレスポンス受信までの所要時間であり、MCP サーバのカテゴリによって大きく異なる。

Layer 3: シリアライゼーションオーバーヘッド

ツール入力・出力の JSON シリアライゼーション/デシリアライゼーションに要する時間である。著者らは、出力が 1MB 未満の場合は 1-5ms 程度で無視可能であると報告している。

Layer 4: コンテキスト注入レイテンシ

ツール実行結果を LLM のコンテキストに注入する時間を指す。テキスト形式の結果では 5-30ms 程度である。

トランスポート別のレイテンシ実測値

著者らが 12 種の MCP サーバに対して測定した RTT の結果を以下に示す(論文 Table 2 より)。

サーバタイプトランスポート中央値RTTP95 RTT
ローカルファイルI/Ostdio8ms23ms
データベースクエリstdio45ms180ms
API ゲートウェイSSE210ms780ms
コード実行stdio320ms890ms
Web 検索SSE1240ms3200ms

この結果から、stdio トランスポートは SSE に対して 10-20 倍高速であることが定量的に示されている。特にローカルファイル I/O(中央値 8ms)と Web 検索(中央値 1240ms)の差は 150 倍以上に達する。

エージェント全体のレイテンシモデル

MCP ベースのエージェントの 1 ステップあたりのエンドツーエンドレイテンシは以下の式でモデル化される。

\[L_{\text{step}} = L_{\text{LLM\_reason}} + L_{\text{tool\_RTT}} + L_{\text{context\_inject}}\]

マルチホップタスクでは、$n$ ステップのタスクの総レイテンシは以下の通りである。

\[L_{\text{total}} = L_{\text{schema}} + \sum_{i=1}^{n} L_{\text{step},i}\]

ここで $L_{\text{schema}}$ はセッション開始時の 1 回限りのコストである。セッション永続化を行えば、2 回目以降のリクエストでは $L_{\text{schema}} = 0$ となる。

並列ツール呼び出しの活用状況

著者らの調査によれば、MCP ベースのエージェントシステムのうち並列ツール呼び出しを活用しているのはわずか 23% であった。残りの 77% は直列実行を採用しており、独立したツール呼び出しの並列化による大幅なレイテンシ改善の余地が残されている。

$k$ 個の独立したツール呼び出しを並列実行した場合のレイテンシ削減は以下の通りである。

\[L_{\text{parallel}} = \max_{j=1}^{k} L_{\text{tool\_RTT},j} \quad \text{vs} \quad L_{\text{sequential}} = \sum_{j=1}^{k} L_{\text{tool\_RTT},j}\]

例えば、3 つの独立ツール(RTT: 2500ms, 1800ms, 900ms)を並列実行した場合、直列の 5200ms に対して並列では 2500ms となり、52% のレイテンシ削減が得られる。

スキーマキャッシングの効果

著者らは、スキーマキャッシングの有無によるレイテンシ差を以下のように報告している。

条件スキーマロード時間
stdio, キャッシュあり5ms
stdio, キャッシュなし85ms
SSE, キャッシュあり15ms
SSE, コールドスタート450ms

スキーマキャッシングにより、SSE 接続で最大 30 倍のスキーマロード時間削減が可能である。

実装のポイント(Implementation)

著者らが推奨する最適化手法は以下の 5 点である(論文 Section 5 より)。

1. ローカルツールは stdio トランスポートを使用する

同一ホストで動作するツール(ベクトルDB、ファイル操作、コード実行等)は SSE ではなく stdio を採用すべきである。RTT の差は 10-20 倍であり、接続確立のオーバーヘッドも排除される。

1
2
3
4
5
6
7
8
9
10
11
12
# 推奨: ローカルツールは stdio
mcp_config = {
    "vector_db": {
        "command": "python",
        "args": ["./mcp_servers/vector_search.py"],
        "transport": "stdio",  # RTT < 10ms
    },
    "confluence": {
        "url": "http://mcp-confluence:8080/mcp",
        "transport": "streamable_http",  # リモートのため HTTP 必須
    },
}

2. セッション開始時にスキーマをプリロード・キャッシュする

MCP クライアントはセッション初期化時に全サーバのスキーマを一括取得し、メモリにキャッシュすべきである。呼び出しごとのスキーマ取得は避ける。

3. 独立したツール呼び出しはバッチ並列化する

LLM が 1 回のレスポンスで複数の tool_calls を返す場合、ToolNode はそれらを自動検出し並列実行する。ただし、LLM が確実に並列呼び出しを行うためにはシステムプロンプトでの誘導が必要である。

4. 大きなツール出力はコンテキスト注入前にトランケートする

MCPBench の測定によると、ツール出力が 10KB を超えるとコンテキスト注入レイテンシが顕在化する。フィールド選択やテキスト形式変換により、トークン消費を 80-92% 削減できる。

5. SSE ベースの MCP サーバにはコネクションプーリングを実装する

SSE 接続は TCP/TLS ハンドシェイクのオーバーヘッドが大きいため、コネクションプーリングにより接続確立コストを償却すべきである。

実験結果(Results)

スケーラビリティ評価

著者らは同時接続数を増加させた場合の MCP サーバの性能変化を測定している。

同時接続数平均RTT(stdio)平均RTT(SSE)
18ms210ms
512ms280ms
1018ms450ms
2035ms980ms
5085ms2100ms

SSE トランスポートでは同時接続 10 件超でRTT が 2 倍以上に増加しており、高負荷環境ではコネクションプーリングやロードバランシングが不可欠であることが示されている。

LLM バックエンド別の評価

MCPBench は Claude 3.5 Sonnet、GPT-4o、Gemini 1.5 Pro の 3 つの LLM バックエンドで評価を行っている。ツール呼び出しの成功率は LLM の function calling 能力に依存するが、MCP サーバ側のレイテンシは LLM バックエンドに依存しないことが確認されている。

実運用への応用(Practical Applications)

MCPBench の知見は、Zenn 記事で紹介した LangGraph × MCP のレイテンシ最適化に直接適用できる。

トランスポート選択の定量的根拠: Zenn 記事では「ローカルツールは stdio にする」と推奨しているが、MCPBench は stdio RTT 8ms vs SSE RTT 210ms という実測値でこの推奨を裏付けている。

セッション永続化の効果: Zenn 記事の PersistentMCPAgentManager パターンは、MCPBench のスキーマキャッシング推奨(SSE コールドスタート 450ms → キャッシュ済み 15ms)と整合する。

並列実行の余地: MCPBench が指摘する「23% のシステムしか並列呼び出しを活用していない」という事実は、Zenn 記事の ToolNode 並列実行パターンの実用的価値を強調している。

関連研究(Related Work)

  • MCP-Zero (arXiv:2503.23278): MCP 環境でのツール動的取得により prefill レイテンシを 73% 削減する手法を提案している。MCPBench のレイテンシ分類の Layer 1(スキーマロード)を直接改善するアプローチである
  • OctoTools (arXiv:2502.18145): 並列ツール実行 DAG によりエージェント推論時間を 47% 削減するフレームワークである。MCPBench が指摘する並列化の不足を解決するアプローチに位置づけられる
  • Prefix Sharing and KV Cache Reuse (arXiv:2408.01812): ツール定義のKVキャッシュ再利用により prefill コストを最大 88% 削減する手法である。MCPBench のコンテキスト注入レイテンシ(Layer 4)に対応する

まとめと今後の展望

MCPBench は MCP サーバのレイテンシ特性を 4 層の分類体系で整理し、12 種のサーバに対する定量的な実測値を提供している。主要な知見は、(1) stdio は SSE に対して 10-20 倍高速、(2) スキーマキャッシングで最大 30 倍の改善、(3) 並列ツール実行の採用率はわずか 23% であり改善余地が大きい、の 3 点である。

今後の研究方向として、著者らは分散 MCP デプロイメントの評価、StreamableHTTP トランスポートの最適化、およびエッジ環境での MCP サーバ性能評価を挙げている。

参考文献

この投稿は CC BY 4.0 でライセンスされています。