BitLocker回復キー対処ガイド Win11 24H2 2026

はじめに：なぜ2026年の今、BitLocker問い合わせが急増しているのか

「PCを再起動したら『BitLocker回復キーを入力してください』という青い画面が出てきて、業務が完全に止まってます……」――2025年後半から2026年にかけて、社内ヘルプデスクで一番件数が伸びているのが、まさにこの種の問い合わせです。私自身、月曜の朝イチに3件連続で同じ電話を受けたことがあって、原因を改めて整理した経験があります。

原因は、はっきりしています。Windows 11 24H2およびその後継となる25H2において、BitLockerによるデバイス暗号化（Auto Device Encryption）が事実上すべてのPCで自動有効化される仕様に変わったからです。

従来は「モダンスタンバイ対応」「HSTI準拠」「許可されていないDMA対応バスが存在しない」といった、わりと厳しい前提条件を満たすデバイスだけが対象でした。ところが24H2以降ではこの2つの主要前提が削除され、Windows 11 Home／Proを問わず、初回セットアップ時に管理者権限のMicrosoftアカウント（または組織アカウント）でサインインすると、ユーザーが意識しないまま暗号化が走ってしまいます。結果として、回復キーの存在すら知らないエンドユーザーが、Windows Updateやちょっとしたハードウェア構成変更をきっかけにロックアウトされる――そんな事例が頻発しているわけです。

本記事では、現場のヘルプデスク担当者が「電話を受けた瞬間から復旧までの最短経路」をたどれるように、回復キーの確認場所、自動修復ループの抜け方、Microsoft Intuneによる組織的な管理、そしてデバイス暗号化を意図的にオフにする手順までを、2026年4月時点の最新仕様で網羅していきます。

第1章：BitLockerと「デバイス暗号化」の違いを正しく押さえる

多くの現場で混乱の元になっているのが、Windows 11には実は2つの暗号化機能が並存しているという点です。問い合わせ内容の切り分けを最初に間違えると、ユーザーに不要な操作をさせてしまうので、ヘルプデスクとしてはここをまず整理しておきたいところ。

BitLockerドライブ暗号化（フル機能版）

Windows 11 ProおよびEnterprise／Educationエディションで利用できる、伝統的なフル機能の暗号化機能です。コントロールパネルの「BitLockerドライブ暗号化」管理ツールが表示され、ドライブごとに有効化／無効化、回復キーの管理、暗号化アルゴリズムの選択（XTS-AES 128 / 256ビット）などができます。GPOやIntuneの詳細ポリシーで挙動を細かく制御できる、いわば「正規版」ですね。

デバイス暗号化（Auto Device Encryption）

Windows 11 Home／Proで提供される簡易版の暗号化機能で、内部的にはBitLocker技術を使ってはいるものの、UIは「設定」→「プライバシーとセキュリティ」→「デバイスの暗号化」のシンプルなトグルだけ。ユーザー操作なしで自動的にONになるのが特徴で、24H2でこの自動有効化条件が大幅に緩和されました。回復キーは初期セットアップ時にサインインしたMicrosoftアカウントへ自動アップロードされる仕組みです。

ヘルプデスク現場で押さえるべきは、ざっくり次の3点。

Homeエディションで「BitLockerが勝手にONになった」と言われたら、それは正確には「デバイス暗号化」のほうです。コントロールパネルからは管理できず、設定アプリから操作する必要があります。
OSが認識する「ロック状態」は両者で同じ。回復キーを入力する画面（あの青地の画面）と、回復キーの取得方法は完全に共通です。
24H2以降の自動暗号化はTPM 2.0必須。TPMが無効化されているPCでは発動しません（古い検証機を触っているとここで一瞬戸惑います）。

第2章：突然「BitLocker回復キー」を求められる5つのトリガー

