大手テック企業が全てMCPを支持しているのに、なぜ「死んだ」と言われるのですか？

「死んだ」というのは採用率ではなく効率の話です。MCPは個人開発のタスクでCLIの10〜32倍のトークンを消費し、失敗率も高いです。大手企業がMCPに賭けるのは、エンタープライズガバナンス、マルチテナント認可、クロスプラットフォーム配布の価値を見込んでいるからで、個人開発者の日常利用とは全く異なるシナリオです。「MCPは死んだ」は過度なハイプへの反発であり、プロトコル自体の終焉ではありません。

個人開発者ですが、今MCPを学ぶべきですか？

大きな時間を投資する必要はありません。CLIとSkillの組み合わせで成功率はほぼ100%、トークン効率はMCPの10〜32倍で、OAuth設定やサーバー運用の負担もありません。唯一の例外はNotionやFigmaなどCLIのないクラウドサービスに接続する場合で、コミュニティの既存MCPサーバーを使うのが合理的です。

SkillはClaude Codeでしか使えませんが、他のプラットフォームではどうすればいいですか？

その通りで、Skillは現在Claude Codeエコシステムに紐づいています（Gemini CLIには部分的な互換性あり）。クロスプラットフォームでツール機能を使いたい場合（Cursor、ChatGPT、Windsurf）、MCPが正しい選択です。ただし、ワークフローや規範を定義したいだけなら、多くのプラットフォームに類似の仕組みがあります。Cursorには.cursorrules、GitHub Copilotには.github/copilot-instructions.mdがあり、コンセプトは同じでフォーマットが違うだけです。

MCPは死んだ？SkillとCLIでは代替できない3つのシナリオ

2026年2月末、「MCP is dead. Long live the CLI」という投稿がHacker Newsのトップページに登場し、議論が爆発しました。「MCPは不要な抽象レイヤーだ」という声がある一方、「大手テック企業が全て参画している」という反論も。Claude CodeやCursorで「MCPサーバーを導入すべきか」迷っているなら、この記事がベンチマークデータと30秒の意思決定フレームワークで判断をサポートします。

TL;DR

2026年6月アップデート：MCP Dev Summit NA（4月、ニューヨーク、参加者1,200名・前回比2倍）でMCPがエンタープライズインフラとして確立。5月19日にAnthropicがMCP Tunnels（研究プレビュー）を発表。Salesforceが6月23日にAgentforce 3でMCPエコシステムに正式参入し、3つの公式サーバーを公開。本記事の意思決定フレームワークは変更なし。

MCPは死んでいない。公式レジストリには9,652以上のサーバー（2026年5月24日時点）、PulseMCPなどのサードパーティディレクトリでは16,500以上を追跡、月間SDKダウンロードは9,700万回で成長を続けている。ただし解決するのは「マルチユーザー・クロスプラットフォームのツール配布」であり、個人のコーディング作業ではない
CLIはトークン効率でMCPの10〜32倍、成功率はほぼ100%
Skillはプロセス知識（AIに「やり方」を教える）、MCPはツール能力（AIに「できること」を与える）。補完関係であり、競合ではない
個人開発者向け：CLI + Skillを基本にし、Notion/FigmaなどCLIのないクラウドサービスが必要な時だけ既存のMCPサーバーを利用
セキュリティリスクが急激にエスカレート：OX Securityが公開したSTDIOアーキテクチャレベルのRCE脆弱性は20万インスタンスに影響。Anthropicは「期待される動作」として修正を拒否。公開サーバーの24%が認証ゼロ

「MCPは死んだ」論争の経緯

MCP（Model Context Protocol）は、Anthropicが2024年11月にリリースしたオープンプロトコルで、AIシステムが統一インターフェースで外部ツールやデータソースに接続できるようにするものです。よく使われる例えは「AIのUSB-C」。MCPサーバーを一度構築すれば、対応する全てのAIクライアントが接続できます。

2025年はMCPのブレイクスルーの年でした。OpenAIが3月にサポートを発表、Google DeepMindが4月に追随、MicrosoftがMCPをSemantic Kernel、Azure OpenAI、Copilot Studio、Agent 365に統合。12月にはAnthropicがMCPをLinux FoundationのAgentic AI Foundationに寄贈し、OpenAI、Google、Microsoft、AWS、Cloudflareが全て創設メンバーとして参加しました。

2026年Q1までに、エコシステムは驚異的な規模に膨張しました。公式レジストリには9,400以上のサーバーが登録され、公式TypeScript・Python SDKの月間ダウンロード数は9,700万回（2026年Q1時点）。プロトコル自体も当初の3プリミティブから5つ（tools、resources、prompts、sampling、roots）に拡張され、トランスポート層にStreamable HTTPが追加されました。2026年5月24日時点で、エコシステムは複数のディレクトリに分散：公式レジストリは9,652以上、PulseMCPなどのサードパーティディレクトリでは16,500以上を追跡しており、プラットフォーム、企業内部、コミュニティへの広範な普及を示しています。4月2-3日にニューヨークで開催されたMCP Dev Summit NA 2026（参加者1,200名、前回比2倍）では、Uber・Bloomberg・Duolingoなどが本番環境での導入事例を発表し、MCPがエンタープライズインフラとして確立したことを示しました。

