Azure AI Foundryの仮想ネットワーク設定｜Foundry Toolsの変更点と確認ポイント

Azure AI Foundry で Foundry Tools を安全に使うなら、最初に確認すべきポイントは「ネットワークを閉じる順番」です。結論から言うと、既定のままでは Foundry Tools リソースは任意のネットワークからの接続を受け入れるため、本番環境では Selected Networks and Private Endpoints を前提に、許可する VNet・IP アドレス・Private Endpoint・DNS・認証をセットで設計する必要があります。特に、既定ルールを Deny にする前に許可ルールを用意しておかないと、アプリケーション、テストコンソール、Azure サービス連携が突然接続できなくなる可能性があります。(Microsoft Learn)

この記事では、Azure AI Foundry の「Configure Virtual Networks for Foundry Tools」で押さえるべき変更点、影響範囲、管理者・開発者が確認すべき設定、移行時の注意点を実務目線で整理します。単に「VNet を設定する」だけでなく、Azure OpenAI、Azure AI Search、オンプレミス接続、Private Link、DNS、IaC 展開まで含めて確認しましょう。

Azure AI Foundry の Foundry Tools 仮想ネットワーク設定で押さえる結論

Azure AI Foundry の Foundry Tools における仮想ネットワーク設定は、単一のスイッチで完結するセキュリティ機能ではありません。Microsoft Learn では、Foundry Tools は階層型セキュリティモデルを提供し、指定した IP アドレス、IP 範囲、Azure Virtual Network のサブネットからの要求だけを許可できると説明されています。ネットワークルールが有効な場合でも、Microsoft Entra ID または有効な API キーによる認証は別途必要です。(Microsoft Learn)

実務では、次のように考えると分かりやすいです。

観点	確認すべきこと
入口の制御	Foundry Tools リソースに対して、どの VNet、サブネット、IP から接続を許可するか
既定動作	既定で許可するのか、既定で拒否して明示的に許可するのか
プライベート接続	Private Endpoint と Private DNS を使い、パブリックインターネットを経由しない構成にするか
Azure サービス連携	Azure AI Search、Azure Machine Learning、Foundry Tools などの信頼された Azure サービスを例外として許可するか
認証	ネットワーク許可だけでなく、Entra ID、API キー、マネージド ID、RBAC が正しく設定されているか

特に重要なのは、ネットワークルールは REST や WebSocket を含む Foundry Tools へのすべてのネットワークプロトコルに適用される点です。既存リソースにも新規リソースにも適用でき、適用後はすべての要求に対して強制されます。(Microsoft Learn)

何が変わるのか：Cognitive Services 的な設定を Foundry Tools として見直す必要がある

今回のポイントは、Azure AI Foundry 利用者が Foundry Tools リソースのネットワーク境界をより明示的に設計する必要があることです。公式ページの URL やコマンド例では cognitiveservices や Microsoft.CognitiveServices が引き続き使われていますが、ドキュメント上は Foundry Tools リソースの仮想ネットワーク構成として整理されています。たとえば、Azure CLI の例では az cognitiveservices account network-rule、サービスエンドポイントでは Microsoft.CognitiveServices が使われています。(Microsoft Learn)

つまり、管理者は「Azure AI Foundry だから Foundry 専用のまったく別のネットワーク設定がある」と考えるのではなく、既存の Cognitive Services 系リソースのネットワーク ACL、サービスエンドポイント、Private Endpoint、DNS、信頼された Azure サービス例外を Foundry Tools の文脈で再点検する必要があります。

影響を受けやすい対象

対象者	影響
Azure 管理者	既定のネットワークアクセス、VNet ルール、IP ルール、Private Endpoint、DNS の設計が必要
ネットワーク担当者	サブネット、サービスエンドポイント、Private DNS、オンプレミス NAT IP、ExpressRoute 経由の到達性確認が必要
アプリ開発者	SDK、REST API、WebSocket、エンドポイント URL、認証方式の確認が必要
セキュリティ担当者	パブリックアクセスの無効化、信頼された Azure サービス例外、マネージド ID 権限の監査が必要
IaC 担当者	Bicep、Terraform、Azure CLI、PowerShell で再現可能な設定に落とし込む必要

