入れ子構成のHyper-Vでネットワークをプロビジョニングできない問題を修正|Windows 11 26H1

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)

今回の情報を整理すると、次のとおりです。

項目内容
対象OSWindows 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)

それぞれの役割は次のとおりです。

階層役割
L0Windows 11が動作する物理Hyper-Vホスト
L1L0上で動作し、内部にHyper-Vを構成した仮想マシン
L2L1上の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)

対象ビルドへ更新した後は、次の順番で確認します。

  1. Windows Updateで更新プログラムを再確認する
  2. 保留中の更新プログラムをすべてインストールする
  3. Windows 11を再起動する
  4. winverでビルド番号を再確認する
  5. L1とL2の仮想マシンを再起動する
  6. 新規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対応CPUWindows 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へ参加しない
本番仮想化基盤一般提供版への反映を確認してから適用
パブリッククラウド上のL1MACスプーフィングより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のリリース情報で確認するのが安全です。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次