MCPはなぜCLIに負けたのか —— 経緯と構造を整理する

2024年11月、AnthropicがMCP（Model Context Protocol）を発表したとき、業界は一気に動いた。各社がMCPサーバーを競って実装し、「AI first」の証明としてMCP対応をアピールした。

それから約1年半。2026年3月現在、MCPの優位性はほぼ失われている。MCP不要論がHacker Newsのトップに繰り返し上がり、Anthropic自身がMCPのスケーリング問題を公式に認め、回避策をドキュメント化している。

この記事では、MCPがCLIに対して優位だった期間がなぜ短かったのか、その経緯と構造を整理する。

MCPが解決しようとした問題

MCPの設計前提は「モデルがツールのインターフェースを自力で理解できない」だった。

2024年11月時点の最先端はClaude 3.5 Sonnet。ツール呼び出しは可能だったが、複雑なCLI出力の安定的な解釈や、マルチステップの認証フローの自律的なハンドリングはまだ不安定だった。エージェントという概念自体、話題にはなっていたが実際に動くものはほとんどなかった。

そこでMCPは、モデルとツールの間にJSON-RPCベースの仲介層を置いた。ツールの入出力をスキーマとして構造化し、モデルに「何ができるか」を明示的に伝える。モデルが自力で理解できないなら、構造化された形式で教えてやればいい。2024年11月時点では、合理的な設計判断だった。

モデルの進化が前提を崩した

2025年、推論モデル（OpenAIのo1、o3）の登場で状況が変わった。エラーから出発してコードベースの複数レイヤーを辿り根本原因を特定する、という種類の推論が可能になり、ツール使用と推論の組み合わせでコーディングエージェントが実用レベルに達した。

2026年3月現在、Opus 4.6はjqやDuckDB CLIを使って大規模構造化データを自律的に探索し、行き詰まったら自分で別のクエリ戦略を試せるレベルにある。manページやヘルプテキストを読むだけで適切なコマンドを組み立てられる。

MCPが解決しようとした「モデルがツールのインターフェースを理解できない」という問題を、モデル側の進化が解消した。補助輪を業界標準として規格化している間に、本体が補助輪なしで走れるようになった。

数字で見るコンテキスト効率の差

Mario Zechnerが2025年8月に公開したベンチマークが、MCPとCLIのコンテキスト効率の差を定量的に示している。

ブラウザ操作のテストでは、MCPのアクセシビリティツリーのスナップショットが52,000トークンを消費したのに対し、CLIの選択的クエリは1,200トークン。43倍の効率差。GitHub MCPサーバーは93のツール定義で55,000トークンを食う。質問を投げる前にコンテキストウィンドウの大部分が埋まる。

一方、Zechnerが自作したCLIツールのREADMEは225トークン。モデルはBashの使い方を既に知っているので、ゼロから教える必要がない。トレーニングデータに含まれる既存知識に乗れるのが、CLIの構造的な強みになっている。

Zechner自身の結論は「MCPかCLIかは配管の問題で、重要なのはツールの設計品質」という穏当なものだったが、11月にはさらに踏み込んで「What if you don't need MCP at all?」という記事を出している。Playwright MCPの21ツール（13,700トークン）やChrome DevTools MCPの26ツール（18,000トークン）に対し、同等機能のCLIツールのREADMEが225トークンで済むという比較は、設計品質の問題だけでは片付かない構造差を示している。

なお、CLIにも隠れたコストはある。Claude Codeはコマンド実行ごとにセキュリティチェックを行うため、MCPコールでは発生しないトークンオーバーヘッドが存在する。

Anthropicの自己矛盾

この話で最も重要なのは、MCPを設計したAnthropic自身がスケーリングの限界を公式に認めている点だ。

2025年11月、Anthropicは「Code execution with MCP」というエンジニアリングブログを公開した。

MCPサーバーを接続しすぎると、ツール定義と結果がコンテキストを圧迫してエージェントの効率が下がる

Anthropic内部では、ツール定義だけで134,000トークンを消費するケースがあった。5サーバー構成で58ツール、約55,000トークン。Jiraだけで約17,000トークン。10サーバーも繋げば100,000トークンを超える。

