MCP vs CLI論争を徹底解説：AIエージェント開発におけるツール接続の最適解とは

2026-03-16

AIコーディングアシスタントが急速に普及する中、開発者コミュニティで激しく議論されているテーマがあります。それは「MCPを使うべきか、CLIで直接ツールを呼ぶべきか」という問いです。

Claude Code、Gemini CLI、Cursorなど、主要なAIエージェントツールがMCP（Model Context Protocol）をサポートする一方で、多くの開発者が「なぜわざわざ複雑なMCPサーバーを経由する必要があるのか」と疑問を呈しています。

本記事では、この論争の核心に迫り、両アプローチのメリット・デメリット、定量的なベンチマーク結果、そしてユースケース別の使い分け指針を詳しく解説します。

MCP vs CLI論争の背景

2024年後半にAnthropicが提唱したMCPは、AIモデルと外部ツール・データソースを接続するためのオープン標準プロトコルです。「AIのUSB-C」として、一度構築すればどのAIクライアントからでも利用できる相互運用性を目指しています。

しかし、AIエージェントが直接ターミナルを操作できるようになると、根本的な疑問が生じました。最新のLLMは膨大な量のシェルスクリプト、manページ、Stack Overflowの回答を事前学習しており、--helpコマンドを実行するだけで自律的にツールを操作できます。

この両者の対立は、開発者コミュニティで「地球上で最も馬鹿げた議論」と揶揄される一方で、AIエージェントアーキテクチャの本質的なジレンマを浮き彫りにしています。

MCPのメリットとデメリット

MCPのメリット

ツール統合の標準化と相互運用性

MCPの最大の功績は、各AIプロバイダーが独自に実装していたFunction Callingを標準化した点です。開発者はMCPサーバーを1つ構築するだけで、VS Code、Cursor、Claude Desktop、Amazon Q CLIなど、あらゆるMCP対応クライアントからツールを利用できます。

セキュリティ・認可の一元管理

エンタープライズ環境において、MCPはOAuth認証をネイティブにサポートしています。StripeのMCPサーバー実装に見られるように、AIエージェントがユーザーに代わってAPIを操作する際の権限スコープを厳格に管理でき、構造化された監査ログも提供されます。

型安全性と構造化データ

MCPはJSON Schemaに基づく厳密な型定義を強制します。バイナリデータの処理や複雑な入れ子構造のデータ受け渡しにおいて、AIのハルシネーション（幻覚）を減らし、安定した操作を保証します。

MCPのデメリット

スキーマの肥大化（Schema Bloat）

MCPに対する最大の批判は、トークンコストの増大です。クライアントがサーバーに接続すると、すべてのツールのスキーマがLLMのコンテキストウィンドウにロードされます。

例えば、公式のGitHub Copilot MCPサーバーは43個のツールを公開しています。「このリポジトリの言語は何か？」という単純な質問でも、使用しない42個のツールスキーマまで毎回コンテキストに注入され、オーバーヘッドが55,000トークンに達するケースも報告されています。

接続の不安定性

ネットワーク経由のMCP通信では、JSON-RPCのオーバーヘッドに加え、タイムアウトや接続切断の問題が多数報告されています。Playwright MCPでの「5秒タイムアウト」や「認証成功後の再接続失敗」など、プロトコルレイヤーによる脆弱性が指摘されています。

過度な抽象化による自己修復能力の阻害

AIモデルは生のAPIエラーやコマンドラインのエラー出力を読み取り、自己補正を行う能力に長けています。StackOneの調査によれば、過度なスキーマ抽象化はこの自己修復能力を阻害する場合があります。

CLI直接利用のメリットとデメリット

CLIのメリット

圧倒的なトークン効率

CLI呼び出しは、AIエージェントがBashコマンドを生成し、標準出力を受け取るだけのシンプルなプロセスです。Stripe APIを利用した実験では、20個のツールを持つMCPサーバーが起動時に約2,100トークンを消費するのに対し、CLIのスキル定義ファイルはわずか23トークンで済むことが確認されています。

LLMの事前学習知識の活用

