Windows Server 2012 R2でSpectre/Meltdown（ADV190013/ADV180012/ADV180002）が未対策と検出される原因とレジストリ対処（FeatureSettingsOverride）

Windows Server 2012 R2 を「最新パッチ適用済み」のつもりでも、Qualys などの脆弱性診断で ADV190013 / ADV180012 / ADV180002 が「対策未完了（レジストリ設定不足）」と判定されることがあります。多くのケースでは、OS 更新だけでは完結しない緩和策（CPU マイクロコードや既定無効の設定）が残っているのが原因です。VM（仮想マシン）環境での確認ポイントと、安全に是正する進め方をまとめます。

まず結論：Windows Update だけで「完全対策」にならないパターンがある

Spectre / Meltdown 系の脆弱性（および同系統の投機実行・マイクロアーキテクチャ系の問題）は、一般的な「OS の脆弱性修正」と違い、次の複数レイヤが揃って初めて“緩和策が有効”になります。

レイヤ	何を満たす必要があるか	足りないとどうなるか	VM環境での影響
OS（ゲストOS）	カーネル/機能更新で緩和策の実装が入っている	診断で「OS更新不足」「緩和策未実装」と出る	ゲストが古いと、ホストが最新でも不足扱い
CPUマイクロコード（ハードウェア）	CPU側で必要な命令/フラグが提供される（BIOS/UEFI更新など）	OSが緩和策を持っていても“使えない”ため不足扱いが残る	ホスト側が未更新だとゲストは基本的に解決しない
設定（レジストリ/ポリシー）	性能影響や互換性の理由で既定無効の緩和策を必要に応じて有効化	診断で「レジストリ設定不足」「緩和策が無効」と出る	ゲストOS側での設定が必要なケースがある
再起動	更新・マイクロコード・設定を反映させる	更新済みでも判定が変わらない	ホスト/ゲスト双方で再起動が必要な場面がある

つまり、診断が「レジストリ設定不足」と出るからといって、いきなり FeatureSettingsOverride / FeatureSettingsOverrideMask を投入しても、根本原因がマイクロコード不足なら解決しません。逆に、マイクロコードも OS 更新も揃っているのに、“既定で無効の緩和策”がオフのままで診断に引っかかるケースは、レジストリ設定で改善する可能性があります。

ADV190013 / ADV180012 / ADV180002 が「未対策」と検出される典型パターン

診断ツールは、OS のビルド番号だけでなく「緩和策が有効になっていること」を複数条件で判定します。特に Windows Server 系では、クライアント OS と違い、性能影響やワークロード互換性を考慮して既定無効のものが混ざりやすく、スキャン上は“不足”になりがちです。

診断で出やすい項目	スキャナが見ていること（例）	「不足」になりやすい原因	最初に疑うべき箇所
ADV180002 （Spectre/Meltdown 系）	OS側緩和策の存在＋有効化状態、必要なCPU機能の有無	OS更新は入っているが、CPU/マイクロコード要件が満たせていない／既定無効のまま	ホストのBIOS/UEFI、ホストOS更新、ゲスト側の有効化設定
ADV180012 （Variant 4 等の系統）	特定緩和策が有効化されていること（サーバーで既定オフがあり得る）	性能影響を避けるため既定で無効、またはポリシーで意図的に無効化	レジストリでの緩和策スイッチ、再起動、ワークロード影響評価
ADV190013 （同系統のマイクロアーキ系）	追加緩和策の有効化状態、CPUマイクロコード要件	マイクロコード不足／OS更新の前提が欠けている／設定が既定オフ	ホスト側マイクロコード、累積更新の前提、診断のチェック内容

ポイントは、同じ「未対策」でも大きく分けて次の2種類があることです。

• 実装が無い（更新不足）：OS更新や前提更新が欠けている、または古いビルドのまま
• 実装はあるが無効（設定不足）：性能影響・互換性を理由に緩和策がオフになっている

Qualys のようなスキャナが「レジストリキー設定不足」と出す場合、後者（実装はあるが無効）の可能性が上がります。ただし、実際にはマイクロコード要件を満たしていないのに、結果だけ“設定不足”っぽく見えることもあるため、次章の VM 観点が重要になります。

VM環境で最重要：ホスト側（物理サーバー/仮想化基盤）の更新が先

VM（ゲストOS）は、CPU を“直接”使っているように見えても、実体はホスト側の CPU 機能・マイクロコード・ハイパーバイザが提供する機能に依存します。したがって、ゲストにいくらパッチを当てても、ホストが古ければスキャン結果は改善しないことがあります。

