「CLIがMCPに勝った」は本当か——議論の前提を分解する¶

対象:

「CLI vs MCP」論争の背景を理解したいエンジニア
エージェント設計でツール統合の方針を決めたい実務者
1年後に読み返しても使える判断軸が欲しい方

この記事のポイント¶

CLI優位論はshell-native開発では当たっているが、一般理論としては広げすぎ
本当に負けたのは「MCPプロトコル」ではなく「大量ツールを事前ロードする実行パターン」
議論を整理するには「実行層・接続層・統制層」の3層で見る必要がある

何が起きているのか¶

2026年2月末、Eric Holmes氏が「MCP is dead. Long live the CLI」を公開した。Hacker Newsで大きな反響を呼び、CLI優位論が一気に加速した。Mario Zechner氏のベンチマーク（MCP約52,000トークン vs CLI約1,200トークン）、Y CombinatorのGarry Tan氏による批判、Perplexity CTOのMCP離れ表明が続き、「MCPの時代は終わった」という空気が形成されつつある¹²³。

一方で、同時期にMCP擁護側からも体系的な反論が出ている。Charles Chen氏は「MCP is Dead; Long Live MCP!」でstdioとHTTPの区別を論じ、Permit.ioはエンタープライズインフラとしてのMCPの価値を主張している⁴⁵。

どちらが正しいのか。結論を急ぐ前に、議論がなぜ噛み合わないのかを分解する。

この記事の見取り図：3層モデル¶

最初にこの記事の判断フレームを提示する。これは公式な分類ではなく、各社の実装や設計思想の差分を説明するための分析フレームである。CLI vs MCPの議論は、ツール統合を3つの層に分けると見通しが良くなる。

実行層： repo操作、ビルド、テスト、ファイル操作など、エージェントが「手を動かす」部分。ここはshell/CLIが強い。AnthropicもOpenAIもshell系の正式サポートを強化し続けており、モデル進化がそのまま効く領域である。

接続層： 外部SaaS、リモートデータソース、社内ナレッジなど、エージェントが「外と繋がる」部分。ここはCLIが存在しない、または貧弱なサービスが多い。MCPか、それに近いconnector標準が残る可能性が高い領域である。OpenAIはremote MCPをChatGPT apps、deep research、company knowledgeなどの拡張面として提供している⁶。

統制層： 認証・認可・監査・配布など、エージェントを「管理する」部分。モデルの知能向上では代替しにくく、エージェントが強くなるほどむしろ必要性が増す領域である。MCP仕様のauthorizationや、Claude Codeのmanaged-mcp.jsonはこの層に関わる。

この3層を分けずに「CLI vs MCP」を論じると、実行層の話と統制層の話が混線する。以下では、このフレームに沿って双方の主張を検証していく。

議論が噛み合わない理由：「MCP」の3つの顔¶

「MCP」という言葉が少なくとも3つの異なるものを同時に指していることも、混線の原因になっている。

1つ目は、プロトコルとしてのMCP。 LLMと外部サービスの接続を標準化するオープンプロトコルであり、Linux Foundation傘下のAgentic AI Foundation（AAIF）に寄贈され、OpenAI・Google・Microsoft・AWSが採用している⁷。JSON-RPCベースの仕様そのもの。

2つ目は、実行パターンとしてのMCP。 全ツール定義を事前ロードし、モデルにdirect tool callingで選ばせ、中間結果をそのまま文脈に戻す——という使い方。

3つ目は、運用統制としてのMCP。 認証・認可・監査・配布を一元化する制御面として機能するMCPサーバーの運用形態。

CLI優位論の多くは2つ目への批判であり、MCP擁護論の多くは1つ目と3つ目の価値を主張している。ここを分けると、双方はかなり両立する。

CLI優位論の根拠を検証する¶

CLI優位論の主な根拠を、効率・運用・統制の3つに束ねて検証する。

効率：トークン消費と既知性¶

Zechner氏のベンチマークでは、MCPのアクセシビリティツリーが約52,000トークンを消費したのに対し、CLIの選択的クエリは約1,200トークンだった。GitHub MCPサーバーは93のツール定義で約55,000トークンを消費するが、同等機能のCLIツールのREADMEは225トークンで済む²。CLIのトークン効率が高い理由の1つは、モデルの訓練データにBashコマンドの用例が大量に含まれていること。git、gh、jq、curlなどの使い方をモデルが既知のため、探索コストがほぼゼロになる。

成立条件： 全ツール定義を事前ロードするdirect tool callingパターンで、成熟した有名CLIが対象の場合、この効率差は現実に発生する。

