目次
はじめに
こんにちは。ACS 事業部の折田です。
Microsoft Foundry で ツールとしてMCP（Model Context Protocol）を利用する際、公式ドキュメントには以下のような重要な注意書きがあります。
「プライベート MCP サーバー: 同じ仮想ネットワークにデプロイされたプライベート MCP サーバーの使用はサポートされていません。パブリックにアクセスできる MCP サーバーのみがサポートされています。」 learn.microsoft.com
この「パブリック公開が必須」という制約について実際に検証してみたところ、その挙動は想像以上にトリッキーで、いくつか見落としがちな “ハマりどころ” が見えてきました。
本記事では、検証結果に基づき以下の2点に絞って解説します。
- Foundry エージェントが MCP に接続する際の「名前解決」の挙動
- MCP をパブリック公開する際に必須となる「セキュリティ対策」の要点
Foundry エージェントが MCP に接続する際の実際の挙動
上図の構成では、Foundry エージェントから各 MCP へ、プライベートエンドポイント経由（プライベート DNS ゾーン設定済み）で接続を試みています。公式ドキュメントの記述からは、「Foundry エージェントは VNet を経由せず、常にパブリック経路で MCP にアクセスする」ものと理解していました。
しかし、この構成で実際にエージェントから MCP を呼び出すと、以下のような 名前解決エラー（Name or service not known） が発生します。
Error encountered while enumerating tools from remote server: https://xxxxxxxx.search.windows.net:443/knowledgebases/knowledgebase-test/mcp. Details: Name or service not known (xxxxxxxx.search.windows.net:443)
調査を進めた結果、プライベート DNS ゾーンの A レコードを削除すると、正常に接続できることが分かりました。
どうやら Foundry エージェントは、インターネット（パブリック）経由で MCP へ到達しようとする際、プライベート DNS ゾーンにレコードが存在していると、それを優先して参照しプライベート IP を解決しようとしてしまうようです。
その結果、パブリック経路での通信と矛盾が生じ、エラーになるものと考えられます。
（これが意図された仕様なのか、現時点での制約的な挙動なのかは判断が難しいところです……）
さらに、Foundry エージェント側で VNet インジェクションを有効化していない環境であっても、プライベート DNS ゾーンが紐づいていると同じ事象が発生することを確認しました。
MCP をパブリック公開する場合に押さえておきたいセキュリティ対策
Foundry エージェントがパブリック経由で MCP にアクセスする必要がある以上、ネットワークによる閉域化に頼るのではなく、「認証・認可レベルでの強固な防御」 が不可欠です。
代表的な MCP 実装である AI Search（Foundry IQ）と Logic Apps / Azure Functionsを例に、有効なセキュリティ構成を整理します。
AI Search（Foundry IQ）で行うべき設定
AI Search を MCP として利用する場合、以下の設定を組み合わせることで、パブリック公開を維持しつつアクセスを Foundry だけに限定できます。
- API キー認証を無効化
キーの漏洩リスクを排除するため、キー認証は使用せず無効化します。 パブリックアクセスを「無効」にし、「信頼されたサービス」の例外を許可
特定の Microsoft サービス（マネージド ID）のみがアクセスできるよう制御します。※「信頼されたサービス」の挙動は PaaS サービスごとに異なる場合があるため、最新の公式ドキュメントを確認しながら設定することを推奨します。
Foundry プロジェクトのマネージド ID に適切な RBAC を付与
「信頼されたサービス」の例外設定だけでは不十分です。Foundry のシステム割り当てマネージド ID に対し、「Search Index Data Reader」などのロールを明示的に割り当てる必要があります。
これにより、「インターネットに口は開いているが、特定のマネージド ID 以外は一切通さない」というセキュアな構成が可能になります。
Logic Apps / Functions を MCP として公開する場合
これらを MCP として利用する場合は、Easy Auth（App Service 認証）を活用してアクセスを絞り込みます。
- App Service 認証を有効化し、未認証リクエストをブロック
「認証されていない要求」に対して HTTP 403 (Forbidden) を返すように設定し、API キー認証なども実質的に無効化します。 - Foundry プロジェクトのマネージド ID を「許可された ID」に指定
ID プロバイダーの設定で、特定の Foundry プロジェクトが持つオブジェクト ID を許可対象に加えます。これにより、そのプロジェクトからのアクセスのみに限定できます。 - 「許可されるトークン対象ユーザー（aud）」を
https://ai.azure.com/に設定
Foundry から発行されるトークンのみを受け入れるようにし、他のアプリケーションからの不正なアクセスを排除します。 - 「テナントの要件」で自組織のテナントに限定
他テナントからのトークンを拒否するよう制限をかけ、マルチテナント攻撃のリスクを抑えます。
これらの設定を施すことで、パブリックエンドポイントを持ちながらも、実質的には特定の Foundry プロジェクトだけがアクセスできる「準閉域」な環境を構築できます。
最後に
今回は、Microsoft Foundry から MCP へ接続する際の挙動と、パブリック公開時に必須となるセキュリティ対策について解説しました。
さらに高度な制御を行いたい場合は、API Management (APIM) を介することで、MCP ツールごとにきめ細かな RBAC 制御を行うことも可能です。 APIM を活用したハンズオン記事も公開しておりますので、興味のある方はぜひこちらも併せてご覧ください。
ACS 事業部のご紹介
私達 ACS 事業部はクラウドネイティブ技術、Azure AI サービス、Platform Engineering などを活用し、攻めの DX 成功に向けた開発者体験の向上・内製化のご支援をしております。
www.ap-com.co.jp
www.ap-com.co.jp
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
www.ap-com.co.jp
