「CLIはMCPより信頼性100% vs 72%・最大32倍安い、MCPを捨てろ」は本当か？ 2026

炎上したクレームの中身

2026年、AIエージェント界隈で「CLI vs MCP」論争が一気に過熱した。火種の一つが、Scalekitが公開した実測ベンチマークだ。gh CLI と GitHub Copilot MCP(43ツール)を、同一モデル(Claude Sonnet 4)・同一タスクで75回比較したところ、CLIが信頼性・コストの両面で圧勝した、という内容だった。

これにYC CEOのGarry Tanが「MCPはコンテキストを食いすぎる、認証も壊れている。CLIの代替を30分で作った」と乗り、Perplexity CTO Denis Yaratsの「社内ではMCPから離脱中」発言(別途こちらの記事で検証済み)とも重なって、SNSでは「MCPはもう要らない」という空気が広がった。クレームは3つに整理できる。一つずつ、出どころまで遡って検証する。

クレーム①「CLIは最大32倍安い」

Scalekitの計測では、「このリポジトリは何の言語で書かれているか」という単純なクエリで、CLIが1,365トークン、MCPが44,026トークンを消費した。約32倍だ。月1万操作換算でCLI約$3.20 vs MCP約$55.20。確かにCLIが安い。

ただし、この差の大半はツール定義のコンテキスト消費から来ている。GitHub Copilot MCPは43ツールを持ち、その定義がプロンプト送信前にコンテキストを埋める。これは トークン肥大問題 で検証した通り、サーバー選定・ツールキュレーション・compactモード・code mode(コード経由呼び出し)で1桁縮められる性質のものだ。Anthropicのcode modeガイダンスでは最大98.7%のオーバーヘッド削減が測定されている。

クレーム②「MCPの信頼性は72%しかない」

ここが最も誤解されている点だ。Scalekitのベンチで、MCP側は25回中7回失敗して72%になった。だが失敗の内訳を見ると、その大半はGitHub Copilot MCPサーバーへの接続でのTCPタイムアウトだった。つまり72%は「MCPというプロトコルの信頼性」ではなく、「特定のリモートMCPサーバー + そのトランスポートの安定性」を測った数字だ。

信頼性はプロトコルではなく実装で決まる。同じMCPでも、安定したトランスポートと堅牢なエラーハンドリングを備えたサーバーは、まったく違う結果を出す。それを示すのがKanseiLinkのグレード評価だ(実測成功率は蓄積中)。

Slack MCP・freee MCP・Backlog MCP——KanseiLinkのグレード評価ではいずれもverified(🟢)で、高い信頼性を示す(実測成功率は蓄積中)。MCPが構造的に72%なのではなく、作りの良いMCPは安定して動き、作りの甘いサーバーやトランスポートが不安定なら72%まで落ちる。それだけのことだ。

クレーム③「MCPを捨ててCLIへ全面移行すべき」

「MCPを捨ててCLIへ」という結論は、複数の実務者から「そもそも問いが間違っている(the wrong fight)」と反論されている。事実関係を整理する。

• 本番エージェントは両方使う — Claude Code、Cursor、Gemini CLIなど主要なエージェント環境は、CLIとMCPを併用している。どちらか一方を捨てる設計にはなっていない。
• CLIが有利な領域 — モデルが既にパターンを熟知しているコマンド(git、gh、awsなど)。学習データに大量に存在するため、ツール定義を読ませなくても正しく使える。
• MCPが有利な領域 — 中央集権的なOAuth、ロールベースアクセス制御(RBAC)、標準化された監査ログ・テレメトリ、動的なツール発見が必要なエンタープライズ統合。HTTPトランスポートのMCPはここで強い。
• 軸はCLI/MCPではない — 本当の判断軸は「そのタスクで、構造とコストのバランスが良いのはどちらか」「そのインターフェースはきちんと作られているか」だ。

Perplexityの離脱も、「検索プロダクトという特定ユースケースでAPI+CLIの方が経済的だった」という1社・1ユースケースの判断であり、「MCPが構造的に終わった」とは別の話だ。

KanseiLink評価 — 「72%」は一般化できない

KanseiLinkは225+の日本SaaSについて、公式MCPの提供とKanseiLinkのMCPハンドシェイク検証に基づき「verified(🟢)」を判定している(実測成功率は蓄積中)。CLI vs MCP論争で語られる「72%」が、いかに一般化できない数字かが分かる。

注目すべきは最終行だ。SmartHRはMCPサーバーを持たずAPI直叩き(CLI的アクセスに近い)だが、KanseiLinkの初期データではエージェント成功率が伸び悩む傾向が観測されている(観測中)。つまり「CLI/API = 高信頼、MCP = 低信頼」という単純な図式は成り立たない。信頼性を決めるのはインターフェースの形式ではなく、実装の品質・トランスポートの安定性・発見可能性だ。

日本SaaSへの含意

日本のSaaSベンダーがこの論争から学ぶべきは、「CLIかMCPか」で慌てて方針転換することではない。エージェントが最終的に選ぶのは形式ではなく、安く・確実に・見つけやすいインターフェースだ。磨くべきは次の3点に集約される。

• トークン効率 — MCPを提供するなら、ツール定義を肥大させない。必要なツールに絞り、compactな記述を心がける。43ツール全部入りは避ける。
• トランスポートの安定性 — 「72%」の正体はTCPタイムアウトだった。タイムアウト設計・リトライ・接続の堅牢性が成功率を直接左右する。
• 発見可能性(AEO) — そもそもエージェントの意図キーワードで見つからなければ、CLIだろうとMCPだろうと使われない。

FAQ

「CLIはMCPより信頼性100% vs 72%」というベンチマークは正確ですか？

Scalekitの75回ベンチ(gh CLI vs GitHub Copilot MCP、Claude Sonnet 4)ではその通りです。ただしMCP側の失敗の大半はGitHub Copilot MCPへのTCPタイムアウトが原因で、プロトコルの欠陥ではありません。KanseiLinkのグレード評価では、verified MCP群は高い信頼性を示します(実測成功率は蓄積中)。

CLIがMCPより4〜32倍安いのは本当ですか？

✅ おおむね本当です。単純クエリでCLI 1,365トークン vs MCP 44,026トークン(約32倍)。ただし差の主因はツール定義の肥大で、キュレーションやcode modeで縮められます。固定的な差ではなく構成依存です。

「MCPを捨ててCLIへ全面移行すべき」は正しいですか？

❌ 不正確です。Claude Code・Cursor・Gemini CLIなど本番エージェントは両方を併用しています。CLIは既知コマンドで有利、MCPは中央集権的なOAuth・RBAC・監査が必要なエンタープライズ統合で有利。二者択一は誤った前提です。

なぜGitHub Copilot MCPは72%で、他のverified MCPは安定して動くのですか？

信頼性はプロトコルではなく実装とトランスポートで決まるからです。72%はTCPタイムアウト由来。安定したトランスポートと堅牢なエラーハンドリングを備えたverified MCP(公式MCP提供＋ハンドシェイク検証済み)は高い信頼性を示します(実測成功率は蓄積中)。

日本SaaSベンダーはどう対応すべきですか？

形式論争に振り回されず、(1)トークン効率(ツール定義の肥大回避)、(2)トランスポートの安定性、(3)発見可能性(AEO)の3点を磨くべきです。エージェントが選ぶのは形式ではなく、安く・確実に・見つけやすいインターフェースです。