3行まとめ
MCPとCLIは、ユースケースによって向き不向きがあります。以下の表が判断の出発点になります。
| 判断軸 | MCP向き | CLI向き |
|---|---|---|
| CLIツールの有無 | 既存CLIがない | 成熟したCLIがある |
| CLIの構造化出力 | CLIにJSON出力がない |
--json等で対応可能 |
| 認証・状態管理 | OAuth等の複雑な認証 | 環境変数やトークンで完結 |
| 利用者 | 非エンジニアを含む | エンジニアのみ |
| クライアント共有 | 複数AIクライアントで使う | 単一環境で使う |
本記事では5つの判断軸と決定フローチャートを提示します。自分のユースケースに当てはめて判断してみてください。
この記事の対象読者
- Claude Code等のAIコーディングツールを使っている方
- MCPサーバーの導入を検討しているが判断に迷っている方
- 「MCPは不要」という記事を読んで本当にそうか気になった方
MCPの基本概念や実装方法については別記事で解説しています。本記事はMCPの仕組みを知ったうえで「使うべきか否か」を判断したい方向けです。
なぜ「MCP vs CLI」が議論になるのか
MCPの設計意図
MCPはAIモデルと外部ツールをつなぐプロトコルです。Tools（関数呼び出し）だけでなくResources（データ参照）やPrompts（テンプレート）も扱えますが、本記事ではTools連携に絞ります。従来はFunction Callingを個別に実装する必要がありました。MCPはこの接続部分を標準化します。一度作ったサーバーを複数のクライアントから利用可能にします。
しかし、多くの開発者が気づいたことがあります。Claude Codeはすでにbashを実行できます。git、curl、jq、ghを直接呼び出せます。わざわざMCPサーバーを作る必要があるのかという疑問です。
推論モデルの進化が変えたこと
2024年初頭のLLMは、CLIの出力解釈が苦手な場面がありました。構造化されたJSON応答を返すMCPの方が扱いやすいケースが多かったのです。
しかし2025年以降、推論モデルの能力は向上しました。git logの出力を読んで要約する、curlの結果から特定フィールドを抽出する。こうしたタスクの精度は大きく改善しています。
この進化がMCPの価値を相対的に下げたのは事実です。ただし、すべての場面でCLIが優るわけではありません。
トークンコストの構造的な違い
MCP導入の判断で見落とされがちなのがトークンコストです。MCPとCLIでは、コストの発生構造が異なります。
MCPのコスト構造
MCPサーバーを登録すると、ツール定義がシステムプロンプトに追加されます。これが入力トークンとして毎回消費されます。
たとえば10個のToolを持つMCPサーバーを3つ登録するとします。30個分のツール定義が読み込まれます。使わないToolにもトークンが消費されます。
ただし、Claude CodeにはTool Searchによる遅延ロード機能があります。すべてのツール定義が常時フルロードされるわけではありません。それでもサーバー数が増えるほど負荷は大きくなります。
CLIのコスト構造
CLIはコマンド実行結果だけがコンテキストに入ります。MCPのような大量のツール定義は不要です。
ただし、CLI実行もコストがゼロではありません。Claude Codeではbash自体がツール定義を持っています。また、git logが数百行を返せばその分トークンを消費します。
コスト比較
| 項目 | MCP | CLI |
|---|---|---|
| ツール定義コスト | サーバー数・ツール数に比例 | bash定義分のみ（固定） |
| 実行時コスト | 構造化された応答（小さい） | コマンド出力全体（可変） |
| 未使用ツールのコスト | 遅延ロードで軽減されるが発生 | なし |
| スケーリング | サーバー数に比例して増加 | 変わらない |
MCPのコストはサーバー数に比例します。使う頻度が低いMCPサーバーは、必要なときだけ有効化する運用を検討してみてください。
5つの判断軸
1. CLIが存在するか
最もシンプルな判断基準です。やりたいことを実現するCLIツールがすでにあるなら、まずCLIを試してみてください。
-
git→ CLIで十分 -
gh（GitHub CLI） → CLIで十分 - 社内の独自API → CLIがなければMCPを検討
2. CLIが必要な構造化出力を提供するか
多くの成熟したCLIはJSON出力をサポートしています。gh --json、aws --output json、kubectl -o jsonなどです。この場合、構造化データのためにMCPを導入する必要はありません。
MCPの構造化出力が有利になるのは以下のケースです。
- CLIがJSON出力に対応していない場合
- バイナリデータや非テキストデータを扱う場合
- 複数APIの結果を組み合わせた応答が必要な場合
3. 認証・状態管理をまたぐか
CLIツールは通常、環境変数やconfig fileで認証情報を管理します。この方式で十分なら、MCPは不要です。
一方、OAuthフローでは話が変わります。リダイレクトやトークンリフレッシュが必要な場合、MCPサーバーに認証ロジックを集約する方が扱いやすくなります。
4. 利用者はエンジニアか
エンジニアはCLIの出力を読めます。エラーが出ても対処できます。この場合、CLIで十分です。
非エンジニア（PM、デザイナー等）がAIツールを使う場合は判断が変わります。CLIのエラー出力が利用者に露出すると混乱を招きます。MCPサーバーが整形された応答を返す方が使いやすくなります。ただし必須条件ではなく、UX上の重み付け要素です。
5. 複数クライアントで共有するか
Claude Codeだけで使うなら、CLIで問題ありません。しかしCursor、Cline、Claude Desktopでも使いたい場合はどうでしょうか。MCPサーバーなら一度の実装で複数クライアントに対応できます。
決定フローチャート
ユースケース別の対応表
具体的なユースケースごとに、MCP・CLIどちらが適しているかを整理します。
| ユースケース | 推奨 | 理由 |
|---|---|---|
| Gitの操作（commit, push, log） | CLI |
git CLIが成熟しており、追加の抽象化は不要 |
| GitHub Issue/PRの操作 | CLI |
gh CLIが高機能で十分 |
| ファイルの読み書き | CLI | シェルコマンドで完結する |
| PostgreSQLクエリ | どちらも | CLIのpsqlで可能だが、MCPならスキーマ補助が便利 |
| Slack連携 | MCP | ワークスペース操作向けの汎用CLIが弱く、OAuth認証が必要 |
| Google Workspace操作 | どちらも | CLIが登場（非公式・pre-1.0）、安定性重視ならMCP |
| 社内REST API | MCP | CLI不在の場合が多く、認証ロジックを内包できる |
| Docker操作 | CLI |
docker CLIが標準的 |
| AWS操作 | CLI |
aws CLIが公式に提供されている |
| ブラウザ自動操作 | どちらも | Playwright CLIが登場しトークン効率が良い。複数クライアント共有ならMCP |
| CI/CDパイプライン操作 | CLI |
ghや各CIツールのCLIで対応可能 |
MCPが優れる場面
CLIでは対応しにくく、MCPが真価を発揮するケースを整理します。
CLIが存在しないSaaS統合
多くのSaaSはREST APIを提供していますが、CLIは公式に提供していません。curlで叩くことは可能です。しかし認証ヘッダーの組み立てやペイロードの構築を毎回モデルに任せるのは非効率です。
MCPサーバーとしてラップすれば、これらのロジックをサーバー側に閉じ込められます。
非エンジニア向けの展開
チーム内の非エンジニアにAIツールを使ってもらう場合、CLIの生出力は読みにくいことがあります。MCPサーバーが整形された応答を返す設計にすれば、ユーザー体験が向上します。
IDE統合での構造化データ
CursorやCline等のIDE統合型AIツールでは、bash実行の自由度がClaude Codeほど高くない場合があります。MCPサーバーなら統一的なインターフェースを提供できます。
CLIが優れる場面
逆に、MCPを使う必然性がなくCLIで十分なケースも多くあります。
ローカル開発での日常操作
git、npm、docker、make──ローカル開発で頻繁に使うツールは、成熟したCLIが揃っています。MCPでラップしてもメリットはほぼありません。むしろツール定義分のトークンが無駄になります。
軽量な情報取得
「このファイルの行数を数えたい」「環境変数を確認したい」──こうした単発の操作に対してMCPサーバーを用意するのは過剰です。wc -lやenvを直接実行する方が速く、安価です。
高頻度の繰り返し操作
1つのセッションで何十回も呼ばれる操作を考えます。MCPの固定コストは相対的に小さくなります。しかしCLIで同じことができるなら、あえてMCPにする理由がありません。
ハイブリッド戦略：両方使う
実務では「MCP or CLI」の二択ではなく、両方を組み合わせるのが現実的です。
MCPサーバー数を絞る
前述の通り、MCPサーバーを登録するだけでトークンコストが発生します。「使うかもしれない」で追加するのではなく、実際に頻繁に使うものだけを登録してみてください。
MCPサーバーを10個以上登録するとツール定義だけで数千トークンに達します。不要なサーバーは無効化しておくのが得策です。
「まずCLI、必要ならMCP」のアプローチ
判断に迷ったら、まずCLIで試してみてください。CLIで不便を感じた場合にのみ、MCPサーバーの導入を検討する。このアプローチなら、過剰なMCP導入を防げます。
CLI運用で不便を感じやすいサインは以下の通りです。
- 毎回同じ認証処理をモデルに書かせている
- CLIの出力パースで頻繁にミスが起きる
- 複数のCLIを組み合わせた複雑なパイプラインが必要
- 非エンジニアのチームメンバーも同じ操作をしたい
.mcp.jsonの設計指針
MCPサーバーを導入する場合の.mcp.json設計で意識したいポイントです。
- 登録サーバーは5個以下を目安にする
- 認証情報は
.mcp.jsonに直書きせず、環境変数で外出しする - プロジェクト固有のサーバーはプロジェクトスコープに配置する
- 汎用的なサーバー（Slack等）はユーザースコープに配置する
{
"mcpServers": {
"internal-api": {
"type": "stdio",
"command": "node",
"args": ["/path/to/internal-api-server/build/index.js"],
"env": {
"API_TOKEN": "${INTERNAL_API_TOKEN}"
}
}
}
}
まとめ
MCPとCLIは競合するものではなく、補完関係にあります。
- CLIが存在し、テキスト出力で十分なら、CLIを使う
- CLIがない、認証が複雑、複数クライアントで共有したいなら、MCPを検討する
- 迷ったらCLIから始めて、不便を感じたらMCPに移行する
自分のユースケースに合った手段を選ぶのが、結局のところ一番合理的です。本記事のフローチャートや対応表を判断材料にしていただければ幸いです。