Windows 11でVBS有効時にVMware・VirtualBoxのVT-x/VT-dとGPUパススルーが使えない理由と対処法

Windows 11 で VBS（仮想化ベースのセキュリティ）を有効にしたまま、VMware Workstation や VirtualBox でネスト仮想化や GPU パススルーを使おうとすると、仕組み上どうしても越えられない壁があります。本記事では「なぜ動かないのか」を Hyper‑V と VBS の構造から丁寧に分解し、現実的に取り得る選択肢（設定例・運用パターン）までまとめて解説します。

前提環境とよくある症状

まず、想定している環境・状況を整理します。

ホスト OS：Windows 11 Pro / Pro N（24H2 を含む）
BIOS/UEFI：Intel VT‑x/VT‑d または AMD‑V/AMD‑Vi（IOMMU）を有効化済み
Windows 側：
- VBS（仮想化ベースのセキュリティ）、コア分離（メモリ整合性）＝オン
- WSL2、Windows Sandbox、仮想マシンプラットフォームなどを利用
サードパーティ製ハイパーバイザー：
- VMware Workstation Pro / Player
- Oracle VirtualBox

この環境で、例えば VMware のゲストにさらに Hyper‑V や ESXi を入れようとすると、次のようなエラーが出がちです。

「Virtualized Intel VT‑x/EPT is not supported on this platform」
「Virtualized AMD‑V/RVI is disabled or not supported on this platform」

また、VMware / VirtualBox から物理 GPU を直接パススルー（PCIe 直結）したり、VT‑d/AMD‑Vi を使った I/O 仮想化機能を有効化することもできません。

結論のざっくりまとめ

先に結論だけ整理すると、次のようになります。

VBS を有効にすると Windows ハイパーバイザー（Hyper‑V の土台）が必ず起動し、VT‑x/VT‑d は Hyper‑V が独占します。
その結果、VMware / VirtualBox は Hyper‑V の上に載る “二段目のハイパーバイザー” として動き、物理 VT‑x/VT‑d へ直接アクセスできません。
Nested 仮想化：WHP（Windows Hypervisor Platform）経由の「代理実装」としてなら ある程度は可能ですが、性能・互換性は限定的です。
I/O 仮想化（VT‑d/AMD‑Vi を使った PCIe/GPU パススルー）：WHP 経由では不可。VMware / VirtualBox から物理 GPU を独占させる API は公開されていません。
Hyper‑V の VM への dGPU 直パススルー（DDA）：正式サポートは Windows Server のみ。Windows 11 クライアントではサポート外です。
GPU を WSL や Sandbox が使えているのは GPU‑PV（GPU パラ仮想化） のおかげで、これは 共有型 であり DDA のような「丸ごと直結」とは別物です。

つまり、「VBS を維持したまま、VMware/VirtualBox から生の VT‑x/VT‑d を握る」ことは仕組み上不可能であり、実現したければ VBS/Hyper‑V か、サードパーティ製ハイパーバイザーかのどちらかを選ぶ必要があります。

なぜ VBS を有効にすると VT‑x/VT‑d が“横取り”されるのか

VBS の正体：Hyper‑V を使ったセキュリティ機構

VBS（Virtualization‑based Security）は、CPU の仮想化機能と Hyper‑V ハイパーバイザーを使って、Windows 内に「セキュリティ専用の隔離環境（VSM）」を作る仕組みです。

メモリ整合性（HVCI / コア分離）
Credential Guard、Application Guard など

これらはすべて「OS がハイパーバイザーの上で動いている」ことが前提になっています。つまり VBS をオンにした瞬間、あなたの Windows はすでに仮想マシンとして動いていると考えて構いません。

Hyper‑V の階層構造（L0/L1/L2）

x86 仮想化では、概念的に次のような階層があります。

レイヤー	役割	このケースでの実体
L0 ハイパーバイザー	物理 VT‑x/VT‑d を直接制御する最上位	Hyper‑V（VBS を有効にした Windows が勝手に起動）
L1 ハイパーバイザー	L0 の上で動くハイパーバイザー	VMware Workstation / VirtualBox（WHP モード）
L2 ゲスト	VMware/VirtualBox 上のゲスト OS	さらにその中で動く Hyper‑V / KVM 等

