目次
炎上したクレームの中身
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 (gh) | MCP (GitHub Copilot MCP) |
|---|---|---|
| 信頼性(75回ベンチ) | 100% | 72%(25回中7回失敗) |
| 単純クエリのトークン | 1,365 | 44,026(約32倍) |
| 月1万操作のコスト概算 | 約$3.20 | 約$55.20 |
| 主な失敗原因 | — | TCPタイムアウト(リモートサーバー接続) |
クレーム①「CLIは最大32倍安い」
トークン効率は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%のオーバーヘッド削減が測定されている。
「CLIが安い」は事実だが、「MCPは構造的に32倍高い」は誤読だ。差の主因はキュレーション不足のツール定義であり、固定的なプロトコル差ではない。何でも全部入りで43ツールを接続すれば高くつくし、絞れば縮む——これはCLIにも言える(巨大なCLIヘルプを全部読ませれば同じ問題が起きる)。
クレーム②「MCPの信頼性は72%しかない」
72%はMCPプロトコルの欠陥ではなく、GitHub Copilot MCPへのTCPタイムアウト由来。他のverified MCPは90%超。
ここが最も誤解されている点だ。Scalekitのベンチで、MCP側は25回中7回失敗して72%になった。だが失敗の内訳を見ると、その大半はGitHub Copilot MCPサーバーへの接続でのTCPタイムアウトだった。つまり72%は「MCPというプロトコルの信頼性」ではなく、「特定のリモートMCPサーバー + そのトランスポートの安定性」を測った数字だ。
信頼性はプロトコルではなく実装で決まる。同じMCPでも、安定したトランスポートと堅牢なエラーハンドリングを備えたサーバーは、まったく違う数字を出す。それを示すのがKanseiLinkの実測データだ。
「72%」とKanseiLink実測 verified MCP の比較
Slack MCP 91%、freee MCP 90%、Backlog MCP 90%——いずれも72%を大きく上回る。これらはエージェントの実測アウトカム報告に基づく数字だ。MCPが構造的に72%なのではなく、作りの良いMCPは90%超え、作りの甘いサーバーやトランスポートが不安定なら72%まで落ちる。それだけのことだ。
クレーム③「MCPを捨ててCLIへ全面移行すべき」
本番エージェントはCLIとMCPを併用している。二者択一は誤った前提だ。
「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実測 — verified MCPは72%ではない
KanseiLinkは225+の日本SaaSについて、エージェントの実測アウトカム報告から成功率を集計し、80%以上を「verified(🟢)」と判定している。CLI vs MCP論争で語られる「72%」が、いかに一般化できない数字かが分かる。
| サービス / インターフェース | 成功率 | 平均レイテンシ | 判定 |
|---|---|---|---|
| Slack MCP | 91% | 163ms | verified 🟢 |
| freee MCP | 90% | 216ms | verified 🟢 |
| Backlog MCP | 90% | 128ms | verified 🟢 |
| kintone MCP | 79% | 199ms | connectable 🟡 |
| (参考)Scalekit計測のGitHub Copilot MCP | 72% | — | トランスポート不安定 |
| (参考)SmartHR(API直叩き、MCPなし) | 39% | 337ms | info_only ⚪ |
注目すべきは最終行だ。SmartHRはMCPサーバーを持たずAPI直叩き(CLI的アクセスに近い)だが、成功率は39%。つまり「CLI/API = 高信頼、MCP = 低信頼」という単純な図式は成り立たない。信頼性を決めるのはインターフェースの形式ではなく、実装の品質・トランスポートの安定性・発見可能性だ。
「CLI 100% vs MCP 72%」は、特定の1サーバー・1トランスポート構成のスナップショットであって、MCPプロトコルの評価ではない。同じ土俵(KanseiLink実測)で見れば、verified MCPは90%超、MCPなしのAPI直叩きが39%という逆転もある。形式論争(CLI vs 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(Slack 91%・freee 90%・Backlog 90%)が72%を大きく上回ります。
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%で、他のMCPは90%超なのですか？
信頼性はプロトコルではなく実装とトランスポートで決まるからです。72%はTCPタイムアウト由来。安定したトランスポートと堅牢なエラーハンドリングを備えたverified MCP(成功率80%以上)は90%前後の成功率を出します。
日本SaaSベンダーはどう対応すべきですか？
形式論争に振り回されず、(1)トークン効率(ツール定義の肥大回避)、(2)トランスポートの安定性、(3)発見可能性(AEO)の3点を磨くべきです。エージェントが選ぶのは形式ではなく、安く・確実に・見つけやすいインターフェースです。
外部クレームの出典: Scalekitのベンチマーク(75回実行、gh CLI vs GitHub Copilot MCP 43ツール、Claude Sonnet 4、CLI 100% / MCP 72%、25回中7回失敗・主因TCPタイムアウト、単純クエリ1,365 vs 44,026トークン≈32倍、月1万操作で約$3.20 vs $55.20)、Garry Tan(YC CEO)およびPerplexity CTO Denis Yaratsの公開発言、各種MCP vs CLI比較記事(Scalekit / Firecrawl / Smithery「MCP vs CLI is the wrong fight」/ DEV/IBM「MCP is not dead」)。code mode最大98.7%削減はAnthropicの公式ガイダンス。KanseiLink側の数値(Slack MCP 91%/163ms、freee MCP 90%/216ms、Backlog MCP 90%/128ms、kintone MCP 79%/199ms、SmartHR 39%/337ms)は get_insights による実測アウトカム報告の集計(各 last_updated 2026年4月時点のスナップショット)であり、エージェント活動により変動します。本記事の「形式より品質」という結論は観測データに対する分析的解釈であり、特定製品の優劣を保証するものではありません。各社ベンチマークは構成・モデル・タスクに依存するため、自環境での再現を推奨します。