目次
炎上したクレームの中身
2026年3月11日、Ask 2026カンファレンスでPerplexity CTO Denis Yaratsが「社内的にAnthropicのMCPからAPI・CLIへ移行している」と表明した。理由は2つ——(1) MCPツール定義がエージェントが仕事を始める前にコンテキスト窓の40-50%を消費すること、(2) 複数サービス接続時の認証フローの摩擦。発言はThreadsとSNSで急速に拡散し、「MCPはもう終わり」「標準が死んだ」というハッシュタグ的な反応が連鎖した。
同じ時期、Merge CTO Gil Feigも独立に「典型的なデプロイ構成ではツールメタデータが利用可能コンテキストの40-50%を占める」と推計を公表。さらに「ある開発者は4 MCPサーバー接続済みでプロンプト入力前に約7,000トークン、ヘビーな構成では66,000トークン(Claude Sonnetの200kコンテキスト窓の約1/3)を会話開始前に消費していた」という実測も観測された。
クレームは3つに整理できる。一つずつ、利用可能な実測値で検証する。
クレーム①「ツール定義は40-50%を食う」
マルチサーバー前提の典型構成では正しい。シングルサーバー・キュレーションされた構成では当てはまらない。
実測ベースで何がトークンを食っているのか。複数の独立した報告が、似た数字に収束している。
| MCPサーバー / 構成 | ツール数 | 定義トークン | 200kコンテキスト比 |
|---|---|---|---|
| GitHub 公式MCP | 94 | ~17,600 | ~8.8% |
| Atlassian 公式MCP(Jira + Confluence) | — | ~10,000 | ~5.0% |
| 大型サーバー複数接続 | — | 30,000+ | ~15%以上 |
| 4サーバー軽量構成(典型例) | — | ~7,000 | ~3.5% |
| ヘビー構成(報告された極端例) | — | ~66,000 | ~33% |
40-50%という数字は絶対値ではなくレンジとして読むべきだ。大型サーバーを複数接続すれば容易にそこへ届く。GitHub MCPだけで94ツール・17.6kトークン消費するため、AtlassianやSlackと並べれば30k+に達する。一方、KanseiLink MCPのようにcompact: trueモードを提供しているサーバーや、サーバーを1-2個に絞った構成なら数千トークン台に収まる。
「MCPは40-50%食う」は『何でも全部入りで接続するとそうなる』という条件付きの真実だ。プロトコルの本質的な欠陥ではなく、運用設計の問題。同じMCPサーバーでも、サーバー選定とツールキュレーション次第で消費トークンは1桁変わる。
クレーム②「MCPはもう終わり」
Perplexity 1社の判断は業界の撤退ではない。むしろ標準は欠点を直しながら広がっている。
「MCPはもう終わり」「標準が死んだ」というSNSの反応は、Perplexity 1社の社内判断を業界全体の傾向に拡大解釈している。事実関係を整理する。
- 採用は広がり続けている — MCPは2024年11月にAnthropicがオープンソース化して以来、OpenAI、Google DeepMind、Microsoft、Cursor、Atlassian、ServiceNow、Salesforce、Linear、GitHubなど多数のエンタープライズプラットフォームに採用されている。2026年4月にはLinux Foundation傘下のAAIF(AI Agent Interoperability Foundation)に寄贈され、ベンダー中立のオープン標準化が進んだ。
- 欠点を直す動きが進行中 — MCP公式リポジトリで SEP-1576: Mitigating Token Bloat in MCP — Reducing Schema Redundancy and Optimizing Tool Selection が議論されており、スキーマ冗長性削減と動的ツール選択の標準化が進んでいる。
- 圧縮ツールが既に存在 — Atlassianの
mcp-compressorは呼び出し方法を変えずにツール記述オーバーヘッドを70-97%削減すると報告されている。AnthropicのMCP公式ガイダンスにあるcode modeは、ツールを直接呼ぶのではなくコード経由で呼ぶことで最大98.7%のコンテキストオーバーヘッド削減を測定している。 - 離脱は1社・1ユースケース — Perplexityの離脱は、検索プロダクトという特定ユースケースで API + CLI の方が経済的だったという判断であり、「MCPが構造的に終わった」とは別の話だ。
プロトコルが死んでいるのではなく、『何でも全部入りで接続したらコンテキストが破裂する』という運用上の欠点が顕在化し、エコシステム全体でその修正が進んでいる——というのが現在地に近い。
クレーム③「ツールが多いと精度が崩壊する」
これはコンテキスト窓の問題とは独立した、認知負荷の問題。ツール数が多すぎるとLLMの選択ヒューリスティクス自体が乱れる。
「ツール定義がトークンを食う」とは別の、より深い問題がある。複数の実測で、ツールセットが肥大するとエージェントのツール選択精度が劇的に低下することが観測されている:
ツールメニュー肥大化の認知コスト
つまり、ツール定義を圧縮してトークンだけ減らしても、『そもそも何を呼ぶか』の判断が壊れる。たとえ200kコンテキストの大半が空いていても、メニューが長いと正しいツールが選ばれない。これは「コンテキスト窓のサイズで解ける問題ではない」ことを意味する。
解決の方向性は明確だ: 必要なツールだけを動的にロードする設計に切り替える。MCP公式のSEP-1576はまさにここを扱っている。
減らし方は分かっている — 4つの実証済み手段
「MCPを使うか/捨てるか」の二択ではなく、「どう絞り込んで使うか」が正しい問いだ。実測で効果が確認されている手段は4つある。
- ① Anthropic code mode — ツールを直接呼ぶのではなくコード経由で呼ぶ。報告ベースで最大98.7%のコンテキストオーバーヘッド削減。Cloudflareの code mode 検証記事も参照(KanseiLink内連載)。
- ② mcp-compressor 系 — Atlassianの
mcp-compressorは呼び出し方法を変えずにツール記述を70-97%圧縮。既存サーバーへ後付けで適用可能。 - ③ サーバーのキュレーション — 必要な1-2サーバーに絞れば、定義は数千トークン台に収まる。「全部入り」をやめるだけで効果は大きい。
- ④ コンパクトモード — KanseiLink MCPの
search_services({compact: true})のように、最小フィールド返却モードを使う。多くのMCPサーバーが類似機能を持ち始めている。
議論の焦点は「MCP vs API」ではなく、「MCPを賢く使うか・愚直に使うか」に移っている。プロトコルの設計を変えるべき領域(SEP-1576)、ベンダーが提供すべき省トークン機能(compact / 動的ロード)、利用者が選ぶべき構成(キュレーション)——三層で取り組めば、40-50%は数%に縮められる。
日本SaaSへの含意
日本SaaSベンダーがMCPサーバーを設計する際、Perplexity離脱騒動から取り出すべき教訓は明確だ。
- ツール数の絞り込み — 「APIエンドポイントの数だけツールを出す」設計は避ける。エージェントが実際に使う粒度に集約する。GitHub MCPの94ツールは多すぎる側の例だ。
- ツール説明の簡潔化 — 1ツールあたりの記述を冗長にしない。マークダウン装飾や繰り返しは削る。
- コンパクトモードの提供 — 一覧系ツールにはfull/compact両モードを用意する。KanseiLink自身がこのパターンを採用しており、
compact: trueでフィールド数を絞り、Web fetchと比べ91-96%のトークン削減を実測している。 - 動的ツールロード対応 — SEP-1576の進展を追い、ユースケース文脈に応じてサブセットだけを露出できる設計に備える。
「MCP対応」を看板にする前に、『どう接続されたときにエージェントから経済的に見えるか』を測ることが、AEO(Agent Engine Optimization)時代のSaaS提供者の責務になる。
FAQ
「MCPツール定義がコンテキストの40-50%を食う」は本当ですか？
⚠️ マルチサーバー前提では本当、シングル/キュレーション構成では当てはまりません。GitHub公式MCPは94ツールで~17,600トークン、Atlassian公式はJira+Confluenceで~10,000、複数大型サーバー接続で30,000+。極端例では66,000トークン(200kコンテキストの~33%)が会話開始前に消費されました。一方、1-2サーバーに絞れば数千トークン台です。
「MCPはもう終わり」「標準が死んだ」は本当ですか？
❌ 不正確です。Perplexity離脱は1社の判断で、業界からの撤退ではありません。MCPは2024年11月のオープンソース化以来、OpenAI・Google DeepMind・Microsoft・Cursor・Atlassian・ServiceNow・Salesforce・Linear・GitHubに採用され、2026年4月にはLinux Foundation傘下AAIFに寄贈されました。MCP公式リポでも SEP-1576 で欠点を直す動きが進行中です。
ツール定義の肥大化はエージェントの性能を落としますか？
✅ 落とします。複数の報告で、ツールセット肥大時にツール選択精度が43%から14%以下に崩壊することが観測されています(3倍の劣化)。これはコンテキスト窓の問題とは独立した認知負荷の問題で、トークン圧縮だけでなく動的ツールロードが必要です。
ツール定義のトークン肥大はどう減らせますか？
4つの実証済み手段があります。(1) Anthropic code mode: 最大98.7%削減。(2) Atlassian mcp-compressor: 70-97%圧縮。(3) サーバーをキュレーション: 必要な1-2サーバーに絞る。(4) コンパクトモード: KanseiLink等の compact: true モードを使う。
結局、企業はMCPをどう使うべきですか？
「使うか/捨てるか」ではなく「どう絞るか」が正しい問いです。(1) 業務に必要なサーバーだけ接続、未使用は外す。(2) 大量ツールサーバーには圧縮 or code modeを評価。(3) ベンダー側はツール絞り込みと動的ロード対応でAEO品質を上げる。Perplexityのように特殊用途で別経路を併用するのは合理的ですが、「MCPが終わった」からではなく「1ユースケースで別経路の方が経済的だった」だけです。
本記事のクレームと数値は2026年5月18日時点で公開された一次・二次情報に基づきます。主な出典: Perplexity CTO Denis YaratsのAsk 2026(2026-03-11)発言(Threadsおよび複数の報道で確認)、Merge CTO Gil Feigによる「ツールメタデータが40-50%」推計、GitHub公式MCPサーバーの94ツール/~17,600トークン実測、Atlassian公式MCP(Jira+Confluence)~10,000トークン実測、ヘビー構成での66,000トークン消費報告、ツール選択精度43%→14%の劣化観測、Anthropic code modeの最大98.7%削減レポート、Atlassian mcp-compressor の70-97%圧縮、MCP公式リポジトリ Issue SEP-1576。これらは公開時点のスナップショットであり、実測値はサーバーバージョンや接続構成により継続的に変動します。「40-50%」は典型的なマルチサーバー構成での推計レンジであり、すべての構成に当てはまる絶対値ではありません。「MCPはもう終わり」というSNS上のクレームに対する評価は、2026年5月時点の公開情報(採用事例・SEP進行・圧縮ツール存在)に基づく分析的判断であり、将来の市場動向を保証するものではありません。