ユーザーから問い合わせを受けたら、最初に切り分けるべきは「なぜ回復モードに入ったのか」です。原因によって今後の予防策が変わってくるので、復旧と並行してトリガーを必ず記録してください。あとから「あれ、何が起きたんだっけ」とならないために。

トリガー1：Windows Update（特に大型機能更新プログラム）

24H2→25H2のような機能更新プログラムや、累積更新プログラム適用後の初回起動時に、もっとも頻繁に発生するパターンです。ブートマネージャー（bootmgfw.efi）やWindows Boot Configuration Data（BCD）の整合性が一時的に崩れ、TPMがそれを「未承認の変更」と判定してしまうため、というのが理由です。

トリガー2：UEFIファームウェアのアップデート

OEMから配信されるBIOSアップデートを適用すると、PCRレジスタ値（特にPCR 7のセキュアブート状態）が変化します。BitLockerはPCR値をシール（封印）した鍵で復号を試みるので、値が変わると当然失敗し、回復キーを要求してくるわけです。Lenovo・Dell・HPのファームウェア更新ツールが裏でこっそり動いた直後に発生する、というパターンが個人的にはいちばん多い印象。

トリガー3：セキュアブート／TPM設定の変更

UEFI設定画面でセキュアブートを誤ってオフにした、TPMをClearした、Boot OrderにUSBドライブを追加した――こうした操作も同じ理由で回復モードを誘発します。

トリガー4：ハードウェア交換・接続変更

ドッキングステーション経由で起動していたPCを直接モニターに接続した、外付けGPUを取り外した、メモリを増設した、といった構成変化もPCR値に影響します（地味にハマりやすいやつです）。

トリガー5：誤ったパスワード／PIN試行の連続

BitLocker PINを設定している環境では、一定回数（既定では4回）以上連続でPINを誤入力すると、自動的に回復キー入力モードに切り替わります。

第3章：回復キーを取得する5つの場所【保存先別チートシート】

回復キーは初期化時にどこへバックアップされたかによって、取得経路が変わってきます。ヘルプデスクとしては「ユーザーが個人アカウントか組織アカウントか」「PCがIntune管理下にあるか」を最初の質問にすると、その後の流れがスムーズです。

3-1. 個人のMicrosoftアカウント（aka.ms/myrecoverykey）

家庭用PCや、組織アカウントでセットアップしたものの個人アカウントでサインインしたPCで、もっとも多いパターン。別の動作するデバイス（スマホでもOK）から次のURLにアクセスします。

https://aka.ms/myrecoverykey

サインイン後、「BitLocker回復キー」セクションにデバイス名・キーID（最初の8桁）・48桁の回復キーが一覧表示されます。キーIDの先頭8桁が、ロック画面に表示されているIDと一致するものを必ず確認してください。複数台所有しているユーザーは取り違えがちです（私も最初これでハマりました）。

3-2. Microsoft Entra ID（旧Azure AD）— 組織アカウント

Entra ID参加またはハイブリッド参加デバイスでは、回復キーは自動的にEntra IDのデバイスオブジェクトに紐づいて保存されます。管理者は次の手順で取得します。

entra.microsoft.com にサインイン（クラウドデバイス管理者またはヘルプデスク管理者ロールが必要）
左メニュー「デバイス」→「すべてのデバイス」
対象デバイス名をクリック
「BitLockerキー」タブを選択し、キーIDが一致する回復キーを表示

ちなみに、エンドユーザー自身が取得できるよう、組織で myaccount.microsoft.com（マイアカウントポータル）の有効化を推奨します。テナント全体の「ユーザーがBitLockerキーをセルフサービスで回復できる」トグルをオンにしておくと、ユーザーは「デバイス」タブから自分のキーを直接確認できる――つまり、ヘルプデスクの一次受け件数を減らせます。

3-3. Microsoft Intune管理センター

