MCP 退潮：为什么一线工程团队开始转向 CLI-First 的 Agent 工具模式 – codigger

2024 年末に MCP (Model Context Protocol) が誕生したとき、それは「AI 世界の USB-C」と呼ばれました。ツール呼び出しを統一し、実装を一度にどこでも利用できるようにし、N×M 適応の悪夢を終わらせる – これらの約束は実際に問題点を突いています。

しかし、2026 年までに、最前線のエンジニアリングチームからの実践的なフィードバックは別の状況を示しています。それは、「使用するかしないか」ではなく、使用すればするほど損失が大きくなるということです。

まず、クリックベイト関係者によって消費されてきた事実を明確にする必要があります。大手メーカーは MCP を放棄したわけではなく、MCP を再構築しているのです。実際に何が起こったかというと、ツールアクセス層の焦点が変更されました。プロトコルのカプセル化に戻るコマンドの実行。この反発は、エージェントエンジニアリングの最も見落とされている層を暴露するため、真剣に解体するに値します。コンテキストは、無料のコンテナではなく、希少なリソースです。

1. 誰も慎重に計算したくないトークンアカウント

MCP の設計上の前提条件は次のとおりです。構造化スキーマを使用してツールの機能を明確に記述することによってのみ、モデルを正しく呼び出すことができます。この仮定は、ツールが 3 つまたは 5 つしかない場合には当てはまりますが、ツールが 50 個になると崩れます。

原因はMCPの読み込み方法に偏りがあるためです集中化: クライアントが起動すると、すべてのツールのメタ情報 (名前、説明、パラメータースキーマ、例) が一度にコンテキストに挿入される傾向があります。 GitHub の MCP サーバーを例にとると、44 のツールの説明テキストは合計約 64,000 文字になり、これは約 14,000 のトークンに相当します。単一の負荷はこの大きさです。 3 台のサーバーがインストールされているため、会話が始まる前にコンテキストバジェットの一部が消費されてしまいます。

控えめに見積もっても、1 つのツールあたり 500 ～ 1000 トークンです。 50 ツールの固定コストは 25,000 ～ 50,000 トークンです。さらに悪いことに、これらのトークンは「効果的な推論」ではなく、「自己テスト」であるということです。このモデルでは、今回は使用しないインターフェイスの説明を大量に読んだ後でのみ、最初のドライバーを手に入れることができます。業界ではそう言われています トークンインフレ: コストはツールの数に応じて直線的に増加しますが、収益はそれに応じて増加しません。

CLI はまったく逆のことを考えます。数十行の命令を使用して bash ツールをモデルに公開するだけです。特定のコマンドはモデルによってオンサイトで書き込まれます。共通コマンド (ls、grep、git、find、curl) は長い間ウェイトに組み込まれており、不人気なオーダーがチェックされるようになりました。 --help または man それでおしまい。

違いはロードのタイミングにあります。

MCP：起動後にファミリーバケット全体をロードします
CLI：今すぐチェックして、すぐに使って、使い切ってから出発

このモデルではドキュメントを読むにもトークンがかかりますが、開始時にマニュアル全体を暗記するのではなく、必要なセクションのみを読み取ります。

2. 5次元の非対称性

コストは別として、エンジニアリングの違いは比較する価値があります。

シート

寸法	MCP の一般的な慣行	CLI ファーストの一般的なプラクティス
コンテキストコスト	起動時にスキーマをバッチでロードする	オンデマンドで読む `--help` / `man` / リードミー
デバッグ経験	JSON‑RPC 多層カプセル化、エラーはネストされたオブジェクトに埋もれます	終了コード + stderr + ログ、問題が直接明らかになります
認証	サービスごとにOAuth/キー配布を行う	OS インフラストラクチャの再利用: SSH、環境変数、ローカル設定
コンビネーション能力	結合ポイントは JSON フィールド間にあり、グルーコードが必要です	結合点は stdout → stdin であり、パイプは直接接続されています
バージョン管理	クライアントとサーバーのバージョンは結合されており、SDK のアップグレードは脆弱です。	独立したバイナリ、semver は明確なセマンティクスを持っています

それについてポイントごとに話しましょう。

デバッグ
MCP コールリンクは、典型的な「抽象漏洩」シナリオです。AI Client → MCP Client → Transport → MCP Server → 目标程序子进程。何らかのレベルでエラーが発生した場合、ユーザーに公開されるのは単なる文であることがよくあります。 Internal Error。パラメータのタイプが正しく記述されていない場合、それを見つけるには 3 層のログが必要になる場合があります。

CLI の失敗パターンは非常に単純です。command not found それはふりをしているのではなく、Permission denied 許可ですよ、Connection refused 機能しなかったサービスです。そして、それをローカルで再現することができます。ターミナルで同じコマンドを入力することで、AI 層で問題を切り分けることができます。