物理 VT‑x/VT‑d は L0 に 1 回だけしか割り当てられません。VBS を有効にした Windows では、必ず Hyper‑V が L0 を占有し、サードパーティ製ハイパーバイザーは L1 の“仮想ハードウェア”しか触れないという構造になっています。

Windows Hypervisor Platform（WHP）の正体

WHP は「Hyper‑V の上で動くための API」

WHP（Windows Hypervisor Platform）は、サードパーティが Windows のハイパーバイザー（Hyper‑V）上で CPU 仮想化を行うための API 群（WHv* 関数）です。

アプリ側からは WinHvPlatform.dll 経由で仮想プロセッサやメモリを操作
実際の CPU/メモリ制御は Hyper‑V が担当
VMware Workstation や VirtualBox は、Hyper‑V が有効なときにこの API を利用するモードを持つ

重要なのは、WHP はあくまで「既に動いている Hyper‑V の上で Type‑2 ハイパーバイザーを動かすための API」であり、Hyper‑V の権限を明け渡したり、PCIe デバイスを丸ごと他者に渡す仕組みではないことです。

VMware / VirtualBox が WHP モードで動くときのイメージ

項目	Hyper‑V 無効（素のハード）	Hyper‑V 有効 + WHP モード
VT‑x/AMD‑V	VMware/VirtualBox が直接使用	Hyper‑V が独占。VMware/VirtualBox は WHP 経由の仮想 CPU を使うだけ
VT‑d/AMD‑Vi（IOMMU）	ハイパーバイザーが直接制御し、PCIe パススルー等が可能	Hyper‑V が管理。WHP には「任意の PCIe を子パーティションへ丸投げする」API はない
性能	ほぼネイティブに近い	Hyper‑V を 1 段挟むためオーバーヘッド増（特に I/O）

このため、Hyper‑V を有効にしたまま VMware/VirtualBox に完全な Nested VT‑x + VT‑d を期待するのは物理的に無理、と理解しておくのが大切です。

サードパーティ製ハイパーバイザーで Nested 仮想化はどこまでできる？

VMware Workstation の場合

Hyper‑V が有効な Windows 11 では、VMware Workstation 17 以降は自動的に「Hyper‑V 互換モード（WHP モード）」で動作します。

前提となる Windows 側の設定

Windows ハイパーバイザープラットフォーム を有効化（optionalfeatures.exe → チェック）
VBS / コア分離をオンにしているなら、そのままで構わない（既に Hyper‑V は起動中）

VMware 側で Nested を試す設定

対象 VM の設定を開く
「ハードウェア」→「プロセッサ」
「Intel VT‑x/EPT または AMD‑V/RVI を仮想化（Virtualize Intel VT-x/EPT or AMD‑V/RVI）」 にチェック

Hyper‑V 無効環境では、この設定によりゲストからさらにハイパーバイザーを動かす「本物の Nested 仮想化」ができます。しかし Hyper‑V 有効環境では、

VMware → WHP → Hyper‑V → 物理 CPU

という多段構造のため、VMware が「仮想 VT‑x」を提供できるかどうかは WHP の実装と CPU に強く依存します。

実際、Windows 11 + Ryzen 環境などでは、「Virtualized AMD‑V/RVI is not supported on this platform」のようなエラーで Nested が有効化できないという報告も多く、Hyper‑V + WHP 経由の Nested は動作保証が非常に弱いのが現状です。

VirtualBox の場合

VirtualBox 6 以降は、Hyper‑V が有効な Windows では ホストの VT‑x ではなく Hyper‑V 経由の仮想化を利用する仕組みに切り替わりました。このため、Hyper‑V 有効時のパフォーマンス低下がよく話題になります。

VirtualBox のパラバーチャライゼーション設定

ゲスト OS の種類に合わせて、以下の設定が推奨されています。

Linux ゲスト：KVM
Windows ゲスト：Hyper‑V