そして、反転が起きました。

2026年2月、Eric Holmesがあの投稿を公開。核心の主張はシンプルでした。LLMは既に十分に賢い。CLIツールとドキュメントを与えればタスクを完遂できる。なぜMCPという抽象レイヤーを追加する必要があるのか？ Pieter Levels（levelsio）もXで同調し、「MCPはllms.txtと同様、AIが実際には必要としない不要な抽象だ」と述べました。

しかし、この論争の答えは白黒つけられるものではありません。MCPは死んだのではなく、ハイプのピークからガートナーの幻滅の谷（trough of disillusionment）に入っただけです。本当の問いは「MCPは良いか悪いか」ではなく、「いつMCPを使うべきか」なのです。

3層アーキテクチャの分解：MCP・Skill・CLIの本質的な違い

多くの人がMCP・Skill・CLIを「AIにツールを使わせる方法」として一括りにしています。しかし実際には全く異なるアーキテクチャ層に位置しており、この理解が正しい選択の前提となります。

能力層：MCP

MCPが解決するのは「AIに何ができるか」です。統一インターフェースを通じてAIをデータベース、API、クラウドサービスに接続する標準プロトコルです。従来のAPIとの決定的な違いは、AIが実行時に利用可能なツールを動的に発見できる点です。プロンプトに各ツールの使い方をハードコードする必要がありません。

プロセス層：Skill

Skillが解決するのは「AIがどう作業すべきか」です。本質的にはMarkdown形式のワークフロー指示で、作業の順序、品質基準、判断ロジックを定義します。2025年末以降、Skillエコシステムは急速に進化しています。Hooks（2025年9月）がイベント駆動の確定的スクリプト実行を提供し、Agent Teams（2026年2月）で複数のClaudeセッションが相互調整・並行作業が可能になりました。コミュニティではmattpocock/skillsなどのオープンソースSkillパッケージも登場しています。実際の使用経験として、私はSkillでコンテンツ制作パイプライン全体を定義し、Hooksでツール呼び出し後の自動検証を、Agent Teamsでマルチエージェント並行執筆を実現しています。

実行層：CLI

CLIは最も直接的なアプローチです。AIがBash経由でマシン上の既存コマンドラインツールを呼び出します。git、curl、npm、ghなど、もともと使っているツールをAIもそのまま使えます。

比較一覧

次元	MCP	Skill	CLI
本質	ツール接続プロトコル	ワークフロー指示（プロンプト）	コマンドラインツール
解決すること	AIに何ができるか	AIがどう作業すべきか	AIが直接実行
媒体	サーバープロセス	Markdownファイル	既存システムツール
クロスプラットフォーム	全MCPクライアント	主にClaude Code	シェルのある全環境
メンテナンスコスト	高（サーバー運用）	極めて低（プレーンテキスト）	ほぼゼロ
最適な例え	USB-Cポート規格	SOPマニュアル	ポケットのスイスアーミーナイフ

重要な洞察：この3つは排他的ではありません。最も賢いアプローチは3層を併用することです。Skillでプロセスを定義し、CLIで大部分のタスクを処理し、MCPはクロスプラットフォーム配布やエンタープライズガバナンスが必要な場合にのみ有効化します。

ベンチマーク実測：CLIはどれだけ優位か

データは意見より説得力があります。私自身のコンテンツパイプラインは毎日数十回のCLI呼び出し（git、curl、ファイルシステム操作）を実行していますが、MCPで起きがちなSchema肥大化やコネクションタイムアウトの問題に遭遇したことはありません。ただし体感だけでは不十分なので、ハードデータを見てみましょう。Scalekitの75回のベンチマークテストによると、CLIは効率指標でMCPを圧倒しています：

指標	CLI	MCP（直接接続）	差
トークン消費量（GitHubクエリ）	1,365	44,026	32倍
月額コスト（1万回操作）	$3.20	$55.20	17倍
成功率	100%	72%	CLI優位

なぜこれほど差があるのでしょうか？原因は「Schema肥大化」です。AIがMCPサーバーを呼び出すたびに、サーバーは全ツールの定義をコンテキストウィンドウに注入します。GitHub MCPサーバーを例に取ると、43個のツールがあり、実際に使いたいのが1つだけでもSchema自体が大量のトークンを消費します。

ただし、MCPがあらゆるシナリオで実用に耐えないわけではありません。MCPの前段にAPIゲートウェイを配置してSchemaフィルタリングとコネクションプールを管理すれば、コストを約$5/月に抑え、信頼性を99%以上に引き上げることが可能です。ただし、これはアーキテクチャの複雑性を増すため、個人開発者には割に合わない可能性が高いです。

