翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# MCP ホスティング戦略
使用可能なツールを MCP サーバーに抽象化すると、エージェント開発と使用可能なツールが切り離されます。これにより、MCP サーバーをホストする場所と、それらのサーバー内でツールがどのように整理されるかという課題が生じます。
## ホスティングアプローチ
MCP サーバーをホストするには、エンドユーザーマシンでローカルに実行する、リモートでホストする、または MCP ゲートウェイを介してホストする 3 つのオプションがあります。各オプションには利点とトレードオフがあります。
### ローカルホスティング
ローカルホスティングは、標準入出力ストリームで JSON-RPC を使用してサーバーと通信するエージェントとともに、ローカルマシンのサブプロセスとして MCP サーバーを実行します。このアプローチでは、クライアントとサーバー間の認証は必要ありません。ツールは、ローカルアプリケーションやファイルとやり取りしたり、ローカルに保存されている認証情報を使用したり、ユーザーのローカルマシンのネットワークアクセスを継承したりできます。これは最もシンプルなホスティングパターンであり、いくつかの利点があります。
多くのお客様は、ローカルサーバーを使用して MCP の使用を開始します。これにより、エンジニアはローカル環境からさまざまな問題を迅速に反復して解決できます。エンジニアのコーディングアシスタントが使用する Git リポジトリに接続する MCP サーバーを考えてみましょう。MCP サーバーをローカルに保持することは、エンジニアの一意の認証情報を使用してリポジトリにアクセスでき、リモート MCP サーバーにネットワーク呼び出しを追加しないため、非常に理にかなっています。次の図は、IDE のコーディングエージェントで使用されているローカルでホストされた MCP サーバーを示しています。
これらのタイプのデプロイでは、MCP サーバーの開発方法と分散方法を考慮する必要があります。ほとんどのお客様は、エンドユーザーがサーバーを登録およびダウンロードできる MCP レジストリを開発しています。これは、ユーザーが特定の機能を検索し、ニーズに適した MCP サーバーを見つけることができるコンテナレジストリと非常によく似ています。
公式 MCP レジストリなどの[パブリック MCP レジストリ](https://registry.modelcontextprotocol.io/)があり、プライベートにホストされたレジストリがあります。通常、組織は MCP レジストリ戦略を、オープンソースソフトウェア配布、コンテナレジストリ、内部パッケージ管理に関する既存のポリシーと整合させます。セキュリティスキャン、承認ワークフロー、コンプライアンス要件などの要因を考慮する必要があります。
ただし、ローカルホスティングには、組織が考慮すべき運用上の課題があります。まず、エンドユーザーは MCP サーバーを個別に検出、ダウンロード、設定する必要があります。これにより、ローカルで使用する個々の MCP サーバーの使用を開始するための複雑さが増す可能性があります。次に、MCP サーバーのライフサイクルを制御できません。つまり、ユーザーはセキュリティの脆弱性や機能不足により、古いバージョンをローカルで引き続き実行できます。これにより、コンプライアンス要件を満たすことが複雑になる可能性があります。[Kiro](https://aws.amazon.com/documentation-overview/kiro/) などの一部の IDEs や CLI ツールを使用すると、組織は[使用可能な MCP ツールを管理および制御できるため](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/mcp-governance.html)、チーム間の一貫性とセキュリティが確保されます。
### リモートホスティング
2 番目のオプションは、HTTP または HTTPS 経由でアクセスされるリモート MCP サーバーをホストすることです。これにより、ネットワーク接続されたクライアントにアクセスできます。リモートホスティングを使用すると、MCP リソースと機能へのアクセスを一元的に制御し、認証と認可を実装し、MCP サーバーロジックのバージョニングと更新を制御できます。リモートホスティングでは、エンドユーザーがエージェントで使用する MCP サーバーを検出できるように、引き続き MCP レジストリを使用する必要があります。次の図は、リモートホスティングのアプローチを示しています。
エージェント開発の観点から見ると、MCP サーバーがローカルでもリモートでもエクスペリエンスは似ています。最も重要な変更は、エージェントの MCP サーバーへのアクセスとサーバーの外部リソースへのアクセスの両方を含む、認証と認可の実装です。リモート MCP サーバーの実装は、マルチテナントアクセスと特権管理を検討するために慎重に計画する必要があります。[MCP ガバナンス戦略](mcp-governance-strategy.md)の章には、認証と認可に関する考慮事項に関する詳細情報が含まれています。
### MCP ゲートウェイ
最後のオプションは MCP ゲートウェイを使用することです。MCP ゲートウェイは、MCP クライアントとサーバー間の一元化されたプロキシとして機能し、登録された MCP サーバーへのアクセスをオーケストレーションします。ゲートウェイがない場合、各エージェントは使用するすべてのリモート MCP サーバーを登録する必要があります。ゲートウェイを使用すると、エージェントは認証、認可、ルーティング、プロトコル変換を管理する単一のエンドポイントに接続できます。新しい MCP サーバーとツールは動的に追加でき、エージェントはすぐに使用できるようになります。次の図は、MCP ゲートウェイのアプローチを示しています。
[Docker MCP Gateway](https://docs.docker.com/ai/mcp-catalog-and-toolkit/mcp-gateway/) などの一部のゲートウェイソリューションも MCP サーバーのライフサイクルを管理し、必要に応じてサーバーをオンデマンドで起動します。[Amazon Bedrock AgentCore ](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html)Gateway などの MCP ゲートウェイは、[ネイティブセマンティック検索機能](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-using-mcp-semantic-search.html)を提供することでツール検出の管理にも役立ちます。これにより、エージェントは 1 つのエンドポイントで MCP クライアントに接続でき、コンテキストウィンドウの使用を最適化できます。その結果、MCP ツールを効果的に選択して使用できるシンプルなエージェントになります。ただし、リモート MCP サーバーアプローチと同様のアイデンティティ関連の課題があります。
## MCP サーバーをホストするためのベストプラクティス
+ ホスティングオプションのスペクトルは、すべてに適合する 1 つのサイズではありません。現在の MCP サーバーの使用の多くはローカルです。
+ リモート MCP サーバーの使用を開始する際の主な考慮事項は、MCP サーバーに対する一貫した認証と認可、および MCP サーバーがダウンストリームリソースに対する認証と認可を実行する方法です。
+ MCP ゲートウェイは、複数のリモート MCP サーバーをホストするための接続と認証、認可を簡素化します。また、該当するツールを検索してコンテキストウィンドウ管理を改善する機能も提供します。