Windows 11 Insider Preview Build 26200でHyper‑V仮想マシンのネットワーク消失を直す方法（vNIC追加・入れ替え）

Windows 11 Insider Preview（Build 26200）適用後、Hyper‑V の仮想マシンで突然ネットワークが消え、サインイン直後に「インターネットに接続できません」状態になる事例があります。外部仮想スイッチの作り直しや付け替えで直らないときは、問題の vNIC を“作り直す”のが最短です。ここでは復旧手順と、静的 IP／DHCP 予約／VLAN など運用上の落とし穴までまとめます。

症状：Hyper‑V 仮想マシン内だけネットワークが消失する

対象は Windows 11 Insider Preview 10.0.26200（Build 26200）適用後に多く報告されるパターンで、ホスト側の物理 NIC や他の通信は生きているのに、ゲスト OS（VM）側だけ「ネットワークなし」になるのが特徴です。ログオン時のネットワーク依存処理（ドメイン参加、クラウドサインイン、ポリシー適用など）が絡むと、ログイン失敗や遅延として表面化します。

観測される現象	よくある状況	一時回避	根本対処
VM が「インターネットに接続できない」になりログインに失敗/遅い	プレビュー更新直後、同一ホスト上の複数 VM で同時発生	VM 再起動、外部スイッチ付け替え（効かない場合あり）	vNIC を追加→疎通確認→旧 vNIC を削除（実質的に作り直し）
外部仮想スイッチは存在し、他 VM は通信できるのに当該 VM だけ不可	スイッチ再作成でも改善しない	ゲスト側の IP 更新や Winsock リセット（まれに改善）	vNIC の“アイデンティティ崩れ”を回避するため新規 vNIC を生成
DHCP 取得できない/リンクは見えるが疎通しない	固定 IP、DHCP 予約、MAC 制御、VLAN 環境	IP を手動で再設定	新規 vNIC の MAC/VLAN/ポリシーを合わせ、旧 vNIC を除去

原因の考え方：vNIC の“識別情報”が崩れると付け替えでは直らない

Hyper‑V の仮想 NIC（vNIC）は、ホスト側（仮想スイッチ／アダプター設定）とゲスト側（デバイス識別子、ドライバー、ネットワークプロファイル、IP 設定、DNS、ファイアウォール適用など）の状態が噛み合って成立します。プレビュー更新でネットワークスタックや仮想化関連コンポーネントが更新されると、既存 vNIC の識別情報・バインド状態だけが「壊れたまま」残り、スイッチの付け替えやリセットでは復旧しないケースがあります。

このとき有効なのが「vNIC を新規に生成してゲスト/ホスト双方に“まっさら”な構成を作らせる」方法です。つまり、旧 vNIC を“修理”するより、新しい vNIC を作って入れ替える方が速いという発想になります。

作業前に最低限おさえるチェック（5分でできる）

いきなり vNIC を追加しても概ね戻せますが、運用環境だと「MAC 変更」「VLAN」「固定 IP」「セキュリティ製品のポリシー」あたりで詰まりやすいので、以下だけ先に控えておくと安全です。

VM 側で控えるもの

現在接続している仮想スイッチ名（外部スイッチ名）
旧 vNIC の VLAN 設定の有無（Access VLAN / Trunk など）
固定 IP／固定 DNS を使っているか
DHCP 予約、MAC アドレス制限、NAC（端末認証）等の利用有無
RDP や管理系ツールが「特定 NIC の IP」に依存していないか

ホスト側の簡易確認（外部スイッチが生きているか）

同じ外部仮想スイッチに繋いでいる別 VM は通信できるか
ホスト OS 自体はネットに出られるか
外部スイッチに紐づく物理 NIC が無効化/エラーになっていないか

PowerShell が使えるなら、ホストで次を確認しておくと切り分けが速いです。

# 物理NIC確認
Get-NetAdapter | Sort-Object Status, Name | Format-Table Name, Status, LinkSpeed, MacAddress

# 仮想スイッチ確認

Get-VMSwitch | Format-Table Name, SwitchType, NetAdapterInterfaceDescription

# VMのvNIC確認（VM名は置き換え）

Get-VMNetworkAdapter -VMName "VM名" | Format-Table Name, SwitchName, MacAddress, Status