Intune登録済みデバイスでは、Intune管理センターからも同じキーが取得できます。Entra IDの権限とは別に、Intuneの「ヘルプデスクオペレーター」ロールを割り当てれば、Entraロールなしで運用できる点も覚えておくと便利です。

intune.microsoft.com にサインイン
「デバイス」→「すべてのデバイス」→対象デバイスを選択
「概要」タブの「BitLockerキーの表示」リンクをクリック

注意点：自動暗号化されたデバイスでも、Intuneのディスク暗号化ポリシーが配信されていない場合、回復キーがIntune／Entra側に届いていないことがあります。これは結構な落とし穴で、第6章で予防策を解説します。

3-4. オンプレミスActive Directory（AD DS）

オンプレADドメイン参加デバイスでGPOによりADへのキーバックアップを構成している場合、ADのコンピューターオブジェクト配下に保存されます。「BitLocker Recovery Password Viewer」機能（リモートサーバー管理ツールの一部）を有効化したうえで、Active Directoryユーザーとコンピューターでコンピューターオブジェクトを開き、「BitLocker回復」タブを表示する流れです。

3-5. ローカル取得：manage-bdeコマンド

ユーザーがWindowsにサインイン可能で、別の管理操作の前に念のため回復キーを退避しておきたい――そんな場面では、管理者権限のターミナルで次のコマンドを実行します。

manage-bde -protectors -get C:

または、もうちょっと読みやすい形式で取得したいなら、次のPowerShellコマンドのほうが便利です。

(Get-BitLockerVolume -MountPoint "C:").KeyProtector |
  Where-Object { $_.KeyProtectorType -eq "RecoveryPassword" } |
  Select-Object KeyProtectorId, RecoveryPassword

取得した48桁のキーは、テキストファイルとしてUSBに退避するか、印刷して安全な場所に保管しておきましょう。

第4章：自動修復ループから抜け出す復旧フロー

「回復キーを入力したのに、再起動するとまた回復キー画面が出てくる」「自動修復→再起動→自動修復…が止まらない」――この事象は、24H2環境で特に多く報告されています。原因の大半は、BCD（Boot Configuration Data）の破損または不整合です。

ステップ1：回復キーで一旦ロックを解除する

まず48桁の回復キーを入力してロック画面を突破します。Windowsが起動するならその後に対処、起動しないならステップ2へ進みます。

ステップ2：Windows回復環境（WinRE）からコマンドプロンプトを起動

「詳細オプション」→「トラブルシューティング」→「詳細オプション」→「コマンドプロンプト」を選択します。WinRE側もBitLockerで保護されているので、起動時に回復キーの再入力を求められる場合があります（はい、もう一度です）。

ステップ3：BitLockerの一時停止

BCDを修復している間、TPMが新たな変更を「侵害」と誤認しないよう、BitLockerを一時停止しておきます。

manage-bde -protectors -disable C: -RebootCount 2

-RebootCount 2を指定すると、2回の再起動後に自動的に保護が再開されます。これにより、再起動を伴う修復作業中の追加の回復キー要求を防げる、というわけです。

ステップ4：BCDの再構築

BCDが破損している場合は、次のコマンド群でブートエントリを再構築します。

bootrec /scanos
bootrec /fixmbr
bootrec /fixboot
bootrec /rebuildbcd

EFI（UEFI）ブートのPCで bootrec /fixboot がアクセス拒否となる場合は、bcdbootコマンドでEFIパーティションのブートファイルを再生成します。

bcdboot C:\Windows /s S: /f UEFI

ここで S: はEFIシステムパーティションのドライブレターです。事前に diskpart で list volume を実行し、FAT32形式の100MB前後のパーティションにドライブレターを割り当ててから、というのを忘れずに。

ステップ5：再起動と保護の再開

修復後にPCを再起動し、Windowsが正常に起動することを確認できれば、BitLocker保護は自動的に再有効化されます。手動で確認したいときは、管理者ターミナルで以下を実行。

manage-bde -status C:

