目次
拡散している主張
2026年3月、Perplexityの動きをきっかけに、X・Medium・DEV.toなどで次のような主張が一気に拡散した。
「PerplexityがMCPを捨ててAPI/CLIに戻った」「MCPはコンテキストの72%を浪費する」「Garry Tan（YC）もCLIを自作した」「MCPという『標準』はもう死につつある」——だからMCPに賭けるのは間違いだ。
主張には事実の核がある一方、結論部分には飛躍もある。一次情報と最新データに当たって、構成要素ごとに切り分ける。
検証1: Perplexityは本当にMCPを捨てたか
Perplexity CTO Denis Yarats が、社内でMCPから従来型API/CLIへ軸足を移すと表明。
Yaratsは2026年3月11日の自社カンファレンス「Ask 2026」で、社内ではMCPから従来型のAPIとCLIツールへ移行すると述べた。理由はコンテキストウィンドウの消費過多と認証フローの煩雑さの2点。代替の中核は2026年2月に一般提供を開始した「Agent API」で、OpenAI互換構文の単一エンドポイントからOpenAI・Anthropic・Google・xAI・NVIDIAのモデルへルーティングする。
ここで重要なのは 「社内ワークロードでの転換」 であって、MCPを外部に向けて否定したわけでも、業界に「やめろ」と呼びかけたわけでもない点だ。Perplexityのように単一の自社プロダクトに対し高頻度・低レイテンシで叩くユースケースでは、汎用プロトコルより専用APIが効率的になりうる——これは合理的な自社最適化であって、標準の死とは別の話だ。
検証2: 「72%コンテキスト浪費」は本当か
MCPはエージェントがユーザーメッセージを処理する前に利用可能コンテキストの最大72%を消費する。
Yaratsは「ユーザーメッセージ処理前にMCPが最大72%のコンテキストを消費しうる」と述べた。ある開発者は200Kトークン中143K（72%）使用、うちツールメタデータが82Kという報告もしている。各ツールの説明・パラメータスキーマ・レスポンス形式をすべて常時コンテキストに展開する設計が原因だ。
この数字は 多数のMCPサーバーを同時接続し、ツール定義を最適化していない場合の上限に近い。逆に言えば、接続するサーバーを絞る・ツール定義を遅延ロードする・スキーマを簡潔にする、といった運用で大きく下がる。「MCP固有の不可避なコスト」というより「運用設計とサーバー実装の問題」という側面が強い。KanseiLinkでもコンテキスト肥大化の主張を別途検証しており、メタデータ設計が成功率とトークン効率に直結することを実測で確認している。
検証3: 大手は軒並みCLIに戻っているか
Garry Tan（YC）もCLIを自作。大手は軒並みMCPからCLIへ回帰している。
Y CombinatorのGarry Tan氏がMCPではなくCLIを自作したと報じられているのは事実だ。しかし「軒並み」と一般化するのは誇張で、同時期に多くのプラットフォームがMCP対応を新規追加している。
むしろ2026年は大手のMCP採用が加速した年だ。Claude（ネイティブ）、ChatGPT（Apps SDK / Connectors）、Google Gemini API・Vertex AI Agent Builder（2026年3月対応追加）、Cursor・Windsurf・Zed・JetBrains AI Assistant、Vercel AI SDK、OpenAI Agents SDKがいずれもMCPをサポートしている。「大手が離れている」と「大手が新規対応している」が同時に観測されているのが実態で、前者だけを切り取ると像を誤る。
検証4: MCPは死につつあるか
MCPという「標準」はもう死につつある。
採用指標はいずれも右肩上がりだ。MCP SDKの月間ダウンロードは2026年3月時点で約9,700万件（ローンチ時10万件から約970倍）。公開レジストリの登録サーバーは9,400超。エンタープライズでは2026年4月時点で78%のAIチームが本番でMCPベースのエージェントを少なくとも1つ運用していると報告されている。
MCP採用指標（2026年）— 「死」とは逆方向
ダウンロード(3月)
サーバー数
を持つ企業(4月)
DL増加倍率
決定打は ガバナンスの移行だ。AnthropicがMCPをLinux Foundationに寄贈し、OpenAI・Google・Microsoftが共同スポンサーに加わったことで、MCPは「Anthropicのプロトコル」から業界中立のインフラへと位置付けが変わった。寄贈と複数大手の共同スポンサー化は、衰退しつつある標準には起こらない動きだ。
「コンテキスト浪費」という批判は正当で、だからこそ2026年のMCPロードマップはスケーラビリティ・エンタープライズ認証・ガバナンスを重点に据え、ツール定義の効率化が議論されている。本サイトのMCP仕様リリース候補（2026-07-28）解説も参照。批判は死の兆候ではなく、進化のドライバーだ。
総合判定とSaaS/開発者への示唆
4つの構成要素を切り分けた結果はこうだ。
| 主張 | 判定 | 根拠の要点 |
|---|---|---|
| Perplexityが社内でMCPから転換 | ✅ 本当 | Ask 2026 (3/11)で表明、Agent APIへ |
| 72%コンテキスト浪費 | ⚠️ 条件付き | 最悪条件の上限。運用設計で大きく低減 |
| 大手が「軒並み」CLI回帰 | ⚠️ 誇張 | 個別事例は事実だが、新規対応も多数 |
| MCPは死につつある | ❌ 誇張 | SDK 9,700万DL、LF寄贈、採用加速 |
総合すると、この主張は 「事実の核を持つが、結論を過剰一般化した『誤解を招く』タイプ」だ。離脱の事例と技術的批判は本物だが、そこから「MCPは終わり」を導くのはデータと整合しない。正しい問いは「MCPかCLIか」ではなく 「どのワークロードに何を選ぶか」である。
- 単一ベンダー・高頻度・低レイテンシの定型処理 → 専用API/CLIがコンテキスト効率で勝ちうる（Perplexityの自社用途型）
- 多数の異種SaaS横断・発見可能性・標準認証・エコシステム互換が要る → MCPが優位
- MCPを使うなら: 接続サーバーを絞る、ツール定義を簡潔に、メタデータ肥大を監視する（72%問題への実務的対処）
- SaaS提供側: 「MCP対応した」だけで満足せず、ツール定義のトークン効率と発見可能性を実測で管理する
MCPは死んでいない。むしろ批判を取り込んで仕様が進化する成熟フェーズに入った。バズった「MCP終焉論」は、技術的に正当な指摘を過剰な結論に膨らませた典型例であり、意思決定はワークロード適合で行うべきだ。
FAQ
Q1. PerplexityはMCPを完全に捨てたのか?
完全放棄ではなく社内主力からの転換。CTO Denis YaratsがAsk 2026(2026/3/11)でAPI/CLIへの移行を表明し、Agent API(2月GA)を中核に据えた。理由はコンテキスト消費過多と認証煩雑さ。標準の否定ではなく特定ワークロードの自社最適化。
Q2. 「72%コンテキスト浪費」は本当?
条件付きで本当。多数サーバー同時接続・ツール定義未最適化という最悪条件の上限値。ある報告では200K中143K使用(うちメタデータ82K)。接続を絞り定義を最適化すれば大幅に下がるため、不可避コストでなく運用設計の問題という側面が強い。
Q3. 大手は軒並みCLIに戻っている?
誇張。Garry Tan(YC)のCLI自作など個別事例は事実だが、同時期にGemini API/Vertex(3月)、ChatGPT、Cursor等が新規対応。離脱と新規採用が並行して起きており「軒並み」ではない。
Q4. MCPは死につつある?
誇張。SDK月間DL 9,700万(970倍/18ヶ月)、登録サーバー9,400超、企業78%が本番運用。AnthropicがLinux Foundationへ寄贈しOpenAI/Google/Microsoftが共同スポンサー。衰退する標準には起きない動き。
Q5. 結局MCPとCLIどちらを使うべき?
ワークロード適合で判断。単一ベンダー高頻度低レイテンシは専用API/CLI有利、多数SaaS横断・発見可能性・標準認証が要るならMCP有利。二者択一ではない。
本記事の事実主張はWebSearchで取得した二次情報に基づく。Perplexity CTO Denis Yaratsの発言（Ask 2026、2026年3月11日、コンテキスト消費過多・認証煩雑さ・72%・Agent API）はAwesomeAgents・Repello AI・byteiota・agent-engineering.dev等の報道に基づく。「200K中143K使用・メタデータ82K」は個別開発者の報告例で、全環境を代表する数値ではない。MCP採用指標（SDK月間9,700万DL・970倍・登録サーバー9,400超・企業78%本番運用・Linux Foundation寄贈・Gemini/Vertex 3月対応）はdigitalapplied・effloow・cdata等の集計に基づき、出典により数値の定義・時点が異なる場合がある。Garry Tan氏のCLI自作は報道ベースで一次確認は限定的（⚠️）。判定（✅⚠️❌）は2026年5月26日時点で利用可能な公開情報に基づく編集判断であり、状況は変化しうる。本番判断時は各一次情報の最新版をご確認ください。