認証
これはしばしば過小評価されます。エージェントは 2 つのシステムを接続しません。多くの場合、開発環境全体、さらには企業のツールセット全体を接続する必要があります。各アクセスポイントが OAuth とキーローテーションをやり直す必要がある場合、それはオペレーティングシステムが数十年にわたって蓄積してきた認証インフラストラクチャをすべて破棄し、最初から再構築することに相当します。

CLI の世界には、すでに非常に成熟した一連のものがあるため、再発明する人はいません。~/.ssh/config、~/.gitconfig、~/.aws/credentials、GITHUB_TOKEN このタイプの環境変数規則。これらはエレガントではありませんが、監査およびローテーションのツールチェーンが付属しており、何十年も実行されています。

組み合わせ
これが最も本質的な違いです。 Unix の哲学の核心は「多数のコマンド」ではなく、「1 つのコマンドが 1 つのことを実行し、それがパイプでつながれる」ということです。

git log --pretty=oneline | grep "hotfix" | awk '{print $2}' | sort | uniq -c | sort -nr

ログからホットフィックスのコミットを取得し、作成者ごとにカウントするコマンド。

MCP はこの種の自由スプライシングを実行できません。各サーバーはアイランドであり、その出力はまずホストによって JSON に解析されてから、次のサーバーに送信される必要があります。組み合わせポイントから流れに退化する分野すべてのスプライシングは接着コードを記述するようなものです。

エージェントの本質は、多くの小さな機能を長いチェーンに結びつけることであり、低摩擦の直列接続の前提は、出力が自然に入力になることができるということであるため、構成可能性はまさにエージェント時代において最も価値のある機能です。

3. 1本のパイプラインと5往復

効率性について抽象的に語ると歪みが生じやすくなります。特定のタスクを見てみましょう。バッチで透かしを入れて、横長の写真をディレクトリにアップロードします。

MCP モードでは、この要件は「ディレクトリの読み取り → 画像情報の確認 → 水平バージョンのフィルタリング → ウォーターマークの追加 → アップロード」の 5 つのステップに分割されます。各ステップは、ツールの呼び出し、モデルの思考、および待機の往復に対応します。

CLI モードでは、パイプラインとループで十分です。

for f in $(find ./photos -name '*.jpg' \
         -exec identify -format '%w %h %i\n' {} \; \
         | awk '$1>$2 {print $3}'); do
convert "$f" -gravity south -pointsize 36 -annotate +0+20 '© me' "wm_$(basename "$f")"
scp "wm_$(basename "$f")" user@server:/uploads/
done

find ImageMagick のトラバースを担当 identify お見積もりサイズ、awk アスペクト比フィルタリングを実行し、convert 透かしを追加し、scp アップロード。 5 つのツールはそれぞれその役割を果たしますが、いずれもこのニーズに特化して開発されたものではありません。

要件が変更されたら (垂直バージョンへの変更、透かしの位置の変更など)、いくつかのパラメーターを変更してスペルを書き直すだけです。 MCP システムでは、これは通常、ツールの書き換え、スキーマの再登録、プロトコルの再実行を意味します。

この背景には、次の 2 つの設計哲学の違いがあります。

MCP: プロトコルの抽象化を追求し、均一性のために透明性を犠牲にする
CLI: セマンティックな透明性を主張し、可視性、予測可能性、構成可能性のために「構造化」を犠牲にする

4. CLI の弱点はまさに MCP の堀です

ここだけの話だと楽観的すぎる結論が出てしまいます。 CLI には、解決する必要がある 2 つの構造上の問題があります。

1つ目は射出面。
モデルがシェルコマンドを自由に生成できるようにすることは、次と同等です。 rm -rf 可能性は確率分布に与えられます。引用符とエスケープは非常に簡単に覆され、エラーが隠されることがよくあります。コマンドの実行は成功しますが、結果は正しくありません。エンタープライズクラウド環境は、「モデルを意識した」セキュリティモデルを受け入れることができません。

2つ目は権限の境界。
MCP の価値は、「設計内でのみ操作を許可する」ことにあります。つまり、サーバーが公開するものはすべて、モデルのみが実行できます。パラメータは JSON であり、境界はスキーマによって明確に定義されており、認証と監査はサーバー側で集中できます。これは、コンプライアンスのシナリオには必ず必要です。

したがって、実際の実装形式は置換ではなく、階層化です。

┌──────────────────────────────────────┐
│ Agent / Coding Assistant             │
├──────────────────────────────────────┤
│ CLI 工具层（git, gh, kubectl, aws）  │ ← 强化
├──────────────────────────────────────┤
│ MCP Server 层（选择性保留）          │ ← 精简
├──────────────────────────────────────┤
│ 原生 API / SDK                       │
└──────────────────────────────────────┘

MCP を保持するシナリオは通常、ネットワーク境界を越えたリモート呼び出し、強い型制約を必要とする複数ステップのワークフロー、サードパーティエコシステムの公式統合などです。
CLI を使用するシナリオは通常、ローカル開発ツールチェーン、高頻度で低遅延の操作、および細かいエラー処理と再試行が必要なタスクです。

