MENU
日程Fit｜「いつ空いてますか？」の往復はもう不要。候補日を選んでURLを送るだけ｜登録不要｜今すぐ無料で使う →

Windows レジストリのVirtualizationEnabledとFipsAlgorithmPolicy（MDMEnabled/STE）を徹底解説

Windows

Windows レジストリには「名前は分かりやすいのに、意味が公式にまとまっていない」値が少なくありません。この記事では、よく質問が出る VirtualizationEnabled（Configuration Manager 配下）と、FipsAlgorithmPolicy（Enabled/MDMEnabled/STE）を、役割の切り分け・値の読み取り方・運用で安全に扱うコツまで含めて整理します。

日程Fit。無料・登録不要。「いつ空いてる？」を、ひとつのリンクで。リンクを送って、○△×でかんたん日程調整。無料で日程を作る。
目次

まず切り分けたい：「仮想化」という言葉が指すものは1つではない

レジストリに VirtualizationEnabled とあると、真っ先に「VBS（Virtualization-based Security）」を連想しがちですが、Windows には “仮想化” という言葉が付く仕組みが複数あります。混同すると、設定変更の意図と結果がずれてトラブルになりやすいので、最初に整理します。

名前（よくある呼び方）ざっくり何をする仕組み？主な対象ユーザーが気づきやすい影響
レジストリ仮想化（Registry Virtualization）権限不足で書き込めないはずの場所（例：HKLM）への書き込みを、ユーザーごとの “VirtualStore” に透過的にリダイレクトする互換性機能主に古い 32bit デスクトップアプリ「同じキーに書いたのに、別の場所に入っていた」など“レジストリが二重に見える”現象
VBS（Virtualization-based Security）/ HVCIハイパーバイザを使って保護領域を分離し、カーネルや資格情報などを守る（例：メモリ整合性）OS のセキュリティ機能（デバイスセキュリティ）ドライバー互換性、（環境によっては）ゲームのフレームタイムや体感性能
アプリ/パッケージ仮想化（MSIX 等）アプリごとにファイル/レジストリの見え方を分離し、アンインストール時に痕跡を残しにくくするストアアプリ/パッケージ化アプリ「同じパスなのに別アプリから見えない」などのスコープ差

この記事で扱う VirtualizationEnabled は、場所が HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\...\Configuration Manager 配下である点が重要です。“Configuration Manager” は Windows カーネルのレジストリ（構成管理）サブシステムそのものを指します。つまり、ここにある “VirtualizationEnabled” は、少なくとも名称上は「レジストリ仮想化（互換性機能）側の設定」として読むほうが自然です。

VirtualizationEnabled：どこにあって、何のスイッチに見えるのか

質問でよく挙がるパスは次の形です（環境により “Session Manager” が挟まって見えることがあります）。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\(Session Manager\)Configuration Manager
  VirtualizationEnabled (REG_DWORD)

この値は、コミュニティの調査メモでは CmVEEnabled（Configuration Manager Virtualization Enabled）として参照されることがあります。つまり OS 内部では、レジストリ（構成管理）機構の“仮想化”挙動を全体として許可するかどうかに関わるフラグである可能性が高い、と推測できます。

レジストリ仮想化（VirtualStore リダイレクト）の挙動をおさらい

Microsoft の説明では、レジストリ仮想化は互換性目的で「グローバルに影響するレジストリ書き込み」をユーザーごとの場所へリダイレクトします。例として、HKEY_LOCAL_MACHINE\Software への書き込みが、ユーザー SID 配下の VirtualStore に転送されます。さらに、仮想化が有効になる対象は限定されており、典型例として “32-bit の対話型プロセス” でのみ有効、などの条件が示されています。

また、レジストリ仮想化は “あくまで暫定的な互換性技術” とされ、将来の Windows で削除される可能性がある旨にも触れられています。したがって、業務アプリ側が仮想化に依存しない設計（正しい保存先・適切な ACL）へ寄せるのが本筋です。

VirtualStore を実際に確認する方法（「二重に見える」現象の切り分け）

VirtualStore が疑わしいときは、まず “どこに書かれているのか” を確認します。次の手順は読み取り中心なので、トラブルシュート向きです。

  • ユーザー SID を確認：whoami /user で SID を取得
  • VirtualStore 側のパスを確認：HKEY_USERS\<SID>_Classes\VirtualStore\Machine\Software 配下を確認
  • 本来の書き込み先（HKLM）と比較：HKEY_LOCAL_MACHINE\Software と内容が分かれていないか確認