CLIがAIエージェントのインターフェースとして優れている最大の理由は、LLMの事前学習データとの親和性です。ターミナルは50年以上の歴史を持ち、git、docker、kubectlの使い方に関する無限のテキストがインターネット上に存在します。

MCPのスキーマをランタイムで読み込ませるのに対し、CLIの知識はモデルの重み（Weights）として既に焼き付けられています。これは「推論時における無料の知識」を意味します。

Unix哲学に基づく柔軟性（Composability）

「一つのプログラムには一つのことをうまくやらせる」「プログラムを組み合わせて使う」というUnix哲学は、AIエージェントにおいても強力に機能します。

MCPでは、APIが返した40個のフィールドを持つ巨大なJSONがそのままコンテキストに投げ込まれます。しかしCLIであれば、AIは自律的に curl ... | jq '.status' といったパイプ処理で必要な情報だけを抽出できます。

CLIのデメリット

標準化の欠如とセキュリティリスク

CLIツールは出力形式が統一されていません。また、シェルアクセスを許可することは、プロンプトインジェクションによる破壊的コマンド実行のリスクを伴います。Claude Code等ではセキュリティチェックのオーバーヘッドが都度発生します。

状態管理の難しさ

ブラウザ自動操作のように、セッションを跨いで状態を保持する必要があるタスクでは、CLIは不向きです。MCPサーバーであればメモリ上にブラウザインスタンスを保持できますが、ステートレスなCLIでは工夫が必要です。

定量的ベンチマーク：MCPはCLIより最大32倍のトークンを消費

Scalekit社がClaude Sonnet 3.5を用いてGitHubリポジトリ操作を比較した結果は衝撃的でした。

タスク内容	CLI（トークン）	MCP（トークン）	コスト倍率
リポジトリの言語・ライセンス確認	1,365	44,026	約32倍
PR詳細とレビューステータス確認	1,648	32,279	約20倍
リポジトリのメタデータとインストール	9,386	82,835	約9倍
貢献者ごとのマージ済みPR集計	5,010	33,712	約7倍
最新リリースと依存関係の特定	8,750	37,402	約4倍
平均タスク成功率（25回試行）	100%	72%	-

MCPの失敗（28%）はすべてTCPレベルの接続タイムアウトによるものであり、ローカルで完結するCLIは100%の信頼性を示しました。

別のベンチマークでは、Chrome DevToolsのMCPサーバーとCDP直接操作CLIツールを比較し、CLIが28%高いタスク完了スコア、33%高いトークン効率を達成しています。

ユースケース別の使い分け：Inner Loop vs Outer Loop

CircleCIのエンジニアリングチームをはじめ、多くのAI専門家が指摘するように、「MCP vs CLI」は二者択一の選択（False Choice）ではありません。

CLI が適している場面：Inner Loop（内部ループ）

開発者が個人のローカルマシン上でコードを記述・テスト・デバッグするInner Loopにおいては、CLIが最適解です。

対象:

個人の開発ワークフロー
ローカルのファイルシステム操作
Git操作、Lint/フォーマットツールの実行

理由:

スピードが最優先
認証の壁がない
LLMがツールの挙動を事前学習で熟知
コンテキストウィンドウの消費を抑え、推論能力を高く維持

MCP が適している場面：Outer Loop（外部ループ）

コードがチームの共有インフラにプッシュされた後のCI/CD、SaaS連携、エンタープライズのデータアクセスといったOuter Loopにおいては、MCPが必須です。

対象:

マルチテナント環境
OAuth認証が必要な外部API（Notion, Slack, Jira等）
ターミナル環境を持たないエンタープライズチャットボット

理由:

「誰の権限で」操作を行わせるかの管理が必要
監査証跡（Audit trail）の担保
CLIでは動的な認証フロー構築が困難

ハイブリッドアプローチ：MCPゲートウェイの台頭

両者の弱点を克服するアーキテクチャとして、MCPゲートウェイ（BFFパターン）が注目されています。

AIエージェントと実際のMCPサーバーの間にゲートウェイを配置し、以下の機能を実現します。

