MCP が最初から悪いアイデアだった理由

最近、MCP 界隈の最新かつ最高の取り組みをテーマにした終日イベントに参加しました。すべての発表者が素晴らしく、自分たちの仕事に情熱を注いでいるように見えましたが、正直なところ私は MCP にうんざりしています。LLM がそれほど賢くなかった時代のために作られたひどいプロトコルであり、私たちはすでにそれを超えています。

簡単な歴史

MCP は 2024 年 11 月に Anthropic チームによって、エージェントが外部サービスやデータソースに接続するのを助けるプロトコルとしてリリースされました。当時のモデルは、現在私たちが持っているものと比較すると、まだ比較的原始的でした。まだ Claude Code はなく、汎用的なエージェント ワークフローは現在よりもはるかに信頼性が低かったです。ユーザーは、自分の AI モデルに外部サービスへのアクセスを与える有用性を認識し始めました。これにより、これまで見たことのないレベルの生産性が可能になりました。MCP の採用が爆発的に増加し、経済全体における LLM 採用の同様に、あるいはそれ以上に爆発的な増加と時を同じくして起こりました。時間の経過とともに、MCP は Anthropic の管理下で進化を続け、最終的に 2025 年に Linux Foundation 傘下の Agentic AI Foundation に寄贈されました。

MCP 産業複合体

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

MCP を中心に構築してきたすべてのものとともに、私たちが考慮に入れていなかった、あるいは無視していたのは、モデルが向上しているという事実です。現在、MCP サーバーを監視し、レスポンスが良好であることを確認し、エージェントがツールに簡単にアクセスできるようにし、スキーマを把握し、エージェントが適切なタイミングで適切な呼び出しを行えるようにするために何を提供すべきかを決定する、専用のシステム全体が存在します。

驚き、驚き、大手研究所は正しかった

モデルは向上しました。今ではコンピューター上でコードを実行し、大規模なコードベースについて推論し、これまで以上に自律的に振る舞うことができます。その作業の大部分は、コーディング目的でスクリプトを書いたり実行したりすることでした。副作用（果たして副作用なのか？）として、今では直接 API を呼び出すのが得意になっています。スクリプトを書き、複数の異なるサービスを組み合わせ、これまで見たことのない API を呼び出すことができ、すべてユーザー側の最小限の介入で有用なワークフローの中で実行できます。

LLM がこの点で非常に優れるようになったため、Cloudflare は Code Mode をローンチしました。これは、LLM がさまざまな呼び出しをサンドボックスで実行可能なスクリプトに組み立てることで、MCP をより良く使用する方法です。しかし、それよりもさらに優れているのは、LLM が `--help` コマンドを使って CLI を発見する方法を理解したことです。したがって、ドキュメント化された API や CLI を通じて利用可能な多くのサービスにアクセスするために、もはや MCP サーバーは必要ありません。ほとんどのリモート サービス MCP サーバーは、最終的に既存の API をラップしているに過ぎません。

今後どうするか？

ほとんどの MCP サーバーを削除します。それだけです。ターミナル アクセスを持つエージェントは、ほとんどの MCP サーバーを置き換えることができ、多くの場合より高性能です。

まだいくつかの問題があります。CLI が機械可読なレスポンス（JSON/XML など）を返す傾向があり、それらは非常に冗長でトークン使用量が多くなりますが、これを修正する方法はあります。代替手段の大部分はすでに存在します：ドキュメント化された HTTP API、標準的なコンテンツ ネゴシエーション、成熟した認証メカニズム。エージェントが HTTP API を直接使用する方法を標準化し始めるべきです。例えば、エージェント クライアントはヘッダーを付けて自分をエージェントとして識別し、サーバーは HTML や... の代わりに Markdown やテキストとしてレスポンス データを自動的に送信できるようになります。