翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

MCP ガバナンス戦略

MCP が組織に提供するもう 1 つの重要な機能は、一元化されたガバナンスのサポートです。MCP ガバナンス戦略は、MCP サーバーとそれらがアクセスするリソースの両方に対する認証と認可に対処する必要があります。また、ダウンストリームリソースを保護するためのレート制限、ツールの使用状況とパフォーマンスをモニタリングするための運用メトリクス、MCP サーバーのデプロイとディストリビューションの管理にも対処する必要があります。

認証と認可

認証および認可戦略の最も重要な部分の 1 つは、MCP サーバーからのダウンストリームリソースアクセスを管理することです。ユーザーがエージェントを呼び出すと、認証と認可が実行され、ユーザーにエージェントを呼び出すアクセス許可が付与されます。次に、エージェントは MCP サーバーの特定のツールの呼び出しを調整します。ツールごとにアクセスを許可する方法を決定する必要があります。

1 つのオプションはmachine-to-machine認可であり、ユーザーの同意や操作は必要ありません。たとえば、時間ベースのエージェント呼び出しでは、MCP サーバーを使用してアプリケーションからログを収集し、分析します。このシナリオでは、エージェントは指定されたデータへのアクセスを事前に許可されています。2 番目のオプションは、ユーザーが委任したアクセスです。ユーザーは、ユーザー固有のデータとリソースへのアクセスに同意したことになります。

次の表は、認証と認可のパターンを示しています。

ユーザー委任アクセスには慎重な実装が必要であり、セキュリティチームとともに開発する必要があります。エージェントは、LLM が選択したツールと、追加の認可が必要かどうかを評価できる必要があります。MCP ツールには、認証と認可の要件とアクセストークンを取得する場所を示す説明が含まれている必要があります。クライアントアプリケーションは中間認証リクエストをサポートしている必要があり、MCP クライアントはツール呼び出しごとに取得した認証情報をエージェントに返す必要があります。

MCP ツールには常に外部機能にアクセスするための独自のトークンがあり、アクセスがログに記録され、監査されていることを確認する必要があります。ユーザー認証情報は、エージェントシステムを介して伝播しないでください。たとえば、MCP サーバーは、エージェントの呼び出しに使用されたデータにアクセスするために同じトークンを使用しないでください。ダウンストリーム呼び出しでは、明示的にスコープ設定され、目的別に生成されたトークンを使用する必要があります。これにより、追加のガードレールを提供して、アクションに代わって意図しないデータアクセスを防ぐことができます。また、幻覚が意図しない結果を生成するのを防ぐのにも役立ちます。完全な管理者権限を持つユーザーが、本番稼働前のデータベースのクローン作成をエージェントに依頼するとします。そのためには、ユーザーに必要なのは READと アクセスCREATE許可のみです。LLM がハルシネーションし、このリクエストの一部として古いデータベースをクリーンアップする必要があると考えるとします。ユーザーの認証情報を再利用する場合、ユーザーの元の認証情報には DELETE アクセス許可があるため、成功する可能性があります。代わりに、MCP サーバーが READと アクセスCREATE許可のみを持つリクエストに意図的にスコープダウンされたトークンを使用する場合、本番データベースを削除しようとすると失敗します。

Amazon Bedrock AgentCore Identity を使用して、これらのパターンを実装できます。MCP サーバーによってホストされるツールを一覧表示および呼び出すアクセス許可が、MCP サーバーが公開する外部機能に対するアクセス許可を意味するかどうかについて、意図的に選択していることを確認してください。MCP サーバーからリソースへ、およびユーザーに戻るこの ID フローは、使用する認証および認可サービスのタイプによって異なります。MCP サーバーの大規模な処理方法を決定する必要があります。

認証および認可パターンを設計するときは、アクセスするツールごとに異なるアクセストークンを取得するトークン分離メカニズムを実装します。ツールとサーバー間でトークンを再利用しないでください。AgentCore Identity は、このトークン分離機能を提供します。ワークロードトークン (machine-to-machine認証用) とユーザートークン (ユーザー委任アクセス用) の両方を自動的に管理して、適切な分離を確保し、アクセス許可のエスカレーションを防ぎます。これは、リモート MCP サーバーまたは MCP ゲートウェイを組み込む場合に特に重要です。

