Windows 11の入れ子構成のHyper-Vで、内側の仮想マシンにネットワークを正しく割り当てられない問題について、MicrosoftはWindows 11 version 26H1のRelease Preview、OS Build 28000.2605で構成上の問題を修正したと案内しました。
ただし、この修正は2026年7月20日に公開されたWindows Insider向けのプレビュー情報です。さらに段階的ロールアウトの対象であるため、同じビルドを導入しても、すべての端末へ一斉に反映されるとは限りません。一般提供版に修正済みと判断したり、本番PCを修正目的だけでInsider Programへ参加させたりするのは避けるべきです。(Microsoft Learn)
この記事では、修正内容の正しい読み方、対象ビルドの確認方法、MACアドレススプーフィングとNATの設定、問題が直らない場合の切り分け手順を解説します。
入れ子構成Hyper-Vのネットワークプロビジョニングを修正
Microsoftのリリースノートでは、Windows 11 Build 28000.2605のネットワーク関連改善として、入れ子構成のHyper-Vにおけるネットワーク設定上の問題を修正し、仮想マシンのネットワークを安定してプロビジョニングできるようにしたと説明されています。(Microsoft Learn)
今回の情報を整理すると、次のとおりです。
| 項目 | 内容 |
|---|---|
| 対象OS | Windows 11 version 26H1 |
| OSビルド | 28000.2605 |
| 配信チャネル | Windows Insider Release Preview Channel |
| 公開日 | 2026年7月20日 |
| 修正内容 | 入れ子構成Hyper-Vのネットワーク設定に関する問題を修正 |
| 期待される改善 | 入れ子VMのネットワークプロビジョニングの信頼性向上 |
| 配信方式 | 段階的ロールアウト |
| 一般提供状況 | 一般提供版への反映済みとは断定できない |
Windows Insider Blogでも、Build 28000.2605はWindows 11 version 26H1向けのRelease Previewビルドとして案内されています。安定版Windows 11へ一般提供された更新プログラムとして発表されたものではありません。(Windows Blog)
Microsoftが明らかにしていない情報
公式発表から確認できるのは、入れ子Hyper-Vのネットワーク設定に関する問題を修正したという点です。一方、次の情報は明らかにされていません。
- 発生する具体的なエラーコード
- 問題が発生する正確な操作手順
- 影響を受ける以前のビルド範囲
- DHCP、NAT、仮想スイッチのどの処理が原因だったのか
- 一般提供版へ反映される時期
- 既存のすべてのHyper-Vネットワーク問題が解消されるか
そのため、「入れ子VMがインターネットにつながらない」というだけで、今回修正された問題と断定することはできません。MACアドレススプーフィング、NAT、IPアドレス、DNS、VLANなど、従来から必要な設定は引き続き確認する必要があります。
入れ子構成のHyper-Vとは
入れ子構成、または入れ子仮想化とは、Hyper-Vの仮想マシン内で、さらにHyper-Vを動かす構成です。
構成を階層で表すと、次のようになります。
物理PC(L0)
└─ Hyper-V仮想マシン(L1)
└─ L1内のHyper-V仮想マシン(L2)
それぞれの役割は次のとおりです。
| 階層 | 役割 |
|---|---|
| L0 | Windows 11が動作する物理Hyper-Vホスト |
| L1 | L0上で動作し、内部にHyper-Vを構成した仮想マシン |
| L2 | L1上のHyper-Vで作成した入れ子仮想マシン |
入れ子仮想化は、Hyper-V構築の研修、検証環境、仮想化製品のテスト、自動構築スクリプトの動作確認などに利用できます。MicrosoftはWindows 11を入れ子仮想化の対応プラットフォームとして案内しており、ネットワーク方式としてMACアドレススプーフィングとNATの2種類を示しています。(Microsoft Learn)
ネットワークプロビジョニングとは何か
ここでいうネットワークプロビジョニングは、単にWebサイトを表示できるかどうかだけを意味するものではありません。
Hyper-Vや管理ツールが仮想マシンを作成する際に、次のようなネットワーク関連設定を適用し、通信可能な状態へ準備する処理を指します。
- 仮想ネットワークアダプターの作成
- 仮想スイッチへの接続
- 仮想NICとVM構成の関連付け
- 入れ子VMから外部ネットワークまでの通信経路の確立
- MACアドレスやネットワーク設定の反映
- 管理ツールや自動化処理によるネットワーク構成
問題が発生すると、実際の画面では次のような現象として見える可能性があります。
- L2仮想マシンを作成してもネットワークアダプターが利用できない
- 仮想スイッチへ接続したはずの設定が正しく反映されない
- 仮想マシンがIPアドレスを取得できない
- VM作成処理や自動プロビジョニングが途中で失敗する
- L1は通信できるのにL2だけ通信できない
- 再起動や再作成のたびに接続状態が変わる
ただし、Microsoftは今回の問題について具体的な症状を列挙していません。上記の現象がすべてBuild 28000.2605で解消されるわけではない点に注意してください。
SR-IOVの変更と混同しない
同じリリースノートのネットワーク項目には、Confidential Virtual Machineが既定でSR-IOVのハードウェアアクセラレーションを利用する変更も記載されています。(Microsoft Learn)
ただし、通常の入れ子Hyper-V環境でSR-IOVを有効にしなければ今回の修正を利用できない、という説明ではありません。SR-IOVの変更と入れ子Hyper-Vのネットワーク修正は、別の改善項目として判断するのが適切です。
最初にWindows 11のビルドを確認する
今回の修正を確認する前に、実際に使用しているWindows 11のバージョンとOSビルドを確認します。
winverで確認する
Windowsキー + Rを押し、次のコマンドを実行します。
winver
表示された画面で、次の情報を確認してください。
Version 26H1
OS Build 28000.2605
Build 28000.2605より前のBuild 28000系を使用している場合、今回の修正が含まれているとは判断できません。
PowerShellで確認する
管理者権限は不要です。PowerShellで次のコマンドを実行します。
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
Select-Object ProductName, DisplayVersion, CurrentBuild, UBR
次のように表示された場合、OSビルドは28000.2605です。
DisplayVersion : 26H1
CurrentBuild : 28000
UBR : 2605
CurrentBuildとUBRをピリオドでつないだ値が、完全なOSビルド番号になります。
Release Preview Channelか確認する
次の画面を開きます。
設定
→ Windows Update
→ Windows Insider Program
Release Preview Channelに参加しているか確認してください。
今回のBuild 28000.2605は、26H1向けRelease Previewとして公開されています。通常のWindows 11安定版を使用しているPCで、Windows Updateにこのビルドが表示されないのは異常ではありません。(Windows Blog)
Build 28000.2605でも修正がすぐ反映されるとは限らない
入れ子Hyper-Vのネットワーク修正は、リリースノートの「Gradual rollout」に記載されています。
段階的ロールアウトでは、対象機能や改善が一斉に有効化されるのではなく、端末ごとに順次配信されます。そのため、同じBuild 28000.2605であっても、適用タイミングに差が出る可能性があります。(Microsoft Learn)
対象ビルドへ更新した後は、次の順番で確認します。
- Windows Updateで更新プログラムを再確認する
- 保留中の更新プログラムをすべてインストールする
- Windows 11を再起動する
winverでビルド番号を再確認する- L1とL2の仮想マシンを再起動する
- 新規L2 VMの作成でも再現するか確認する
既存のL2 VMだけで問題が続く場合は、保存済みのVM設定や仮想NIC構成に問題が残っている可能性があります。新規VMでも同じ現象が発生するかを確認すると、OS側の修正と既存構成の問題を切り分けやすくなります。
入れ子仮想化のCPU設定を確認する
ネットワーク設定を確認する前に、L1仮想マシンへ仮想化拡張機能が公開されているかを確認します。
L0の物理Hyper-Vホストで、PowerShellを管理者として実行します。
Get-VMProcessor -VMName "L1-HyperV" |
Select-Object VMName, ExposeVirtualizationExtensions
ExposeVirtualizationExtensionsがTrueであることを確認してください。
VMName ExposeVirtualizationExtensions
------ ------------------------------
L1-HyperV True
Falseの場合は、L1仮想マシンを正常終了し、状態がOffになったことを確認してから設定します。
Set-VMProcessor -VMName "L1-HyperV" `
-ExposeVirtualizationExtensions $true
ExposeVirtualizationExtensionsは、ホスト側の仮想化拡張機能を仮想マシンへ公開し、入れ子仮想化を有効にする設定です。(Microsoft Learn)
CPUとVM構成バージョンの要件
Microsoftが示している主な前提条件は次のとおりです。(Microsoft Learn)
| CPU | ホストOSの主な条件 | VM構成バージョン |
|---|---|---|
| Intel VT-x/EPT対応CPU | Windows 10以降、またはWindows Server 2016以降 | 8.0以上 |
| AMD Ryzen/EPYC以降 | Windows 11以降、またはWindows Server 2022以降 | 9.3以上 |
VM構成バージョンは、L0ホストで次のコマンドを実行して確認できます。
Get-VM -Name "L1-HyperV" |
Select-Object Name, Version, State
OSを更新しても、CPU要件やVM構成バージョンを満たしていなければ、入れ子仮想化は正常に動作しません。
入れ子Hyper-Vのネットワーク方式を選ぶ
入れ子仮想化では、L2仮想マシンの通信をL0の外部ネットワークへ通すために、通常は次のどちらかを構成します。
| 方式 | 適している環境 | 長所 | 注意点 |
|---|---|---|---|
| MACアドレススプーフィング | 社内LAN、検証用物理PC | 構成が比較的単純 | 上位ネットワークが複数MACアドレスを許可する必要がある |
| NAT | クラウド、無線LAN、MACスプーフィングを許可できない環境 | L2をプライベートネットワークへ分離できる | IP、ゲートウェイ、DNSの管理が必要 |
Microsoftも、入れ子VMのネットワーク方式としてMACアドレススプーフィングとNATを案内しています。パブリッククラウドなど、MACアドレススプーフィングを利用できない環境ではNATが適しています。(Microsoft Learn)
OSをBuild 28000.2605へ更新しても、このどちらかのネットワーク方式を正しく構成する必要があります。
MACアドレススプーフィングを設定する手順
MACアドレススプーフィング方式では、L2仮想マシンの通信が、L1とL0の2段階の仮想スイッチを通過します。
L2が使用するMACアドレスをL0側の仮想スイッチへ通すため、L1仮想マシンの外向きネットワークアダプターでMACアドレススプーフィングを有効にします。(Microsoft Learn)
L1の接続先を確認する
L0の物理ホストで実行します。
Get-VMNetworkAdapter -VMName "L1-HyperV" |
Format-Table Name, SwitchName, MacAddressSpoofing, Status
確認する項目は次のとおりです。
- L1の仮想NICが目的の仮想スイッチへ接続されている
Statusが正常である- 外向きアダプターを識別できている
- 複数NICがある場合、管理用NICとL2通信用NICを混同していない
MACアドレススプーフィングを有効にする
L0の物理ホストで実行します。
Set-VMNetworkAdapter `
-VMName "L1-HyperV" `
-Name "<L1の外向きアダプター名>" `
-MacAddressSpoofing On
設定後、再度確認します。
Get-VMNetworkAdapter -VMName "L1-HyperV" |
Format-Table Name, SwitchName, MacAddressSpoofing
MacAddressSpoofingがOnになっていれば、Hyper-V側の設定は有効です。
MACスプーフィング方式で確認するポイント
設定を有効にしても通信できない場合は、次を確認してください。
- L1内部の仮想スイッチにL2の仮想NICが接続されているか
- 上位ネットワークにDHCPサーバーが存在するか
- 物理スイッチのポートセキュリティで複数MACアドレスが拒否されていないか
- VLAN IDがL0、L1、L2で一致しているか
- 無線LANアダプターやVPNクライアントが通信を制限していないか
- セキュリティソフトのネットワークフィルタードライバーが干渉していないか
MACアドレススプーフィングは、必要なL1仮想NICだけで有効にします。管理用ネットワークを含むすべての仮想NICへ無条件に設定するのは避けてください。
NAT方式を設定する手順
MACアドレススプーフィングを使用できない場合は、L1内に内部仮想スイッチとNATを作成します。
構成は次のようになります。
外部ネットワーク
↑
L0
↑
L1の外向きNIC
↑ NAT
VmNAT:192.168.100.0/24
↑
L2:192.168.100.10
以下のコマンドは、L1仮想マシン内のPowerShellで実行します。
既存の仮想スイッチとNATを確認する
Get-VMSwitch
Get-NetNat
同じ名前や同じIPアドレス範囲の設定がすでに存在する場合は、新しく重複作成しないでください。
内部仮想スイッチを作成する
New-VMSwitch -Name "VmNAT" -SwitchType Internal
L1側のゲートウェイアドレスを設定する
$Adapter = Get-NetAdapter -Name "vEthernet (VmNAT)"
New-NetIPAddress `
-InterfaceIndex $Adapter.ifIndex `
-IPAddress 192.168.100.1 `
-PrefixLength 24
NATを作成する
New-NetNat `
-Name "LocalNAT" `
-InternalIPInterfaceAddressPrefix "192.168.100.0/24"
Microsoftの公式手順でも、L1内に内部仮想スイッチとNATを作成し、L2仮想マシンへ同一サブネットのIPアドレスとNAT側のゲートウェイを設定する方法が案内されています。(Microsoft Learn)
L2仮想マシンへ設定する値
L2では、例えば次のように設定します。
| 項目 | 設定例 |
|---|---|
| IPアドレス | 192.168.100.10 |
| サブネットプレフィックス | 24 |
| デフォルトゲートウェイ | 192.168.100.1 |
| DNSサーバー | 組織内または外部へ到達可能なDNSサーバー |
複数のL2 VMを作成する場合、IPアドレスが重複しないように管理してください。
また、NAT用サブネットには、物理LAN、VPN接続先、Docker、WSL、ほかの仮想スイッチで使用していないアドレス範囲を選びます。例えば、接続先VPNでも192.168.100.0/24を使用している場合、経路が競合する可能性があります。
症状から原因を切り分ける
入れ子Hyper-Vのネットワーク問題は、症状によって確認すべき場所が異なります。
| 症状 | 主に確認する場所 |
|---|---|
L2が169.254.x.xになる | DHCP、静的IP設定、仮想スイッチ接続 |
| L2に仮想NICが表示されない | L2のVM設定、Hyper-V VMMS、プロビジョニング処理 |
| L2からゲートウェイへ到達できない | L1内部スイッチ、VLAN、IP設定 |
| ゲートウェイには到達できるが外部へ出られない | NAT、ルーティング、ファイアウォール |
| IPアドレスへは接続できるが名前解決できない | DNS設定 |
| L1は通信できるがL2だけ通信できない | MACスプーフィングまたはNAT |
| L1もL2も通信できない | L0の外部スイッチ、物理NIC、VPN、ドライバー |
| L2作成時にネットワーク設定が失敗する | Build 28000.2605の修正対象、VMMS、VmSwitchログ |
| 再起動するたびに接続状態が変わる | 段階的配信、仮想NICの関連付け、外部スイッチのバインド |
特に、L2がIPアドレスを持っているかどうかで、確認範囲を大きく絞り込めます。
L2のIP設定を確認する
L2仮想マシン内で実行します。
Get-NetIPConfiguration
または、コマンドプロンプトで次を実行します。
ipconfig /all
段階的に疎通確認する
L2から順番に確認します。
Test-NetConnection 192.168.100.1
次に、外部のIPアドレスへ接続できるかを確認します。
Test-NetConnection <接続確認先のIPアドレス> -Port 443
最後に、DNS名を使用して確認します。
Test-NetConnection <接続確認先のホスト名> -Port 443
IPアドレスでは成功し、ホスト名では失敗する場合、Hyper-VのプロビジョニングではなくDNS設定が原因である可能性が高くなります。
Hyper-Vの構成をPowerShellで確認する
L0とL1の両方で、次の情報を採取すると切り分けが容易になります。
仮想スイッチ一覧
Get-VMSwitch |
Format-Table Name, SwitchType, NetAdapterInterfaceDescription
仮想マシンのネットワークアダプター
Get-VMNetworkAdapter -All |
Format-Table VMName, Name, SwitchName, MacAddressSpoofing, Status
物理・仮想ネットワークアダプター
Get-NetAdapter |
Format-Table Name, InterfaceDescription, Status, LinkSpeed
NAT構成
Get-NetNat
IPアドレスと経路
Get-NetIPAddress
Get-NetRoute -AddressFamily IPv4
L0とL1で別々に結果を保存しておくと、どの階層で通信経路が途切れているかを判断できます。
イベントログを確認する
仮想マシン作成時や仮想スイッチ接続時にエラーが発生する場合は、Hyper-V関連のイベントログを確認します。
主なログは次の2つです。
アプリケーションとサービス ログ
→ Microsoft
→ Windows
→ Hyper-V-VMMS
→ Admin
アプリケーションとサービス ログ
→ Microsoft
→ Windows
→ Hyper-V-VmSwitch
→ Operational
PowerShellから確認する場合は、次のコマンドを使用できます。
Get-WinEvent `
-LogName "Microsoft-Windows-Hyper-V-VMMS/Admin" `
-MaxEvents 50
Get-WinEvent `
-LogName "Microsoft-Windows-Hyper-V-VmSwitch/Operational" `
-MaxEvents 50
MicrosoftのHyper-Vトラブルシューティング情報でも、VM管理上の問題を確認するログとしてHyper-V-VMMS/Adminが使用されています。(Microsoft Learn)
問題を再現した時刻を記録し、その直前と直後に出力されたエラーや警告を確認してください。単にイベントIDだけを見るのではなく、対象VM名、仮想NIC名、仮想スイッチ名、エラーコードを合わせて記録することが重要です。
仮想スイッチをすぐに削除しない
ネットワーク問題が発生すると、外部仮想スイッチを削除して作り直したくなります。しかし、外部仮想スイッチの再作成は、物理ホスト自身のネットワーク接続やIPアドレス設定にも影響します。
削除する前に、最低限次の情報を保存してください。
Get-VMSwitch | Format-List * |
Out-File "$env:USERPROFILE\Desktop\vmswitch.txt"
Get-VMNetworkAdapter -All | Format-List * |
Out-File "$env:USERPROFILE\Desktop\vmnetworkadapter.txt"
Get-NetAdapter | Format-List * |
Out-File "$env:USERPROFILE\Desktop\netadapter.txt"
Get-NetIPConfiguration | Format-List * |
Out-File "$env:USERPROFILE\Desktop\netipconfiguration.txt"
特にリモートデスクトップ経由で作業している場合、外部仮想スイッチの削除によって接続を失う可能性があります。現地操作手段やコンソール接続を確保してから実施してください。
本番環境ではInsiderビルドを修正目的だけで導入しない
Build 28000.2605はRelease Preview Channel向けです。Release Previewは将来の更新を事前検証するためのチャネルであり、通常の安定版Windows 11と同じ扱いにはできません。
環境ごとの判断基準は次のとおりです。
| 利用環境 | 推奨対応 |
|---|---|
| 個人の検証PC | バックアップ後にBuild 28000.2605で再現確認 |
| 研修・検証用Hyper-V | 更新前後の結果を比較 |
| 業務用PC | 修正目的だけでInsiderへ参加しない |
| 本番仮想化基盤 | 一般提供版への反映を確認してから適用 |
| パブリッククラウド上のL1 | MACスプーフィングよりNATを優先して検討 |
| 自動構築環境 | 新規作成、削除、再作成、再起動を繰り返して検証 |
一度だけL2 VMが通信できたことをもって、プロビジョニング問題が解消したと判断するのは不十分です。
次の操作を複数回実施し、結果が安定しているか確認します。
- L2 VMの新規作成
- 仮想ネットワークアダプターの追加
- 仮想スイッチの切り替え
- L2 VMの再起動
- L1 VMの再起動
- L0の再起動
- IPアドレス取得
- ゲートウェイへの疎通
- DNS名前解決
- 外部サービスへの接続
OS側の修正を評価する場合は、更新前と更新後で同じ構成、同じ操作、同じ確認項目を使用することが重要です。
現時点で取るべき対応
入れ子構成のHyper-Vでネットワークを正しくプロビジョニングできない場合は、次の順番で対応します。
まず、winverを実行し、Windows 11 version 26H1、OS Build 28000.2605であるかを確認します。該当する場合でも段階的ロールアウトであるため、Windows Updateの再確認と再起動を行います。
次に、L1仮想マシンのExposeVirtualizationExtensionsが有効かを確認します。そのうえで、ネットワーク方式がMACアドレススプーフィングなのかNATなのかを明確にし、必要な設定を見直してください。
問題が続く場合は、L2のIPアドレス、ゲートウェイ、DNSの順に疎通を確認し、Hyper-V-VMMSとHyper-V-VmSwitchのイベントログを採取します。
Build 28000.2605で修正が案内されたことは前進ですが、現時点ではWindows Insider Release Previewの情報です。本番環境では、Insiderビルドの導入を急ぐのではなく、既存構成の確認と回避策を優先し、一般提供版への正式な反映をMicrosoftのリリース情報で確認するのが安全です。

コメント