MCP vs CLI｜筆者が MCP から移行した結論【CLI が10-32倍安い・2026】

MCP vs CLI ――AI エージェントに外部ツールを操作させるとき、どちらの接続方式を選ぶべきか。筆者は以前 MCP（Model Context Protocol） を積極的に使っていたが、現在は CLI を基本に、MCP は必要な場面でのみ使うスタイルに移行している。

移行の決め手は Scalekit が公開したベンチマークだ。CLI は MCP の 10〜32 倍安く、信頼性は 100% 対 72%。筆者自身も Docker MCP Toolkit・PostgreSQL・K8s・Google 系サービス・Obsidian・Playwright など大量の MCP を接続していた構成から CLI 中心に切り替えた結果、月 $100 の API 費用のうち約 $10、使っている MCP によっては $30〜$50 が MCP のスキーマ注入だけで消えていた分が $1 以下に激減し、コンテキスト圧縮による作業中断もほぼ解消した。この記事では、筆者の MCP → CLI 移行体験と客観データの両面から、MCP vs CLI の最適な使い分けを解説する。

出典：Scalekit 公式ブログ（2026年、Claude Sonnet 4、75回実行）

MCP vs CLI とは — それぞれの仕組みと特徴【2026年版】

MCP（Model Context Protocol）の概要

MCP（Model Context Protocol）は、2024年11月に Anthropic が発表したオープンプロトコルだ。AI モデルが外部ツールやデータソースと通信するための標準化されたインターフェースを定義する。よく「AI 版の USB-C」と表現されるように、ツールごとにカスタム統合を開発する必要がなくなり、1つのプロトコルであらゆるサービスに接続できるのが最大のメリットだ。

アーキテクチャはクライアント-サーバー構成で、AI アプリケーション（MCP クライアント）が MCP サーバーを経由して外部サービスにアクセスする。各ツールの機能は JSON Schema で定義され、モデルはスキーマを読み取ってどのツールを呼ぶべきか、どんなパラメータが必要かを判断する。

2025年12月には Linux Foundation 傘下の Agentic AI Foundation（AAIF） に寄贈され、Anthropic、Block、OpenAI が共同設立。Google、Microsoft、AWS、Cloudflare も支援に加わり、単一企業のプロジェクトから業界標準へと進化した。2026年現在、Claude Code、Cursor、Windsurf、Zed、VS Code Copilot、Codex CLI、OpenClaw など主要ツールがほぼすべて MCP に対応している。MCP 対応エディタ同士の違いについては「Cursor vs Windsurf 徹底比較」で詳しく比較している。

出典：MCP 公式サイト、Anthropic

CLI アプローチの概要

CLI アプローチとは、AI エージェントがシェル経由で既存のコマンドラインツールを直接実行する方式だ。git、gh（GitHub CLI）、docker、kubectl、curl など、開発者が日常的に使っているツールをそのまま活用する。MCP のような専用プロトコルを介さず、OS のシェルが「統合レイヤー」として機能する。

# CLI アプローチの例：GitHub リポジトリの言語構成を調べる
gh api repos/owner/repo/languages
# MCP だと専用サーバー経由で同じ情報を取得
# → ツール定義のスキーマが毎回コンテキストに注入される

なぜ AI は CLI が得意なのか

筆者が MCP vs CLI を実際に使い分けて強く感じるのは、AI は CLI の方が圧倒的にうまく扱えるという点だ。Claude Code に CLI コマンドを実行させると、ほぼ一発で正しいコマンドを組み立てる。MCP は時々スキーマの読み込みミスやパラメータの型エラーが発生するのと対照的だ。

パイプラインの合成性は、実際に使うと想像以上に強力だ。筆者の実感では、AI は人間が理解や記述に時間がかかるような複雑なパイプコマンドを器用に組み立てる。gh pr list --json number,title,author | jq '.[] | select(.author.login=="myuser")' | head -5 のような絞り込みも一発で生成してくれる。仮に CLI の実行でエラーが出ても、AI は --help を確認したり、それでも解決しなければ Web 検索で調べて自己修正するため、CLI 操作で詰まることはほぼない。むしろリスクがあるのは CLI の失敗ではなく、AI が意図を誤解して別の作業を実行してしまう場面だ。この点は CLI でも MCP でも共通の課題であり、CLI 特有の弱点ではない。

MCP vs CLI コスト比較【トークン消費の衝撃的な差】

