Namsang LABS
Radar · #ai #mcp #cli #developer-tools #ai-agent

MCP、個人には不要で組織には不完全だ

· Sangkyoon Nam
Also in 한국어 , English

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 sucks honestly」と投稿し、30分後にはCLI代替を自ら作り上げた。
  • 2025年7月、セキュリティ企業Knosticがインターネットに露出したMCPサーバー1,862台のうち119台を手動検証したところ、実際に1台たりとも認証を要求しなかった。2026年現在、OAuthの適用率は8.5%にとどまる。

9,700万ダウンロードが語らないことがある。

#スキーマが食い尽くすスペース

MCPはスキーマ（どんなコマンドがあり、どんな引数を受け取り、何を返すか）をモデルのコンテキストウィンドウに入れる構造だ。ツールを1つ接続するたびにそのスキーマがコンテキストを占有し、モデルが実際の作業に使える空間が減るだけでなく、精度まで低下する。

YaratsがAsk 2026カンファレンスでその規模を数値で公開した。MCPスキーマがエージェントのコンテキストウィンドウの72%を占有しており、ユーザーのクエリが処理される前に作業スペースの大半が消えた状態で、会話が長くなるほど悪化する。エージェントがツールを繰り返し呼び出すと、スキーマのオーバーヘッドは複利で積み上がる。

“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の体感はもっと具体的だった。ツールを2つ接続しただけでコンテキストの20%が消えると語った。Perplexityは最終的に自社Agent API（RESTベース、OpenAI互換）に移行した。MCPサーバー自体は維持しつつも、主力プロダクトからは外す方向を選んだ。

#CLIを渡せばLLMは自分で使う

2026年2月28日、Eric Holmesが一本の記事で論争に火をつけた。

“LLMs are really good at using command-line tools. They’ve been trained on millions of man pages, Stack Overflow answers, and GitHub repos full of shell scripts.”

LLMはコマンドラインツールを非常にうまく使う。何百万ものman page、Stack Overflowの回答、シェルスクリプトだらけのGitHubリポジトリで訓練されているからだ。

— Eric Holmes, “MCP is dead. Long live the CLI”

Holmesの論点は3つだった。

  • デバッグ:MCPはJSONログを掘らなければならない。CLIならjira issue viewの一行でエージェントが見たものと同じ結果を直接確認できる。
  • 認証:MCPは独自の認証体系を新たに実装する必要がある。CLIはAWS SSO、GitHub CLI、kubeconfigなど既存の認証をそのまま使える。人が使ってもエージェントが使っても追加作業がない。
  • 運用:MCPサーバーは別プロセスを立ち上げて状態を管理しなければならない。CLIはインストール済みのコマンドを実行すれば終わりだ。

この記事がHacker Newsで広まった後、Tanの投稿とPerplexityの離脱が連鎖的に続いた。調査結果も同じ方向を指している。Pragmatic Engineerが900人を対象に実施したアンケート（2026年1〜2月）で、最も使われているAIツールの1位はClaude Codeだった。ターミナルからファイルを直接読み書きするエージェントであり、MCPなしでも動作する。

ただし、この論理には限界がある。Holmesの主張がきれいに機能するのは、git、curl、jqのようにLLMの訓練データにすでに大量に含まれているツールに限ってのことだ。社内で作ったカスタムCLIは事情が異なる。LLMが初めて見るツールには結局スキーマが必要になり、この時点でCLIの「スキーマ不要」という主張は成り立たなくなる。カスタムツールが多い組織ほど、CLIだけでは足りなくなる。

#認証を強制しないスペック

セキュリティ側の数字はさらに深刻だ。2025年7月、Knosticがインターネット上のMCPサーバー1,862台のうち119台を手動で検証したところ、1台たりとも認証を要求せず、CVSS 9点台のCVEもすでに3件積み上がっていた。9ヶ月が経った2026年になっても状況は大きく変わっていない。2026年2月、Astrixが5,200件のオープンソースMCPサーバーを分析した結果、88%が認証を要求していたが、その半数以上（53%）がAPIキーやPATなどの長期有効な静的シークレットに依存していた。認証はあるが、破られやすい認証だ。MCPスペックにOAuth 2.1が追加されたが、実際の適用率は8.5%にとどまる。

根本原因はエコシステムの未成熟ではない。MCPスペック自体が認証をオプションとして設計しているからだ。スペックが強制しないからサーバー開発者が省略し、エコシステムの75%が企業ではなく個人が作ったサーバーであることを考えれば、予測可能な結果だ。時間が解決する類の問題ではない。スペックが変わらなければならない。

#ではMCPは死んだのか

9,700万ダウンロードが示すように、MCPは依然として人気のあるツールだ。ただし、使われ方が以前とは変わりつつある。

“Individual usage of coding agents looks very different from organizational adoption.”

個人がコーディングエージェントを使うことと、組織が導入することはまったく別の問題だ。

— Charles Chen, “MCP is Dead; Long Live MCP!”

個人開発者にとってMCPはオーバーヘッドだ。gh pr createを打てば済む話に、MCPサーバーを立ち上げる理由がない。Holmesが正しく、Claude Codeが1位である理由がここにある。

かといって「組織ではMCPが必要だ」もあまりに安直な結論だ。gh、aws、gcloudといったCLIツールはすでに組織単位でSSOと監査ログをサポートしており、組織だからという理由だけでMCPが自動的に必要になるわけではない。

MCPが実際に必要になる条件はもっと狭い。数百人が社内カスタムツール数十個にアクセスする必要があり、中央集権的な認証と監査が必要で、ツールカタログが頻繁に変わる環境だ。ほとんどのチームはまだそこに到達していない。MCP 2026ロードマップでエンタープライズ準備項目がまだpre-RFC段階であるという事実が、このギャップをよく表している。必要性は明確なのにスペックがない。

個人にとってMCPはすでに不要だ。組織にとってMCPはまだ不完全だ。MCPが生き残るには、このギャップを認めるところから始めなければならない。

#参考資料

Share this post