Azure AI Foundryでエージェントやプロンプトを扱う際に「外部通信をどこまで閉じるべきか」「Private Endpointをどう設計すべきか」で悩んでいる管理者にとって、managed virtual network（マネージド仮想ネットワーク）は重要な選択肢になります。
結論から言うと、このプレビュー機能は、Foundryプロジェクト内のAgent関連のアウトバウンド通信をMicrosoft管理のネットワーク境界で制御し、Storage、Cosmos DB、Azure AI Searchなどの依存リソースへPrivate Endpoint経由で接続しやすくする仕組みです。ただし、作成後に無効化できない設定や、Azure Portal UIでの作成未対応、リージョン制限、Azure Firewall課金など、設計段階で決めるべきポイントが多くあります。(Microsoft Learn)
本番環境へ展開する前に、分離モード、RBAC、Private Endpoint、アウトバウンド規則、既存環境からの移行可否を整理しておくことが重要です。
Azure AI Foundryのマネージド仮想ネットワークで何が変わるのか
Azure AI Foundryのmanaged virtual networkは、Foundryリソースに対してMicrosoft管理の仮想ネットワークを用意し、Foundryプロジェクト内のAgentサービスが利用する基盤コンピューティングの送信通信をネットワーク境界内で制御する機能です。自社でVNet、サブネット、IP範囲、委任設定を一から設計する負担を減らしつつ、承認したAzureリソースへの接続を許可できます。(Microsoft Learn)
特に注目すべき点は、新しいFoundryポータル、新しいResponses API、Promptサービス、Hosted Agentサービスでマネージド仮想ネットワークがサポートされるようになっていることです。Agentを業務データや社内システムと連携させる場合、データ流出リスクを抑えるためのネットワーク設計がこれまで以上に重要になります。(Microsoft Learn)
ただし、この機能は万能な「閉域化スイッチ」ではありません。対象は主にFoundryプロジェクトで作成する新しいAgentのアウトバウンド通信であり、選択した分離モードやアウトバウンド規則によって到達先が決まります。既存のネットワーク分離設計、Private Link、Azure Firewall、オンプレミス接続要件と合わせて評価する必要があります。
対象になる管理者・開発者
この変更の影響を受けるのは、Azure AI Foundryを使う開発者だけではありません。むしろ、ネットワーク、セキュリティ、ID管理、コスト管理の担当者が早い段階で設計に入るべき機能です。
| 対象者 | 確認すべきポイント |
|---|---|
| Azure管理者 | 対応リージョン、サブスクリプションのリソースプロバイダー登録、クォータ、RBAC |
| ネットワーク管理者 | 分離モード、Private Endpoint、FQDN規則、Azure Firewall課金 |
| セキュリティ担当者 | 承認済み送信先、データ流出対策、監査方針 |
| Foundry開発者 | Agentが必要とするStorage、Cosmos DB、AI Search、外部FQDN |
| IaC担当者 | Bicep、Terraform、az rest、Azure CLIによる展開方法 |
| 運用担当者 | デプロイ後の検証、アウトバウンド規則の棚卸し、CapHost再作成 |
開発者だけで分離モードを選んでしまうと、後から「必要なFQDNに出られない」「Azure Firewallの費用を見込んでいなかった」「既存のカスタムVNet構成から移行できない」といった問題が起きやすくなります。
分離モードは2種類、選び方を間違えると戻せない
マネージド仮想ネットワークでは、主に2つのアウトバウンド分離モードを選択します。Microsoft Learnでは、Allow internet outboundとAllow only approved outboundが説明されています。前者はインターネットへの送信を広く許可し、後者はサービスタグ、Private Endpoint、必要に応じたFQDN規則で送信先を制限します。(Microsoft Learn)
| モード | 特徴 | 向いているケース | 注意点 |
|---|---|---|---|
| Allow internet outbound | インターネット向けアウトバウンドを許可 | 検証環境、外部接続先が多いPoC、厳密な閉域要件がない環境 | 許可範囲が広いため、データ流出対策は別途検討が必要 |
| Allow only approved outbound | 承認済みの送信先だけを許可 | 本番環境、機密データを扱うAgent、金融・医療・社内データ連携 | FQDN規則やPrivate Endpoint設計が不足すると機能が動かない |
| DisabledまたはカスタムVNet | マネージド仮想ネットワークを使わない | 既存の自社VNet、独自Firewall、UDR、ピアリングを細かく制御したい環境 | 構成が複雑になり、サブネット委任などの設計が必要 |
重要なのは、一度有効化したマネージド仮想ネットワークは無効化できず、Allow only approved outboundからAllow internet outboundへ戻すこともできない点です。モード変更を前提にした段階的な本番移行は避け、検証用Foundryリソースで通信要件を洗い出してから本番用リソースを作成するのが安全です。(Microsoft Learn)
対応リージョンと日本環境での確認ポイント
2026年5月時点の公式情報では、マネージド仮想ネットワークの対応リージョンにJapan East（東日本）が含まれています。一方で、すべてのAzureリージョンで使えるわけではありません。米国東部、米国東部2、東日本、フランス中部、UAE北部、ブラジル南部、スペイン中部、ドイツ中西部、イタリア北部、米国中南部、オーストラリア東部、スウェーデン中部、カナダ東部、南アフリカ北部、米国西部、米国西部3、インド南部、英国南部などが対象として挙げられています。(Microsoft Learn)
日本企業で確認すべきポイントは次の3つです。
- 東日本リージョンで要件を満たせるか
- 利用するAzure AI Search、Storage、Cosmos DBなどの依存リソースも同一または適切なリージョンで用意できるか
- 社内ルール上、西日本や特定リージョンを必須としていないか
リージョン対応は今後変わる可能性があるため、展開直前に公式ドキュメントとAzure側の実際の利用可否を確認してください。
導入前に確認すべき前提条件
マネージド仮想ネットワークを使うには、Azure CLI、リソースプロバイダー、RBAC、リージョンクォータを事前に確認する必要があります。公式手順では、Azure CLI 2.86.0、Microsoft.Network、Microsoft.KeyVault、Microsoft.CognitiveServices、Microsoft.Storage、Microsoft.Search、Microsoft.ContainerServiceなどのリソースプロバイダー登録が前提として示されています。(Microsoft Learn)
| 項目 | 確認内容 |
|---|---|
| Azure CLI | バージョン2.86.0以上を使用する |
| リソースプロバイダー | Network、KeyVault、CognitiveServices、Storage、Search、ContainerServiceを登録 |
| Foundry側RBAC | Foundry Account Owner、Foundry Userなどの権限を確認 |
| Azure RBAC | RBAC割り当てにはOwnerまたはRole Based Access Administratorが必要 |
| リージョンクォータ | Foundry、Cosmos DB、AI Search、Storageなどを作成できる余裕があるか |
| 依存リソース | Storage、Cosmos DB、AI Search、Key VaultなどのリソースIDと配置先を確認 |
Foundry関連のRBACロールは名称変更が進んでおり、Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerは、以前はAzure AI User、Azure AI Owner、Azure AI Account Owner、Azure AI Project Managerという名前でした。ロールIDと基本的な権限は変更されていないとされていますが、Azure Portalやドキュメント上で旧名称が表示される場合があります。(Microsoft Learn)
既存環境への後付けや移行で注意すべきこと
マネージド仮想ネットワークで最も見落としやすいのは、Foundryリソース作成時に設定が必要なプロパティがあることです。公式手順では、AI Servicesアカウント作成時にcustomSubDomainName、allowProjectManagement、networkInjectionsを設定する必要があり、これらはアカウント作成後に追加できないと説明されています。(Microsoft Learn)
また、カスタムVNet構成からマネージド仮想ネットワークへ直接アップグレードするパスはなく、Foundryリソースの再デプロイが必要です。既存のFoundryリソースをそのまま切り替えられると考えると、移行計画に大きなズレが出ます。(Microsoft Learn)
移行時は、次の順序で棚卸ししてください。
- 既存Foundryリソースがマネージド仮想ネットワーク前提で作成されているか確認する
- Agentが利用する依存リソースを洗い出す
- Storage、Cosmos DB、AI Search、Key Vaultなどの接続方式を決める
- 必要なFQDN、サービスタグ、Private Endpointを整理する
- 検証用リソースでAgentを実行し、通信エラーを確認する
- 本番用リソースはIaCで再現可能な形にする
特に、マネージド仮想ネットワークが有効なFoundryリソース内で新しいプロジェクトを作成する場合、BYOリソースとマネージドネットワークを使わせるためにProject capability host、いわゆるCapHostの再作成が必要になる場合があります。(Microsoft Learn)
デプロイ方法はCLI、az rest、Bicep、Terraformが中心
現時点では、マネージドネットワーク作成のAzure Portal UIサポートはまだ提供されていないと説明されています。そのため、実務ではaz rest、Azure CLIのaz cognitiveservices、Bicep、Terraformを使った展開を前提にする必要があります。(Microsoft Learn)
AI Servicesアカウント作成時にnetworkInjectionsを設定する
ネットワークインジェクションを含むFoundryリソース作成は、Azure CLIだけではまだ対応していないため、公式手順ではaz restの利用が示されています。APIバージョンは2026-03-01が使われています。(Microsoft Learn)
az rest --method PUT \
--url "https://management.azure.com/subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.CognitiveServices/accounts/{account-name}?api-version=2026-03-01" \
--body '{
"location": "{region}",
"kind": "AIServices",
"sku": { "name": "S0" },
"identity": { "type": "SystemAssigned" },
"properties": {
"allowProjectManagement": true,
"customSubDomainName": "{account-name}",
"networkInjections": [
{
"scenario": "agent",
"subnetArmId": "",
"useMicrosoftManagedNetwork": true
}
],
"disableLocalAuth": false
}
}' \
--headers "Content-Type=application/json"作成後はprovisioningStateがSucceededになるまで待ってから次の手順へ進めます。プロビジョニング途中でRBACやPrivate Endpointの設定を進めると、後続処理の失敗原因を切り分けにくくなります。
Managed IdentityにNetwork Connection Approverロールを割り当てる
Foundryリソースのシステム割り当てマネージドIDに、Azure AI Enterprise Network Connection Approverロールを付与します。ロールIDはb556d68e-0be0-4f35-a333-ad7ee1ce17eaです。このロールにより、マネージドネットワークのPrivate Endpoint接続を作成・承認できるようになります。(Microsoft Learn)
az role assignment create \
--assignee-object-id {principal-id} \
--assignee-principal-type ServicePrincipal \
--role "b556d68e-0be0-4f35-a333-ad7ee1ce17ea" \
--scope /subscriptions/{subscription-id}/resourceGroups/{resource-group}Storage、Cosmos DB、AI Searchなどのターゲットリソースが別のリソースグループにある場合は、そのリソースグループまたはサブスクリプションに対してスコープを広げる必要があります。RBACのスコープ不足は、Private Endpoint作成失敗の典型的な原因です。(Microsoft Learn)
マネージドネットワークを作成する
Allow internet outboundで作成する場合は、次のように指定します。
az cognitiveservices account managed-network create \
--resource-group {resource-group} \
--name {account-name} \
--managed-network allow_internet_outboundAllow only approved outboundで作成する場合は、Azure Firewall SKUも考慮します。
az cognitiveservices account managed-network create \
--resource-group {resource-group} \
--name {account-name} \
--managed-network allow_only_approved_outbound \
--firewall-sku StandardBicepまたはTerraformで展開する場合は、foundry-samplesリポジトリ内の18-managed-virtual-networkテンプレートを利用できます。テンプレートのパラメーターでは、リージョン、リソースグループ、分離モード、既存のCosmos DB、Storage、SearchのリソースIDなどを事前に整理しておく必要があります。(Microsoft Learn)
アウトバウンド規則は3種類を使い分ける
デプロイ後は、マネージドネットワークが到達できる宛先をアウトバウンド規則で管理します。対応する規則タイプは、FQDN、Private Endpoint、Service Tagの3種類です。(Microsoft Learn)
| 規則タイプ | 用途 | 例 |
|---|---|---|
fqdn | ドメイン名やワイルドカードドメインへの通信を許可 | *.openai.azure.com |
privateendpoint | AzureリソースへPrivate Endpoint経由で接続 | Storageのblob、Cosmos DBのSql |
servicetag | Azureサービス単位で通信を許可 | Storage、AzureActiveDirectory |
実務では、まずPrivate Endpointで接続すべき依存リソースを決め、その後でどうしても必要なFQDNだけを追加する方が安全です。FQDN規則を広く設定しすぎると、Allow only approved outboundを選んだ意味が薄れます。
機能別に必要なFQDNを確認する
Allow only approved outboundでは、機能によって追加のFQDN規則が必要になる場合があります。公式情報では、Agent、Application Insightsを使う評価・トレース、ファインチューニングで利用されるFQDN例が示されています。(Microsoft Learn)
| シナリオ | 追加を検討する宛先 | 主な用途 |
|---|---|---|
| Agents | *.identity.azure.net、login.microsoftonline.com、*.login.microsoftonline.com、*.login.microsoft.com、mcr.microsoft.com、またはAAD Service Tag | Agentサービスの認証、コンテナーイメージ取得 |
| 評価・トレース | settings.sdk.monitor.azure.com、*.livediagnostics.monitor.azure.com、*.in.applicationinsights.azure.com | Application Insightsへの結果送信 |
| ファインチューニング | raw.githubusercontent.com | Foundryポータルでキュレーション済みサンプルデータセットを選ぶ場合 |
FQDN規則はポート80と443のみをサポートします。別ポートが必要な外部サービスや、独自の通信要件を持つ社内サービスと連携する場合は、Application GatewayやカスタムVNet構成を含めて検討してください。(Microsoft Learn)
Private Endpoint設計で確認すべきポイント
マネージド仮想ネットワークを有効にすると、Agentはパブリックインターネットを使わずに、Storage、Azure AI Search、Cosmos DBなどの依存リソースへPrivate Endpoint経由でアクセスできます。ただし、FoundryのマネージドPrivate EndpointはMicrosoftによって完全に管理され、利用者のサブスクリプション上にNICとして表示されません。通常のVNet Private Endpointと同じ見え方を期待すると、運用確認で混乱します。(Microsoft Learn)
| 接続先 | よく使うサブリソースターゲット | 確認ポイント |
|---|---|---|
| Azure Storage | blob | Agentが参照するファイル、データ格納先 |
| Azure Cosmos DB | Sql | Agentやアプリが利用するデータストア |
| Azure AI Search | searchService | RAGや検索連携 |
| Azure Key Vault | vault | シークレット、キー、証明書 |
| Application Gateway | 構成に依存 | オンプレミスや別VNet上の非Azureリソース接続 |
対応リソースには、Microsoft Foundry、Azure Application Gateway、Azure API Management、Azure AI Search、Azure Container Registry、Azure Cosmos DB、Azure Data Factory、Azure Key Vault、Azure SQL Server、Azure Storage、Application Insightsなどが含まれます。ただし、Private Endpoint作成にはCLIが必要です。(Microsoft Learn)
オンプレミスリソースへプライベートにアクセスしたい場合は、Application Gatewayを使った構成が案内されています。L4とL7の両方のトラフィックがサポートされると説明されていますが、ネットワーク経路、証明書、名前解決、バックエンドプールの設計は個別に検証が必要です。(Microsoft Learn)
コスト面ではAzure FirewallとPrivate Linkを見落とさない
Foundryのマネージド仮想ネットワーク機能自体は無料とされています。ただし、Private Endpointに使われるAzure Private Linkと、FQDNアウトバウンド規則で利用されるAzure Firewallには課金が発生します。(Microsoft Learn)
特に注意したいのは、Allow only approved outboundモードでFQDN規則を追加すると、マネージドAzure Firewallが自動的に作成される点です。既定SKUはStandardで、Basic SKUも選択できますが、デプロイ後にSKUを変更できません。また、このFirewallは利用者のテナント内で直接管理するものではなく、制御できる主な設定はSKUに限られます。(Microsoft Learn)
さらに、同じマネージドFirewallを複数のFoundryアカウントで再利用することはできません。FoundryアカウントごとにFirewallが作成されるため、複数環境を展開する場合は、開発、検証、本番それぞれのコストを見積もる必要があります。(Microsoft Learn)
マネージドネットワークとカスタムVNetはどちらを選ぶべきか
マネージド仮想ネットワークは、ネットワーク分離を簡素化したい場合に有効です。一方、独自のFirewall、UDR、VNetピアリング、詳細なログ取得、細かなルーティング制御が必要な場合は、カスタムVNet構成の方が適していることがあります。
| 判断軸 | マネージド仮想ネットワーク | カスタムVNet |
|---|---|---|
| 構築の容易さ | Microsoftがサブネット範囲やIP選択などを管理 | 自社で設計・管理 |
| セキュリティ制御 | 承認済みアウトバウンド、Private Endpoint、Service Tag、FQDN規則 | Firewall、UDR、ピアリングなどを詳細制御 |
| Firewall | BYO Firewall不可。マネージドFirewallが使われる | 独自Firewallを利用可能 |
| オンプレミス接続 | Application Gateway経由で検討 | 既存ネットワーク設計に組み込みやすい |
| ログ | アウトバウンドトラフィックのログ記録はまだ未対応と説明されている | 自社のFirewallや監視基盤で設計可能 |
| 運用負荷 | 低め | 高め |
社内のセキュリティ審査で「すべてのアウトバウンド通信ログを自社管理のFirewallで取得する」ことが必須なら、マネージド仮想ネットワークだけでは要件を満たせない可能性があります。一方、AgentからAzure Storage、Cosmos DB、Azure AI Searchへ安全に接続できればよく、ネットワーク構成を簡素化したい場合は、マネージド仮想ネットワークが有力です。(Microsoft Learn)
デプロイ後の確認手順
マネージド仮想ネットワークを作成したら、設定が反映されているかをCLIで確認します。公式手順では、isolationModeが選択したモードになっているか、アウトバウンド規則とステータスが正しいか、基本的なAgentを作成・実行できるかを確認する流れが示されています。(Microsoft Learn)
az cognitiveservices account managed-network show \
--resource-group {resource-group} \
--name {account-name}az cognitiveservices account managed-network outbound-rule list \
--resource-group {resource-group} \
--name {account-name}検証では、単にリソース作成が成功したかを見るだけでは不十分です。次の観点で確認してください。
isolationModeが意図した値になっているか- Storage、Cosmos DB、AI SearchへのPrivate Endpoint規則が作成されているか
- FQDN規則のステータスが成功しているか
- Agentが認証、データ参照、検索、出力生成まで完了するか
- Application Insightsや評価機能を使う場合、必要なFQDNが許可されているか
- 不要なアウトバウンド規則が残っていないか
失敗しやすいポイントと対策
マネージド仮想ネットワークは便利ですが、プレビュー段階の機能であり、展開時のつまずきやすいポイントがあります。
| 失敗しやすいポイント | 原因 | 対策 |
|---|---|---|
| 既存Foundryリソースに後付けできない | 作成時に必要なプロパティがある | 新規作成または再デプロイを前提にする |
| Private Endpointが作成・承認されない | Managed IdentityのRBAC不足 | Network Connection Approverロールのスコープを確認 |
| FQDN規則が効かない | Firewall未プロビジョニング、ポート制限の見落とし | Firewall SKUと80/443制限を確認 |
| Azure Portalだけで作成しようとする | Portal UI作成が未対応 | CLI、az rest、Bicep、Terraformを使う |
| コストが想定より増える | FQDN規則でAzure Firewallが作成される | FQDN許可を最小化し、SKUを事前に決める |
| NICが見つからない | マネージドPrivate Endpointは利用者サブスクリプションにNICを表示しない | 通常のPrivate Endpointと見え方が違うと理解する |
| CapHost作成に失敗する | プロジェクトとネットワーク構成の不整合 | 問題のCapHostを削除し、テンプレートを再デプロイする |
公式のトラブルシューティングでも、CapHost作成失敗時の再デプロイ、FQDN規則が適用されない場合のFirewall SKUとポート確認、Private Endpoint競合時のサービスエンドポイント構成削除が案内されています。(Microsoft Learn)
管理者と開発者が今すぐ確認すべきチェックリスト
本番展開を検討している場合は、次の順番で確認すると抜け漏れを減らせます。
管理者向けチェック
- 利用リージョンが対応対象に含まれているか
- Azure CLI 2.86.0以上を使えるか
- 必要なリソースプロバイダーを登録済みか
- Foundry Account Owner、Owner、Role Based Access Administratorなどの権限が揃っているか
Azure AI Enterprise Network Connection Approverロールを適切なスコープで割り当てられるかAllow internet outboundとAllow only approved outboundのどちらを使うか決めているか- FQDN規則を使う場合、Azure Firewallの課金を見積もっているか
- 既存のカスタムVNet構成からの移行可否を確認したか
開発者向けチェック
- Agentが必要とするStorage、Cosmos DB、AI Searchを洗い出したか
- RAG、評価、トレース、ファインチューニングで必要なFQDNを確認したか
- 外部APIやSaaSへ接続する必要がある場合、FQDN規則で許可できるか
- 検証環境でAgentを実行し、認証からデータ参照まで確認したか
- 不要な通信先を許可していないか
- エラー発生時にアウトバウンド規則、RBAC、Private Endpointのどこを確認するか決めているか
まずは通信要件の棚卸しから始める
Azure AI Foundryのマネージド仮想ネットワークは、Agentを安全に業務利用するための重要な機能です。特にAllow only approved outboundを使えば、承認済みのAzureリソースやFQDNに通信先を絞り、データ流出リスクを抑えやすくなります。
一方で、作成後に無効化できない、カスタムVNetから直接移行できない、Azure Portal UIだけでは作成できない、FQDN規則でAzure Firewallの費用が発生するなど、設計前に知っておくべき制約も多くあります。
最初にやるべきことは、FoundryプロジェクトでAgentが必要とする通信先を一覧化することです。Storage、Cosmos DB、Azure AI Search、Key Vault、Application Insights、外部FQDNを洗い出し、Private Endpointで閉じる通信とFQDN規則で許可する通信を分けてください。そのうえで、検証用Foundryリソースを新規作成し、IaCで再現できる構成にしてから本番展開へ進むのが安全です。
コメント