MCPが時代遅れになりつつある理由：Model Context Protocolの批判的レビュー

TL;DR – MCPの関連性は低下している

2024年11月に発表されたModel Context Protocol（MCP）は、今日の大規模言語モデルがAPIやコマンドラインツールを直接発見・呼び出しできるため、ますます不要になりつつあります。MCPサーバーがもたらすコンテキストの肥大化と運用オーバーヘッドを排除できるからです。

MCPの当初の約束

MCPはAnthropicによって、エージェントが統一されたJSON-RPCインターフェースを通じて外部サービスにアクセスできるようにするために作られました。初期のモデルは、自然言語の意図を具体的なツール呼び出しに変換するための薄い抽象化レイヤーを必要としており、MCPはターミナルアクセスを持たないエージェント向けのプラグアンドプレイソリューションとして急速に普及しました。

「MCPは2024年11月にAnthropicチームによって、エージェントが外部サービスやデータソースに接続するのを支援するプロトコルとしてリリースされました」【1】。

プロトコルが崩れ始めた理由

増え続けるツールセットによるコンテキストの肥大化

各MCPサーバーには多くのツールがバンドルされており、それぞれに独自のスキーマがあります。エージェントが複数のサーバーをロードすると、組み合わされたスキーマがモデルのコンテキストウィンドウを圧迫し、開発者はツールを削減したりプロキシしたりせざるを得なくなります。

「各サーバーには複数のツールが付属し、それぞれに独自のスキーマがあるため、これらすべてのモデルのコンテキストを過負荷にし始めました」【1】。

より優れたモデルはコードを直接生成・実行できる

現代のエージェント（Claude Code、Meta Muse、OpenClawなど）は、スクリプトを書き、複数サービスのワークフローを構成し、これまで見たことのないAPIを呼び出すことができます。CloudflareのCode Modeは、LLMがMCPサーバーに依存する代わりにサンドボックス化されたスクリプトを生成できるようにすることで、この変化を示しています【1】。

「LLMはこれが非常に得意になったため、CloudflareはCode Modeを立ち上げました。これは、LLMがさまざまな呼び出しをサンドボックスで実行できるスクリプトに構成することで、MCPをより良く使う方法です」【1】。

`--help`による直接的なCLI発見

エージェントは現在、コマンドラインツールの--help出力を使用して引数を推測するため、別のディスカバリーレイヤーが不要になりました。

「LLMは--helpコマンドを使ってCLIを発見する方法を理解したため、多くのサービスにアクセスするためにMCPサーバーはもはや必要ありません」【1】。

コミュニティからの反論

ガバナンス、認証、監査可能性

一部のコメンテーターは、MCPが依然として資格情報の処理、権限境界、監査ログのための制御されたゲートウェイを提供すると主張しています。これらは生のAPIやCLIアクセスにはない機能です。

「MCPを使うと、エージェントがアクセスできる外部サービスを正確に制御し、APIキーを公開せずに認証を処理し、強力な監査ログを提供することが容易になります」 – @simonw。

エンタープライズレベルのツールとプラグインストア

ビジネスユーザーは、ChatGPT/ClaudeマーケットプレイスにあるワンクリックMCPプラグインに依存しており、これらは認証とUI統合をバンドルしています。

「MCPが勝っているのは、ChatGPTアプリとClaudeアプリの中にプラグインストアがあるからです。これらのプラグインは、認証をサポートしたワンクリックインストールのMCPサーバーです」 – @whazor。

リモートコントロールシナリオ

エージェントが公開APIを持たないUI専用アプリケーションやデバイスと対話する必要がある場合、MCPサーバーはソケットレベルのコマンドプロトコルを公開できます。

「MCPサーバーは、それ以外に『アクセスポイント』を持たないUIアプリケーション（ゲームエンジンエディターなど）をリモートコントロールする場合には、依然として非常に理にかなっています」 – @flohofwoe。

直接HTTPまたはCLIがMCPに勝る場合

ステートレスで文書化されたRESTエンドポイント – エージェントはAccept: text/markdownヘッダー（または類似のもの）を添付して、追加のスキーマなしに簡潔でエージェント向けの応答を受け取ることができます。
大きなJSONペイロード – jqやcurlをサイズ制限付きで使用することで、エージェントはデータを反復的にフィルタリングでき、冗長なMCP応答によるトークン爆発を回避できます。
セキュリティ最優先の環境 – 集中型の認証と権限システムをAPIゲートウェイに直接組み込むことができ、追加のMCPレイヤーが不要になります。

「エージェントがHTTP APIを直接使用する方法を標準化し始めるべきです。例えば、エージェントクライアントは自分自身をエージェントとして識別するヘッダーを添付し、サーバーは自動的に応答データをMarkdownやテキストとして送信できるようにするなどです」 – 著者。

新興プラクティスの実例

Accept-Markdownヘッダー – ドキュメントサイトは現在、Accept: text/markdownを尊重してHTMLの代わりにレンダリングされたMarkdownを配信し、トークン数を削減しています。
SDK選択のためのAccept-Language – VercelとShopifyは言語設定を使用して言語固有のSDK例を提供し、エージェントにとっての関連性を向上させています。

今後の道筋 – 二者択一ではない

コミュニティのコンセンサスは微妙です：

独自の価値を提供する場所ではMCPを維持する – 制御された資格情報処理、レガシーUI自動化、エンタープライズプラグインエコシステム。
単純でステートレスなサービスではMCPを段階的に廃止する – エージェントが--helpで発見できる直接HTTP呼び出しやCLIツールに置き換えます。
エージェント向けHTTPを標準化する – ヘッダー（例：User-Agent: agent/1.0）やコンテンツネゴシエーション形式を導入して、APIをMCPツールと同じくらいLLMが消費しやすくします。

結論

MCPは初期のLLMにとって実用的な橋渡しでしたが、モデル能力の急速な向上、コード生成ツールの台頭、MCPサーバー維持のオーバーヘッドにより、費用対効果のバランスは変化しました。組織は、MCPが依然として実際の問題（安全な資格情報仲介やリモートUI制御など）を解決するかどうかを評価し、そうでない場合は、よりシンプルで高性能でコンテキスト肥大化しにくい直接HTTPまたはCLIアプローチを採用すべきです。