既定では「すべてのネットワークから接続可」なので、本番環境では見直しが必要

Foundry Tools リソースは、既定では任意のネットワーク上のクライアントからの接続を受け入れます。選択したネットワークだけに制限するには、Azure portal の Networking で Selected Networks and Private Endpoints を選び、既定のネットワークアクセスルールを変更します。(Microsoft Learn)

ただし、ここでよくある失敗が「先に拒否してしまう」ことです。既定ルールを Deny にすると、許可する VNet ルールや IP ルールがない限り、データアクセスはブロックされます。公式ドキュメントでも、既定ルールを拒否にする前に許可ネットワークを構成し、オンプレミスを許可する場合は発信に使われるすべてのパブリック IP アドレスを追加するよう注意されています。(Microsoft Learn)

実務では、次の順番で進めるのが安全です。

手順	作業	目的
1	現在の接続元を洗い出す	アプリ、開発端末、CI/CD、Azure サービス、オンプレミス拠点を把握する
2	許可する VNet・サブネット・IP を決める	必要な経路だけを残す
3	Private Endpoint と DNS を設計する	パブリックインターネットを避ける
4	検証環境で Deny を試す	影響範囲を事前に確認する
5	本番で段階的に切り替える	障害時に戻せるようにする

VNet ルールを使う場合は「サブネット単位」で許可する

Foundry Tools リソースは、特定のサブネットからのアクセスだけを許可できます。対象のサブネットは同じサブスクリプションでも、別サブスクリプションでも構成可能です。別サブスクリプションを使う場合は、そのサブスクリプション側でも Microsoft.CognitiveServices リソースプロバイダーの登録が必要です。(Microsoft Learn)

VNet ルールを適用するには、対象サブネットに対して適切な権限が必要です。公式ドキュメントでは、既定の共同作成者ロールまたは Cognitive Services 共同作成者ロールが必要とされています。異なる Microsoft Entra テナントの VNet にあるサブネットを許可する場合、Azure portal では表示はできても構成はできず、PowerShell、Azure CLI、REST API を使う必要があります。(Microsoft Learn)

Azure CLI で確認する基本コマンド

現在の既定ネットワークルールを確認するには、次のように実行します。

az cognitiveservices account show \
  --resource-group "myresourcegroup" \
  --name "myaccount" \
  --query properties.networkAcls.defaultAction

既存サブネットで Foundry Tools のサービスエンドポイントを有効にする例です。

az network vnet subnet update \
  --resource-group "myresourcegroup" \
  --name "mysubnet" \
  --vnet-name "myvnet" \
  --service-endpoints "Microsoft.CognitiveServices"

サブネットをネットワークルールに追加する例です。

subnetid=$(az network vnet subnet show \
  --resource-group "myresourcegroup" \
  --name "mysubnet" \
  --vnet-name "myvnet" \
  --query id \
  --output tsv)

az cognitiveservices account network-rule add \
  --resource-group "myresourcegroup" \
  --name "myaccount" \
  --subnet $subnetid

最後に既定ルールを Deny にしないと、ネットワークルールは期待どおり効力を発揮しません。公式ドキュメントでも、既定ルールを拒否に設定する必要があると明記されています。(Microsoft Learn)

IP ルールは「パブリック IPv4」だけを許可対象にする

オンプレミス拠点や固定グローバル IP を持つサービスから接続する場合は、IP ネットワークルールを使えます。CIDR 形式または個別の IP アドレスで許可できますが、対象はパブリックインターネット IP アドレスのみです。10.*、172.16.*〜172.31.*、192.168.* のようなプライベート IP 範囲は IP ルールでは使えません。(Microsoft Learn)

また、現時点でサポートされるのは IPv4 アドレスのみで、各 Foundry Tools リソースは最大 100 個の IP ネットワークルールをサポートします。IP ルールは VNet ルールと組み合わせて利用できます。(Microsoft Learn)

やりたいこと	推奨設定
社内ネットワークから接続したい	社内の送信元 NAT パブリック IP を IP ルールに追加
Azure VM やアプリを閉域で接続したい	VNet ルールまたは Private Endpoint を使う
プライベート IP を直接許可したい	IP ルールではなく VNet ルールや Private Endpoint を検討
ExpressRoute Microsoft ピアリング経由で許可したい	使用される NAT パブリック IP を確認して許可

