なぜMCPは常に悪いアイデアだったのか

なぜMCPは常に悪いアイデアだったのか

最近、MCPの世界における最新かつ最高の技術に焦点を当てた終日イベントに参加しました。発表者は皆素晴らしく、自分たちの仕事に情熱を持っているように見えましたが、正直に言って私はMCPにうんざりしています。MCPは、LLMがあまり賢くなかった時代のために作られたひどいプロトコルであり、私たちはそれをとうに卒業しました。

［画像: はっきりさせておこう、君はMCPが悪いアイデアだと思うのか？ 私はそう思うし、そうでないふりをすることにうんざりしている。］

簡単な歴史

MCPは2024年11月にAnthropicチームによってリリースされたプロトコルで、エージェントが外部サービスやデータソースに接続できるように設計されました[1]。当時のモデルは、少なくとも現在のものと比較すると、まだ比較的原始的でした。当時はClaude Codeさえなく、汎用的なエージェントワークフローははるかに信頼性が低かったです。

ユーザーはAIモデルに外部サービスへのアクセスを許可することの有用性を見出し始めました。それは、これまで見たことのないレベルの生産性を可能にしました。MCPの採用は爆発的に増加し、経済全体でのLLM採用の同様の、あるいはそれ以上の爆発的な成長と一致しました。

時間の経過とともに、MCPはAnthropicの管理下で進化を続け、2025年にはLinux Foundation傘下のAgentic AI Foundationに寄贈されました[2]。

MCP産業複合体

採用が大幅に増加するにつれて、ユーザーはセットアップに多くのMCPサーバーを追加し始め、コンテキストの肥大化問題に直面し始めました。各サーバーには複数のツールがあり、それぞれが独自のスキーマを持っているため、これらのモデルのコンテキストが過負荷になり始めました。Harnessの開発者は、Composio、MintMCP、Pipedreamのようなプラットフォームが提供する汎用的な検索/実行パターンを含む、多くの回避策を見つけました。これらはすべて、さまざまな外部サービスへの認証情報を一元化し、エージェントに最小限のツールセット（コンテキストの肥大化を減らすため）を提供してアクセスできるようにするという問題を効果的に解決します。これは短期的な良いことだと明確に言いたいと思います。

MCPを中心に構築してきたすべてのものの中で、私たちが考慮に入れなかった、あるいは無視してきたのは、モデルの改善です。現在、MCPサーバーを監視し、応答が良好であることを確認し、エージェントがツールに容易にアクセスできることを確認し、スキーマを特定し、適切なタイミングで適切な判断を下すためにエージェントに何を提供する必要があるかを判断するための、専用のシステム全体があります。

サプライズ、サプライズ、大手の研究所は正しかった

モデルは改善しました。それらは現在、コンピュータ上でコードを実行し、大規模なコードベースについて推論し、以前よりもはるかに自律的に動作できるようになっています。その作業の大きな部分は、コーディング目的のスクリプトの作成/実行でした。副作用（しかし、それは副作用なのでしょうか？）は、それらが現在、APIを直接呼び出すのが得意になったことです。それらはスクリプトを作成し、複数の異なるサービスを構成し、最小限のユーザー介入で有用なワークフロー全体で、以前見たことのないAPIを呼び出すことができます。

LLMはこの点で非常に優れているため、CloudflareでさえCode Modeをローンチしました。これは、LLMがさまざまな呼び出しをサンドボックスで実行できるスクリプトに構成することでMCPを使用するより良い方法です[3]。

しかし、それ以上に、LLMは--helpコマンドを使用してCLIを発見する方法を見つけました。そのため、多くのサービスにアクセスするためにMCPサーバーを必要としなくなりました。これらのサービスは、文書化されたAPIまたはCLIを通じて利用可能です。ほとんどのリモートサービスMCPサーバーは、最終的に既存のAPIをラップしています。

これからどうするか？

ほとんどのMCPサーバーを削除します。それだけです。ターミナルアクセスを備えたエージェントは、ほとんどのMCPサーバーを置き換えることができ、多くの場合、より高機能です。CLIが機械可読な応答（JSON/XMLなど）を返す場合、それらは非常に冗長でトークン使用量が多くなるという問題はまだありますが、これらを修正する方法はあります。

代替手段の多くはすでに存在します。文書化されたHTTP API、標準的なコンテンツネゴシエーション、成熟した認証メカニズムです。

エージェントがHTTP APIを直接使用する方法を標準化する必要があります。たとえば、エージェントクライアントは、エージェントとして識別するためにヘッダーを添付でき、サーバーは自動的にHTMLや冗長なJSONではなくMarkdownまたはテキスト形式の応答データを送信できます。

いくつかの実際の例

1. Accept Markdown ヘッダー

   特にドキュメントサイトのようなテキスト中心のサイトで、LLMフレンドリーなサーバーが増加しており、Accept: text/markdown ヘッダーを尊重しています。これらのサーバーは、通常送信するHTML応答の代わりに、レンダリングされたMarkdownファイルを自動的に送信できます。メディアタイプ自体は標準化されており、エージェント指向のコンテンツネゴシエーションに使用することは採用が進んでいます。

2. Accept-Language ヘッダーを使用するドキュメントサイト

   最近、Vercelのエンジニアが、クライアントが好むプログラミング言語を送信するようにハーネスに依頼しました。これにより、ドキュメントサイトはより具体的な例を提供できるようになります。たとえば、Pythonを追加すると、Python SDKのドキュメントが優先され、汎用的なものが送信されるのを防ぐことができます。ShopifyのTobi Lutkeはこれを非常に気に入ったため、現在Shopifyのドキュメントに搭載されています。

Malte Ubl (@cramforce): ハーネスへのリクエスト： “Accept: text/markdown” を送信してくれるようになったのは素晴らしいです。次にやりたいのは、好みのプログラミング言語をAccept-Languageヘッダーに含めることです。

Tobi Lutke (@tobi): 素晴らしいアイデアです。Shopifyのドキュメントでこれをサポートします。

締めくくり

共通のプロトコルを中心に標準化することで、インターネットは今日の姿になりました。MCPは今や過去の時代のプロトコルです。エージェントは賢く、スクリプトを作成し、欲しいものを正確に尋ねることができます。MCPの迷宮をさらに進むのではなく、それを終息させ、必要なインターフェースをすでに提供しているHTTP APIとCLIに直接依存する時が来たと私は言います。

引用

1. Anthropic, “Introducing the Model Context Protocol”, November 25, 2024. ↩
2. Anthropic, “Donating the Model Context Protocol and establishing the Agentic AI Foundation”, December 9, 2025. ↩
3. Kenton Varda and Sunil Pai, “Code Mode: the better way to use MCP”, Cloudflare Blog, September 26, 2025. ↩