Microsoft Foundry / Azure OpenAIのネットワーク分離は、Private Endpointを作れば完了という単純な話ではなくなっています。2026年4月下旬に確認されたMicrosoft公式ドキュメント「How to configure network isolation for Microsoft Foundry」では、受信アクセス、送信アクセス、Agent ServiceのVNet injection、BYOリソース、DNS、ツール別の通信経路まで含めて設計する必要があることが明確に整理されています。(Microsoft Learn)
結論から言うと、IT管理者やプロダクトオーナーが最初に確認すべきポイントは3つです。Foundry本体への受信はPrivate Endpointで閉じる、Agent Serviceの送信はVNet injectionで制御する、Storage、Azure AI Search、Cosmos DBなどのBYOリソースも個別にPrivate EndpointとDNSを設計することです。Azure OpenAIからMicrosoft Foundryへ拡張・移行する環境では、既存のOpenAIエンドポイントだけでなく、Foundry機能で使う追加FQDNやDNSゾーンも見落とさないようにしましょう。(Microsoft Learn)
Microsoft Foundry / Azure OpenAIのネットワーク分離で何が重要になったか
Microsoft Foundryは、Azure OpenAIだけでなく、モデル、エージェント、ツール、評価、監視などをまとめて扱うAzure上のエンタープライズAI基盤です。Microsoft公式ドキュメントでは、Microsoft Foundryを「enterprise AI operations、model builders、application development」のための統合PaaSとして説明しており、RBAC、ネットワーク、ポリシーを1つの管理単位で扱う方向に整理されています。(Microsoft Learn)
そのため、ネットワーク分離もAzure OpenAI単体の時代より考える範囲が広がります。従来は「Azure OpenAIのパブリックアクセスを無効化し、Private Linkで接続する」ことが主な論点でした。しかしFoundryでは、Agent ServiceがAzure AI SearchやStorage、Cosmos DB、外部ツール、MCP、Azure Functionsなどにアクセスするケースが増えます。
つまり、これからの設計では次のように考える必要があります。
| 観点 | 旧来のAzure OpenAI中心の設計 | Microsoft Foundryで必要な設計 |
|---|---|---|
| 保護対象 | Azure OpenAIリソース | Foundry account、project、Agent Service、接続先データソース、ツール |
| 受信制御 | Private Endpoint、Public network access | Private Endpoint、PNA、Selected networks |
| 送信制御 | 比較的限定的 | Agent clientのVNet injection、Firewall、Private Link |
| データ保存先 | 主にサービス側の設定確認 | BYO Storage、Azure AI Search、Cosmos DBの設計が重要 |
| DNS | OpenAI系エンドポイント中心 | Foundry、OpenAI、Cognitive Services、services.ai.azure.com系の名前解決を確認 |
| 運用リスク | 接続不可、RBAC不足 | ツール別通信経路、DNS不整合、Agent起動失敗、外部API遮断 |
ポイントは、Foundryのネットワーク分離は「入口を閉じる」だけでは不十分ということです。AIエージェントが社内データやAzure PaaSにアクセスするなら、出口、名前解決、認証、権限、ツールの対応状況までセットで設計する必要があります。
更新ポイントの要約：読むべき箇所はここ
Microsoft公式記事「How to configure network isolation for Microsoft Foundry」で特に重要なのは、次の5点です。
| 更新・注目ポイント | 実務での意味 |
|---|---|
| ネットワーク分離を3領域で整理 | 受信、Foundryからの送信、Agent clientからの送信を分けて考える必要がある |
| BYOリソースの重要性 | Storage、Azure AI Search、Cosmos DBを自社Azureテナント内に用意する前提が強まる |
| VNet injectionの明記 | Agent Serviceや評価クライアントの送信経路を顧客管理VNetに入れる設計が必要 |
| ツール別の通信経路 | MCP、Azure AI Search、Code Interpreter、Bing Groundingなどで経路が異なる |
| 制限事項とトラブルシュートの充実 | DNS、Pending状態、403、Agent起動失敗など、実装時の落とし穴が明文化された |
Microsoft公式記事では、ネットワーク分離を「Microsoft Foundryリソースへの受信」「Microsoft Foundryリソースからの送信」「Agent clientから依存先への送信」の3つに分けて説明しています。特に3つ目のAgent clientの送信制御は、生成AIアプリや社内データ連携エージェントを本番展開する組織にとって重要です。(Microsoft Learn)
受信アクセスはPrivate EndpointとPublic network accessで制御する
Microsoft Foundryリソースへの受信アクセスは、Public network access、Private Endpoint、Selected networksの組み合わせで設計します。公式ドキュメントでは、PNAフラグによってプロジェクトがPrivate Endpointを必要とするかどうかを制御でき、Selected IP addressesによる中間的なアクセス制御も説明されています。(Microsoft Learn)
実務では、次のように判断すると分かりやすくなります。
| 要件 | 推奨設定の考え方 |
|---|---|
| 社内ネットワーク、VPN、ExpressRoute経由に限定したい | Public network accessをDisabledにし、Private Endpointを使う |
| 一部の管理端末や固定IPからのみ許可したい | Selected networksまたはIP制限を検討する |
| 検証環境で一時的に広く接続したい | All networksを使う場合でも期間と対象を限定する |
| 金融、医療、製造など厳格なデータ管理が必要 | 原則としてPrivate Endpoint前提で設計する |
Private Endpointを追加する場合は、Azure portalでFoundryリソースのNetworkingからPrivate endpoint connectionsを開き、対象VNetとサブネットを指定します。このとき、Private EndpointはVNetと同じリージョンを選ぶ必要があります。権限が不足している場合、接続はApprovedではなくPendingのままになり、通信できません。(Microsoft Learn)
受信アクセス設計でよくある失敗
受信側で多い失敗は、Private Endpointを作っただけで接続確認を終えてしまうことです。Private Endpointが存在していても、DNSがパブリックIPを返していれば、クライアントは意図したプライベート経路を使いません。
最低限、次の確認を行いましょう。
nslookup <your-foundry-endpoint-hostname>
Test-NetConnection <private-endpoint-ip-address> -Port 443VNet内のVM、またはVPNやExpressRouteで接続されたオンプレミス端末から名前解決し、FoundryのエンドポイントがPrivate EndpointのプライベートIPに解決されることを確認します。公式ドキュメントでも、Private Endpoint接続がApprovedであること、VNet内からDNSがプライベートIPを返すこと、443番ポートで接続できることを検証手順として示しています。(Microsoft Learn)
送信アクセスはVNet injectionが中心になる
今回の更新で実務上もっとも重要なのは、Agent Serviceの送信経路です。Microsoft Foundryでは、Agent clientを顧客管理のVNetサブネットに注入するVNet injectionにより、Azure PaaSリソースやプライベートデータソースへの送信通信を顧客定義のネットワーク境界内に保つ設計が説明されています。(Microsoft Learn)
これは、社内文書検索、RAG、業務システム連携、MCPツール、Azure Functions連携などを行うAIエージェントでは特に重要です。エージェントが実行時にどこへ通信するのかを制御できなければ、Private EndpointでFoundry本体を守っていても、実際のデータアクセス経路が期待とずれる可能性があります。
VNet injectionを使うための主な条件
公式ドキュメントでは、FoundryリソースをVNet injection付きで作成するには、BYO VNetを使う方法やBicep、Terraformによる作成が説明されています。Azure portalで設定する場合、StorageタブでAgent Service用にStorage、Azure AI Search、Azure Cosmos DBを選択し、NetworkタブでPublic accessをDisabledにしたうえでPrivate Endpointを追加します。その後、VNet injectionのドロップダウンからVNetとサブネットを選びます。(Microsoft Learn)
特に注意すべき条件は次の通りです。
| 条件 | 内容 |
|---|---|
| BYOリソース | Azure Storage、Azure AI Search、Azure Cosmos DBが必要 |
| Public network access | Disabledが前提 |
| サブネット委任 | Microsoft.App/environmentsへの委任が必要 |
| サブネットサイズ | 公式記事では/27以上が必要と説明。Agent Serviceの詳細記事では/24推奨も示されている |
| Private Endpoint | Foundry本体だけでなく、Storage、Search、Cosmos DB側にも個別に作成する |
| DNS | 各Private Link対象のPrivate DNS ZoneをVNetにリンクする |
ここで重要なのは、Foundryリソースを作成してもAzure AI Search、Azure Storage、Azure Cosmos DBのPrivate Endpointは自動作成されない点です。公式ドキュメントでも、これらのリソースのPrivate Endpointは各リソース側で個別に作成する必要があると明記されています。(Microsoft Learn)
BYOリソースはコンプライアンス設計の中心になる
Microsoft Foundry Agent Serviceの標準セットアップでは、エージェントデータを自社Azureテナント内に保持するためにBYOリソースが求められます。対象にはAzure Storage、Azure AI Search、Azure Cosmos DBが含まれ、Foundry Agent Serviceで処理されるデータはこれらのリソースに保存されると説明されています。(Microsoft Learn)
プロダクトオーナー視点では、これは単なるインフラ要件ではありません。次のような判断に直結します。
| 判断項目 | 確認すべきこと |
|---|---|
| データ保存場所 | 顧客データ、会話履歴、検索インデックス、ファイルがどのリソースに保存されるか |
| 監査 | Storage、Search、Cosmos DBのログ取得と保持方針 |
| 権限 | Agent Service、開発者、運用者に必要最小限のRBACを付与しているか |
| 暗号化 | Microsoft-managed keyで十分か、CMK要件があるか |
| リージョン | Foundry、VNet、関連PaaSのリージョンとデータ転送コスト |
| 削除 | プロジェクト削除時に関連リソースやデータをどう扱うか |
特にRAG構成では、Azure AI Searchのインデックスに機密文書の一部が格納される場合があります。アプリケーション側のプロンプトやレスポンスだけでなく、検索インデックス、Blob Storage、Cosmos DBのスレッド情報も含めてデータ分類を行うべきです。
DNS設計は最初に詰めるべき
Microsoft Foundry / Azure OpenAIのネットワーク分離で、実装時にもっともつまずきやすいのがDNSです。Private Endpointを作成すると、Azureはprivatelinkサブドメインに対応するCNAMEやPrivate DNS Zoneを使って、VNet内からの名前解決をPrivate EndpointのIPへ誘導します。VNet外から解決した場合はパブリックエンドポイントに解決されるため、接続元によって結果が変わります。(Microsoft Learn)
カスタムDNSやオンプレミスDNSを使っている企業では、privatelinkサブドメインをAzure Private DNS Zoneへ委任する、またはDNSサーバー側にAレコードや条件付きフォワーダーを設定する必要があります。Agent ServiceのPrivate networking記事では、Foundry account、Azure AI Search、Cosmos DB、Azure Storageに対応するPrivate DNS Zoneと、Azure DNS Virtual Server IP 168.63.129.16への条件付きフォワーダーが整理されています。(Microsoft Learn)
Azure OpenAIからFoundryへアップグレードする場合のDNS注意点
Azure OpenAIリソースをMicrosoft Foundryへアップグレードする場合、既存のAPIエンドポイントやAPIキー、ネットワーク構成は保持されると説明されています。一方で、Foundryのすべての機能を使うには、既存のAzure OpenAI DNS Zoneに加えて追加のDNSゾーン構成が必要になります。(Microsoft Learn)
公式ドキュメントでは、Foundryリソースが次の3つのFQDNで機能を公開すると説明されています。
{custom-domain}.openai.azure.com
{custom-domain}.services.ai.azure.com
{custom-domain}.cognitiveservices.azure.comまた、Foundryへアップグレードする場合、services.ai.azure.comやcognitiveservices.azure.com側のIP構成を作成するため、Private Link Endpointの再作成が必要になる場合があります。Azure OpenAI時代のPrivate Endpointがあるから大丈夫、と判断しないようにしてください。(Microsoft Learn)
Agent toolsは「使えるか」だけでなく「どこを通るか」を確認する
Microsoft Foundryのネットワーク分離では、Agent toolsの対応状況と通信経路を確認することが欠かせません。公式ドキュメントでは、ネットワーク分離環境でサポートされるツールと、VNet、Private Endpoint、Microsoft backbone network、Public endpointのどれを通るかが整理されています。(Microsoft Learn)
代表的な分類は次の通りです。
| ツール | サポート状況 | 主な通信経路 | 実務上の判断 |
|---|---|---|---|
| MCP Tool / Private MCP | 対応 | VNetサブネット | 社内APIや業務ツール連携に向く |
| Azure AI Search | 対応 | Private Endpoint | RAG構成で重要。Search側のPrivate Endpoint必須 |
| Code Interpreter | 対応 | Microsoft backbone network | 追加Private Endpoint不要だが、組織の基準に合わせて確認 |
| Function Calling | 対応 | Microsoft backbone network | 関数実体の到達経路は別途設計 |
| Bing Grounding | 対応 | Public endpoint | 完全閉域要件では注意 |
| Websearch | 対応 | Public endpoint | インターネット通信を許容するか判断 |
| SharePoint Grounding | 対応 | Public endpoint | Microsoft 365側の制御と合わせて確認 |
| OpenAPI tool | 対応 | VNet | 社内APIを閉域化したい場合に有効 |
| Azure Functions | 対応 | VNet | Functions側のPrivate Endpointや認証も設計 |
| Fabric Data Agent | 非対応 | 開発中 | 現時点では本番閉域要件に組み込みにくい |
| File Search | 非対応 | 開発中 | 代替としてAzure AI Search構成を検討 |
| Image Generation | 非対応 | 開発中 | 閉域必須のユースケースでは採用前に確認 |
注意すべきなのは、Bing Grounding、Websearch、SharePoint Groundingはネットワーク分離環境でも動作しますが、Public endpointを使う点です。公式ドキュメントでも、すべての通信をプライベートネットワーク内に維持する必要がある組織では、これらのツールがコンプライアンス要件を満たさない可能性があると説明されています。(Microsoft Learn)
推奨アーキテクチャ：まずは用途別に分けて考える
Microsoft Foundry / Azure OpenAIのネットワーク分離は、すべての環境で同じ構成にする必要はありません。重要なのは、ユースケースのリスクと運用負荷に応じて段階を分けることです。
| ユースケース | 推奨構成 |
|---|---|
| 個人・小規模検証 | Public accessを許可した検証環境。ただし本番データは使わない |
| 社内PoC | Selected networksまたはPrivate Endpoint。DNS検証を必ず行う |
| RAG本番環境 | Foundry、Storage、Azure AI Search、Cosmos DBをPrivate Endpoint化 |
| AIエージェント本番環境 | Standard Agent、BYOリソース、VNet injection、Firewallを組み合わせる |
| 厳格な閉域要件 | Public endpointツールを制限し、MCP、Private Link、Azure Functionsなど閉域経路を優先 |
| Azure OpenAIから移行 | 既存Private Linkだけでなく、Foundry用FQDNとDNSゾーンを再確認 |
実務では、最初から全機能を有効化するより、ネットワーク境界を守れるツールから段階的に採用するほうが安全です。たとえば、社内ナレッジ検索を行うなら、WebsearchやBing Groundingを最初から有効にするのではなく、Azure AI SearchとPrivate Endpointを使ったRAG構成から始めると、データフローを説明しやすくなります。
導入手順：本番前に確認する流れ
Microsoft Foundryのネットワーク分離を本番導入する場合、次の順番で進めると手戻りを減らせます。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | ユースケースを分類 | チャット、RAG、Agent、外部API連携のどれか |
| 2 | データ分類 | 機密情報、個人情報、顧客データの有無 |
| 3 | ネットワーク方針を決定 | Public無効、Selected networks、Private Endpointの選択 |
| 4 | BYOリソースを設計 | Storage、Azure AI Search、Cosmos DBのリージョンと権限 |
| 5 | VNetとサブネットを設計 | Agent用サブネット、Private Endpoint用サブネットを分ける |
| 6 | DNSを設計 | Private DNS Zone、条件付きフォワーダー、オンプレDNS連携 |
| 7 | Foundryを作成 | Public access Disabled、Private Endpoint、VNet injectionを設定 |
| 8 | 関連PaaSをPrivate Endpoint化 | Search、Storage、Cosmos DB側も個別に設定 |
| 9 | Agent toolsを選定 | Public endpointを使うツールを許可するか判断 |
| 10 | 接続検証 | nslookup、Test-NetConnection、Agent実行テスト |
| 11 | 監査と運用設計 | ログ、RBAC、Azure Policy、変更管理を整備 |
この順番で進める理由は、ネットワーク分離の失敗がアプリ開発の後半で発覚すると、設計変更の影響が大きくなるためです。特にDNSとPrivate Endpointは、アプリコードではなくインフラ側の問題として見えますが、実際にはエージェント実行や検索、ファイル取得に直接影響します。
IT管理者が押さえるべきチェックリスト
本番化前には、次のチェックリストを使って確認してください。
| チェック項目 | OKの基準 |
|---|---|
| Public network access | 本番環境ではDisabledまたはSelected networksで管理されている |
| Private Endpoint状態 | Foundryと関連PaaSの接続がApprovedになっている |
| DNS解決 | VNet内からFoundry、Search、Storage、Cosmos DBがプライベートIPに解決される |
| BYOリソース | Storage、Azure AI Search、Cosmos DBが自社テナント内で管理されている |
| Agentサブネット | Microsoft.App/environmentsに委任され、十分なIPアドレスがある |
| RBAC | 開発者、運用者、マネージドIDに必要最小限の権限が付与されている |
| ツール通信経路 | Public endpointを使うツールの利用可否が承認されている |
| Firewall | 外向き通信の許可先、TLS inspection、ブロックログを確認済み |
| Azure OpenAI移行 | Foundry用FQDNとPrivate Link Endpoint再作成要否を確認済み |
| 障害時対応 | DNS、443番ポート、403、Pending状態、Agent起動失敗の切り分け手順がある |
特に、Private EndpointがPendingのまま、DNSがパブリックIPを返す、403をネットワーク障害と誤認する、という3つは現場で起きやすいミスです。403 Forbiddenはネットワークではなく認証・RBACの問題であることが多いため、ネットワークログだけでなく権限設定も確認しましょう。公式ドキュメントでも、403は認証問題を示すことが多いと説明されています。(Microsoft Learn)
プロダクトオーナーが判断すべきポイント
プロダクトオーナーは、ネットワーク分離を単なるセキュリティ部門の作業と考えないほうがよいです。どのツールを使うか、どのデータに接続するか、外部検索を許可するかは、プロダクト仕様そのものに影響します。
たとえば、次のような判断が必要です。
| 判断 | ビジネス上の影響 |
|---|---|
| Websearchを許可するか | 最新情報を扱えるが、Public endpoint通信が発生する |
| SharePoint Groundingを使うか | Microsoft 365データ活用が進むが、アクセス制御と監査が重要 |
| Azure AI Search中心にするか | 閉域RAGを作りやすいが、インデックス設計と運用が必要 |
| MCPで社内API連携するか | 業務自動化に強いが、APIの認証・認可・監査設計が必要 |
| Hosted agentsを使うか | 柔軟性は高いが、ネットワーク制限やContainer Registry要件を確認する必要がある |
AIエージェントは、単に質問に答えるだけでなく、検索、ファイル参照、API実行、関数呼び出しを行います。そのため、プロダクト要件定義の段階で「どの通信を許可するか」「どのデータに触れるか」「監査ログをどこに残すか」を決めておく必要があります。
トラブルシュート：よくある症状と原因
ネットワーク分離後に接続できない場合は、症状ごとに切り分けると解決が早くなります。
| 症状 | 主な原因 | 確認方法 |
|---|---|---|
| Private EndpointがPending | Foundry側の承認権限不足 | Private endpoint connectionsで状態を確認 |
| 名前解決がパブリックIPになる | Private DNS Zone未リンク、条件付きフォワーダー不足 | VNet内からnslookup |
| 443番ポートで接続できない | NSG、Firewall、ルーティングの問題 | Test-NetConnection、Firewallログ |
| Agentが起動しない | Basic Agentを使っている、VNet injection未設定、IP不足 | Standard Agent構成とサブネット確認 |
| Azure AI Searchに接続できない | Search側Private Endpoint未作成、DNS不整合、RBAC不足 | SearchのPrivate EndpointとManaged Identity確認 |
| 403 Forbidden | ネットワークではなく認証・権限不足の可能性 | RBAC、Entra ID、マネージドID確認 |
| 外部API呼び出しがタイムアウト | Firewallで外向きHTTPSが遮断 | 許可先FQDN、NAT、Firewallログ確認 |
Agent Serviceの詳細ドキュメントでは、Private Endpoint DNS解決に失敗する場合、各Private DNS ZoneがVNetにリンクされているか、条件付きフォワーダーがAzure DNS Virtual Server IP 168.63.129.16を向いているかを確認するよう説明されています。(Microsoft Learn)
2026年4月更新を踏まえた実務上の結論
Microsoft Foundry / Azure OpenAIのネットワーク分離は、今後のエンタープライズAI基盤で避けて通れないテーマです。今回の公式ドキュメント更新で明確になったのは、Private Endpointだけではなく、VNet injection、BYOリソース、DNS、Agent toolsの通信経路まで含めた総合設計が必要だという点です。
まず取り組むべきことは、現在のAzure OpenAIまたはFoundry環境を棚卸しすることです。Public network accessの状態、Private Endpoint、DNS、BYOリソース、Agent Serviceの利用有無、ツールごとの通信経路を確認してください。Azure OpenAIからFoundryへアップグレード済み、またはアップグレード予定の環境では、既存のOpenAI用DNSだけでなく、Foundryで追加されるFQDNとPrivate Link構成も必ず見直しましょう。
実務では、次の順番で進めるのが現実的です。
- 本番データを扱うFoundry / Azure OpenAI環境を特定する
- Public network accessをどう制御するか決める
- Foundry本体とBYOリソースのPrivate Endpointを設計する
- VNet injectionが必要なAgentユースケースを切り分ける
- DNSとFirewallを先に検証する
- Agent toolsを通信経路ごとに許可・禁止する
nslookup、443番ポート、Agent実行まで含めて運用テストする
「AIを使えるようにする」だけなら設定は簡単に見えます。しかし、業務データを安全に扱い、監査やコンプライアンスに耐えるMicrosoft Foundry環境を作るには、ネットワーク分離をアーキテクチャの初期段階で設計することが重要です。
コメント