MENU

Win32_Processor.VirtualizationFirmwareEnabled が false になる原因と対処法【Windows 11／Dell EBT2250 実機検証】

Windows11

Windows 11で仮想化は問題なく動いているのに、PowerShellで Win32_Processor.VirtualizationFirmwareEnabled を取得すると False が返ってしまう――最近のDell製デスクトップや最新CPU環境で、同じ戸惑いを感じている管理者は少なくありません。本記事では、Dell EBT2250／Core Ultra 9 285K 実機での事象を軸に、この挙動の意味と影響、そして運用上の安全な対処法を整理します。

目次

前提と症状の整理

今回テーマにしているのは、以下のような状況です。

  • 機種：Dell EBT2250（Tower Plus）、CPU：Intel Core Ultra 9 285K
  • OS：Windows 11（Pro想定）
  • BIOSで「Intel Virtualization Technology（VT‑x）」「VT‑d」などは有効化済み
  • Hyper‑V、WSL2、VBS（仮想化ベースのセキュリティ）も実際に動作している
  • にもかかわらず、以下のコマンドが False を返す
Get-WmiObject -Class Win32_Processor | Select-Object VirtualizationFirmwareEnabled

同様の「仮想化は動いているのに VirtualizationFirmwareEnabled が false」という報告は、Microsoft Q&A や GitHub の WSL Issue、Stack Overflow などでも複数確認できます。 特に Dell EBT2250 / Core Ultra 9 285K 環境で同じ症状が報告されており、単なる個体不良ではなく、ある程度機種依存の傾向があると考えられます。

VirtualizationFirmwareEnabled の意味を正しく理解する

Win32_Processor クラスの VirtualizationFirmwareEnabled は、一般に「CPU がハードウェア仮想化をサポートしており、かつファームウェア（BIOS/UEFI）でその機能が有効化されているかどうか」を示すフラグとして説明されます。

ただし重要なのは、これはあくまで「OS がファームウェアからそう申告されていると認識しているか」というインジケータに過ぎず、実際の Hyper‑V や WSL2 の起動可否を直接決めているスイッチではないという点です。

より具体的には、Windows が仮想化を利用する際には、以下のような複数の情報源を組み合わせて判断します。

  • CPU の CPUID 命令から取得できる仮想化拡張（VT‑x/AMD‑V、EPT/SLAT など）の有無
  • ACPI テーブルや SMBIOS を通じたファームウェア設定の反映
  • Boot パラメータ（hypervisorlaunchtype など）
  • Secure Boot / TPM / IOMMU など、VBS に必要なハードウェア機能

VirtualizationFirmwareEnabled はこのうちの「ファームウェア側の申告値」に近いものであり、これ単体が False でも、他の条件と整合が取れていれば Hyper‑V や WSL2 は動作し得ます。

なぜ「false」でも Hyper‑V や WSL2 が動くのか

実環境で Hyper‑V や WSL2 が問題なく動いているのに VirtualizationFirmwareEnabled = False となるのは、一言で言うと「ファームウェア→OSへの通知ロジックと、WMIクラスの実装が噛み合っていない」ためと考えられます。

想定されるパスを簡略化すると、次のようになります。

レイヤ実際にしていることVirtualizationFirmwareEnabled への関わり
CPUVT‑x/VT‑d/SLAT などの機能そのものを提供CPUID で能力を申告。通常ここは正しく機能している
BIOS/UEFI設定画面で VT を有効化し、ACPI/SMBIOS で OS に通知ここが新CPU/新チップセットでの実装差異の影響を受けやすい
Windows カーネルCPUID や ACPI 情報を読み取り、Hyper‑V/VBS を起動仮想化自体の有効/無効を決定する主役
WMI（Win32_Processor）内部の情報を WMI クラスとして公開ここで VirtualizationFirmwareEnabled を計算・報告する

どこか一箇所で「新しい CPU ファミリに対して判定条件が古いまま」などの不整合があると、

  • Hyper‑V や WSL2 は正常に動作する
  • しかし VirtualizationFirmwareEnabled だけ古い判定ロジックを使っており False を返す

という状況が起こり得ます。Dell EBT2250 / Core Ultra 9 285K での報告も含め、特定機種・特定世代の CPU で偏って発生していることから、OS 全体の仕様変更というよりはファームウェア実装＋WMI 側の互換性問題と見るのが自然です。

Dell EBT2250 / Core Ultra 9 285K 環境での状況

Dell EBT2250（Tower Plus）＋ Core Ultra 9 285K ＋ Windows 11 という組み合わせでは、

  • BIOS で VT‑x / VT‑d を有効化
  • Hyper‑V や WSL2 は動作
  • Task Manager では「仮想化：有効」と表示
  • しかし Win32_Processor.VirtualizationFirmwareEnabled は False

という報告が複数存在し、Dell コミュニティでも同様のスレッドが立っています。 また、Microsoft Q&A でも同じクラス・同じプロパティについて「自作PCでは True だが特定機種では False になる」というやり取りがあり、回答者も「OS というより UEFI/BIOS/ファームウェア互換性の可能性が高い」とコメントしています。

2025年11月時点で、Microsoft が「Windows 11 の仕様として、仮想化が動作していても VirtualizationFirmwareEnabled は False を返す」と明言した公式ドキュメントは確認できません。また、この挙動を「既知の不具合」として Windows Update のリリースノートに明記している情報も見当たりません。

つまり現状では、「仕様としてそうなっている」と断言することも、「必ずバグである」と断定することも難しく、実態としては機種依存の互換性問題が OS 上に見えてしまっている状態と考えておくのが現実的です。

Device Guard / Credential Guard への影響

次に一番気になるポイント、「Device Guard / Credential Guard に影響はあるのか？」です。

Device Guard や Credential Guard は、総称して「仮想化ベースのセキュリティ（VBS）」機能群に属しており、ハイパーバイザーと Secure Boot、TPM などを組み合わせて、機密情報を隔離した保護領域に格納します。

これらの機能が有効かどうかを確認する際に重要なのは、Win32_DeviceGuard の状態です。

Get-CimInstance -ClassName Win32_DeviceGuard `
  -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object SecurityServicesConfigured,
                SecurityServicesRunning,
                VirtualizationBasedSecurityStatus

Microsoft のドキュメントや各種検証記事によると、SecurityServicesRunning は「どの VBS サービスが実際に稼働しているか」を示す配列で、以下のような値が返ります。

値意味（代表例）
0VBS 関連サービスは動作していない
1Credential Guard が稼働
2Memory Integrity（HVCI）が稼働
3 以降System Guard Secure Launch や SMM 測定など他の保護機能

また、Microsoft 公式は Credential Guard の有効性確認方法として、

  • msinfo32.exe（システム情報）で「仮想化ベースのセキュリティ サービスの構成／実行中」を確認
  • 上記の Win32_DeviceGuard を PowerShell で確認
  • Event Viewer の DeviceGuard ログ

などを推奨しており、Win32_Processor.VirtualizationFirmwareEnabled を唯一の判断材料として挙げてはいません。

つまり、

  • ハイパーバイザーが起動しており（systeminfo の Hyper‑V 要件がすべて「はい」）
  • Win32_DeviceGuard.SecurityServicesRunning や msinfo32 上で Credential Guard / Memory Integrity が「実行中」となっている

のであれば、VirtualizationFirmwareEnabled が False だからという理由だけで Device Guard / Credential Guard が止まる、ということは考えにくいと言えます。

確認と切り分けに使える PowerShell コマンド

ここからは、実際の検証で使えるコマンド群を整理します。従来の Get-WmiObject は非推奨なので、基本的には Get-CimInstance を優先しましょう。

CPU とファームウェアの仮想化サポート状況

Get-CimInstance -ClassName Win32_Processor |
  Select-Object Name,
                VirtualizationFirmwareEnabled,
                VMMonitorModeExtensions,
                SecondLevelAddressTranslationExtensions
  • VMMonitorModeExtensions … VT‑x / AMD‑V が有効な場合に True
  • SecondLevelAddressTranslationExtensions … EPT/SLAT が有効な場合に True

VirtualizationFirmwareEnabled だけが False で、他が True なら、「仮想化自体は有効で通知ロジックだけがおかしい」という推測に説得力が出ます。

Hyper‑V ハイパーバイザーの有効化状態

Get-WindowsOptionalFeature -Online `
  -FeatureName Microsoft-Hyper-V-Hypervisor

状態が Enabled で、再起動後に systeminfo の「Hyper‑V の要件」がすべて「はい」となっていれば、Hyper‑V が正しく稼働できる土台は整っています。

systeminfo | findstr /I "Hyper-V"

VBS / Device Guard / Credential Guard の状態

Get-CimInstance -ClassName Win32_DeviceGuard `
  -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object SecurityServicesConfigured,
                SecurityServicesRunning,
                VirtualizationBasedSecurityStatus

ここで VirtualizationBasedSecurityStatus や SecurityServicesRunning に値が入っていれば、VBS は実際に稼働しています。

WSL2 / 仮想マシンプラットフォーム

Get-WindowsOptionalFeature -Online `
  -FeatureName VirtualMachinePlatform,
               Microsoft-Windows-Subsystem-Linux

Docker や WSL2 でエラーが出る場合、このあたりの有効化／再有効化が効くケースもあります。

コマンドと用途の対応表

コマンド確認できること
Get-CimInstance Win32_ProcessorCPU 仮想化機能とファームウェア申告値
systeminfo | findstr "Hyper-V"Hyper‑V 要件（SLAT/VT/VMモニタ拡張など）
Get-WindowsOptionalFeature ... Hyper-V-HypervisorHyper‑V ハイパーバイザーのインストール有無
Get-CimInstance Win32_DeviceGuardVBS / Device Guard / Credential Guard の構成・稼働状況
msinfo32.exeGUI での VBS / Credential Guard の状態

推奨される対処手順（優先度順）

1. UEFI/BIOS とベンダードライバを最新化

  • Dell サイトから EBT2250 向けの最新 BIOS を適用
  • チップセットドライバ、Intel ME（管理エンジン）、ストレージ、電源管理など、Dell 提供の純正ドライバを漏れなくインストール
  • BIOS の仮想化関連設定は「Auto」ではなく「Enabled」を明示的に選択（Intel VT‑x、VT‑d、あるいは IOMMU など）
  • 設定変更後は完全シャットダウン → 数秒待ってから電源投入（いわゆるコールドブート）

既に最新 BIOS にしても VirtualizationFirmwareEnabled が False という報告もあるため、これだけで必ず解消するとは言えません。しかし、ベンダーに問い合わせる際も「最新 BIOS / ドライバで再現しているか」は必ず聞かれるため、最初に済ませておく価値があります。

2. CIM ベースで再取得し、複数ソースを突き合わせる

Get-WmiObject はレガシー API なので、Get-CimInstance でも同様に False になるかを確認します。

Get-CimInstance -ClassName Win32_Processor |
  Select-Object Name,
                VirtualizationFirmwareEnabled,
                VMMonitorModeExtensions,
                SecondLevelAddressTranslationExtensions

並行して、先述の Win32_DeviceGuard や systeminfo、msinfo32 の表示も確認し、

  • 仮想化や VBS 自体は問題なく動作している
  • しかし VirtualizationFirmwareEnabled だけが False で一貫している

という状態であれば、「機能影響は小さいが、監査指標としては信頼すべきではない」という整理がしやすくなります。

3. 構成管理・監査ロジックの見直し

社内ツールやスクリプトで「VirtualizationFirmwareEnabled が True かどうか」だけをもって、

  • Hyper‑V 対応マシンか否か
  • Credential Guard 要件を満たしているか

といった判定をしている場合、EBT2250 のような環境では誤検知（偽陰性）が発生します。

実務上は、例えば次のようなロジックへの変更を検討すると良いでしょう。

  • CPU 機能：VMMonitorModeExtensions と SecondLevelAddressTranslationExtensions が True
  • ハイパーバイザー：systeminfo の Hyper‑V 要件がすべて「はい」
  • VBS：Win32_DeviceGuard.VirtualizationBasedSecurityStatus が有効値
  • Credential Guard：Win32_DeviceGuard.SecurityServicesRunning に 1 が含まれる、または msinfo32 で Credential Guard が「実行中」

VirtualizationFirmwareEnabled は、あくまで「参考情報」程度に格下げし、必須条件から外しておくのが安全です。

4. ベンダー（Dell）へのエスカレーション

ここまで確認した結果、

  • 最新 BIOS / ドライバ適用済み
  • VT‑x / VT‑d / SLAT は有効
  • Hyper‑V / WSL2 / VBS / Credential Guard は動作
  • それでも VirtualizationFirmwareEnabled は False

という状況であれば、Dell サポートに以下の情報を添えて問い合わせましょう。

  • 機種名、シリアル、BIOS バージョン
  • Windows 11 のエディションとビルド
  • 上記 PowerShell コマンドの出力（スクリーンショットかテキスト）
  • 「他機種では True を返す」「Dell コミュニティで同様の報告がある」旨

あわせて Microsoft 側にも Feedback Hub などから「特定機種で VirtualizationFirmwareEnabled が False になるが仮想化は動作する」というフィードバックを送っておくと、将来的に OS 側の判定ロジックが改善される可能性もあります。

監査・セキュリティ準拠チェックの設計を見直す

企業環境では、CIS ベンチマークや社内セキュリティ基準に沿って「仮想化ベースのセキュリティ必須」「Credential Guard 必須」といった要件を課すケースが増えています。その際、

  • VirtualizationFirmwareEnabled だけで判定していると、EBT2250 のような環境が誤って「非準拠」と評価される
  • 「誤検知が多すぎて、現場が基準そのものを信じなくなる」という逆効果も起こり得る

ため、チェックロジックは少し手間をかけてでも複数の根拠を組み合わせることをおすすめします。

例えば、次のような構成です。

  • VBS 必須：
    • Win32_DeviceGuard.VirtualizationBasedSecurityStatus > 0 を必須条件にする
  • Credential Guard 必須：
    • Win32_DeviceGuard.SecurityServicesRunning に 1 が含まれるか
    • または msinfo32 で「Virtualization-based Security Services Running」に Credential Guard が含まれる
  • Hyper‑V 対応必須：
    • VMMonitorModeExtensions と SecondLevelAddressTranslationExtensions が True
    • systeminfo の Hyper‑V 要件がすべて「はい」

こうした「実際の稼働状況に紐づく指標」をメインに据えれば、VirtualizationFirmwareEnabled に多少の誤差があっても、実運用の安全性を損なわずに運用できます。

よくある誤解と注意点

誤解1：VirtualizationFirmwareEnabled = False なら必ず VT 無効

実際には、VT‑x/VT‑d が有効で Hyper‑V や WSL2 が動作しているのに False となるケースが複数報告されています。 このプロパティはあくまで「ファームウェア側の申告値の一部」であり、絶対的な真偽値ではありません。

誤解2：Windows 11 Home では仕様として False

WSL2 は Windows 11 Home でも「仮想マシンプラットフォーム」機能の上で動作可能であり、エディションによって VirtualizationFirmwareEnabled の挙動が必ず変わる、という公式情報はありません。 実際、Home でも True を返す環境があります。

誤解3：このフラグが False だと Credential Guard は使えない

