ハクソク

世界を動かす技術を、日本語で。

MCPとCLIはいつ使い分けるべきか？

85日前原文(ejholmes.github.io)

概要

MCP（Model Context Protocol） の普及が停滞している理由を解説。 CLI（コマンドラインインターフェース） の優位性を具体例とともに強調。 認証やデバッグの簡便さ など、CLIの現実的な利点を列挙。 MCPが適切な場合もあるが、 大半の用途ではCLIが有効 と主張。 開発者への提言として、まず CLIの提供を優先 する重要性を訴求。

MCPはすでに衰退しつつある

  • OpenClaw や Pi がMCPをサポートしていない現状
  • Anthropic によるMCP発表時の業界の過剰反応
  • 多くの企業が MCPサーバー開発にリソース投入 という非効率
  • LLMが既存の方法で十分にサービスと連携できる事実
  • MCPの現実的な価値への疑問

LLMに特別なプロトコルは不要

  • LLMは CLIツールの利用が得意 である訓練済み
  • マニュアルやStack Overflow、GitHub などの情報も豊富に学習
  • MCPによるインターフェースの「清潔化」は 実際には冗長
  • 結局 CLIの使い方やパラメータ説明 など、同じドキュメント作成が必要
  • 新プロトコル導入の実益の薄さ

CLIは人間にも分かりやすい

  • LLMがJira操作で想定外の動作をした場合、 同じCLIコマンドで確認可能
  • CLIなら出力の透明性 が担保される
  • MCPでは 内部的なやり取りがブラックボックス化 しやすい
  • デバッグの難易度上昇 と非効率化

CLIの強力な構成性

  • CLIはパイプやリダイレクトによる柔軟な組み合わせ が可能
    • jqやgrepとの連携
    • ファイルへの出力
  • 例： Terraformの大規模プラン分析 もCLIなら既存ツールで簡単対応
  • MCPでは データ全体をコンテキストに投入（非効率・高コスト） や、サーバー側でのカスタム実装が必要
  • CLIの方が既存の資産や知見を活用しやすい

認証は既存の仕組みで十分

  • MCPは 認証方式が独自で過剰
  • CLIは aws, gh, kubectl など、既存の認証フローが安定
  • 認証トラブル時も 従来通りの解決手順 で対処可能
  • MCP固有のトラブルシューティング不要

余計なプロセス管理が不要

  • MCPサーバーはプロセス管理が必要 で、不安定要素
  • Claude Codeでは 子プロセスとして起動 だが、失敗時に再起動や状態リセットが必要
  • CLIは単なるバイナリ で、プロセス常駐や初期化不要
  • 必要な時だけ起動・利用できる シンプルな運用

MCP導入による実務的な不便さ

  • 初期化の不安定さ で作業効率低下
  • MCPツールごとに 認証作業が煩雑
  • CLIならSSOや長期認証で一括管理 が可能
  • MCPの 権限管理が大雑把 で、CLIのような細やかな操作制御が不可
  • 具体例： gh pr view は許可、 gh pr merge は承認必須など、CLIなら柔軟な許可設定

MCPが有効なケース

  • CLI相当が存在しないツール にはMCPが有用
  • MCPの 標準化インターフェース としての価値は一定あり
  • ただし 大半の業務ではCLIの方が現実的

本質的な教訓

  • 人間と機械の両方に使いやすいツールが最良
  • CLIは 長年の設計改善 で熟成
  • デバッグ性・構成性・認証連携 の面でCLIが優秀
  • MCPは 既存の良い仕組みを置き換えるには至らず

開発者への提言

  • MCPサーバー開発前に公式CLIの提供を優先 する重要性
  • まず APIとCLIを整備 し、エージェント側での活用を促進
  • LLMやエージェントは既存CLIを十分活用可能 である現実

Hackerたちの意見

昨年の5月頃から、反MCP・賛CLIの流れが続いてるね（私もその頃からずっと言ってるけど）。でも、MCPには本当に実用的な使い道があると思う。特に、MCPはカプセル化の素晴らしい単位なんだ。私はセキュアエージェントフレームワーク（https://github.com/sibyllinesoft/smith-core）を使って、MCPをサイドカー経由でマイクロサービスに変換してサービスメッシュに接続してる。これで、エージェントの機能を簡単にセキュアにできるんだ。エージェントは、すべてのコマンドをbashでcurlするだけで済むから、CLIが必要なくなる。CLIは少しトークン効率が良いけど、全体的にはシンプルさとパワーが大きな勝利だよ。

MCPとCLIのどちらが優れているかをみんなが議論してるなんて信じられない。どちらもツール呼び出しの方法で、LLMがどのフォーマットを使っても、同じ機能を提供できれば問題ないんだ。CLIの方がほんの少し良いかもしれないけど（LLMは一般的なCLIで訓練されてるかもしれないし）、MCPにも使い道がある（複雑な認証やユーザーをデータソースに接続するなど）。私の経験では、フロンティアモデルを使っているなら、どのツール呼び出しフォーマットを使ってもあまり関係ないよ。オーダーメイドのフォーマットでも問題ないしね。話すべき違いは、スキルがどれだけ効率的なコンテキスト管理を可能にするかだと思う。スキルはCLIの使用とよく結びつけられるけど、理由が見当たらない。例えば、AmpではスキルにMCPサーバーを接続できるんだ。エージェントがそのスキルを読み込むと、MCPサーバーが自動的に起動する[0]。MCPサーバーとCLIの両方において、スキルに組み込むことが効率的なコンテキストの方法だと思うし、他のエージェントもこの機能を採用してくれることを願ってるよ。[0]: https://ampcode.com/manual#mcp-servers-in-skills

└

MCP対CLIは、カッコのメリットと重要な空白について議論している現代版みたいなもんだね。つまり、長く議論することにはならないと思う。

└

MCPはトレーニング中にサポートされ、LLMに組み込まれる必要があるけど、CLIはすでにトレーニングセットで非常に一般的なんだ。MCPは特に大きなメリットを提供しないから、良いCLIツールとLLMによるその使用が今後の道だと思う。

└

同じ機能を提供できれば問題ないんだ。もしあなたの「機能」の定義が、提供されたツールのモデル理解や、ツールを理解しようとする際のトークンの無駄遣いを含むほど広いなら、それはいいけど。ツールを理解できないものを与えたら、同じ機能を持つツールを理解している場合でも、トークンを大量に消費することになるよ。ツールの組み合わせがパフォーマンスや成功率、効率に大きく影響することを示す証拠はたくさんある。あなたの段落の最後でも、いくつかのモデルにしか焦点を当てていないことを認めているよね。でもそれでも、理解できないツールを与えたら、トークンを無駄にすることになるよ。ツールは本当に重要なんだ。

└

いや、本当に重要なんだ。コンテキストトークンに与える影響があるから。MCPに関するGHの問題を読むだけで、仕様を読み込むのに54,000トークンも消費するんだ。複数のMCPを使うと、すぐにトークンが増えていくよ。

└

エージェントがそのスキルを読み込むと、MCPサーバーが自動的に起動する 現在のこのアプローチの主な問題は、プロンプトキャッシュが壊れることなんだ。LLMはすべてのツール定義がコンテキストウィンドウの最初に定義されることを期待しているから。入力トークンは推論コストの主な要因で、多くのユースケースはプロンプトキャッシングなしでは経済的じゃない。将来的には、LLMがコンテキストウィンドウのどこにでもツール定義を追加できるように訓練されることを願ってる。多くのユースケースがこれから恩恵を受けると思う。例えば、eコマースでは、最初にLLMに「カートをクリアする」ツールを提供する意味はあまりないから、アイテムが最初に追加された後に動的に提供できるといいよね。

└

両方ともツール呼び出しの方法で、LLMがツール呼び出しにどのフォーマットを使うかは、同じ機能を提供する限り関係ない。MCPのツール呼び出しはコンポーザブルじゃない。同じ機能じゃない。大きな違いだよ。

└

うん、もっとスキルを使わなきゃ。先週、自分が作ったスキルを使うまで、あんまり理解できてなかったんだ。スキルが実行される単一のコマンドのためだけにコンテキストに引き込まれるって知らなかった。スキルが呼ばれたらコンテキストに引き込まれて、そのまま残ると思ってた。今考えると、それはすごく強力なことだね。

MCP（特にリモートMCP）は、まるでブラックボックスAPIみたいだね。何もインストールしたり、リソースを準備したりする必要がない。呼び出すだけで、答えが返ってくる。そういうのも必要だけど、MCPは結局鈍器みたいなもんだ。一方でCLIツールは精密機器みたいなもの。確かに一度ローカルにインストールする必要があるけど、その後はローカル環境にアクセスできて、自分で物事を発見できる。特に大規模な構造化データを扱うのに強力なCLIが2つある：jqとduckdb CLI。エージェントには、大きなJSON、CSV、Parquetファイルをコンテキストに読み込ませないように言ってる。代わりに、これらのCLIツールを使ってデータをサンプリングして賢く調べるんだ。そしてOpus 4.6はこれがすごく得意！数秒でデータの形を理解して、DuckDBやjqで「プロービング」クエリを書くんだ。ボトルネックにぶつかると、Opus 4.6は何が問題かを理解して、他のクエリ戦略を試す。うさぎの穴に入っていく様子を見て、そして自動的に回復するのは本当にすごい。これはML作業での探索的データ分析に特に役立つ。エージェントはこれらのツールを使って、データのエッジケースを素早くチェックして、私よりもずっと徹底的に仕事をしてくれる。CLIはMCPよりも「サクサク」動く感じがする。MCPは遅延があることが多いけど、CLIはリアルタイムで動くのが見える。これには特有の使いやすさがあるね。追記：エージェントと一緒に使うことが多い他のCLI：showboat（Simon Willison）でコードのリニアウォークスルーをする。br（Rust版Beads）でOpusに計画を実装するためのエピック/ストーリー/タスクを作成する。psqlでPostgresデータベースを調べる。roborev（Wes McKinney）で自動コードレビューと修正を行う。

└

俺もそれを見つけたよ。CLIはインタラクティブにテキストを出力したり入力したりするから、テキストベースのLLMには最適だと思う。視覚やマルチモーダルモデルが進化すれば、もっとクレイジーなインタラクションが見られると思うよ。duckdbについてだけど、ChatGPTとduckdbで話すのは楽しいけど、インメモリDBだけにしてるんだ。現在のフォルダにローカルでduckdbデータベースを保持するようなシステムプロンプトを設定してる？

└

一度ローカルにインストールするか、Dockerをインストールして、エージェントがローカルディレクトリをマウントしたDockerコンテナ内でCLIコマンドを実行する必要がある。そうすれば、基本的に何もインストールする必要がなくなる。CLIのやり取りのためにDocker（またはPodmanなど）を使う方法を説明する「スキル」を設定できると思うけど、まだ試してないんだ。

これはOpenAPIと文字列（JSONかもしれない）を比較するようなもので、変だし、意味がないかもしれないね。MCPは一般的な意味で正式に定義されてるけど（トランスポートプロトコルを含む）、CLIはそうじゃない。特定のCLIだけが定義できるけど、一般的なCLIはただの(String, List String, Map Int Stream) -> PIDで、細かい意味は付いてない（コマンド名が示すことを除いて）。トランスポートは「ストリームとPIDを動かすために持ってこれるものなら何でも」って感じ。("cli-tool", ["--help"], {1: stdout})を使わないと、詳しいことはわからないよね（「--help」が認識されることを期待して）。それか、標準化されたドキュメントがあればman/infoを使うか、他のドキュメントを参照するしかない。でも、結局どっちもAPIなんだよね。十分な意味が提供されれば、どちらも目的を果たす。もし即時の（最初のプロンプト）コンテキストサイズが気になるなら、ドキュメントを積極的に押し付けるんじゃなくて、特定のタスクに役立つツール（MCPやCLIなど）が何かを答えられるRAGを入れればいいんじゃないかな。あるいは、モデルが「正しいツールを使う方法を自然に知っている」ように微調整するのもあり。要するに、重要なのはMCPやCLIじゃなくて、「Xを達成するにはFを使わなきゃいけない [詳細は続く]」ってことなんだ。MCPはこれを構造化された方法で書く手段に過ぎないし、CLIもこの問題を魔法のように回避するわけじゃない。

└

CLIツールは--helpを使って完全なドキュメントを提供するように設計されてる。LLMがその出力を完全に理解できるなら、MCPの標準化はCLIの--helpの標準化よりもどうして良いの？

└

理論に時間をかけるより、実践にもっと時間を使った方が、みんなが何を言いたいのか理解できると思う。理論上、MCPとCLIは同じかもしれないけど、実際は今のところ違うんだよね。

MCPは、これを構造化された形で書く方法に過ぎない。 いやいや、君は理解してないか、意図的に違いを無視してるよ。ここだけで20以上のコメントで説明されてることなんだから。これは論争の余地がある主張じゃなくて、関連するユーザーコミュニティが合意している事実なんだ。君が今言ってることは間違ってると思われてるし、もし君が他の人が知らないことを知ってるなら、playwright CLIとplaywright MCPが同じ数のトークンをコンテキストに追加し、どちらも同じように設定可能であることを示す例のリポジトリを作るべきだよ。もし多くの人が失敗したところを君がうまくやれたら、それは本当に大きな貢献になると思う。できなければ、理論的に考えてる時には理解できなかったことを直接体験することになるよ。

ずっとこれを書くのを避けてきたけど、MCPには実際の利益がないと思う。これは100%正しいと思うし、誰かが言ってくれて嬉しい。俺はシェルコマンドで開発ワークフロー全体を制御するAIエージェントを運用してるけど、驚くほど上手くやってる。エージェントは、見たことのないCLIフラグを--helpの出力から理解するんだ。一方で、俺が使ったMCPサーバーは、いつも不安定で手間がかかるプロセスだった。コンポーザビリティの議論がこの議論を終わらせるべきだと思う。CLIの出力をjqでパイプしたり、grepしたり、ファイルにリダイレクトしたりできるけど、MCPではそれができない。MCPサーバーが返すものに縛られて、もしそれが冗長すぎたら、無駄にトークンを消費してるだけだ。 > 企業は「AIファースト」の証拠としてMCPサーバーを急いで出荷したけど、これは本当の話。MCPの採用は技術的なものではなく、マーケティングのシグナルだ。MCPサーバーが242%成長したって、ほとんどが既存のCLIより劣ってるなら意味がない。

└

読んでくれてありがとう！そうだね、もし誰かがこれから何かを持ち帰るとしたら、それはツールの組み合わせについてだね。他の議論は議論の余地があるけど、それだけは間違いない。

└

完全に同意だね。MCPサーバーは、AIやLLMがまだあまり発展していなかった時期に作られたから、色々な面で能力が低かった。CLIやシェルコマンドを使ってツール呼び出しを改善するためのデータがたくさんあるのに、MCPサーバーでポストトレーニングしたいってのは変に思えた。

└

LLMが見るCLIインターフェースと人間のインターフェースをどう分けるの？例えば、LLMにデータを読み取るだけのアクセスを与えたいけど、書き込ませたくない場合。明らかな解決策は、認証レイヤーでこれを設定することだけど、この場合MCPを使うのが便利かもしれないね。

└

私はほとんどのMCPを避けてる。LLMにスクリプトを書かせて出力を取り込むよりも、コンテキストを多く取る傾向があるから。JIRAのMCPを使おうとしたらめちゃくちゃだったし、LLMにAPIを叩かせて、カスタムスキーマを理解させて、必要なことを正確にやるためのスクリプトをいくつか書く方がずっと良かった。今はそのスクリプトが再利用できるし、使うコンテキストも少なくて済む。私には、LLMのCLIツールが今のところ最高峰に見える。LLM関連の企業は、何がうまくいくか試すために、たくさんのアイデアを壁に投げつけてる感じだね。

└

ツールはコンテキストスペースをめっちゃ食うよね。対照的に、シェルツールはClaudeに組み込まれてるし。

└

