「完全な MCP」から「シェルの再発見」へ
2024 年後半、コミュニティはかつて MCP が世界を統一するためのツールを統合すると信じていました。各サービスは MCP サーバーとしてパッケージ化され、各エージェント ホストは MCP をサポートし、各ワークフローは MCP ツール呼び出しを通じて完了する必要があります。私もトレンドに従い、GitHub MCP、Playwright MCP、Memory MCP、Sequential Thinking、Context7、Exa、Firecrawl などを多数インストールしました。
しかし、半年後、傾向は非常に明らかです。コーディングエージェントの日常的なワークフローここで、本当に毎日使い、最後まで使い切るツールは、ほとんどMCPではなくCLIです。クロード・コードによるBash、gh、git、kubectl、rtk、cmux、これらは日々の生産性の主軸です。
これは「MCP の失敗」ではありません (Anthropic は 2025 年末に MCP も Agentic AI Foundation に寄付し、ChatGPT/Cursor/Copilot はすべてサポートに参加しましたが、明らかに拡大を続けています)。しかしエージェントを使用して開発者向けのプログラムを作成するこのシナリオでは、ツール設計の振り子は実際に CLI に向かって振れています。私なりにまとめた5つの理由です。
理由 1: コンテキスト税を逃れることはできません (デフォルトの実装では)
ほとんどの MCP ホストのデフォルト動作では、各ツールの説明、パラメーター スキーマ、および戻り形式の説明のプロンプト/ツール コンテキストがサーバーにプリロードされます。この会話が電話をかけるかどうかに関係なく。 Anthropic 自身のドキュメントには、「MCP ツールの定義がコンテキストのかなりの部分を占める可能性がある」と記載されています。 Playwrightの関係者も、MCPモードのトークンがより高価であることを直接認めています。
この状況は最近解決され始めました: Anthropic の立ち上げMCPツール検索、ツール定義がしきい値を超えると、遅延読み込みに変更されます。 GitHub MCP と Playwright MCP にも「コンテキストの削減」フラグが追加されました。ただし、これらは新しい機能であり、デフォルトではなく、すべてのホストでサポートされているわけではありません。
したがって、実際にはまだ次のとおりです。何かを書き込む前に、いくつかの MCP サーバーを停止し、税金として数千から数万のトークンを支払います。。 CLI ツールはまったく必要ありません -gh pr list事前にモデルに伝える必要はありませんghそれは何ですか？トレーニング データにはすでに数千万件のデータが含まれています。ghたとえば、モデルは単独で使用できます。
(大まかな個人的な経験: 中規模の MCP サーバーには約 5 ～ 10,000 のトークンがあり、5 つが積み重なると 30 ～ 50,000 になります。これは感覚に基づく桁違いであり、テストされた事実ではありません。参考として使用してください。)
理由 2: CLI 出力は傍受およびフィルタリングされる可能性があり、MCP を返すのは困難です
CLI からの戻り値はプレーン テキスト ストリームであり、フィルターと連結できます。
rtk git log
rtk gh pr view 123
gh pr list --json title,state | jq '.[] | select(.state=="OPEN")'RTK が「クロード コードによりトークンが 50% 節約される」という効果を達成できる理由は、エージェント コンテキストに入る前に CLI 出力をインターセプト、圧縮、再配置できるためです。
MCP は後処理ができないわけではありません。MCP 仕様では、テキスト、画像、音声、リソース リンク、その他のコンテンツ ブロックが許可されており、クロード コードでは次の機能も提供されます。PostToolUseフックは MCP ツールの結果を傍受できます。ただし、これらはホスト/サーバーのそれぞれの拡張ポイントであり、Unix パイプのような「一行ずつ自然に使用できる」という組み合わせ性はありません。私は、5000 行がコンテキストに直接注がれた Playwright のスナップショットを見たことがあります。その時はフックが先に阻止してくれることを祈るしかありませんでした。
理由 3: CLI は「シェルを実行できるエージェント」で真に移植可能です
同じものgh pr create, Claude Code、Codex CLI、Aider、Cursor エージェント、Cline、Continue.dev で実行できます。指示は変更されず、エージェントは誰でも置き換えることができます。
(私がよく犯す間違い: ChatGPT のコード インタープリター/データ分析は、シェルではなく Python サンドボックスです。ghそこでは実行できないため、このルールは「実際にシェルを実行できるエージェント」にのみ適用されます。 ）
MCP 構成は比較的断片化されています。 Claude Code は確かに Claude デスクトップ設定をインポートできます。カーソル CLI とエディターは MCP 設定を共有します。 Cline CLI と VS Code 拡張機能も共有します。しかしさまざまなベンダー間でそれでも、それぞれ 1 つずつ実行する必要があります。構成ファイルの場所、インストール パス、環境変数はすべて異なります。 MCP 全体を Claude / Cursor / Cline / Codex 間で移動するには、ほとんど一度再設定する必要があります。 「最も困難な問題を解決するために最強のエージェントを使用したい」人にとって、CLI は依然として移植性の高いツール言語です。
理由 4: デバッグの透明性
CLI に問題がある場合、コマンド ライン、標準出力、標準エラー出力、終了コードなどの完全なトレースが端末ログに残されていることがわかります。
MCP に問題がある場合、多くの場合、ツールが空の配列を返すかどうか、両方を比較する必要があります。サーバーがそれをキャッチできなかったためでしょうか、それともスキーマ解析エラーがあるのでしょうか、あるいはホスト側でタイムアウトが発生したためでしょうか?通常は、ホスト コンソールを確認し、サーバー側のログを追加する必要があります。
エージェント自律が深夜に 8 時間実行されると、この透明性のギャップはさらに拡大します。CLI 障害モードでは、エージェントは自身で stderr を読み取ることで修正できます。 MCP 障害モードでは、多くの場合、エージェントは疲れるまで諦めるか再試行することしかできません。
理由 5: 遅延
多くの MCP サーバーは stdio サブプログラムまたはコンテナーです。最初の呼び出しごとにハンドシェイクと初期化が必要です。リモート MCP にも HTTP/SSE が必要です。ウォーム シェル、またはコンパイルされたバイナリ (RTK など) を使用すると、「クイック ルックアップ」リクエストが桁違いに高速になります。
エージェントにとって、このギャップはスピードだけでなく、「軽くチェックしても良いかどうか」というコストの基準でもあり、安価なツールがより頻繁に使用され、高価なツールは徐々に敬遠されます。
では、MCPはどこでまだ生きているのでしょうか？ （実際にはかなりの数です）
私は MCP を完全に外すことを主張しているわけではありません。次のようなシナリオでも依然として強力です。
ステートフルセッション: Playwright MCP はブラウザのプロセスを維持し、Cookie とページの状態を保持します。 CLI でやり直すのは意味がありません。
構造化データ: ナレッジ グラフとアクセシビリティ スナップショットのツリー状データは、プレーン テキストよりも MCP コンテンツ ブロックに適しています。
厳格な権限の境界: エージェントが実行できることを明示的に制御する必要がある場合 (任意のシェルの実行を許可しない)、MCP のツール ホワイトリストはオープン Bash よりも安全です。
リソースとプロンプト: MCP 仕様では、リソース (エージェントが読み取り可能なコンテンツ) とプロンプト (事前設定された要求テンプレート) が提供されますが、CLI には対応する構造がありません。
リモートOAuthサービス: Linear、Notion、Atlassian などの正式な OAuth プロセスを備えた SaaS の場合、MCP コネクタは、エージェントにトークンの更新を独自に処理させるよりもはるかにクリーンです。
プロジェクト以外のユーザー向けのディスカバリ: Google カレンダーをクロード デスクトップに接続し、ボタンを押して使用します。プログラミングをしないユーザーにとって、MCP の GUI/メニューは CLI よりもはるかに使いやすいです。
その中間のデザインもあります: Anthropic のエージェントのスキル。スキルには MCP の検出機能もあります (リストはシステム プロンプトで確認できます) が、スキルのコンテンツは実行中に遅延ロードされます。結局のところ、作業の実行には依然として Bash/CLI が使用されており、これは「MCP の検出の利便性 + CLI の実行コスト」に相当します。
実践的なアドバイス: 引き算から始める
現在のクロード コード (または他のエージェント) で多数の MCP がハングしている場合は、次のことをお勧めします。
どの MCP が実際に使用されているか、どの MCP がコンテキストを書き込んでいるだけかを確認します。
「月に 1 回未満しか使用しない」MCP をすべて取り外します。
CLI で置き換えられるもの (GitHub、アーカイブ、grep、git) については、代わりに CLI + フィルター (RTK など) を使用します。
残るもの: ブラウザー、構造化データ、権限境界、リモート OAuth、組織共有統合。
私自身の設定は、約 12 MCP から 4 MCP に減りました。エージェントはより賢く、応答が速くなり、コンテキストは長時間のセッションに耐えることができます。
結論：振り子は真ん中に振れた
これは「MCP が失敗する」という話ではなく、ツール設計の振り子が「オールイン MCP」から中間に戻るようなものです。結局のところ、LLM は数メガバイトのシェル コマンドを読み込んだ種です。端末を与えると、Unix エコシステム全体を使用できるようになります。 MCP を与えると、インストールしたいくつかのツールを使用できます。つまり、それぞれに適切なシナリオを持つ 2 つの抽象化レベルがあります。
コーディング エージェントの将来は次のようになります。CLIはメインコースとして使用され、スキルはインデックスとして使用され、MCPは特別な目的として使用されます。 「すべてが MCP である」という流行は、より合理的な位置に後退しました。