限界： この数字は「MCPプロトコル自体の宿命」ではなく、「現在よくあるeager loadの運用パターン」の問題である。AnthropicはTool Search Toolで85%削減、Programmatic Tool Callingで平均37%削減を実現している⁸。また、トークン効率におけるCLIの訓練データ優位は、MCPエコシステムの拡大とともに今後相対化されうる。コンテキストウィンドウの拡大とトークン単価の低下が進めば、この差が意思決定を左右する比重自体が下がる可能性もある。

運用：認証とプロセス管理¶

Holmes氏は、CLIが既存の認証基盤（SSO、gh auth login等）をそのまま使える点と、MCPサーバーのバックグラウンドプロセス維持が不安定になる点を批判した¹。

成立条件： 個人の開発マシンで、1人のエンジニアが1つのエージェントを動かす場合は、既存の資格情報に乗せるのが最もシンプル。stdio上のローカルMCPサーバーでは、プロセス管理の摩擦も現実に存在する。

限界： HTTP上のリモートMCPサーバーでは、話が変わる。サーバー側の運用はインフラチームが担当し、クライアントはHTTPエンドポイントを指すだけになるため、運用の複雑性がクライアント側からサーバー側に移る（消えるわけではなく、責務の場所が変わる）。認証についても、リモートMCPサーバー経由であれば、ユーザーはOAuth/SSOで認証し下流のAPIキーに触れない設計を組みやすい⁹。ただし、CLIでもOAuth＋短寿命トークン＋revocationで同等の設計は可能であり、これは「CLI vs MCP」の問題というより認証アーキテクチャの設計問題でもある。

統制：権限粒度とラッパー問題¶

Claude Codeでは、CLIならコマンド単位（gh pr viewは許可、gh pr mergeは承認要求）で制御できるが、MCPツールはツール名単位でしか許可設定できない。また、Holmes氏は「GitHub MCPサーバーはgh CLIの再実装であり、抽象化レイヤーを足した結果、コストが増えデバッグが困難になっている」と指摘した¹。

成立条件： 2026年3月時点のClaude Code実装では、shell制御の方が自然に細かい粒度を持つ。GitHub、filesystem、Dockerなど成熟したCLIが既にある領域では、ラッパー批判もかなり当たる。

限界： 権限粒度については、MCP仕様自体はツールごとのannotation（readOnlyHint、destructiveHint等）を持ち、将来より細かいポリシー実装の材料はある。ただし、これらはあくまでhintであり、信頼できないサーバー相手にそれだけで意思決定してはいけないと仕様側が明記している。現時点では成熟CLIに対するshell制御の方が自然に細かい。ラッパー問題については、CLIが存在しない、または貧弱なSaaS（Notion、Jira、Slack等のREST API）では「ラップすべきCLI」がそもそもない。ここではエージェント向けの接続面として、MCPが候補の1つとして機能する。

見落とされている分水嶺：stdio vs HTTP¶

CLI vs MCPの議論で最も欠落しているのが、MCPの通信形態による区別である。Chen氏がこの点を体系的に論じている⁴。

stdio上のMCP（ローカル実行） では、MCPサーバーがローカルでエージェントと同居して動く。この形態では、CLIの方がシンプルであるという批判はかなり当たる。Chen氏自身「stdio modeではMCPは不要で、CLIの方が良い」と認めている。

HTTP上のMCP（リモート実行） では、MCPサーバーが中央のサーバーとして動き、複数のクライアントがHTTP経由で接続する。この形態では、認証情報のローカル散在を減らしやすく、テレメトリや運用責任を中央に寄せやすい。IT管理者がサーバーを配布・制御する設計も取りやすくなる。GitHub Actionsのようなエフェメラルな実行環境でも、HTTPエンドポイントを指すだけで複雑なバックエンドを利用できる。

CLI優位論の多くは、stdioモードのMCPをCLIと比較している。HTTPモードのMCPが解いている問題は、CLIとは別の次元にある。

「モデルが強くなればMCPは不要になる」は本当か¶

Zenn記事の核心的な主張は「MCPの設計前提（モデルがCLIを理解できない）がモデル進化で無効化された」というものだった¹⁰。この主張を3層モデルで検証する。

実行層では、CLI/shellの優位はさらに広がる可能性が高い。 モデルが強くなるほど、helpやmanページを読む力、エラー回復、複数コマンドの試行錯誤が改善する。ここはCLI側の見立てが堅い。