「保護状態：保護はオン」と表示されればOK、復旧完了です。

第5章：ヘルプデスク向けスクリプト：問い合わせから復旧までのフロー

現場で標準化しておくと処理時間がぐっと短縮できる、推奨フローを示します。

受付フェーズ（最初の3分）

確認1：画面上部に表示されている「キーID」の先頭8桁を読み上げてもらう
確認2：PCはどのアカウントでセットアップされたか（個人 / 組織）
確認3：直前に何があったか（更新／BIOSアップデート／構成変更）
確認4：エディションは？（Home / Pro / Enterprise）

キー取得フェーズ（3〜10分）

組織管理デバイス：Intune管理センターまたはEntra IDで該当キーIDを検索
個人アカウントデバイス：ユーザーに aka.ms/myrecoverykey へのサインインを案内
キーID不一致の場合：複数台所有の可能性を確認、またはOEMが管理している可能性を案内

復旧フェーズ（10〜30分）

キー入力後にWindowsが正常起動：トリガー（更新・BIOS等）を記録し、必要なら回復キーをユーザーに改めて配布
自動修復ループ：第4章の手順でBCD修復
キーが取得できない：データ救出は不可能であることを誠実に伝え、初期化＋再セットアップへ案内

第6章：Microsoft Intuneでの組織的なBitLocker管理

場当たり的な対応から脱却するためには、組織として「すべてのデバイスの回復キーをEntra ID／Intuneに確実にエスクロー（保管）させる」状態を作ることが必須です。これができていないと、何度同じ手順書を回しても、現場の負担は減りません。

6-1. ディスク暗号化ポリシーの作成手順

Intune管理センター → 「エンドポイントセキュリティ」 → 「ディスク暗号化」 → 「+ ポリシーの作成」
プラットフォーム：Windows / プロファイル：BitLocker
「BitLockerドライブ暗号化を有効にする」を「はい」に設定
「BitLocker - OSドライブ設定」で次を構成：
- 暗号化アルゴリズム：XTS-AES 256-bit（推奨）
- OSドライブの起動認証：TPMのみまたは TPM＋PIN（高セキュリティ環境）
- BitLocker回復情報をAzure Active Directoryに保存：はい
- BitLocker回復情報がAzure ADに保存されるまでBitLockerを有効にしない：はい（重要）
割り当て：すべてのデバイスまたは特定のグループ

6-2. 暗号化レポートを使った可視化

Intune管理センターの「デバイス」→「監視」→「暗号化レポート」で、テナント全体の暗号化状況を一覧できます。次の状態は重点的に監視してください。

「Encrypted (Encryption method does not match the BitLocker policy)」：自動暗号化されたものの、ポリシーで指定したアルゴリズムと違う状態。一度復号してから再暗号化する必要があります。
「Awaiting user action」：TPM未準備、または起動認証がポリシーと合致せず、暗号化を開始できない状態。
「Recovery key not backed up」：もっとも危険。回復キーがどこにも保存されておらず、トラブル発生時には復旧不能となります。ここがゼロになるまでは、夜もぐっすり眠れません。

6-3. 既存のキーをスクリプトで強制エスクロー

24H2以降のクリーンインストール時にIntuneポリシーが間に合わず、ローカルにしか回復キーが残っていない――そんなデバイスを救うには、PowerShellプラットフォームスクリプトとしてIntuneから配布できる強制バックアップスクリプトが効きます。

$blv = Get-BitLockerVolume -MountPoint "C:"
$rp = $blv.KeyProtector |
  Where-Object { $_.KeyProtectorType -eq "RecoveryPassword" }

foreach ($protector in $rp) {
  BackupToAAD-BitLockerKeyProtector `
    -MountPoint "C:" `
    -KeyProtectorId $protector.KeyProtectorId
}