ここでの落とし穴は、オンプレミスの出口 IP が複数あるケースです。プロキシ、SD-WAN、拠点別 NAT、災害対策回線を使っている環境では、実際の送信元 IP が設計書と異なることがあります。切り替え前に、アプリケーションログ、Firewall ログ、ネットワーク担当者への確認をセットで行いましょう。

Private Endpoint を使う場合は DNS が成否を分ける

Foundry Tools リソースの Private Endpoint を使うと、仮想ネットワーク上のクライアントが Azure Private Link 経由でリソースへ接続できます。トラフィックは仮想ネットワークと Microsoft Azure バックボーン上の Private Link を通るため、パブリックインターネットへの露出を減らせます。(Microsoft Learn)

Private Endpoint 構成で特に重要なのは、エンドポイント URL と DNS です。公式ドキュメントでは、クライアントから Private Endpoint へ要求する際、Foundry Tools リソースのカスタムサブドメインをベース URL として指定し、Azure 内部の CNAME 解決で使われる *.privatelink.openai.azure.com を直接呼び出してはいけないと説明されています。(Microsoft Learn)

また、Azure OpenAI in Foundry Models は、他の Foundry Tools とは異なる Private DNS ゾーンとパブリック DNS ゾーンフォワーダーを使う点にも注意が必要です。カスタム DNS やオンプレミス DNS を使う場合は、Foundry Tools リソースの FQDN が Private Endpoint のプライベート IP に解決されるように、privatelink サブドメインの委任や DNS A レコードを構成します。(Microsoft Learn)

Private Endpoint 構成で確認する項目

確認項目	失敗すると起きること
Private DNS ゾーンが VNet にリンクされているか	パブリック IP に解決され、閉域接続にならない
カスタム DNS から Private DNS へ名前解決できるか	社内端末やジャンプサーバーから接続できない
アプリがカスタムサブドメインを使っているか	内部 privatelink URL を直接呼び出して失敗する
Public network access をどう扱うか	Private Endpoint があってもパブリック経路が残る可能性がある
Speech など例外サービスを使っていないか	通常と異なるエンドポイント設定が必要になる場合がある

接続確認では、VNet 内の VM、Azure Bastion 経由のジャンプボックス、または VPN 接続済み端末から nslookup を実行し、対象 FQDN が 10.x、172.16〜172.31、192.168.x などのプライベート IP に解決されるかを確認します。

Azure OpenAI と Azure AI Search 連携では「信頼された Azure サービス」も確認する

Azure OpenAI を含む Foundry Tools リソースをネットワーク制限すると、Azure AI Search、Azure Machine Learning、他の Foundry Tools との連携が影響を受けることがあります。公式ドキュメントでは、適切なロール割り当てを持つマネージド ID がある場合、Foundry Tools、Azure Machine Learning、Azure Search などの信頼された Azure サービスに Azure OpenAI へのアクセスを許可できると説明されています。(Microsoft Learn)

この例外は、単にネットワーク上で許可するだけでは不十分です。マネージド ID とロール割り当てが前提になります。Azure portal では、ネットワーク設定の例外として「信頼されたサービスの一覧上の Azure サービスにこの Cognitive Services アカウントへのアクセスを許可する」を選択します。REST API では networkAcls.bypass を AzureServices に設定し、取り消す場合は None に戻します。(Microsoft Learn)

開発者にとっては、ここがトラブルの多いポイントです。たとえば、Azure AI Search のインデクサーやスキルセットから Azure OpenAI を呼び出す構成では、ネットワーク、Private Link、マネージド ID、RBAC のどれか一つが欠けても失敗します。接続エラーだけを見て「API キーが違う」と判断せず、ネットワーク ACL と認可を分けて調査してください。

Foundry Agent Service を使う場合は別のネットワーク要件も確認する

Azure AI Foundry で Agent Service を使う場合は、Foundry Tools リソース単体の VNet 設定だけでは不十分です。Microsoft Learn の Foundry Agent Service のプライベートネットワーク手順では、Standard Setup with private networking により、パブリック egress なし、サブネット統合、プライベートリソースアクセスを実現できると説明されています。(Microsoft Learn)

