「Azure Virtual Network FAQ」が2026年7月10日時点の更新情報として挙がり、「既存のVNetに設定変更が必要なのか」「新しい制限が追加されたのか」と気になっている管理者もいるでしょう。
結論からいうと、今回確認できるのは主にFAQの文書更新です。 新機能の一般提供やSKU変更ではなく、説明範囲、用語、注意書き、表記が整理されています。公開差分からは、既存のAzure Virtual Networkが自動的に変更される内容は確認できません。
ただし、Azure VM上でDHCPサーバーを運用している環境、サービスエンドポイントを利用している環境、グローバルVNetピアリングとBasic Load Balancerを組み合わせている環境、新規VNetの送信接続を暗黙の既定動作に依存している環境は、設計を再確認する必要があります。
Azure Networkingの「Azure Virtual Network FAQ」で何が変わるのか
2026年7月10日はサービスの提供開始日ではない
Microsoft LearnのAzure Virtual Network FAQには「最終更新 2026年7月8日」と表示されています。一方、Microsoftの公開ドキュメントリポジトリでは、同ファイルに対するコミットが2026年7月9日に反映されています。
したがって、2026年7月10日は新機能のリリース日というより、更新後の公式情報を確認できた日として捉えるのが適切です。FAQの更新日とAzureサービス自体の仕様変更日は同じとは限りません。(Microsoft Learn)
公開差分を分類すると、主な変更は次のとおりです。(GitHub)
| 変更領域 | 更新内容 | 実務への影響 |
|---|---|---|
| ページ情報 | 更新日を2024年7月22日から2026年7月8日に変更。説明文に構成、接続、セキュリティ、ピアリング、移行を明記 | FAQの対象範囲が分かりやすくなったが、サービス仕様の変更ではない |
| 用語 | CIDRを「Classless Inter-Domain Routing」と正式名称で表記。IETFなどの略語も補足 | 初心者向けの可読性向上。設定変更は不要 |
| DHCP | オンプレミス端末向けDHCPサーバーの説明と、T1・T2更新時の挙動を明確化 | DHCPリレーを利用する環境は、監視条件や障害判定を再確認する価値がある |
| VNetピアリング | MACsecによるデータリンク層暗号化の文章と参照先を修正 | 新しい暗号化機能の追加ではなく、既存説明の整理 |
| サービスエンドポイント | VNet ACL、送信元IP変更、IPv6ログ、ICMPによるテスト、上限表の表現を整理 | 導入順序や接続試験の方法を誤ると通信断につながるため要確認 |
| クラシック移行 | 見出しや文法を修正 | 移行要件の変更ではない |
公開差分には、新しいSKU、料金体系、API、リージョン展開の追加は含まれていません。そのため、今回のFAQ更新だけを理由に緊急メンテナンスを実施する必要はありません。
一方で、FAQには障害につながりやすい既存仕様がまとまっています。変更管理手順書やネットワーク設計書が古い場合は、今回の更新を棚卸しのきっかけにするとよいでしょう。
自社環境で対応が必要かを判断する
まず、次の表で対応要否を判定してください。
| 現在の状況 | 優先度 | 推奨する対応 |
|---|---|---|
| 既存VNetを利用しており、最近構成を変更していない | 低 | 緊急の設定変更は不要。設計書と運用手順を最新FAQに合わせて確認する |
| 新しいAPIバージョンやAzure portalでVNetを新規作成する | 高 | Private Subnetと明示的な送信経路を確認する |
| Azure VM上のDHCPサーバーからオンプレミス端末へアドレスを配布する | 高 | DHCPリレー、T1・T2更新、リース失効前の復旧性をテストする |
| Azure SQL、Storage、Cosmos DBなどでサービスエンドポイントを使う | 高 | VNet ACL、IPファイアウォール、送信元IP変更、設定順序を確認する |
| グローバルVNetピアリング先にBasic Load Balancerがある | 高 | フロントエンドIP経由の到達性を確認し、必要に応じてStandardへ移行する |
| 異なるMicrosoft Entraテナント間で接続する | 中 | VNetピアリングとサービスエンドポイントで条件が異なることを確認する |
| VNetのDNSサーバー設定を変更する | 中 | 影響を受けるVMでDHCPリースを更新する |
| クラシックネットワークリソースが残っている | 中 | 今回の文書変更とは別に、対象サービスの移行条件と期限を確認する |
特に注意したいのは、新規VNetの送信接続です。FAQには「VNet内のサービスはインターネットへ送信接続できる」という一般的な説明がありますが、現在は明示的な送信方法を構成しなければ接続できないケースがあります。(Microsoft Learn)
Azure Virtual Network FAQで押さえる設計条件
CIDRは将来のピアリングまで考えて決める
Azure Virtual Networkは、サブスクリプション専用の論理的に分離されたネットワークです。VNet同士やオンプレミスネットワークを接続できますが、CIDRが重複しているとVNetピアリングを構成できません。(Microsoft Learn)
一般的には、次のプライベートアドレス範囲を使用します。
| アドレス範囲 | CIDR |
|---|---|
| 10.0.0.0～10.255.255.255 | 10.0.0.0/8 |
| 172.16.0.0～172.31.255.255 | 172.16.0.0/12 |
| 192.168.0.0～192.168.255.255 | 192.168.0.0/16 |
| 100.64.0.0～100.127.255.255 | 100.64.0.0/10 |
100.64.0.0/10もAzureではプライベートIPアドレス空間として扱われます。ただし、既存のオンプレミスネットワークや接続先で利用していないことを事前に確認してください。(Microsoft Learn)
実務では、VNetを作る時点で次の接続候補まで洗い出します。
- オンプレミスネットワーク
- 他リージョンのVNet
- 開発・検証・本番環境
- 買収先やグループ会社のネットワーク
- 将来追加するハブVNetやセキュリティVNet
たとえば、本番環境を10.10.0.0/16、検証環境を10.20.0.0/16、ハブVNetを10.0.0.0/16と分離しておけば、後からピアリングを追加しやすくなります。目先のVM台数だけを基準に、小さなCIDRを細切れに割り当てると、将来の拡張やPaaS統合で不足しやすくなります。
サブネットでは5個のIPアドレスが予約される
Azureは各サブネットの先頭4個と末尾1個、合計5個のIPアドレスを予約します。最小のIPv4サブネットは/29ですが、/29には8個のアドレスしかないため、実際にリソースへ割り当てられるのは3個です。
そのため、/29が作成できることと、運用に適していることは別問題です。冗長化したVM、ロードバランサー、Private Endpoint、将来の増設を考えると、本番用サブネットでは余裕を持たせる必要があります。IPv6サブネットは/64で作成します。(Microsoft Learn)
VNetはレイヤー3であり、VLANの延長ではない
Azure Virtual Networkはレイヤー3のオーバーレイネットワークです。オンプレミスのVLANをそのままAzureへ延長する仕組みではありません。
マルチキャスト、ブロードキャスト、IP-in-IP、GREパケットはサポートされません。そのため、ブロードキャスト検出に依存するアプリケーションや、GREトンネルを前提とする仮想アプライアンスは、Azure対応方式へ変更できるか確認が必要です。(Microsoft Learn)
VNetは1つのリージョンに限定されますが、同一リージョン内の可用性ゾーンをまたいで利用できます。異なるリージョン間の接続には、グローバルVNetピアリングなどを使用します。(Microsoft Learn)
NSGとUDRの評価順序を理解する
NSGをサブネットとNICの両方に設定した場合、評価順序は方向によって異なります。
| 通信方向 | 評価順序 |
|---|---|
| 受信 | サブネットのNSG → NICのNSG |
| 送信 | NICのNSG → サブネットのNSG |
| サブネットにNSGとUDRがある場合の送信 | NSG → UDR |
「UDRでファイアウォールへ転送しているから通信できるはず」と考えても、その前段のNSGで拒否されていれば通信は成立しません。障害調査では、有効なルートだけでなく、NICとサブネットの両方のNSGを確認してください。(Microsoft Learn)
DNS設定の変更後はDHCPリースを更新する
VNetのDNSサーバー一覧は後から変更できます。ただし、設定を保存しただけでは、既存VMに直ちに反映されない場合があります。
影響を受けるVMではDHCPリースを更新します。Windows VMの場合は、VM内で次のコマンドを実行します。
ipconfig /renewDNS変更後に名前解決だけが失敗する場合は、NSGやルーティングを変更する前に、VMが新しいDNS設定を受け取っているか確認してください。(Microsoft Learn)
Azure VM上でDHCPサーバーを運用する場合の注意点
Azure VNetはAzure VMに対してDHCPとDNSを提供します。一方、Azure VMに独自のDHCPサーバーを構築し、DHCPリレーエージェントを介してオンプレミス端末へアドレスを配布する構成も可能です。
以前はAzure上のUDP/67にレート制限があり、この構成は現実的ではありませんでした。公式FAQでは、プラットフォーム更新によってレート制限が取り除かれたと説明されています。ただし、今回の差分では文章が整理されたにとどまり、2026年7月に新しく提供開始された機能とは記載されていません。(Microsoft Learn)
重要なのは、オンプレミス端末からAzure上のDHCPサーバーへ直接送る、送信元UDP/68・宛先UDP/67の通信がサポートされない点です。
DHCPリース更新時には、次の挙動が想定されます。
- T1のタイミングで端末がAzure上のDHCPサーバーへ直接更新を試みる
- Azure側で通信が通常とは異なる形で処理され、タイムアウトが発生する
- T2のタイミングでDHCPリレー経由の更新を行う
- DHCPリレー経由で更新が成功する
このため、T1のタイムアウトだけを見てDHCP障害と判断すると、不要な切り戻しにつながる可能性があります。一方、T2で更新できていない状態を放置すると、最終的にリースが失効します。(Microsoft Learn)
運用前には、次の条件を満たしているか確認します。
| 確認項目 | 合格基準 |
|---|---|
| DHCPリレー | オンプレミス端末からAzure上のDHCPサーバーまで、必ずリレーを経由している |
| T1・T2試験 | T1のタイムアウトと、T2での正常更新を区別して確認できる |
| ログ監視 | DHCPサーバー、リレー、オンプレミス端末のログを時系列で突合できる |
| 経路 | VPNまたはExpressRoute、UDR、NSGの変更後もリレー通信が成立する |
| 冗長性 | DHCPサーバーやリレーが単一障害点になっていない |
| リース期間 | 障害対応に必要な時間より短すぎるリース期間を設定していない |
サービスエンドポイントは設定順序と送信元IPに注意する
ネットワーク側とサービス側の両方を設定する
Azure StorageやAzure SQLなどをサービスエンドポイントで保護するには、次の2つの設定が必要です。
- サブネットで対象サービスのサービスエンドポイントを有効にする
- Azureサービス側でVNet ACLを設定する
サブネット側でサービスエンドポイントを有効にしただけでは、アクセス元を特定のVNetやサブネットに制限できません。サービス側のVNet ACLまで設定して初めて制限が成立します。(Microsoft Learn)
標準の設定順序と通信断を避ける順序は異なる場合がある
公式FAQの標準手順は、サービスエンドポイントを有効にした後、サービス側のVNet ACLを設定する順序です。
ただし、サービスエンドポイントを有効にすると、Azureサービスから見える送信元IPが、従来のパブリックIPv4アドレスからVNet内のプライベートIPアドレスへ切り替わります。Azureサービス側のIPファイアウォールが旧パブリックIPだけを許可していると、一時的な通信断が発生する可能性があります。(Microsoft Learn)
Azure SQLやAzure Cosmos DBなど、IgnoreMissingVnetServiceEndpointをサポートするサービスでは、次の順序を選択できます。
IgnoreMissingVnetServiceEndpointを有効にする- サービス側のVNet ACLを先に設定する
- サブネット側でサービスエンドポイントを有効にする
- 接続を確認する
この例外手順は、対象サービスがフラグをサポートしている場合に限ります。ほかのAzureサービスへ同じ手順を流用せず、サービス固有のドキュメントを確認してください。(Microsoft Learn)
pingやtracertでは正しい経路を確認できない
サービスエンドポイントが処理するのはTCPトラフィックです。ICMPはサービスエンドポイントの経路を通らないため、pingやtracertの結果だけでは、実際のアプリケーション通信がサービスエンドポイントを通っているか判断できません。
接続試験では、次のように実際のサービスで使用するプロトコルを使います。
- Azure SQLへのデータベース接続
- Azure StorageへのHTTPSリクエスト
- Key VaultへのAPIアクセス
- アプリケーションの正常性確認
- サービス側の診断ログや拒否ログ
サービスエンドポイントのシステムルートはBGPルートより優先されます。NVAやオンプレミス経由でPaaS通信を検査している環境では、有効なルートが設計どおりかも確認してください。(Microsoft Learn)
サブスクリプションとテナントの条件
VNetとAzureサービスが異なるサブスクリプションにある場合でも、同じMicrosoft Entraテナント内であれば、サービスエンドポイントとVNet ACLを構成できます。
異なるMicrosoft Entraテナント間で利用できるのは、FAQ上ではAzure StorageとAzure Key Vaultです。その他のサービスでは、テナントをまたいだサービスエンドポイントとVNet ACLはサポートされません。(Microsoft Learn)
また、VPNやExpressRouteで接続されたオンプレミス環境から、サービスエンドポイントで保護されたPaaSへは、既定ではアクセスできません。オンプレミス側のパブリックNAT IPをサービスのIPファイアウォールで許可するか、対応サービスでPrivate Endpointを利用する方法を検討します。(Microsoft Learn)
Service EndpointとPrivate Endpointの使い分け
| 選択肢 | 向いている環境 | 主な注意点 |
|---|---|---|
| Service Endpoint | Azure内の特定サブネットからPaaSへのアクセスを簡潔に制限したい | サービスのパブリックエンドポイントを使用する。オンプレミスからの利用には追加設計が必要 |
| Private Endpoint | PaaSへVNet内のプライベートIPで接続したい。オンプレミスからも閉域経由で利用したい | Private DNS、名前解決、ルーティング、接続元ごとのアクセス制御が必要 |
| IPファイアウォール | 固定されたパブリックIPからの接続を許可したい | NAT後のIP変更や送信元IPの増減を管理する必要がある |
サービスエンドポイントには追加料金がありません。ただし、サービスごとに1リソースへ登録できるVNetルール数の上限があります。FAQに掲載されている例は次のとおりです。(Microsoft Learn)
| Azureサービス | VNetルール数の例 |
|---|---|
| Azure Storage | 200 |
| Azure SQL | 128 |
| Azure Synapse Analytics | 128 |
| Azure Key Vault | 200 |
| Azure Cosmos DB | 64 |
| Azure Event Hubs | 128 |
| Azure Service Bus | 128 |
これらの上限はサービス側で変更される可能性があります。大規模なマルチVNet構成では、FAQの数値だけで設計を確定せず、対象サービスの最新ドキュメントも確認してください。
VNetピアリングで確認すべき制限
VNetピアリングは、同一リージョンだけでなく、異なるリージョンやサブスクリプション間でも利用できます。異なるMicrosoft Entraテナントに属するサブスクリプション間でのピアリングにも対応しています。(Microsoft Learn)
一方、次の制限を見落とすと接続できません。
| 確認項目 | 条件 |
|---|---|
| アドレス空間 | ピアリングするVNet間で重複不可 |
| 接続方向 | 双方向にピアリングリンクを作成する |
Initiated状態 | 片方向のリンクしか作成されていない可能性が高い |
Disconnected状態 | 残っているリンクを削除し、両方向を再作成する |
| リモートゲートウェイ | Use Remote Gatewayを有効にできる接続先は1つ |
| 推移的接続 | VNet A－B、B－Cを接続しても、A－Cは自動接続されない |
| VNet移動 | ピアリングを削除してから移動する |
| 料金 | ピアリングリンクの作成は無料だが、データ転送は課金対象 |
特に、異なるリージョン間のグローバルVNetピアリングでは、Basic Load BalancerのフロントエンドIPを経由して背後のリソースへ接続できません。Standard Load Balancerには、この制限はありません。古い環境にBasic Load Balancerが残っている場合は、プライベートIPへの直接接続またはStandardへの移行を検討します。(Microsoft Learn)
VNetピアリングの通信については、Microsoftが管理しない物理境界の外をデータセンター間トラフィックが通る場合、基盤ネットワークでMACsecによるデータリンク層暗号化が使用されます。ただし、これはアプリケーションのエンドツーエンド暗号化と同じではありません。機密データを扱うシステムでは、TLSやIPsecなどの要件を別途定義してください。(Microsoft Learn)
FAQだけでは見落としやすい2026年の送信接続変更
Azure Virtual Network FAQには、VNet内のサービスからインターネットへ送信接続できると記載されています。しかし、現在のAzureでは、送信経路を明示的に構成しなければインターネットやMicrosoftのパブリックエンドポイントへ到達できないVNetがあります。
2026年3月31日より後にリリースされたAPIバージョンで新しいVNetを作成すると、サブネットのdefaultOutboundAccessは既定でfalseになり、Private Subnetとして作成されます。Azure portalでもPrivate Subnetが既定です。既存VNetが自動的に変更されるわけではありません。(Microsoft Learn)
この変更により、次のような処理が失敗する可能性があります。
- Windowsのライセンス認証や更新
- OSやアプリケーションのパッケージ取得
- 外部APIへのアクセス
- Microsoftのパブリックエンドポイントへの接続
- SaaSや外部監視サービスへのログ送信
明示的な送信方法は、用途に応じて選択します。
| 送信方法 | 向いている構成 | 判断ポイント |
|---|---|---|
| NAT Gateway | 多数のVMから安定した送信接続が必要 | 多くの一般的な構成で推奨される。サブネット単位で管理しやすい |
| Standard Load Balancerのアウトバウンド規則 | 既にStandard Load BalancerのバックエンドとしてVMを構成している | SNATポートやバックエンド構成を含めて設計する |
| VMのNICにStandard Public IPを関連付け | 少数のVMに個別の送信元IPが必要 | VMごとの管理が増え、集約的な出口制御には向かない |
| Azure FirewallまたはNVA＋UDR | 通信検査、集中ログ、FQDN制御などが必要 | 可用性、経路対称性、運用負荷、コストを含めて設計する |
既存サブネットをPrivate Subnetへ変更した場合、既存VMのネットワークインターフェイスへ反映させるには、VMの停止と割り当て解除が必要です。稼働中の本番VMへ一括適用せず、メンテナンス計画と送信接続試験を準備してください。(Microsoft Learn)
組織全体でPrivate Subnetを標準化する場合は、Azure Policyの組み込み定義「Subnets should be private」を利用できます。監査だけで始めて影響範囲を把握し、明示的な送信経路を整備した後にDenyへ切り替えると、安全に展開できます。(Microsoft Learn)
提供条件・料金・プレビュー機能を整理する
Azure Virtual Network FAQには、一般提供機能とプレビュー機能が混在しています。FAQに掲載されているから本番利用できるとは限りません。
| 項目 | 提供条件・料金 |
|---|---|
| グローバルVNetピアリング | Azureパブリックリージョン、中国クラウド、政府機関向けクラウドで利用可能。パブリックリージョンと各国クラウド間のグローバルピアリングは不可 |
| VNetピアリング | リンク作成自体は無料。ピアリング経由のデータ転送は課金対象 |
| サービスエンドポイント | 追加料金なし。対応サービスやVNetルール上限はサービスごとに異なる |
| Virtual Network TAP | プレビュー。SLAなしで、本番ワークロードへの利用は推奨されない |
| TAPと高速ネットワーク | 組み合わせ可能だが、ミラーリングのオフロードに対応していないため、VMの性能や遅延へ影響する可能性がある |
Virtual Network TAPを検証する場合は、監視対象NIC、TAPリソース、収集先を同じリージョンに配置します。性能検証なしに本番NICへ適用しないでください。(Microsoft Learn)
導入・運用前に確認するチェックリスト
| 分類 | 確認内容 | 完了の判断基準 |
|---|---|---|
| アドレス設計 | VNet、オンプレミス、接続予定の他VNetでCIDRが重複していないか | 将来の接続先まで含むIPアドレス管理表がある |
| サブネット容量 | Azure予約分5個と、将来追加するNICやPrivate Endpointを考慮したか | 通常時だけでなく障害時・増設時の空きIPがある |
| リージョン | VNetが1リージョンに限定されることを考慮したか | DR先との接続方法が設計されている |
| 送信接続 | defaultOutboundAccessと明示的な送信方法を確認したか | NAT Gateway、Firewall、Load Balancerなどの経路が明示されている |
| セキュリティ | NIC・サブネットのNSG、UDR、Firewallの役割が重複していないか | 評価順序と責任範囲が設計書に記載されている |
| DNS | DNSサーバー、Private DNS、オンプレミス名前解決の経路を確認したか | 正引き・逆引き・Private Endpointの名前解決試験に合格している |
| ピアリング | 双方向リンク、非推移性、ゲートウェイ転送を確認したか | Connected状態で、想定した全経路を試験済み |
| サービスエンドポイント | ネットワーク側とサービス側の両方を設定したか | VNet ACL外からの接続が拒否され、許可元から接続できる |
| 送信元IP変更 | 既存のIPファイアウォール規則への影響を調査したか | 切り替え前後の送信元IPと許可規則が確認できている |
| DHCP | DHCPリレーとT1・T2更新を確認したか | T2でリース更新でき、リース失効前に復旧できる |
| RBAC | サービスエンドポイント設定に必要な権限があるか | Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/actionを保有している |
| 接続試験 | pingだけで判定していないか | TCPやアプリケーションレベルで正常性を確認している |
| 監視 | 403、404、DNS失敗、SNAT枯渇、経路変更を検知できるか | ログの保存先、アラート、担当者、初動手順が決まっている |
| 切り戻し | 設定変更前の状態へ戻せるか | IaC、設定値、変更順序、復旧手順が保存されている |
まとめ：多くの既存環境は緊急対応不要だが、設計確認は必要
2026年7月10日時点で確認できるAzure Virtual Network FAQの更新は、主に文書の整理と説明の明確化です。公開差分からは、今回の更新だけで既存VNetの構成が変わる内容や、利用者に一律の移行を求める内容は確認できません。
ただし、次の環境は優先的に確認してください。
- Azure VM上のDHCPサーバーをオンプレミス端末から利用している
- サービスエンドポイントとIPファイアウォールを併用している
- グローバルVNetピアリング先にBasic Load Balancerがある
- 新規VNetのインターネット送信を既定動作に依存している
- 異なるMicrosoft Entraテナントをまたぐ構成がある
最初に行うべきことは、VNetとサブネットの一覧を作成し、CIDR、defaultOutboundAccess、サービスエンドポイント、ピアリング、DNS、DHCP依存関係を記録することです。該当する構成が見つかった場合は、本番環境を直接変更せず、非本番環境で通信経路と切り戻し手順を検証してから反映してください。
コメント