2024年の12月に、私たちはAnthropicと共同で、AIエージェントでツールを実行するためのまったく新しい仕様(当時)であるモデルコンテキストプロトコル(MCP)についてのブログを公開しました。それ以来、Agentic AI を使用してツールを構築、共有、実行したいという開発者の意欲が爆発的に高まっています。新しいMCPクライアントが出現し、GoogleやOpenAIなどの大手企業がこの標準にコミットしているのを目の当たりにしてきました。しかし、ほぼすぐに、初期の成長の痛みが、実際にMCPツールを構築して使用することになると摩擦につながりました。現在、私たちは大きな困難に直面しています。
MCPの問題点
- ランタイム:
- MCPサーバーを起動して実行することは、開発者にとって頭痛の種です。MCP サーバーの標準ランタイムは、特定のバージョンの Python または NodeJS に依存しており、ツールを組み合わせるということは、MCP サーバーが必要とする可能性のある追加の依存関係に加えて、それらのバージョンを管理することを意味します。
- セキュリティ:
- LLM がホスト システム上でソフトウェアを実行するための直接アクセスを許可することは、愛好家の環境以外の開発者には受け入れられません。幻覚や誤った出力が発生した場合、重大な損害を与える可能性があります。
- ユーザーは、機密データをプレーンテキストの json ファイルで構成するように求められます。MCP設定ファイルには、エージェントがあなたに代わって行動するために必要なすべてのデータが含まれていますが、同様に、悪意のある人物がアカウントを悪用するために必要なすべてのものを一元化します。
- 検出
- ツールはそこにありますが、最高のMCPサーバーを見つけるのに適した場所は1つではありません。マーケットプレイスが出現し始めていますが、開発者は依然として自分たちで優れたツールのソースを探す必要があります。
- MCPのユーザーエクスペリエンスの後半では、LLMを圧倒するほどの十分なサーバーとツールが大量に用意され、誤ったツールが使用され、結果が悪化する可能性があります。LLM がジョブに適したツールを持っている場合、LLM はより効率的に実行できます。LLMが間違ったツールを手に入れたり、決定できないツールが多すぎると、幻覚が急増し、評価が急落します。
- 信頼:
- ツールが開発者に代わって LLM によって実行される場合、MCP サーバーの発行元を信頼することが重要です。現在のMCP出版社の状況はゴールドラッシュのように見えるため、信頼できない著者からのサプライチェーン攻撃に対して脆弱です。
MCP ランタイムとしての Docker
Dockerは、ツールが実行される環境を安定させるための実証済みのランタイムです。複数の Node または Python インストールを管理する代わりに、Docker 化された MCP サーバーを使用すると、Docker Engine を使用しているすべてのユーザーが MCP サーバーを実行できます。
Docker は、望ましくない LLM の動作がホスト構成を損なわないように、ツールにサンドボックス化された分離を提供します。たとえば、LLM は、MCP コンテナが明示的にバインドされていない限り、ホスト・ファイルシステムにアクセスできません。
MCP ゲートウェイ
LLMが自律的に機能するためには、自分でツールを見つけて実行できる必要があります。これは、これらすべての MCP サーバーを使用してもほぼ不可能です。新しいツールが追加されるたびに、設定ファイルを更新し、MCPクライアントを更新する必要があります。現在の回避策は、新しい MCP サーバーを構成する MCP サーバーを開発することですが、これも再読み込みが必要です。はるかに優れたアプローチは、単に 1 つの MCP サーバー (Docker) を使用することです。この MCP サーバーは、コンテナ化されたツールの動的セットへのゲートウェイとして機能します。しかし、ツールはどのようにして動的になるのでしょうか?
MCPカタログ
1つのMCPサーバー内の動的なツールセットは、ユーザーが構成を変更せずにMCPツールを追加または削除するためにどこかに行くことができることを意味します。これは、Docker Desktop のシンプルな UI を使用して、MCP ゲートウェイが提供できるツールのリストを維持することで実現されます。ユーザーは、ゲートウェイMCPサーバーに「接続」することで、MCPクライアントを構成し、数百のDocker化されたサーバーを使用できます。
Docker Hubと同様に、Docker MCP Catalogは、開発者向けのツールを見つけるための信頼できる一元化されたハブを提供します。また、ツールの作成者にとっては、そのハブが重要な配布チャネルとなり、新しいユーザーにリーチし、Claude、Cursor、OpenAI、VS Code などのプラットフォームとの互換性を確保する方法となります。
ドッカーシークレット
最後に、アクセストークンやその他のシークレットをコンテナに安全に渡すために、Docker Desktopの一部としてシークレットを管理する機能を開発しました。設定すると、シークレットは MCP のコンテナプロセスにのみ公開されます。つまり 、実行中のコンテナを検査してもシークレットは表示されません。シークレットを必要とするツールに厳密にスコープを設定できるようにすることで、MCP設定ファイルを残したままビッグデータ侵害のリスクを冒すことがなくなります。