Credential Guard の要件は、64bit OS、UEFI、VT‑x/AMD‑V＋SLAT、TPM、Secure Boot などであり、その可否判定には Win32_DeviceGuard や msinfo32 の VBS ステータスが利用されます。 VirtualizationFirmwareEnabled が False でも、他の条件を満たしていれば Credential Guard が稼働しているケースは十分考えられます。

誤解4：仮想化ツール（VirtualBox, VMware など）が使えていれば問題なし

VirtualBox や VMware Workstation のようなホスト型ハイパーバイザーは、Hyper‑V と排他的に動作することも多く、Windows 側の VBS や Device Guard と競合するケースがあります。 VirtualizationFirmwareEnabled の True/False に関係なく、「どのハイパーバイザーがどのレイヤで動いているか」を意識して設計する必要があります。

Q&A：元の質問への直接回答

Q1. これは Windows 11 の仕様上あり得る挙動か？

公式ドキュメントで「仮想化が実際に動作していても VirtualizationFirmwareEnabled が False を返す」と明言している記述はなく、仕様として積極的に定義されている挙動ではないと考えられます。一方で、Windows 11 かつ複数ベンダーの環境で「仮想化は正常・フラグだけ False」という事例が散見されるため、OS の設計上は想定外だが、実際には機種依存の互換性問題として発生しているグレーな挙動と見るのが妥当です。

Q2. 仕様外なら修正予定はあるか？

2025年11月時点で、この挙動を「既知の不具合」として扱い、修正予定を明記した情報は見つかりませんでした。 将来の Windows Update や BIOS アップデートで静かに改善される可能性はありますが、確定的なスケジュールは公開されていません。そのため、現実的には「当面はワークアラウンドとして、監査ロジックを Win32_Processor から Win32_DeviceGuard などへ切り替える」という方針を取るのが安全です。

Q3. Device Guard / Credential Guard 等の機能に影響するか？

Hyper‑V / VBS / Credential Guard は、実際には Win32_DeviceGuard や VirtualizationBasedSecurityStatus など、別の指標と実際のハイパーバイザー動作を基準に制御されています。 従って、仮想化機能が稼働しており、かつ Device Guard / Credential Guard が実際に「実行中」と判定されている限り、VirtualizationFirmwareEnabled が False であることが直接のブロッカーになる可能性は低いと考えられます。

ただし、

  • 社内の監査スクリプト
  • サードパーティの診断ツール

などが、このフラグだけを見て「仮想化が無効」と判定している場合、レポート上は「要件を満たしていない」と誤判定される点には注意が必要です。

まとめ

  • Win32_Processor.VirtualizationFirmwareEnabled は、ファームウェアが仮想化を有効として申告しているかどうかのインジケータに過ぎず、仮想化機能そのもののスイッチではない。
  • Dell EBT2250 / Core Ultra 9 285K など一部環境では、仮想化が実際に動作していてもこのフラグが False になる事例が複数報告されており、OS 全体の仕様というより、UEFI/BIOS 実装や WMI 側の互換性問題である可能性が高い。
  • Device Guard / Credential Guard の有効性判定には Win32_DeviceGuard や msinfo32 が用いられており、このフラグ単体が False だからといって、直ちに機能が無効になるとは限らない。
  • 実務上は、BIOS/ドライバの最新化と複数ソースでの確認を行ったうえで、VirtualizationFirmwareEnabled を監査の唯一の判定根拠に使わないよう、スクリプトや基準を見直すことが重要。
  • 問題が残る場合は、ログとコマンド結果を整理して Dell サポートや Microsoft へ情報提供しつつ、「誤検知を減らす」方向で自組織の監査ロジックをチューニングしていくのが現実的な解決策となる。

「フラグの値」だけを見て一喜一憂するのではなく、「Hyper‑V / WSL2 / VBS が期待通りに動いているか」という実体と、「どの指標をもって準拠とするか」という運用設計を切り分けて考えることが、最新の Windows 11 環境ではますます重要になっています。

Windows11
PowerShell Hyper-V Windows 11 Credential Guard WSL2 Device Guard

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次