MCPは終わったのか？ Model Context ProtocolとCLI優先戦略の評価

Model Context Protocol (MCP) は、「AIエコシステムのUSB-C」と称賛され、Large Language Models (LLMs) を GitHub、Slack、Notion といった外部ツールに接続するためのユニバーサルな標準になると期待されていました。しかし、開発者がこれらのツールを日常のワークフローに統合するにつれ、重要な議論が浮上しています。形式化されたプロトコルのオーバーヘッドは、そのメリットを上回っているのでしょうか？

Quandriのエンジニアリングチームによる最近の分析は、多くの技術的なワークフローにおいて、MCPはオーバーエンジニアリングである可能性を示唆しています。MCPを「Skills」や直接的なCLI (Command Line Interface) の使用と比較することで、彼らは業界が、よりシンプルで効率的なエージェント的インタラクションのモデルへと移行している可能性があると主張しています。

MCPに対する反対意見：コンテキスト、信頼性、および冗長性

MCPに対する主な批判は、コンテキストウィンドウの消費、運用の安定性、および既存の開発者ツールとの重複という3つの主要な問題点に集中しています。

1. コンテキストウィンドウの税金

LLMsは有限のコンテキストウィンドウ内で動作します。MCPサーバーが接続されている場合、ツール定義（LLMにツールの機能や呼び出し方を伝えるスキーマ）をそのウィンドウ内にロードする必要があります。

Quandriの測定結果は、重大な「コンテキスト税」を明らかにしています。4つのサーバー（Linear, Notion, Slack, and Postgres）が接続されたスタックでは、200Kトークン・コンテキストウィンドウ（Claude）の10.5%と、128Kウィンドウ（GPT-4o）の16.5%が、ツール定義だけで消費されていました。

例えば、Linear MCPサーバーは42個のツール定義を提供します。開発者が単一のIssueをフェッチするだけであっても、LLMは42個すべてのツールの定義を保持しなければならず、一部の個別のツール（save_issueなど）はそれぞれ600トークン以上を消費します。

2. 運用の信頼性

MCPはLLMと基盤となるAPIの間に追加のプロセス層を導入するため、レイテンシと不安定さを引き起こす可能性があります。ベンチマークでは、MCPは直接的なREST API呼び出しよりも大幅に遅いことが示されています。初期化のオーバーヘッドにより、1回の呼び出しあたり最大3倍、最初の呼び出しでは10倍近く遅くなることがあります。

一般的な失敗モードには以下が含まれます：

初期化の失敗: 繰り返される再認証の要求。
セッション中のクラッシュ: 会話中にMCPサーバーのプロセスが失敗する。
不透明な権限: 特定のツールが具体的にどのような権限を持っているかを監査するのが困難。

3. CLIとの冗長性

開発者にとって、CLIはすでに強力で構成可能なインターフェースです。この記事では、MCPがターミナルですでに存在する機能を複製していることが多いと主張しています。

代替案：CLI優先戦略と「Skills」パターン

これらの問題を軽減するために、Quandriは2つの代替案を提案しています。

代替案 1: CLI優先戦略

プロトコルを介さず、LLMにCLI、API、およびドキュメントを提供します。LLMsはすでに膨大な技術ドキュメントやman pagesに基づいて学習されているため、最小限の追加プロンプトで既存のCLIを使用できることが多いです。

代替案 2: The Skills パターン

MCPが「テーブルの上にすべてのメニューを事前に並べる」ものだとすれば、Skillsパターンは「司書に、必要な本だけを尋ねる」ものです。Skillは、凝縮された指示セット（例：特定の curl コマンドとAPIエンドポイント）であり、そのSkillが具体的に呼び出されたときにのみコンテキストウィンドウにロードされます。これにより、MCPの恒久的なコンテキスト税を回避できます。

MCPの反論：なぜMCPは依然として重要なのか

批判はありますが、コミュニティ（OpenAIのエンジニアを含む）は、MCPの価値は単なる関数の呼び出し方ではなく、ディスカバリー（発見）とトランスポート（転送）のプロトコルとしての役割にありますと主張しています。

非技術的なユーザーへのアクセスの拡大

CLIは開発者には強力ですが、人事、財務、またはプロジェクトマネージャーには利用不可能です。MCPは、非技術的なユーザーがターミナルに触れることなく、複雑なサービスと対インタ랙ションできる抽象化レイヤーを提供します。あるコメントでは、「人事や財務の担当者にCLIをインストールさせようとしてみてください」と述べられています。

「APIレス」な世界におけるサービスディスカバリー

多くの企業は、堅牢なきCLIや公開APIを持っていません。そのような組織にとって、MCPサーバーを構築することは、サービスを「AI-ready」にするための最も速い方法です。この観点では、MCPは単なる通信レイヤーではなく、サービスがその機能をエージェントに広告するための方法です。

安全性とガバナンス

本番環境において、MCPは重要な安全性レイヤーを提供します。CLIベースのエージェントが、もしコマンドを誤認（hallucinate）した場合、理論上、データベースに対して DROP TABLE を実行してしまう可能性があります。しかし、MCPサーバーは、読み取り専用モードを強制したり、クエリをデータベースに届ける前にサーバーレベルでクエリを検証したりすることができます。

統合：適切なツールを選択する

議論の焦点は、必ずしもどちらの技術が「より優れている」かではなく、どちらが特定のユースケースに適しているかです。議論から、以下のフレームワークが導き出されます。

Bash + CLI を使用する: ローカル開発、個人用ツール、および強力な既存のCLI（例：gh, aws）を持つサービス用。これは、最も速く、最もトークン効率の良い方法です。
Skills を使用する: 繰り返し可能で、かつ、すべてのプロンプトでアクティブである必要はない、マルチステップのワークフロー用。
MCP を使用する: CLIのないサービス、CLIを使えない非技術的なエンドユーザー、または、厳格な権限スコープとクエリの安全性が必要な本番環境用。

結論

「MCPは終わったのか」というナラティブは、コンテキストの肥大化やレイテンシに関する実態的な非効率性を指摘していますが、それはAIエージェントのアクセスを民主化するプロトコルの役割を見落としています。パワーユーザーにとっては、CLI remains king（CLIが王であり続けます）。エコシステム全体にとっては、サービスディスカバリーと認証のための標準化されたプロトコルは不可欠です。将来的には、ハイブリッドアプローチが主流となるでしょう。すなわち、遅延ロード（コンテキスト税を回避するため）と、MCPが単なる関数呼び出しのラッパーではなく、OAuth-likeなアイデンティティとディスカバリーのレイヤーとして機能する方向へのシフトです。