MCPは死んだ。CLI万歳

 (ejholmes.github.io)
36 ポイント 投稿者 GN⁺ 2026-03-02 | 8件のコメント | WhatsAppで共有
  • MCPは業界で急速に関心を失っており、今ではCLIベースのアプローチのほうがより実用的
  • LLMはすでにコマンドラインツールの利用に長けており、別個のプロトコルがなくても文書とCLIだけで十分に作業を遂行可能
  • CLIは人間とLLMの両方が同じ環境で実行・デバッグ可能で、問題原因の把握が単純
  • 合成可能性(composability)と認証体系、安定性の面でもCLIはMCPより効率的で保守しやすい
  • MCPは初期化の不安定さ、繰り返しの再認証、権限制御の欠如など、実務で継続的な摩擦を引き起こす
  • ほとんどの場合、CLIのほうがより単純で信頼性の高い選択肢であり、企業はMCPサーバーより先にAPIとCLIの提供に注力すべき

MCPの限界とCLIの優位性

  • Anthropicの**Model Context Protocol(MCP)**発表以降、業界は競うようにMCPサーバーを構築したが、OpenClawやPiなど主要ツールはこれをサポートしておらず、実質的な利点もない
    • LLMはすでにCLIとドキュメントを通じて作業を実行できる
    • MCPは新たなエンドポイントと認証体系を追加するが、既存機能を重複させるだけ
  • LLMはCLIツールの利用に最適化されており、非常に習熟している
    • 数百万件のman page、Stack Overflowの回答、GitHubのシェルスクリプトを学習している
    • たとえば gh pr view 123 のようなコマンドをClaudeに指示すれば、そのまま動作する
  • MCPはよりクリーンなインターフェースを約束したが、実際には各ツールの説明・パラメータ・使用タイミングを同じように文書化しなければならない

CLIは人間にとっても有用

  • CLIでは人間とLLMが同じコマンドを共有できる
  • Jiraで予期しない挙動が起きたとき、同じ jira issue view コマンドを直接実行して再現できる
  • MCPではツールがLLMの会話内にしか存在せず、問題発生時にはJSON送信ログを掘り返す手間が生じる
  • デバッグにプロトコルデコーダが必要であってはならない
  • CLIは入力と出力が明確で、問題追跡が容易

合成可能性(Composability)

  • CLIは jq、grep、ファイルリダイレクトなどとパイプラインで組み合わせられる
  • 大規模なTerraformプラン分析の例:
    • terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'
  • MCPではプラン全体をコンテキストウィンドウにダンプする必要があり（高コストで、しばしば不可能）、またはMCPサーバー自体にカスタムフィルタリングを実装しなければならない
  • CLI方式は、すでに存在し十分に文書化されたツールを活用し、人間とエージェントの双方が理解できる

認証(Auth)の問題

  • MCPは認証について不必要に強い前提を持ちすぎている(opinionated)
  • CLIツールはすでに検証済みの認証体系を使っている: aws はプロファイルとSSO、gh は gh auth login、kubectl は kubeconfig
  • 人間が直接使う場合でもClaudeが駆動する場合でも、同じ認証フローが適用される
  • 認証問題が起きた場合も、aws sso login、gh auth refresh など既存の方法で解決でき、MCP専用のトラブルシューティングは不要

運用上の問題点: 可動部品がないこと(No Moving Parts)

  • ローカルMCPサーバーは別途プロセスを起動・維持する必要があり、Claude Codeでは子プロセスとして生成されるため、ときどき問題が起きる
  • CLIツールはディスク上のバイナリファイルにすぎず、バックグラウンドプロセス・状態管理・初期化手順が不要

実務での不便さ

  • 初期化の不安定さ: MCPサーバーが起動せずClaude Codeを再起動することが頻繁にあり、状態を初期化してから再試行する必要がある
  • 繰り返しの再認証: 複数のMCPツールを使うとそれぞれで認証が必要だが、SSOや長期有効な資格情報を使うCLIにはこの問題がない
  • 権限制御の粗さ: Claude CodeではMCPツールを名前ベースで許可できるが、読み取り専用制限やパラメータ範囲の指定はできない
    • CLIでは gh pr view は許可し、gh pr merge には承認を求めるなど、きめ細かな権限制御が可能

