Azure AIの公式ドキュメント更新「Clarify subnet IP address limitation in documentation」は、機能追加ではなく、Azure AI Foundry Agent Serviceのプライベートネットワーク構成で使えるサブネットのIPアドレス範囲を明確化した更新です。結論から言うと、確認すべき最大のポイントは、Agent用サブネットやPrivate Endpoint用サブネットにCGNAT向けの 100.64.0.0〜100.127.255.255 を使っていないかです。
この更新では、従来「Public IP and CGNAT address ranges are not supported」とされていた記述に、CGNATの具体的な範囲として 100.64.0.0〜100.127.255.255 が追記されました。GitHub上のMicrosoftDocs公式コミットでは、2026年4月30日に「unsupported CGNAT address ranges」を明確化する変更として記録されています。(GitHub)
Azure AIの公式ドキュメント更新で何が変わったか
今回の更新対象は、Azure AI Foundry Agent Serviceのプライベートネットワーク設定に関するドキュメントです。Microsoft Learnの該当ページでは、Standard Setup with private networkingにより、パブリックアクセスを抑えた分離ネットワーク環境を作成し、Azure Storage、Azure AI Search、Azure Cosmos DBなどのBYOリソースと連携する構成が説明されています。(Microsoft Learn)
変更点は大きな仕様変更ではありません。差分としては、サブネットIPアドレス制限の説明に、CGNATの具体的なアドレス範囲が追加されたものです。
| 確認項目 | 内容 |
|---|---|
| 更新日 | 2026年4月30日 |
| 更新対象 | Azure AI Foundry Agent Serviceのプライベートネットワーク関連ドキュメント |
| 変更内容 | CGNATアドレス範囲 100.64.0.0〜100.127.255.255 がサポート対象外であることを明記 |
| 影響を受けやすい環境 | BYO VNet、VNet injection、Private Endpoint、閉域ネットワーク構成を使うAzure AI環境 |
| すぐ確認すべきこと | Agent用サブネットとPrivate Endpoint用サブネットのCIDRがRFC1918範囲内か |
公式ドキュメントでは、両方のサブネットはRFC1918のプライベートIPv4範囲、つまり 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 の範囲内である必要があり、Public IPおよびCGNAT範囲 100.64.0.0〜100.127.255.255 はサポートされないと説明されています。(Microsoft Learn)
今回のポイントは「CGNATもAzureの私的利用に使えそう」という誤解を防ぐこと
Azure Virtual Networkでは、一般的なVNet設計の文脈でRFC1918のプライベートアドレス範囲が推奨されています。一方で、Azure全体のネットワーク仕様としては、RFC6598で予約された 100.64.0.0/10 がAzure上でプライベートIPアドレス空間として扱われる場面もあります。(Microsoft Learn)
ここが誤解しやすい点です。
Azureの一部ネットワーク機能で 100.64.0.0/10 を扱えるからといって、Azure AI Foundry Agent Serviceのプライベートネットワーク構成でも使えるとは限りません。今回の更新は、その誤解を避けるために、Azure AI側の制限としてCGNAT範囲を明示したものと考えるべきです。
CGNAT向けの 100.64.0.0/10 は、RFC6598でShared Address Spaceとして定義された範囲です。IETFのRFC6598では、この範囲はCarrier-Grade NAT、つまり主にサービスプロバイダー側のNAT環境で使うための共有アドレス空間として説明されています。(IETF Datatracker)
そのため、社内ネットワークやAzure VNetのアドレス設計で「RFC1918が不足しているから100.64系を使う」という設計をしている場合、Azure AI Foundry Agent Serviceのプライベートネットワーク構成では見直しが必要になる可能性があります。
影響を受ける構成と受けにくい構成
今回の更新は、すべてのAzure AI利用者に同じ影響があるわけではありません。特に確認が必要なのは、Azure AI Foundry Agent Serviceを閉域構成で使う、または使う予定がある環境です。
| 構成 | 影響の可能性 | 確認すべき点 |
|---|---|---|
| Azure AI Foundry Agent Serviceをパブリックアクセス中心で利用 | 低い | 今後プライベートネットワーク化する予定があるか |
| Standard Setup with private networkingを利用 | 高い | Agent用サブネットとPrivate Endpoint用サブネットのCIDR |
| BYO VNetを使ってAzure AI環境を構築 | 高い | 既存VNetにCGNAT範囲が含まれていないか |
| BicepやTerraformでVNet injectionを自動構築 | 高い | IaCテンプレート内のaddressPrefix、addressPrefixes |
| 既存のAzure VNetを複数サービスで共用 | 中〜高 | 他サービスでは使えていてもAzure AI側で制限に抵触しないか |
| 検証環境のみで小規模利用 | 中 | 本番移行時に同じCIDRを流用しないか |
特に注意したいのは、PoCや検証環境で一時的に 100.64.x.x を使っていたケースです。検証段階ではネットワーク設計を簡略化しがちですが、本番移行時にそのままIaCテンプレートを流用すると、Azure AI Foundry Agent Serviceのデプロイや接続確認で失敗する可能性があります。
まず確認すべきサブネットは2つ
Azure AI Foundry Agent Serviceのプライベートネットワーク構成では、サブネットの役割を分けて考える必要があります。Microsoft Learnのドキュメントでは、自動プロビジョニングされるネットワーク例として、Agent SubnetとPrivate endpoint Subnetが示されています。(Microsoft Learn)
確認すべき主なサブネットは次の2つです。
| サブネット | 主な用途 | 確認ポイント |
|---|---|---|
| Agent用サブネット | Agent実行基盤をVNetに接続するためのサブネット | Microsoft.App/environments への委任、サイズ、CIDR範囲 |
| Private Endpoint用サブネット | Foundry、Azure Storage、Azure AI Search、Azure Cosmos DBなどのPrivate Endpoint配置 | RFC1918範囲内か、既存リソースと重複しないか |
公式ドキュメントでは、Agent用サブネットは Microsoft.App/environments に委任され、VNet injectionに必要なサブネットサイズとして /27 以上が必要と説明されています。また、制限事項では、委任されたAgentサブネットの推奨サイズとして /24 が示されています。(Microsoft Learn)
つまり、単に「RFC1918の範囲ならよい」だけでは不十分です。次の3点をまとめて満たす必要があります。
| 条件 | 実務での確認内容 |
|---|---|
| アドレス範囲 | 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 のいずれか |
| サブネットサイズ | Agent用サブネットは少なくとも /27 以上、余裕を持つなら /24 を検討 |
| サブネットの使い回し | Agent用サブネットを複数のFoundryリソースで共有しない |
使ってよいIPアドレス範囲と使ってはいけない範囲
Azure AI Foundry Agent Serviceのプライベートネットワーク構成では、サブネットのCIDRを次のように整理して確認すると判断しやすくなります。
| 種類 | 範囲 | Azure AI Foundry Agent Serviceでの扱い |
|---|---|---|
| RFC1918 private IPv4 | 10.0.0.0/8 | 使用可能 |
| RFC1918 private IPv4 | 172.16.0.0/12 | 使用可能 |
| RFC1918 private IPv4 | 192.168.0.0/16 | 使用可能 |
| CGNAT / Shared Address Space | 100.64.0.0/10 | 使用不可 |
| Public IP範囲 | グローバルIPアドレス範囲 | 使用不可 |
注意したいのは、172 から始まるアドレスのすべてがプライベートアドレスではない点です。RFC1918の範囲は 172.16.0.0〜172.31.255.255 です。たとえば 172.32.0.0/16 はRFC1918の範囲外です。RFC1918では、プライベートネットワーク用の範囲として 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 が定義されています。(RFCエディタ)
実務では、以下のようなCIDRを見つけたら要注意です。
| CIDR例 | 判定 | 理由 |
|---|---|---|
10.20.0.0/24 | OK | 10.0.0.0/8 の範囲内 |
172.20.10.0/24 | OK | 172.16.0.0/12 の範囲内 |
192.168.100.0/24 | OK | 192.168.0.0/16 の範囲内 |
100.64.10.0/24 | NG | CGNAT範囲内 |
100.127.255.0/24 | NG | CGNAT範囲内 |
172.32.0.0/24 | NG | RFC1918の172系範囲外 |
8.8.8.0/24 | NG | Public IP範囲 |
運用担当者が確認すべきチェックリスト
既存環境がある場合は、次の順番で確認すると手戻りを減らせます。
| 確認順 | 作業 | 見るべき場所 |
|---|---|---|
| 1 | Azure AI Foundry Agent Serviceでプライベートネットワーク構成を使っているか確認 | Azure Portal、設計書、構成管理台帳 |
| 2 | 対象VNetのアドレス空間を確認 | Virtual NetworkのAddress space |
| 3 | Agent用サブネットのCIDRを確認 | Subnets |
| 4 | Private Endpoint用サブネットのCIDRを確認 | Subnets、Private Endpoint一覧 |
| 5 | IaCテンプレートのCIDRを確認 | Bicep、ARM、Terraform |
| 6 | オンプレミスや他VNetとの重複を確認 | IPアドレス管理台帳、ネットワーク設計書 |
| 7 | DNS解決とPrivate Endpointの到達性を確認 | nslookup、Private DNS Zone、条件付きフォワーダー |
Azure Portalで確認する場合は、対象のVirtual Networkを開き、Address spaceとSubnetsを確認します。100.64. から始まる範囲だけでなく、100.65、100.100、100.127 などもCGNAT範囲に含まれます。範囲の始点だけを見るのではなく、CIDR全体が 100.64.0.0/10 に含まれるかを確認してください。
Terraformを使っている場合は、次のような項目を重点的に確認します。
address_space = ["10.40.0.0/16"]
address_prefixes = ["10.40.1.0/24"]Bicepの場合は、次のようなプロパティを確認します。
addressSpace: {
addressPrefixes: [
'10.40.0.0/16'
]
}
subnets: [
{
name: 'agent-subnet'
properties: {
addressPrefix: '10.40.1.0/24'
}
}
]このとき、100.64.0.0/10 そのものだけでなく、100.64.10.0/24 や 100.100.0.0/16 のような部分的な切り出しも避ける必要があります。
既存環境でCGNAT範囲を使っていた場合の対応
既存のVNetやサブネットでCGNAT範囲を使っている場合、単純にサブネットCIDRを書き換えれば済むとは限りません。サブネットにはPrivate Endpoint、委任設定、ルートテーブル、NSG、DNS、接続元アプリケーションなどが紐づいているためです。
現実的には、次の流れで移行を検討します。
| 手順 | 内容 | 注意点 |
| -: | ————————– | ———————————— |
| 1 | 影響範囲を棚卸しする | Azure AI以外のリソースも同じVNetを使っていないか確認 |
| 2 | RFC1918範囲で新しいCIDRを設計する | オンプレミス、VPN、ExpressRoute、他クラウドと重複させない |
| 3 | 新しいサブネットを作成する | Agent用とPrivate Endpoint用を分ける |
| 4 | IaCテンプレートを修正する | 手作業変更とテンプレートの差分を残さない |
| 5 | Private EndpointとDNSを再確認する | 名前解決がプライベートIPを返すか確認 |
| 6 | 検証環境でAgent作成・実行をテストする | デプロイ成功だけでなく実行時通信まで確認 |
| 7 | 本番切り替え計画を作る | ロールバック手順を用意する |
特にPrivate Endpointは、再作成やDNSレコードの更新が必要になる場合があります。Azure AI Search、Azure Storage、Azure Cosmos DBなどのPrivate Endpointが自動作成されない構成では、各リソース側でPrivate Endpointを個別に作成する必要がある点にも注意してください。公式ドキュメントでも、これらのリソースへのPrivate EndpointはFoundryリソースのデプロイ時に自動作成されないと説明されています。(Microsoft Learn)
設計時に避けたい失敗パターン
今回の更新を受けて、Azure AIのネットワーク設計で避けたい失敗は次の通りです。
| 失敗パターン | 何が問題か | 対策 |
|---|---|---|
| Azure全体で使える範囲とAzure AIで使える範囲を混同する | 100.64.0.0/10 をAzure AIのサブネットに使ってしまう | サービス別の制限事項を確認する |
| 検証環境のCIDRを本番に流用する | PoC用の暫定設計が本番障害の原因になる | 本番前にIPアドレス設計レビューを行う |
| Agent用サブネットを複数リソースで共用する | Foundryリソースごとの専用サブネット要件に抵触する | リソース単位でAgent用サブネットを分ける |
/27 ギリギリで設計する | 将来拡張や運用変更の余地が少ない | 可能なら /24 など余裕のある設計を検討 |
| DNS確認を省略する | デプロイ後にAzure Cosmos DBやStorageへ到達できない | nslookup でPrivate Endpointの名前解決を確認する |
| IaCだけ直して既存環境を見落とす | 実環境とテンプレートが乖離する | Portal、CLI、IaCの3点で照合する |
ネットワーク設計では「Azure上で作成できたから正しい」と判断しないことが重要です。Azure AI Foundry Agent Serviceのように、サービス固有の制限がある場合、VNet自体は作成できても、サービス統合やAgent実行の段階で問題が出ることがあります。
開発者・クラウド管理者・アーキテクト別の見るべきポイント
開発者が確認すべきこと
開発者は、アプリケーションコードよりも、開発・検証環境の接続経路を確認することが重要です。
特に、Agent PlaygroundやSDKからAzure AI Foundry Agent Serviceを操作する場合、VNet内の踏み台VM、VPN、ExpressRoute、Azure Bastionなどを経由してアクセスする構成になっているかを確認してください。公式ドキュメントでは、保護されたFoundryプロジェクトへのアクセス方法として、Azure VPN Gateway、ExpressRoute、Azure Bastionが例示されています。(Microsoft Learn)
開発者向けの確認ポイントは次の通りです。
| 確認項目 | 内容 |
|---|---|
| SDK実行環境 | VNet内または許可された経路から実行しているか |
| 名前解決 | Foundry、Storage、Search、Cosmos DBがプライベートIPに解決されるか |
| エラー切り分け | 認証エラー、DNSエラー、ネットワーク到達性エラーを分けて確認できるか |
| 検証環境 | 本番と同じCIDR設計ルールで作っているか |
クラウド管理者が確認すべきこと
クラウド管理者は、既存VNetとサブネットの棚卸しが優先です。とくに複数チームが同じAzureサブスクリプションを使っている場合、アドレス空間の選定が属人的になっていることがあります。
確認すべき項目は次の通りです。
| 確認項目 | 内容 |
|---|---|
| VNetアドレス空間 | 100.64.0.0/10 が含まれていないか |
| サブネット委任 | Agent用サブネットが Microsoft.App/environments に委任されているか |
| NSG | 必要な通信を過度に遮断していないか |
| UDR | Private Endpointや必要なAzureサービス向け通信が不適切に迂回していないか |
| Azure Firewall | FQDN許可リストやTLS検査の影響を確認しているか |
| Private DNS Zone | VNetに正しくリンクされているか |
公式ドキュメントでは、Azure Firewallを統合する場合、Managed Identityに関連するFQDNの許可、またはService Tag AzureActiveDirectory の追加が説明されています。また、FirewallでTLS inspectionが自己署名証明書を追加していないか確認する注意点も示されています。(Microsoft Learn)
ソリューションアーキテクトが確認すべきこと
ソリューションアーキテクトは、今回の更新を「1つのドキュメント修正」としてではなく、Azure AI導入時のネットワーク標準を見直すきっかけとして扱うべきです。
特に、以下の観点が重要です。
| 設計観点 | 判断基準 |
|---|---|
| IPアドレス管理 | RFC1918内で将来拡張できる空き範囲を確保しているか |
| マルチリージョン | 各リージョンで同じCIDRを使い回して接続時に重複しないか |
| ハイブリッド接続 | オンプレミス、VPN、ExpressRouteと重複しないか |
| セキュリティ | Public network accessを無効化した場合の運用経路を確保しているか |
| 運用 | 障害時にDNS、Private Endpoint、Firewall、RBACを切り分けられるか |
| IaC標準化 | 禁止CIDRをレビュー項目やポリシーに組み込めるか |
Azure AIは、モデルやアプリケーションの話に注目が集まりがちです。しかし、企業利用ではネットワーク設計が運用品質を左右します。とくにAgent Serviceのように複数のデータストアや検索基盤と連携する構成では、サブネット、Private Endpoint、DNS、RBACのいずれかが崩れると、原因調査が難しくなります。
移行準備で決めておくべき判断基準
今回の更新を受けて移行準備をする場合、最初に決めるべきなのは「どのCIDRへ移すか」ではなく、「どのルールでCIDRを選ぶか」です。
おすすめの判断基準は次の通りです。
| 判断基準 | 推奨 |
|---|---|
| 基本方針 | Azure AI関連サブネットはRFC1918に限定する |
| 優先範囲 | 大規模環境は 10.0.0.0/8、小規模・部門単位は 172.16.0.0/12 や 192.168.0.0/16 を検討 |
| 禁止範囲 | 100.64.0.0/10、Public IP範囲、オンプレミスと重複する範囲 |
| サブネット分離 | Agent用、Private Endpoint用、管理用を分ける |
| サイズ | Agent用は将来拡張を考え、可能なら /24 を検討 |
| 管理方法 | IaC、IPAM、設計書を同時に更新する |
たとえば、グローバル企業でAzure AIを複数リージョンに展開するなら、次のようにリージョンや用途ごとに範囲を分けると管理しやすくなります。
| 用途 | CIDR例 |
|---|---|
| Japan East Azure AI用VNet | 10.40.0.0/16 |
| Agent用サブネット | 10.40.1.0/24 |
| Private Endpoint用サブネット | 10.40.2.0/24 |
| 管理用サブネット | 10.40.10.0/24 |
| 将来拡張用 | 10.40.100.0/24 以降を予約 |
このように用途別に余白を持たせると、Private Endpointの追加、別プロジェクトの展開、監視基盤の追加が発生しても、既存構成を大きく崩さずに対応できます。
デプロイ後に確認すべき動作確認
サブネットCIDRを修正した後は、Azureリソースが作成できたかだけでなく、Agentが実際に使えるかまで確認します。
最低限、次の項目を確認してください。
| 確認項目 | コマンド・確認方法 | 期待結果 |
|---|---|---|
| サブネット範囲 | Azure PortalまたはAzure CLI | RFC1918範囲内 |
| サブネット委任 | VNet > Subnets | Microsoft.App/environments が設定されている |
| Public network access | 各リソースのNetworking設定 | Disabled |
| DNS解決 | nslookup <resource-fqdn> | Private IPが返る |
| Agent作成 | Foundry PortalまたはSDK | Agentを作成できる |
| Agent実行 | PlaygroundまたはSDK | 応答が返る |
| Storage/Search/Cosmos DB接続 | Agent実行ログ、各サービスの診断 | 接続エラーがない |
Microsoft Learnでも、デプロイ後の確認として、サブネット委任、Public network access、Private EndpointのDNS解決、Agent接続テストが挙げられています。(Microsoft Learn)
今回の更新を受けて今すぐやるべきこと
今回のAzure AI公式ドキュメント更新は、派手な新機能ではありません。しかし、企業の閉域ネットワーク設計では見逃せない更新です。特に 100.64.0.0/10 を「Azureでもプライベートっぽく使える範囲」として採用している組織では、Azure AI Foundry Agent Serviceの制限に抵触する可能性があります。
今すぐ行うべきことは、次の3つです。
- Azure AI Foundry Agent Serviceのプライベートネットワーク構成を使っている環境を洗い出す
- Agent用サブネットとPrivate Endpoint用サブネットに
100.64.0.0/10が含まれていないか確認する - 今後のIaCテンプレートや設計レビューで、Azure AI用サブネットはRFC1918範囲に限定するルールを追加する
今回の更新は、単なるドキュメントの文言修正ではなく、Azure AIを安全に本番運用するためのネットワーク設計チェックポイントです。既存環境の棚卸し、IaCテンプレートの見直し、DNSとPrivate Endpointの疎通確認までをセットで進めることで、デプロイ時の失敗や本番移行時の手戻りを減らせます。
コメント