この構成では、Azure Storage、Azure AI Search、Azure Cosmos DB などの BYO リソースが重要になります。特に、仮想ネットワークインジェクションを使う場合、Storage、Azure AI Search、Cosmos DB は自分で用意する必要があります。また、Foundry リソースをデプロイしても、Azure AI Search、Azure Storage、Azure Cosmos DB への Private Endpoint は自動作成されないため、各リソース側で別途作成する必要があります。(Microsoft Learn)

Agent Service では、デプロイ後に次の確認が推奨されています。

確認項目	内容
サブネット委任	Agent サブネットが Microsoft.App/environments に委任されているか
Public network access	Foundry、Azure AI Search、Azure Storage、Azure Cosmos DB で無効化されているか
DNS 解決	各エンドポイントが Private Endpoint のプライベート IP に解決されるか
Agent の実行	VNet 内から Foundry プロジェクトにアクセスし、Agent を作成・実行できるか
ロール割り当て	必要なマネージド ID、Network Contributor、関連 RBAC が設定されているか

Hosted agents では、ネットワークインジェクションを Foundry アカウント作成時に含める必要があり、既存の Foundry アカウントへ後から追加することはサポートされていないとされています。展開後に閉域化すればよいと考えていると、作り直しが必要になる可能性があるため、設計段階で確認してください。(Microsoft Learn)

管理者が確認すべき設定チェックリスト

本番環境で Azure AI Foundry の Foundry Tools を使う前に、最低限次の項目を確認しましょう。

リソース単位の確認

• Foundry Tools リソースの networkAcls.defaultAction が意図した値になっているか
• All networks のまま本番利用していないか
• Selected Networks and Private Endpoints にした場合、許可 VNet、IP、Private Endpoint がそろっているか
• VNet ルールを使う場合、対象サブネットで Microsoft.CognitiveServices サービスエンドポイントが有効か
• IP ルールにプライベート IP 範囲を入れようとしていないか
• IP ルール数、VNet ルール数が上限に近づいていないか

DNS と接続経路の確認

• Private DNS ゾーンが正しい VNet にリンクされているか
• オンプレミス DNS から Private Endpoint の名前解決ができるか
• アプリが *.privatelink.openai.azure.com ではなく、Foundry Tools リソースのカスタムサブドメインを使っているか
• VPN、ExpressRoute、Bastion、ジャンプボックスなど、運用時の接続経路が確保されているか
• 障害時に検証できる VNet 内端末があるか

認証と権限の確認

• アプリケーションが Microsoft Entra ID または API キーで認証できるか
• マネージド ID を使う Azure サービスに必要な RBAC が割り当てられているか
• Azure AI Search、Azure Machine Learning、Foundry Tools 連携で trusted services 例外が必要か
• クロステナント、別サブスクリプション構成で PowerShell、Azure CLI、REST API による設定が必要か
• IaC とポータル手動変更の差分が発生していないか

開発者が注意すべき実装ポイント

開発者側で最も重要なのは、ネットワークエラーと認証エラーを分けて切り分けることです。ネットワークルールが有効な環境では、API キーやトークンが正しくても、接続元が許可されていなければアクセスできません。逆に、ネットワークが許可されていても、Entra ID や API キーが不正なら当然失敗します。

実装時は、次のような確認を入れておくと運用が楽になります。

実装ポイント	理由
エンドポイント URL を環境変数で管理する	Private Endpoint 構成でも同じ接続文字列を使うケースがあるため、環境差分を吸収しやすい
SDK と REST の両方で接続確認する	SDK 固有の設定ミスとネットワーク問題を分けやすい
VNet 内からの疎通テストを用意する	Private DNS や Firewall の問題を早期に見つけられる
タイムアウトとリトライを適切に設定する	DNS、Firewall、Private Link の問題が単なる遅延に見えることがある
CI/CD の実行元 IP を把握する	デプロイ時やテスト時だけ失敗する原因になりやすい

特に、Azure portal のテストコンソールや Studio 系画面からの確認を前提にしているチームは注意が必要です。公式ドキュメントでは、Azure OpenAI、LUIS、Speech、Language などでポータルや Studio を VNet から使う場合、AzureActiveDirectory、AzureFrontDoor.Frontend、AzureResourceManager、CognitiveServicesManagement、CognitiveServicesFrontEnd などのサービス タグが必要になると説明されています。(Microsoft Learn)