チェックの優先順位

1. 物理ホストの BIOS/UEFI 更新（＝CPUマイクロコード更新の取り込み）
2. ホストOS／ハイパーバイザの更新（Hyper-V/VMware/その他の基盤側）
3. ゲストOS（Windows Server 2012 R2）の更新（累積更新・前提更新の取りこぼしがないか）
4. 必要な場合のみ、ゲストOSの緩和策を有効化する設定（レジストリ等）
5. ホスト/ゲストの再起動を計画し、反映させてから再スキャン

VMで「レジストリ不足」が残る典型原因

原因	現場で起きがちな状況	対処の方向性
ホスト側マイクロコード未更新	ゲストにだけ Windows Update を当てて満足している	先にホストのBIOS/UEFI更新、ハイパーバイザ更新を実施
ホスト/ゲストの更新レベル不整合	ホストは最新だがゲストが古い、またはその逆	双方の更新を揃え、再起動してから判定を見る
緩和策が既定無効	サーバー用途のため性能影響が嫌われ、既定でオフの項目がある	影響評価の上で有効化（レジストリ）、再起動、再スキャン
診断が「レジストリ」しか見ていない/見えない	実際は対策済みでも、検査方式の都合で不足に見える	OS内の確認コマンド結果も併記し、例外/補足として整理

ここまでを踏まえると、VM環境での鉄板の進め方は「ホストを先に整えてから、ゲストの設定に着手する」です。スキャナの結果を短期で消したいときほど、順序を逆にすると遠回りになりがちです。

FeatureSettingsOverride / FeatureSettingsOverrideMask とは何か

Qualys の指摘でよく出てくる FeatureSettingsOverride と FeatureSettingsOverrideMask は、Windows が提供する“投機実行系緩和策のオン/オフ（または既定動作の上書き）”を制御するためのレジストリ値です。主に次のような役割を持ちます。

• FeatureSettingsOverride：特定の緩和策を「有効/無効」にしたい場合の上書き値
• FeatureSettingsOverrideMask：どの項目（ビット）を上書き対象にするかを指定するマスク

重要なのは、これらは“OSが持っている緩和策の動作を切り替えるスイッチ”であって、CPUマイクロコードが無い状態を魔法のように解決するものではないという点です。マイクロコード要件を満たしていない場合、OSがスイッチをONにしても実装できない（＝有効化できない）ことがあります。

どこに設定するのか（代表例）

一般的に、次の場所で参照されるケースが多いです（環境や対象緩和策により異なる場合があります）。

• レジストリパス：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
• 値：FeatureSettingsOverride（DWORD）
• 値：FeatureSettingsOverrideMask（DWORD）

スキャナが「レジストリ設定不足」と言うときは、概ね次のどちらかです。

• 該当する値が存在しない（＝既定動作のまま）
• 値は存在するが、スキャナが期待するビット設定になっておらず緩和策が無効と判断される

レジストリ設定を入れる前に押さえるべき注意点

ここが一番大事です。FeatureSettingsOverride 系の値は、診断上の判定を変える可能性がある一方で、サーバーにとって無視できない影響もあり得ます。

注意点

• 性能影響：投機実行の緩和は、I/O が多い、コンテキストスイッチが多い、暗号化/圧縮が多い、などのワークロードで遅延やスループット低下が出やすい
• 互換性：特定のドライバや古いアプリ、特殊なセキュリティ製品で想定外の挙動になるケースがある
• 運用リスク：値を入れたのに再起動していない／入れ間違い／戻し方が用意されていない、が現場トラブルの定番

「値を入れれば万能に直る」の誤解が起きる理由

スキャナの表示が「レジストリ不足」となっていると、“設定を足せば OK”に見えます。しかし実際には、次のような組み合わせで症状が変わります。

状態	OS更新	マイクロコード	レジストリ（有効化）	スキャン結果の傾向
パッチ不足	×	？	？	まず「更新不足」扱い。設定だけでは改善しない
マイクロコード不足	○	×	○/×	設定しても有効化できず、未対策が残りやすい
既定無効のまま	○	○	×	「レジストリ不足」になりやすい。設定で改善する可能性
全条件が揃っている	○	○	○	多くの環境で改善。ただし検査方式によっては残ることも

したがって、レジストリ投入は「最後のピース」になり得ますが、順番を誤ると効果が見えにくくなります。

実務で失敗しにくい“進め方の型”