対策として提案されたのは、MCPサーバーをコードAPIとして提示し、エージェントがツールを直接呼ぶ代わりにコードを書いてやり取りする方式だった。従来150,000トークンかかっていたワークフローが約2,000トークンに。98.7%の削減。

2026年にはさらに「Tool Search Tool」を発表。全ツール定義の事前ロードをやめ、オンデマンドで発見する方式に切り替えた。Opus 4の精度は49%→74%、Opus 4.5は79.5%→88.1%に改善した。

つまりAnthropicは、MCPのスケーリング問題に対して「MCPをそのまま使わない方法」を自ら提案している。プロトコルの設計者が、プロトコルの回避策をドキュメント化した。

Eric Holmesの「MCP is dead」

2026年2月28日、Eric Holmesが「MCP is dead. Long live the CLI」を公開。Hacker Newsで85ポイント・66コメントを集めた。

Holmesの論点は3つ。

認証の問題。 CLIは既存の認証基盤（SSO、kubeconfig、gh auth login）をそのまま使える。MCPは独自の認証レイヤーを要求する。複数のMCPツールを使えば、認証が際限なく発生する。

プロセス管理の問題。 MCPサーバーはバックグラウンドプロセスとして起動・維持する必要がある。初期化が不安定で、Claude Codeの再起動を余儀なくされることがある。CLIはディスク上のバイナリを呼ぶだけで、プロセス管理が不要。

権限粒度の問題。 Claude Codeでは、MCPツールの許可はツール名単位でしかできない。CLIならgh pr viewは許可してgh pr mergeは承認を要求する、といった粒度の制御ができる。

Holmesの指摘で特に効いているのは、「ほとんどのMCP実装は結局CLIツールをラップしているだけ」という点だ。GitHub MCPサーバーはGitHub CLIの再実装であり、ファイルシステムMCPサーバーは標準のファイル操作コマンドのラッパーにすぎない。抽象化のレイヤーを足した結果、トークンコストが増え、認証が複雑になり、デバッグが困難になっている。

Hacker Newsの温度変化

HNでのMCP評価を時系列で追うと、懐疑論が段階的に高まっていく様子がわかる。

2025年4月 —「Everything wrong with MCP」。プロトコルは初期段階だがAnthropicはコミュニティの声を聞いて改善している、と比較的好意的。認証仕様のRFCにはMicrosoft、Auth0、Stytchなどが参加しており、エコシステムとしての期待感があった。

2025年8月 —「MCP overlooks hard-won lessons from distributed systems」。MCPサーバーが不正な出力を返し、LLMがそれを元に幻覚を起こし、下流のシステムに影響する大規模インシデントの可能性が指摘された。分散システムの知見が活かされていないという批判。

2026年1月 —「MCP is a fad」。「USB規格と同じで標準化に価値がある」という擁護と、「ローカルスクリプトで十分」という反論が拮抗。

2026年3月 —「MCP is dead. Long live the CLI」。セキュリティとサンドボックスがMCP擁護側の主な論点として残るが、実運用での摩擦が上回っているという報告が多数。

MCPとTools（Function Calling）の混同

MCPを巡る議論で見落とされがちなのは、MCPとTools（Function Calling）がしばしば混同されている点だ。

MCPは初期からFunction Callingと同等の扱いを受けているが、MCPはあくまで呼び出しの手続きに関するプロトコルであり、Toolsはモデルが外部機能を呼び出す仕組みそのものだ。レイヤーが違う。

この混同を解きほぐすと、「真に強力なのはToolsであり、MCPはToolsの不自由な下位互換にすぎない」という見方が出てくる。実際、エージェント型の開発環境において現在最も優れた体験を提供しているのはTools/Function Callingの仕組みであり、MCPではない。

MCPのServer Instructionsやツール定義のドキュメンテーションについても、「良いドキュメントを揃えることが重要だ」という議論がある。しかし本質的には、モデルの性能向上とともに、公開情報を網羅的に解釈してインターフェースを適切にハンドリングする能力は上がり続ける。ドキュメントの質やオンボーディングの整備度が問題になるのは、モデルの能力が不足していた時期の話であって、モデルが公式リファレンスやAPIドキュメントを自力で読んで理解できるなら、MCPサーバー側に専用の指示を内蔵する必要性は薄れる。