30秒意思決定フレームワーク

記事全体を読む時間がない方は、このデシジョンツリーをどうぞ：

AIが複数の異なるユーザーの代理として操作する必要がありますか？（OAuth認可、テナント分離、監査要件）

はい → MCPを使用。これがMCPの真に代替不可能なユースケースです。

自分のワークフローを自動化したいだけですか？

はい → CLI + Skill。エージェントがローカル権限を継承すれば十分です。

接続先のサービスにCLIはありますか？

ある（git、gh、npm、aws-cli...）→ CLIを直接使用
ない（Notion、Figma、SlackなどAPIのみ）→ コミュニティの既存MCPサーバーを利用

AIにワークフローを教えたいだけですか？

はい → Skillを使用（またはプラットフォーム対応のプロンプト設定ファイル）

3つの典型シナリオ

シナリオA：個人開発者がClaude Codeでサイドプロジェクトを開発 → CLI + Skill。Bashでできることにはそもそもそれで十分です。Skillでコードレビュー基準やコミット規約を定義。最低コスト、最高信頼性。

シナリオB：SaaS製品でユーザーがAI経由で自分のStripeアカウントを管理 → MCPが必要。各ユーザーが独自のOAuthトークンを持ち、テナント分離とアクセス制御が求められます。CLIでは対応できません。

シナリオC：チームがCursorとClaude Codeの両方で社内wikiを検索したい → MCPが合理的。MCPサーバーを1つ構築すれば、2つのクライアントが接続可能。統合の重複作業を回避できます。

セキュリティリスクの開示：MCP利用前に知るべきこと

MCPの利便性は、実際のセキュリティリスクと表裏一体です。理論上の仮定ではありません。

Coalition for Secure AI（CoSAI）は2026年のホワイトペーパーで12のコア脅威カテゴリに約40の独立した脅威を特定しました。ZuploのMCPレポート（公開エコシステム調査）によると、現在公開MCPサーバーの24%は認証メカニズムが一切ありません。別のBloomberry調査では1,412のサーバー（公開・非公開含む）を分析し、ゼロ認証の割合は38.7%——サンプルのカバレッジの違いから数字が異なります。

2026年4月：OX SecurityがSTDIOアーキテクチャレベルのRCEを公開

2026年4月に状況が急激にエスカレートしました。OX Securityが公開したMCP STDIOトランスポート層のアーキテクチャレベルのリモートコード実行（RCE）脆弱性は、1.5億回以上のSDKダウンロードと最大20万の脆弱なインスタンスに影響。Cursor、VS Code、Windsurf、Claude Code、Gemini CLIの全てが対象でした。OX Securityは30件以上の責任ある開示と10件以上のHigh/Critical CVE（CVE-2026-30623のコマンドインジェクションを含む）を発行しましたが、Anthropicは「期待される動作」としてプロトコルアーキテクチャの修正を拒否しました。

実際に発生した攻撃

プロンプトインジェクションハイジャック：攻撃者が公開GitHubのIssueに悪意ある指示を埋め込み、AIエージェントがそれを読み取って乗っ取られ、企業のプライベートリポジトリからデータが流出
サプライチェーン攻撃：npmに偽のPostmark MCPサーバーが出現。表面上は正常に動作するが、実際には全てのメールを攻撃者にBCC送信
SQLインジェクション：SupabaseのMCPがサポートチケット内のSQLインジェクションで悪用され、高権限の統合トークンが漏洩

AIエージェントのセキュリティ防御フレームワークについてさらに詳しく知りたい方は、こちらの完全ガイドをご覧ください。

MCP利用前の防御チェックリスト

最小権限の原則：MCPサーバーにはタスク完了に必要な最小限のアクセススコープのみを付与
独立した入力検証：LLMのツール呼び出し判断を盲目的に信頼せず、機密操作の前に独立した検証レイヤーを追加
ソースの確認：MCPサーバーのインストール前にソースが信頼できることを確認。出所不明のサードパーティサーバーは避ける

まとめ

MCPは死んでいません。ただし、その真の価値は「配布」と「ガバナンス」にあり、「効率」ではありません。

個人開発者やデジタルワーカーにとって最も実践的な戦略は、CLI + Skillをデフォルトにし、MCPは必要に応じて利用することです。コマンドラインツールがあるタスクにはCLIを、ワークフローの定義にはSkillを使い、クロスプラットフォーム配布やCLIのないクラウドサービスへの接続が必要な場合にのみMCPを導入します。

これは3つから1つを選ぶ問題ではなく、3層アーキテクチャがそれぞれの役割を果たす設計です。各層が何を解決するかを理解すれば、「MCPは死んだ」「MCPは必須」といった極端な意見に振り回されることはなくなります。

Skillを実際に試してみたい方は、コミュニティSkillsとAgent Fleet完全ガイドでゼロからワークフローを構築する方法を解説しています。MCPを使う場合は、ベストMCPサーバーガイドで検証済みサーバーの推薦を参考にしてください。