このスクリプトをIntune → 「デバイス」 → 「スクリプトと修復」 → 「プラットフォームスクリプト」で配布すると、各PCで実行され、回復キーがEntra IDへバックアップされます。地味ですが、効果は絶大です。

第7章：Windows 11 25H2のBitLocker新機能と注意点

2026年に多くの組織が直面することになる25H2では、BitLocker周りに次の改善と注意点があります。

ハードウェアオフロード暗号化

Intel第13世代Core以降のSoCに搭載された暗号化エンジンに、BitLockerのI/O処理がオフロードされるようになりました。CPU使用率が大幅に下がり、ノートPCのバッテリ寿命にもプラスに働きます。組織側で特別な設定は不要です（個人的にはここが一番嬉しいアップデート）。

セキュリティベースラインの更新

Microsoftが提供する「Windows 11 バージョン25H2 セキュリティベースライン」では、BitLocker関連の推奨設定がさらに厳格化されています。XTS-AES 256-bitがデフォルトとなり、未エスクロー状態での暗号化開始を許容しないポリシーに変更されています。Intuneのセキュリティベースラインから直接インポートして、組織のポリシーに統合できます。

個人データ暗号化（PDE）との併用

BitLockerに加え、ファイル単位でWindows Hello認証と連動する個人データ暗号化（PDE）も併用可能になっています。BitLockerは「ディスク全体」、PDEは「特定フォルダ／ファイル」と役割が異なるため、機密情報を扱う組織では組み合わせると多層防御を構築できる、というわけですね。

第8章：デバイス暗号化を意図的に無効化する手順

BYODのHomeエディションPCで業務利用していない場合や、回復キーバックアップ手段が確保できない個人ユーザーから依頼があった場合の手順です。

設定アプリから（デバイス暗号化）

「設定」→「プライバシーとセキュリティ」→「デバイスの暗号化」
「デバイスの暗号化」のトグルをオフにする
確認ダイアログで「オフにする」を選択
復号処理が完走するまで待機（容量によりますが、30分〜数時間かかります）

BitLocker（Pro / Enterprise）の場合

コントロールパネルから「BitLockerドライブ暗号化」を開き、「BitLockerを無効にする」をクリック。または管理者権限のターミナルで次を実行します。

manage-bde -off C:

進捗を確認するには、こちらのコマンドを使います。

manage-bde -status C:

「変換状況：完全に復号化されました」と表示されれば完了です。

OOBE段階で自動暗号化を阻止する方法

新規PCのキッティング時、Microsoftアカウントでサインインする前にローカルアカウントで初期化することで自動暗号化を回避できます。OOBE中に Shift + F10 でコマンドプロンプトを開き、次のレジストリ値を設定してから先へ進めましょう。

reg add "HKLM\SYSTEM\CurrentControlSet\Control\BitLocker" /v PreventDeviceEncryption /t REG_DWORD /d 1 /f

キッティング後にIntuneポリシーで意図的にBitLockerを有効化する運用と組み合わせれば、回復キーが確実にEntra IDへエスクローされる状態を作れます。これは大規模展開のときに本当に効きます。

第9章：予防策とユーザー教育

ヘルプデスクの問い合わせ件数を恒久的に減らすには、技術的な仕組みと利用者教育の両輪が必要です。片方だけだと、いずれ穴が空きます。

技術側の対策

すべての組織管理デバイスでIntuneディスク暗号化ポリシーを必須化し、「Entra IDに保存されるまで暗号化しない」を有効に
暗号化レポートを月次で監査し、エスクロー漏れデバイスをゼロに維持
BIOS／ファームウェア配信時はBitLockerを -RebootCount オプションで一時停止する管理スクリプトを併用
機能更新プログラム（24H2→25H2など）の展開リング配信前に、検証リングで回復キー要求の有無をチェック

ユーザー教育の要点

