本記事は GitHub Copilot および Microsoft Foundry を活用して作成されています。内容の正確性については各公式ドキュメントをご確認ください。
Microsoft Foundry の価値は「使えるモデルの種類が豊富なこと」だけではありません。エンタープライズで AI を本番運用するうえで避けて通れない「ネットワーク要件」を満たす機能——プライベートネットワークへの閉じ込め、Private Link による通信保護、VNet インジェクションによるエージェント実行基盤の隔離、ファイアウォールによる egress 制御——をプラットフォーム標準で提供している点が、大きな強みです。
ただし、これらのネットワーク機能は 開発者が理解して実装するのが難しい のも事実です。Foundry の閉域化は「Private Endpoint を張れば終わり」ではなく、インバウンド と アウトバウンド で仕組みがまったく異なり、特にアウトバウンドはエージェント実行基盤を VNet に注入する「ネットワークインジェクション」が前提になります。そこで本記事では、公式ドキュメントのアーキテクチャ図を交えながら、Foundry のネットワーク設計を インバウンド／アウトバウンド に分けて整理します。あわせて、アウトバウンドを Hub & Spoke 構成にする場合／しない場合 の違い、直近アップデートである プライベート MCP サーバー接続 も解説します。
本記事は以下の公式ドキュメントを根拠にしています（2026 年 6 月時点）。
1. Foundry のネットワーク分離は「3つの領域」で考える
公式ドキュメントでは、Foundry のネットワーク分離を次の 3 領域 に分けて考えるよう示しています。
- インバウンド：Foundry リソースへ入ってくる通信（例：データサイエンティストや業務アプリが Foundry にアクセスする）
- アウトバウンド（Foundry リソース発）：Foundry リソースから他の Azure サービス（Storage / Key Vault / Container Registry / 監視など）へ出ていく通信
- アウトバウンド（Agent クライアント発）：エージェント実行基盤から、プライベートなデータソースや Azure PaaS、許可されたインターネット先へ出ていく通信
下図が、インバウンドとアウトバウンドを俯瞰した公式の全体像です。
出典: How to configure network isolation for Microsoft Foundry
ポイントは、インバウンドは Private Endpoint（Private Link）で守り、アウトバウンドは VNet インジェクション（サブネット委任）で守る、という非対称な構造になっていることです。順番に見ていきます。
2. インバウンド：Private Endpoint で「入口」を閉じる
インバウンドは比較的シンプルです。Foundry プロジェクトの Public Network Access（PNA）フラグ で、入口の開閉を制御します。
| PNA 設定 | 挙動 |
|---|---|
Disabled |
Private Endpoint 経由のみアクセス可能（完全閉域） |
Enabled from selected IP addresses |
指定した IP アドレス／VNet からのみ許可 |
Enabled（既定） |
パブリックに開放 |
閉域化する場合は Disabled を選び、Foundry リソースに対して Private Endpoint を作成します。これにより、VNet 内のクライアント（または ExpressRoute / VPN で接続したオンプレ）から、同じ接続文字列のままプライベート IP で名前解決されるようになります。
DNS のポイント
- Private Endpoint を作ると、Azure は
privatelinkサブドメインのプライベート DNS ゾーンに A レコードを作成します。 -
オンプレや独自 DNS を使う場合は、
privatelinkサブドメインを Azure DNS（168.63.129.16）へ条件付きフォワードする必要があります。 - Foundry（アカウント）で必要となる主な DNS ゾーン：
privatelink.cognitiveservices.azure.comprivatelink.openai.azure.comprivatelink.services.ai.azure.com
インバウンドの接続経路
閉域化した Foundry へ「どこから入るか」は、次のいずれかを選びます。
- ExpressRoute：オンプレからプライベート接続（本番の閉域要件で推奨）
- VPN Gateway（Point-to-site / Site-to-site）
- Azure Bastion + ジャンプボックス VM：VNet 内に開発環境を置く
3. アウトバウンド：VNet インジェクションで「実行基盤」を VNet に注入する
ここが Foundry Agent の最大の特徴です。
エージェントの実体は Azure Container Apps 基盤上で動くコンテナ（Agent クライアント） です。これを顧客の VNet 内の 委任サブネット（Microsoft.App/environments に委任）へ「注入（インジェクション）」することで、エージェントから Cosmos DB / AI Search / Storage などへの アウトバウンド通信を VNet 内に閉じ込めます。
重要：インバウンドの Private Endpoint だけでは、エージェントのアウトバウンドは閉域化できません。アウトバウンドには VNet インジェクション（委任サブネット）が必須です。両方を構成して初めて「No public egress（公開アウトバウンドなし）」が実現します。
下図が、Agent Service と評価（Evaluation）まで含めた推奨ネットワーク分離構成です。
![Foundry の推奨ネットワーク分離構成（Agent / 評価）]
出典: Set up walkthrough for outbound network isolation
アウトバウンド閉域化の前提条件
- Standard Agent Setup（標準セットアップ）が必須。Basic（マネージドリソース）構成では VNet インジェクションは使えません。
- BYO リソースが必須：Azure Storage / Azure AI Search / Azure Cosmos DB を自前で用意し、それぞれに Private Endpoint を手動で作成します（Foundry 作成時に自動作成されません）。
-
Agent サブネット：
Microsoft.App/environmentsに委任。最小/27、公式推奨は/24。他の Foundry リソースと 共有不可（専有）。 -
リージョン制約：Foundry リソースは VNet と同一リージョン。
10.x.x.x（Class A）が使えるリージョンは限定されており、Japan East は利用可能。
構成変更不可という制約に注意
アウトバウンドのネットワーク設定は 後から変更できません。
- 委任サブネットを後から別サブネットに変えられない
- 既存の Foundry に後から VNet インジェクションを追加できない（再デプロイが必要）
このため、最初の設計段階で IP アドレス帯とサブネットを確定させておくことが極めて重要です。
4. アウトバウンドのツールごとのトラフィックフロー
エージェントが使う「ツール」は、閉域環境での通信経路がツールごとに異なります。これを理解しておかないと、「閉域化したのに特定ツールがインターネットに出ていた」という事態になります。
| ツール | 閉域対応 | トラフィック経路 |
|---|---|---|
| MCP Tool（プライベート MCP） | ✅ 対応 | 自分の VNet サブネット経由 |
| Azure AI Search | ✅ 対応 | Private Endpoint 経由 |
| OpenAPI Tool | ✅ 対応 | 自分の VNet サブネット経由 |
| Azure Functions | ✅ 対応 | 自分の VNet サブネット経由 |
| Agent-to-Agent (A2A) | ✅ 対応 | 自分の VNet サブネット経由 |
| Function Calling | ✅ 対応 | Microsoft バックボーン |
| Code Interpreter | ⚠️ 一部 | Microsoft バックボーン。ファイル無しなら可。ファイルの送受信は非対応（SDK で container_id を渡す回避策あり） |
| Bing Grounding / Web Search / SharePoint Grounding | ✅ 動作 | パブリックエンドポイント（インターネット経由） |
| Fabric Data Agent / Logic Apps / File Search / Browser Automation / Computer Use / Image Generation | ❌ 非対応 | 開発中など |
出典: Agent tools with network isolation
注意：Bing / Web Search / SharePoint Grounding は閉域環境でも「動作」しますが、通信は パブリックインターネット経由です。すべての通信を私設ネットワーク内に閉じ込めたい組織では、これらは要件を満たさない可能性があります。Azure Policy でブロックすることも可能です。
5. アウトバウンドを Hub & Spoke にする場合／しない場合
エージェントのアウトバウンド（egress）をさらに厳格に制御したい場合、Azure Firewall などでトラフィックを検査・制御します。ここで構成が 2 パターンに分かれます。
パターン A：スタンドアロン（Hub & Spoke にしない）
- 単一の Foundry 用 VNet 内で完結する構成。
- ファイアウォールも同じ VNet 内、もしくはファイアウォールを使わずに NSG / ルートテーブルで制御。
- 小規模・単一プロジェクト・PoC 向き。
- ネットワークレイアウトは下記の Hub & Spoke 図とは異なる形になります（公式も「ハブ前提でない場合は構成が変わる」と明記）。
パターン B：Hub & Spoke（共有ファイアウォールを中央集約）
- ハブ VNet：共有 Azure Firewall を配置（複数ワークロードの egress を一元管理）。
- スポーク VNet：Foundry のネットワーク（Agent サブネット＋ PE サブネット）を配置。
- ハブとスポークを VNet ピアリング で接続し、スポークからの egress をハブのファイアウォール経由に強制（UDR）。
- 企業の共通ネットワークガバナンス（中央集約型のセキュリティ運用）に適合。
下図が公式の Hub & Spoke 構成例です。
![Foundry の Hub & Spoke ＋ファイアウォール構成（egress 制御）]
出典: Hub-and-spoke and firewall network configuration
ファイアウォールで許可（allowlist）すべき FQDN
VNet インジェクションでファイアウォールを置く場合、以下の FQDN を許可する必要があります（抜粋）。
| シナリオ | 許可する FQDN / サービスタグ | 用途 |
|---|---|---|
| Agents |
*.identity.azure.net, login.microsoftonline.com, *.login.microsoftonline.com, *.login.microsoft.com（または AzureActiveDirectory サービスタグ） |
Agent サービスの Container App 委任に必要 |
| Evaluations & Traces |
*.blob.core.windows.net, settings.sdk.monitor.azure.com
|
評価カタログ／App Insights への結果送信 |
| Finetuning | raw.githubusercontent.com |
キュレーション済みサンプルデータセット利用時 |
TLS インスペクションに注意：ファイアウォールで TLS インスペクション（自己署名証明書の挿入）を行うと Agent の通信が失敗します。Agent サブネットの egress では TLS インスペクションを無効化してください。
6. 【最新アップデート】プライベート MCP サーバー接続
直近のアップデートで、MCP（Model Context Protocol）サーバーをエージェントのツールとして接続する際に、パブリック／プライベートの 2 種類のエンドポイントがサポートされました。
何が嬉しいのか？（ユースケース）
パブリック MCP だけでは、エージェントに渡したい「社内固有のツールやデータ」をインターネット経由で公開せざるを得ず、閉域要件を満たせませんでした。プライベート MCP は、この MCP サーバー自体を VNet 内に閉じ込めたまま エージェントから利用できるようにします。たとえば次のようなシナリオで効果を発揮します。
- 社内 API / 基幹システムをツール化したい：インターネットに公開できない院内システムや業務 DB へのアクセスを、内部専用の MCP サーバー経由でエージェントに安全に提供する。
- 機微データを扱う規制業種（医療・金融・公共）：プロンプトやツール呼び出しの内容を含め、すべての通信を私設ネットワーク内に閉じ込めたい。
- 既存の社内ツール資産を再利用したい：自前でホストした MCP サーバーに社内ナレッジ・検索・計算ロジックをまとめ、複数のエージェントから共通利用する。
- サードパーティ MCP に依存したくない：信頼できる自社ホストのサーバーだけにアクセスを限定し、データの保持先・経路を完全に統制する。
要するに、「エージェントの拡張機能（ツール）まで含めて完全閉域にできる」 のがプライベート MCP の価値です。
| エンドポイント種別 | 必要な構成 | 説明 |
|---|---|---|
| パブリック MCP | Basic / Standard どちらでも可 | 公開された任意のリモート MCP サーバーに接続（例：GitHub の https://api.githubcopilot.com/mcp） |
| プライベート MCP | Standard Agent Setup（閉域）＋ 専用 MCP サブネット必須 | インターネット非公開の MCP サーバーに接続 |
プライベート MCP の構成要件
- Standard Agent Setup（BYO VNet）が前提。Basic 構成ではプライベート MCP エンドポイントは使えません。
- MCP サーバーは Azure Container Apps 上に内部専用イングレス（
--internal-only true）でデプロイします。 -
Microsoft.App/environmentsに委任した専用の MCP サブネットが別途必要です（Agent サブネットとは別枠で設計する必要あり）。 - 公式の Bicep テンプレート 19-private-network-agents-tools-setup が、MCP サブネットを含む必要なネットワークを一括プロビジョニングします。
既知の制約
- 非ストリーミングの MCP ツール呼び出しは 100 秒でタイムアウト。長時間処理はサーバー側で最適化・分割が必要。
- プライベート MCP のホスティングは Azure Container Apps が検証済み構成。Function Apps / App Service でも動く可能性はあるが内部検証はされていない。
出典: Public and private MCP server endpoints
設計への示唆：プライベート MCP を使う予定があるなら、Agent サブネット（
/24推奨）に加えて MCP 専用の委任サブネットを IP 設計に最初から組み込んでおきましょう。後からの追加は再デプロイを伴う可能性があります。
7. 押さえておきたい主な制約（2026 年 6 月時点）
ネットワーク分離が「まだ未対応／一部対応」の機能があります。設計前に必ず確認しましょう。
| 機能 | 状態 | 補足 |
|---|---|---|
| Traces（トレース） | 非対応 | プライベート App Insights での VNet サポートが未対応 |
| Workflow Agents | 一部対応 | インバウンドは対応。アウトバウンドの VNet インジェクションは未対応 |
| AI Gateway (APIM) | 一部対応 | Foundry ポータルから作る Gateway は自動的にパブリック。閉域化は Azure Portal で別途構成が必要 |
| Synthetic Data Gen for Evaluations | 非対応 | 自前データで評価を実行する |
| Hosted Agent の ACR | 制約あり | コンテナイメージ用 ACR はパブリックアクセス有効が必須（PE で完全閉域化不可） |
| アウトバウンド設定の変更 | 不可 | 委任サブネット変更や後付け追加は不可。再デプロイが必要 |
その他、IP 設計で注意すべき点：
-
172.17.0.0/16は使用禁止（Docker ブリッジネットワーク予約のため）。 - Private Endpoint は VNet と同一リージョン・同一サブスクリプションに作成する。
8. まとめ
Microsoft Foundry のネットワーク設計は、次の 3 点を押さえると整理できます。
- インバウンドは Private Endpoint（Private Link）、アウトバウンドは VNet インジェクション（委任サブネット） という非対称構造。両方そろって初めて完全閉域になる。
- アウトバウンドは Hub & Spoke にするか／しないかを、組織のガバナンス（中央集約ファイアウォールの有無）で選ぶ。本番・大規模・共通ガバナンスなら Hub & Spoke が有力。
-
アウトバウンド設定は後から変更不可。Agent サブネット（
/24推奨）、PE サブネット、（必要なら）プライベート MCP 用サブネットを、IP 設計の段階で確定させておく。
特に「Private Endpoint だけ張れば閉域化できる」という誤解は、Foundry Agent では通用しません。実行基盤（コンテナ）を VNet に注入するという発想を最初から設計に織り込むことが、手戻りのない閉域化への近道です。