最短復旧：問題のある vNIC を“作り直す”

結論はシンプルです。旧 vNIC をいじり倒すより、新しい vNIC を追加して通信を復旧→旧 vNIC を削除すると、壊れた識別情報やバインド状態を回避できます。

Hyper‑V マネージャーでの手順

影響を受けた VM を選択し、［設定］を開きます。
左の［ハードウェアの追加］から［ネットワークアダプター］を選び、［追加］します。
追加したネットワークアダプターの接続先を、従来と同じ「外部仮想スイッチ」に指定します。VLAN を使っている場合は同じ VLAN 設定も入れます。
［適用］→［OK］で閉じ、VM にサインインします。
ゲスト OS で IP 取得・DNS 解決・疎通（ブラウザ/ ping / nslookup など）を確認します。
通信が戻ったら、再度 VM の［設定］を開き、問題のあった旧アダプターを選択→［削除］→［適用］します。

ポイント：新規 vNIC を作ることで、ゲスト OS とホスト双方で NIC 構成が再生成され、破損した状態（いわば“アイデンティティ崩れ”）を迂回できます。外部仮想スイッチの再作成より影響範囲が狭く、復旧も速いのが利点です。

ゲスト OS 側での疎通確認チェックリスト

IP アドレスが付いたか（DHCP の場合）
DNS が引けるか（名前解決ができるか）
デフォルトゲートウェイへ pingできるか
社内リソース（AD / ファイルサーバー）へ到達できるか

# ゲストOS（Windows）側の例
ipconfig /all
ping 192.168.1.1
nslookup www.microsoft.com
tracert 8.8.8.8

運用でハマりがちな落とし穴（ここを見落とすと「直ったのに直ってない」）

vNIC を追加すると、ゲスト OS からは「別の NIC」として見えます。つまり、過去の NIC に紐づいた設定は自動で引き継がれない場合があります。特に次の項目は要注意です。

要注意ポイント	なぜ起きる	対処の要点
固定 IP／固定 DNS	新しい NIC は別インターフェースとして認識される	旧 NIC の値を控えておき、新 vNIC 側に再設定（IPv4/IPv6、DNS、メトリックも確認）
DHCP 予約	MAC が変わるため予約が外れる	DHCP サーバー側の予約を新 MAC に更新。必要なら vNIC を静的 MAC にして運用を安定化
NAC／MAC 制御／FW ルール	MAC や NIC 指紋に連動するポリシーがある	許可リスト更新、セキュリティ製品（EDR/ゼロトラスト）の端末扱いを再確認
VLAN 設定	新 vNIC に VLAN が未設定だと別セグメント扱いになる	Hyper‑V 側で VLAN ID を旧 NIC と揃える（アクセス VLAN / トランク利用時は要注意）
Windows のネットワークプロファイル（パブリック/プライベート）	新 NIC としてプロファイルが作り直される	必要に応じてプライベートに変更し、FW の受信ルール（RDP など）を再チェック
監視・資産管理	NIC 切替でホスト名同じでも識別子が変わることがある	監視対象の IP/MAC/エージェント状態を確認。アラート抑止が必要なら先に手当て

MAC アドレスを引き継ぎたい場合（DHCP 予約が多い環境向け）

多くの環境では DHCP 予約を更新するのが素直ですが、台数が多い・申請が重い環境だと「MAC を固定して動かしたい」こともあります。その場合は、Hyper‑V 側で新 vNIC を静的 MAC にするのが実務的です（ただし MAC 重複には注意）。

# 新vNICのMACを静的にする例（VM名とNIC名は置き換え）
Set-VMNetworkAdapter -VMName "VM名" -Name "NewNIC" -StaticMacAddress "00155D123456"

# 現在のMAC確認
Get-VMNetworkAdapter -VMName "VM名" | Format-Table Name, MacAddress

VLAN を使っている場合の注意

VLAN を使う現場では、旧 vNIC が VLAN 設定済みだったのに新 vNIC が未設定で、結果として「リンクはあるが通信できない」になりがちです。外部スイッチが同じでも VLAN が違えば別世界なので、必ず揃えます。

# Access VLAN の例
Set-VMNetworkAdapterVlan -VMName "VM名" -VMNetworkAdapterName "NewNIC" -Access -VlanId 20