ここでいう「Hyper‑V」はあくまで ゲストが見る仮想ハイパーバイザーの“顔”であり、VirtualBox 自身が Hyper‑V になるわけではありません。ただし、Windows 11 ホスト上で Hyper‑V が有効な場合、VirtualBox は内部的には WHP を利用して動くため、

Nested 仮想化を有効にしても安定して動かない
GPU 周りのパフォーマンス・互換性が悪化する

といった制限を受けやすくなります。

VT‑d/AMD‑Vi ベースの I/O パススルーが無理な理由

VT‑d / AMD‑Vi / IOMMU の役割

VT‑d や AMD‑Vi は、PCIe デバイスからの DMA を安全にサンドボックス化する IOMMU（I/O メモリ管理ユニット）の機能です。ハイパーバイザーはこれを使って、

特定の GPU/ネットワークカード/ストレージを、ある VM に 物理直結 する（他からは見えない）
DMA 可能なメモリアドレス範囲を VM ごとに分離する

といった高性能 I/O 仮想化を実現します。

Hyper‑V の DDA（Discrete Device Assignment）

Hyper‑V では DDA（Discrete Device Assignment）という機能で、PCIe デバイスを VM に丸ごとパススルーできます。公式ドキュメントでも、GPU や NVMe デバイスなどの利用例が紹介されています。

しかし重要なポイントは、

DDA は Windows Server の Hyper‑V でのみ正式サポート
Windows 10 / 11 クライアントの Hyper‑V は、基本的に DDA をサポートしない

ということです。Microsoft の Q&A でも、「DDA は Server バージョンのみサポート」と明言されています。

なぜ WHP 経由では I/O パススルーできないのか

WHP の API を見ると、主に以下のような機能が提供されています。

仮想パーティション（VM）の作成・設定・削除
仮想プロセッサの作成・レジスタ設定・実行
ゲスト物理メモリのマップ
仮想割り込みの配送

一方で、

「この物理 GPU を丸ごとパーティション X に渡せ」
「この PCIe バスを Hyper‑V ではなくサードパーティに管理させろ」

といった 物理デバイスを独占させるための API は存在しません。IOMMU を操作できるのはあくまで L0 ハイパーバイザー（Hyper‑V）だけであり、WHP を使う L1 ハイパーバイザーにはその権限が渡されない設計です。

つまり、Hyper‑V が動いている限り、VMware/VirtualBox から VT‑d を直接触るルートは用意されていないため、I/O パススルーは不可能ということになります。

Hyper‑V 側でできる GPU 仮想化：DDA と GPU‑PV

Windows Server + DDA（dGPU 直パス）

Windows Server では、Hyper‑V の DDA を使うことで、物理 GPU を VM に丸ごと割り当てられます。手順の概要は以下の通りです。

ホスト OS から対象 GPU を「ホストから切り離し、割り当て可能デバイス」にする
切り離したデバイスを特定の VM にアタッチ
ゲスト OS 内で通常どおり GPU ドライバーをインストール

この構成では、VM から見える GPU は「ほぼ物理そのもの」であり、CUDA/OpenCL などもネイティブ同様に動かせます。

ただし前述のとおり、この DDA は公式には Windows Server 専用機能であり、Windows 11 Pro にそのまま持ち込むことはできません。

Windows 11 で使われている GPU‑PV（パラ仮想化 GPU）

一方、Windows 11 では WSL2 や Windows Sandbox で GPU‑PV（GPU Paravirtualization） という技術が使われています。

物理 GPU をいくつかの「パーティション」に分割し、複数の VM/コンテナに同時提供
ホスト OS は引き続き GPU を 100% 利用できる
ゲスト側は「論理的な仮想 GPU」を通じて一部リソースを利用

WSL2 用 CUDA ドライバーなどは、この GPU‑PV を前提に実装されています。

ただし GPU‑PV は、

あくまで「共有型」の仮想化であり、
Hyper‑V の通常 VM に自由に GUI から割り当てられる仕組みではない