MCP vs CLI の比較で最もインパクトが大きいのがトークンコストだ。筆者が CLI に移行した最大の理由もこのコスト差にある。

Scalekit ベンチマーク結果

Scalekit が Claude Sonnet 4 を使用し、同一タスクを CLI と MCP でそれぞれ 75回 実行したベンチマーク結果は、業界に大きな衝撃を与えた。

出典：Scalekit “MCP vs CLI: The Hidden Cost of AI Tool Integration”（2026年）

出典：Jannik Reinhard “Why CLI Tools Are Beating MCP for AI Agents”（2026年）

なぜ MCP はトークンを大量消費するのか

MCP のトークン消費が大きい根本原因は、ツール定義のスキーマが毎回コンテキストウィンドウに注入される仕組みにある。

出典：GitHub MCP Server（筆者調べ）

GitHub MCP サーバーを接続すると、93個のツール定義だけで約 55,000 トークン がコンテキストウィンドウに注入される。これはモデルのコンテキストウィンドウの 40〜50% に相当し、実際のタスク処理に使えるスペースが大幅に圧迫される。「リポジトリの言語を調べる」というシンプルなタスクでも、全93ツールのスキーマが注入されるのだ。

対照的に、CLI アプローチでは gh api repos/{owner}/{repo}/languages という1行のコマンドを生成するだけ。スキーマの注入は不要で、モデルの事前知識がスキーマの役割を果たす。

トークン削減の取り組み（2026年）

MCP のトークン消費問題に対して、複数のアプローチが試みられている。

これらの取り組みは有望だが、いずれも仕様レベルでの解決ではなく、実装側の工夫に留まっている。MCP プロトコル自体が「全スキーマを注入する」前提で設計されている以上、根本的な解決には仕様の改訂が必要だ。

なお、Claude Code と Codex CLI の徹底比較記事でも解説しているが、CLI ベースのツールはこのコスト問題を最初から回避できる設計になっている。

筆者の MCP → CLI 移行でコストはどう変わったか

筆者は以前、Docker MCP Toolkit・PostgreSQL・K8s・Google 系サービス・Obsidian・Playwright など大量の MCP を同時に接続して作業していた。MCP vs CLI のコスト差を痛感したのは、Claude Max プラン（$100/月）で長時間セッションを行うようになってからだ。

特に印象的だったのは、コンテキストウィンドウが 20k トークンまでしか対応していなかった時期の体験だ。MCP を複数接続した状態では、スキーマ注入だけで大部分が消費され、数ターンの会話で上限に到達することもあった。CLI に切り替えただけで追加で数ターン作業できるようになり、コンテキストの「空き」が目に見えて増えた。現在は 100k 以上のコンテキストに対応するモデルも増えたため以前ほど極端ではないが、複数ツールを同時接続する場合のスキーマ消費は依然として無視できない。

Obsidian の MCP でも検証したが、MCP サーバーを接続するだけで、使用していなくてもスキーマ分のトークンが常に消費されている。この「待機コスト」は MCP を複数入れるほど積み上がるため、月 $100 の API 費用のうち約 $10、使っている MCP によっては $30〜$50 が MCP のスキーマだけに消えていた計算だ。CLI 移行後は $1 以下に収まっている。

MCP vs CLI 信頼性・パフォーマンス比較【2026年】

トークンコストだけでなく、信頼性とパフォーマンスにも大きな差がある。Scalekit ベンチマークの25回実行テストでは、CLI の成功率 100% に対し、MCP は 25回中7回が ConnectTimeout で失敗し、成功率は 72% にとどまった。

出典：Scalekit 公式ブログ（2026年）

ただし、72% という数字の背景には注意が必要です。この信頼性低下の主因はリモート MCP サーバーへの接続タイムアウトです。ローカル MCP サーバー（stdio 接続）ではネットワーク起因の障害が発生しにくく、信頼性は大幅に向上します。実際、Zechner のベンチマークでは、ローカル環境で MCP と CLI の両方が 100% の成功率を記録しています。つまり、MCP の信頼性問題はプロトコル自体の欠陥ではなく、リモート接続に起因する部分が大きいということです。

CLI が高い信頼性を示す理由は明確だ。依存するコンポーネントが少ない。CLI は OS のシェルとローカルにインストールされたツールだけで動作する。一方、MCP は MCP サーバープロセス → JSON-RPC 通信 → 外部 API という多段構成のため、各レイヤーで障害が発生しうる。