# 設定確認
Get-VMNetworkAdapterVlan -VMName "VM名" -VMNetworkAdapterName "NewNIC"

PowerShell でまとめて復旧したい（管理者向け）

GUI で 1 台ずつ直すのが最も安全ですが、検証環境や多数 VM で同時に発生した場合は PowerShell が時短になります。以下は「新 vNIC を追加→外部スイッチに接続→一覧確認→旧 vNIC 削除」の基本形です。

# 新規 vNIC を追加して、外部スイッチに接続（VM名/スイッチ名は置き換え）
Add-VMNetworkAdapter -VMName "VM名" -Name "NewNIC" -SwitchName "外部スイッチ名"

# いま付いている vNIC を確認
Get-VMNetworkAdapter -VMName "VM名" | Format-Table Name, MacAddress, SwitchName, Status

# 旧 vNIC を削除（削除前に “NewNIC で疎通していること” を必ず確認）
Remove-VMNetworkAdapter -VMName "VM名" -Name "旧NIC名"

複数 VM を対象にする場合は、VM 名の配列を回して追加していくのが定番です。運用環境では、削除前に疎通確認とVLAN/固定 IP の再設定を挟んでください。

それでも不安定なときの追加トラブルシュート

ゲスト OS（Windows）側のネットワーク再初期化

新 vNIC 追加で概ね直るものの、ゲスト側に古い設定が残って挙動が怪しい場合は、次の順で軽めのリセットを試します（再起動が必要なものがあります）。

ipconfig /release
ipconfig /flushdns
ipconfig /renew

netsh winsock reset
netsh int ip reset
shutdown /r /t 0

また、ゲストのデバイスマネージャーに「非表示のデバイス」が大量に残っていると、プロファイルや優先度が混線することがあります。不要なゴースト NIC を整理するのは有効ですが、慎重に行ってください（誤削除すると別の NIC まで消えたように見えることがあります）。

ホスト側：外部仮想スイッチの再作成は“最後の手段”

複数 VM で同じ症状が出ていて、しかも vNIC 作り直しでも改善が薄い場合、外部仮想スイッチ自体に更新由来の不整合が残っている可能性があります。ただし外部スイッチの再作成はぶら下がる全 VM に影響するため、メンテナンス時間を確保して計画的に実施してください。

外部スイッチを消す前に、どの VM が接続しているか（一覧）を控える
チーミング（SET / LBFO）、Wi-Fi ブリッジ、VPN フィルタ、セキュリティ製品のフィルタドライバが絡む場合は特に慎重に
物理 NIC ドライバー更新やロールバックも検討（プレビュー環境ほど変化が大きい）

ログで状況を掴む

原因が vNIC 側か vSwitch 側か切り分けたいときは、ログが手がかりになります。

ホスト：イベントビューアー → Microsoft → Windows → Hyper‑V‑VmSwitch
ホスト：イベントビューアー → Microsoft → Windows → Hyper‑V‑Worker（VM のデバイス関連）
ゲスト：システムログ（NIC/ドライバー/ DHCP 関連のエラー）

「いつから」「どの VM が」「同時に」起きたかを時系列で見るだけでも、更新起因か個別要因かの判断がしやすくなります。

再発予防：Insider Preview で Hyper‑V を使うなら“戻れる設計”にする

プレビュー版は新機能検証の場である一方、ネットワークや仮想化のような基盤部分は変更の影響が出やすい領域です。業務影響を抑えるには、次の「戻れる・分ける・記録する」が効きます。

戻れる：更新前にチェックポイントと設定控えを残す

VM のチェックポイント（運用ポリシーに合わせて）
vNIC 名、MAC、VLAN、固定 IP/DNS、外部スイッチ名をメモ
DHCP 予約や FW の MAC 依存設定を一覧化

分ける：検証用ホスト／検証用スイッチを分離する

可能なら Insider Preview は検証用ホストに限定する
運用 VM と検証 VM を同じ外部スイッチに混在させない（影響範囲を局所化）
VPN やセキュリティ製品が絡む場合は、適用順序と例外設定を決めておく

記録する：更新履歴と発生条件を残して次回に活かす