ため、「Hyper‑V VM に dGPU を直パスしたい」という要件の 代替として完全互換ではありません。コミュニティ製スクリプト（Easy‑GPU‑PV など）を使えば一般の Hyper‑V VM に GPU‑PV を割り当てることも技術的には可能ですが、サポート外であり、トラブルシュートも自己責任になります。

実用的な運用パターンと具体的な手順

ここまでの制約を踏まえ、現実的な選択肢を３つに整理します。

パターンA：VBS を維持しつつ、VM は「動く範囲」に割り切る

セキュリティ要件で「VBS 必須」の場合は、次のような割り切りが必要です。

VMware/VirtualBox は WHP 経由で動く範囲の Nested のみ使用
GPU をフルに使うワークロードは、
- ホスト OS 直接
- WSL2 + GPU‑PV
- Windows Sandbox
に寄せる
Hyper‑V の通常 VM への dGPU 直パスは諦める（Server 以外ではサポート外）

Windows 側のチェックポイントとしては、

msinfo32 →「仮想化ベースのセキュリティ：実行中」「ハイパーバイザーが検出されました：はい」になっていること
optionalfeatures.exe で「Windows ハイパーバイザープラットフォーム」「仮想マシンプラットフォーム」が有効になっていること

この状態で VMware/VirtualBox を利用し、「Nested は動けばラッキー、GPU 直結はそもそも無理」という前提で使うのが、VBS を維持する上での妥協点です。

パターンB：仮想化の自由度優先で VBS / Hyper‑V を無効化する

「どうしても VMware/VirtualBox に VT‑x/VT‑d を握らせたい」「ESXi や Proxmox をネストしたい」「GPU パススルーをサードパーティ側でやりたい」といったニーズでは、Hyper‑V/VBS を無効化して、サードパーティ製ハイパーバイザーを L0 にするしかありません。

大まかな手順

Windows セキュリティで メモリ整合性（コア分離）をオフにする。
- Windows セキュリティ →「デバイスセキュリティ」→「コア分離の詳細」→ メモリ整合性をオフ → 再起動。
必要に応じて DeviceGuard / VBS のレジストリやグループポリシーもオフにする。
管理者 PowerShell / コマンドプロンプトで、Hyper‑V の起動を止める：

bcdedit /set hypervisorlaunchtype off

（再度 Hyper‑V を使いたくなったら auto に戻します）

bcdedit /set hypervisorlaunchtype auto

この状態で再起動し、msinfo32 で「ハイパーバイザーが検出されました：いいえ」になっていれば、VMware/VirtualBox は再び物理 VT‑x/VT‑d を直接使用できます。

もちろん、これは VBS / Credential Guard / HVCI を犠牲にするトレードオフです。業務要件次第ではセキュリティ部門との調整が必要になるでしょう。

パターンC：本気で GPU パススルーをやりたい場合の現実解

「どうしても仮想マシンに GPU を直結したい」「RDP 越しに GPU ワークステーションとして使いたい」といった本格利用では、次のような構成が現実解です。

Windows Server + Hyper‑V + DDA
- ホスト OS を Windows Server にし、Hyper‑V と DDA で GPU を VM に直パス
- ゲスト OS は Windows / Linux どちらでも可（GPU ドライバ次第）
ベアメタル型ハイパーバイザー
- ESXi / Proxmox / oVirt / XCP‑ng などを 別マシン に構築
- そこで GPU パススルー（VFIO など）を実施
デュアルブート構成
- 日常利用は Windows 11 + VBS（セキュア）
- GPU パススルーが必要なときだけ、別 OS（例：Proxmox）でブート

残念ながら「Windows 11 + VBS を維持しつつ、同じマシンで VMware/VirtualBox に dGPU を直結」は、現状の設計ではほぼ不可能です。

よくある質問と誤解の整理

Q1. 「Hyper‑V の役割」を入れていないのに VT‑x が奪われているのはなぜ？

A. VBS / メモリ整合性（コア分離）を有効にするだけで、Hyper‑V ハイパーバイザーはバックグラウンドで起動します。Hyper‑V の「管理ツール」や「役割」を入れていなくても、VBS 機能が Hyper‑V を使っているためです。