MCPが有効な領域

以上を踏まえた上で、MCPに居場所がないわけではない。

CLIが存在しないサービスやWeb API onlyのSaaSでは、何らかの仲介層は依然として必要になる。IDE統合（Cursor、Claude Desktop）のように、シェル環境を前提にできないクライアントでもMCPは機能する。非エンジニアユーザー向けのAIアシスタントにとっては、CLIはそもそも選択肢にならない。

また、MCPの「ツールの能力を機械可読な形式で宣言する」という設計思想自体は筋が悪いわけではない。問題は、その宣言にかかるトークンコストがモデルの自力理解コストを上回った、というタイミングの話だ。

もうひとつ、MCPの interoperability——1つのMCPサーバーを立てれば複数のMCP対応クライアントから繋がる——を評価する声もある。Slack APIやNotion APIなど、個別にAPI統合コードを書かなくて済む利便性は確かにある。ただし、これはシングルエージェント構成では優位にならない。複数のMCP対応クライアントを横断的に運用する場面でのみ活きる価値であり、それがどれだけの開発者に該当するかは疑問が残る。

「プロトコルとしての可換性」は反論になるか

この記事を公開した後、「MCPとCLIはレイヤーが違う。Coding Agentユーザーの視点だけで語るべきではない」という意見を目にした。複数のクライアント（ChatGPT、Claude、Difyなど）から同じツールを触らせたいとき、MCPの可換性——1つのMCPサーバーを立てれば全クライアントから繋がる——に価値がある、という主張だ。

これは一見もっともらしいが、2つの点で疑問がある。

具体的な代替手段がすでに存在する。 十分に優秀なモデルが前提なら、OpenAPIスキーマやRESTエンドポイントを1つ公開するだけで、どのクライアントのモデルもそれを読んで叩ける。複数クライアントからの可換性はMCPの専売特許ではなく、既存のAPI標準でも成立する。MCPサーバーを立てて運用するのと、既存のRESTインフラに乗るのと、どちらが軽いかは自明ではない。むしろ既存インフラに乗れる分、REST側が軽い場面は多い。

そもそもの構造として、これはインターフェースからデータリソースまでの「距離」の問題でしかない。 十分に優秀なモデルが動く世界では、LLMをインターフェースの近くに配置して、リソースへは簡素なAPIで直接繋げばいい。CLIだろうとMCPだろうと、仲介層が簡素であるほどリソースまでの距離は短くなる。MCPの規格としての優位性は、その距離を縮める手段のひとつにすぎず、唯一の解ではない。

もうひとつ付け加えると、「非エンジニアユーザーやリテラシーの低いユーザー向けにMCPが有用」という議論もあるが、構造化された仲介が必要なほどツールを自力で扱えないモデルが、今後サービスとして実用に耐えるだろうか。モデルの能力は上がる一方で、下がることはない。MCPが前提とする「モデルの能力不足」は、時間が経つほど解消される方向にしか進まない。

構造的な教訓

MCPの経緯が示しているのは、「モデルの能力不足を補う技術は、規格化が完了する前にモデルが追い越すリスクがある」 ということだ。

MCPが設計された2024年11月から、CLIの優位が明確になった2026年初頭まで、約1年。この間にモデルはCLI出力の安定的な解釈、マルチステップ推論、自律的なエラー回復といった能力を獲得した。MCPが標準化のプロセスを進めている間に、MCPの存在意義を支えていた前提が消えた。

これはMCPに限った話ではない。RAGの最適構成、プロンプトエンジニアリングのベストプラクティス、エージェントのオーケストレーション設計——モデルが1世代進むたびに前提が崩れうる領域は多い。AIツールチェーンの上に「標準」を建てることの構造的な難しさを、MCPの1年半は端的に示している。

---

参考リンク

• MCP is dead. Long live the CLI — Eric Holmes (2026/2/28)
• MCP vs CLI: Benchmarking Tools for Coding Agents — Mario Zechner (2025/8/15)
• What if you don't need MCP at all? — Mario Zechner (2025/11/2)
• Code execution with MCP — Anthropic Engineering (2025/11)
• Advanced tool use — Anthropic Engineering (2026)
• Model Context Protocol 公式