Azure AI Foundryで社内データやエージェントを扱う場合、ネットワーク分離は「あとから閉じる設定」ではなく、設計時点で決めるべき重要項目です。特に今回の公式情報では、Private Linkによるインバウンド保護だけでなく、Agent Serviceのアウトバウンド通信、BYOリソース、エージェントツールの対応可否まで確認する必要があります。
結論から言うと、Azure AI Foundryのネットワーク分離では、パブリックネットワークアクセスを無効化し、プライベートエンドポイントを作成し、DNS解決を正しく構成することが基本です。さらに、エージェントや評価機能まで閉域で運用したい場合は、Azure Storage、Azure AI Search、Azure Cosmos DBなどのBYOリソースと、VNetインジェクションを前提に設計する必要があります。Microsoft Learnの日本語版ドキュメントは、2026年5月8日に更新されています。(Microsoft Learn)
Azure AI Foundryのネットワーク分離で押さえるべき全体像
Azure AI Foundryのネットワーク分離は、単に「Private Linkを有効にする」だけでは完了しません。公式ドキュメントでは、Microsoft Foundry内のネットワーク分離を次の3つの領域で考えるよう整理されています。(Microsoft Learn)
| 領域 | 何を保護するか | 主な設定 |
|---|---|---|
| インバウンドアクセス | 利用者や開発者がFoundryリソースへ接続する経路 | パブリックネットワークアクセス、プライベートエンドポイント、選択したIPアドレス |
| Foundryリソースからのアウトバウンド | FoundryがAzureサービスへアクセスする経路 | Private Link、プライベートエンドポイント |
| Agentクライアントからのアウトバウンド | エージェントがデータソース、PaaS、外部エンドポイントへ接続する経路 | VNetインジェクション、BYO VNet、ファイアウォール制御 |
実務上のポイントは、「利用者からFoundryへ入る通信」と「エージェントが外へ出る通信」を分けて設計することです。たとえば、管理者がAzure AI Foundryポータルへのアクセスを閉じたいだけなら、インバウンドのPrivate Link設定が中心になります。一方、エージェントが社内データベース、Azure AI Search、MCPサーバー、Azure Functionsなどへアクセスする場合は、アウトバウンド経路まで含めた設計が必要です。
2026年5月8日更新情報で確認すべき主なポイント
今回の公式情報で特に重要なのは、Azure AI Foundryのネットワーク分離が、Private Endpoint、BYOリソース、Agent Service、ツール対応状況まで含めて具体化されている点です。
| 確認ポイント | 内容 | 実務への影響 |
|---|---|---|
| Private Linkが基本 | Foundryアカウントとプロジェクトへプライベート接続する方法が中心 | パブリック公開を避けたい環境では必須の設計項目 |
| PNA設定が重要 | Public Network Accessを無効化、または選択したIPアドレスに制限できる | 「完全閉域」か「限定公開」かを事前に決める必要がある |
| BYOリソースが必要 | Standard構成ではAzure Storage、Azure AI Search、Azure Cosmos DBを持ち込む | エージェントデータの保存先と責任範囲を明確にできる |
| VNetインジェクションに条件がある | BYOリソース選択、PNA無効化、委任済みサブネットなどが必要 | あとから簡単に追加できないため、新規構築時の設計が重要 |
| 関連リソースのPrivate Endpointは自動作成されない | Storage、AI Search、Cosmos DBのPrivate Endpointは個別に作成する | 「Foundryだけ閉じたのに検索やストレージが公開されたまま」を防ぐ必要がある |
| エージェントツールごとに通信経路が違う | VNet経由、Microsoftバックボーン、パブリックエンドポイント、未対応が混在 | コンプライアンス要件に応じて利用可能ツールを選別する必要がある |
| アウトバウンド設定は変更制限がある | 既存デプロイに後からアウトバウンドVNetインジェクションを追加できない | 既存環境では再デプロイを含めた移行計画が必要 |
特に注意したいのは、ネットワーク分離を「既存環境に後付けする」場合の限界です。インバウンドのプライベートエンドポイント追加は既存リソースでも可能ですが、アウトバウンドのVNetインジェクションは既存デプロイへ後から追加できず、必要な場合はFoundryの再デプロイが必要とされています。(Microsoft Learn)
管理者・開発者・セキュリティ担当者への影響範囲
Azure AI Foundryのネットワーク分離は、ネットワーク担当者だけの作業ではありません。AIアプリケーションを作る開発者、ID管理を担当する管理者、セキュリティレビューを行う担当者がそれぞれ確認すべき項目があります。
| 対象者 | 確認すべきこと | 失敗しやすいポイント |
|---|---|---|
| Azure管理者 | Foundryリソース、Private Endpoint、PNA、RBAC | 権限不足でプライベートエンドポイントがPendingのままになる |
| ネットワーク担当者 | VNet、サブネット、DNS、NSG、Azure Firewall、ExpressRoute/VPN | DNSがパブリックIPを返し、閉域化できていない |
| AI開発者 | Agent Service、MCP、Azure AI Search、外部API接続 | 利用したいツールがネットワーク分離環境で未対応 |
| セキュリティ担当者 | パブリックエンドポイント利用、BYOリソース、監査要件 | Bing/Websearchなどがパブリック通信する点を見落とす |
| 運用担当者 | 接続確認、障害切り分け、再デプロイ計画 | 403エラーをネットワーク問題と誤認する |
社内の設計レビューでは、「Private Linkを使うか」だけでなく、どの機能がどの経路で通信するかを一覧化しておくと、後工程の手戻りを減らせます。
インバウンドネットワーク分離の設定ポイント
インバウンドネットワーク分離では、ユーザーやクライアントがAzure AI Foundryリソースへ接続する経路を制御します。公式ドキュメントでは、パブリックネットワークアクセスを無効にしてプライベートエンドポイントを使う方法、または選択したIPアドレスやネットワークのみを許可する方法が示されています。(Microsoft Learn)
新規リソース作成時の基本手順
新しくFoundryリソースを作成する場合は、次の流れで設計します。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | AzureポータルでFoundryリソースを作成 | リージョン、サブスクリプション、リソースグループを確認 |
| 2 | ネットワーク設定でPublic Network Accessを無効化 | パブリックアクセスを完全に閉じるか、選択ネットワークにするか決める |
| 3 | Private Endpointを追加 | VNetと同じリージョンを選ぶ |
| 4 | 接続先のVNetとサブネットを選択 | IPアドレス枯渇やNSG制限を事前確認 |
| 5 | DNS構成を確認 | privatelinkサブドメインが正しく解決されるか確認 |
Private Endpointの作成時は、ポータル上のターゲットが「account」と表示される場合があるため、Foundryリソースを選択する点にも注意が必要です。(Microsoft Learn)
既存リソースへPrivate Endpointを追加する場合
既存のFoundryリソースやプロジェクトにネットワーク分離を追加する場合も、Private Endpointの追加は可能です。ただし、既存環境での変更は影響範囲を必ず確認してください。
特に、以下のような環境では事前検証が必要です。
| 状況 | 確認すべきこと |
|---|---|
| すでに開発者がパブリック経由で利用している | PNA変更後にアクセスできなくならないか |
| オンプレミスから利用している | VPN、ExpressRoute、名前解決、ルーティングが整っているか |
| 複数プロジェクトで共有している | Private Endpoint削除や変更が他プロジェクトに影響しないか |
| カスタムDNSを使っている | privatelinkサブドメインの委任またはAレコード登録が必要か |
Private Endpointを削除すると、そのエンドポイントに関連付けられた仮想ネットワークからプロジェクトが切り離されます。ただし、削除しただけで自動的にパブリックアクセス可能になるわけではありません。パブリックアクセスを戻すには、別途「All networks」などの設定変更が必要です。(Microsoft Learn)
DNS設定はネットワーク分離の成否を左右する
Azure AI FoundryのPrivate Endpoint設定で最もトラブルになりやすいのがDNSです。公式ドキュメントでは、Private Endpointを使うVNet上のクライアントは、パブリックエンドポイントへ接続する場合と同じ接続文字列を使い、DNS解決によってPrivate Link経由へルーティングされると説明されています。(Microsoft Learn)
つまり、アプリケーション側の接続先文字列を大きく変えるのではなく、名前解決の結果をプライベートIPへ向けることが重要です。
DNS確認で使うコマンド
VNet内のVM、またはVPN/ExpressRouteで接続されたオンプレミスマシンから、次のように確認します。
nslookup <your-foundry-endpoint-hostname>期待する結果は、FoundryエンドポイントがPrivate EndpointのプライベートIPアドレスへ解決されることです。
続いて、ポート443で接続できるか確認します。
Test-NetConnection <private-endpoint-ip-address> -Port 443この確認を行わずにアプリケーション側のエラーだけを見ると、DNS、NSG、Firewall、RBACのどこで詰まっているのか判断しにくくなります。
カスタムDNS利用時の注意点
オンプレミスDNSや独自DNSサーバーを使っている場合は、privatelinkサブドメインをAzure側のプライベートDNSゾーンへ委任するか、DNSサーバー側に必要なAレコードを登録する必要があります。カスタムDNSサーバーが名前解決できない場合は、privatelinkサブドメインの問い合わせをAzure DNSへ転送する構成も確認対象です。(Microsoft Learn)
アウトバウンドネットワーク分離ではBYOリソースが重要
エージェントや評価機能を含めてエンドツーエンドでネットワーク分離したい場合、BYOリソースの設計が重要になります。公式ドキュメントでは、StandardセットアップではエージェントデータがAzureテナント内に留まるよう、Azure Storage、Azure AI Search、Azure Cosmos DBをBYOリソースとして使用する必要があると説明されています。(Microsoft Learn)
BYOリソースとして確認すべきもの
| リソース | 役割 | 確認ポイント |
|---|---|---|
| Azure Storage | エージェント関連データやファイルの保存先 | ネットワーク制限、Private Endpoint、暗号化、RBAC |
| Azure AI Search | 検索・RAG・エージェントツール連携 | パブリックアクセス無効化、Private Endpoint、インデックス権限 |
| Azure Cosmos DB | エージェントデータの保存先 | Private Endpoint、ファイアウォール、キー管理、RBAC |
ここで見落としやすいのは、Foundryリソースをデプロイしても、Azure Storage、Azure AI Search、Azure Cosmos DBへのPrivate Endpointは自動作成されない点です。各リソースのページで個別にPrivate Endpointを作成する必要があります。(Microsoft Learn)
VNetインジェクションを使う場合の設計条件
Agent Serviceや評価クライアントのアウトバウンド通信まで閉域化する場合は、VNetインジェクションを使います。AzureポータルでVNetインジェクションを使ったFoundryリソースを作成するには、BYOリソースを選択し、パブリックネットワークアクセスを無効にしている必要があります。また、サブネットはMicrosoft.App/environmentsに委任され、サイズは/27以上である必要があります。(Microsoft Learn)
VNetインジェクションの事前チェック
| チェック項目 | 確認内容 |
|---|---|
| BYOリソース | Storage、AI Search、Cosmos DBを選択または作成しているか |
| PNA | Public Network AccessをDisabledにしているか |
| サブネット委任 | Microsoft.App/environmentsへ委任しているか |
| サブネットサイズ | /27以上を確保しているか |
| Private Endpoint | Foundry本体だけでなく、BYOリソースにも作成しているか |
| DNS | Foundry、Storage、Search、Cosmos DBの名前解決がプライベートIPになるか |
| ファイアウォール | 必要なFQDNや外部APIの許可ルールを整理しているか |
この段階で「後から変えればよい」と考えるのは危険です。公式ドキュメントでは、現在のところアウトバウンドネットワーク設定を更新できず、既存のFoundryデプロイへ後からアウトバウンドVNetインジェクションを追加することはできないとされています。(Microsoft Learn)
エージェントツールの対応状況と通信経路
ネットワーク分離環境では、すべてのエージェントツールが同じように使えるわけではありません。特に、ツールによって通信経路がVNet、Private Endpoint、Microsoftバックボーン、パブリックエンドポイントに分かれます。公式ドキュメントでは、新しいFoundryポータルまたはSDK/CLIで作成されたResponses APIエージェント向けの対応状況が示されています。(Microsoft Learn)
| ツール | ネットワーク分離環境での対応 | 主な通信経路 | 実務上の注意 |
|---|---|---|---|
| MCP Tool（Private MCP） | 対応 | VNetサブネット経由 | 社内MCPサーバー連携で重要 |
| Azure AI Search | 対応 | Private Endpoint経由 | RAG構成ではPrivate Endpoint必須 |
| Code Interpreter | 対応 | Microsoftバックボーン | 追加のPrivate Endpointは不要 |
| Function Calling | 対応 | Microsoftバックボーン | 関数自体の接続先設計は別途確認 |
| Bing Grounding | 対応 | パブリックエンドポイント | 完全閉域要件では利用可否を審査 |
| Websearch | 対応 | パブリックエンドポイント | インターネット通信を許可しない環境では注意 |
| SharePoint Grounding | 対応 | パブリックエンドポイント | コンプライアンス要件と照合 |
| Foundry IQ | 対応、プレビュー | MCP経由 | プレビュー機能として扱う |
| OpenAPI tool | 対応 | VNetサブネット経由 | API側のプライベート到達性が必要 |
| Azure Functions | 対応 | VNetサブネット経由 | Functions側のネットワーク制限も確認 |
| Agent-to-Agent（A2A） | 対応 | VNetサブネット経由 | エージェント間連携の経路設計が必要 |
| Fabric Data Agent | 非対応 | 対象外 | Fabric側にパブリックアクセス要件あり |
| Logic Apps | 非対応 | 開発中 | 代替手段を検討 |
| File Search | 非対応 | 開発中 | RAG用途ではAzure AI Search連携を検討 |
| Browser Automation | 非対応 | 開発中 | 業務自動化用途では注意 |
| Computer Use | 非対応 | 開発中 | 本番採用前に対応状況を確認 |
| Image Generation | 非対応 | 開発中 | 画像生成を含むエージェントでは設計見直し |
Bing Grounding、Websearch、SharePoint Groundingはネットワーク分離環境でも動作しますが、通信はパブリックエンドポイント経由です。組織の要件が「すべてのトラフィックをプライベートネットワーク内に収める」場合、これらのツールは要件を満たさない可能性があります。(Microsoft Learn)
信頼されたAzureサービスの例外設定も確認する
Foundryプロジェクトでネットワークアクセスを制限している場合、一部の信頼されたAzureサービスに対してネットワークルール例外を作成できます。対象サービスはマネージドIDで認証し、適切なロール割り当てを持っている必要があります。(Microsoft Learn)
| サービス | リソースプロバイダー名 |
|---|---|
| Foundry Tools | Microsoft.CognitiveServices |
| Azure AI Search | Microsoft.Search |
| Azure Machine Learning | Microsoft.MachineLearningServices |
ここで重要なのは、ネットワーク例外だけでなく、マネージドIDのRBACもセットで確認することです。ネットワーク的には許可されていても、IDに権限がなければ403エラーなどが発生します。
ファイアウォール許可リストで確認すべきFQDN
VNetインジェクションを使い、Azure Firewallなどでエグレス通信を制御する場合は、Foundryのシナリオに応じてFQDN許可リストを整備する必要があります。公式ドキュメントでは、エージェント、評価とトレース、ファインチューニングで使うFQDN例が示されています。(Microsoft Learn)
| シナリオ | 許可が必要なFQDN例 | 用途 |
|---|---|---|
| Agents | *.identity.azure.net、login.microsoftonline.com、*.login.microsoftonline.com、*.login.microsoft.com | Agent Serviceの委任や認証 |
| Evaluations & Traces | *.blob.core.windows.net、settings.sdk.monitor.azure.com | 評価カタログやApplication Insightsへの結果送信 |
| Finetuning | raw.githubusercontent.com | Foundryポータルでキュレーション済みサンプルデータセットを選ぶ場合 |
許可リストを作るときは、「公式ドキュメントにあるFQDNをそのまま入れる」だけでは不十分です。実際のアプリケーションが外部API、社内API、MCPサーバー、監視基盤へ接続する場合、それぞれの宛先、ポート、認証方式も棚卸ししてください。
機能制限と移行時の注意点
Azure AI Foundryのネットワーク分離は強力ですが、すべての機能が完全対応しているわけではありません。公式ドキュメントでは、評価用の合成データ生成やトレースはネットワーク分離未対応、Workflow AgentsやAI Gatewayは部分対応とされています。(Microsoft Learn)
| 機能・構成 | 状態 | 注意点 |
|---|---|---|
| 評価用の合成データ生成 | 未対応 | 評価には独自データの持ち込みを検討 |
| Traces | 未対応 | プライベートApplication InsightsでのVNetサポートに注意 |
| Workflow Agents | 部分対応 | インバウンドは対応、アウトバウンドVNetインジェクションは未対応 |
| AI Gateway（APIM） | 部分対応 | 新しいFoundryポータルで作成したゲートウェイは自動的にパブリックになる点に注意 |
| Private AI SearchをAgent toolで利用 | 条件付き | 新しいFoundryポータルで新規エージェントを作成する必要がある |
| Teams/M365へのエージェント発行 | 追加設定が必要 | パブリックアクセス無効環境でも可能だが追加セットアップが必要 |
| Hosted AgentsとPrivate ACR | 制限あり | Private Endpoint付きでPNA無効のAzure Container Registryは現時点で未対応 |
| アウトバウンドネットワーク変更 | 制限あり | 既存環境へ後からVNetインジェクションを追加できない |
既存のAzure AI Foundry環境を運用している場合、移行判断は次のように分けると整理しやすくなります。
| 現在の状況 | 推奨される判断 |
|---|---|
| ユーザーのアクセス経路だけを閉じたい | 既存リソースへPrivate Endpointを追加し、DNSとPNAを調整 |
| エージェントのデータ保存先を自社テナントに明確化したい | BYO Storage、BYO AI Search、BYO Cosmos DB構成を検討 |
| エージェントのアウトバウンドも閉域化したい | 新規構築または再デプロイを前提にVNetインジェクションを設計 |
| パブリック検索系ツールを禁止したい | Azure Policyや組織ルールでツール利用を制御 |
| 既存Agentをクラシックポータルで作成している | 新しいFoundryポータルまたはSDK/CLIベースの移行を検討 |
よくあるトラブルと切り分け方法
ネットワーク分離のトラブルは、原因がネットワーク、DNS、権限、サブネット設計に分かれます。症状だけで判断せず、順番に切り分けることが重要です。
| 症状 | 主な原因 | 確認する場所 | 対応 |
|---|---|---|---|
| Private EndpointがPendingのまま | Foundryリソースへの承認権限がない | Private endpoint connections | ContributorまたはOwnerに承認してもらう |
| Private Endpoint作成に失敗 | VNetまたはサブネットへの権限不足、IP不足 | IAM、サブネット | Network Contributor権限と空きIPを確認 |
| DNSがパブリックIPを返す | Private DNS Zone未作成、VNetリンク漏れ | Private DNS Zone、VNet link | privatelinkゾーンとAレコードを確認 |
| ポート443でタイムアウト | NSGまたはFirewallで遮断 | NSG、Azure Firewall | Private Endpoint IPへの443アウトバウンドを許可 |
| オンプレミスから到達できない | VPN/ExpressRoute、ルート設定、DNS不備 | VPN、ExpressRoute、UDR、DNS | VNetアドレス空間への経路と名前解決を確認 |
| 403 Forbidden | 認証・認可の問題 | RBAC、マネージドID | Foundryプロジェクトへの適切なロールを付与 |
| Agentが起動しない | Basic構成、VNetインジェクション不備、IP不足 | Agent構成、サブネット | Standard Agent、委任済みサブネット、空きIPを確認 |
| MCPツールに接続できない | 接続先AzureサービスのPrivate Endpoint不足 | MCP、対象サービス | すべての依存サービスにPrivate EndpointとRBACを設定 |
| 外部API呼び出しがタイムアウト | ファイアウォールで外部HTTPSが未許可 | Firewall、NAT Gateway | 宛先FQDNまたはNAT Gateway構成を確認 |
公式ドキュメントでも、403 Forbiddenはネットワークではなく認証の問題を示すことが多いとされています。ネットワーク分離後にエラーが出た場合でも、DNSやFirewallだけでなくRBACも必ず確認してください。(Microsoft Learn)
本番展開前のチェックリスト
Azure AI Foundryのネットワーク分離を本番展開する前に、次の項目を確認してください。
| チェック | 確認内容 |
|---|---|
| 設計方針 | 完全閉域か、選択IP許可か、パブリックツールを許容するか |
| PNA | Public Network AccessをDisabledまたはSelected networksにしているか |
| Private Endpoint | Foundry本体、Storage、AI Search、Cosmos DBに必要なPrivate Endpointを作成したか |
| DNS | VNet内からFoundryエンドポイントがプライベートIPへ解決されるか |
| RBAC | Foundry、VNet、Private DNS Zone、BYOリソースへの権限が揃っているか |
| Agent構成 | Standard Agentか、Basic構成ではないか |
| VNetインジェクション | /27以上の委任済みサブネットを用意しているか |
| ツール利用 | Bing/Websearch/SharePointなどのパブリック通信を許容するか |
| Firewall | 必要なFQDN、外部API、社内APIを許可しているか |
| 移行計画 | 既存環境で再デプロイが必要か判断したか |
| 検証 | nslookup、Test-NetConnection、Agent起動、RAG検索、外部連携を確認したか |
本番環境では、開発者の手元端末から直接アクセスするより、VNet内の開発用VM、Azure Bastion、VPN、ExpressRouteなどを組み合わせるほうが運用しやすい場合があります。公式ドキュメントでも、パブリックネットワークアクセスを無効にしたFoundryへ接続する方法として、Azure Virtual Network Gateway、ExpressRoute、Azure Bastion VMが挙げられています。(Microsoft Learn)
まず何をすべきか
Azure AI Foundryのネットワーク分離を検討している場合、最初に行うべきことは、現在または予定しているAIアプリケーションの通信経路を洗い出すことです。
具体的には、次の順番で確認すると実務に落とし込みやすくなります。
| 優先度 | 作業 | 目的 |
|---|---|---|
| 高 | Foundryへ誰がどこからアクセスするかを整理 | インバウンド設計を決める |
| 高 | エージェントが使うデータソースとツールを一覧化 | アウトバウンド設計を決める |
| 高 | BYOリソースの要否を判断 | データ保存先とコンプライアンス要件を満たす |
| 中 | Private EndpointとDNS設計を作る | 閉域接続を成立させる |
| 中 | 既存環境で再デプロイが必要か判断 | 移行コストと停止リスクを把握する |
| 中 | ツールごとの通信経路をレビュー | パブリック通信の見落としを防ぐ |
| 低 | 運用時のトラブルシューティング手順を文書化 | 障害対応を短縮する |
Azure AI Foundryのネットワーク分離は、セキュリティ設定というよりも、AI基盤全体のアーキテクチャ設計です。Private Link、BYOリソース、VNetインジェクション、DNS、RBAC、エージェントツールの対応状況をまとめて確認し、既存環境では「後付けできる範囲」と「再デプロイが必要な範囲」を切り分けてから作業を始めることが重要です。
コメント