スキーマ・フィルタリング: 43個あるツールのうち、現在のタスクに必要な2〜3個だけを動的に注入（トークン消費を約90%削減）
コネクション・プーリング: 不安定なMCP接続をゲートウェイがプール・維持し、Failure rateを28%から1%以下へ低減
認証の集中管理: セッションごとのOAuthトークン更新や監査ログを一元管理

また、mcpcやmcp-cliのようなブリッジツールも登場しており、スクリプト内でMCPサーバーをCLIライクに呼び出すハイブリッド手法も確立されつつあります。

開発者コミュニティの声

Redditでの評価

r/ClaudeCodeサブレディットでは、「Claude CodeはCLIの神」と評価する声が多く見られます。「ローカルネットワーク操作用に3つのMCPサーバーを立てただけで、コンテキストウィンドウが枯渇した」という失敗談も共有されています。

SupabaseやGitHubの操作には、MCPではなく公式CLI（supabase-cli、gh）を利用することが推奨されています。

著名開発者の見解

Simon Willisonをはじめとする著名な開発者は、「LLMはcli-tool --helpの使い方を知っているため、MCPのように詳細に記述してトークンを消費する必要がない」と指摘しています。

日本のコミュニティ

ZennやQiitaでも「MCPはなぜCLIに負けたのか」というセンセーショナルな分析記事が話題になりました。Anthropic自身がClaude CodeでMCPのパフォーマンス問題を回避するため、軽量なBashコマンドとスキル定義を組み合わせるアプローチを推奨している「自己矛盾」も指摘されています。

企業のMCP採用状況

開発者のローカル環境でのCLI人気とは裏腹に、企業エコシステム全体ではMCP採用が急速に進んでいます。

主要な採用事例:

Stripe: 公式MCPサーバーで決済処理・顧客管理をAIエージェントに許可
AWS: Amazon Q CLI v1.9からMCPクライアント機能を搭載
IDE: Cursor、VS Code、JetBrains IDEがネイティブMCPサポート
Angular CLI: 実験的MCPサーバー内蔵でAIアシスタントと連携
Home Assistant: Claude DesktopからIoTデバイス操作を実現

2026年のMCPロードマップでは、単なる「AIとツールの接続」から「AI自律連携インフラ（Agent-to-Agent Communication）」への進化が予定されています。

結論：システムの境界線をどこに引くか

「MCPを使うべきか、CLIで直接ツールを呼ぶべきか」という問いの答えは、「システムの境界線をどこに引くか」という一点に帰着します。

Inner Loop（ローカル開発）: CLIアプローチが絶対的な最適解です。圧倒的なトークン効率、LLMの事前学習知識の活用、Unixの柔軟なパイプラインを享受できます。現時点でのMCPは「過剰エンジニアリング」となる可能性が高いでしょう。

Outer Loop（エンタープライズ連携）: MCPが不可欠です。OAuthによるセキュアな認証、型安全性、監査ログの担保は、エンタープライズ要件を満たすためにCLIでは代替できない価値を提供します。

今後のAIエージェント開発では、この二項対立に終止符を打つべく、ゲートウェイアーキテクチャによる動的スキーマフィルタリングやサブエージェントによるコンテキスト隔離といったハイブリッドな設計パターンが主流となっていくでしょう。

50年前のターミナル技術の堅牢性と、MCPという最新プロトコルのガバナンスをいかに適材適所で組み合わせるか。これが次世代AIエンジニアリングの成否を分ける鍵となります。

参考文献

📢この記事をシェアしませんか？

おすすめの投稿:

MCP vs CLI、結局どっちを使うべき？MCPは最大32倍のトークンを消費、CLIは成功率100%。開発フェーズで使い分けるのが正解。ローカル開発はCLI、エンタープライズ連携はMCPで。

引用しやすいフレーズ:

“MCPはCLIと比較して最大32倍のトークンを消費し、成功率も72%に留まる”

“CLIの知識はLLMの重みに焼き付けられている - 推論時における無料の知識”

“Inner LoopはCLI、Outer LoopはMCP - 開発フェーズで使い分けるのが正解”

“50年前のターミナル技術と最新プロトコルのガバナンスを適材適所で組み合わせる”

または自分の言葉で: