MENU

Surface Pro 8でVMwareがVT‑xエラー！Windows 11 VBSとWindows Helloを両立させる完全ガイド

Windows11

Surface Pro 8 に Windows 11 Pro 24H2 を導入すると、
「Virtualized Intel VT‑x/EPT is Not Supported」 というエラーで VMware Workstation 17 Pro 上の 64 bit VM が起動しなくなることがあります。
原因は Device Guard / Credential Guard（以下まとめて VBS） によるハードウェア仮想化の占有と、Surface 固有の UEFI 挙動が組み合わさる点にあります。本記事では VBS と Windows Hello を両立させつつ VMware を使う方法、または割り切って Hyper‑V に乗り換える手順を、検証ログと併せて詳解します。

目次

問題の全体像

Surface Pro 8 は第 11 世代 Tiger Lake‑U 世代の Intel CPU を搭載し、VT‑x と Second‑Level Address Translation(EPT) を正式サポートしています。
ところが Windows 11 が VBS を有効 にすると、Windows カーネルの Hyper‑V ハイパーバイザが常駐し、既存の VT‑x 機能を予約 します。この状態で VMware を起動すると、次のダイアログまたはログが出力されます。

VMware Workstation does not support nested virtualization on this host.
Module 'HV' power on failed.
Virtualized Intel VT-x/EPT is not supported.

単に VBS をオフにすれば解消しますが、Surface ファームウェアは「Windows Hello を再設定した瞬間に VBS を強制再有効化する」という特性があります。そのため 「VMware or Windows Hello」 の二択になりがちです。

主要機能の相関図

方策VMwareでVT‑x/EPTWindows Helloセキュリティ/VBS
VBS（Device Guard／Credential Guard）を完全に無効化◎再設定すれば概ね◎
※Surface 固有の再発例あり		▲（VBS停止）
VBSを維持し Hyper‑V に乗り換え△（VMware独自機能は不可）◎◎

アプローチ A：VMware を最優先（VBS を切る）

1. 事前確認

  • 管理者 PowerShell で systeminfo を実行し、Virtualization-based security が Running なら VBS が稼働中。
  • Windows セキュリティ > デバイス セキュリティ > コア分離 で “メモリ整合性” がオンになっていないか確認。

2. 無効化手順（推奨）

# ①Hyper-V 常駐ハイパーバイザ停止
bcdedit /set hypervisorlaunchtype off

②Hyper-V 機能そのものを外す

Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All

③必要に応じて Device Guard 構成を解除

.\DGReadinessTool\_v3.6.ps1 -Disable
  1. 上記コマンドを管理者 PowerShell で実行。
  2. 再起動後、ローカルパスワードでサインインし「設定 > アカウント > サインイン オプション」から Windows Hello を 一度無効化 → 再構成。
  3. 再起動して VMware を起動。VT‑x/EPT サポートが復活しているか確認。
  4. 3～6 日後に Surface UEFI が VBS を自動再有効化するケースがあるため、systeminfo と “コア分離” を定期確認。

3. 再発を防ぐコツ

  • レジストリ HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard に EnableVirtualizationBasedSecurity = 0 をポリシー側で固定しておく。
  • 企業ドメインの場合は Intune や GPO で “Credential Guard 無効化” を上書き。
  • ファームウェア更新が配信されたら適用の前後で VBS 状態をチェック。

アプローチ B：Windows Hello／セキュリティを最優先（Hyper‑V に乗り換え）

開発ターゲットが Windows Server や WSL2/Android エミュレータであれば、Hyper‑V ＋ WSL2 で大半のニーズを満たせます。Hyper‑V は VBS 前提で設計されているため、Windows Hello や BitLocker、Credential Guard と問題なく共存します。

Hyper‑V 乗り換え手順

  1. 「Windows の機能の有効化または無効化」で Hyper‑V プラットフォーム と ハイパーバイザ をオン。
  2. 再起動し、PowerShell の Get-VMProcessor でネスト仮想化(ExposeVirtualizationExtensions)を必要に応じて有効化。
  3. WSL2 や Windows 11 Dev Kit の Android Subsystem と組み合わせ、VMware で使っていた機能を置き換える。
VMware 機能Hyper‑V 代替
フル／差分スナップショットCheckpoints（自動/手動）
NAT / Host‑Only ネットワークDefault Switch / vSwitch + NAT ルール
仮想 TPM クローン運用Shielded VM & vTPM

Surface 固有の“VBS 再有効化”を回避するテクニック

Surface Pro 8 では Windows Hello カメラの再セットアップ時に UEFI が「自動 VBS 再設定フラグ」を ACPI 経由で OS に渡すケースがあります。以下の 2 つの設定が揃うと VBS が自動再有効化されるので注意してください。

  • UEFI セキュアブート → Microsoft Third‑Party UEFI CA がオン
  • “Platform TPM Provisioning” が Enabled, Full

これに該当する場合は、Surface UEFI(電源＋音量↑) で次を変更します。

  1. Secure Boot を有効のまま「Store keys only」に下げる。
  2. TPM Provisioning を Disabled に切替え、OS 起動後に tpmvscmgr.exe で再 Provisioning。

上記変更は BitLocker リカバリキーを要求する場合がありますので、作業前に回復キーをバックアップしておいてください。

トラブルシューティング チェックリスト

1. VBS 状態をコマンドで見る

# Device Guard 全体
Get-CimInstance -ClassName Win32_DeviceGuard

サービス単位

sc query hvhost
sc query lsaiso

2. VMware ログの該当行

2025-05-17T08:31:53.123Z In(05) vmx: HV: Checking for VT-x/EPT capabilities...
2025-05-17T08:31:53.125Z In(05) vmx: HV: Nesting is NOT permitted: Device Guard/Credential Guard is active.

3. Windows Hello 再設定前後の差分

# 再設定前
REG QUERY HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard /v EnableVirtualizationBasedSecurity
=> 0x0

再設定後

=> 0x1 (自動で書き戻される)

VBS 無効化時のリスクとメリット

観点VBS 有効VBS 無効
パスワード／証明書窃取耐性LSAISO が保護 (高)平文 LSASS (低)
悪意あるドライバブロックHVCI により署名必須署名無しカーネルドライバも可能
VMware ネスト仮想化性能不可100% 利用可
バッテリー稼働時間若干短いやや長い

FAQ

Surface ファームウェア更新で必ず解決しますか？

過去に登場した Surface Laptop 4、Surface Pro 9 でも類似事象があり、ファームウェア更新で緩和された例はありますが、恒久的に解決する保証はありません。最終的には Microsoft サポートへ報告し、共同検証が必要です。 VMware と Hyper‑V を共存させる「Windows Hypervisor Platform」は？

WHP 経由で VMware を動かすことは技術的には可能ですが、VT‑x ではなく enlightened VM モードになるため、パフォーマンスと一部機能が制限されます。本稿では開発用途の快適さを優先し、VBS を完全に切る方式を推奨しています。 職場のセキュリティポリシーで VBS 必須と言われている場合は？

ガバナンス要件がある場合は Hyper‑V 乗り換え（アプローチ B）一択となります。Intune または GPO で Turn On Virtualization Based Security = Enabled が配布されていると、ローカル側で設定を変えてもすぐ復旧します。

まとめ

Surface Pro 8 で VMware を快適に使う最短ルートは、VBS を完全オフ → Windows Hello を再構成 → レジストリ固定 です。ただし VBS を切ることでパスワード保護やカーネル整合性など複数の防御層を失います。テスト端末かつオフライン開発が中心なら許容できますが、業務用・情報資産を扱う場合は Hyper‑V への移行も射程に入れて評価してください。

サポート窓口早見表

目的連絡先備考
Surface 固有ハード／UEFI の不具合Microsoft サポート（Web・電話・チャット）チケットに「VBS と Windows Hello の競合で VMware が VT‑x エラー」と記載
コミュニティでの事例調査Microsoft Q&A / TechCommunity / VMware Community回避策やスクリプト例を参照

本記事が、仮想化環境とセキュリティ機能を両立させたいエンジニアの一助になれば幸いです。

Windows11
Windows 11 Surface Pro 8 VMware Workstation Device Guard Hyper‑V Credential Guard VT‑x Windows Hello

この記事を書いた人

佐藤健司のアバター 佐藤健司

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

関連記事

コメント

コメントする

目次