以下は、現場でスキャン結果の改善と安全性を両立させやすい手順です。特に Windows Server 2012 R2 は古い世代のため、無理に継ぎ足しで延命するよりも、“確認→影響評価→限定適用”の順で進めるのが事故を減らします。

手順

1. スキャナの検出内容を具体化する
   • ADV190013 / ADV180012 / ADV180002 のどれが「Missing」なのか、「Registry setting not found」なのかを切り分ける
   • 可能なら、Qualys の QID 詳細で「どのレジストリ」「どの条件」を見ているか確認する
2. ホスト（物理/仮想基盤）を更新する
   • 物理サーバーの BIOS/UEFI をベンダー推奨の最新へ
   • ハイパーバイザ（Hyper-V/VMware 等）の更新・パッチ適用
   • 更新後にホスト再起動（必要に応じてメンテナンスウィンドウ確保）
3. ゲストOS（Windows Server 2012 R2）を最新化する
   • 「インストール済み更新プログラム」を確認し、取りこぼしがないか棚卸し
   • 月例ロールアップや前提更新が欠けていると、緩和策の一部だけ未実装になることがある
   • 更新後に再起動
4. OS側で“緩和策が有効になっているか”を確認する
   • スキャナの結果だけでなく、OS内部の状態確認（後述のコマンド）で「実装/有効」を見る
5. 必要な場合のみ、レジストリで有効化する
   • 性能影響が許容できるか、対象サーバーの役割（DB/ファイル/AD/アプリ）に合わせて判断
   • 変更前にスナップショット/バックアップ、戻し手順を用意
   • 設定後は必ず再起動
6. 再スキャンして差分を確認する
   • 改善した項目／残った項目を整理し、残ったものは「ホスト依存」「検査方式」「非該当」などの説明可能性を検討

確認に使えるコマンドと、スキャナとの突き合わせ方

スキャナは“外から見える情報”で判定するため、OS内部の状態とズレることがあります。運用としては、スキャナ結果＋OS内部の確認結果をセットで持っておくと、監査や社内説明が格段に楽になります。

レジストリ値の有無を確認する（ゲストOS）

FeatureSettingsOverride / Mask が存在しているかだけを確認するなら、次のように参照できます。

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" ^
 /v FeatureSettingsOverride

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" ^
/v FeatureSettingsOverrideMask

値が存在しない場合は “既定動作” です。既定動作が「無効寄り」になっていると、スキャナが不足と判定することがあります。

緩和策が有効かどうかを俯瞰する（ゲストOS/ホストOS）

代表的な確認手段として、投機実行系の緩和策状態をレポートする PowerShell の確認スクリプト/モジュールが利用されることがあります。環境により実行可否や導入手順が異なるため、運用ポリシーに合わせて実施してください。

• 「OSが緩和策を持っているか（実装）」
• 「CPU機能として利用できるか（マイクロコード/ハイパーバイザ）」
• 「既定で無効のものが有効化されているか（設定）」

この3点が揃って初めて、診断上の “対策済み” に近づきます。

Qualys の「FeatureSettingsOverride を入れれば直る？」への答え

結論としては、直ることもあるが、条件付きです。判断軸は次の通りです。

• 直りやすいケース
  • ホスト側のマイクロコードが最新で、ゲストOSも必要な更新が揃っている
  • それでもサーバー既定で無効の緩和策が残っており、スキャナが「レジストリ不足」と言っている
  • 有効化に伴う性能影響を受け入れられる（または影響が軽微）
• 直りにくい（直らない）ケース
  • ホスト側のマイクロコード更新が入っていない（BIOS/UEFI が古い）
  • ゲストOSの更新が一部欠けていて、緩和策がそもそも実装されていない
  • そもそもその脆弱性が対象CPU/構成では「非該当」なのに、検査方式で不足に見える

したがって、Qualys が提示する値を“そのまま”投入する前に、次の順で確認するのが安全です。

1. ホスト側の BIOS/UEFI（マイクロコード）更新状況
2. ホストOS/ハイパーバイザのパッチ適用状況
3. ゲストOSの更新状況（前提更新の取りこぼしがないか）
4. スキャナが見ているチェック内容（どの緩和策のどの設定を要求しているか）
5. 性能影響を許容できるか（業務影響評価）

レジストリを変更する場合の“安全策”

ここでは、値そのもの（数値）ではなく、運用品質を落とさずに実施するための安全策に絞って整理します。数値は対象の緩和策・診断条件・Microsoft のガイダンスで変わるため、環境に合わせた判断が必要です。

