Windows 11

BitLocker不具合、KIR回避策がWindowsから消える

4月Patch TuesdayのBitLocker回復画面不具合で、MicrosoftがKIR回避策の一部を取り下げた模様だ。Windows 11向けページからKIR記述が削除され、管理者にはグループポリシー手修正のルートしか残っていない。

情報の灯台

2026年4月22日

4月アップデートで再びBitLocker回復画面

Windows 11のBitLocker回復画面トラブルが、また戻ってきている。4月14日に配信された4月のPatch Tuesday（KB5083769、KB5082052、Windows 10向けKB5082200、Windows Server 2025向けKB5082063）を適用した一部環境で、初回再起動時にBitLocker回復キーの入力を求められる事象が発生した。

Microsoftは当初、問題の回避策として2つのルートを提示していた。ひとつはグループポリシーの修正、もうひとつは「Known Issue Rollback（KIR）」の適用だ。ところが4月22日、海外メディアのNeowinが自社記事の更新で「MicrosoftがKIR回避策を削除した」ことを報じた。同社は「理由は説明されていない」とした上で、ロールバックの動作不良の可能性に触れている。残されたのは、管理者が手作業でグループポリシーに触る道だけである。

誰が引っかかるのか

今回の不具合は、家庭で使うWindows 11にはまず当たらない。影響条件がかなり狭い。

Microsoftのサポートページによれば、以下のすべてに該当する環境でのみ問題が発生する。OSドライブでBitLockerが有効、「ネイティブUEFI ファームウェア構成用のTPMプラットフォーム検証プロファイルの構成」というグループポリシーが設定されPCR7が検証プロファイルに含まれている、msinfo32.exeがSecure Boot状態のPCR7 Bindingを「Not Possible」と報告する、Windows UEFI CA 2023証明書がデバイスのSecure Boot署名データベース（DB）に存在する、そしてデバイスがまだ2023年署名のWindows Boot Managerで動いていない。この5条件である。

条件は細かいが、言い換えれば「IT部門が管理する企業端末」がほぼ該当する。家庭用PCでここまで凝ったセキュアブート構成を手動で組んでいるユーザーは稀だろう。

MicrosoftのNotebookcheck向けコメントでも、対象は「限られた数のシステム」だとされている。ただし、症状自体は見かけほど軽くない。回復キーを手元に用意していない管理者にとって、初回再起動でいきなり48桁のキーを要求される画面は、単純な「一度きりの入力」で済まない場合がある。

KIRが消えたという事実

ここで気になるのは、取り下げられたKIRの扱いだ。

Known Issue Rollbackは、Microsoftが特定のアップデートの一部機能だけを巻き戻すための仕組みで、パッチ全体をアンインストールせずに不具合の原因だけを無効化できる。今回のケースでは、KIRを適用することで2023年署名のBoot Managerへの自動切り替えを止め、BitLocker回復のトリガーを回避する設計だった。パッチ適用前にKIR用のグループポリシーMSIを配布すれば、問題自体を発生させずに済む、手堅い回避策である。

Microsoftのサポートページには当初このKIRに関する段落が存在していた。ただし本稿執筆時点でも、Windows Server 2025向けのKB5082063サポートページにはKIR手順が残っており、削除はWindows 11向けページに先行して行われた可能性がある。Microsoft公式からの明確な撤回発表は確認できていない。

代わりにMicrosoftは、恒久修正は将来のWindowsアップデートで提供する、という従来通りのスタンスを維持している。候補として挙がっているのが、リリースプレビューチャンネルで先行公開されているKB5083631だ。これはFile Explorerの起動速度改善などが目玉の「Windows 11を速くする」系アップデートだが、Secure BootとBitLockerの相互作用まわりの挙動にも手が入る可能性がある。

残された道はポリシー修正だけ

KIRが消えた以上、現時点で確実に動く対処法はグループポリシーの書き換えになる。

Microsoft公式が案内している手順はシンプルだ。まずグループポリシーエディタ（gpedit.msc）を開き、「コンピュータの構成 > 管理用テンプレート > Windowsコンポーネント > BitLockerドライブ暗号化 > オペレーティングシステムのドライブ」へ進む。そこで「ネイティブUEFIファームウェア構成用のTPMプラットフォーム検証プロファイルの構成」を「未構成」に設定する。その後、影響を受けるデバイスでgpupdate /forceを実行してポリシー変更を反映させ、manage-bde -protectors -disable C:でBitLockerを一時停止、manage-bde -protectors -enable C:で再開する。これでBitLockerのバインディングがWindows既定のPCRプロファイルに更新され、次回以降の再起動で回復画面が出なくなる。

この手順は「更新前」に実施するのが理想だが、すでに回復画面に遭遇してしまった管理者でも、キーを一度入力したあとに同じ修正を走らせれば再発を防げる。ただし、リモートでしかアクセスできない端末や、ネットワークに間欠的にしか繋がらない端末では、この「一度キーを入力させる」工程自体が相当なコストになる。

Windows Centralの取材に対してMicrosoftは、問題が広範囲には及ばないと強調している。ただ、企業のIT部門から見れば、200台中60台が引っかかれば十分な事件だ。ある管理者は、組織内の約30%の端末でBitLocker回復プロンプトが出たと報告している。

繰り返される同じ失敗

今回のトラブルがもう一つ気になるのは、この手のBitLocker誤作動が過去4年で4回目だという点だ。2022年8月のKB5012170、2024年7月のWindows全バージョン、2025年5月のWindows 10向け、そして今回。Patch Tuesdayが原因でBitLocker回復画面が暴発するパターンが、ほぼ定期イベントのように再発している。

背景には、Microsoftが進めているSecure Boot証明書の世代交代がある。大多数のWindowsデバイスで使われているSecure Boot証明書は、2026年6月から順次期限切れを迎える。4月のPatch Tuesdayも、新しいSecure Boot証明書の配布対象を広げる処理を含んでいた。証明書の更新、Boot Managerの世代交代、TPM測定プロファイル、デバイス管理ポリシー。これらが同時に動くタイミングで、どこか1箇所でも足並みが揃わないと、ユーザーから見ればそれは「BitLocker回復画面」として現れる。