はじめに
Microsoft Foundry（旧 Azure AI Foundry）で PoC を作るだけなら、ポータルから数クリックでモデルもエージェントも動きます。しかし「社内の本番環境に載せる」となった瞬間に、ネットワーク分離・ID・データ保存先・クォータ・監視といったインフラ側の論点が一気に噴出します。しかも Foundry はエージェント実行基盤がプラットフォーム管理型のため、従来の IaaS 的な感覚（VM を並べて VNet に置く）とは考え方がかなり違います。
この記事では、Cloud Solution Architect として顧客と設計レビューをするときに毎回論点になるポイントを、インフラ観点に絞って 整理します。アプリ実装やプロンプト設計の話は扱いません。
対象読者: 情報システム部門 / クラウド基盤担当 / セキュリティ担当、および Foundry を本番展開しようとしているアーキテクト
前提: Azure の VNet・Private Endpoint・RBAC の基礎知識があること
情報時点: 2026年9月時点。Foundry は更新が非常に速いため、実装前に必ず公式ドキュメントの最新版を確認してください
0. まず前提となるリソースモデルを理解する
インフラ設計の議論が噛み合わない原因の多くは、「何が Foundry の管理境界で、何が別リソースなのか」が共有されていないことにあります。
Foundry は次の 3 層構造です。
レイヤー 役割 インフラ的な意味
Foundry リソース 最上位の Azure リソース。ネットワーク、セキュリティ、モデルデプロイなどのガバナンス設定を持つ ここが「IT 部門が握る」境界
プロジェクト Foundry リソース内の開発境界。チーム単位でエージェント・評価・ファイルを分離 ここが「開発チームが動く」境界
接続リソース Storage / Key Vault / Azure AI Search など、接続経由で参照する Azure サービス 独立した Azure リソース。ネットワークもアクセスポリシーも別管理
リソースプロバイダーは Microsoft.CognitiveServices/accounts（種類は AIServices）、プロジェクトは Microsoft.CognitiveServices/accounts/projects です。Azure OpenAI や Speech / Vision / Language と同じプロバイダー名前空間を共有しているため、既存の Azure Policy や RBAC のカスタムロールがそのまま効くのは移行時の大きなメリットです。
最大の落とし穴: Storage / Key Vault / AI Search を「Foundry の一部」と誤解して、Foundry 側だけネットワークを閉じて満足してしまうケース。接続リソースは独自のガバナンス境界を持つため、Private Endpoint も RBAC も個別に設計・実装が必要です。
- リージョンと機能可用性
Foundry は「リージョンによって使える機能が違う」サービスです。ここを詰めずにランディングゾーンのリージョンを決めると、後から詰みます。
チェックすべき軸は 3 つ。
モデルの可用性 — 使いたいモデルがそのリージョンにあるか
デプロイの種類のオプション — 後述の Global / DataZone / Regional のうち、どれが選べるか
機能のサポート — エージェント、評価などが対象リージョンで利用可能か
日本の顧客だと Japan East を第一候補にしつつ、最新モデルが来ていないため一部ワークロードだけ別リージョンに逃がす、という構成になりがちです。その場合は後述のデータ所在地とセットで整理してください。
- モデルデプロイの種類とデータ所在地
Foundry のデプロイ種別は「データ処理がどこで行われるか」でグループ化されています。ここはセキュリティ部門への説明で必ず聞かれるところです。
処理スコープ デプロイの種類 課金
リージョン横断（Azure 管理） グローバル標準 / グローバル プロビジョニング済み / グローバル バッチ 従量、時間単位の予約容量、バッチ価格
データゾーン境界内 データゾーン標準 / プロビジョニング済みデータゾーン / データゾーン バッチ 同上
単一リージョン Standard / リージョン プロビジョニング済み 同上
任意のリージョン（データ所在地保証なし） Developer 従量。ファインチューニング済みモデルの評価用途、24 時間の有効期間、SLA なし
ポイントは以下です。
保存データは指定した Azure の地域に格納される
**推論データ（プロンプトと応答）**の扱いはデプロイ種別に依存する。グローバルは任意のリージョンにルーティングされうる、データゾーンは米国または EU のゾーン内に留まる、Standard / リージョンはデプロイリージョンで処理される
Developer デプロイは SLA がないので、本番ワークロードには使わない
「日本国内で処理を完結させたい」という要件が出た場合、グローバルデプロイは選択肢から外れ、スループットとレイテンシの前提が変わります。要件定義の最初期に確認すべき論点です。
- 可用性設計（ここが一番の注意点）
Foundry はリージョン間の自動フェールオーバーをサポートしません。
マルチリージョン可用性が必要な場合は、
ターゲットリージョンごとに個別の Foundry リソースをデプロイする
データの同期とルーティングはアプリケーション層で自前実装する
という設計になります。PaaS だから勝手に冗長化されている、という思い込みは危険です。「AI 基盤の RTO / RPO をどう定義するか」を、他システムと同じ土俵で議論しておきましょう。実務的には Azure API Management や Front Door を前段に置き、リージョン間のルーティングとフォールバックを担わせる構成がよく取られます。
- ネットワーク分離
Foundry のネットワーク分離は、インバウンドとアウトバウンドを分けて考えるのが鉄則です。
4-1. インバウンド（誰が Foundry に入ってくるか）
Public Network Access（PNA）フラグで制御します。選択肢は 3 つ。
有効（すべてのネットワーク） — 検証環境向け
選択したネットワーク — 指定 IP アドレス / VNet からのみ許可。中間的な落としどころ
無効 + Private Endpoint — 完全プライベート。エンタープライズの標準形
PNA を無効にした場合、Foundry ポータルへの到達経路も必要になります。VPN（P2S / S2S）、ExpressRoute、または VNet 内の踏み台 VM + Azure Bastion のいずれかを用意してください。「作ったけど誰も繋げない」は初期構築でよくある事故です。
補足: すべてのパブリックアクセスをブロックする構成は、ポータル UI からは設定できません。 SDK / CLI / Bicep / Terraform で構成する必要があります。IaC 前提で設計しましょう。
4-2. アウトバウンド（Foundry から外に出ていくトラフィック）
ここが従来の Azure Machine Learning と大きく違うところです。Foundry ではトレーニング用の IaaS コンピューティングを顧客が管理しません。代わりに、エージェントクライアントを顧客の VNet サブネットに注入（VNet インジェクション / コンテナーインジェクション）します。
選べるモデルは 2 つ。
モデル 仕組み トレードオフ
カスタマーマネージド VNet（BYO VNet） 自分の VNet と、Microsoft.App/environments に委任した専用サブネットを指定。プラットフォームがそこに注入される ネットワークを完全にコントロールできる。ただし自分で管理する責任も負う
マネージド VNet Foundry が代理で VNet を管理 セットアップが簡単。カスタマイズの余地は限られる
エンタープライズでは基本的に BYO VNet を選ぶことになります。
サブネット要件（必ず押さえる）
委任先: Microsoft.App/environments
最小サイズ: /27 以上（インジェクションの必須要件）
推奨サイズ: /24（256 アドレス） — Azure Container Apps のサブネットサイジングに準じる
Foundry リソースごとに専用のエージェントサブネットが必要（使い回し不可）
Private Endpoint 用のサブネットは別途用意する
アドレス空間の禁止事項
172.17.0.0/16 は使用しない（Docker ブリッジネットワークの予約範囲）
169.254.0.0/16、172.30.0.0/16、172.31.0.0/16、192.0.2.0/24、0.0.0.0/8、127.0.0.0/8、100.64.0.0/11、100.100.0.0/17 などの予約範囲と重複しない
この制約は VNet に含まれるすべてのアドレス空間、およびピアリング先にも及ぶ
大企業の既存ランディングゾーンだと、IPAM 上ここが衝突しがちです。アドレス設計は着手前に確認してください。
4-3. 必要な Private DNS ゾーン
閉域構成では、接続する依存サービスの分だけ Private DNS ゾーンが必要になります。ネットワーク分離環境で登場する主なゾーンは次のとおりです。
privatelink.services.ai.azure.com
privatelink.openai.azure.com
privatelink.cognitiveservices.azure.com
privatelink.blob.core.windows.net
privatelink.documents.azure.com
privatelink.search.windows.net
privatelink.azurecr.io
privatelink.agentsvc.azure-automation.net
privatelink.monitor.azure.com
privatelink.ods.opinsights.azure.com
privatelink.oms.opinsights.azure.com
ハブ集約型の DNS（カスタム DNS サーバーやオンプレ DNS）を使っている場合は、privatelink サブドメインのクエリを Azure DNS（168.63.129.16）に転送する設定を忘れずに。名前解決がパブリック IP を返すのは、この設定漏れが原因の定番です。
検証は VNet 内の VM から次の 2 つで行います。
nslookup
Test-NetConnection -Port 443
4-4. Private Endpoint の制約
VNet と同じリージョン・同じサブスクリプションにデプロイする必要がある
状態が 「承認済み」 の Private Endpoint のみトラフィックを流せる。Foundry リソースに対する共同作成者 / 所有者権限がないと「保留中」のまま止まる
Foundry をデプロイしても、Azure AI Search / Storage / Cosmos DB への Private Endpoint は自動作成されない。 各リソース側で個別に作成する
4-5. ハブ＆スポークとファイアウォール許可リスト
エグレスを制御するなら、Azure Firewall（または同等製品）をハブ VNet に置き、Foundry 用スポークとピアリングする構成が標準です。その際、以下は許可リストに入れる必要があります。
シナリオ FQDN / サービスタグ
エージェント（Container Apps 委任に必要） .identity.azure.net、login.microsoftonline.com、.login.microsoftonline.com、.login.microsoft.com、または AAD サービスタグ
評価・トレース（Application Insights 連携） settings.sdk.monitor.azure.com、.livediagnostics.monitor.azure.com、*.in.applicationinsights.azure.com、AzureMachineLearning サービスタグ
ファインチューニング raw.githubusercontent.com（ポータルでキュレーション済みサンプルデータセットを選ぶ場合）
ホステッドエージェント → Agent365 の可観測性 AzureFrontDoor.Frontend サービスタグ、TCP 443
評価については、サービスタグの代わりに {region}.api.azureml.ms と *.dataproxy.{region}.api.azureml.ms を許可する方法もあります（{region} は評価が実行されるリージョン）。
- エージェントツールの閉域対応状況
「閉域にしたらこのツールが動かない」は要件定義段階で潰しておきたい論点です。ネットワーク分離環境でのサポート状況とトラフィック経路は次のとおりです。
ツール 状態 トラフィック経路
MCP ツール（プライベート MCP） ✅ VNet サブネット経由
Azure AI Search ✅ Private Endpoint 経由
ファイル検索 ✅ Private Endpoint 経由
OpenAPI ツール / Azure Functions / A2A ✅ VNet サブネット経由
コードインタープリター / 関数呼び出し ✅ Microsoft バックボーン（追加構成不要）
Bing グラウンディング / Web 検索 / SharePoint グラウンディング ✅ パブリックエンドポイント
Foundry IQ（プレビュー） ✅ MCP 経由
Fabric IQ ⚠️ 部分的 項目種別により差異あり
Fabric データエージェント ❌ Fabric 側のパブリックネットワークアクセスが必要
Logic Apps / ブラウザー自動化 / コンピューター使用 / 画像生成 ❌ 開発中
🔴 重要: Bing グラウンディング、Web 検索、SharePoint グラウンディングは閉域環境でも動作しますが、通信はパブリックインターネット経由です。「すべてのトラフィックをプライベートネットワーク内に留める」という要件がある組織では、これらはコンプライアンス要件を満たしません。組織として使わせたくない場合は Azure Policy でブロックできます。
また、閉域下で Azure AI Search をエージェントツールとして使う場合、インデクサーの executionEnvironment を Private に設定してください。既定のマルチテナント実行では Private Endpoint を通過できず、エラーにならずインデックスが空のままという厄介な失敗をします。ただしインデックス付きナレッジソースの自動生成インデクサーはプライベート実行環境をサポートしません。
- ID とアクセス制御
Foundry の RBAC は「コントロールプレーン」と「データプレーン」がはっきり分かれています。
コントロールプレーン: デプロイの作成、プロジェクトの作成など
データプレーン: エージェントの構築、評価の実行、ファイルのアップロードなど
ロールは Foundry リソーススコープとプロジェクトスコープの両方に割り当てられます。最小権限の基本形は次の 2 つです。
各開発者のユーザープリンシパルに、Foundry リソーススコープで Foundry ユーザー
各プロジェクトのマネージド ID に、Foundry リソーススコープで Foundry ユーザー
📝 ロール名が最近変更されています。Foundry User / Foundry Owner / Foundry Account Owner / Foundry Project Manager は、以前それぞれ Azure AI ユーザー / Azure AI 所有者 / Azure AI アカウント所有者 / Azure AI Project Manager という名前でした。ロール ID とコア権限は変わっていませんが、ドキュメントや IaC のロール名表記が混在するため注意してください。
自動化やサービス間アクセスにはマネージド ID を使います。ネットワークを絞った Foundry に対しては、信頼された Azure サービス（Foundry Tools = Microsoft.CognitiveServices、Azure AI Search = Microsoft.Search、Azure Machine Learning = Microsoft.MachineLearningServices）への例外をネットワークルールで作ることもできます。これらはマネージド ID で認証します。
- データストレージと暗号化
7-1. Basic セットアップ vs Standard セットアップ
Basic セットアップ Standard セットアップ
スレッド / メッセージ / ファイルの保存先 Microsoft 管理のマルチテナントストレージ（論理分離） 自分の Azure リソース（BYO）
必要なリソース なし（自動作成） Azure Storage、Azure AI Search、Azure Cosmos DB
データの分離単位 論理分離 ストレージアカウント内でプロジェクト単位に分離
エージェントのデータをすべて自社テナント内に留めたい場合は、Standard セットアップ（BYO リソース）が必須です。Basic は PoC 向け、と割り切るのが分かりやすい整理です。
なお、閉域下でエージェントが起動しない場合、Basic セットアップのまま構築しているのが原因のことがあります。
7-2. 暗号化とシークレット管理
既定では Microsoft 管理キーで、FIPS 140-2 準拠の 256 ビット AES による保存時・転送時の暗号化が行われます。カスタマーマネージドキー（CMK）を使う場合の前提条件は次のとおりです。
Key Vault が Foundry リソースと同じ Azure リージョンにあること
Key Vault で論理削除（soft delete）とパージ保護が有効なこと
マネージド ID に必要なキー権限（Azure RBAC なら Key Vault Crypto User）があること
シークレットについては、既定では API キーベースの接続シークレットが Foundry のマネージド Key Vault に保存されます。自社管理にしたい場合は Key Vault を接続します。1 つの Key Vault 接続で、すべてのプロジェクト / リソースレベルの接続シークレットを管理する構成になります。
- 監視
Azure Monitor のメトリックはスコープごとに分かれています。
リソースレベル: トークン消費量、モデルのレイテンシ、リクエスト数、全プロジェクト横断のエラー率
プロジェクトレベル: 評価実行の結果、エージェント呼び出し数、ファイル操作
診断設定を有効化して、Log Analytics / Storage / Event Hubs にログをルーティングします。閉域環境では監視系の Private DNS ゾーン（privatelink.monitor.azure.com、privatelink.ods.opinsights.azure.com、privatelink.oms.opinsights.azure.com）が必要になる点も忘れずに。
コスト面では、トークン消費量メトリックをプロジェクト単位でダッシュボード化しておくと、チャージバックの議論がスムーズになります。
-
ハマりどころ・既知の制限（重要度順）
実務でインパクトが大きい順に並べます。 -
アウトバウンドのネットワーク設定は後から変更・追加できない
既存の Foundry デプロイに、後からアウトバウンド VNet インジェクションを追加することはできません。 追加するには Foundry を再デプロイする必要があります
委任済みサブネットを別のサブネットに変更することもできません
つまり、「まず PoC で作って、あとで閉域化しよう」が通用しないということです。将来的に閉域化する可能性が少しでもあるなら、最初から VNet インジェクション込みで作ってください。これがこの記事で一番伝えたい点です。 -
ワークフローエージェントのアウトバウンド分離が未対応
インバウンドは UI / SDK / CLI でサポートされますが、ワークフローエージェントは現時点で VNet インジェクションによるアウトバウンド分離に対応していません。 -
AI ゲートウェイ（APIM）は自動的にパブリックになる
新しい Foundry ポータルからプライベートな Foundry リソースに対して AI ゲートウェイを作成できますが、そのゲートウェイは自動的にパブリックになります。プライベート Foundry でデータプレーン操作を完結させるには、Azure ポータル側で AI ゲートウェイのネットワーク分離を別途構成する必要があります。 -
ホステッドエージェント + プライベート ACR は作成日に依存
2026年6月25日以降に作成された Foundry プロジェクトは、パブリックネットワークアクセスを無効にしたプライベート ACR と Private Endpoint をサポートします。それ以前に作成されたプロジェクトでは、レジストリにパブリックエンドポイント経由で到達できる必要があります。既存プロジェクトは影響を受けず、パブリックアクセスを使い続けます。 -
クラシック Foundry ポータルで作ったエージェントは閉域非対応
閉域下のツールサポートは、SDK / CLI または新しい Foundry ポータルで作成した新しい Responses API エージェントが対象です。クラシックポータル体験で作成したエージェントはサポートされません。パブリックアクセス無効の AI Search をエージェントツールとして使う場合も同様です。 -
Private Endpoint を削除してもパブリックにはならない
Private Endpoint を削除しても、プロジェクトが自動的にパブリックアクセス可能になるわけではありません。パブリックアクセスを有効にするには、ネットワーク設定の「ファイアウォールと仮想ネットワーク」で明示的に「すべてのネットワーク」を選択する必要があります。逆に、パブリックアクセスを有効にしても既存の Private Endpoint は削除されません。 -
設計チェックリスト
本番展開前に、以下を潰しておけば大きな手戻りは防げます。
リージョン・容量
デプロイ先リージョンで、必要なモデル・デプロイ種別・機能（エージェント、評価）が利用可能か確認した
モデルデプロイの上限とレート制限（クォータ）を確認し、必要なら増枠申請した
Provisioned（PTU）と従量課金のどちらを使うか、コストとレイテンシ要件から決めた
データ所在地・可用性
デプロイ種別（Global / DataZone / Regional）とデータ所在地要件の整合を取った
自動フェールオーバーがないことを前提に、マルチリージョン構成とルーティングをアプリ層で設計した
ネットワーク
インバウンド（PNA / Private Endpoint / 選択したネットワーク）の方式を決めた
最初からアウトバウンド VNet インジェクションを含めて設計した（後付け不可）
エージェントサブネットを Microsoft.App/environments に委任し、/24 を確保した
172.17.0.0/16 などの予約範囲と重複しないアドレス設計にした
必要な Private DNS ゾーンをすべて洗い出し、VNet リンクとハブ DNS の転送設定を用意した
AI Search / Storage / Cosmos DB の Private Endpoint を個別に作成する計画がある
Azure Firewall の許可リスト（AAD、Monitor、必要なら評価用エンドポイント）を定義した
使用予定のエージェントツールが閉域でサポートされるか確認した（Bing / Web 検索 / SharePoint はパブリック経由）
ポータルから設定できない構成があるため、IaC（Bicep / Terraform）を前提にした
ID・データ
Foundry リソーススコープとプロジェクトスコープで RBAC を適切に分けた
Basic / Standard セットアップを選択した（テナント内完結なら Standard 必須）
CMK を使う場合、Key Vault の同一リージョン・論理削除・パージ保護・キー権限を満たした
運用
診断設定を有効化し、ログの送信先と保持期間を決めた
リソースレベル / プロジェクトレベルのメトリック監視とアラートを設計した
おわりに
Microsoft Foundry のインフラ設計で最も重要なのは、「アウトバウンドのネットワーク構成は後から足せない」 という一点です。ここだけは PoC の段階で意思決定しておかないと、本番移行時に丸ごと作り直しになります。
裏を返せば、リソースモデル（Foundry リソース / プロジェクト / 接続リソース）とネットワーク分離の 2 点さえ最初に固めておけば、あとは通常の Azure PaaS の設計プラクティスがそのまま通用します。
この記事が、社内のセキュリティレビューや設計書レビューの叩き台になれば幸いです。誤りや「うちではこうしている」という知見があれば、ぜひコメントで教えてください。
参考リンク
Microsoft Foundry アーキテクチャ
Microsoft Foundry のネットワーク分離を構成する方法
Foundry Agent Service のプライベート ネットワークを設定する
Microsoft Foundry のロールベースのアクセス制御
Foundry モデルのデプロイの種類