MCPとは何か——「AIのUSB-Cポート」の約束
Model Context Protocol（MCP）は、Anthropicが2024年11月25日に発表したオープンソースプロトコルだ。AIモデルが外部のツール、データソース、サービスと接続するための標準化されたインターフェースを提供し、しばしば「AIアプリケーションのためのUSB-Cポート」と形容される。技術的にはJSON-RPCをstdioまたはHTTP（SSE/Streamable HTTP）のトランスポート層上で使用する。
MCPの登場以前、AIモデルが外部ツールにアクセスするには、各ツールごとにカスタムの統合コードを書く必要があった。MCPはこの「N×M問題」（N個のAIモデルとM個のツールの組み合わせ）を標準化によって解決すると約束した。2025年3月にOpenAIがChatGPTデスクトップアプリでMCPを公式採用したことで勢いが加速し、2025年11月の1周年記念仕様改定、2025年12月のLinux Foundation傘下Agentic AI Foundation（AAIF）への寄贈を経て、SDKの月間ダウンロード数は9,700万回、17,000以上のMCPサーバーがインデックスされ、300以上のアクティブなクライアントが存在する巨大なエコシステムを形成した。
すべての主要AIプロバイダー——Anthropic、OpenAI、Google、Microsoft、Amazon——がMCPをサポートし、業界標準の座を確立したかに見えた。
MCP賛成派の主張——なぜ支持されたのか
MCPの支持者は、以下の利点を挙げてプロトコルの価値を主張する。
第一に、ユニバーサルスタンダードとしての価値。すべての主要AIベンダーが採用したことで、ツール開発者は一度MCPサーバーを実装すれば、あらゆるAIクライアントから利用可能になる。これはウェブのHTTPや、USBのように、プロトコルの標準化がエコシステム全体の効率を飛躍的に高めるという古典的な議論だ。
第二に、セキュリティフレームワーク。OAuth 2.1ベースのユーザーごとの認証、スコープされたパーミッション、監査ログが組み込まれている。エンタープライズ環境では、各ユーザーが自分の権限でツールにアクセスし、すべての操作が記録される仕組みが不可欠であり、MCPはこれを標準化した。
第三に、エコシステムの規模。9,700万の月間SDKダウンロード、17,000以上のサーバー、14万3,000の実行可能なAIコンポーネントという数字は、ネットワーク効果がすでに臨界点を超えていることを示唆する。
第四に、ベンダーニュートラルなガバナンス。Linux Foundation傘下のAAIFに寄贈されたことで、Anthropic一社の支配から解放され、業界全体の共有資産となった。
これらの主張は、表面的には説得力がある。しかし2026年初頭、エンジニアリングコミュニティの最前線から、これらの約束が現実と乖離しているという批判が噴出した。
「MCPは正直ダメだ」——Y Combinator CEO Garry Tanの宣言
2026年3月、シリコンバレーのMCPに対する不満が一気に表面化した。
火付け役の一人は、Y Combinator CEOのGarry Tan氏だ。Tan氏は「MCPは正直言ってダメだ（MCP sucks honestly）。コンテキストウィンドウを食いすぎるし、いちいちオンオフを切り替えなければならない」と公言し、わずか30分で「100倍マシ」なCLIラッパーをバイブコーディングで作り上げたと報告した。世界最大級のスタートアップアクセラレーターのCEOがこれほど直接的にプロトコルを批判することは異例であり、スタートアップエコシステム全体に波紋を広げた。
同じ時期、Perplexity CTOのDenis Yarats氏はAsk 2026カンファレンスで、Perplexityが社内システムのMCPからの脱却を進めていることを発表した。Yarats氏は、ツールスキーマのオーバーヘッドが利用可能なコンテキストウィンドウの40〜50%を消費していること、認証の複雑さが実装の摩擦を生んでいることを理由に挙げた。MCPのサポートは限定的なユースケース（例: Claude DesktopからPerplexity検索へのアクセス）にのみ継続するとした。この発表はXで「クレイジーなほどバイラル」になった。
連続起業家のPieter Levels氏は「MCPが死んでくれてありがたい。llms.txtと同じくらい無駄なアイデアだ。AIは人間と同じくらい賢いのだから、すでにそこにあるもの——つまりAPI——をそのまま使えばいい」とツイートした。
これらの声は孤立した意見ではなかった。2026年2月28日にインフラエンジニアのEric Holmes氏が公開した「MCP is dead. Long live the CLI」というブログ記事はHacker Newsのトップに達し、「LLMが本当に得意なのは、自分で物事を理解することだ。CLIとドキュメントを与えれば十分」という主張が広範な共感を集めた。
コンテキストウィンドウを「食い尽くす」——トークン消費量の衝撃的な格差
MCP批判の中核にあるのは、トークン消費量の問題だ。数字は衝撃的である。
Scalekitが2026年にClaude Sonnet 4を使用して実施したベンチマークによれば、リポジトリの言語とライセンスを取得する単純なタスクで、CLIは1,365トークンを消費したのに対し、MCPは44,026トークンを消費した——32倍の差だ。プルリクエストの詳細とレビューを取得するタスクでは20倍、リポジトリのメタデータとインストール方法の取得で9倍、コントリビューターごとのマージ済みPRの集計で7倍。最も差が小さい「最新リリースと依存関係の取得」でも4倍の開きがあった。
この格差の根本原因は、MCPの設計そのものにある。GitHubのMCPサーバーは93個のツールを公開しており、セッション開始時に約55,000トークンのスキーマ定義がコンテキストに注入される。ユーザーが一言も発する前に、コンテキストウィンドウの大部分がツール定義で埋まっている状態だ。あるチームでは、200,000トークンのコンテキストウィンドウのうち143,000トークン（72%）がツール定義に消費されたと報告されている。データベースMCPサーバー（106ツール）は初期化だけで54,600トークンを消費した。MCPGaugeフレームワークの分析では、MCPのコンテキスト取得がトークン予算を最大236倍に膨張させるケースが確認された。
月間コストに換算すると、10,000回の操作をClaude Sonnet 4の料金で計算した場合、CLIは約3.20ドル、MCPは約55.20ドル——17倍のコスト差だ。ゲートウェイによるスキーマフィルタリングを導入しても約5ドルであり、CLIの単純さにはかなわない。
「CLIは100%、MCPは72%」——信頼性と速度の実測データ
コストだけでなく、信頼性と速度でもCLIが優位性を示している。
信頼性テストでは、CLIが25回中25回成功（100%）だったのに対し、MCPは25回中18回成功（72%）にとどまった。MCPの7回の失敗は、GitHubのCopilot MCPサーバーへのTCPレベルのタイムアウトが原因だった。
ブラウザ自動化のベンチマークでは、CLIエージェントのトークン効率スコア（TES）は202.1、MCPエージェントは152.3——CLIが33%優位だ。タスク完了スコアではCLIが28%高い値を記録した。さらに深刻なのは、LLMのパフォーマンスがコンテキストサイズと負の相関を示すことだ。MCPの統合が増えるほど精度が低下する。Tau-BenchでのテストではClaude 3.7 Sonnetが基本的な航空券予約タスクで16%の成功率しか達成できなかった。
CLIが200トークンで初期化を完了するのに対し、MCPは10,000トークン以上を要する。この差は、LLMが数十億行のターミナル操作データで事前学習されており、CLIが事実上LLMの「ネイティブ言語」であることに起因する。CLIツールにドキュメントを渡せば、LLMは自力で使い方を理解できる。MCPの55,000トークンのスキーマ注入は、LLMがすでに知っていることを冗長に説明し直しているに過ぎない。
深刻すぎるセキュリティ脆弱性——CVEの連鎖
MCPのセキュリティ問題は、コスト以上に深刻だ。発見された脆弱性の数と深刻度は、プロトコルの根本的な設計上の欠陥を示唆している。
CVE-2025-49596（CVSS 9.4、Critical）。Oligo Security Researchが2025年1月に発見した、Anthropic公式のMCP Inspector開発ツールの脆弱性だ。MCP Inspectorを実行中の開発者が悪意あるウェブサイトを訪問すると、DNSリバインディングにより開発マシン上で任意のコマンドが実行可能になる。認証なしのリモートコード実行——開発者のマシンが完全に乗っ取られる。バージョン0.14.1でセッショントークンと許可オリジンチェックにより修正された。
CVE-2025-6514（CVSS 9.6、Critical）。JFrogが発見した、mcp-remote OAuthプロキシの脆弱性だ。43万7,000以上のダウンロードを記録したこのパッケージで、悪意ある認可エンドポイントがシェルコマンドを注入できた。Cloudflare、Hugging Face、Auth0との統合に影響するサプライチェーン攻撃のリスクがあった。
CVE-2025-68143/68144/68145。Anthropic公式のGit MCPサーバーに発見された3つの連鎖脆弱性だ。悪意ある.git/configファイルを通じて、Filesystem MCPサーバーと組み合わせて完全なリモートコード実行が可能だった。
CVE-2025-53109/53110（Critical）。Filesystem MCPのサンドボックスエスケープとシンボリックリンクバイパスにより、任意のファイルアクセスとコード実行が可能だった。
CVE-2025-64106（CVSS 8.8）。CursorのMCPインストールフローにおける脆弱性で、攻撃者が任意のコマンドを実行可能だった。
これらはいずれもAnthropicの公式ツールまたは主要なMCPエコシステムコンポーネントにおける脆弱性であり、サードパーティの品質問題として片付けられるものではない。
ツールポイズニングとラグプル——信頼モデルの崩壊
CVEレベルの脆弱性に加え、MCPの信頼モデルそのものを攻撃する手法が確認されている。
Invariant Labsは2025年4月、ツールポイズニング攻撃のデモンストレーションを公開した。悪意あるMCPサーバーがツール定義の説明文に隠し命令を埋め込み——ユーザーには表示されないがLLMには読める——、ユーザーのWhatsApp全履歴を静かに窃取するという衝撃的な内容だった。さらに「クロスサーバーシャドウイング」として、悪意あるサーバーが信頼されたピアへの呼び出しを傍受・書き換える手法も実証された。
ラグプル攻撃はさらに陰湿だ。MCPツールはインストール後に自身の定義を変更できる。初日に安全に見えるツールを承認しても、7日目にはAPIキーを抜き取るツールに変貌している可能性がある。MCPクライアントはリクエスト間でツールスキーマの一貫性を検証しない。具体的な手法として、セッション途中でAWS_ACCESS_KEY_IDを「必須パラメータ」として追加し、LLMがユーザーの認証情報を抽出して攻撃者に渡すケースが確認されている。
2025年9月にはPostmarkの偽MCPサーバーが出現し、正規のサーバーとわずか1行の差分で、すべての送信メールを攻撃者にBCCするという事件が発生した。AI自動化パイプライン経由のトランザクションメールが影響を受けた。2025年10月にはMCPホスティングサービスSmitheryで、smithery.yamlのパストラバーサルにより3,000以上のホスティングMCPサーバーを制御するFly.io APIトークンが漏洩した。
セキュリティ研究者のSimon Willison氏は「プロンプトインジェクションの呪いは、2年半以上前から問題を認識していながら、いまだに説得力のある緩和策がないことだ」と指摘し、AIエージェントにおける「致命的な三位一体（lethal trifecta）」——プライベートデータへのアクセス、アクションの実行能力、信頼できないコンテンツへの露出——を警告した。Elena Cross氏は「MCPの"S"はセキュリティの"S"」と皮肉った——MCPにSは含まれていない。
Astrix Securityの2025年調査は、MCPエコシステム全体のセキュリティ状況を数字で示した。テスト対象のMCPサーバーの43%にコマンドインジェクション脆弱性、22%がディレクトリトラバーサルを許可、30%が制限なしのURLフェッチ、53%が安全でない長期静的シークレットに依存。セキュアなOAuth認証を実装しているのはわずか8.5%。36.7%にSSRFの潜在的リスク。クライアント認証も暗号化もない状態で公開されているMCPサーバーが492台発見された。
CLIが圧倒的に優れている理由——エンジニアリングの観点
MCPに対するCLIの優位性は、単なるコスト削減にとどまらない。エンジニアリングの観点から見ると、CLIアプローチには構造的な優位性がある。
トークン効率。CLIの初期化は約200トークン。MCPは55,000トークン以上。同一タスクでCLIは4〜32倍少ないトークンで完了する。これはLLMが数十億行のターミナル操作データで学習しており、git log --oneline -5のようなコマンドの意味と出力形式を「すでに知っている」ことによる。MCPはLLMが既に理解していることを冗長なJSONスキーマで再説明しており、本質的に無駄だ。
信頼性。CLIは100%の成功率（25/25）、MCPは72%（18/25）。CLIコマンドは50年の歴史を持つ枯れた技術であり、障害モードが完全に理解されている。MCPはネットワーク越しの新しいプロトコルであり、タイムアウト、認証失敗、スキーマの不一致など、新たな障害モードを導入する。
検査可能性。Unixパイプは50年のツーリングに裏打ちされたオリジナルのコンポーザビリティプリミティブであり、各ステップが検査可能だ。CLIはパイピング、チェーン、リダイレクトをネイティブにサポートし、デバッグが容易。MCPサーバーの内部動作はブラックボックスであり、何が起きているかの可視性が低い。
セキュリティ面。CLIツールはローカルマシン上で既知の権限で実行される。MCPはネットワーク越しの任意のサーバーに接続し、ツール定義が動的に変更される可能性があり、攻撃面が桁違いに大きい。CLIでgit logを実行しても、そのコマンドが翌日に別のコマンドに変わることはない。MCPではそれが起きうる。
月間コスト。10,000回の操作で、CLI約3.20ドル対MCP約55.20ドル。年間で624ドル対6,624ドル。大規模な運用では数百万ドルの差になる。
Cloudflareはこの問題に独自に到達し、Code Modeとして約1,000トークンで動作する代替手法を構築した。MCPのネイティブスキーマでは244,000トークンを要した同等の機能が、250分の1のトークンで実現されている。エージェントがコードを生成してAPIを直接呼び出す方式では、MCPと比較して最大98%のトークン削減が達成された。
Thoughtworks Technology Radarの警告
テクノロジーコンサルティングの権威であるThoughtworks Technology Radarは、「ナイーブなAPI-to-MCP変換」をHold（導入を推奨しない）に分類した。既存のREST APIをそのままMCPサーバーに変換するアプローチは、期待される効果を生まないと判断されたのだ。この評価は、MCPのプロトコルとしての価値が技術的な優位性ではなく、「社会学的な」——つまり全員が使っているから使うという——ものに過ぎないという議論を裏付けている。
Tim Kellogg氏は「MCPでできることはすべてOpenAPIでもできる」と指摘し、MCPの必然性は技術的優位性ではなく集団的採用にある——つまり価値は社会学的（sociological）であって技術的（technological）ではない——と分析した。
反MCP陣営の具体的なアプローチ
MCPからの脱却を主張する陣営は、いくつかの具体的な代替アプローチを提唱している。
ダイレクトCLI統合。Eric Holmes氏のアプローチ——LLMにCLIツールとドキュメントを渡せば、あとは自分で理解する。CLIの200トークンの初期化対MCPの55,000トークン以上のスキーマ注入。LLMは数十億行のターミナル操作で訓練されており、CLIは「ネイティブ言語」だ。
REST API直接呼び出し。Perplexityが採用した方式。チームは「REST APIエンドポイントを薄くラップした小さなツールラッパーを書いただけ」で十分だったと報告している。既存のOpenAPI仕様はそのまま活用でき、新たなプロトコルを学ぶ必要がない。
AGENTS.mdアプローチ。OpenAIが発案し、AAIFに寄贈された標準。プロジェクト固有のガイダンスをAIエージェントに提供する。60,000以上のオープンソースプロジェクトとAmp、Codex、Cursor、Devin、Gemini CLI、GitHub Copilotなどのフレームワークで採用されている。MCPと補完的だが、多くのケースでMCPを不要にするとの議論がある。
Unixパイプの哲学。「Unixパイプは50年のツーリングに裏打ちされたオリジナルのコンポーザビリティプリミティブであり、各ステップが検査可能だ」。パイプ、チェーン、リダイレクションをネイティブにサポートし、新しいプロトコルを発明する必要がない。
賛成派の反論と「死んでいない」という主張
公平を期すために、MCPの擁護者の反論も記しておく。
Elie Steinbock氏は「Levelsは有用なMCPを使ったことがないのだ。MCPは非常に有用だし、死んでなどいない」と反論した。GoogleがフルマネージドMCPサーバーをクラウドサービス向けに発表し、AWSがあらゆるAPIをMCPに変換するゲートウェイを出荷し、OpenAIがMCPサポートを全製品で深化させている事実は、少なくとも大手プラットフォームがMCPに賭け続けていることを示している。
Charles Chen氏は「MCP is Dead; Long Live MCP!」と題した記事で、ローカルstdioベースのMCPは問題が多いがHTTPベースのエンタープライズMCPには正当な役割があると主張した。マルチユーザー認証、監査証跡、構造化されたツール発見など、CLIだけでは実現困難なエンタープライズ要件が存在するのは事実だ。
しかし、この「エンタープライズ用途では有用」という反論は、裏を返せば、ソロ開発者やコスト意識の高い運用環境ではMCPが不要だという批判を認めていることに等しい。MCPの当初の約束——「AIのUSB-Cポート」——は、すべてのAIツール接続を標準化するというものだった。その約束が「エンタープライズのマルチユーザー認証には使える」に縮小されたこと自体が、批判派の主張を裏付けている。
Anthropicの対応——ロードマップと限界
Anthropicは批判に沈黙しているわけではない。2025年12月のLinux Foundation寄贈は、プロトコルの中立性を確保し「Anthropic一社の都合で変わる」という批判を封じる意図があった。2026年のロードマップでは、エンタープライズ管理型認証（SSO統合フロー）、監査証跡と観測性、ゲートウェイとプロキシパターン、水平スケーリングのためのステートレスHTTPトランスポート、MCP Server Cards（.well-knownメタデータ発見）、レジストリの改善、コントリビューターガバナンスモデルが計画されている。
しかし批判者の一部は、Anthropicが「Linux Foundationに寄贈することで責任を転嫁しつつ、セキュリティ問題は未解決のままだ」と指摘している。MCP仕様が2025年だけで3回（3月、6月、11月）の大規模改定を経たことも、実装の安定性に対する懸念を生んでいる。日本のテックコミュニティでは、この急速な仕様変更がMCP採用の躊躇につながっているとの報告がある。
業界への影響
「MCP is Dead」の議論は、AIツール接続のアーキテクチャに関する根本的な問い——新しい標準プロトコルを発明すべきか、既存のインフラを活用すべきか——に対する業界の回答が、後者に傾きつつあることを示している。
第一に、コスト意識の台頭がアーキテクチャ選択を変える。LLMの推論コストがAI運用の主要なコストドライバーとなるなかで、同一タスクに4〜32倍のトークンを消費するプロトコルは持続不可能だ。月間55.20ドル対3.20ドルの差は、大規模運用では年間数百万ドルの差になる。CFOがAI運用コストを精査し始めた今、MCPの「便利だが高価」な特性は致命的な弱点となる。
第二に、セキュリティ問題がエンタープライズ採用の最大の障壁となっている。Astrix Securityの調査で38%のMCPビルダーがセキュリティ懸念が採用を阻害していると回答し、テスト対象の43%にコマンドインジェクション脆弱性が存在する現実は、CISOの承認を得ることを極めて困難にする。特にラグプル攻撃のように、一度承認したツールが事後的に変貌する可能性は、従来のセキュリティモデルの想定外であり、対策が困難だ。
第三に、CLIとREST APIへの回帰が新しいエンジニアリング文化を形成する。PerplexityやCloudflareのような先進企業がMCPから離脱し、CLIと直接API呼び出しに移行したことは、業界のベストプラクティスの転換を示唆している。LLMが「すでに知っている」ツールをそのまま使うという哲学は、不必要な抽象化を排除するUnixの設計思想と共鳴し、エンジニアリングコミュニティの広範な支持を得ている。
第四に、MCPの役割は縮小するが消滅はしない。エンタープライズのマルチユーザー認証、監査証跡、構造化されたガバナンスが必要な場面では、MCPに代わる標準は現時点で存在しない。しかし「AIのUSB-Cポート」という当初の壮大なビジョンは、「エンタープライズ統合レイヤー」という限定的な役割に縮小されている。MCPは死んだのではない——その居場所が正当に再定義されたのだ。
第五に、日本の開発者コミュニティへの影響。日本ではMCPのセキュリティリスクに対する懸念が特に高く、DX/AI推進担当者の60.2%がMCPのセキュリティとガバナンスに懸念を表明している。GMOフラットセキュリティのブログ、トレンドマイクロ・ジャパンの公開MCPサーバーリスクの報告、日経xTECHのMCP脆弱性連鎖に関する報道は、日本企業がMCP採用に慎重な姿勢を取る根拠を提供している。一方で、CLIベースのアプローチは日本のエンジニアリング文化——精緻さ、コスト効率、安定性を重視する——と親和性が高い。
MCPの「死」は、より正確に言えば「万能ツール」としての幻想の死だ。そしてその代わりに浮上しているのは、40年以上の歴史を持つコマンドラインインターフェースという、枯れた技術の再評価である。LLMが最も得意なのは「自分で物事を理解すること」であり、それを最もコスト効率よく実現するのはCLIだ。MCPの55,000トークンのスキーマ注入は、LLMに「あなたが知っていることを、もう一度教えてあげよう」と言っているに等しい。その冗長さに、エンジニアリングコミュニティはついに「もう結構です」と答えたのだ。