MCP (Model Context Protocol) の技術的負債と2026年におけるアーキテクチャ上の再評価

Tue, 26 May 2026 12:40:20 +0900

1. 2026年におけるMCP論争の技術的背景

2026年3月、AI開発コミュニティにおいてModel Context Protocol（MCP）の存続可能性に関する激しい議論が巻き起こりました。PerplexityのCTOであるDenis Yarats氏による「内部的なMCPの破棄」宣言と、Quandri Engineeringによる「MCP is Dead」という技術レポートがその発端です。批判の核心は、CLIと比較して最大65倍に達するコンテキストウィンドウの浪費、40件を超えるCVE脆弱性の検出、および運用上の信頼性の低さにあります。

本稿では、インフラアーキテクトの視点から、MCPの構造的欠陥と、それでもなお拡大を続ける採用メトリクスの乖離を分析し、実務における導入判断基準を定義します。

2. コンテキストウィンドウの枯渇：定量的分析

Quandriの調査によれば、MCPサーバーの接続はLLMのコンテキストウィンドウを著しく圧迫します。Linear、Notion、Slack、Postgresの4つのサーバーを同時接続した場合、ユーザーの入力を処理する前に、ツール定義だけでコンテキストの約10.5%が消費されることが判明しました。

トークン消費の具体例（スキーマ定義のみ）

Linear Server (42 tools): 約12,807 tokens
Notion Server (14 tools): 約4,039 tokens
Slack Server (12 tools): 約3,792 tokens
Postgres Server (9 tools): 約438 tokens
合計オーバーヘッド: 約21,076 tokens

CLI（curl）を用いた場合、単一のクエリに対するプロンプト消費は200トークン程度に収まりますが、MCP経由ではツール定義を含めて12,957トークンを要します。これは、同一タスクにおいてMCPがCLIの約65倍のトークンを消費することを意味します。Perplexityの事例では、3つのMCPサーバーが200,000トークンのうち143,000トークン（72%）を占有し、推論に利用可能な領域が致命的に不足する事態が報告されています。

3. セキュリティ・クライシス：STDIOとRCEの脆弱性

2026年1月から4月の間に、MCP実装に関連する40件以上のCVEが公開されました。特に深刻なのは、MCPの主要なトランスポート層であるSTDIO（標準入出力）の設計に起因する脆弱性です。

脆弱性の内訳

シェル/実行インジェクション (43%): 生成されたコマンド文字列のサニタイズ不備によるRCE。
認証バイパス (13%): ツールへの不正アクセス。
パス・トラバーサル (10%): ファイルシステム境界の突破。

特に CVE-2025-6514 (CVSS 9.6) は、Python、TypeScript、Rustの公式SDKに影響を与え、攻撃者がユーザーデータや内部データベースにアクセスすることを可能にしました。Anthropic側はこの挙動を「想定内」とし、サニタイズの責任を開発者に委ねていますが、これはプロトコルレベルでの「修正不能な欠陥」と見なされるリスクを孕んでいます。

4. 運用上の摩擦とレイテンシ

実務におけるMCPの運用には、以下の摩擦点が存在します。

初期化のオーバーヘッド: Jira MCPサーバーのベンチマークでは、直接的なREST API利用と比較して、初期化時間を含めると9.4倍の遅延が発生します。
プロセスの多重管理: 各サーバーに対して個別のプロセスを維持する必要があり、リソース消費とゾンビプロセスの管理が課題となります。
ツール競合: 同一セッション内で複数のツールが競合した場合の優先順位付けや、不透明な権限管理がデバッグを困難にします。

5. 採用判断基準：MCP vs CLI vs Skills

選択肢	推奨ユースケース	メリット	デメリット
CLI/API	gh, psql, aws等の既存ツールがある場合	低レイテンシ、高い信頼性	LLM専用の抽象化がない
Skills Pattern	定型的なワークフロー（PRレビュー等）	プロンプトに最適化、低コスト	汎用性に欠ける
MCP	Slack, Notion等のCLIがないサービス	ベンダー中立、相互運用性	トークン消費大、セキュリティリスク

6. 実装におけるガードレールと対策

MCPを導入する場合、以下の制約を課すことが不可欠です。

対策1：ツールの最小化 Harnessの事例では、ツール数を130から11に削減することで、コンテキスト占有率を26%から1.6%に改善しました。必要なエンドポイントのみを公開する「疎な定義」が必須です。

対策2：Deferred Loading（Tool Search）の採用 Claude Code（2026年1月リリース）に見られるように、初期化時に全スキーマをロードせず、キーワード検索に基づいて必要な3〜5個のツールのみを動的にロードする手法を採用することで、トークン消費を85-95%削減可能です。

対策3：入力サニタイズの厳格化 SDKの機能に依存せず、ツール呼び出しの直前で独自のバリデーション層を実装してください。

// Example: Strict Input Validation Layer for MCP Tool Calls
async function callMcpTool(toolName: string, args: any) {
const schema = getSecuritySchema(toolName);

// 1. Strict Regex Validation for Shell Injection Prevention
if (args.command &amp;&amp; !/^[a-zA-Z0-9\-\_\.]+$/.test(args.command)) {
throw new Error("⚠️ Security Alert: Potential Injection Detected");
}

// 2. Path Traversal Check
if (args.path &amp;&amp; args.path.includes("..")) {
throw new Error("⚠️ Security Alert: Path Traversal Attempted");
}

return await mcpClient.execute(toolName, args);
}

Findings

💡 MCPは「死んだ」わけではなく、ハイプサイクルの幻滅期（Trough of Disillusionment）にあります。月間ダウンロード数9,700万件という数字は、そのエコシステムの強固さを示しています。
⚠️ 最大の課題は、ナイーブな実装によるトークンの浪費と、STDIOに起因するセキュリティ境界の曖昧さです。
🛠️ エンタープライズ環境では、Tool Searchによる動的ロードと、読み取り専用モードの強制、および厳格な監査ログ（auditd等との連携）を組み合わせた運用が標準となります。
🚀 2026年後半には、APIゲートウェイベンダーによるMCPネイティブサポートが進み、プロトコルの抽象化層がより堅牢なものへと進化することが予想されます。

Context-Window-Optimization on K-Life Hack | 韓国ハイエンド・ライフスタイルガイド