MCP 認証と認可のベストプラクティス

負荷の制御

他の分散システムと同様に、MCP サーバーフリートの負荷を制御する方法を検討する必要があります。まず、MCP サーバーにレート制限を実装するかどうかと、制限を実装する場所を検討します。レート制限を実装しない場合は、ダウンストリームリソースによって実行されるレート制限を渡します。多くのシステムは、ユーザーやアカウント ID などのリクエスト属性に基づいて制限をレートすることを選択します。ダウンストリームサービスに送信されるリクエストが同じ属性を実行し、複数のユーザーが別のユーザーによって駆動される負荷の影響を受けないようにします。

レート制限を実装することを選択した場合、推奨されるアプローチは MCP サーバーレベルでプライマリレート制限を実装することです。バックエンドサービスはセカンダリ保護を提供し、エージェントはレート制限のフィードバックに基づいて動作を適応させます。レート制限が MCP サーバーごとか、ツールごとかを検討します。MCP サーバーあたりのレート制限は、マルチテナント環境で MCP サーバーフリートとサービスを保護するのに役立ちます。ただし、これは非常に粗い場合があります。ツールごとのレート制限は、それ自体が十分にレート制限されない可能性のある圧倒的なダウンストリームリソースを防ぐように設計されています。ツールが複数の APIsを呼び出す場合は、それらの APIs で許可される最低レートに合わせてレート制限を設定する必要があります。

HTTP ヘッダーにレート制限情報を渡すことは、ユーザーや自動システムにとって独自のリクエストレートと再試行戦略の管理に役立つメトリクスでもあります。例えば、次の例に示すように、これらのヘッダーを MCP サーバーからエージェントに送り返すことができます。

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 45
X-RateLimit-Reset: 1640995200

さらに、単一の顧客がレート制限を超えていないが、負荷がシステムのパフォーマンスに影響を与えている場合に、サービス全体を保護するために負荷分散を検討してください。

負荷を制御するためのベストプラクティス

運用メトリクス

MCP 実装でキャプチャする主要なメトリクスは、提供するカスタマーエクスペリエンスに焦点を当てる必要があります。これらのメトリクスには、通常、トークンの使用、ツール選択の精度、エージェントに登録されているツールの数、ツールのレイテンシーが含まれます。たとえば、各ツールによって返される出力トークンをモニタリングすると、ツールがコンテキストウィンドウの使用のしきい値を超えたときにアラームを設定できます。ツールがそのしきい値を超えた場合は、ツールの動作を確認することをお勧めします。これは MCP ツール設計戦略にも関連しています。ツール選択精度メトリクスは、エージェントが特定のタスクに適したツールをどの程度適切に選択しているかを示し、実行速度と成功率はパフォーマンスのボトルネックと信頼性の問題を強調します。

例えば、ツール選択とツール使用の精度メトリクスを評価するために、 AWS チームは回帰テスト用のゴールデンデータセットを作成しました。データセットは、ユーザークエリの履歴 API 呼び出しログの LLMs を使用して合成的に生成されました。事前定義されたツール選択メトリクスとツール使用メトリクス (ツール選択精度、ツールパラメータ精度、マルチターン関数呼び出し精度など) を使用すると、 AWS チームは AI エージェントの能力を客観的に評価して、適切なツールを正しく識別し、パラメータに正確な値を入力し、会話のターン全体で一貫したツール呼び出しシーケンスを維持できます。

エージェントに登録されているツールの数に関するメトリクスを測定すると、潜在的なコンテキストウィンドウ管理の課題や、MCP サーバーによって提供される利用可能なツールの変更を特定するのに役立ちます。MCP サーバーとツールのユーザーエクスペリエンスを示す運用メトリクスを定期的に確認する必要があります。