筆者の体験でも、MCP サーバーの起動失敗やバージョン不整合でデバッグに時間を取られることがあった。CLI は which コマンド で存在確認するだけで済む。この「トラブルシューティングの手軽さ」は、日常の開発生産性に大きく影響する。

他のベンチマーク結果との比較

Scalekit のベンチマークは業界に大きなインパクトを与えましたが、異なる条件でテストを行った結果も存在します。複数のデータを比較することで、より正確な全体像が見えてきます。

出典：Smithery.ai、Zechner ベンチマーク（2026年）

MCP vs CLI セキュリティ比較

セキュリティは MCP vs CLI の比較で MCP が明確に優位なフィールドだ。MCP は設計段階からエンタープライズグレードのセキュリティを組み込んでいる。

MCP のセキュリティ強み

CLI のセキュリティリスクと対策

セキュリティの判断基準

エンタープライズレベルのガバナンスが必要なら MCP 一択だ。OAuth 2.1、スコープ付き権限、監査ログは、組織的なセキュリティ要件を満たすために設計されている。一方、個人開発や信頼できるチーム内であれば、CLI のセキュリティリスクは適切な運用で十分にカバーできる。

筆者の運用では、個人開発は CLI + 環境変数で十分と判断している。チーム開発やクライアント向けプロダクトでは MCP の権限管理が安心だ。

出典：MCP 公式仕様、Descope（2026年）

実例で比較 — MCP vs CLI どちらが有利か【GitHub・Docker・Slack・DB】

GitHub CLI vs GitHub MCP

GitHub の公式 MCP サーバーは 93個のツール を提供する。Issue 管理、PR 操作、リポジトリ設定、Actions、Packages など、GitHub API のほぼすべてをカバーする包括的なサーバーだ。しかし、この包括性がそのままコスト問題になる。

# CLI アプローチ：わずか1コマンドで完了（1,365トークン）
$ gh api repos/owner/repo/languages
{
  "Python": 45230,
  "JavaScript": 12500,
  "TypeScript": 8900
}
# MCP アプローチ：93ツールのスキーマ注入後に実行（44,026トークン）
# → 32倍のコスト差

筆者の判断: 個人開発では gh CLI 一択。GitHub MCP は不要だ。ただし、GitHub MCP は Webhook やリポジトリ設定の自動化など、CLI にない機能もある点は留意すべきだ。

ツール別おすすめ早見表

筆者調べ（2026年3月時点）

ポイントは明確だ。成熟した CLI が存在するサービスでは CLI を優先し、CLI がないサービス（Slack、Notion、ブラウザ操作など）では MCP が唯一の選択肢になる。筆者の使い分けもまさにこのパターンだ。日常的な DB 操作は psql で CLI 実行し、複雑なスキーマ調査時のみ MCP を一時的に接続している。

筆者の MCP → CLI 移行体験【実践レポート】

MCP vs CLI の理論的な比較だけでなく、筆者が実際に MCP 中心の構成から CLI 中心に移行した体験を共有する。

移行前の構成（MCP 中心）

以前の筆者の構成は「使えるものは全部入れる」スタイルだった。Docker MCP Toolkit・PostgreSQL MCP・K8s MCP・Google 系サービス MCP・Obsidian MCP・Playwright MCP など、利用可能な MCP サーバーを手当たり次第に接続していた。統一的なインターフェースで何でも操作できるのは確かに魅力的だったが、代償は大きかった。

• コンテキストウィンドウの大部分をスキーマが占有（各サーバーが数千〜数万トークンを常時消費）
• 20k コンテキスト時代は数ターンで上限に到達することもあった
• 長時間セッションでコンテキスト圧縮が頻発し、AI が直前の文脈を忘れる
• MCP サーバーの起動失敗・バージョン不整合で作業が中断

移行後の構成（CLI 中心）

現在は MCP サーバーを基本的にすべて削除している。gh・psql・docker・kubectl などは CLI をシェル経由で直接実行し、CLI がなくても API 経由で操作できるサービスについては、その使い方を Claude Code の Skills に記述して対応した。つまり「MCP の代わりに Skills + API」という構成だ。段階的に移行を進め、CLI 対応サービスが増えたことで現在は完全に移行できている。移行して「やっぱり MCP の方がよかった」と思う場面は特になかった。無駄なコンテキスト消費がなくなってスッキリした、というのが率直な感想だ。エディタ自体も CLI 中心の開発スタイルに合わせて選ぶのが重要で、筆者は「Windsurf vs Zed 徹底比較」で解説しているように、軽量な Zed と CLI エージェントの組み合わせを採用している。

