Model Context Protocol: 過剰か、それともエージェント的ワークフローの未来か？

Model Context Protocol (MCP) は、そのアーキテクチャの必要性をめぐって開発者の間で議論を巻き起こしています。その核心において、このプロトコルは AI エージェントがデータやツールとどのように対話するかを標準化することを目指しています。しかし、批判的な人々は、コマンドの発見や権限のスコープ設定といった、このプロトコルが提供する機能は、すでに Command Line Interface (CLI) によって数十年にわたり解決されてきたものだと主張しています。

この緊張関係は、AI 時代における根本的な問いを浮き彫りにしています。新しいプロセスのレイヤーを導入することで、ローカル環境に不必要な複雑さを加えているのか、それとも MCP は CLI では提供できない重要な抽象化を提供しているのか？

CLI の主張: なぜ別のプロセスが必要なのか？

多くの経験豊富な開発者にとって、Model Context Protocol は冗長に思えます。ローカルマシン上で MCP プロセスが増殖することに対する主な反対意見には、以下が含まれます。

• Permission Scoping: CLI コマンドはすでに特定の権限でスコープを設定でき、ツールがシステム上で何ができるかを制限できます。
• Discoverability: 標準的な --help フラグや man ページは、ユーザー（および潜在的にはエージェント）がコマンドとその必要な引数を発見するための堅牢な方法を提供します。
• Resource Overhead: 単一の PC 上で数十、あるいは数百の個別の MCP プロセスを実行することは、不必要なオーバーヘッドを生み出し、潜在的なシステム不安定性の表面積を増加させます。

この観点からは、MCP は「大きな利益をもたらさずに、余分な複雑さと可動部品を増やしている」と見なされています。

ローカルプロセスを超えて: サーバーサイド MCP

「100 個のプロセス」という懸念に対する一つの反論は、MCP がローカルでの実行を必要としないことです。このプロトコルは柔軟に設計されており、サーバーサイドでのホスティングが可能です。

コミュニティメンバーが指摘しているように、Atlassian のような企業はすでにこのアプローチを実装しています。MCP をサーバーサイドでホストし、Dynamic Client Registration や OAuth を活用することで、組織はユーザーのローカルマシンに負担をかけることなく、ツールへの安全で認証されたアクセスを提供できます。これにより、 oauth2-proxy や Nginx を使用してオープンソースの MCP を Single Sign-On (SSO) レイヤーでラップし、エンタープライズ向けに準備を整えることが可能になります。

状態管理と監査可能性

CLI はコマンドを実行して結果を受け取るには優れていますが、複雑で多段階のエージェント的ワークフローに必要な状態管理に対処できていません。

AI エージェントが 50 ステップにわたるタスクを実行しているとき、単純な CLI 呼び出しでは、コンテキストを簡単に「ロールバック」したり、特定の時点での失敗から回復したりすることはできません。ここで、より構造化されたプロトコルへの移行が不可欠になります。エージェントのメモリのための Git のようなブランチ作成やスナップショットの必要性が、これらのプロセスを監査可能かつ回復可能にするための重要な要件として浮上しており、「100 個のプロセス」を負債から、構造化され管理可能な記録システムへと変貌させています。

結論

将来が数百のローカル MCP プロセスを伴うものになるのか、それとも中央集権的なサーバーサイドアーキテクチャになるのかに関わらず、Model Context Protocol は AI のためのツール統合に関する私たちの考え方の転換を表しています。CLI は人間の開発者にとって強力なツールであり続けますが、AI エージェントの要件（特に状態、リモート認証、および標準化された発見について）は、単純なスクリプト実行を超えて、真に自律的なエージェント的ワークフローへと進むためには、より形式的なプロトコルが必要であることを示唆しています。