第14章 — ベンチマーク、テスト、性能

LLM Primer IV: MCPで設計するAI認知 の章ごとウォークスルー、第15回・最終回です。アーキテクチャがついに身もふたもない問いに答えねばならなくなります — このシステムは本当に動くのか? — そして答えは、本物のベンチマーク、2つの体系的失敗モード、ほとんどのチームが本番ロールアウト初日に発見する10倍スループットの崖、を通じて到着します。

なぜこの章があるのか

丁寧に設計され、安全に堅牢化され、フレームワークでクリーンに包まれたプロトコルも、身もふたもない問いに答えねばなりません: システムは本当に動くか。エージェントは作られた仕事を解くか。負荷が倍になっても持ちこたえるか。優雅な劣化を停止に変える性能の崖はどこにあるか。前章までは「アーキテクチャを正しくする」話でした; この章は「組み上がったアーキテクチャが実際に届けるか」を測る話です。本物のLLMを本物のMCPサーバーに対して走らせた最初の公開テスト・ハーネス、MCP-Universe ベンチマーク、ベンチマークが暴いた2つの体系的失敗モードと効き始めた緩和、そしてよく設計されたセッション・プールと素朴なリクエスト単位パターンの差が1桁あるスループット側の話を歩きます。

14.1 MCP-Universe: 本物のサーバー上でエージェントを測る

2024年から2025年初頭にかけて、公開のエージェント評価は奇妙な場所にありました。ツール使用ベンチマークは、モデルが合成APIに対して構文的に正しい呼び出しを発するかを測りました。エージェント・ベンチマークは、サンドボックスでのタスク完了を測りました。欠けていたのは、本物の認証、本物のレート制限、ドリフトする本物のスキーマ、たまに空結果を返す本物のツールを持つ 本物の MCPサーバーに対してモデルを試すベンチマークでした。Salesforce AI Research が2025年にリリースした MCP-Universe が、最初の真剣な試みです。実本番MCPサーバー11個 — Google Maps、GitHub、Yahoo Finance、Blender、Playwright、本物の検索エンジン — を覆う6つの評価ドメインと、231タスク。それぞれに、モデルが沿道で「正しい」ツール呼び出しを発したかではなく、最終状態が期待結果に一致するかを確認する自動評価器がついています。

見出しの結果はモデル世代を跨いで持ちこたえています。合成ベンチマークで80点台のClaude 3.5 Sonnet は、MCP-Universe 全体で40点台前半までしか届きませんでした。GPT-4o、Gemini 1.5 Pro、Llama-3 70B 系も同様の領域に集まりました。閉鎖コースのツール使用と本物のMCP性能のあいだのギャップは絶対値で約40点で、規模だけでは閉じませんでした。失敗は分かりやすいカテゴリに集まります: ツール出力がウィンドウを満たすにつれての長文コンテキスト劣化、馴染みのないスキーマを読み違える未知ツール探索、出力形式が合わずに意味的橋渡しがないサーバー間の協調、そしてモデルが正しいツールを選び、正しく呼び、正しい答えを取り戻しながら、ツール出力を広い推論に統合し損ねて最終的に間違った結論に着くタスク固有推論。MCP-Universe を真剣な計器にしている構造的判断は、実行ベース評価(参照トレースとの比較ではなく本物のサーバーへ呼び出しを実行する)、リアルタイム・データ(ライブ市場データを使い、評価器が実行時点の答えを追跡)、マルチターン評価(各ステップではなく最終状態で採点)。有用な副作用: ベンチマークはサーバー設計への間接的な品質シグナルとして働き、エージェント性能を気にするサーバー作者は公開のターゲットを持てるようになりました。

14.2 2つの体系的課題と効くもの

長文コンテキスト劣化と未知ツール探索は、緩和が自明でないので丁寧な扱いに値する2つの大きな失敗モードです。MCPエージェントでの長文コンテキスト劣化には特有の形があります: コンテキストがツール出力で満たされる — それぞれは何らかの意味で 関連 していて、どれもモデルが選んだ呼び出しの結果 — が、どれも嵩高く、その中で実際に荷重を担う事実は小さい。緩和は情報提示のレベルで動きます。ツール結果の要約 は、エージェントのコンテキストに着地する前の生のツール出力に対して安価なモデル(Haiku、GPT-4o-mini、Gemini Flash)を走らせる; 本番配備は長文コンテキスト完了率が2〜3倍改善し、呼び出しあたりコストは安価モデルが支配すると報告されています。JSON ペイロードと並ぶ summary フィールド付きの 構造化ツール出力 — 2025年のプロトコル改訂で形式化された — は、追加モデル呼び出しなしで同様の仕事をします。エージェント・ループ上の コンテキスト圧縮 は、圧縮を逐語で生き延びるエージェント管理スクラッチパッドと組み合わさり、会話自体が長くなりすぎるケースを扱います; 本番配備は20〜40ステップごとに圧縮を引き、元コンテキストのおよそ3分の1を保ちます。