移行・展開時に失敗しやすいポイント

既定ルールを先に Deny にしてしまう

最も多い失敗は、許可ルールを作る前に Deny にすることです。この場合、アプリケーションだけでなく、検証用ツールや Azure サービス連携まで止まります。先に VNet ルール、IP ルール、Private Endpoint、DNS を構成し、検証してから Deny に切り替えましょう。

Private Endpoint を作っただけで閉域化できたと思い込む

Private Endpoint を作成しても、DNS がパブリックエンドポイントを向いていれば、期待した閉域接続になりません。VNet 内から名前解決し、Private Endpoint のプライベート IP に解決されることを必ず確認します。

Azure サービス連携を考慮していない

Azure AI Search や Azure Machine Learning から Azure OpenAI を呼び出す構成では、信頼された Azure サービス例外、マネージド ID、RBAC が必要になる場合があります。ネットワークだけでなく、認証・認可の設計も同時に確認してください。

IaC に反映せず、ポータルで手作業してしまう

検証時にポータルでネットワークルールを追加し、そのまま本番展開すると、再作成や別環境展開で設定漏れが起きます。Bicep、Terraform、Azure CLI、PowerShell のいずれかで、ネットワーク ACL、Private Endpoint、Private DNS、ロール割り当てを再現できる状態にしておきましょう。

Agent Service の BYO リソースを閉域化し忘れる

Foundry Agent Service では、Foundry リソースだけでなく、Storage、Azure AI Search、Cosmos DB などの関連リソースも閉域化対象です。公式手順でも、これらの Private Endpoint は自動作成されないため、別途作成が必要とされています。(Microsoft Learn)

どの接続方式を選ぶべきか

接続方式は、セキュリティ要件、運用負荷、既存ネットワーク構成で選びます。

接続方式	向いているケース	注意点
VNet サービスエンドポイント	Azure 内の特定サブネットから Foundry Tools に接続したい	既定ルールを Deny にしないと効果が出ない
IP ルール	固定パブリック IP を持つオンプレミスや外部サービスから接続したい	プライベート IP は指定できず、IPv4 のみ
Private Endpoint	パブリックインターネットを避け、閉域接続したい	DNS 設計と Private DNS ゾーンのリンクが必須
Trusted Azure services	Azure AI Search や Azure Machine Learning などから連携したい	マネージド ID と RBAC が前提
Foundry Agent Service private networking	Agent、BYO Storage、Search、Cosmos DB を含めて閉域化したい	サブネット委任、BYO リソース、Private Endpoint をまとめて設計する必要がある

基本方針として、本番環境では Private Endpoint を第一候補にし、オンプレミスや一部外部サービスの接続に IP ルールを補助的に使う設計が現実的です。開発環境では運用負荷とのバランスを見ながら、少なくとも本番データを扱うリソースは All networks のままにしないことを推奨します。

次にやるべきこと

Azure AI Foundry の Foundry Tools を利用している管理者は、まず対象リソースのネットワーク設定を棚卸ししてください。確認すべき最初のコマンドは、既定ルールの確認です。

az cognitiveservices account show \
  --resource-group "<resource-group>" \
  --name "<foundry-tools-resource-name>" \
  --query properties.networkAcls

そのうえで、次の順番で進めると安全です。

優先度	作業
高	本番リソースが All networks になっていないか確認する
高	アプリ、Azure サービス、オンプレミス、CI/CD の接続元を洗い出す
高	Private Endpoint と DNS の設計を決める
中	VNet ルール、IP ルール、trusted services 例外の必要性を判断する
中	検証環境で Deny 切り替えを試す
中	IaC にネットワーク設定を反映する
低	運用手順書に名前解決、疎通確認、ロール確認、切り戻し手順を追加する

Azure AI Foundry のネットワーク設定は、セキュリティ強化のための重要な機能ですが、設定順序を誤ると業務アプリや開発環境に影響します。まずは「誰が、どこから、どの Foundry Tools リソースへ接続しているのか」を可視化し、許可ルールと DNS を整えてから既定拒否へ移行するのが安全です。