AIエージェントは、研究デモから実際のエンタープライズアプリケーションへと急速に移行しており、大規模言語モデル(LLM)を企業データやサービスと接続しています。一般的なアプローチは、ツールやプラグインを使用してLLMがコンテキストを取得したりアクションを実行したりできるようにすることですが、これらを単なる「美化されたAPI呼び出し」として片付ける人もいます。実際には、AIをビジネスシステムと安全に統合することははるかに複雑です。ここでModel Context Protocol(MCP)が登場し、エンタープライズ規模のデプロイメントにはOpenID Connect(OIDC)アイデンティティを備えた堅牢なプロキシアーキテクチャが不可欠である理由があります。
\n\ngraph TB\n User[ユーザー] --> |対話| AIAgent[AIエージェント]\n AIAgent --> |MCPリクエスト| Proxy[APIゲートウェイ/プロキシ]\n Proxy --> |認証| OIDC[アイデンティティプロバイダー/OIDC]\n Proxy --> |ルーティング| Tools[MCPツール/サーバー]\n Tools --> |アクセス| Backend[バックエンドシステム]\n \n subgraph \"セキュリティ境界\"\n Proxy\n OIDC\n end\n \n classDef security fill:#f96,stroke:#333,stroke-width:2px;\n class Proxy,OIDC security;\n上の図は、安全なMCP実装の高レベルアーキテクチャを示しています。このアーキテクチャの中核は、AIエージェントとMCPツールの間の中央セキュリティ制御ポイントとしてAPIゲートウェイ/プロキシを配置することです。プロキシは、OIDCをサポートするアイデンティティプロバイダーと連携して、認証、認可、アクセス制御を実施するセキュリティ境界を作成します。これにより、AIエージェントからのすべてのMCPリクエストが、実際のMCPツールに到達する前に適切に認証および認可されることが保証され、MCPツールは順番にさまざまなバックエンドシステムにアクセスします。
\n\nMCPは、AIアシスタントが外部データソースやツールと対話するための一貫した方法を提供するオープン標準(元々はAnthropicによって導入)です。各システムに対する個別の統合の代わりに、MCPは普遍的なコネクタのように機能し、AIモデルが標準化されたJSON-RPCインターフェースを介してコンテキストを取得したりタスクを実行したりできるようにします。重要なことに、MCPはセキュリティを念頭に置いて構築されました—デフォルトではAIに何も公開されず、明示的に許可したものにのみアクセスできます。しかし実際には、多くのツールとユーザーにわたってその「許可リスト」原則を確保するには、慎重なインフラストラクチャが必要です。本番環境レベルのAPIゲートウェイ(プロキシ)は、AIエージェント(MCPクライアント)とツールまたはデータソース(MCPサーバー)の間のゲートキーパーとして機能し、認証、認可、ルーティングルールを実施できます。
\n\nソリューションに入る前に、Envoyについて簡単に説明します: MCPゲートウェイのリファレンス実装としてEnvoy Proxyを使用する提案が活発に行われています。EnvoyのリッチなL7ルーティングと拡張性により、強力な候補となっており、まもなくファーストクラスのMCPサポートが含まれる可能性があります。とはいえ、ここで説明するパターンはプロキシに依存しません—同様の機能を提供する最新のHTTPリバースプロキシまたはAPIゲートウェイ(Envoy、NGINX、HAProxy、Kongなど)を使用できます。目標は、Envoy設定の詳細ではなく、MCPの安全なアーキテクチャを概説することです。
\n\n一見すると、MCPを介してAIツールを使用することは、Web APIを呼び出すのと同じくらい簡単に見えるかもしれません。基本的なデモでは、LLMエージェントがRESTエンドポイントにアクセスし、JSONを取得して、それで終わりです。しかし、実際のエンタープライズシナリオでは、舞台裏でもっと多くのことが起こっています:
\n\ngraph LR\n subgraph \"シンプルなAPI呼び出し\"\n A[クライアント] -->|リクエスト| B[API]\n B -->|レスポンス| A\n end\n \n subgraph \"エンタープライズMCPの現実\"\n C[ユーザー] -->|対話| D[AIエージェント]\n D -->|アイデンティティ付きMCPリクエスト| E[APIゲートウェイ]\n E -->|トークン検証| F[アイデンティティプロバイダー]\n E -->|リクエストルーティング| G[ツールレジストリ]\n E -->|認可されたリクエスト| H[MCPツール]\n H -->|ユーザーコンテキスト付きクエリ| I[バックエンドシステム]\n I -->|データ| H\n H -->|レスポンス| E\n E -->|フィルタリングされたレスポンス| D\n D -->|結果| C\n \n J[セキュリティ監視] -..->|監査| E\n end\n \n classDef security fill:#f96,stroke:#333,stroke-width:2px;\n class E,F,G,J security;\nこの図は、シンプルなAPI呼び出しとエンタープライズMCP実装の複雑な現実を対比しています。シンプルなケースでは、クライアントがAPIに直接リクエストを行い、レスポンスを受け取ります。しかし、エンタープライズMCPの現実では、フローははるかに複雑です:
\n\nこのプロセス全体を通じて、セキュリティ監視システムがゲートウェイレベルでのやり取りを監査します。この包括的なフローにより、ユーザーのアイデンティティ、権限、セキュリティポリシーがすべてのステップで実施され、シンプルなAPI呼び出しが伴うものをはるかに超えています。
\n\n要するに、エンタープライズは、AIツール統合を他の本番サービス統合と同じ厳密さで扱う必要があります—それ以上ではないにしても。適切なゲートウェイレイヤーは、中央制御ポイントとして機能することで、これらの懸念に対処するのに役立ちます。各AIエージェントまたはツールに信頼をハードコーディングする代わりに、プロキシは組織全体のセキュリティポリシーを課します。このアプローチは、「単にAPIを呼び出す」という考え方を超えて、すべてのMCP呼び出しが認証、認可、監視、監査される構造化されたモデルに移行します。
\n\nMCPを大規模に展開する際に発生するいくつかの特定のセキュリティ課題と、それらが重要である理由を見てみましょう:
\n\ngraph TD\n A[コンテキストポイズニング] --> |緩和| B[コンテンツフィルタリング]\n A --> |緩和| C[ツール検証]\n \n D[アイデンティティ伝播] --> |解決| E[トークンベース認証]\n D --> |解決| F[委任チェーン]\n \n G[動的ツールプロビジョニング] --> |管理| H[ツールレジストリ]\n G --> |管理| I[承認ワークフロー]\n G --> |管理| J[バージョン追跡]\n \n K[リモートMCP変更] --> |制御| L[プロキシガバナンス]\n \n subgraph \"プロキシセキュリティ制御\"\n B\n C\n E\n F\n H\n I\n J\n L\n end\n \n classDef challenge fill:#f66,stroke:#333,stroke-width:2px;\n classDef solution fill:#6f6,stroke:#333,stroke-width:2px;\n \n class A,D,G,K challenge;\n class B,C,E,F,H,I,J,L solution;\nこの図は、MCPワークフローにおける主要なセキュリティ課題(赤で表示)を、プロキシセキュリティ制御内で実装できる対応するソリューション(緑で表示)にマッピングしています。図は次のことを示しています:
\n\nプロキシレイヤー内でこれらの制御を実装することにより、組織は各ツールまたはエージェントに対して個別に解決しようとするのではなく、これらのセキュリティ課題を一元化された一貫した方法で対処できます。
\n\nsequenceDiagram\n participant User as ユーザー\n participant AIAgent as AIエージェント\n participant Proxy as APIゲートウェイ\n participant IdP as アイデンティティプロバイダー\n participant Tool as MCPツール\n participant Backend as バックエンドシステム\n \n User->>IdP: 1. 認証(ユーザー名/パスワード)\n IdP->>User: 2. OIDCトークン発行\n User->>AIAgent: 3. AIと対話(トークン添付)\n AIAgent->>Proxy: 4. トークン付きMCPリクエスト\n Proxy->>IdP: 5. トークン検証\n IdP->>Proxy: 6. トークン有効、クレーム/スコープ含む\n \n alt トークン有効で必要な権限あり\n Proxy->>Tool: 7. ユーザーコンテキスト付きリクエスト転送\n Tool->>Backend: 8. 委任認証でクエリ\n Backend->>Tool: 9. データ返却(ユーザー権限でフィルタリング)\n Tool->>Proxy: 10. 結果返却\n Proxy->>AIAgent: 11. 認可されたレスポンス返却\n AIAgent->>User: 12. 結果提示\n else トークン無効または権限不足\n Proxy->>AIAgent: 7. リクエスト拒否(401/403)\n AIAgent->>User: 8. アクセス拒否報告\n end\nこのシーケンス図は、OIDCを使用したMCPシステムにおける認証と認可のフローを示しています。プロセスは、ユーザーがアイデンティティプロバイダーに認証し、OIDCトークンを受け取ることから始まります。このトークンは、ユーザーのAIエージェントとのやり取りに添付されます。エージェントがMCPリクエストを行うと、このトークンが含まれ、APIゲートウェイがアイデンティティプロバイダーでそれを検証します。
\n\nトークンが有効で必要な権限(クレーム/スコープ)を含んでいる場合、リクエストはユーザーのコンテキストとともに適切なMCPツールに転送されます。ツールは委任認証を使用してバックエンドシステムにクエリを実行でき、返されるデータがユーザーの権限に従ってフィルタリングされることを保証します。結果はシステムを通じてユーザーに戻ります。
\n\nトークンが無効であるか、十分な権限がない場合、リクエストはゲートウェイレベルで適切なエラーコード(401 Unauthorizedまたは403 Forbidden)で拒否され、AIエージェントはこのアクセス拒否をユーザーに報告します。
\n\nこのフローにより、ユーザーのアイデンティティと権限が、機密データや操作への不正アクセスを防ぎながら、やり取りチェーン全体を通じて一貫して実施されることが保証されます。
\n\nsequenceDiagram\n participant Admin as 管理者\n participant Registry as ツールレジストリ\n participant Proxy as APIゲートウェイ\n participant Tool as 新しいMCPツール\n participant AIAgent as AIエージェント\n \n Admin->>Tool: 1. 新しいMCPツール開発\n Admin->>Registry: 2. ツール登録(メタデータ、エンドポイント、認証要件)\n Registry->>Registry: 3. ツール設定検証\n Registry->>Proxy: 4. ルーティング設定更新\n \n Note over Registry,Proxy: ツールは登録されたが、まだ承認されていない\n \n Admin->>Registry: 5. 特定のユーザーグループに対してツール承認\n Registry->>Proxy: 6. アクセスポリシー更新\n \n Note over AIAgent,Proxy: ツールは認可されたユーザーが利用可能になった\n \n AIAgent->>Proxy: 7. 利用可能なツールを発見\n Proxy->>AIAgent: 8. ユーザーに承認されたツールを返却\n AIAgent->>Proxy: 9. 新しいツールを呼び出し\n Proxy->>Tool: 10. 認可されている場合、リクエストをルーティング\nこのシーケンス図は、安全なMCP環境におけるツール登録と承認ワークフローを示しています。プロセスは、管理者が新しいMCPツールを開発し、メタデータ、エンドポイント、認証要件を提供してツールレジストリに登録することから始まります。レジストリはツール設定を検証し、APIゲートウェイのルーティング設定を更新します。
\n\nこの時点で、ツールは登録されていますが、まだ使用が承認されていません。管理者は特定のユーザーグループに対してツールを明示的に承認する必要があり、これによりAPIゲートウェイのアクセスポリシーの更新がトリガーされます。その後初めて、ツールが認可されたユーザーに利用可能になります。
\n\nAIエージェントがプロキシを通じて利用可能なツールを発見すると、現在のユーザーに対して承認されたツールに関する情報のみを受け取ります。エージェントが新しいツールを呼び出すと、プロキシはユーザーがそれにアクセスすることを認可されている場合にのみ、リクエストをツールにルーティングします。
\n\nこのワークフローにより、新しいツールが使用される前に適切な検証と承認を受けることが保証され、アクセスが認可されたユーザーのみに制限されます。また、ツールガバナンスプロセスを一元化し、安全な方法でMCPツールのライフサイクルを管理しやすくします。
\n\nこれらの課題を認識することで、セキュリティエンジニアとアーキテクトは問題が発生する前に防御を設計できます。次に、アイデンティティ対応プロキシがクリーンで一元化された方法でこれらの防御を提供する方法を見ていきます。
\n\nクラウドアーキテクチャで実証されている設計は、サービスの前にリバースプロキシ(しばしばAPIゲートウェイと呼ばれる)を配置することです。MCPベースのAIシステムも例外ではありません。AIエージェント(クライアント)とMCPサーバー(ツール/バックエンド)の間にインテリジェントなプロキシを導入することで、すべてのAIツールトラフィックが通過する制御されたファネルを作成します。このプロキシはレイヤー7(アプリケーション層)で動作できます。つまり、HTTPやJSONペイロードさえも理解し、きめ細かい制御を可能にします。以下では、このようなプロキシがMCPのセキュリティ保護において果たす主要な役割を概説します:
\n\ngraph TB\n subgraph \"クライアント側\"\n User[ユーザー]\n AIAgent[AIエージェント]\n User -->|対話| AIAgent\n end\n \n subgraph \"セキュリティレイヤー\"\n Proxy[APIゲートウェイ/プロキシ]\n Auth[認証]\n RBAC[認可/RBAC]\n Registry[ツールレジストリ]\n Audit[監査ログ]\n \n Proxy -->|使用| Auth\n Proxy -->|実施| RBAC\n Proxy -->|参照| Registry\n Proxy -->|生成| Audit\n end\n \n subgraph \"MCPツール\"\n Tool1[ドキュメント検索]\n Tool2[データベースクエリ]\n Tool3[ファイル操作]\n Tool4[外部API]\n end\n \n subgraph \"バックエンドシステム\"\n DB[(データベース)]\n Storage[ファイルストレージ]\n APIs[内部API]\n External[外部サービス]\n end\n \n AIAgent -->|MCPリクエスト| Proxy\n Proxy -->|ルーティング| Tool1\n Proxy -->|ルーティング| Tool2\n Proxy -->|ルーティング| Tool3\n Proxy -->|ルーティング| Tool4\n \n Tool1 -->|読み取り| DB\n Tool1 -->|読み取り| Storage\n Tool2 -->|クエリ| DB\n Tool3 -->|管理| Storage\n Tool4 -->|呼び出し| APIs\n Tool4 -->|呼び出し| External\n \n classDef security fill:#f96,stroke:#333,stroke-width:2px;\n class Proxy,Auth,RBAC,Registry,Audit security;\nこの図は、MCPのためのアイデンティティ対応プロキシパターンの詳細なビューを提供します。アーキテクチャは4つの主要なレイヤーに分かれています:
\n\nAIエージェントからのすべてのMCPリクエストはプロキシを通過する必要があり、プロキシはリクエストを認証し、RBACポリシーを実施し、ツールレジストリに問い合わせてルーティングを決定し、監査ログを生成します。プロキシは認可されたリクエストを適切なMCPツールにルーティングし、ツールは順番にバックエンドシステムと対話します。
\n\nこの一元化されたセキュリティアーキテクチャにより、使用されているツールやアクセスされているバックエンドシステムに関係なく、すべてのMCPインタラクションにわたってセキュリティポリシーの一貫した実施が保証されます。
\n\nシンプルなステートレスAPI呼び出しとは異なり、MCPセッションは長期間にわたり、ストリーミング(出力用のServer-Sent Eventsなど)を含む可能性があります。プロキシは、特定のセッションまたは会話に属するすべてのリクエストとレスポンスが一貫して処理されることを保証する必要があります。これはしばしばセッションアフィニティの実装を意味します—MCPサーバーの複数のインスタンスが実行されている場合、プロキシは特定のセッションのトラフィックを毎回同じインスタンスにルーティングします。これにより、たとえばツールAの状態(インメモリキャッシュ、コンテキストウィンドウなど)がリクエスト2がリクエスト1とは異なるインスタンスに行ったために失われるという問題を防ぎます。最新のプロキシは、HTTPヘッダーまたはルートを使用してセッション対応ロードバランシングを実行できます(たとえば、URLのセッションIDまたはクライアントIDを特定のバックエンドにマッピング)。さらに、プロキシはSSE接続を適切に処理できるため、ストリーミングレスポンスがネットワーク仲介者によって誤って壊されることはありません。セッションを再開または引き継ぐ必要がある場合、ゲートウェイはそれを調整できます(MCP用の今後のEnvoy機能で提案されているように)。要するに、プロキシはMCPのステートフルなやり取りの信頼性と一貫性を保証し、これはユーザーエクスペリエンスと正しいコンテキストの維持にとって重要です。
\n\nsequenceDiagram\n participant User as ユーザー\n participant AIAgent as AIエージェント\n participant Proxy as APIゲートウェイ\n participant Instance1 as ツールインスタンス1\n participant Instance2 as ツールインスタンス2\n \n User->>AIAgent: 会話開始\n AIAgent->>Proxy: MCPリクエスト1(session=abc123)\n \n Note over Proxy: セッションアフィニティルーティング\n \n Proxy->>Instance1: インスタンス1にルーティング\n Instance1->>Proxy: 状態付きレスポンス\n Proxy->>AIAgent: レスポンス返却\n \n User->>AIAgent: 会話継続\n AIAgent->>Proxy: MCPリクエスト2(session=abc123)\n \n Note over Proxy: 同じセッションIDは同じインスタンスにルーティング\n \n Proxy->>Instance1: インスタンス1にルーティング(状態保持)\n Instance1->>Proxy: 更新された状態付きレスポンス\n Proxy->>AIAgent: レスポンス返却\n \n Note over User,Instance2: セッションアフィニティがないと、リクエストがインスタンス2に行き、状態が失われる可能性がある\nこのシーケンス図は、MCP環境でセッションアフィニティがどのように機能するかを示しています。ユーザーがAIエージェントとの会話を開始すると、エージェントはセッション識別子(この場合は「abc123」)を含むMCPリクエストをAPIゲートウェイに送信します。ゲートウェイはこのセッションIDを使用して、リクエストを特定のツールインスタンス(インスタンス1)にルーティングします。
\n\nユーザーが会話を続けると、エージェントは同じセッションIDで別のMCPリクエストを行います。ゲートウェイがセッションアフィニティを実装しているため、このリクエストを同じインスタンス(インスタンス1)にルーティングし、前のやり取りからの状態を保持します。これにより、ユーザーに一貫性のある首尾一貫したエクスペリエンスが保証されます。
\n\nセッションアフィニティがないと、2番目のリクエストが別のインスタンス(インスタンス2)にルーティングされる可能性があり、最初のリクエストからの状態情報がありません。これにより、ツールが前のやり取りのコンテキストを持たないため、壊れたエクスペリエンスになります。
\n\nセッションアフィニティは、多くのAIインタラクションがステートフルでコンテキスト依存であるため、MCPにとって特に重要です。プロキシがこのセッションの一貫性を維持する能力は、よりシンプルなAPI統合アプローチに対する重要な利点です。
\n\nMCPゲートウェイに到達するすべてのリクエストは、有効なアイデンティティトークン—通常、OIDCを介してアイデンティティプロバイダーによって発行されたJSON Web Token(JWT)—を運ぶ必要があります。JWTを要求することで、プロキシはツール自体から認証をオフロードし、認証され認可された呼び出しのみが通過することを保証します。実際には、これはAIエージェント(またはエージェントとのユーザーのセッション)がOIDCトークン(たとえば、IDトークンまたはアクセストークン)を取得し、各MCPリクエストに添付する必要があることを意味します(多くの場合、Authorization: Bearer <token>のようなHTTPヘッダーで)。プロキシはこのトークンを検証し、署名とクレーム(発行者、オーディエンス、有効期限など)をチェックし、適切に認証されていないリクエストを拒否します。このようにして、MCPサーバーは匿名の呼び出しを見ることはありません—ゲートウェイがアイデンティティを検証したことを信頼します。
sequenceDiagram\n participant User as ユーザー\n participant App as AIアプリケーション\n participant IdP as アイデンティティプロバイダー\n participant Proxy as APIゲートウェイ\n participant Tool as MCPツール\n \n User->>App: AIアプリケーションにアクセス\n App->>IdP: ログインにリダイレクト\n User->>IdP: 認証\n IdP->>App: 認可コード\n App->>IdP: トークンのコード交換\n IdP->>App: IDトークン + アクセストークン\n \n Note over App: トークンを安全に保存\n \n User->>App: AIツールを使用してリクエスト\n App->>Proxy: アクセストークン付きMCPリクエスト\n \n Proxy->>Proxy: トークン検証(署名、有効期限、オーディエンス)\n Proxy->>Proxy: ユーザーアイデンティティと権限を抽出\n \n alt トークン有効\n Proxy->>Tool: ユーザーコンテキスト付きリクエスト転送\n Tool->>Proxy: レスポンス\n Proxy->>App: レスポンス返却\n App->>User: 結果表示\n else トークン無効\n Proxy->>App: 401 Unauthorized\n App->>User: セッション期限切れ、再度ログインしてください\n end\n \n Note over App,Proxy: トークンリフレッシュはバックグラウンドで発生\n App->>IdP: 必要に応じてトークンをリフレッシュ\n IdP->>App: 新しいアクセストークン\nこのシーケンス図は、MCP環境におけるOIDC認証フローを示しています。プロセスは、ユーザーがAIアプリケーションにアクセスすると開始され、アプリケーションは認証のためにアイデンティティプロバイダーにリダイレクトします。ユーザーが認証すると、アイデンティティプロバイダーは認可コードを発行し、アプリケーションはそれをIDトークンとアクセストークンと交換します。
\n\nアプリケーションはこれらのトークンを安全に保存し、AIエージェントを通じてMCPリクエストを行うときにアクセストークンを使用します。プロキシがリクエストを受信すると、署名、有効期限、オーディエンス、その他のクレームをチェックしてトークンを検証します。また、トークンからユーザーのアイデンティティと権限を抽出します。
\n\nトークンが有効な場合、プロキシはユーザーのコンテキストとともに適切なMCPツールにリクエストを転送します。ツールはリクエストを処理してレスポンスを返し、プロキシを通じてアプリケーションに、最終的にユーザーに流れます。
\n\nトークンが無効(期限切れ、改ざんなど)の場合、プロキシは401 Unauthorizedレスポンスを返し、アプリケーションはユーザーに再度ログインするよう促します。
\n\nバックグラウンドでは、アプリケーションはリフレッシュトークンを使用して、ユーザーに再認証を要求することなく、必要に応じて新しいアクセストークンを取得できます。これにより、セキュリティを維持しながらスムーズなユーザーエクスペリエンスが保証されます。
\n\nこのOIDC統合は、エンタープライズ環境で広く採用されている堅牢な認証メカニズムを提供し、既存のアイデンティティ管理システムとうまく統合されます。
\n\n上記の議論は人間のユーザーの認証に焦点を当てていますが、本番環境レベルのMCPデプロイメントでは、さらに2つのアクターを識別する必要があります:
\n\n私たちの関連記事「OpenID Connect for Agents(OIDC-A)1.0提案」({{ site.baseurl }}/2025/04/28/oidc-a-proposal/)は、OIDC Core 1.0をエージェントアイデンティティ、証明、委任チェーンのための豊富なクレームセットで拡張しています。実際には、これは次のことを意味します:
\n\nagent_type、agent_model、agent_instance_id、delegator_sub、delegation_chainなど)を含むIDトークンを取得します。このトークンは、すべてのMCPリクエストでユーザーのアクセストークンと一緒に移動します。agent_capabilities、agent_trust_level、agent_attestation)などのメタデータを宣伝する独自のOIDCアイデンティティを公開できます(または署名されたリソーストークンを発行されます)。OIDC-Aを採用すると、いくつかの利点があります:
\n\nemail:draft機能を宣伝するエージェントのみがMailツールを呼び出すことを許可)。agent_attestation)により、ゲートウェイはトラフィックをルーティングする前に、エージェントとツールの両方の整合性と出所を検証できます。この記事の残りの部分では、ゲートウェイによって検証される「トークン」に言及するときはいつでも、これがユーザーのトークン、エージェントのOIDC-Aトークン、および(オプションで)ツール/リソーストークンを含むと仮定してください—すべてが単一のポリシー決定ステップで評価されます。
\n\nこのパターンは、APIセキュリティで既に広く使用されています:「APIゲートウェイは、アプリケーション自体に負担をかけることなく、認証を安全かつ一貫して実装できます。」私たちのコンテキストでは、MCPプロキシはOIDC経由でエンタープライズSSO(Azure AD、Oktaなど)と統合して、ユーザーログインフローとトークン検証を処理する可能性があります。多くのゲートウェイはOIDCをネイティブにサポートし、必要に応じてユーザーログインのリダイレクトを開始し、結果のトークンをセッション継続のためにCookieに保存します。ヘッドレスエージェントシナリオ(AIがサーバー間でツールを呼び出している場合)では、トークンは帯域外でプロビジョニングされる可能性があります(たとえば、ユーザーがAIアプリにログインしたため、アプリがエージェントが使用するトークンを注入します)。いずれにせよ、ゲートウェイはトークンなし=アクセスなしを実施します。また、トークンクレームを役割またはスコープにマッピングして認可を実装することもできます(たとえば、「HR_read」スコープを持つユーザーのみが「HRデータベース」ツールを使用できます)。これは、MCPの安全な接続の設計目標と完全に一致します—MCPをOIDCおよびOIDC-Aと組み合わせることで、ツール使用のためのエンドツーエンドの認証されたチャネルが得られます。
\n\nsequenceDiagram\n participant User as ユーザー\n participant Agent as LLMエージェント(OIDC-A)\n participant Proxy as APIゲートウェイ\n participant Tool as MCPツール(OIDC-A)\n participant Backend as バックエンドシステム\n\n User->>Agent: 1. 対話(チャット、フォームなど)\n Agent->>Proxy: 2. MCPリクエスト\\nBearerユーザートークン + エージェントOIDC-Aトークン\n Proxy->>Proxy: 3. ユーザートークン(OIDC) & エージェントトークン(OIDC-A)を検証\n Proxy-->>Tool: 4. ツールのオプションの*リソーストークン*付きリクエスト転送\n Tool->>Backend: 5. 委任認証を使用してクエリ/アクション\n Backend-->>Tool: 6. データ/結果\n Tool-->>Proxy: 7. レスポンス(証明を含む可能性あり)\n Proxy-->>Agent: 8. 認可されたレスポンス\n Agent-->>User: 9. 結果提示\nプロキシの強力な利点は、URLだけでなく、リクエスト内のメタデータに基づいてルーティング決定を行えることです。MCPでは、リクエストとレスポンスはJSON-RPC形式であり、ツールメソッド名、パラメータ、さらにはツールアノテーションなどのフィールドが含まれます。アイデンティティ対応プロキシは、これらの詳細を検査し、ポリシールールを適用するように設定できます。たとえば、次のようなルールを設定できます:
\n\ngraph TD\n subgraph \"MCPリクエスト\"\n Request[JSON-RPCリクエスト]\n Method[ツールメソッド]\n Params[パラメータ]\n User[ユーザーアイデンティティ]\n end\n \n subgraph \"ポリシーエンジン\"\n Rules[ポリシールール]\n RBAC[ロールベースアクセス]\n Audit[監査ログ]\n Transform[レスポンス変換]\n end\n \n Request --> Method\n Request --> Params\n Request --> User\n \n Method --> Rules\n Params --> Rules\n User --> RBAC\n \n Rules --> Decision{許可/拒否}\n RBAC --> Decision\n \n Decision -->|許可| Forward[ツールに転送]\n Decision -->|拒否| Reject[リクエスト拒否]\n \n Forward --> Audit\n Reject --> Audit\n \n Forward --> Tool[MCPツール]\n Tool --> Response[ツールレスポンス]\n Response --> Transform\n Transform --> Filtered[フィルタリングされたレスポンス]\n \n classDef request fill:#bbf,stroke:#333,stroke-width:1px;\n classDef policy fill:#fbf,stroke:#333,stroke-width:1px;\n classDef action fill:#bfb,stroke:#333,stroke-width:1px;\n \n class Request,Method,Params,User request;\n class Rules,RBAC,Audit,Transform policy;\n class Decision,Forward,Reject,Filtered action;\nこの図は、MCPプロキシでツールメタデータフィルタリングとポリシー実施がどのように機能するかを示しています。プロセスは、ツールメソッド、パラメータ、ユーザーアイデンティティ情報を含むJSON-RPC形式のMCPリクエストから始まります。これらのコンポーネントが抽出され、ポリシーエンジンに供給されます。
\n\nポリシーエンジンは、ポリシールール、ロールベースアクセス制御(RBAC)、監査ログ、レスポンス変換コンポーネントで構成されています。ツールメソッドとパラメータはポリシールールに対して評価され、ユーザーアイデンティティはRBAC権限に対してチェックされます。
\n\nこれらの評価に基づいて、ポリシーエンジンは許可/拒否の決定を行います。リクエストが許可されている場合、MCPツールに転送されます。拒否されている場合は拒否されます。いずれの場合も、アクションは監査目的でログに記録されます。
\n\nリクエストが許可されてツールによって処理されると、レスポンスはクライアントに返される前に変換ステップを通過する可能性があります。この変換は、ユーザーが見るべきでない機密情報を削除するなど、セキュリティポリシーに基づいてレスポンスをフィルタリングまたは変更できます。
\n\nメタデータレベルでのこのきめ細かいポリシー実施により、シンプルなURLベースのルーティングをはるかに超える洗練されたセキュリティ制御が可能になります。たとえば:
\n\ndelete_fileで、ユーザーがIT管理者グループにいない場合、リクエストを拒否します。」execute_sqlツールを許可し、すべてのクエリをログに記録します。」これは、Webアプリケーションファイアウォール(WAF)またはAPIゲートウェイがコンテンツフィルタリングを実行することに類似していますが、AIツールの使用に合わせて調整されています。Envoy MCP提案では、これはMCPメッセージを解析し、それらにRBACフィルターを使用することに対応します。プロキシは本質的に各ツール呼び出しの意図を理解し、適切にゲートできます。また、必要に応じてデータを編集または変換することもできます—たとえば、ユーザーが見るべきでないレスポンスから特定のフィールドを削除したり、個人を特定できる情報をマスキングしたりします。これをゲートウェイで一元化することで、各ツールサービスでチェックを実装する必要がなくなります(一貫性がなかったり忘れられたりする可能性があります)。監査も別の利点です:プロキシは、ユーザーアイデンティティとパラメータとともにすべてのツール呼び出しをログに記録し、監視のためにSIEMシステムに供給できます。そうすれば、AIがいつか本来すべきでないことをした場合、どのツール呼び出しが関与し、誰がそれを促したかの明確な証跡があります。要するに、メタデータベースのフィルタリングは、プロキシをスマートなポリシー実施ポイントに変え、MCPの基本機能の上に安全層を追加します。
\n\nエンタープライズは常にサービスを進化させています—新しいバージョン、A/Bテスト、ステージング対本番デプロイメントなど。プロキシは、AIエージェントがこれらの変更を処理する方法を大幅に簡素化できます。AIがどのバージョンのツールを呼び出すかを知る必要がある代わりに、ゲートウェイはバージョン対応ルーティングを実装できます。たとえば、「ドキュメント検索」ツールのMCPエンドポイントはエージェントにとって同じままですが、プロキシはリクエストの90%をサービスのv1に、10%を新しいv2にルーティングする可能性があります(カナリアロールアウトの場合)。または、内部ユーザーを「ベータ」インスタンスにルーティングし、外部ユーザーを安定版にルーティングします。これは、リクエスト属性に一致させるか、ユーザーオーディエンスとツール識別子を含むルーティングルールを使用して行われます。
\n\ngraph TB\n AIAgent[AIエージェント] -->|MCPリクエスト| Proxy[APIゲートウェイ]\n \n Proxy -->|\"90%トラフィック\"| V1[ツールv1]\n Proxy -->|\"10%トラフィック\"| V2[ツールv2 - カナリア]\n \n Proxy -->|\"内部ユーザー\"| Beta[ベータバージョン]\n Proxy -->|\"外部ユーザー\"| Stable[安定バージョン]\n \n Proxy -->|\"小さいリクエスト\"| Standard[標準インスタンス]\n Proxy -->|\"大きいリクエスト\"| HighMem[高メモリインスタンス]\n \n Proxy -->|\"米国ユーザー\"| US[米国リージョン]\n Proxy -->|\"EUユーザー\"| EU[EUリージョン]\n \n classDef proxy fill:#f96,stroke:#333,stroke-width:2px;\n classDef version fill:#bbf,stroke:#333,stroke-width:1px;\n classDef audience fill:#bfb,stroke:#333,stroke-width:1px;\n classDef size fill:#fbf,stroke:#333,stroke-width:1px;\n classDef region fill:#ff9,stroke:#333,stroke-width:1px;\n \n class Proxy proxy;\n class V1,V2 version;\n class Beta,Stable audience;\n class Standard,HighMem size;\n class US,EU region;\nこの図は、APIゲートウェイがMCPリクエストに対して実装できるさまざまなルーティング戦略を示しています。ゲートウェイは複数の要因に基づいてトラフィックをルーティングできます:
\n\nAIエージェントはこれらのルーティング決定を認識する必要はありません。論理的なツール名にリクエストを行うだけで、ゲートウェイが適切なバックエンドへのルーティングの複雑さを処理します。この抽象化により、エージェントの実装が簡素化され、強力な運用機能が提供されます。
\n\n同様に、ルーティングはコンテキストを考慮できます—たとえば、ユーザーの場所がわかっている場合は、レイテンシを低くするために最も近い地域サーバーにリクエストを誘導したり、リクエストのサイズに応じて異なるバックエンドを選択したりします(おそらく非常に大きなファイル用の特別な高メモリインスタンス)。これらすべてはプロキシレベルで設定可能です。AIエージェントは論理的なツール名を呼び出すだけで、ゲートウェイが適切なバックエンドを見つけることを処理します。これにより、運用が容易になるだけでなく(AIのインターフェースを壊すことなくバックエンドツールをアップグレードできます)、セキュリティも向上します。テスト用に特定のバージョンを分離したり、実験的なツールが特定の条件下でのみアクセス可能であることを保証したりできます。トラフィックフローを制御することで、プロキシはマクロスケールで最小権限の原則を維持するのに役立ちます—AIは、現在のコンテキストに適したルートを介して、到達すべきバックエンドにのみ到達します。
\n\n主要なセキュリティパターンをカバーしたので、アイデンティティ対応プロキシを使用してMCPセキュリティを実装する実用的なアプローチを見てみましょう。このセクションでは、コンポーネント間の統合ポイントに焦点を当てて、安全なMCP環境をセットアップする手順を概説します。
\n\ngraph TB\n subgraph ImplementationSteps[\"実装手順\"]\n Step1[1. アイデンティティプロバイダーのセットアップ]\n Step2[2. APIゲートウェイの設定]\n Step3[3. ツールレジストリの実装]\n Step4[4. セキュリティポリシーの定義]\n Step5[5. AIエージェントの統合]\n Step6[6. 監視と監査]\n \n Step1 --> Step2\n Step2 --> Step3\n Step3 --> Step4\n Step4 --> Step5\n Step5 --> Step6\n end\n \n classDef step fill:#beb,stroke:#333,stroke-width:1px\n class Step1,Step2,Step3,Step4,Step5,Step6 step\nこの図は、プロキシを使用してMCPセキュリティを実装する6つの主要な手順を概説しています。プロセスは論理的な進行に従います:
\n\n各ステップは前のステップの上に構築され、包括的なセキュリティ実装を作成します。以下のセクションでは、各ステップを詳しく説明します。
\n\n最初のステップは、MCPセキュリティに必要なOIDCフローをサポートするようにアイデンティティプロバイダー(IdP)を設定することです。これには通常、次のことが含まれます:
\n\nIdPは、ユーザーを認証し、MCPリクエストを保護するために使用されるトークンを発行する責任があります。認可決定に必要な情報がトークンに含まれるように、適切なスコープとクレームを設定することが重要です。
\n\n次に、MCPプロキシとして機能するようにAPIゲートウェイを設定する必要があります。これには次のことが含まれます:
\n\nsequenceDiagram\n participant Admin as 管理者\n participant Gateway as APIゲートウェイ\n participant IdP as アイデンティティプロバイダー\n \n Admin->>Gateway: 1. OIDC統合を設定\n Gateway->>IdP: 2. OIDC検出ドキュメントを取得\n IdP->>Gateway: 3. エンドポイントとキーを返却\n \n Admin->>Gateway: 4. MCPルーティングルールをセットアップ\n Admin->>Gateway: 5. セキュリティポリシーを設定\n \n Note over Gateway: ゲートウェイはトークンを検証し、MCPトラフィックをルーティングする準備ができました\nこのシーケンス図は、MCPセキュリティのためにAPIゲートウェイを設定するプロセスを示しています。プロセスは、管理者がゲートウェイでOIDC統合を設定することから始まります。ゲートウェイはアイデンティティプロバイダーからOIDC検出ドキュメントを取得し、トークン検証に必要なエンドポイントとキーを返します。
\n\n次に、管理者はMCPルーティングルールをセットアップし、さまざまな基準に基づいてリクエストを異なるMCPツールに誘導する方法を定義します。管理者はまた、誰がどのツールにどのような条件でアクセスできるかを指定するセキュリティポリシーを設定します。
\n\nこれらの設定が完了すると、ゲートウェイは定義されたルールとポリシーに従ってトークンを検証し、MCPトラフィックをルーティングする準備ができています。このセットアッププロセスにより、ゲートウェイがすべてのMCPインタラクションの中央セキュリティ制御ポイントとして確立されます。
\n\n設定手順には次のものが含まれます:
\n\nゲートウェイは、トークンの検証、セキュリティポリシーの実施、MCPリクエストの適切なバックエンドへのルーティングを担当します。ゲートウェイがMCP JSON-RPC形式を処理し、ポリシー決定に必要な情報を抽出するように適切に設定されていることを確認することが重要です。
\n\nツールレジストリは、環境内のMCPツールのライフサイクルを管理するために不可欠です。これには次のことが含まれます:
\n\nツールレジストリは、利用可能なツールのリスト、そのエンドポイント、およびアクセス要件を維持する責任があります。また、ルーティングとポリシー実施のためにAPIゲートウェイに必要な情報を提供します。
\n\ngraph TB\n subgraph \"ツールレジストリ\"\n DB[(ツールデータベース)]\n API[レジストリAPI]\n UI[管理UI]\n \n UI -->|ツール管理| API\n API -->|CRUD操作| DB\n end\n \n subgraph \"統合ポイント\"\n Gateway[APIゲートウェイ]\n Agents[AIエージェント]\n \n API -->|ツール設定| Gateway\n API -->|利用可能なツール| Agents\n end\n \n subgraph \"ツールライフサイクル\"\n Register[登録]\n Approve[承認]\n Deploy[デプロイ]\n Monitor[監視]\n Retire[廃止]\n \n Register --> Approve\n Approve --> Deploy\n Deploy --> Monitor\n Monitor --> Retire\n end\n \n classDef registry fill:#bbf,stroke:#333,stroke-width:1px;\n classDef integration fill:#fbf,stroke:#333,stroke-width:1px;\n classDef lifecycle fill:#bfb,stroke:#333,stroke-width:1px;\n \n class DB,API,UI registry;\n class Gateway,Agents integration;\n class Register,Approve,Deploy,Monitor,Retire lifecycle;\nこの図は、MCP環境におけるツールレジストリのコンポーネントとライフサイクルを示しています。ツールレジストリは3つの主要なコンポーネントで構成されています:
\n\nツールレジストリは2つの主要なシステムと統合されます:\n- APIゲートウェイ:レジストリからツール設定を受け取り、ルーティングとポリシー決定に情報を提供します。\n- AIエージェント:ユーザー権限とツールステータスに基づいて、レジストリを通じて利用可能なツールを発見します。
\n\n図はまた、MCPツールのライフサイクルを示しています:\n1. 登録:新しいツールがメタデータとともにシステムに登録されます。\n2. 承認:ツールがレビューを受け、特定のユーザーグループによる使用が承認されます。\n3. デプロイ:ツールが本番環境で利用可能になります。\n4. 監視:ツールの使用とパフォーマンスが監視されます。\n5. 廃止:不要になったツールはシステムから廃止されます。
\n\nこのツール管理への包括的なアプローチにより、すべてのMCPツールがライフサイクル全体を通じて適切に検証、デプロイ、監視され、セキュリティリスクと運用上の問題が軽減されます。
\n\nセキュリティポリシーは、MCPツールへのアクセスを管理するルールです。これには次のことが含まれます:
\n\nセキュリティポリシーは、ユーザーのアイデンティティとアクセスされているツールに基づいて、APIゲートウェイによって実施されます。ポリシーが包括的で、組織のセキュリティ要件と整合していることを確認することが重要です。
\n\n最後に、AIエージェントを安全なMCP環境と統合する必要があります。これには次のことが含まれます:
\n\nAIエージェントは、必要なトークンを取得し、MCPリクエストに含める責任があります。また、認証と認可エラーを適切に処理し、ユーザーに適切なフィードバックを提供する必要があります。
\n\nsequenceDiagram\n participant User as ユーザー\n participant Agent as AIエージェント\n participant App as アプリケーション\n participant IdP as アイデンティティプロバイダー\n participant Gateway as APIゲートウェイ\n participant Tool as MCPツール\n \n User->>App: AIアプリケーションにアクセス\n App->>IdP: ユーザーを認証\n IdP->>App: トークン発行\n \n User->>Agent: AI機能を使用してリクエスト\n Agent->>App: MCP用のトークンをリクエスト\n App->>Agent: トークンを提供\n \n Agent->>Gateway: トークン付きMCPリクエスト\n Gateway->>Gateway: トークンを検証してポリシーを適用\n Gateway->>Tool: 認可されたリクエストを転送\n Tool->>Gateway: レスポンス\n Gateway->>Agent: レスポンス返却\n Agent->>User: 結果提示\n \n Note over App,Gateway: トークンリフレッシュサイクル\n App->>IdP: 必要に応じてトークンをリフレッシュ\n IdP->>App: 新しいアクセストークン\nこのシーケンス図は、AIエージェントと安全なMCP環境との統合を示しています。プロセスは、ユーザーがAIアプリケーションにアクセスすると開始され、アプリケーションはアイデンティティプロバイダーでユーザーを認証し、トークンを受け取ります。
\n\nユーザーがAI機能を必要とするリクエストを行うと、AIエージェントはアプリケーションにトークンをリクエストし、アプリケーションはそれを提供します。エージェントは、APIゲートウェイへのMCPリクエストにこのトークンを含めます。
\n\nゲートウェイはトークンを検証し、セキュリティポリシーを適用して、リクエストを許可すべきかどうかを判断します。認可されている場合、リクエストは適切なMCPツールに転送され、処理してレスポンスを返します。このレスポンスはゲートウェイを通じてエージェントに、最終的にユーザーに流れます。
\n\nバックグラウンドでは、アプリケーションがトークンリフレッシュサイクルを処理し、必要に応じてアイデンティティプロバイダーに新しいアクセストークンをリクエストします。これにより、ユーザーが頻繁に再認証する必要なく、継続的な操作が保証されます。
\n\nこの統合アプローチにより、AIエージェントがプロキシアーキテクチャによって確立されたセキュリティフレームワーク内で動作し、すべてのリクエストが適切に認証および認可されることが保証されます。
\n\nアイデンティティ対応プロキシを使用して安全なMCPアーキテクチャを実装することで、「美化されたAPI呼び出し」をはるかに超えて、AIエージェントとビジネスシステム間の堅牢なエンタープライズグレードの統合に移行します。このアプローチは、MCPデプロイメントの主要なセキュリティ課題に対処します:
\n\nプロキシベースのアーキテクチャは、セキュリティポリシーを実施し、ツールアクセスを管理し、AIエージェントアクティビティを監視するための一元化された制御ポイントを提供します。また、バックエンドサービスの複雑さを抽象化し、AIエージェントに一貫したインターフェースを提供することで、運用を簡素化します。
\n\nMCPが進化し、採用が進むにつれて、この記事で説明されているセキュリティパターンは、エンタープライズデプロイメントにとってますます重要になります。これらのパターンを今実装することで、AIエージェントインフラストラクチャが安全でスケーラブルで、将来に備えていることを保証できます。
\n\ngraph LR\n A[美化されたAPI呼び出し] -->|進化| B[安全なMCPアーキテクチャ]\n \n subgraph \"主要な利点\"\n C[一元化されたセキュリティ]\n D[アイデンティティ伝播]\n E[ポリシー実施]\n F[監査とコンプライアンス]\n G[運用の簡素化]\n end\n \n B --> C\n B --> D\n B --> E\n B --> F\n B --> G\n \n classDef benefit fill:#bfb,stroke:#333,stroke-width:1px;\n class C,D,E,F,G benefit;\nこの最後の図は、「美化されたAPI呼び出し」から安全なMCPアーキテクチャへの進化をまとめ、このアプローチの主要な利点を強調しています:
\n\nこのアーキテクチャを採用することで、組織はエンタープライズ環境にAIエージェントを自信を持ってデプロイでき、MCPインタラクションが安全で監査可能で、大規模に管理可能であることを知ることができます。これは、AIツールを単なるAPI呼び出しとして見る単純な見方を大きく前進させ、本番AIシステムの複雑なセキュリティ要件を認識しています。
", "source_hash": "sha256:2e298f37ca328b0eb320a81887dd3640aeb212ad3bf1d820c547bb98ab9e3b19", "model": "claude-sonnet-4-5-20250929", "generated_at": "2026-01-02T03:20:29.215753+00:00" }