「アプリは書いたつもりなのに、別アプリからは見えない」「管理者で実行すると見える」などの症状は、VirtualStore 由来の可能性があります。

VirtualizationEnabled の値 0/1/2：現場向けの読み取り方

結論から言うと、この DWORD の 0/1/2 を公式ドキュメントで明確に定義した資料は見つけにくいのが実情です。そのうえで、運用の現場では次のように“安全側”に解釈して扱うのが実用的です。

値一般的に想定される状態影響が出やすい場面運用上の注意
0（レジストリ仮想化の）無効古い 32bit アプリが HKLM 配下へ書こうとして失敗する／VirtualStore へ回らなくなる互換性問題が表面化しやすい。業務アプリのインストーラや古いツールがある端末では特に慎重に
1有効（標準動作の想定）“二重に見えるレジストリ”現象（VirtualStore）を踏む可能性はあるが、互換性は保ちやすい基本は既定のままが無難。個別に問題がある場合はキー単位（reg flags）で調整するほうが副作用が小さい
2有効（拡張/強制/互換性・保護の追加モードの可能性）環境依存（OS ビルドや管理ポリシーにより意味が変わり得る）明確な根拠がない限り、2 を狙って設定する運用は避ける。もし 2 が入っている場合は “どの管理経路が書いたか” を先に特定する

なお、Microsoft Q&A などでは、この VirtualizationEnabled を VBS（仮想化ベースのセキュリティ）のオン/オフ/強化レベルとして説明している回答も見かけます。ただし回答者が “Independent Advisor” のケースもあり、この値だけで VBS 状態を断定するのは危険です。VBS を切り替えたい場合は、後述の「VBS/HVCI を確認する手順」で 実際の状態 を先に確認してください。

「目的が VBS/HVCI の調整」なら、見るべき場所は別にある

ゲームのスタッタリングや一部ドライバーの相性で “仮想化系のセキュリティを疑う” ことは現場でもあります。ただし、VBS/HVCI は Configuration Manager 配下の値 1 本で安全に運用するものではなく、通常は GUI（Windows セキュリティ）やポリシー（GPO/Intune）で管理します。

  • Windows セキュリティ：デバイス セキュリティ → コア分離（メモリ整合性）などで状態確認
  • msinfo32：システム情報で「仮想化ベースのセキュリティ」の状態を確認
  • systeminfo：Hyper-V 要件やハイパーバイザ有無の手掛かりを確認

ここで “VBS が有効/無効” が明確になれば、VirtualizationEnabled を触る前に、正式な管理経路でオン/オフしたときに現象が再現するかを確認できます。結果として、レジストリの未文書値に頼らずに問題を収束させやすくなります。

FipsAlgorithmPolicy：FIPS 準拠暗号ポリシーを OS へ反映する仕組み

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy は、いわゆる「FIPS モード（FIPS 準拠アルゴリズムのみを利用する方針）」に関係するキーです。一般的には、組織の規制・監査（政府系、金融、重要インフラなど）で “FIPS 準拠が必須” という要件がある場合にだけ、有効化を検討します。

Enabled / MDMEnabled / STE：それぞれ何を意味する？

まずは、よく出てくる 3 つの値を「誰が書くのか」「何のためにあるのか」という観点で並べます。

値名代表的な意味1 にされやすい経路読み取りのポイント
Enabled従来からある “FIPS ポリシーを有効化” のフラグローカル セキュリティ ポリシー / GPO など最も分かりやすいが、これだけが “FIPS 関連フラグ” の全てではない
MDMEnabledMDM（Intune など）経由で FIPS 方針を適用したことを示す/反映するためのフラグとして扱われるMDM ポリシー（Policy CSP）Enabled=0 でも MDMEnabled=1 のような状態があり得る。管理経路の違いがそのまま値に表れることがある
STE暗号モジュールが FIPS 承認モードとして動作するための “Self-test（自己テスト）” 条件に関わるフラグとして記載されるOS/モジュール要件（環境・構成により）「テレメトリ」と結び付けた説明も見かけるが、少なくとも FIPS 140 のセキュリティポリシー文書では自己テスト条件の一部として扱われる

MDMEnabled：Intune で FIPS を配るときの “足跡” になりやすい

Microsoft の Policy CSP（MDM から端末設定を配る仕組み）には暗号ポリシー項目があり、MDM 経由で FIPS ポリシーを制御できることが示されています。MDM 管理下の端末では、GPO ではなく CSP 側の設定が優先されたり、結果がレジストリへ反映（いわゆる tattoo）されたりすることがあるため、「Enabled は 0 のままなのに、実際には MDM で FIPS を強制していた」といった見え方になり得ます。