事前準備（必須）

• ロールバック手段：VMスナップショット、システムバックアップ、またはレジストリ変更前のエクスポート
• メンテナンスウィンドウ：反映には再起動が必要になりやすい
• 性能の基準値：CPU使用率、ディスクI/O、主要アプリの応答、ジョブ時間など、変更前の基準を採取

運用手順（推奨）

1. 対象レジストリキーをエクスポートして保全する
2. 値を設定（必要な項目だけ。過剰に広く設定しない）
3. 再起動
4. OS内部の確認コマンドで、緩和策が「有効」になったことを確認する
5. 性能・アプリ影響を確認する（特に高負荷時間帯やバッチ時間）
6. Qualys で再スキャンし、改善の有無と残件の理由を整理する

ありがちな落とし穴

落とし穴	起きること	回避策
再起動を忘れる	値を入れても判定が変わらず、原因調査が迷走する	変更チケットに「再起動」まで含め、作業完了条件にする
ホスト側が未更新	ゲストで何をしても改善しない	作業順序を固定（ホスト→ゲスト）し、先にホストを証跡化
“全部有効化”で性能劣化	スキャンは消えたが業務影響が出る	必要最小限の緩和策に絞り、影響の大きい役割は移行計画も検討
診断の取りこぼし/誤検知	対策済みでも残る	OS内部の確認結果を併記し、例外扱いの根拠を作る

Windows Server 2012 R2 ならではの現実的な判断：延命より「移行」を軸に考える

Windows Server 2012 R2 は世代的に古く、投機実行系の緩和策が登場した当時は、性能影響や互換性を考慮して“慎重に有効化する”運用が推奨されることが多くありました。その結果として、今になって脆弱性診断で「設定不足」と出るのは珍しくありません。

ただし、次のような条件に当てはまる場合は、レジストリでの継ぎ足し対処よりもOS更改（Windows Server の新しいバージョンへ移行）を優先した方が、総合的に安全で運用コストも下がりやすいです。

• サーバー台数が多く、個別にレジストリ調整するのが運用品質的に厳しい
• 性能影響が出ると困る（DB、仮想デスクトップ、低遅延アプリなど）
• 監査要件が厳しく、スキャナの指摘を“例外扱い”しにくい
• 仮想基盤も含めて更新が滞っている（BIOS/UEFI更新が難しい）

移行がすぐにできない場合でも、最低限「ホストのマイクロコード＋基盤更新」「ゲストOS更新の取りこぼし排除」「必要最小限の緩和策だけ有効化」という設計にしておくと、スキャン結果の改善と業務影響のバランスを取りやすくなります。

チェックリスト：スキャン改善のために見るべきポイント

最後に、実務でそのまま使える形に寄せてチェック項目をまとめます。

ホスト（物理/仮想基盤）

• BIOS/UEFI（マイクロコード）更新が適用済み
• ホストOS/ハイパーバイザのパッチが最新
• 更新後に再起動済み
• ゲストへ必要なCPU機能が公開される状態になっている（基盤側の設定/バージョン要件がないか確認）

ゲストOS（Windows Server 2012 R2）

• 必要な更新（ロールアップ/前提更新）に不足がない
• 更新後に再起動済み
• OS内部の確認で、緩和策が「実装済み」になっている
• スキャナが要求する緩和策が「有効」になっている（既定無効の場合は要判断）

レジストリ（必要な場合のみ）

• FeatureSettingsOverride / FeatureSettingsOverrideMask の現状値を把握
• 値変更前のバックアップ/ロールバックを準備
• 設定後に再起動
• 性能影響・アプリ影響の確認（変更前後比較）

まとめ

Windows Server 2012 R2 で ADV190013 / ADV180012 / ADV180002 が「対策未完了（設定不足）」と検出される場合、原因は大きくホスト側のマイクロコード/基盤更新不足か、既定無効の緩和策がオフのままかのどちらかに寄ります。VM 環境では特にホスト側の更新が支配的で、ゲストのレジストリ設定だけでは解決しないケースが多いです。

Qualys の推奨する FeatureSettingsOverride / FeatureSettingsOverrideMask は「不足判定を消す切り札」ではなく、“必要条件が揃った上での有効化スイッチ”として位置づけるのが安全です。ホスト→ゲスト→必要ならレジストリ→再起動→再スキャン、の順で進めることで、スキャン結果の改善と運用品質の両立がしやすくなります。