2026年3月25日、MCP（Model Context Protocol）の月間SDKダウンロード数が9,700万を超えたという集計が出た。2024年11月のリリースから16ヶ月後のことで、数字だけ見ればMCPは勝った。
同じ月の別の場面は反対の方向を指している。Perplexity CTOのDenis Yaratsは、Ask 2026カンファレンスでプロダクションのコストを理由に主力プロダクトからMCPを外し始めたと明かした。Y Combinator CEOのGarry TanはXにMCPはいまいちだと書きながら、その夜30分でPlaywrightのCLIラッパーを作ってMCPの代わりに使っていると付け加えた。
9,700万ダウンロードが語らないことがある。
#スキーマが食い尽くす空間
ほとんどのMCPクライアントは、ツールのスキーマをモデルのコンテキストウィンドウに前もって入れる。どんなコマンドがあり、どんな引数を受け取り、何を返すかがツールごとに入るので、ツールを一つつなぐたびにモデルが作業に使える空間が減り、精度も落ちやすい。
Yaratsが挙げた理由は、コンテキストウィンドウの消費と認証の二つだった。二次報道にはスキーマがコンテキストの72%を食ったという数字がついて回るが、その数字がPerplexityの計測なのか別の導入事例から持ち込まれたものなのかは、発表の原文で確認できなかった。確かなのは、エージェントがツールを繰り返し呼ぶほどこのコストが積み上がるという側だ。
“MCP sucks honestly. It eats too much context window and you have to toggle it on and off and the auth sucks.”
MCPは正直ダメだ。コンテキストウィンドウを食いすぎるし、トグルでオンオフしなければならないし、認証もひどい。
出典: Garry Tan, X
Tanが代わりに作ったのはPlaywrightのCLIラッパーで、作ってみたらVercelがすでに同じものを作っていたという。PerplexityはMCPサーバーは維持しつつ、主力プロダクトをRESTベースの自社エージェントAPIに移した。
このコストはプロトコルの宿命ではない。2025年11月、Anthropicはツール定義をすべて前もって入れる代わりに、エージェントがコードで必要なツールだけを呼び込む方式を公開し、例では15万トークンが2千トークンに減ったとした。ところがその記事自体が、ほとんどのMCPクライアントはすべてのツール定義をコンテキストに前もって入れると書いている。遅延ロードはクライアントが別に実装しなければならない迂回路であって、よくある実装のデフォルトの動作ではなく、上の数字はツール定義を前もって入れるよくある方式から出ている。
#CLIを渡せばLLMは自分で使う
2026年2月28日、Eric HolmesはLLMがすでにコマンドラインツールをうまく使うと書いた。何百万ものman page、Stack Overflowの回答、シェルスクリプトだらけのGitHubリポジトリで訓練されているからだ。彼の論点は三つだった。
- デバッグ：MCPはJSONログを掘らなければならない。CLIなら
jira issue viewの一行で、エージェントが見たものと同じ結果を直接確認できる。 - 認証：MCPは独自の認証体系を新たに実装しなければならない。CLIはAWS SSO、GitHub CLI、kubeconfigのような既存の認証をそのまま使う。人が使ってもエージェントが使っても追加作業がない。
- 運用：MCPサーバーは別プロセスを立ち上げて状態を管理しなければならない。CLIはインストール済みのコマンドを実行すれば終わりだ。
Holmesと同じ方向を指す調査結果もある。Pragmatic Engineerが2026年初めに900人へ尋ねた調査で1位になったClaude CodeはMCPに対応しているが、デフォルトの動作はターミナルでファイルとCLIを直接扱うことだ。その調査の回答者のあいだで最も使われているツールが、MCPなしで動くように設計されているという意味だ。
#認証を強制しないスペック
認証側の数字はもっと悪い。2025年7月、セキュリティ企業Knosticがインターネットに露出したMCPサーバー1,862台のうち119台を手で検証した。認証なしにツール一覧を返すサーバーが119台すべてだった。ツールを実際に実行してはいないと研究者は書いている。
3ヶ月後の2025年10月、AstrixがオープンソースのMCPサーバー5,200台を分析したときは、88%が資格情報を要求していた。ところが全体の53%は静的なAPIキーや個人アクセストークンのような長期シークレットに依存しており、OAuthを使うサーバーは8.5%にすぎなかった。認証はあるが、キーが一度漏れればそのまま開く認証だ。この数字が数えているのは、MCPサーバーがGitHubやPostgresのような後ろ側のサービスにどんなキーで接続するかだ。クライアントがMCPサーバーにどう認証するかは、ここには入っていない。スペックが扱う認証は前側で、後ろ側については第三者のOAuthトークンの保管責任を書いておいた程度にすぎず、静的キーの発行と交換と失効までは標準化していない。
私の見るところ、前側の0件はエコシステムが未成熟だからではなく、MCPスペックがHTTPトランスポートで認証をオプションにしたからで、後ろ側の53%はスペックがその場所をほとんど扱っていないからだ。スペックが強制しないからサーバーを作る側が省くか静的キーで済ませ、オープンソースのサーバーが何千台も出てくるエコシステムでは、この結果は予測できる側にある。時間がたてば解決する種類の問題ではない。スペックが変わらなければならない。
#それでMCPは死んだのか
9,700万ダウンロードが示すように、MCPはいまも使われている。ただし処方は使う側によって違う。Charles Chenが区別したように、個人がコーディングエージェントを使うことと、組織が導入することは別の問題だ。
コーディングエージェントを使う個人開発者にとってMCPはオーバーヘッドだ。gh pr createを打てば終わる仕事に、MCPサーバーを立ち上げる理由がない。かといって、組織ではMCPが必要だというのもあまりに安易な結論だ。gh、aws、gcloudのようなCLIは、すでに組織単位のSSOと監査ログに対応しており、組織だからという理由だけでMCPが自動的に必要になるわけではない。
訓練データにすでに溢れるほど入っているgitやcurlのようなツールではHolmesのCLIの主張が通るが、社内で作ったカスタムCLIはLLMが初めて見るツールなので、スキーマがまた必要になる。カスタムツールが多い組織ほど、CLIだけでは足りない。
MCPが必要になる条件は、だからもっと狭い。数百人が社内のカスタムツール数十個にアクセスしなければならず、中央の認証と監査が必要で、ツールカタログが頻繁に変わる環境だ。その環境でも、スペックが認証を強制するまでは限られた条件でしか使えない。MCP 2026ロードマップでエンタープライズ対応の項目がまだ正式な提案前の議論段階だという事実が、この隔たりを示している。必要は明確なのにスペックがない。
コーディングエージェントを使う個人開発者にとってMCPはすでに不要だ。組織にとってMCPはまだ不完全だ。
#参考資料
- Artur Markus、MCP 9,700万ダウンロード (2026.03.25)。PythonとTypeScriptのSDKの月間ダウンロード合計が9,700万を超えたという集計の報道。
- Anthropic、Code execution with MCP (2025.11.04)。ツール定義を前もって入れる代わりに、コードで必要なツールだけを呼び込めばトークンが15万から2千に減ると説明した記事。
- Eric Holmes、MCP is dead. Long live the CLI (2026.02.28)。LLMがすでに慣れているCLIを渡せば、MCPなしでもツールを使うと主張した記事。
- Garry Tan、X (2026.03.11)。MCPがコンテキストウィンドウを食い、認証が弱いと書いた投稿。
- Perplexity、MCPから自社エージェントAPIへ転換 (Ask 2026)。コンテキストの消費と認証を理由に、主力プロダクトを自社エージェントAPIへ移すと明かした発表を伝えた報道。
- Charles Chen、MCP is Dead; Long Live MCP! (2026.03.14)。個人の使用と組織の導入は別の問題だと反論した記事。
- Astrix、State of MCP Server Security 2025 (2025.10)。オープンソースMCPサーバー5,200台が後ろ側のサービスに接続する資格情報の方式を分析し、静的キー53%、OAuth 8.5%を集計した報告書。
- MCP 2026ロードマップ (WorkOS)。エンタープライズ対応項目がpre-RFC段階にあることを整理した記事。
- Pragmatic Engineer、AI Tooling for Software Engineers in 2026。開発者900人の調査で、Claude Codeが最も使われるツールに挙がった結果。