Q2. Windows Hypervisor Platform を「オフ」にしたら解決する？

A. いいえ。WHP をオフにすると、VMware/VirtualBox が Hyper‑V の上で動くための API が消えるだけで、Hyper‑V 自体は VBS によって起動したままです。VT‑x/VT‑d の占有権は Hyper‑V のままなので、問題の本質的な解決にはなりません。

Q3. CPU が Nested Virtualization に対応していれば VMware の Nested も動く？

A. CPU の対応は前提条件ですが、最終的に支配権を持っているハイパーバイザー（ここでは Hyper‑V）がその機能をどう外部に見せるかが重要です。Hyper‑V 自身は Hyper‑V on Hyper‑V 用の Nested 機能を持っていますが、WHP 経由で VMware/VirtualBox に「好き放題に VT‑x を再仮想化させる」設計にはなっていません。

Q4. Hyper‑V VM に GPU‑PV を割り当てれば DDA の代わりになる？

A. 部分的には yes ですが、完全な代替ではありません。

GPU‑PV：ホストと複数 VM で GPU を共有。リソース配分は論理的で、ホストも引き続き GPU を利用。
DDA：GPU を完全に特定 VM に独占させる。ホストからはその GPU が消える。

AI 学習やゲームなど「GPU を100%占有したい」ケースでは、依然として DDA やベアメタル型ハイパーバイザーの方が適しています。

チェックリスト：自分の環境で何ができるかを一発で把握する

最後に、よくある構成パターンと「できること／できないこと」を表にまとめます。

構成	VBS	Hyper‑V	VMware/VirtualBox	Nested VT‑x	GPU 直パス
Windows 11 + VBS オン	オン	常時起動	WHP モード	一部可（制限大）	不可
Windows 11 + Hyper‑V 有効（VBS オフ）	オフ	オン	WHP モード	一部可	Hyper‑V VM でのみ（DDA＝Server のみ）
Windows 11 + Hyper‑V 完全無効	オフ	オフ	ネイティブモード	ほぼ自由（CPU 依存）	VMware/VirtualBox の機能次第
Windows Server + Hyper‑V + DDA	任意	オン	基本使わない想定	Hyper‑V VM 内で Nested 可	Hyper‑V VM に dGPU 直パス可

まとめ：VBS と「直ハード支配」は両立しないと考える

本記事のポイントを一行ずつに絞ると、次のようになります。

VBS を有効にすると、Hyper‑V が物理 VT‑x/VT‑d を独占し、Windows 自身も VM の一種になる。
VMware/VirtualBox はその上で動く「二段目のハイパーバイザー」となり、物理 VT‑x/VT‑d には直接触れない。
Nested 仮想化は WHP が許す範囲で部分的に可能だが、性能・互換性は限定的。
PCIe/GPU の直パス（VT‑d/AMD‑Vi）は WHP 経由ではできず、Hyper‑V の DDA も Server 専用機能。
本格的な GPU パススルーが必要なら、Windows Server やベアメタルハイパーバイザーなど、別レイヤーで設計する必要がある。

つまり、「VBS を保持したままサードパーティ製ハイパーバイザーに直ハード支配をさせる」という要件そのものが、x86 仮想化の設計と矛盾している、というのが根本の答えです。

運用としては、

セキュリティ最優先 → VBS/Hyper‑V を維持しつつ、サードパーティ製ハイパーバイザーは「動く範囲」利用
仮想化自由度・性能最優先 → VBS/Hyper‑V を止めて VMware/VirtualBox をネイティブ動作
GPU パススルー最優先 → Windows Server + DDA、またはベアメタル型ハイパーバイザーへシフト

という三択から、自分の要件に一番近いものを選ぶのが現実的です。

この記事を書いた人

佐藤健司

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

Windows 11でVBS有効時にVMware・VirtualBoxのVT-x/VT-dとGPUパススルーが使えない理由と対処法

前提環境とよくある症状

結論のざっくりまとめ