「MCPはCLIのラッパーに過ぎない。だから不要」
X（旧Twitter）上でこうした極論が飛び交い、「MCPは滅んでいい」とまで言い切る声も出ています。CLIの人間デバッグしやすさや柔軟性を挙げ、MCPは過剰な抽象化だという主張です。
結論から言えば、この議論はMCPとCLIの役割の違いを無視しています。
MCPはCLIのラッパーではありません。CLIが「1回呼んで1回返す」ステートレスな実行モデルであるのに対し、MCPは接続を維持したまま複数の操作をオーケストレーションするステートフルなプロトコルです。これらは設計思想からして異なるものであり、「どちらが上か」ではなく「どの場面でどちらが適切か」で語るべきテーマです。
CLIが合理的な場面
CLIやAPIラッパーが適しているのは、単発のリクエスト/レスポンスで完結する処理です。
- ファイルの変換や整形
- 単一のAPI呼び出しとそのレスポンスの取得
- 冪等な操作（何度実行しても同じ結果になる処理）
これらの処理には状態の保持が不要で、一回のコマンド実行で入力から出力までが完結します。呼び出しのオーバーヘッドも小さく、人間にとってもデバッグしやすい。この領域でCLIが優れているのは間違いありません。
MCPが本領を発揮する場面
一方、MCPが強みを持つのは「状態の保持」が鍵になるユースケースです。
- 永続的なコネクション管理: データベースセッションやSSH接続など、確立にコストがかかる接続を維持したまま複数の操作を実行する場面
- コンテキストを伴うマルチステップワークフロー: 前のステップの結果を踏まえて次の操作を判断する、連続した処理
- リアルタイムの双方向通信: ツール側からの通知やストリーミング更新が必要な場面
単純なリクエスト/レスポンスならCLIが勝ちますが、MCPの価値はステートフルなオーケストレーション層にあります。
実測で見えたCLIの限界：データベース接続のレイテンシ
sqlewはAIコーディングアシスト向けのMCPツールで、開発中の設計方針や誓約事項をデータベースに蓄積し、AIエージェントがJust-in-Timeで参照できるようにしています。
開発初期にCLIでの実装実験を行いました。しかし、CLIではTool呼び出しのたびにプロセスが起動・終了するため、毎回データベースへの接続処理が発生します。この接続処理だけで1回あたり約1秒のレイテンシが加わることがわかりました。
AIエージェントがsqlewのツールを呼び出す回数は、1セッションで数十回に及びます。仮に50回のTool呼び出しがあれば、接続のオーバーヘッドだけで約50秒。ユーザー体験として無視できない遅延です。
MCPであればサーバープロセスが常駐し、データベース接続を保持したまま複数のツール呼び出しに応答できます。接続コストは初回の1回のみです。
| 方式 | 接続タイミング | 50回呼び出し時のオーバーヘッド |
|---|---|---|
| CLI | 毎回接続・切断 | 約50秒（1秒 × 50回） |
| MCP | 初回のみ接続 | 約1秒（初回の1回のみ） |
「MCPかCLIか」ではなく「いつどちらを使うか」
MCPが不要かどうかは、扱う処理の性質で決まります。
ステートレスな処理にはCLIが合理的です。しかし、データベース接続の維持、セッション横断のコンテキスト管理、マルチステップの連続処理など、状態の保持が前提になる場面では、MCPには構造的な優位性があります。
「MCPかCLIか」という二者択一ではなく、ツールの特性に応じて使い分ける。sqlewがMCPを採用しているのは、設計意図の蓄積と参照という性質上、ステートフルな接続が不可欠だからです。
