Windows Server

Windows Server 2025の4月更新でBitLocker回復画面が発動──もはや恒例行事か

Microsoftの月例アップデートが、またしてもBitLockerの回復キー入力を求めてくる。管理者たちにとって、この光景はデジャヴを通り越して年中行事になりつつある。

情報の灯台

2026年4月15日

セキュリティ更新が招く「鍵をよこせ」

Windows Server 2025向けの2026年4月セキュリティ更新プログラム（KB5082063）を適用すると、一部のサーバーが再起動時にBitLocker回復画面を表示する。Microsoftは4月15日（日本時間）、この問題を既知の不具合として公式に認めた。

BitLockerはストレージを暗号化してデータ窃盗を防ぐWindows標準のセキュリティ機能だ。ハードウェア変更やTPM（Trusted Platform Module）の更新を検知すると、正当なユーザーであっても 48桁の回復キー の入力を求めてくる。セキュリティとしては正しい動作だが、それがWindows Update起因で誤発動するとなると話は別だ。

Microsoftによれば、回復キーの入力は初回再起動時の1回限りで、以降の再起動では回復画面は表示されない。

ただし「1回で済む」という説明は、回復キーを手元に持っている前提の話だ。企業のIT部門がActive DirectoryやAzure ADにキーをエスクローしていなければ、その「1回」がサーバーの長時間停止に直結する。

発動条件は限定的、だが厄介

今回の問題は、5つの条件すべてを満たすシステムでのみ発生する。OSドライブでBitLockerが有効、グループポリシーでTPMプラットフォーム検証プロファイルにPCR7を含めている、msinfo32.exeでSecure Boot State PCR7 Bindingが「Not Possible」、Windows UEFI CA 2023証明書がSecure Boot署名データベースに存在する、そして2023年署名のWindows Boot Managerがまだ既定になっていない。この5つだ。

条件が5つも並ぶと「自分には関係ない」と思いがちだが、この構成はエンタープライズ環境で珍しくない。Microsoft自身も「個人デバイスでは影響を受ける可能性は低い」と認めており、裏を返せば IT部門が管理するサーバー こそが標的だ。

企業向けのBitLockerグループポリシーを手動でカスタマイズしている環境ほど、この問題に引っかかりやすい構造になっている。

回避策は2つ、だが「事前」が前提

Microsoftが提示している回避策は2つある。

グループポリシーの変更（推奨）

1つ目は、更新プログラム適用前にグループポリシーエディタで「ネイティブUEFI ファームウェア構成のTPMプラットフォーム検証プロファイルの構成」を「未構成」に変更し、gpupdate /forceでポリシーを反映した後、manage-bdeコマンドでBitLockerを一時停止・再開する方法だ。

KIR（Known Issue Rollback）の適用

2つ目は、PCR7グループポリシーを変更できない環境向けのKIR（既知の問題のロールバック）だ。KIRは2023年署名Boot Managerへの自動切り替えを阻止し、BitLocker回復のトリガーを回避する。ただしKIRの入手にはMicrosoftのビジネスサポートへの問い合わせが必要で、即座にダウンロードできるものではない。

どちらの回避策も「更新プログラム適用前」に実施することが前提であり、適用後に回復画面が出てからでは遅い。恒久的な修正は将来のアップデートで提供予定とされているが、具体的な時期は示されていない。

2022年から繰り返される「BitLocker回復ガチャ」

この種の問題が起きたのは今回が初めてではない。むしろ、Windows アップデート後のBitLocker回復画面は 定期的に再発する持病 のような存在だ。

2022年8月にはKB5012170がSecure Boot DBXの更新時に回復画面を誘発した。2024年7月のセキュリティ更新ではデバイス暗号化が有効な環境で広範囲に発生し、翌8月の修正を待つ羽目になった。2025年5月にはWindows 10でLSASSプロセスの異常終了が原因で回復ループに陥るケースが報告され、緊急アップデートが配信された。そして2025年10月には、Intel製CPUのModern Standby搭載機を中心にWindows 10/11の両方で再発。Azure VMまで巻き込まれ、Redditの管理者コミュニティは騒然となった。

約4年で5回。セキュリティ更新のたびにBitLockerが「敵か味方か分からなくなる」状態は、もはやバグではなく構造上の欠陥だ。

背景にあるSecure Boot証明書の期限切れ

今回の問題を単なるバグとして片付けるのは早い。背景には、2026年6月に迫るSecure Boot証明書の期限切れという大きな構造変化がある。

2011年に発行されたSecure Boot証明書は、 15年の運用期間 を経て2026年6月末から順次失効する。Microsoftはこれに先立ち、2023年版の新しい証明書への移行を段階的に進めている。今回のKB5082063にも、新しいSecure Boot証明書の展開範囲を拡大する変更が含まれていた。

つまり今回のBitLocker問題は、証明書移行の過渡期に起きた副作用だ。古い証明書と新しいBoot Managerの切り替わりタイミングで、BitLockerのブート整合性チェックが「何かが変わった」と判断してしまう。セキュリティ機能として正しく動作した結果、管理者がロックアウトされる──Microsoftが自分で仕掛けた変更に自分のセキュリティ機能が反応している、という間の抜けた構図だ。

証明書が失効すれば、Windows Boot Managerへのセキュリティ更新が受けられなくなり、BlackLotusのようなUEFIブートキットに対する防御も失われる。HP、Dell、Lenovoといった主要OEMはファームウェア更新の準備を進めているが、2012年以降に製造された膨大な数のデバイスすべてがスムーズに移行できる保証はない。

167件の脆弱性修正と引き換えの「地雷」

今回の4月Patch Tuesdayは 167件 の脆弱性を修正する大規模なリリースだった。ゼロデイが2件含まれ、SharePoint Serverのスプーフィング脆弱性（CVE-2026-32201）は実際に攻撃に悪用されている。Windows IKEサービスのリモートコード実行脆弱性（CVE-2026-33824）はCVSSスコア 9.8 で、認証不要の攻撃が可能だ。

セキュリティ更新を適用しなければ攻撃のリスクが高まる。しかし適用すればBitLockerの回復画面に遭遇するかもしれない。管理者はこの二択を、毎月のように迫られている。

セキュリティの強化と安定性の維持は本来両立すべきものだ。だが少なくともBitLockerに関しては、Microsoftは同じ穴に何度も落ちている。管理者にできるのは回復キーのバックアップを確認し、グループポリシーを事前に見直すことだけだ。それで十分かと問われれば、十分なはずがない。

参照元