「青い画面でキーIDが表示されたら、まず最初にヘルプデスクへ連絡」と明文化したクイックリファレンスを配布
BYOD利用者には「個人のMicrosoftアカウント」と「業務用組織アカウント」を絶対に混在させないことを周知
四半期ごとに aka.ms/myrecoverykey でキーIDの存在確認を呼びかけ

FAQ：よくある質問

Q1. BitLocker回復キーを紛失しました。Microsoftサポートに問い合わせれば再発行できますか？

残念ながら、再発行はできません。Microsoftは設計上、サポート部門であってもユーザーの回復キーを生成・取得・提供することはできない仕組みになっています。Microsoftアカウント／Entra ID／Intune／オンプレADのいずれにも保存されておらず、ローカルにも控えがない場合は、暗号化されたデータの復元は事実上不可能です。ドライブを初期化してWindowsを再インストールするしかありません。これがBitLockerが「強い暗号化」と評される理由でもあります（裏返せば、それだけ徹底しているということです）。

Q2. ロック画面に表示される「キーID」と「回復キー」の違いは何ですか？

キーIDは、その回復キーを識別するための公開ID（GUID）で、先頭8桁が画面に表示されます。これ自体では復号できません。一方、回復キーは48桁の数値（6桁×8グループ）で、これを入力することで実際に暗号化を解除できます。Microsoftアカウントなどから取得する際は、画面に表示されたキーIDの先頭8桁と、保存されているキーのキーIDが一致するものを必ず選んでください。間違ったキーを入力するとカウンタが増え、最終的にロックされる場合があるので、ここはちょっと慎重に。

Q3. Windows 11 Home版でBitLockerが自動有効化されたのですが、これは正常な動作ですか？

はい、Windows 11 24H2以降の正常な動作です。従来Home版では「デバイス暗号化」と呼ばれる簡易版がHSTI準拠デバイスのみで自動有効化されていましたが、24H2以降は前提条件が緩和され、TPM 2.0搭載のほぼすべてのデバイスで自動的にONになります。回復キーは初期セットアップ時にサインインしたMicrosoftアカウントへ自動アップロードされているはずなので、念のため aka.ms/myrecoverykey で表示されることを確認しておいてください。業務利用していない個人PCで暗号化が不要な場合は、第8章の手順で無効化できます。

Q4. Windows Update後に毎回回復キーを聞かれます。どうすれば良いですか？

更新前にBitLocker保護を一時停止していなかったために、毎回PCR値の変化で回復モードに入っている可能性が高いです。組織配布の場合は、Windows Updateを配布するスケジュールに合わせ、Intuneのプラットフォームスクリプトで Suspend-BitLocker -MountPoint "C:" -RebootCount 2 を実行する仕組みを組むと、再起動を含む更新中は保護が一時停止され、終了後に自動再開されます。個別PCでの応急処置としては、サインイン後に管理者ターミナルで manage-bde -protectors -disable C: -RebootCount 1 を実行してから次の更新を適用してみてください。それでも頻発するようなら、TPMファームウェアまたはマザーボード故障の可能性もあるため、ハードウェア診断を実施します。

Q5. 退職者のPCを再利用したいのですが、BitLockerが有効のままで本人のアカウントが使えません。どう対応すれば良いですか？

組織管理デバイスであれば、Entra IDまたはIntuneから当該デバイスの回復キーを管理者権限で取得できます（第3章3-2、3-3参照）。回復キーで一度ロックを解除した後、Windowsを初期化（「設定」→「システム」→「回復」→「このPCをリセット」）すれば再利用可能です。Intune登録デバイスの場合は、Intune管理センターから「ワイプ」を実行することで、ローカルアカウント情報をクリアしながらデバイスを再展開できます。BYOD扱いで個人Microsoftアカウントに紐づいていた場合は、退職者の協力なしには回復キーを取得できないため、入社時にBYOD運用を許可するかどうかのポリシーを社内で明確化しておくことが重要です（ここで揉めるケースを何度も見てきました）。