MCPを捨てますか？ CLI がエージェントのデフォルトのツール層になりつつある理由

過去 1 年間、エージェントツールチェーンに関する議論は、次の 1 つの問題にますます集中してきました。

MCP (モデルコンテキストプロトコル) はツールの呼び出しを簡単にしますか? それとも、もともと単純だったものを複雑にしますか?

CLI は、ほとんどの日常的な開発タスクにとって、より実用的なデフォルトになりつつあります。

コストの違いは「経験の問題」ではなく、桁違いの問題です

MCP に対する実際の最大のプレッシャーはトークンのオーバーヘッドです。

一般的なシナリオでは、MCP は実際にタスクを実行する前に、多数のツールスキーマをロードする必要があります。 GitHub MCP サーバーを例に挙げると、初期化で数万のトークンが消費される可能性があります。長いタスクの場合、これはコンテキストバジェットを直接圧迫します。

コミュニティのベンチマークは、同じ結論を繰り返し示しています。

これは「遅い」というギャップではなく、むしろ API 料金、レイテンシー、安定性の問題にまで拡大します。

見落とされがちな事実は、トレーニングの分布です。

LLM は、トレーニング中にコマンド、出力、エラーレポート、スクリプト、マニュアルページなどの大量の端末テキストを確認しました。言い換えれば、CLI 対話モードは本質的にモデルの「母国語入力」に近いものになります。

それどころか、MCP の JSON-RPC とツールスキーマは、ここ 2 年間で大規模に登場したばかりの新しいパラダイムです。モデルは確かに学習できますが、親しみやすさと圧縮効率は通常、CLI などの歴史的コーパスほど良くありません。

これは、その理由を何度も説明するものでもあります。

MCP がセキュリティを実現できないわけではありませんが、エコシステムはまだ初期段階にあります。

現在の一般的な懸念事項は次のとおりです。

もちろん、CLI にもセキュリティの問題 (インジェクション、不正アクセス、パスのリスク) がありますが、そのプロセスモデル、権限の境界、監査リンクは数十年にわたるエンジニアリングの実践によって検証されています。本番環境では、この「予測可能性」が重要です。

私はMCPを放棄すべきではないと思います。

より合理的な位置付けは次のとおりです。

一般に、ハイブリッドアーキテクチャ: CLI + MCP Gateway とも呼ばれます。

多数のリモートシステムに接続し、統合された権限管理とコンプライアンス監査を実行する必要がある場合、MCP には依然として明白な価値があります。しかし、「エージェントが開発タスクを迅速に完了できるようにする」という点では、多くの場合、CLI ファーストの方が現在のモデルの機能の境界に沿っています。

今日のエンジニアリングの現実では、CLI はエージェントの母国語に似ています。 MCP は、唯一の実行プロトコルではなく、接続プロトコルとして適しています。