AnthropicがMCPを発表したのは2024年11月25日。18ヶ月が経った今、プロトコルはLinux Foundation傘下に入り、SDKのダウンロード数は月9,700万件、登録サーバー数は1万を超えました。 ところが同じ期間に、Garry TanはXに「MCP sucks」と書き込み、Perplexity CTOのデニス・ヤラツはAsk 2026カンファレンスで「内部的にMCPを外してREST APIとCLIに戻る」と発表しました。 死んだわけじゃないんです。ただ、「デフォルト」の座から降りたというのが、18ヶ月を振り返ったときの核心です。

一目でわかる
2024.11 リリース → 大手ベンダー採用 → トークン・セキュリティの壁 → 2026.3 バックラッシュ → レイヤード化された未来

18ヶ月間、何があったのか?

MCPの採用カーブは異例なほど速かったです。2025年3月にOpenAIがAgents SDK・Responses APIでMCPを正式サポートし、同月Streamable HTTPトランスポートが導入されたことでリモートサーバーの運用が実質的に可能になりました。 その後、6月のGoogle I/OでGeminiが、Build 2025でMicrosoftがWindows 11の「基盤レイヤー」と宣言し、2026年3月にはAWSがBedrock AgentCore Runtimeで14リージョンにstateful MCPサーバー機能を展開しました。12月にはAnthropicがMCPをLinux Foundation傘下のAgentic AI Foundationに寄贈しました。

単一ベンダー → 中立ガバナンス＋主要クラウド全採用。この組み合わせが18ヶ月で出来上がったのは異例です。

数字で見るとさらに明確です。

  1. 9,700万
    Python・TypeScript SDKの月間ダウンロード合計。
  2. 10,000+
    登録されたMCPサーバー数。MCP Registryには約2,000件がインデックスされています。
  3. 150+
    A2A(Agent2Agent)プロトコルを支持する組織数。MCPと並んで成長している補完的な標準です。

そして2026年1月にはMCP Appsがリリースされ、テキストベースだったプロトコルがインタラクティブUIまで拡張されました。Amplitude・Asana・Box・Canva・Figma・Slack・Salesforceがローンチパートナーとして加わりました。

では、なぜ突然バックラッシュが起きたのか?

2026年2月28日、Eric Holmesの「MCP is dead. Long live the CLI.」という投稿が発端でした。3月11日、Y CombinatorのGarry TanがXに「MCP sucks honestly — コンテキストウィンドウを食い尽くして、認証もめちゃくちゃだ」と直撃し、自ら作ったCLIラッパー「gstack」を公開しました。 数日後、Perplexity CTOのデニス・ヤラツがAsk 2026で「MCP内部利用を外す」と公式化しました。 批判は感情的なものではありません。3つの運用の壁から測定された結果です。

運用の壁 測定された問題 代替パターン
トークンオーバーヘッド サーバー3つ接続時、200Kコンテキストの72%を消費。ツール選択精度43% → 14% Skills(段階的開示) + Cloudflare Code Mode (-98%トークン)
セキュリティのデフォルト スキャンされた1,862件の公開サーバーのうち119件すべてが無認証。41%が認証なし Gateway + OAuth 2.1 + CIMD義務化
リモートスケーリング statefulセッション、水平スケーリング、ゲートウェイ動作が未定義 AWS AgentCore式stateless streamable-HTTP

トークンオーバーヘッドの数字は衝撃的です。2025年に発表されたMCPGAUGE論文は、「MCP統合が平均精度を9.5ポイント下げ、入力トークン量を3.25倍〜236.5倍まで増やす」と報告しています。 同じ200Kコンテキストのモデルで、GitHub・Playwright・IDEサーバーの3つを繋ぐだけで143Kがツール定義で埋まってしまいます。本作業が始まる前に30%しか残らないんです。

「context rot」— ツールが増えるほどモデルが迷子になります。ツール選択精度が43%から14%未満に落ちました。

セキュリティはさらに深刻です。Knosticが2026年初頭にスキャンした1,862件のインターネット公開MCPサーバーのうち119件を検証してみると、すべて無認証で内部ツールリストへのアクセスが可能でした。 Bitsightは約1,000件の認証なしサーバーを発見し、別の分析では518件のサーバーのうち41%が認証なしでした。Cloudflareの公式ガイドも「without authentication」デプロイを正常なオプションとして提示しています。運用衛生の問題です。

注意 — stdioモードとHTTPモードは区別して見る必要があります
ローカルstdio MCPの問題(トークン・セキュリティ)は実在します。ただし、エンタープライズ向けリモートHTTP MCPは話が違います。Slack/Cursor/Claude Code/社内アシスタントが同じサーバーを呼び出すとき、OAuth・Audit・Telemetryを1か所で強制できるのはMCPだけです。「MCPが死んだ」ではなく、「どのモードを使うか」の問題として見るべきです。

では、今どう選べばいいのか?

現実で最も実用的な組み合わせは、CLI + RESTful + Skills + 選択的MCPです。 判断の流れはこうです。

  1. ローカルのシングルユーザーワークフローか?
    Yes → CLIまたはSkills。モデルはすでにgit/curl/jq/awsを知っています。MCPはオーバーヘッドになります。
  2. 自分でクライアントとツールの両方を持っているか?
    Yes → REST API。統合標準は必要ありません。No → 次の質問へ。
  3. 複数のホスト(Cursor、Claude、ChatGPT)で同じツール・ポリシーを使いたいか?
    Yes → リモートHTTP MCP。統合1回/使用N回。これがMCPが本当に活躍する領域です。
  4. エンタープライズでOAuth・SSO・Auditが必要か?
    Yes → MCP + WorkOS/Glean式Gatewayパターン。認証標準が保証されます。

興味深いのは、Cloudflareが発表した「Code Mode」です。ツール定義をあらかじめすべて読み込まず、エージェントが動的に発見・呼び出せるようにすることで、トークン使用量を98%以上削減しました。 これがSEP-1576（「Mitigating Token Bloat in MCP」）の方向性です。段階的開示（progressive disclosure）、スキーマの重複排除、tool search。これらのパターンがデフォルトになれば、MCPの最初の運用の壁は崩れます。

そして2026年4月2〜3日にニューヨークでMCP Dev Summitが開催されます。AAIF・Linux Foundation主催、主要クラウドベンダー全社がスポンサーとして加わりました。 開発者の感情は揺れても、ガバナンスとエコシステムへの投資は別の時間軸で動いているというシグナルです。

さらに深掘りしたい人へ

WorkOS — Everything Your Team Needs to Know About MCP in 2026 アーキテクチャ/認証/2026ロードマップまで一度に整理。CIMD vs DCR、非同期Tasks、MCP Appsをすべてカバー workos.com

PerplexityがMCPを外した理由 コンテキスト72%消費、ツール選択精度43%→14%、Skillsの段階的開示との比較 dev.to

MCP Isn't Dead. But It's Not the Default Answer Anymore. Garry Tan/Eric Holmes/Perplexityの批判の出典とトークンオーバーヘッド9.5ポイントの精度低下測定の根拠 medium.com

Glean — When MCP Adds Real Value vs When CLI Is Enough ローカルstdio vs エンタープライズHTTP MCPの違い、「統合1回使用N回」パターンが本当の価値である理由 glean.com