MCPは死んだ？SkillとCLIでは代替できない3つのシナリオ
2026年2月末、「MCP is dead. Long live the CLI」という投稿がHacker Newsのトップページに登場し、議論が爆発しました。「MCPは不要な抽象レイヤーだ」という声がある一方、「大手テック企業が全て参画している」という反論も。Claude CodeやCursorで「MCPサーバーを導入すべきか」迷っているなら、この記事がベンチマークデータと30秒の意思決定フレームワークで判断をサポートします。
TL;DR
- MCPは死んでいない。ただし解決するのは「マルチユーザー・クロスプラットフォームのツール配布」であり、個人のコーディング作業ではない
- CLIはトークン効率でMCPの10〜32倍、成功率はほぼ100%
- Skillはプロセス知識（AIに「やり方」を教える）、MCPはツール能力（AIに「できること」を与える）。補完関係であり、競合ではない
- 個人開発者向け：CLI + Skillを基本にし、Notion/FigmaなどCLIのないクラウドサービスが必要な時だけ既存のMCPサーバーを利用
- MCPのセキュリティリスクは無視できない：CoSAIホワイトペーパーは40以上の脅威カテゴリを列挙、公開サーバーの24%が認証ゼロ
「MCPは死んだ」論争の経緯
MCP（Model Context Protocol）は、Anthropicが2024年11月にリリースしたオープンプロトコルで、AIシステムが統一インターフェースで外部ツールやデータソースに接続できるようにするものです。よく使われる例えは「AIのUSB-C」。MCPサーバーを一度構築すれば、対応する全てのAIクライアントが接続できます。
2025年はMCPのブレイクスルーの年でした。OpenAIが3月にサポートを発表、Google DeepMindが4月に追随、MicrosoftがBuildカンファレンスでWindowsエコシステムに統合。12月にはAnthropicがMCPをLinux FoundationのAgentic AI Foundationに寄贈し、OpenAI、Google、Microsoft、AWS、Cloudflareが全て創設メンバーとして参加しました。
そして、反転が起きました。
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形式のワークフロー指示で、作業の順序、品質基準、判断ロジックを定義します。実際の使用経験として、私はSkillでコンテンツ制作パイプライン全体（トピック選定から翻訳まで）を定義しており、AIはSkillを読むだけで各ステップで何をすべきか、どのフォーマットで出力すべきかを把握できます。
実行層：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はありますか？
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年のホワイトペーパーで40以上のMCP固有の脅威カテゴリを特定しました。ZuploのMCPレポートによると、現在公開MCPサーバーの24%は認証メカニズムが一切ありません。
実際に発生した攻撃
- プロンプトインジェクションハイジャック：攻撃者が公開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を実際に試してみたい方は、Claude Code Skills完全ガイドでゼロからワークフローを構築する方法を解説しています。
FAQ
大手テック企業が全てMCPを支持しているのに、なぜ「死んだ」と言われるのですか？
「死んだ」というのは採用率ではなく効率の話です。MCPは個人開発のタスクでCLIの4〜32倍のトークンを消費し、失敗率も高いです。大手企業がMCPに賭けるのは、エンタープライズガバナンス、マルチテナント認可、クロスプラットフォーム配布の価値を見込んでいるからで、個人開発者の日常利用とは全く異なるシナリオです。「MCPは死んだ」は過度なハイプへの反発であり、プロトコル自体の終焉ではありません。
個人開発者ですが、今MCPを学ぶべきですか？
大きな時間を投資する必要はありません。CLIとSkillの組み合わせで成功率はほぼ100%、トークン効率はMCPの10〜35倍で、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があり、コンセプトは同じでフォーマットが違うだけです。
