「MCP vs CLI」どっちを使うべき？AI時代のツール連携、その正解に迫る

Model Context Protocol (MCP) と従来の CLI (コマンドラインインターフェース) を比較して、どのようなケースで MCP を採用するのが適切なのか、その使い分けやメリットについての疑問です。AIエージェントに直接ツールを扱わせるならMCP、人間が操作するならCLIという単純な話なのか、エンジニア視点での使い分けの境界線について議論しましょう。

去年の5月くらいから「MCP反対、CLI賛成」みたいな流れが続いてるよね（俺もずっとその太鼓を叩き続けてきたんだけど）。でも、MCPにはマジで実用的なユースケースがあると思うんだ。

具体的には、MCPはカプセル化の単位としてすごく優秀。俺が作ってるセキュアエージェントフレームワーク（https://github.com/sibyllinesoft/smith-core）では、サイドカー経由でMCPをマイクロサービスに変換してサービスメッシュに組み込んでるんだけど、既存のポリシーや管理ツールを使えるからエージェントの機能をセキュアにするのがめちゃくちゃ簡単になる。そうすれば、エージェントはいちいちCLIを用意しなくてもbashでcurlするだけで済むしね。CLIの方がトークン効率は少し良いけど、全体的なシンプルさとこの仕組みのパワーを考えれば大勝利だよ。

みんながMCPかCLIかどっちが優れてるかなんて話してるのが信じられないな。どっちもツール呼び出しの手法に過ぎないし、同じ機能が提供されるならLLMがどのフォーマットを使おうが「どうでもいい」はずなんだ。CLIの方が（LLMが一般的なCLIで学習されてるから）わずかに有利かもしれないけど、MCPにはMCPの使い道（複雑な認証やデータソースへの接続など）がある。俺の経験上、フロンティアモデルを使ってるならどのフォーマットかなんて関係ないし、独自のフォーマットでも普通に動くよ。

本当に議論すべきなのは、スキルによっていかにコンテキスト管理を効率化できるか、っていう点だと思う。スキルはCLIとセットで語られることが多いけど、なぜそうなのか理由がわからないな。例えばAmpだとスキルにMCPサーバーを紐付けられて、エージェントがそのスキルを読み込んだ時に自動でサーバーが立ち上がるようになってる。MCPでもCLIでも、効率的なコンテキスト管理のためにはスキル化するのが正解だと思うし、他のエージェントもこの機能を採用してほしいね。

トークン予算の観点があるからこそ、これは単なる哲学的な好みの問題じゃなくて現実的なアーキテクチャの選択になるんだよね。

プロジェクトで両方のアプローチを試して辿り着いたパターンはこれ。ステートフルなもの（DB接続、認証セッション、ブラウザ自動化など）にはMCPを使い、出力が予測可能なステートレスな操作にはCLIを使う。理由は単純で、MCPのツール定義は常にコンテキストに居座るから、使ってようがなかろうがトークンを消費し続けるんだ。CLIなら必要な時だけ呼び出して後は忘れられる。

ただ、ディスカバリー（機能発見）の側面は過小評価されてる気がする。MCPなら、手の込んだシステムプロンプトを書かなくても、モデルは何のツールがあってどんな引数を取るかを把握できる。CLIだと、モデルが元々そのツール（grepやgit、curlとか）を知っているか、結局こっちで説明を書く羽目になる。それって結局ツール定義を再発明してるだけなんだよね。

正直、この議論全体が2017年頃の「RESTかGraphQLか」みたいな話に聞こえる。どっちも機能するし、答えは制約次第。2年後には、たぶん両方を過去のものにする何かが登場してるよ。

MCP（特にリモートのやつ）はブラックボックスなAPIみたいなものだね。何もインストールしなくていいし、リソースの準備もいらない。ただ呼び出せば答えが返ってくる。そういう場所も必要だけど、結局のところMCPは「大雑把な道具」なんだ。

対してCLIツールは「精密機械」みたいなもの。最初にローカルへインストールする手間はあるけど、一度入れればローカル環境にアクセスして自分で色々と見つけ出してくれる。大きな構造化データを扱うのに特に強力なCLIが2つあって、それがjqとduckdbなんだ。俺はエージェントに、巨大なJSONやCSV、Parquetファイルをコンテキストに読み込ませるな、代わりにそれらのCLIを使ってインテリジェントにサンプリングして調査しろって伝えてる。これに関してはOpus 4.6がマジで凄いんだ！DuckDBやjqで「調査用」のクエリを書いて、数秒でデータの形を自力で把握しちゃう。ボトルネックにぶつかっても、Opus 4.6は何が悪いか自分で突き止めて別のクエリ戦略を試す。深みにハマっても自動で復帰する様子は見ていて圧巻だよ。特にML（機械学習）の仕事で探索的データ解析をする時にめちゃくちゃ役立つ。エージェントがこれらのツールを使ってデータの端っこまで素早くチェックしてくれるから、俺がやるよりずっと徹底してるよ。

あとCLIはMCPより「キビキビ動く」感じがする。MCPはレイテンシがあることが多いけど、CLIはリアルタイムで動いてるのが見えるからね。この使い心地の良さは無視できないな。

追記：エージェントと一緒によく使うCLI:
showboat: コードをリニアに解説させる用
br: Opusに実装計画を指示するためのエピック/ストーリー/タスク作成用
psql: Postgres DBの調査用
roborev: 自動コードレビューと修正用

