Azure AI Foundry（公式更新では Microsoft Foundry と表記）の「Managed virtual network for evaluations」は、プライベートエンドポイント配下にあるモデルやエージェントに対して、クラウド上の評価ジョブを実行しやすくする更新です。結論から言うと、AIアプリやCopilotの品質評価をCI/CDや本番前検証に組み込みたいが、ネットワーク分離や閉域接続の要件で止まっていた組織にとって、導入を再検討する価値があります。公式のAzure Updatesでは、この機能が評価用途で一般提供されたことが案内されています。(マイクロソフト Azure)
ただし、既存のAzure AI Foundry環境へ単純に「後からオン」にできる設定ではありません。ネットワーク分離モード、リージョン、マネージドIDの権限、Private LinkやAzure Firewallの費用、既存のカスタムVNet構成との関係を先に確認しないと、再デプロイや評価ジョブ失敗につながります。
Azure AI FoundryのManaged virtual network一般提供で何が変わるのか
今回のポイントは、Azure AI Foundryの評価機能そのものではなく、評価ジョブが利用するネットワーク経路をMicrosoft管理の仮想ネットワークで制御しやすくなったことです。公式ドキュメントでは、Managed virtual networkを有効にすると、Foundryリソースに対してMicrosoft管理の仮想ネットワークがプロビジョニングされ、Foundryプロジェクト内のAgentsサービス基盤のアウトバウンド通信をネットワーク境界で保護できると説明されています。(Microsoft Learn)
クラウド評価は、テストデータセットを使った本番前検証、スケールする評価、CI/CDへの組み込みに向いています。評価結果はFoundryプロジェクトに保存され、ポータル、SDK、接続済みのApplication Insightsから確認できます。(Microsoft Learn)
今回の更新によって、次のような構成を取りやすくなります。
| 観点 | これまで課題になりやすかったこと | 今回の更新で見直せること |
|---|---|---|
| 評価ジョブの到達性 | モデルやエージェントをPrivate Endpoint配下に置くと、クラウド評価から到達させる設計が難しい | Foundry管理のVNet経由で、承認済み宛先へのアウトバウンド接続を設計しやすい |
| セキュリティ | 評価のためだけに広いインターネットアウトバウンドを許可しがち | 「承認済みアウトバウンドのみ」の構成を選べる |
| 運用負荷 | 評価環境ごとにBYO VNet、サブネット、ルート、ファイアウォールを細かく設計する必要がある | Microsoft管理のネットワーク境界を使い、必要な接続ルールを中心に管理できる |
| 評価自動化 | ローカル評価や手動検証に寄りがち | クラウド評価をCI/CDや継続的評価に組み込みやすい |
特に、RAG構成でAzure AI Search、Azure Storage、Azure Cosmos DB、Key Vaultなどをプライベート接続にしている環境では、評価だけがネットワーク要件から外れてしまう問題を減らせます。
影響を受ける利用者と管理者の範囲
この更新の影響が大きいのは、Azure AI FoundryでAIアプリやエージェントを本番運用に近い形で評価しているチームです。逆に、公開エンドポイントだけを使った検証や、ローカル環境で小規模に評価している段階では、すぐに構成変更が必要とは限りません。
影響が大きいケース
次のいずれかに当てはまる場合は、Managed virtual network for evaluationsを優先的に確認すべきです。
- モデル、エージェント、検索基盤、ストレージをPrivate Endpoint配下で運用している
- 生成AIアプリや社内Copilotの評価をCI/CDに組み込みたい
- 本番データに近い評価データを扱うため、広いインターネットアウトバウンドを避けたい
- セキュリティ部門から、評価環境にも本番相当のネットワーク分離を求められている
- Application Insightsのトレースを使って、エージェント応答を継続的に評価したい
クラウド評価では、既存データセット、モデルターゲット、エージェントターゲット、FoundryエージェントのレスポンスID、Application Insightsのトレースなど複数の入力パターンを扱えます。モデルターゲット評価やエージェントターゲット評価では、評価時にモデルやFoundryエージェントへ問い合わせ、生成された応答を評価できます。(Microsoft Learn)
管理者・開発者・プラットフォーム担当者で見るべきポイント
| 役割 | 主な確認ポイント |
|---|---|
| Azure管理者 | リージョン、リソースプロバイダー、RBAC、マネージドID、Private Endpoint承認、費用 |
| ネットワーク管理者 | アウトバウンド分離モード、FQDNルール、Azure Firewall、Private Link、オンプレミス接続 |
| 開発者 | 評価データのスキーマ、評価レベル、SDK、評価対象のモデル・エージェント接続 |
| MLOps・Platform担当 | IaC化、CI/CDへの組み込み、既存Foundry環境からの移行方針、検証環境の分離 |
ここで重要なのは、Managed virtual networkが「開発者だけの便利機能」ではない点です。実際には、ネットワーク、ID、コスト、評価設計がまたがるため、導入前に運用チームと開発チームで責任範囲を決めておく必要があります。
管理者が最初に確認すべき設定
Managed virtual networkを使うには、Azureサブスクリプション、Azure CLI 2.86.0、複数のリソースプロバイダー登録、Foundry関連のRBAC権限が前提になります。公式ドキュメントでは、Microsoft.Network、Microsoft.KeyVault、Microsoft.CognitiveServices、Microsoft.Storage、Microsoft.Search、Microsoft.ContainerServiceなどの登録が必要とされています。(Microsoft Learn)
| 確認項目 | 確認する内容 | 見落とした場合のリスク |
|---|---|---|
| 対象リージョン | 対象リージョンでManaged virtual networkがサポートされているか | デプロイ不可、または別リージョン設計が必要になる |
| RBAC | Foundry Account Owner、Foundry User、OwnerまたはRole Based Access Administratorなどが適切か | リソース作成やPrivate Endpoint承認で失敗する |
| マネージドID | Foundryリソースのシステム割り当てマネージドIDを使うか | アウトバウンド先リソースへの承認ができない |
| リソースプロバイダー | Network、Storage、Search、Cosmos DB関連などが登録済みか | テンプレートやCLI実行時に失敗する |
| CLI・IaC | Azure CLI 2.86.0以上、Bicep、Terraform、az restの利用方針 | ポータル操作だけで完結すると誤解しやすい |
| 費用 | Private Link、FQDNルール利用時のAzure Firewall費用 | 評価環境でも想定外の月額費用が発生する |
現時点のドキュメントでは、Managed virtual networkはEast US、East US2、Japan Eastなど複数リージョンをサポートしており、追加リージョンは今後対応予定とされています。日本の環境ではJapan Eastが含まれている点は確認材料になりますが、実際の展開前には必ず最新のリージョン対応状況を確認してください。(Microsoft Learn)
ネットワーク分離モードの選び方
Managed virtual networkでは、アウトバウンド通信の扱いを選びます。公式ドキュメントでは、主に「Allow internet outbound」「Allow only approved outbound」「Disabled」の3つの考え方が示されています。(Microsoft Learn)
| モード | 内容 | 向いているケース | 注意点 |
|---|---|---|---|
| Allow internet outbound | インターネットへのアウトバウンド通信を許可 | 検証環境、外部依存が多い初期開発 | 広い外向き通信が許容される前提が必要 |
| Allow only approved outbound | サービスタグ、Private Endpoint、FQDNルールで承認済み宛先だけを許可 | 本番前評価、機密データを扱う評価、閉域要件がある環境 | FQDNルールではAzure Firewall費用やポート制限を確認 |
| Disabled | Managed virtual network分離を使わない | 公開エンドポイント中心、またはカスタムVNetを使う | 評価ジョブのネットワーク分離は別途設計が必要 |
本番データに近い評価データを扱うなら、基本的には「Allow only approved outbound」を優先して検討します。一方、PoC段階で外部APIや複数の検証用エンドポイントへ頻繁に接続する場合は、「Allow internet outbound」で早く検証し、後から本番相当の環境を別リソースで作るほうが安全です。
注意すべきなのは、分離モードの変更に制約があることです。Managed virtual networkをAllow internet outboundで構成した後にDisabledへ戻すことはできず、Allow only approved outboundで構成した後にAllow internet outboundへ変更することもできません。(Microsoft Learn)
展開時の基本手順
Managed virtual networkは、Foundryリソース作成時点の設計が重要です。公式ドキュメントでは、customSubDomainName、allowProjectManagement、networkInjectionsをアカウント作成時に設定する必要があり、後から追加できないと説明されています。また、ネットワークインジェクション付きのFoundryリソース作成には、Azure CLIだけでなくaz restコマンドが必要とされています。(Microsoft Learn)
実務では、次の順番で進めると失敗を減らせます。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| Foundryリソースを新規作成 | ネットワークインジェクションを含めて作成 | 既存リソースへの後付け前提にしない |
| マネージドIDを確認 | Foundryリソースのprincipal IDを取得 | システム割り当てIDが有効か |
| 承認ロールを割り当て | Azure AI Enterprise Network Connection Approverを付与 | Storage、Cosmos DB、AI Searchなどの接続先スコープを確認 |
| Managed networkを作成 | allow_internet_outboundまたはallow_only_approved_outboundを指定 | 本番相当なら承認済みアウトバウンドを優先 |
| アウトバウンドルールを追加 | Private Endpoint、Service Tag、FQDNを設定 | 評価、トレース、エージェント実行に必要な宛先を洗い出す |
| 動作確認 | managed-network show、outbound-rule list、基本エージェント実行 | ネットワークだけでなく評価ジョブまで通す |
Allow only approved outboundで作成する場合のコマンド例は次の形式です。
az cognitiveservices account managed-network create \
--resource-group <resource-group> \
--name <foundry-account-name> \
--managed-network allow_only_approved_outbound \
--firewall-sku Standardまた、ネットワークインジェクションの考え方としては、作成時のプロパティに次のような設定を含めます。
"networkInjections": [
{
"scenario": "agent",
"subnetArmId": "",
"useMicrosoftManagedNetwork": true
}
]この設定は「後でポータルから有効化すればよい」という種類のものではありません。検証環境であっても、リソース名、リージョン、接続先、権限、費用を含めた小さな設計レビューを先に行うべきです。
評価ジョブで必要になりやすいアウトバウンドルール
Allow only approved outboundでは、必要な通信先を明示的に許可する設計になります。公式ドキュメントでは、Agent serviceなどの機能に必要なアウトバウンドルールとして、Cosmos DB、Storage、AI SearchへのPrivate Endpoint、AzureActiveDirectoryとAzureMachineLearningへのService Tagが挙げられています。(Microsoft Learn)
特に評価やトレースでApplication Insightsを使う場合は、追加のFQDNルールが必要になることがあります。ドキュメントでは、評価カタログやApplication Insightsへ結果を送るための宛先として、settings.sdk.monitor.azure.com、*.livediagnostics.monitor.azure.com、*.in.applicationinsights.azure.comが示されています。(Microsoft Learn)
| 用途 | 代表的な許可先 | 実務上の見方 |
|---|---|---|
| 評価対象の依存リソース | Azure Storage、Azure Cosmos DB、Azure AI Search | RAGや評価データ保存で使う可能性が高い |
| 認証 | AzureActiveDirectory Service Tag | Entra ID認証を使うなら必須になりやすい |
| 評価カタログ | AzureMachineLearning Service Tag | 評価カタログ利用時に確認 |
| トレース・監視 | Application Insights関連FQDN | 継続評価やトレース評価で確認 |
| エージェント実行 | Microsoft Container RegistryやID関連FQDN | Hosted Agentやコンテナー実行時に確認 |
開発者は「SDKの評価コードは正しいのに、評価ジョブだけ失敗する」という状況に遭遇しがちです。その場合、まず評価データやコードではなく、Managed networkのアウトバウンドルールとPrivate Endpoint承認状態を確認してください。
開発者が確認すべき評価設計
Managed virtual networkが整っても、評価ジョブの設計が曖昧だと運用には乗りません。クラウド評価では、既存データセットの評価、CSV評価、モデルターゲット評価、エージェントターゲット評価、レスポンスIDによる評価、Application Insightsトレース評価などを使い分けます。(Microsoft Learn)
| 評価パターン | 向いている場面 | 注意点 |
|---|---|---|
| JSONL/CSVデータセット評価 | 既にquery、response、ground_truthなどがある | フィールド名とdata_mappingを正確に合わせる |
| モデルターゲット評価 | 入力だけを用意し、モデル応答をその場で生成して評価 | モデル容量、TPM、Private Endpoint到達性を確認 |
| エージェントターゲット評価 | Foundry agentへ問い合わせて応答品質を評価 | Prompt AgentとHosted Agentの構成差を確認 |
| レスポンスID評価 | 既に発生したFoundry agent応答を評価 | レスポンスIDを収集できる実装が必要 |
| トレース評価 | Application Insights上の実行履歴を評価 | OpenTelemetryやApplication Insights接続が前提 |
評価レベルにも注意が必要です。クラウド評価では、turnとconversationの評価レベルを指定できますが、各Evaluatorが対応する評価レベルは異なります。たとえば、ターン単位のみ対応のEvaluatorを会話全体評価に使うと失敗します。(Microsoft Learn)
評価データの失敗で多いのは、JSONLの1行1オブジェクト形式の崩れ、フィールド名の大文字小文字違い、data_mappingの指定漏れです。ネットワーク分離を入れると原因が見えにくくなるため、最初は小さなデータセットで「SDK、認証、ネットワーク、評価ロジック」を順に確認するのがおすすめです。
既存環境からの移行で注意すべきこと
Managed virtual networkは、既存のFoundry環境をそのまま安全に変換する魔法のスイッチではありません。公式ドキュメントでは、Managed virtual network isolationを有効化した後は無効化できず、カスタムVNet構成からManaged virtual networkへのアップグレードパスはなく、Foundryリソースの再デプロイが必要とされています。(Microsoft Learn)
移行時に特に注意すべき点は次のとおりです。
| 注意点 | 実務上の対処 |
|---|---|
| 既存Foundryリソースに後付けできない設定がある | 検証用に新しいFoundryリソースを作成して比較する |
| カスタムVNetからManaged VNetへ直接移行できない | IaCで再デプロイ手順を作り、接続先リソースを再確認する |
| Managed Private EndpointのNICはサブスクリプションに見えない | NICではなく、Foundry側のアウトバウンドルールと接続状態で確認する |
| 新規プロジェクト追加時にCapability Host再作成が必要になる場合がある | プロジェクト追加手順を運用Runbookに含める |
| Azure Firewallを自前で持ち込めない | 独自Firewall、UDR、詳細ログ要件があるならBYO VNetを検討する |
Managed Private EndpointはMicrosoftにより管理され、通常のVNet Private Endpointのように顧客サブスクリプション内のNICとして表示されません。ネットワーク管理者が従来のPrivate Endpointと同じ感覚でNICやプライベートIPを探すと、原因調査に時間を使ってしまいます。(Microsoft Learn)
費用で見落としやすいポイント
Managed virtual network機能そのものは無料とされていますが、利用する周辺リソースには課金が発生します。公式ドキュメントでは、Private Endpointに使うAzure Private Link、FQDNアウトバウンドルールで使うAzure Firewallの料金に注意するよう案内されています。(Microsoft Learn)
| 費用項目 | 発生条件 | 確認ポイント |
|---|---|---|
| Azure Private Link | Managed Private EndpointでAzureリソースへ接続する | 接続先リソース数と評価環境数 |
| Azure Firewall | Allow only approved outboundでFQDNルールを使う | SKU、常時稼働コスト、環境数 |
| モデル利用料 | 評価ジョブがモデルを呼び出す | 評価データ件数、Evaluator数、再実行回数 |
| Application Insights | トレースや評価結果を送る | サンプリング、保持期間、データ量 |
FQDNルールを追加するとManaged Azure Firewallが作成されます。FQDNルールはポート80と443のみをサポートし、Azure Firewallを自分で持ち込むことはできません。また、Allow only approved outboundではFoundryアカウントごとにManaged Firewallが作られるため、環境を細かく分けるほど固定費が増えやすくなります。(Microsoft Learn)
PoCでは見過ごされがちですが、評価ジョブは再実行が多く、Evaluatorによってはモデル呼び出し回数も増えます。ネットワーク費用だけでなく、評価用モデルのTPM、利用量、Application Insightsへの送信量も一緒に見積もるべきです。
よくある失敗と対処法
Managed virtual networkを使った評価環境では、失敗原因が「SDK」「認証」「ネットワーク」「モデル容量」のどこにあるか切り分けにくくなります。代表的な失敗パターンを先に押さえておくと、初回展開の手戻りを減らせます。
| 症状 | 主な原因 | 対処 |
|---|---|---|
| 評価ジョブが対象モデルやエージェントへ到達しない | Private Endpointまたはアウトバウンドルール不足 | managed-network outbound-rule listで許可先を確認 |
| Private Endpoint接続が承認されない | FoundryリソースのマネージドIDに承認権限がない | Azure AI Enterprise Network Connection Approverロールを確認 |
| NICやプライベートIPが見つからない | Managed Private Endpointは顧客サブスクリプションにNICを表示しない | Foundry側のルールと接続状態で確認 |
| FQDNルールが効かない | Firewallが作成されていない、または対象ポートが80/443以外 | Firewall SKUとポートを確認 |
| 評価ジョブが長時間Runningのまま | Azure OpenAIモデルの容量不足で再試行が続いている | ジョブをキャンセルし、モデル容量やTPMを見直す |
| 401または403エラー | 認証設定、Foundry Userロール、プロジェクトエンドポイントURLの誤り | az login、RBAC、エンドポイントURLを確認 |
| スキーマエラー | JSONL形式、フィールド名、data_mapping不一致 | 小さなテストデータで先に検証 |
| エージェント評価でツールエラー | Evaluatorが対象ツールに非対応 | 対応ツールを確認し、必要に応じてユーザー定義関数ツールとしてラップ |
クラウド評価のトラブルシューティングでは、長時間Running、認証エラー、データ形式エラー、429レート制限、エージェントEvaluatorのツールエラーなどが公式ドキュメントで整理されています。(Microsoft Learn)
Managed VNetとカスタムVNetはどちらを選ぶべきか
Managed virtual networkは、ネットワーク分離を簡単に始めたいチームに向いています。Microsoft側がサブネット範囲やIP選択、委任の一部を扱うため、評価環境ごとにネットワークを細かく作り込む負担を減らせます。一方で、独自のAzure Firewall、詳細なルーティング、ネットワークピアリング、アウトバウンドログなどを厳密に管理したい場合は、カスタムVNetのほうが適している可能性があります。(Microsoft Learn)
| 判断軸 | Managed virtual networkが向く | カスタムVNetが向く |
|---|---|---|
| 導入スピード | 速く始めたい | 設計に時間をかけてもよい |
| ネットワーク制御 | 承認済み宛先を中心に管理したい | UDR、Firewall、Peeringを細かく制御したい |
| 運用負荷 | Microsoft管理部分を増やしたい | 自社ネットワーク標準に完全準拠したい |
| 監査要件 | 基本的な分離で足りる | 詳細なアウトバウンドログや経路証跡が必要 |
| オンプレミス連携 | Application Gateway経由で足りる | 複雑な閉域接続や既存ハブネットワーク統合が必要 |
判断基準はシンプルです。評価環境の目的が「Private Endpoint配下のFoundryリソースや依存Azureサービスへ安全に到達し、クラウド評価を回すこと」ならManaged virtual networkが有力です。逆に、企業標準のFirewall、SOC監視、オンプレミス閉域接続、細かな経路制御が必須なら、BYOのカスタムVNetを前提に設計したほうが無理がありません。
導入前に作っておきたいチェックリスト
本番前に、少なくとも次の項目を確認してください。
| チェック項目 | 完了条件 |
|---|---|
| 評価対象の棚卸し | モデル、エージェント、Storage、AI Search、Cosmos DB、Key Vault、Application Insightsを一覧化した |
| ネットワークモード決定 | 環境ごとにAllow internet outboundかAllow only approved outboundを決めた |
| リージョン確認 | 対象リージョンがManaged virtual networkに対応している |
| 権限確認 | Foundry管理者、RBAC管理者、開発者のロールが明確になっている |
| コスト確認 | Private Link、Azure Firewall、モデル評価、Application Insightsの費用を見積もった |
| IaC方針 | Bicep、Terraform、CLIのどれで再現可能にするか決めた |
| 評価データ検証 | JSONL/CSV、data_mapping、評価レベルを小規模データで確認した |
| 失敗時の切り分け | ネットワーク、認証、データ、モデル容量の確認手順をRunbook化した |
この機能は、Azure AI FoundryでAIアプリやCopilotを安全に評価するための実務的な選択肢です。まずは本番環境を直接変更するのではなく、同じリージョン・同じ依存サービス構成に近い検証用Foundryリソースを作り、Managed virtual network、Private Endpoint、評価ジョブ、Application Insights連携まで一通り流してください。その結果をもとに、CI/CDへ組み込むか、カスタムVNet構成を選ぶかを判断するのが安全です。
コメント