「いつのビルドで」「どのホストで」「どの VM で」起きたか
vNIC 入れ替えで直ったか、VLAN や静的 IP の再設定が必要だったか
ログの該当箇所（重要イベント）

ロールバックという選択肢（業務影響が大きい場合）

Insider Preview の更新で業務が止まるのは本末転倒です。vNIC 作り直しで一旦復旧しても再発する、あるいは基盤全体が不安定な場合は、前ビルドへのロールバックや該当更新のアンインストールを検討してください。手順は環境（Insider チャネル、更新方式、保持期限）で異なるため、組織の運用ルールに合わせて実施します。

まとめ：最短は「新規 vNIC 追加→疎通→旧 vNIC 削除」

Windows 11 Insider Preview（Build 26200）適用後、Hyper‑V VM のネットワークが消失するケースがある
外部仮想スイッチの作り直しや付け替えで直らない場合、vNIC を作り直す（新規追加→旧削除）が最短
復旧後は固定 IP/DNS、DHCP 予約、MAC 制御、VLAN、FW ポリシーなど「NIC に紐づく設定」を必ず見直す
プレビュー版では“戻れる設計”が重要。影響が大きいならロールバックも視野に入れる

この記事を書いた人

佐藤健司

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

Windows 11 Insider Preview Build 26200でHyper‑V仮想マシンのネットワーク消失を直す方法（vNIC追加・入れ替え）

症状：Hyper‑V 仮想マシン内だけネットワークが消失する

原因の考え方：vNIC の“識別情報”が崩れると付け替えでは直らない

作業前に最低限おさえるチェック（5分でできる）

VM 側で控えるもの

ホスト側の簡易確認（外部スイッチが生きているか）

最短復旧：問題のある vNIC を“作り直す”

Hyper‑V マネージャーでの手順

ゲスト OS 側での疎通確認チェックリスト

運用でハマりがちな落とし穴（ここを見落とすと「直ったのに直ってない」）

MAC アドレスを引き継ぎたい場合（DHCP 予約が多い環境向け）

VLAN を使っている場合の注意

PowerShell でまとめて復旧したい（管理者向け）

それでも不安定なときの追加トラブルシュート

ゲスト OS（Windows）側のネットワーク再初期化

ホスト側：外部仮想スイッチの再作成は“最後の手段”

ログで状況を掴む

再発予防：Insider Preview で Hyper‑V を使うなら“戻れる設計”にする

戻れる：更新前にチェックポイントと設定控えを残す

分ける：検証用ホスト／検証用スイッチを分離する

記録する：更新履歴と発生条件を残して次回に活かす

ロールバックという選択肢（業務影響が大きい場合）

まとめ：最短は「新規 vNIC 追加→疎通→旧 vNIC 削除」

この記事を書いた人

コメント

コメントするコメントをキャンセル

Windows 11 Insider Preview Build 26200でHyper‑V仮想マシンのネットワーク消失を直す方法（vNIC追加・入れ替え）

症状：Hyper‑V 仮想マシン内だけネットワークが消失する

原因の考え方：vNIC の“識別情報”が崩れると付け替えでは直らない

作業前に最低限おさえるチェック（5分でできる）

VM 側で控えるもの

ホスト側の簡易確認（外部スイッチが生きているか）

最短復旧：問題のある vNIC を“作り直す”

Hyper‑V マネージャーでの手順

ゲスト OS 側での疎通確認チェックリスト

運用でハマりがちな落とし穴（ここを見落とすと「直ったのに直ってない」）

MAC アドレスを引き継ぎたい場合（DHCP 予約が多い環境向け）

VLAN を使っている場合の注意

PowerShell でまとめて復旧したい（管理者向け）

それでも不安定なときの追加トラブルシュート

ゲスト OS（Windows）側のネットワーク再初期化

ホスト側：外部仮想スイッチの再作成は“最後の手段”

ログで状況を掴む

再発予防：Insider Preview で Hyper‑V を使うなら“戻れる設計”にする

戻れる：更新前にチェックポイントと設定控えを残す

分ける：検証用ホスト／検証用スイッチを分離する

記録する：更新履歴と発生条件を残して次回に活かす

ロールバックという選択肢（業務影響が大きい場合）

まとめ：最短は「新規 vNIC 追加→疎通→旧 vNIC 削除」

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル