
2026/03/02 1:54
**MCP(管理制御プレーン)とCLI:それぞれを使うべき場面** - **CLI(コマンドラインインターフェース)** - *短時間で完結する作業*: 一度または数回だけ実行すればよい単純なコマンド。 - *スクリプトや自動化*:コマンドをスクリプトに埋め込んだり、ジョブとして定期実行したいとき。 - *細かい制御*:一つの操作で詳細なオプションやフラグを指定する必要がある場合。 - *リソース消費が少ない*:GUIもバックグラウンドプロセスも不要。 - **MCP(Management Control Plane)** - *複雑で多段階のワークフロー*: 複数ステージを経る作業やコンポーネント間の調整が必要なケース。 - *永続的な状態管理*: 設定・ポリシー・履歴などをセッション横断して保持したいとき。 - *高可用性・スケーラビリティ*:MCPは水平に拡張可能なサービスとして稼働することが多い。 - *統一インターフェース*:コンテナ、ネットワーク、ストレージなど多様なリソースをひとつの制御点から管理できる。 **結論** 軽量で繰り返し実行可能なコマンドやスクリプトはCLIで。複数コンポーネントを時間をかけて統括する堅牢で状態保持型の管理層が必要ならMCPを利用してください。
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
Summary
著者は、Model Context Protocol(MCP)が実質的に廃れつつあり、コマンドラインインターフェース(CLI)よりも実用性が低いと主張しています。MCP は Anthropic の発表後に導入され、企業はサーバー、新しいエンドポイント、ワイヤフォーマット、および LLM 用の認可スキームを構築するようになりました。しかし、プラットフォームのサポートが限定的(例:OpenClaw、Pi)であり、サーバー設定が脆弱、複雑な JSON 転送ログがデバッグを妨げ、意見に偏った認証ロジックが問題となっています。
対照的に、CLI はほとんどのツールで既に提供されている単純なバイナリです。直接デバッグでき、
jq や grep などの慣れ親しんだシェルユーティリティと組み合わせることが可能であり、人間と LLM の両方に機能するテスト済みの認証メカニズム(AWS プロファイル/SSO、GitHub 認証、kubeconfig)を利用できます。LLM は膨大な量のシェルスクリプトドキュメントで訓練されているため、CLI を自然に使用することができます。
MCP はクリーンなインターフェースを提供することを意図していましたが、実際には CLI と同じ文書作成労力を要し、現実世界のメリットはありません。MCP の実務上の摩擦には、初期化の不安定さ、各ツールごとの再認証、すべてか無い権限の粗雑な許可リスト、ローカルサーバーが失敗またはハングするリスクなどが含まれ、CLI では回避できます。
著者は開発者に対し、まず堅牢な API を提供してから CLI を追加すべきだと提案しています。コミュニティが MCP から CLI に移行すれば、組織はインフラストラクチャの複雑さを削減し、信頼性を向上させ、確立されたツールエコシステムを活用できるようになり、大規模言語モデルとサービス間の相互作用が合理化されます。
本文
私は大胆な主張をしようとしています:MCP(Model Context Protocol)はすでに衰退しているのです。まだ完全に認識されていないかもしれませんが、兆候は見えてきています——OpenClaw はサポートしておらず、Pi も同様ですし、当然の理由があります。
Anthropic が Model Context Protocol を発表したとき、業界全体が一斉に狂ったようになりました。各社は「AIファースト」であることを証明するために MCP サーバーを投入するべく急いだのです。新しいエンドポイントやワイヤーフォーマット、認可スキームへ莫大なリソースが注がれ、LLM が既に使い慣れたサービスと対話できるようになりました。
正直言って、その必要性を完全には理解していませんでした。LLM が本当に得意なのは何でしょう?自ら物事を解決することです。CLI とドキュメントを与えれば、彼らはすぐに動き出します。
長い間このテーマを書きたくありませんでしたが、やはり MCP は現実世界でのメリットがなく、むしろ不要だと確信しています。以下で説明します。
LLM には特別なプロトコルは必要ない
-
CLI の使用に長けている
LLM は数百万ものマニュアルページや Stack Overflow の回答、GitHub 上のシェルスクリプトを学習しています。Claude に
を使わせれば、すぐに機能します。gh pr view 123 -
MCP はクリーンなインターフェースを約束しましたが
実際には同じドキュメントを書かざるを得ませんでした:各ツールの機能、受け付けるパラメータ、そして何よりもいつ使うべきか。LLM は新しいプロトコルを必要としていませんでした。
CLI は人間にも役立つ
-
Claude が Jira で予期せぬ動作をしたとき
同じ
コマンドを実行すれば、入力も出力も同じで、何が起こったかを明確に確認できます。jira issue view -
MCP の場合は LLM 会話内だけのツールです
問題が発生すると JSON トランスポートログを調査しなければならず、単純にコマンドを自分で実行するよりも複雑になります。デバッグにはプロトコルデコーダーは不要です。
コンポジビリティ
ここが差が生まれるポイントです。CLI はパイプや
jq との連携、grep のチェーン、ファイルへのリダイレクトなどを自然に行えます。これは単なる便利さではなく、多くの場合唯一の実用的な手段です。
大規模な Terraform プランを分析するケースを考えてみましょう:
terraform show -json plan.out | jq '[.resource_changes[] | select(.change.actions[0] == "no-op" | not)] | length'
MCP では、プラン全体をコンテキストウィンドウに投入する(高価でほぼ不可能)か、MCP サーバー自体にカスタムフィルタリングを組み込むかのいずれかです。どちらにしても、より悪い結果を得るために余分な作業が発生します。CLI アプローチは既存でドキュメント化され、人間とエージェントの両方が理解できるツールを利用しています。
認証はすでに機能している
MCP は認証について不必要に主観的です。LLM にツールを与えるプロトコルが認証に関心を持つべきでしょうか?
- CLI ツールは気にしません。
はプロファイルと SSO を、aws
はgh
を、gh auth login
は kubeconfig を使用します。これらはキーボードで操作する場合も Claude が動かす場合も同じでテスト済みの認証フローです。認証が壊れたときはいつものようにkubectl
、aws sso login
で修復します。MCP 専用のトラブルシューティングは不要です。gh auth refresh
動的な構成要素がない
ローカル MCP サーバーはプロセスです。起動し、稼働し、黙ってハングしないように管理する必要があります。Claude Code では子プロセスとして生成されますが、うまくいかないこともあります。
CLI ツールはディスク上のバイナリに過ぎません。バックグラウンドプロセスや状態管理、初期化ダンスはありません。必要なときにそこにあり、不要なときには見えません。
実際の痛み
設計哲学を超えて、MCP は日常的に摩擦を生み出します:
-
初期化が不安定
MCP サーバーが起動しないために Claude Code を再起動した回数は数え切れません。リトライで成功する場合もあれば、状態をクリアして最初からやり直す必要があります。 -
再認証が永続的
複数の MCP ツールを使用すると、それぞれに認証が必要です。CLI は SSO や長期有効な資格情報でこの問題はありません。一度認証すれば終了です。 -
権限は全てか無いか
Claude Code ではツール名で allowlist ができますが、それだけです。読み取り専用操作やパラメータ制限まで細分化できません。CLI なら
は allowlist し、gh pr view
は承認を求めるといった微細な粒度が可能です。gh pr merge
いつ MCP が意味を持つのか?
MCP が完全に無用だとは言っていません。ツールに CLI の等価物が実際に存在しない場合、MCP は正しい選択肢になるでしょう。私は日常業務でそれが唯一利用可能なケースも多く使っています。
標準化されたインターフェースを持つことに価値があると主張する人もいますし、CLI よりも意味があるユースケースは確かに存在するでしょう。
しかし、大多数の作業では CLI がシンプルでデバッグが速く、信頼性があります。
本当の教訓
最高のツールとは、人間と機械の両方に使えるものです。CLI は何十年にもわたる設計イテレーションを経てきました。コンポジブルでデバッグしやすく、既存の認証システムを活用しています。
MCP はより良い抽象化を構築しようとしましたが、結局私たちはすでにかなり優れたものを持っていたということです。
建設者へのお願い
もし MCP サーバーに投資している企業が公式 CLI を持っていないなら、一旦立ち止まって再考してください。まずは良い API を提供し、次に良い CLI を配備しましょう。エージェントは自ら学びます。