Hyper-Vで外部の仮想スイッチを作ったら、ネットワーク接続の一覧に「vEthernet (スイッチ名)」が増えた。元の「イーサネット」を開くと、設定していたIPアドレスが見当たらない。それでも通信はできている。外部・内部・プライベートのどれを選べばよかったのかも、はっきりしない。
3種類の違いは、「物理NICを通って外へ出られるか」と「ホスト自身がそのスイッチにつながる仮想NICを持つか」の2点で説明できます。 NICが増えたのも、IP設定が移ったのも、この2点で読めます。逆に、ここを理解しないまま既定の設定で進めると、ホストに同じネットワークのIPアドレスが2つ付き、ときどき通信がおかしくなる構成が出来上がります。
この記事は、無料動画「Hyper-Vネットワーク入門:仮想スイッチ設定法」を素材に、2026年10月18日時点のMicrosoft Learnで手順と用語を確かめて書きました。チーミング(複数NICの束ね)やVLANの詳細設計は扱いません。
Hyper-Vを入れると、ホストのWindowsも仮想マシンの1台になる
最初に押さえておきたいのは、Hyper-Vの役割を入れたあとのホストの位置付けです。元のWindowsの上に仮想マシンが載る、と考えがちですが、実際にはハイパーバイザーの上に、元のWindows(親パーティション、Hyper-Vマネージャーの用語では管理オペレーティングシステム)と仮想マシンが横に並びます。
親パーティションは物理デバイスを管理する特別な役目を持ちますが、ネットワークの見え方は仮想マシンと同じ考え方になります。だからホスト自身にも仮想NICが付くのです。無料動画の3分40秒からは、この「自分も仮想化されて横並びになる」関係を図で説明しています。
3種類の違いは、2つの問いで決まる
仮想スイッチは、ソフトウェアで作られたレイヤー2のイーサネットスイッチです(公式の概要「Hyper-V 仮想スイッチ」)。種類ごとの違いを、2つの問いで並べるとこうなります。
| 種類 | 物理NICを通って外のネットワークへ出られるか | ホストにこのスイッチ用の仮想NICができるか | 主な用途 |
|---|---|---|---|
| 外部 | 出られる(物理NICを1つ選ぶ) | 「管理オペレーティングシステムにこのネットワークアダプターの共有を許可する」のチェック次第 | 仮想マシンを社内LANに直接つなぐ |
| 内部 | 出られない | 必ずできる | ホストと仮想マシンだけの閉じたネットワーク、NATの土台 |
| プライベート | 出られない | できない | 仮想マシン同士だけの隔離されたネットワーク |
作成手順は公式「Hyper-V を使用して仮想スイッチを作成して構成する」にあり、外部を選んだときだけNICの選択が求められます。動画の6分5秒からは、仮想スイッチマネージャーで3種類から選ぶ画面、27分36秒からは「ホストにNICが増えるのはどれか」をまとめ直す場面です。
内部とプライベートの違いはチェックボックスではなく種類で選び、外部だけはチェックボックスで選ぶ。この非対称さが、Hyper-Vのネットワークを分かりにくくしている原因の1つです。
外部スイッチを作ると、元のNICは「スイッチ」に変わる
外部スイッチを作り、共有を許可するチェックを入れたままにすると、ネットワーク接続の一覧はこう変わります。
- 元の「イーサネット」は残るが、中身はNICではなく仮想スイッチになる。プロパティを開くと「Hyper-V 拡張可能仮想スイッチ」だけにチェックが入り、インターネットプロトコル(TCP/IP)のチェックは外れている
- 新しく「vEthernet (スイッチ名)」ができる。説明は「Hyper-V Virtual Ethernet Adapter」。ホストのIPアドレスやDNSの設定は、こちらに移っている
つまり「IPが消えた」のではなく、ホストが通信に使うNICが、物理NICから仮想NICに替わったのです。元のNICに改めてIPアドレスを設定し直す必要はありません。動画の7分53秒からでNICが増えた一覧を、10分42秒からで元のNICがスイッチに変わったことを、12分29秒からでそのプロパティ画面を確認できます。アイコンはNICのままなので、ここは画面で一度見ておくと迷いません。
公式手順にあるとおり、外部スイッチを作るときは「ネットワーク接続が中断される可能性がある」という警告が出ます。そのNIC経由でリモート接続している最中に作業すると、作業の途中で接続が切れることがあります。コンソールなど別の経路で操作できる状態にしてから始めてください。
今どうなっているかは、PowerShellで確かめられます。
Get-VMSwitch | Format-Table Name, SwitchType, NetAdapterInterfaceDescription, AllowManagementOS
Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
AllowManagementOS が True の外部スイッチがあれば、そのスイッチ用の「vEthernet」がホストに付いています。
「共有を許可する」は、ホスト用の仮想NICを挿すかどうかの質問
外部スイッチの画面にある「管理オペレーティングシステムにこのネットワークアダプターの共有を許可する」は、言葉からは意味が読み取りにくい項目です。実際に問われているのは、ホスト(管理OS)用の仮想NICを作って、このスイッチに挿すかどうかです。
- オン:ホストにvEthernetができ、仮想マシンと同じ物理NICを通って外へ出られる
- オフ:スイッチは仮想マシン専用になり、ホストはこの物理NICを通信に使わない
PowerShellでは -AllowManagementOS がこの設定にあたります。公式のNew-VMSwitchのリファレンスは、このパラメーターを「管理OSが、作成する仮想スイッチにバインドされた物理NICにアクセスできるかどうか」と説明しています。動画では13分24秒から、このチェックと仮想NICの関係を図で整理しています。
外部スイッチを1つ作り、ホストも仮想マシンも全部そこにつなぐだけなら、チェックはオンのままで問題ありません。仮想マシンを外部スイッチへつなぐ流れは動画の14分59秒からです。
管理用NICを分けたときの落とし穴:同じネットワークにホストのIPが2つ
動画で勧めているのが、仮想スイッチにしない管理用のNICを、ホストに1つ以上残しておく構成です。Hyper-Vまわりで問題が起きても、管理用の経路があればホストにリモートで入れます(17分12秒から)。
ここでやりがちな間違いがあります。NIC 1を管理用にそのまま残し、NIC 2で外部スイッチを作る。このときチェックをオンのままにすると、ホストには管理用NICとvEthernetの2つのNICが、同じネットワークに、それぞれIPアドレスを持って存在することになります。
すると、次のようなことが起きます。
- ホストから同じネットワークの相手へ送るとき、どちらのNICから出るかが状況で変わる
- ホスト名をDNSに登録するとき、どちらのIPアドレスが使われるかがずれる
- 出たNICと返事が届くNICが食い違い、いつもではなく、たまに通信がおかしくなる
この構成をあえて取る設計もあります。ただ、意図せずにこうなっているなら、外部スイッチのチェックを外して、ホストのvEthernetを無くせば済みます。ホストの通信は管理用NICだけになり、IPアドレスも1つに決まります。動画では18分13秒からがこの間違いの図、19分21秒からが何がまずいのかの説明、21分14秒からがチェックを外して解決する場面です。
実際に通信がどちらのNICから出ているかは、Test-NetConnection の出力にある SourceAddress(送信元IP)と InterfaceAlias(使ったインターフェイス)で確かめられます。読み方はpingは通るのに接続できない原因と切り分けにまとめました。
ホストがドメインコントローラーなら、DNS登録まで確かめる
複数のNICとIPアドレスを持つマルチホームの状態は、ドメインコントローラーでは特に影響が大きくなります。ドメインコントローラーは自分のIPアドレスをDNSに登録し、クライアントはそれを引いて接続先を決めるからです(この仕組みはActive DirectoryとDNSの関係で詳しく扱っています)。
公式の「マルチホーム ドメイン コントローラー上の DNS に不要な NIC を登録しないようにする手順」は、不要なNICのアドレスがDNSに登録されると、クライアントが到達できないアドレスを受け取って接続できなくなる現象と、NICの「この接続のアドレスを DNS に登録する」を外すなどの対処を説明しています。無料動画「ドメインコントローラー構築時の落とし穴」でも、10分0秒からでマルチホーム構成が推奨されない理由を、13分54秒からでDNSへ登録させるべきIPアドレスの考え方を図で説明しています。
内部とプライベートは、「ホストも話すか」で選ぶ
内部とプライベートは、どちらも物理NICとは関係のない、ホストの中に閉じたスイッチです。違いはホストが参加するかどうかだけです。
内部スイッチの使いどころの1つがNATです。公式「NAT ネットワークを設定する」では、内部スイッチを作り、ホスト側のvEthernetにゲートウェイとなるIPアドレスを付け、New-NetNat でNATを構成します。社内LANのアドレスを使わずに、仮想マシンを外へ出したいときの選択肢です。同じ記事には、現時点ではホストごとにNATネットワークは1つに制限されていること、NAT自体は仮想マシンにIPアドレスを配らないので、仮想マシン側でIPアドレス・既定のゲートウェイ・DNSを設定する必要があることも書かれています。
プライベートは、本番のネットワークから完全に切り離した検証用ネットワークを作るときに向いています。ホストからも触れないので、検証中の仮想マシンが社内へ影響しません。
検証環境は、スイッチの設計ごと作り直せるようにしておく
Hyper-Vの仮想スイッチを理解しておくと、手元の検証環境を組むときに役立ちます。無料動画「企業でよくあるWindows/M365環境 Part 5」では、1分20秒から、1台の物理サーバーの仮想マシンでさらにHyper-Vを動かす入れ子の構成で、Active Directoryの検証環境を作る前提を説明しています。
メンバー限定の「AnsibleでActive Directory環境を完全自動構築」では、6分57秒から、Hyper-V上の仮想マシンをすべて消した状態から、Ansibleのプレイブックを実行し、ドメインコントローラーの構築からクライアントのドメイン参加までを自動で作り直す流れを見られます。手で作った環境は、どのスイッチにどの仮想マシンをつないだかが記録に残りません。コードにしておけば、壊しても同じ構成に戻せます。この「まるごと作り直す」感覚は、文字よりも実際に消えて戻る画面で見るほうが伝わります。メンバーでない場合は、リンク先でメンバーシップの案内が表示されます。
LinuxをHyper-Vの仮想マシンとして立てる使い方もあります。メンバー限定の「WindowsユーザーのためのWSL2入門」の9分12秒からでは、Claude CodeをLinuxで動かす環境として、WSL2・専用のLinuxサーバー・Hyper-V上の仮想マシンなどの選択肢を比べています。この動画は仮想スイッチの設定そのものは扱っていないので、どの環境で動かすかを決める段階の参考にしてください。
まとめ:仮想スイッチを作る前に決めること
- 仮想マシンは社内LANに直接出る必要があるか。あるなら外部、無いなら内部かプライベート
- ホスト自身もそのスイッチで通信するか。外部ならチェック、内部とプライベートは種類で決まる
- 管理用NICを別に残すなら、外部スイッチのチェックを外し、同じネットワークにホストのIPが2つ並ばないようにする
- 作ったあとは「vEthernet」が何個あり、どれにIPアドレスが付いているかを
Get-VMSwitchとGet-NetAdapterで確かめる - ホストがドメインコントローラーを兼ねるなら、DNSに登録されているIPアドレスまで確かめる
NICが増えた一覧を見て慌てたら、まず「元のNICはスイッチになり、ホストは新しいvEthernetで通信している」と読み替えてください。その一覧が、ここまでの2つの問いへの答えをそのまま表しています。