MCPが有効な場合

  • CLIに相当するツールがまったく存在しない場合、MCPが適している可能性はある
  • 標準化されたインターフェースとしての価値や、CLIよりMCPのほうが適したユースケースが存在する可能性は認められる
  • しかし大半の作業ではCLIのほうが単純で、デバッグが速く、信頼性が高い

中核的な教訓とビルダーへの要請

  • 最高のツールとは人間にも機械にも機能するツールであり、CLIは数十年にわたる設計の反復を経て、組み合わせやすく、デバッグしやすく、既存の認証システムと統合されている
  • MCPはより良い抽象化を作ろうとしたが、すでに十分に良い抽象化が存在していた
  • MCPサーバーに投資しながら公式CLIを持たない企業は戦略を再考すべきであり、
    良いAPI → 良いCLI の順で提供すれば、エージェントが自律的に活用する
  • 不要なプロトコルの複雑さを減らし、生産性と保守性を向上できる

関連記事

8件のコメント

 
sonnet 2026-03-03

MCPに利点がないというわけではなく、MCPの利点がない用途にまで無差別に使っていた幻想から目が覚めたということです。マイクロサービスをLLMのために公開する時もCLIを使うわけではないですし、MCPは「API」プロトコルなのですから。
 
brainer 2026-03-03

あのときもAPIを使えばよかったんですよね。実際、MCPを使っていた理由はlong contextの限界のためだったのですが、今ではその限界の大半を克服したので。
 
jamsya 2026-03-03

ものすごく共感します。
aws mcpを入れなくても、Claude Codeが勝手にaws cliで必要なものを取ってきて使っていました 😂
 