未知ツール探索は別の形をしています。エージェントが訓練されていないツールを持つサーバーに接続すると、モデルの最初の呼び出しはしばしば失敗します — 型違い、順序違い、ときに完全に違うツール。緩和はメイン・ループの前の 探索フェーズ: フレームワークはモデルに各ツールの説明を読ませ、何をするかを要約させ、例示の起動を生成させ、自信のないパラメータを印付けさせます。結果のメモはエージェントのコンテキストの先頭に付きます。コストはセッション開始時の安価呼び出し数回、利益は MCP-Universe のようなベンチマークで完了率20〜30ポイントの改善と、後の失敗を帰属させやすくする「エージェントが述べた理解」の監査可能な記録。パターンは 変更された ツールへも広がります: 接続時にツール面のハッシュを取り、ハッシュが変わるたびにウォームアップを再実行する。これで「サーバーが更新され、エージェントが何週間も失敗し続け、誰も気づかない」という静かなドリフトの失敗モードは消えます。関連する3つ目の論点も名指す価値があります: ツール記述の質。多くのサーバーは人間開発者向けに書かれた記述 — 簡潔、業界用語混じり、文脈前提 — を出荷しました。「そのシステムを見たことのないインターンに対して書く」スタイルに書き直されたサーバーは、エージェントコードを変えずに同じモデルで測定可能な改善を示しました。モデルがツールを覗く唯一の窓は記述で、単独で立たない記述は「ツールを使えないモデル」を生みます。

14.3 セッション・プールのスループット崖

正しさは話の半分です。本番現実は、エージェントを速くする設計選択がしばしば正しさに含意を持ち、その逆も真、ということ。2025〜2026年のMCP配備で単一最大のスループット問題は、Streamable HTTP セッションを管理する2つの方法のあいだのギャップで、約10倍です。セッション・パー・リクエストは、エージェント・リクエストごとに新しいセッションを開き、その中でツール呼び出しを走らせ、完了時に閉じます。共有セッション・プールは、長命なセッションのプールを維持し、各リクエストをプールから1つに割り当てます。標準的なサーバーと代表的なワークロードでのスループット差は一貫して約10倍 — コモディティ・ハードウェアでセッション・パー・リクエストが約30 req/s、プールが約290〜300 req/s。ギャップを知らないチームは、ステージングは順調、本番ロールアウトでセッション作成オーバーヘッドが支配するリクエストレートで壁にぶつかる、という形で発見します。

機構は素直です。セッション作成は高価 — 状態割り当て、能力交渉、認証情報の検証、クリーンアップ登録、構造化ロギング — で、MCPレベルのハンドシェイクはトランスポートが避けられないプロトコル・ラウンドトリップを足します。セッション・パー・リクエストは全リクエストごとにこのコストを払い、プールはセッションあたり一度払って按分します。プールが実務で本当に動くかを決める実装ディテール: 隔離(リクエストごとの状態はセッション内のサブ・コンテキストで、リクエストごとに生成・破棄され、セッションごとの状態は共有)、プール・サイズ(バーストにオートスケーリング付きのp95同時数)、ヘルス・チェック(アイドル・セッションへのバックグラウンド・チェック、割り当て時の高速チェック)、複数呼び出しに状態がまたがるツール向けのスティッキー・セッション越しの リクエスト・アフィニティ。その上に、HTTP/2 または HTTP/3 の接続多重化 — 1本の下層接続が多くの同時ストリームを運ぶ — を重ねると、引用した数字に到達します。プール層のどちらかだけでは、改善ははるかに小さい。テール・レイテンシ次元も大事です: セッション・パー・リクエストのサーバーは作成中の不運な瞬間に長いテール・レイテンシを持ち、プールは作成コストがリクエストのホットパスから外れて非同期なので締まったテールを持ちます。p99 は普通3〜4倍改善 — スループットより大きな改善で、ユーザー体験を実際に形作るのはこちらです。

14.4 シリーズが組み立てたもの

4巻は意図的なアークを歩きました。第I巻はモデルの内側について。第II巻はプロンプトと推論について。第III巻は検索拡張生成について。本巻はエージェントとツールについて、MCPを軸に組まれました — MCPが、エージェント・アーキテクチャを首尾一貫させた技術的基盤だからです。3つの糸が通底しています。1つ目は 認知と運用の分離: モデルが認知層、フレームワークとMCPサーバーが運用層で、本番失敗のほとんどは2つを混ぜたところから来ます。2つ目は 有限のコンテキスト予算: コンテキストは希少リソースで、信頼できるエージェントを生むアーキテクチャ上の選択は、この希少性を尊重するものです。3つ目は 境界としてのプロトコル: MCPはワイヤ形式以上のもの — 能力が流れ、信頼が交渉され、将来の進化が続く境界 — です。工学的圧力に耐えるプロトコルはインフラになります。MCPはそうなりつつあるようです。

第IV巻を踏まえて

本章は本巻の最終章なので、踏まえるのは次章ではなく次巻です。LLM Primer V — 実世界のLLMアプリケーションを作る は、第I巻から第IV巻で築いた基盤を、特定のアプリ原型 — ソフトウェア工学のアシスタント、業務自動化のエージェント、垂直アプリの中の副操縦士、自律的な研究ツール — に組み立てます。扱いは、基盤的な仕組み(前巻まで)より、アプリケーション・レベルの工学的選択 — LLMアプリのスコープをどう切れば確実に価値を届けるか、本番で評価する方法、アプリが進化するにつれてプロンプト・ツール・メモリのライフサイクルをどう管理するか — に重心が移ります。第V巻を読み終えた読者は、単一の注意ヘッドから、本物のインフラ上の本物のMCPサーバー・スタックに対してエージェントを走らせる配備済みアプリまでの道を歩き、各層がなぜそう作られたかを判断できる工学的判断力を手にしているはずです。

シリーズは LLM Primer V — 実世界のLLMアプリケーションを作る に続きます。