これってOpenAPIと（JSONかもしれない）ただの文字列を比較してるようなもんだよね。変な感じだし、下手したら意味のない比較かも。

MCPは一般的な意味で（転送プロトコル含め）形式的に定義されているけど、CLIはそうじゃない。特定のCLIなら定義できるけど、一般的なCLIって要は (String, List String, Map Int Stream) -> PID でしかなくて、コマンド名から推測できる以上の細かいセマンティクス（意味論）はないんだ。転送についても「ストリームとPIDを動かせるなら何でもいい」って感じ。詳しく知るには（「--help」が通じることを祈りつつ）("cli-tool", ["--help"], {1: stdout}) みたいなことをしなきゃいけない。あるいはmanやinfo、その他のドキュメントを頼るかだね。

でも結局のところ、どっちも単なるAPIなんだ。十分なセマンティクスが提供されていれば、どっちでも目的は達成できる。

もし最初のプロンプトのコンテキストサイズが心配なら、ドキュメントを全部ぶち込むんじゃなくて、特定のタスクに役立ちそうなツール（MCPでもCLIでも何でも）が外のどこにあるかを回答できるRAGでも入れればいい。あるいは、モデルが適切なツールとその使い方を「本能的に」知っているようにファインチューニングするとかね。

大事なのはMCPかCLIかじゃなくて、「Xを達成するにはFを使わなきゃいけない」っていう中身の方。MCPはそれを構造化して書くための一手法に過ぎないし、CLIにしたからといってその手間が魔法のように消えるわけじゃないよ。

ずっとこれを書くのを避けてきたけど、MCPが現実世界でメリットをもたらすことはないって確信してるよ

個人的には100%同意。ようやく誰かが言ってくれて嬉しい。俺は開発ワークフローのすべてをシェルコマンドで操作するAIエージェントを動かしてるけど、驚くほど優秀だよ。エージェントは見たこともないCLIのフラグだって「--help」の出力から自力で理解しちゃう。一方で、これまで使ったMCPサーバーはどれも手がかかる不安定なプロセスばかりだった。

組み合わせやすさ（コンポーザビリティ）の議論だけでも、この決着はつくはず。CLIの出力をjqにパイプしたり、grepしたり、ファイルにリダイレクトしたりできるけど、MCPでそれができるか？無理だよね。MCPサーバーが返すと決めたものに縛られるし、冗長すぎたら何の成果もないのにトークンを無駄にするだけ。

企業は「AIファースト」であることを証明するために、急いでMCPサーバーを出荷した

ぶっちゃけ、これが真相だよね。MCPの採用は技術的な判断じゃなくてマーケティング上のシグナルなんだ。既存のCLIより出来が悪いサーバーがいくら増えたところで、242%の成長なんて何の意味もないよ。

いい指摘だけど、このブログはLLMの開発者向けユースケースにかなり偏ってる気がするな。非技術者向けのツールやサービスに接続するチャットUIなら、UXの観点だけでもMCPの方がずっと理にかなってるし。

MCP自体に悪いところはないよ。ただ、stdio MCPがオーバーエンジニアリングだっただけだね。

OAuthディスカバリーを備えたMCPのStreamable HTTPは、今の時代、自社製品にAI連携を組み込むためのベストな方法だよ。CLIだとサンドボックス化が必要だし、認証も標準的な方法で扱えないし、ChatGPTやClaudeとも統合できない。

Sentryを見てみなよ。彼らは単一のURL（https://mcp.sentry.dev/mcp）を公開してるだけで、他には何もいらない。MCPをサポートしてるエージェントなら、リンクをクリックしてSentryにログインするだけで、認証済みのデータを取得するためにSentryを呼び出せるようになる。

MCPの主な問題は実装方法にあるんだ。MCPを呼び出すのにbashを使う代わりに、エージェントは単一のMCPツール呼び出しをするように設計されていて、これだと組み合わせが効かない。俺たちはMCPツールをHTTPエンドポイントとして公開することでこの問題を解決したけど、めちゃくちゃ快適に動いてるよ。

MCPサーバーを使うのをやめてから、LLMでうまくいくことがかなり増えたんだ。理由はいくつかあると思う。

一つは、コンテキストの消費量が劇的に減ったこと。二つ目は、MCPの代わりに既存のツールを使いこなすためのより良い指示を与えるようにしたこと。

要するに、MCPはコストが高い割に、軽量なツールを適切な指示で使う以上のメリットがないんだよね。

記事にもあったけど、シェルで使える良いツールとそれをどう使うかの良い指示さえあれば、大きなタスクをこなすのに必要なトークンは劇的に減る。あの環境でのツールの組み合わせやすさは、コンピューティングの世界でも他に類を見ないレベルだからね。

Claudeが自力で良いワークフローを見つけられない稀なケースでも、自分でスキルを作ったりCLAUDE.mdに指示を足したりすれば、驚くほど良い結果が得られるよ。

何かを構築する（あるいは構築されるための準備をする）ならAPIを使おう。これが「プロダクション」用。

探索やコーディング、学習ならCLIを使おう。これが「グリーンフィールド（新規開発）」用。

一般的に、宣言的（Declarative）な方が命令的（Imperative）なものより優れているよね。