GN⁺ 2026-03-02
Hacker Newsの意見

  • 長い間この言い方を避けてきたが、今ではMCPには実質的な利点がないという確信がある
    自分は開発ワークフロー全体をシェルコマンドで制御するAIエージェントを運用しているが、こいつらはCLIフラグを初めて見ても--helpの出力だけでうまく把握する
    一方でMCPサーバーは常に不安定で、管理が必要だった
    CLIはjq、grep、ファイルリダイレクトなどで組み合わせられるが、MCPはサーバーが返す形式に縛られている
    結局のところMCP採用は技術的理由というより、「AI-first」なマーケティングシグナルにすぎないと思う

    • MCPは2024年に急成長したが、2025年初頭に**ターミナルエージェント（Claude Code）**が登場して、メタが急速に変わった事例だと思う
    • 私は逆にMCPを好む。CLIよりもエラー処理とデバッグがずっとクリーンで、危険なフラグを制限したり、結果をページネーションで分割したりできる
      MCPはRESTやgRPCのように、単なるラッパー概念として理解すればよい
    • 自分もMCPは避けている。JIRA MCPを使ってみたがひどかった。その代わり、LLMにAPIを直接呼ばせてスクリプトを書かせた方がずっと効率的だった
      今はLLM CLIツールが頂点だと思う
    • うちの会社では、社内WikiのようなWeb専用ツールをMCPで公開して、Claudeがログとメトリクスを直接照会できるようにしている
      ただ、MCPの結果が常にコンテキストウィンドウに入るのは不便だ。ファイルシステムにダンプできればよいのにと思う
    • MCPサーバーは、LLMがまだ十分に発達していなかった頃に作られた過渡的な産物のように思える。CLIデータで学習する方がずっと良いと思う

  • MCPは、インストールやリソースプロビジョニングなしにすぐ呼び出せるブラックボックスAPIのようなものだ
    一方CLIはローカル環境にアクセスできるので、はるかに精密だ
    jq、duckdb CLIを使って大規模なデータファイルをサンプリングし、Opus 4.6が自動でクエリを調整しながら探索する
    CLIはリアルタイム応答性が高く、探索的データ分析に特に有用だ
    よく使うCLIにはshowboat、br、psql、roborevなどがある

    • 自分も同じ経験をした。CLIのテキスト入出力はLLMの学習方式と最も相性が良い
      duckdbをChatGPTと一緒に使ったときは楽しかったが、ローカルDBを維持するようにシステムプロンプトを設定しているのか気になる
    • CLIの代わりにDockerコンテナでコマンドを実行すれば、インストールの問題を避けられる。こうしたアプローチを自動化する「skill」を作ることもできそうだ
    • 英語非ネイティブとして、MCPsのように複数形を使うのが面白く感じる

  • MCPは、CLIにないツールを見つけて文脈に応じて呼び出すときに意味がある
    たとえば自分が作ったechomindrは、ポッドキャストから創業者の意思決定を抽出したDBをMCPとして提供している
    Claudeがスタートアップ関連の質問を受けると、実際の創業者の経験を検索して答える
    CLIは人間がどのツールを使うべきかをすでに知っている場合に適していて、MCPは発見型のツール選択に適している

  • 筆者はAIの使い方を開発者中心にしか見ていないようだ
    ほとんどのユーザーはChatGPTのようなWebベースのインターフェースでLLMを使っている
    企業の立場では、マーケティング、セールス、プロジェクト管理ツールをつなぐにはMCPの方がはるかに適している

  • MCP自体は悪くないが、stdio MCPは過剰設計だ
    その代わり、Streamable HTTP + OAuth Discovery方式が、最近では最も効率的なAI統合の方法だ
    たとえばSentry MCPは、単一のURLだけで認証とデータアクセスが可能だ
    問題はMCPの実装方式だ。bashで呼び出す代わりに、MCPをHTTPエンドポイントとして公開すれば、はるかに柔軟に動作する

    • CLIでもMCPでも、権限システムはAPIレベルで一貫して設計されるべきだ。Streamable HTTPの部分はもう少し説明が必要だと思う
    • 自分も同じ立場だ。集中化された認証とテレメトリーの方がずっと簡単だ。ただし、正しい用途にだけ使うべきだ

  • 私の顧客の一部にはMCPサーバーがないのに、開発者たちがそれを求めてくる
    結局、Postman APIをJSONでエクスポートして提供したが、開発者たちはMCPサーバーを欲しがる
    MCP対応の有無がマーケティングのチェックリストのように機能しているのが現実だ

  • このブログは開発者中心の視点に偏っているようだ
    非開発者向けツールやサービスと接続するときは、MCPの方がはるかに自然だ

    • その通り。チャットインターフェースではCLI実行が不可能で、非開発者向けサービスにはCLI自体がない
    • ChatGPTやLeChatのようなWeb・モバイルインターフェースでCLIを動かせるのかも疑問だった
    • 非開発者向けインターフェースは、すでにOpenClaw、Claude Coworkのような形へ進化しつつある

  • 「MCP 5年経験者募集」のような求人広告は、結局無意味なミームになったわけだ

  • CLIがMCPより優れている理由の1つは、情報理論的に最適化された形式を持っているからだ
    Unixツールの出力は関連情報が近くに配置されていて、LLMの注意メカニズムが効率的に働く
    JSONはパースはしやすいが、読むことや推論には不便だ
    CLI形式は人間にもLLMにも直感的だ
    関連参考: Entropy and Information Layout

  • MCPとCLIの比較は、まるでOpenAPIと文字列（JSON）を比較するようなものだ
    MCPは形式的に定義されている一方、CLIは(String, List String, Map Int Stream) -> PIDレベルの抽象インターフェースだ
    結局どちらもAPIにすぎず、重要なのは    目標達成のために適切なツールを選ぶこと    だ

    • しかしCLIは--helpで完全なドキュメントを提供するので、LLMがそれを理解できるならMCPの標準化の方が良いとは言いにくい
    • 理論より実際の使用経験が重要だ。MCPとCLIが同じだと言うなら、たとえばPlaywright CLIとMCPが同じトークン使用量と構成可能性を示す例を作るべきだ
      そうでなければ、現実には両アプローチが異なることを直接体感するはずだ
 
develosopher 2026-03-03

ある人がSaaSを開発していて、AI統合のためにCLIとMCPのどちらか一方を検討するなら、おそらく先にMCPを選ぶ気がします。CLIをサポートするのは管理ポイントが増えることですからね。両立はできても、なくなりはしないと思います。
 
hanje3765 2026-03-03

LLMの知能が高まるにつれて、MCPの必要性が曖昧になってきたということのようですね。
私も実際にそう感じています。
 
m00nlygreat 2026-03-03

リモート実行はmcp、ローカル実行はskillsとして整理されるようです。
 
hulryung 2026-03-03

私もMCPよりCLIでツールを直接作って使い始めました。