一文で言うと：CLI は個人およびイントラネットに属し、MCP は企業とクラウドの境界に残ります。

5. なぜ今なのか: 3 つの前提が同時に確立される

興味深い疑問は、「CLI の方が優れている」ということではなく、「なぜこれが 2026 年にのみ起こるのか」ということです。 CLI は 50 年間変わらず、常に存在しています。変わるのは他の 3 つの前提条件です。

モデルの機能は「文書の読み取り」の限界を超えています
初期の頃、私はスキーマを好み、そのサブテキストは「モデルはあまりにも愚かなので、標準的な答えを与える必要がある」でした。モデルがそれ自体を読み取れる場合 --helpマニュアルページを読んだり、README を読んだり、試行錯誤を通じて出力構造を理解したりしても、ツールを厳格な JSON スキーマに変換する利点は大幅に低下します。暗記する必要がある取扱説明書ではなく、探索するための入り口を提供するだけで十分です。
コンテキストウィンドウは安くならず、むしろ高価になっています
ウィンドウが数百万に拡大したとしても、「詰め込み」は依然として悪い戦略です。無関係なコンテキストにより注意が薄れ、遅延とコストが増加します。ツールの説明は、再利用頻度が高く限界価値が低い典型的なコンテンツであるため、永続的に使用するべきではありません。
エージェントの実行形式が「質疑応答」から「作業」に変わりました
質疑応答のシナリオでは、さらに数百個のトークンがあっても問題ありません。作業シナリオでは、1 つのタスクが数十のツール呼び出しをトリガーする可能性があり、コストと遅延は桁違いに増大します。これが、レイテンシーデータが非常に驚異的である理由です。チームが MCP から CLI に移行した後、ツール呼び出しのレイテンシーは平均 230 ミリ秒から 45 ミリ秒に低下しました。この差は主に、ツール自体ではなく、JSON‑RPC シリアル化とリンク転送によるものです。

6. ツールを作成している場合: CLI を製品として設計する

この変化がツール開発者に与える影響は非常に具体的です。CLI は API です。

判断基準はたったの3つ。

ユーザーはすでに CLI を使用してツールを使用していますか?
出力マシンは解析可能ですか?
エラーメッセージは、エージェントが自動的に修復できるほど明確ですか?

3 つすべてが「はい」です。多くの場合、適切に設計された CLI が MCP サーバーよりも優先されます。

✅ 良い点: 出力はインターフェースです

$ mytool list --format=json --quiet
{"items":[{"id":1,"name":"foo"}],"total":1}

❌ 悪い点: 人間に優しい、機械による災害

$ mytool list
Here are your items:
Item #1: foo (created 2 days ago)

いくつかの具体的な提案:

供給 --json / --format 人間が判読できるデフォルトを維持しながら構造化された出力
バンドル --help これは文書として書かれており、エージェントの最初のエントリポイントであり、人々が一目見るためのメモではありません。
出力を安定させてください。見栄えを良くするためだけに絵文字、カラーコード、または動的プログレスバーを追加しないでください。これらを追加すると、解析が直接クラッシュする原因になります。
終了コードのセマンティクスを正しく理解します。ゼロ以外は失敗を示す必要があり、エラーを隠すために 0 を使用しないでください。
デバッグエクスペリエンスを製品の機能として扱います。エンジニアリング時間のほとんどはトラブルシューティングに費やされます。-v / --trace 経験が定着率を直接決定します

アプリ開発者にとって、実用的な戦略は次のとおりです。 CLI が優先され、MCP がすべてを処理します：

async function safeExec(cmd: string[], args: string[]) {
  const r = await execa(cmd, args, { reject: false });
  if (r.exitCode === 0) return r.stdout;
  // CLI 失败时回退到结构化通道，或交由模型读 stderr 重试
  return mcpFallback(cmd, args, r.stderr);
}

同時に、自由に生成されたコマンドにはホワイトリストとサンドボックスの制約が課されます。CLI の柔軟性は、モデルの自己規律に依存するのではなく、外部のガードレールによってバランスを取る必要があります。

結論: 複雑さは消えることはなく、移動するだけです

MCP と CLI の間の議論は、本質的には、AI 時代における RPC とローカルコマンド実行の間の古代の議論の新たなラウンドです。カプセル化は決して複雑さを排除することではなく、複雑さを「ユーザー操作」から「プロトコル設計、スキーマ管理、コンテキスト課金、認証統合、リンクのデバッグ」に移すことです。引っ越しをした後、煩雑さは減らないどころか、むしろ請求額が重くなっていることに気づくこともよくあります。

MCP のビジョンには何の問題もありません。それは対処しますガバナンス質問; CLI の勝利仕事質問。モデルが十分に賢くなった場合、最良のツール戦略は、もはやそのモデルの世界を記述することではなく、人間がすでにインターフェース、認証、結合方法、デバッグ方法を構築している世界にモデルを置き、モデルが自ら学習できるようにすることです。

一文だけ残す場合:

ツールをシンプルにして、AI にシンプルなツールの使い方を学習させます。

Source link