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

なぜMCPは常に悪いアイデアだったのか 最近、MCPの世界における最新かつ最高の技術に焦点を当てた終日イベントに参加しました。発表者は皆素晴らしく、自分たちの仕事に情熱を持っているように見えましたが、正直に言ってMCPにはうんざりしています。MCPは、LLMがあまり賢くなかった時代のために作られたひどいプロトコルであり、私たちはそれをとうに超えてしまいました。 MCPの簡単な歴史 MCPは2024年11月にAnthropicチームによって、エージェントが外部サービスやデータソースに接続するのを助けるために設計されたプロトコルとしてリリースされました。当時のモデルは、現在のものと比較するとまだ比較的原始的でした。Claude Codeすらなく、汎用的なエージェントワークフローははるかに信頼性が低かったです。ユーザーはAIモデルに外部サービスへのアクセスを許可することの有用性を見始めました。それは、これまで見たことのないレベルの生産性を可能にしました。経済全体でのLLM採用の同様か、それ以上に爆発的な成長と一致して、MCPの採用が爆発的に増加しました。時が経つにつれて、MCPはAnthropicの管理下で進化を続け、2025年にはLinux Foundation傘下のAgentic AI Foundationに寄贈されました。 MCP産業複合体 採用の巨大な成長に伴い、ユーザーはセットアップに多くのMCPサーバーを追加し始め、コンテキストの肥大化問題に直面し始めました。各サーバーには複数のツールがあり、それぞれが独自のスキーマを持っており、これらすべてのモデルのコンテキストを過負荷にし始めました。Harnessの開発者は、Composio、MintMCP、Pipedreamのようなプラットフォームが提供する汎用的な検索/実行パターンを含む、多くの回避策を見つけました。これらはすべて、さまざまな外部サービスへの認証情報を配置する場所を1つにし、エージェントが使用できる最小限のツールセット（コンテキストの肥大化を減らすため）を提供することで、問題を効果的に解決します。これは短期的に良いことだと明確にしたいです。MCPの周りに構築されたすべてのものの中で、私たちが考慮に入れなかった、あるいは無視したかもしれないのは、モデルがより賢くなることです。現在、MCPサーバーを監視し、応答が良いことを確認し、エージェントがツールに簡単にアクセスできることを確認し、スキーマを特定し、適切なタイミングで正しい判断を下すためにエージェントに何を提供する必要があるかを判断するためのシステム全体があります。 驚き、驚き、大手の研究所は正しかった モデルはより賢くなりました。それらは現在、コンピューター上でコードを実行し、大規模なコードベースについて推論し、以前よりもはるかに自律的に動作することができます。その作業の大きな部分は、コーディング目的のスクリプトの作成/実行でした。副作用（しかし、それはそうでしょうか？）は、それらが現在、APIを直接呼び出すのが得意になったことです。それらはスクリプトを作成し、複数の異なるサービスを構成し、ユーザー側からの最小限の介入で有用なワークフロー全体で、以前見たことのないAPIを呼び出すことができます。LLMはこの点で非常に優れているため、CloudflareはMCPをより良く使用する方法であるCode Modeを立ち上げました。これは、LLMがさまざまな呼び出しをサンドボックスで実行できるスクリプトに構成するものです。しかし、それ以上に、LLMは--helpコマンドを使用してCLIを発見する方法を見つけました。そのため、ドキュメント化されたAPIまたはCLIを通じて利用可能な多くのサービスにアクセスするためにMCPサーバーを必要としなくなりました。ほとんどのリモートサービスMCPサーバーは、最終的に既存のAPIをラップしています。 これからどうするか？ MCPサーバーのほとんどを削除します。それだけです。ターミナルアクセスを持つエージェントは、ほとんどのMCPサーバーを置き換えることができ、しばしばより強力です。 CLIが機械可読な応答（JSON/XMLなど）を返すという問題はまだいくつかありますが、これらはトークン使用量が多く、非常に冗長になりがちですが、修正する方法はあります。代替手段の多くはすでに存在します：ドキュメント化されたHTTP API、標準的なコンテンツネゴシエーション、成熟した認証メカニズムです。エージェントがHTTP APIを直接使用する方法を標準化すべきです。たとえば、エージェントクライアントは、エージェントであることを示すヘッダーを添付でき、サーバーは自動的にMarkdownまたはテキスト形式で応答データを送信できます。HTMLや冗長なJSONの代わりに。 いくつかの実際の例 Accept Markdown Header 特にドキュメントサイトのようなテキスト中心のサイトでは、LLMフレンドリーなサーバーが増加しており、Accept: text/markdownヘッダーを認識します。これらのサーバーは、通常送信するHTML応答の代わりに、レンダリングされたMarkdownファイルを自動的に送信できます。メディアタイプ自体は標準化されており、エージェント指向のコンテンツネゴシエーションに使用することは採用が進んでいます。 Accept-Language Headerを使用するドキュメントサイト 最近、Vercelのエンジニアは、クライアントが好むプログラミング言語を送信するようにHarnessに依頼しました。これにより、ドキュメントサイトはより具体的な例を提供できるようになります。たとえば、Pythonを追加すると、一般的なものを送信する代わりにPython SDKのドキュメントを優先できます。ShopifyのTobi Lutkeはそれを非常に気に入ったため、現在Shopifyのドキュメントに搭載されています。 Tobi Lutke (@tobi): Great idea. Will support this on Shopify docs. 締めくくり 共通プロトコルを中心とした標準化は、インターネットを今日の姿に成長させました。MCPは今や過去の時代のプロトコルです。エージェントは賢く、スクリプトを作成し、欲しいものを正確に尋ねることができます。MCPの迷宮をさらに進むのではなく、それを終わりにし、必要なインターフェースを提供している場所ではHTTP APIとCLIに直接依存する時が来たと私は言います。 引用 Anthropic, “Introducing the Model Context Protocol”, November 25, 2024. ↩ Anthropic, “Donating the Model Context Protocol and establishing the Agentic AI Foundation”, December 9, 2025. ↩ Kenton Varda and Sunil Pai, “Code Mode: the better way to use MCP”, Cloudflare Blog, September 26, 2025. ↩