Lilith Lilith.
編集イラスト: 開発者エージェントが依然としてMCPを必要とする理由:Simon Willisonの反論
Lilithのイラスト · 編集リミックス

Simon Willisonは、Model Context Protocol(MCP)を不必要な遠回りとみなすHacker Newsでの最近の議論に反論しました。批判者たちの前提は単純です。Claude Code、Codex、Meta Museなどの完全なターミナルエージェントをすでに実行している場合、それらはすでにファイルシステムとローカルツールへのアクセスを持っています。したがって、MCPのような中間レイヤーは、モデルの能力に対する人為的なボトルネックのように見えます。

生のアクセスがより良い統合を意味しない理由

議論で見落とされている点は、純粋な能力の枠を超えています。Willisonは、MCPの現在の価値は、エージェントがファイルを読み取れるかどうかではないと指摘しています。それは、システムコンテキスト全体に対する白紙委任状をエージェントに渡すことなく、特定のデータ(内部データベースやサードパーティのAPIなど)を標準化され、分離され、監査可能な方法でエージェントに公開することにあります。開発者にとって、これは構造化されたインターフェースと、モデルが理解してくれることを期待してリポジトリ全体をプロンプトに投げ込むことの違いです。

コンテキストの分離がモデルの役割を変える

この違いは、ローカルマシンを超えてエージェントを展開するチームにとって重要です。無制限のアクセス権を持つターミナルエージェントは、ローカルでの迅速な反復作業には最適ですが、詳細なアクセス制御を必要とするパイプラインや本番環境には移行できません。MCPは契約として機能します。エージェントは利用可能なツールとデータを正確に把握しており、システムはエージェントが何に触れているかを正確に把握しています。

生のアクセスの限界が実践で顕著になる

このレイヤーを削除するということは、不透明な統合へと後退することを意味します。エージェントはすべてを見るかもしれませんが、チームはモデルが見るべきものと見るべきでないものを区別する能力を失います。プロトコルがなければ、制御はプロンプトによるディレクトリの禁止に縮小され、これはセキュリティパッチであり、システム的な解決策ではありません。

企業での採用が議論の決着をつける

MCPが生き残るための決定的な要因は、ローカルのハッカーの熱意ではなく、より厳しいセキュリティとガバナンスの要件に直面しているチームでの採用です。既存のプラットフォームやデータソースへの統合が、カスタムWebhookから標準化されたMCPサーバーへと移行すれば、このプロトコルは基本的なビルディングブロックとしての役割を確固たるものにするでしょう。

Lilithの判定

アクセスに関する議論は的を外しています。本番環境の現実は、エージェントが暴走して会社全体を閲覧し始めたときに、誰が監査ログの鍵を握るかという点に尽きます。

外部リンクは最後に置いています。まずここで簡潔に解説 — 他人のサイトを探し回る必要はありません。

元の記事 ↗