移行して感じた変化

筆者調べ（2026年3月時点、Claude Max プラン利用）

移行で最も実感したのは、なんらかの制約がない限り CLI を使うべきだということだ。移行は段階的に進めた。CLI 対応が進んだサービスから順に切り替え、現在は MCP を基本的にすべて外している。CLI がなくても API があるサービスは Skills に使い方を記述して対応した。とはいえ、CLI を AI エージェントが扱える場所に配置する必要はあるし、CLI も API もないサービスでは MCP に頼る場面は残る。両方のアプローチを理解して、統合ごとに最適な方を選ぶのが現実的な結論だ。

MCP vs CLI 使い分けの判断基準【フローチャート】

使い分けを考える上で、開発ワークフローの「Inner Loop」と「Outer Loop」という切り口が参考になる。Inner Loop は手元でコードを書いて即座にフィードバックを得るフェーズ（コーディング・デバッグ・テスト実行）。Outer Loop はコードが外部システムと連携するフェーズ（CI/CD・デプロイ・チーム間コラボレーション・SaaS 連携）だ。

ただし筆者の実践では、Outer Loop でも CLI や API + Skills で対応できるケースがほとんどだった。MCP でしかできないものでなければ CLI を使う、というシンプルな基準で十分だ。

CLI を選ぶべきケース

MCP を選ぶべきケース

ハイブリッドが正解（筆者の結論）

現実的には、CLI と MCP を状況に応じて使い分ける「ハイブリッドアプローチ」が2026年のベストプラクティスだ。

筆者調べ（2026年3月時点）

MCP vs CLI の業界動向【2026年最新】

MCP を推進する動き

MCP エコシステムは2026年に入って加速度的に拡大している。

• Linux Foundation AAIF: Anthropic、OpenAI、Block、Google、Microsoft の5社が共同設立。MCP の標準化とガバナンスを推進
• Docker MCP Catalog: Docker Hub のように MCP サーバーをワンクリックで配備できるカタログが登場。セットアップの障壁が大幅に低下
• 主要 SaaS 対応: GitHub、GitLab、Jira、Confluence、Salesforce、HubSpot など、エンタープライズ向け SaaS のほぼすべてが公式 MCP サーバーを提供
• Streamable HTTP トランスポート: 従来の stdio に加え、HTTP ベースのトランスポートが標準化。リモート MCP サーバーの運用が容易に

CLI 回帰の動き

• Anthropic コード実行パターン: Anthropic 自身が MCP の代替として、コード実行ベースのツール呼び出しを研究。スキーマ注入を 98.7% 削減するアプローチ
• ターミナルファーストツールの台頭: Claude Code、Warp Terminal、Ghostty など、ターミナル/CLI をファーストクラスの AI インターフェースとして設計するツールが増加
• 「CLI is all you need」論: 開発者コミュニティで「MCP は過剰設計、CLI で十分」という議論が活発化。特に個人開発者やスタートアップで共感を集めている

今後の展望

MCP と CLI は共存する方向に進んでいる。MCP はエンタープライズ・マルチテナント・ノーコード領域で、CLI は開発者向けワークフロー・コスト最適化領域で、それぞれの強みを発揮する。今後注目すべきポイントは以下の3つだ。

よくある質問 — MCP vs CLI の違いについて

まとめ — MCP vs CLI は「CLI 優先、MCP は補完」が正解

最後に、重要なのは「技術の優劣」ではなく「タスクへの適合性」だ。CLI で事足りる場面で MCP を使えばコストを浪費し、MCP でしかできない場面で CLI に固執すれば機能を失う。自分のユースケースを冷静に分析し、最適なツールを選ぼう。

📖 この記事で紹介した関連記事

Cursor vs Windsurf 徹底比較【どちらを選ぶべき？2026年最新】Claude Code Codex 徹底比較｜料金・エージェント・コード品質・MCP連携【2026年版】Claude Max $100 vs $200 vs API｜自腹ユーザーの損益分岐【2026】Claude Code セキュリティ｜業務で効く9ステップ実践ガイド【2026】Claude Code Skill 実践ガイド｜作成・チーム配布・安全運用【2026】Windsurf vs Zed 徹底比較｜AI機能・性能・料金で選ぶべきエディタが分かる【2026年】

著者

krona23

IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。

DevGENT について →