しかし、統制層では、モデルが強くなるほど必要性が上がる。 強いエージェントほど実行できることが増えるため、誤操作時の影響範囲も広がる。identity、authorization、audit、observabilityの需要はエージェント能力に比例して増える。

接続層でも、標準化の価値は残る。 「○○を作ってください」と言えば出来上がる世界を想像すると、そのエージェントは数十のサービスに接続し、認証を通し、操作を実行する。このとき必要なのは「Bashコマンドを叩く能力」ではなく、「多数のサービスと標準的な方法で接続・認証・操作できるプロトコル」になる。

つまり、モデル進化はゼロサムではない。実行層ではCLIで済む範囲が広がり、接続層・統制層ではMCPの価値の重心が「モデル補助」から「接続・統制」へ移る。「モデルが強くなればMCPは不要」ではなく、「MCPの存在意義が変わる」が正確な見立てである。

本当に負けたのは何か¶

ここまでを1文で言えば、負けたのはMCP一般ではなく、eager-loadedな実装パターンである。

具体的に否定されたのは以下の1つである。

「大量のツール定義を事前にロードし、モデルにdirect tool callingで全部選ばせ、中間結果をそのまま文脈に戻す」というeager-loadedな実行パターン。

これはMCPに限った話ではない。非MCP環境でも、大量のtool surfaceをeager loadする設計全般が不利になっている。Anthropic（Tool Search、Programmatic Tool Calling）もOpenAI（tool_search）も、deferred loadingに向かっている⁸。

一方、以下は否定されていない。

MCPプロトコルの仕様としての価値（標準化された接続面）。HTTP上のリモートMCPサーバーの運用価値（認証設計、テレメトリ、配布を中央に寄せやすい構造）。Resources、Prompts、Sampling、Elicitationといった、Tool以外のプリミティブ。エコシステムの蓄積（AAIF管理、OpenAI・Google・Microsoft・AWS採用）⁵⁶⁷。

条件分岐マップ¶

3層モデルに沿って、判断の分岐を示す。具体例として、ある開発チームがエージェントにタスクを任せる場面を想像すると：repo編集・テスト実行・PR作成はCLI-first。Notion・Jira・社内ナレッジの横断検索はMCP-first。監査対象がサービス接続単位で、ITがエージェントの接続先を統制したい場合はmanaged/remote MCPを経由させる。

CLI-firstになる条件¶

エージェントの実行責任がローカルにある（手元で完結する）
操作対象に成熟したCLIが存在する（gh、git、docker、kubectl、jq等）
認証を個別の環境資格情報で持てる
監査の対象が「どのコマンドを実行したか」である
1つのクライアントが専用で使う

MCP-firstになる条件¶

実行責任を中央集約したい（ITが統制する）
対象がリモートSaaS/HTTP APIで、CLIが存在しないか貧弱
認証を中央で握り、個々のエージェントに鍵を渡したくない
監査の対象が「どのサービス接続をどう使ったか」である
同じ統合を複数クライアントから再利用したい

hybrid（多くの現場のデフォルト）¶

実行層（repo操作・ビルド・テスト）はCLI
接続層（外部SaaS連携・社内ナレッジ接続）はMCP
統制層が必要な接続面だけMCPサーバーを経由させる

まとめ¶

「CLIがMCPに勝った」は、shell-native開発の実行層では当たっている。しかし、それをMCPプロトコルの終焉として一般化すると、接続層と統制層で反証が出る。

本当に起きていることは、より正確にはこうである。

eager-loadedなdirect tool callingが、shell-nativeな開発ワークフローで優位を失った
MCPの価値の重心が、「モデル補助」から「接続・統制・再利用」に移りつつある
モデルが強くなるほど、実行層ではCLIが広がり、統制層ではMCPの必要性が強まる

実務的な判断は、以下の1文に圧縮できる。

CLIで済むところにMCPを足さない。ただし、MCPでしか綺麗に解けない統合面には遠慮なく使う。

補足：この議論の賞味期限について¶

この記事で述べた「トークン効率」「ベンチマーク数値」は、2026年3月時点の制約条件に強く依存する。コンテキストウィンドウの拡大、トークン単価の低下、Tool SearchやProgrammatic Tool Callingの成熟が進めば、トークン効率を理由にCLIを選ぶ必然性は薄れる。

1年後に残るのは、おそらく「実行層・接続層・統制層」の分業構造の方だろう。どの層にどのツールを置くかという設計判断は、トークン単価が変わっても有効性を保つ。

なお、MCPとSkillsの使い分けについては関連記事を参照されたい。本記事はCLIという軸を加えた上で、議論全体を再検証したものである。