MCPサーバーは嫌いだな。ただ、MCPサーバーの核心的な主張は、LLMに企業サービスの周りにガードレール付きのAPIを提供することなんだ。Gmailの統合がいい例だね。MCPがなければ、VMをスクラッチスペースとして使ったり、OAuthを更新する方法を用意したり、LLMがメールの半分を削除するようなクレイジーなことをしないようにする手段が必要なんだ。信頼できるプロバイダーが構築したMCPサーバーは、これらの問題をすべて解決してくれる。でも、実際にはそうはならなかった。開発者たちとAnthropicはこの件に夢中になって、概念をややこしくしちゃったんだ。例のサーバーはいつも役に立たないし、面白いと思ってたよ。信じられないことに、今でもメンテされてるんだよね。

└

最初からそう思ってた。もし「完全に観測可能」や「決定論的」なことができないなら（おそらくその言葉の緩い定義で）、何の意味があるの？

いいポイントだね。でも、このブログはLLMの開発者ユースケースにかなり焦点を当ててると思う。非開発者向けのツールやサービスと接続するためのチャットスタイルのインターフェースでは、UXの観点からももっと意味があると思う。

└

ありがとう、私もこんなことを言おうと思ってた。ここにあるコメントを全部読んで、「ChatGPTやLeChatとかって、ウェブやモバイルのインターフェースからCLIを実行できるのかな？」って考えてた。

└

そうそう。チャットインターフェースでCLIを実行できないだけじゃなくて、非開発者が使うサービスにはそもそもCLIがないことが多いんだ。開発者はターミナルにいるから、豊富なCLIを持っていて、自分のためにそのツールを作ってるんだよね。

これはちょっと方向性が間違ってる気がする。MCPは、決定論的なサブフロー（つまり、段階的なプロセス）を実行するための最良の方法の一つであり、LLMが実行中に迷子になるか、直接アクセスすべきではないツールを安全に扱うためのものなんだ。

└

まだMCPがどのタイミングでうまく機能するのか理解するのに苦労してる。しばらくすると、全部CLIに移行しちゃうんだ。もっと具体的な例を教えてくれない？君の言ってることは信じてるけど、ただ理解できないだけなんだ。

└

MCPで一番興味があるのはセキュリティレイヤーだね。CLIにフルアクセスを許可するのは超危険に感じるし、LLMの使用を制限したいコマンドもあるかもしれない。

MCP自体には問題ないんだけど、stdio MCPはやりすぎだったね。MCPのStreamable HTTPとOAuthディスカバリーは、今のAI統合には最適な方法だよ。CLIはサンドボックスが必要だし、標準的な方法で認証を扱わないし、ChatGPTやClaudeとも統合できない。Sentryを見てみて、彼らは単一のURL、https://mcp.sentry.dev/mcpを提供していて、他に何も必要ないんだ。MCPをサポートするエージェントは、Sentryにログインするためのリンクをクリックできて、認証されたデータを取得するためにSentryに呼び出しを行うんだ。MCPの主な問題は実装だね。bashを使ってMCPを呼び出す代わりに、エージェントは単一のMCPツール呼び出しをするように設計されていて、コンポーザビリティを許さないんだ。この問題は、MCPツールをHTTPエンドポイントとして公開することで解決して、うまくいってるよ。

└

これも同意だな。設定がめっちゃ簡単で、認証とテレメトリーが集中化されてる。正しいユースケースに使えばいいだけだよ。

MCPサーバーを使わなくなってから、LLMでの成功がかなり増えたよ。いくつかの理由があると思ってて、一つはコンテキストの使用がかなり減ったこと、もう一つは、利用可能なツールを使うためのより良い指示に置き換えたこと。要するに、MCPは高くつくし、軽量なツールを使うための良い指示には勝てないってこと。記事にもあるように、シェルに良いツールがあって、それを使うための良い指示があれば、かなりの作業を行うために必要なトークンが劇的に減るんだ。特に、その環境でのツールのコンポーザビリティは、コンピューティングでは前例がないからね。Claudeが良いワークフローを自分で見つけられない珍しいケースでも、スキルを作ったりCLAUDE.mdに指示を追加すれば、結果は驚くほど良いよ。

MCPって全然役に立たない抽象概念だと思うんだけど、なんで誰かが基本的なCLIツールやスキルよりもこれを推すのか理解できない。