STE：FIPS 140 の “自己テスト条件” として登場する値

FIPS 140 検証（CMVP）のセキュリティポリシー文書では、Windows の暗号モジュールが FIPS 承認モードとして動作する条件の一つとして、FipsAlgorithmPolicy 配下の STE（DWORD）を 1 に設定する、といった記述が見られます。これは、モジュールが起動時に行う自己テスト（Self-Tests）と関連付けて説明されており、「STE = Secure Telemetry」といった推測よりも、Self-test を有効にする（あるいは FIPS 承認モードへ移行するための条件を満たす）ためのフラグとして理解するほうが整合的です。

Enabled が 0 なのに「FIPS が効いている気がする」時の考え方

現場で混乱しやすいのが、Enabled=0 でも、MDMEnabled や STE が 1 といった組み合わせです。これは “誰が・どの管理経路で” 設定したかが違うだけで、端末としては FIPS 要件を満たすためのフラグが立っている可能性があります。

  • 端末が Intune 管理であれば、まずは MDM の暗号ポリシー（暗号要件・ベースライン）を確認
  • 監査対応で「FIPS モードが必要」なら、OS の UI 表示だけでなく、監査手順が求める評価方法（監査チェックリスト/検証ツール）を優先
  • アプリ互換性トラブルが出ているなら、まずは FIPS を本当に必須にしている規定（社内規程・顧客要件・法令）を確認し、段階的に対策を検討

運用で迷わないための実践ガイド

レジストリを直接編集する前にやること

  • 目的を言語化：互換性問題（VirtualStore）を潰したいのか、セキュリティ要件（VBS/FIPS）を満たしたいのか
  • 管理経路を確認：GPO / Intune / ローカル変更 / スクリプト配布のどれが効いているか
  • 変更影響を事前テスト：検証端末でアプリ動作・ログオン・VPN・証明書・業務システムまで確認

確認に使える PowerShell（読み取り専用）

まずは “現状がどうなっているか” を揃えるだけで、トラブルシュートがかなり楽になります。

# VirtualizationEnabled（存在しない環境もあります）
$cmPath1 = 'HKLM:\SYSTEM\CurrentControlSet\Control\Configuration Manager'
$cmPath2 = 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Configuration Manager'

Get-ItemProperty -Path $cmPath1 -ErrorAction SilentlyContinue | Select-Object VirtualizationEnabled
Get-ItemProperty -Path $cmPath2 -ErrorAction SilentlyContinue | Select-Object VirtualizationEnabled

# FipsAlgorithmPolicy
$fipsPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy'
Get-ItemProperty -Path $fipsPath | Select-Object Enabled, MDMEnabled, STE

トラブルを避ける “おすすめの考え方”

VirtualizationEnabled は「未文書に近い領域」であることが多く、業務端末での一律変更には向きません。VirtualStore 起因の不具合なら、まずは該当アプリの権限設計（正しい保存先へ移行）か、キー単位の仮想化フラグ（reg flags）での制御を優先するのが安全です。

FIPS は “必要だから入れる” ものであって、“何となく強化したいから入れる” ものではありません。Enabled/MDMEnabled/STE が 1 になると、暗号アルゴリズム選択が制限され、アプリケーション側で互換性問題（暗号方式が使えない、例外が出る、通信が確立しない等）が起きることがあります。監査要件がない限り、基本は無効のままにし、必要な場合でも段階的に適用するのが現実的です。

まとめ：キーを見たら「目的」と「管理経路」で判断する

  • VirtualizationEnabled は Configuration Manager（レジストリサブシステム）配下に現れる値で、レジストリ仮想化（互換性機能）と結び付く文脈で理解するのが自然。0/1/2 の厳密な公式定義は追いづらいため、端末の役割と影響を見ながら慎重に扱う。
  • FipsAlgorithmPolicy の Enabled は従来の FIPS ポリシー、MDMEnabled は MDM 経由適用の反映、STE は暗号モジュールの自己テスト条件として登場する値として把握すると、実務での見え方のズレを説明しやすい。
  • どちらも “レジストリを直接いじる” より、可能な限り GPO/Intune/Windows セキュリティなど公式の管理経路で制御し、検証→段階展開の順で進めるのが安全。
Windows
Windows レジストリ FIPS VirtualizationEnabled

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次