BitLocker実務ガイド ── 回復キーの管理から始めるドライブ暗号化

「PCを初期化したら、次の起動で見たことのない青い画面が出て、48桁のキーを求められた」「BIOSを更新しただけなのに回復キーの入力画面になった。そんなキーは預かっていない」「新しいPCの設定を見たら『デバイスの暗号化』が勝手にオンになっている。業務アプリが遅くなりそうだし、切ってしまっていいか」── ここ1年ほど、お客様からこの種の相談が目に見えて増えました。

背景ははっきりしています。Windows 11 バージョン24H2以降、クリーンインストールしたPCでは「デバイスの暗号化」(BitLockerの自動有効化)が既定で動くようになったからです。ハードウェア要件も緩和され、対象になるPCは大きく広がりました。つまりBitLockerはもう「大企業が意識して導入するもの」ではなく、「中小企業のPCにも黙って入ってくるもの」に変わっています。このとき唯一の生命線になるのが回復キーで、これが誰の管理下にもないまま暗号化だけが進んでいる状態が、いちばん危険です。

この記事では、中小企業の情シス担当者・経営者と、業務アプリや装置PCを預かる開発者を対象に、BitLockerを「切るもの」ではなく「使いこなすもの」として整理します。エディションごとの違い、TPMと鍵の関係という最低限の仕組み、回復キーの保存先の判断表、組織での有効化と運用、事故対応、そして廃棄との関係まで、2026年8月時点のMicrosoft Learn等の一次情報にもとづいて解説します。

1. まず結論

• BitLockerはドライブ全体を暗号化するWindowsの機能で、紛失・盗難・不適切な廃棄によるデータ流出を防ぎます。ディスクを抜いて別のPCにつなぐ攻撃に対しても、暗号化されていればデータは読めません。¹
• フル機能のBitLockerを有効化できるのはPro/Enterprise/Pro Education/Educationです。その簡易版である「デバイスの暗号化」はHomeを含む全エディションで利用できます。¹
• Windows 11 24H2以降、自動デバイス暗号化の要件が緩和されました。HSTI/Modern Standby要件と「未許可のDMAインターフェイスがないこと」の要件が撤廃され、クリーンインストール後のOOBE(初期セットアップ)完了時に、TPM+UEFIセキュアブートを満たす多くのPCで暗号化が既定で初期化されます。²
• 暗号化の「開始」と保護の「有効化」は別です。Microsoftアカウント・Entra ID・(回復ポリシー構成済みの)AD DSのいずれかへ回復キーのバックアップが成功するまで、保護は有効化(アーム)されません。どこにもバックアップされないローカルアカウントのみのPCは、暗号化されていても保護されない状態のままです。¹²
• 回復キー(48桁の回復パスワード)の保存先は、Entra ID / AD DS / Microsoftアカウント / 印刷・ファイルの4択です。Entra ID参加ならEntra IDへ、ADドメイン参加ならAD DSへ、どちらでもなければ管理者のMicrosoftアカウントへ、というのが既定の流れです。¹³
• 回復キーが要求されるのは異常時だけではありません。ファームウェア更新、セキュアブート設定変更、TPMのクリア、マザーボード交換、ドライブの載せ替えなど、起動環境の変化はすべてトリガーになり得ます。計画作業の前には保護の一時停止(サスペンド)が定石です。³
• 既定の暗号化方式はXTS-AES 128ビットです。方式を後から変えるには復号→再暗号化が必要なので、初回に決め切るのが得策です。新品ドライブなら「使用済み領域のみ暗号化」で初回の暗号化時間を大幅に短縮できます。⁴⁵
• 回復キーを聞かれて出せないPCのデータは、諦めるしかありません。Microsoftサポートも紛失したキーは取り出せません。だからこそ本記事の主題は「暗号化するかどうか」ではなく「回復キーをどこに保存し、誰が取り出せるようにするか」です。⁶

この記事の知識マップ

BitLockerはドライブ全体を暗号化して紛失・盗難によるデータ流出を防ぎ、暗号化キーの保護には通常TPMを使います。Windows 11 24H2以降は「デバイスの暗号化」により多くのPCで自動的に暗号化が初期化されるため、生命線である回復キーをEntra ID・AD DS・Microsoftアカウントのどこに保存し、誰が取り出せるようにするかの管理が実務の中心になります。

flowchart LR
    accTitle: BitLocker実務ガイドの知識マップ
    accDescr: BitLocker、TPM、デバイスの暗号化、回復キー、回復モードとその引き金(ファームウェア更新・セキュアブート変更・ハードウェア交換)、保存先(Entra ID・AD DS・Microsoftアカウント・手動の控え)、エディション条件、クリアキーと保護されない暗号化状態、修理・廃棄時の運用の関係を示す図
    bitlocker["BitLocker"]
    recovery_key["回復キー(回復パスワード)"]
    tpm["TPM"]
    xts_aes["XTS-AES"]
    device_loss_data_leak["紛失・盗難によるデータ流出"]
    device_encryption["デバイスの暗号化"]
    uefi_secure_boot["UEFIセキュアブート"]
    entra_id["Microsoft Entra ID"]
    active_directory["Active Directory(AD DS)"]
    microsoft_account["Microsoftアカウント"]
    recovery_mode["BitLocker回復モード"]
    firmware_update["ファームウェア更新"]
    group_policy["グループポリシー"]
    intune["Microsoft Intune"]
    bitlocker_pin["起動時PIN(TPM+PIN)"]
    startup_key["スタートアップキー"]
    bitlocker_suspend["保護の一時停止(サスペンド)"]
    key_backup_policy["回復情報のバックアップ必須ポリシー"]
    recovery_key_loss["回復キー不在によるデータ喪失"]
    manage_bde["manage-bde"]
    pro_edition["Windows Pro/Enterprise系エディション"]
    home_edition["Windows Homeエディション"]
    clear_key["クリアキー"]
    local_account["ローカルアカウント"]
    unprotected_encryption["保護されない暗号化状態"]
    hardware_replacement["ハードウェア交換"]
    printed_copy["印刷・ファイルの控え"]
    used_space_only["使用済み領域のみ暗号化"]
    repair_maintenance["修理・保守作業"]
    recovery_key_exposure["回復キーの漏えい"]
    key_rotation["回復パスワードの再発行(ローテーション)"]
    pc_disposal["PC廃棄"]
    data_erasure["データ消去手順"]
    encryption_overhead["暗号化の性能影響"]
    msinfo32["msinfo32(システム情報)"]
    password_protector["パスワード方式"]
    personal_account_storage["担当者個人アカウントでの回復キー保管"]
    recovery_key_id["回復キーID"]
    cipher_choice["暗号化方式の選定"]
    unattended_pc["無人運転の装置PC"]
    encrypted_master_image["保護有効化済みイメージの複製"]
    clone_deployment["クローン展開"]
    dpapi["DPAPI"]
    app_secrets["アプリの秘密情報"]
    bitlocker -.->|"利用する"| tpm
    bitlocker -->|"利用する"| xts_aes
    bitlocker -->|"防止する"| device_loss_data_leak
    device_encryption -->|"自動化する"| bitlocker
    device_encryption -->|"前提とする"| tpm
    device_encryption -->|"前提とする"| uefi_secure_boot
    recovery_key -.->|"に保存される"| entra_id
    recovery_key -.->|"に保存される"| active_directory
    recovery_key -.->|"に保存される"| microsoft_account
    recovery_mode -->|"前提とする"| recovery_key
    firmware_update -.->|"原因になり得る"| recovery_mode
    bitlocker -->|"で構成できる"| group_policy
    bitlocker -->|"で構成できる"| intune
    bitlocker -.->|"利用する"| bitlocker_pin
    bitlocker -.->|"利用する"| startup_key
    bitlocker_suspend -.->|"防止する"| recovery_mode
    key_backup_policy -->|"防止する"| recovery_key_loss
    key_backup_policy -->|"で構成できる"| group_policy
    recovery_mode -.->|"原因になり得る"| recovery_key_loss
    bitlocker -->|"で確認できる"| manage_bde
    bitlocker -->|"前提とする"| pro_edition
    home_edition -->|"利用する"| device_encryption
    device_encryption -->|"利用する"| clear_key
    local_account -.->|"原因になり得る"| unprotected_encryption
    unprotected_encryption -.->|"原因になり得る"| device_loss_data_leak
    uefi_secure_boot -.->|"原因になり得る"| recovery_mode
    tpm -.->|"原因になり得る"| recovery_mode
    hardware_replacement -.->|"原因になり得る"| recovery_mode
    recovery_key -.->|"に保存される"| printed_copy
    bitlocker -.->|"利用する"| used_space_only
    repair_maintenance -.->|"原因になり得る"| recovery_key_exposure
    key_rotation -->|"軽減する"| recovery_key_exposure
    pc_disposal -->|"前提とする"| data_erasure
    data_erasure -->|"防止する"| device_loss_data_leak
    bitlocker -.->|"原因になり得る"| encryption_overhead
    bitlocker_suspend -->|"より先に行うべき"| firmware_update
    key_backup_policy -->|"より先に行うべき"| bitlocker
    key_rotation -->|"推奨される対応"| recovery_key_exposure
    key_rotation -.->|"前提とする"| key_backup_policy
    device_encryption -->|"で確認できる"| msinfo32
    password_protector -->|"用いるのは非推奨"| bitlocker
    personal_account_storage -.->|"原因になり得る"| recovery_key_loss
    recovery_key -->|"で確認できる"| recovery_key_id
    recovery_key -->|"で確認できる"| manage_bde
    cipher_choice -->|"より先に行うべき"| bitlocker
    bitlocker_pin -->|"両立しない"| unattended_pc
    encrypted_master_image -->|"用いるのは非推奨"| clone_deployment
    dpapi -->|"推奨される対応"| app_secrets

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全48件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. BitLockerとデバイス暗号化の違い ── エディション別に何が使えるか

まず言葉を整理します。「BitLocker」と「デバイスの暗号化」は同じ暗号化技術の2つの顔です。

• BitLocker(フル機能): ドライブ単位で有効化し、TPM+PIN・スタートアップキーなどの認証方式、グループポリシー/Intuneでの制御、manage-bde.exe やPowerShellでの管理まで含む、管理者向けの姿。
• デバイスの暗号化(Device Encryption): 要件を満たすPCでBitLockerを自動で有効にする仕組み。設定アプリに「デバイスの暗号化」のスイッチが現れ、OSドライブと内蔵の固定ドライブだけを暗号化します(外付け/USBドライブは対象外)。¹

エディション別の対応は次のとおりです。¹

Windows 11 24H2で何が変わったか

自動デバイス暗号化は以前からありましたが、対象は「Modern StandbyまたはHSTI準拠」「外部からDMAアクセス可能なポートがない」といった条件を満たす、比較的新しめのモバイルPC中心でした。Windows 11 バージョン24H2でこの2つの要件が撤廃され、残る主要条件は「TPM(1.2または2.0)を搭載」「UEFIセキュアブートが有効」などに絞られました。OEMが未許可DMAバスをレジストリ(AllowedBuses)に登録する運用も不要になり、このキー自体が24H2以降は無視されます。なお、この要件緩和はWindows IoTエディションには適用されません。²

その結果、クリーンインストール(初期化・再セットアップを含む)後のOOBEを完了すると、ごく普通のデスクトップPCでも暗号化が既定で初期化されるようになりました。ここで重要なのが「初期化」と「保護の有効化」の区別です。

• OOBE完了時点では、ドライブはクリアキー(保護なしの一時鍵)で暗号化された状態です。エクスプローラーには警告アイコンが表示されます。¹
• Microsoftアカウント・Entra IDアカウントでのサインイン、またはドメイン参加PCなら(回復ポリシー構成済みの)AD DSへのバックアップが成功すると、TPMプロテクターが作成されクリアキーが除去されます。ここで初めて保護が有効になります。¹²
• ローカルアカウントのみで使っているPCは、暗号化されていても保護されないままです。¹

この流れを図にすると次のとおりです。

flowchart TB
    A["クリーンインストール・初期化<br/>(Windows 11 24H2以降)"] --> B{"TPM+UEFIセキュアブート等の<br/>要件を満たすか"}
    B -- "満たさない" --> Z["暗号化されない"]
    B -- "満たす" --> C["OOBE完了時に暗号化を初期化<br/>(クリアキー=保護なしの一時鍵)"]
    C --> D{"回復キーの<br/>バックアップ先は?"}
    D -- "Microsoftアカウント / Entra ID /<br/>AD DS(回復ポリシー構成済み)" --> E["回復キーのバックアップに成功"]
    E --> F["TPMプロテクター作成・クリアキー除去<br/>=保護が有効化(アーム)される"]
    D -- "ローカルアカウントのみ<br/>(バックアップ先がない)" --> G["暗号化されたまま保護は無効<br/>(警告アイコンが表示される)"]

「気づいたら暗号化されていた」の正体はこの仕組みです。Windows 10のサポート終了対応でWindows 11 PCへの入れ替えを進めている組織は(Windows 10サポート終了の判断)、新PCが最初からこの状態で届くことを前提に、回復キーの管理をキッティング手順に組み込む必要があります。

自機の対応状況は、システム情報(msinfo32.exe)を管理者として開き、「デバイスの暗号化のサポート」の行で確認できます。「前提条件を満たしています」なら対象です。¹

3. 仕組みの最低限 ── TPMと鍵の関係

BitLockerの鍵を守っているのはTPM(Trusted Platform Module)です。TPMはOSがオフラインの間にデバイスが改ざんされていないことを確認する役割を担い、起動時の検証に通ったときだけ暗号化キーを使えるようにします。だからこそ、正規のWindowsが正常に起動すればユーザーは何も入力せずに使え、ディスクだけ抜き取られた場合は読めない、という両立ができます。¹ TPMそのものの仕組み(鍵を外に出さない構造、PCR、測定起動)は「WindowsのTPMとは何か」で図解しています。

起動のたびに起きていることを図にすると、こうなります。

flowchart TB
    ON["電源オン"] --> M["TPMが起動環境を測定<br/>(ファームウェア・ブート構成など)"]
    M --> Q{"測定結果は<br/>いつもと同じか"}
    Q -- "同じ" --> UN["TPMが暗号化キーを解放"]
    UN --> BOOT["通常起動<br/>(ユーザーは何も入力しない)"]
    Q -- "違う" --> REC["回復モード<br/>48桁の回復キーを要求"]
    REC --> K1["回復キーを入力できれば起動"]
    REC --> K2["入力できなければ<br/>データは取り出せない"]

TPMに加えて、起動時にPINの入力やスタートアップキー(USBメモリ内の鍵ファイル)の挿入を必須にする多要素構成も選べます。TPMのないPCでもスタートアップキー方式でOSドライブを暗号化できますが、パスワード方式はロックアウトの仕組みがなく総当たりに弱いため、既定で無効化されています。¹

回復キーが要求されるのはどんなときか

TPMは「起動環境がいつもと同じか」を見ているため、環境が変わると正規の持ち主でも回復モードに入ります。Microsoftが挙げる代表的なトリガーは次のとおりです。³

• BIOS/UEFIファームウェアの更新など、起動初期コンポーネントの更新
• TPMをオフ・無効化・クリアした、またはTPMの自己テスト失敗
• TPM検証プロファイルが使うPCR(プラットフォーム構成レジスター)の変更 ── セキュアブート設定の変更はここに効きます
• マザーボード交換(新しいTPMへの交換)
• BitLocker保護されたドライブを別のPCに移設した
• ドッキングステーションへの着脱、NTFSパーティションテーブルの変更、ブートマネージャーの変更、PXEブート
• PINの誤入力を繰り返した、(TPM 1.2の機種で)起動デバイス順序を変更した

つまり「BIOS更新で回復キーを聞かれた」は故障でも攻撃でもなく、設計どおりの動作です。計画的な作業(ファームウェア更新やハードウェア交換)の前には保護を一時停止(サスペンド)するのが定石で、一時停止してもドライブは暗号化されたまま、作業後は回復キーの入力なしで再開できます。既定では再起動すると保護が自動で再開されます(再起動回数の指定も可能)。³

# ファームウェア更新の前に一時停止。既定では1回の再起動で保護が自動再開する
# ため、複数回再起動する更新では2回目以降の再起動が回復画面で止まり得る。
# -RebootCount 0 で自動再開を止め、作業完了後の再開を手順に組み込む
Suspend-BitLocker -MountPoint C: -RebootCount 0
# 作業後に必ず再開する(-RebootCount 0 では自動再開しないため、この実行が必須)
Resume-BitLocker -MountPoint C:

なお用語について。技術文書では48桁の数字を「回復パスワード」、USBメモリに保存する .bek ファイルを「回復キー」と区別しますが³、一般向けの画面や本記事では、広く使われている呼び方に合わせて48桁の数字を「回復キー」と呼びます。

4. 回復キーの保存先判断表 ── 4択をどう選ぶか

本記事の核心です。回復キーの保存先は実質4択で、PCのサインイン形態でほぼ自動的に決まります。まず判断表を示します。

ハイブリッド参加(ADとEntra IDの両方)のデバイスでは、回復パスワードは両方にバックアップされます。⁴

組織として押さえるポイントは3つです。

1. 「組織の保存先」を1つに決める。Entra ID参加が進んでいるならEntra ID、オンプレADならAD DSです。担当者個人のMicrosoftアカウントに会社PCの回復キーが入っている状態は、退職・異動で即座に破綻します。
2. AD DSは「自動で入る」と思い込まない。AD DSへのバックアップにはポリシー構成(後述)が前提です。また、Active Directoryは回復パスワードの履歴を保持し続け、古いキーはコンピューターオブジェクトを削除しない限り自動では消えません。³
3. ファイル保存を選ぶなら保存場所を厳格に。回復キーのファイルは、そのPC自身以外の場所(ネットワークフォルダー等)に保存する必要があります。⁵ 回復キーを持つ者はドライブの全データにアクセスできるため、保護対象のPCと分離して保管し、アクセスを統制することが必須です。³

いま自分のPCがどうなっているかを確認する

管理者権限のターミナルで、次のいずれかを実行します。⁵

# PowerShell: 暗号化状態とプロテクターの種類を確認
Get-BitLockerVolume C: | Format-List
# 回復パスワード(48桁)とそのIDを確認
(Get-BitLockerVolume -MountPoint C).KeyProtector

:: コマンドプロンプト: 状態確認
manage-bde -status
:: プロテクター(TPM、回復パスワード等)の一覧と48桁の値
manage-bde -protectors -get C:

manage-bde -protectors -get C: の出力に「数字パスワード」(Numerical Password)として表示されるのが48桁の回復キーで、あわせて表示されるIDの先頭8桁が、回復画面で「どのキーか」を照合する手がかりになります。⁶

すでに暗号化済みのPCの回復パスワードを、後からEntra IDやAD DSへバックアップすることもできます。⁵

# 回復パスワードのIDを確認してから実行
# Entra IDへバックアップ
BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId "{ID}"
# AD DSへバックアップ
Backup-BitLockerKeyProtector -MountPoint C: -KeyProtectorId "{ID}"

:: manage-bdeの場合
manage-bde -protectors -aadbackup C: -id {ID}
manage-bde -protectors -adbackup C: -id {ID}

「全PCの回復キーが組織の保存先に入っているか」の棚卸しは、IPAの中小企業向けガイドラインで言う情報セキュリティの基本対策と同じく、一度やって終わりではなく台帳運用に載せる類のものです(「中小企業のセキュリティ対策、何から始めるか」)。

5. 組織での有効化と運用 ── ポリシー・コマンド・暗号化方式

5.1. ポリシーで「回復キーなしの有効化」を禁止する

BitLockerの設定は、グループポリシー(GPO)とMDM(IntuneなどのBitLocker CSP)の両方から構成できます。⁴ 回復キー管理の観点で最重要のポリシーは「BitLockerで保護されているオペレーティングシステムドライブの回復方法を選択する」です。ここで次を構成します。⁴³

• AD DSに回復情報を保存する(回復パスワードのみ、またはキーパッケージも含めて)
• 「回復情報がAD DSに保存されるまでBitLockerを有効にしない」を有効化 ── バックアップが成功しない限り暗号化を始めさせない、事故防止の要です。この構成では回復パスワードが自動生成されます

Entra ID参加デバイスをIntuneで管理している場合も考え方は同じで、回復キーのバックアップを必須にしたうえで暗号化を有効化します。Entra ID上の回復キーは、Entra管理センター・Intune管理センター・PowerShell・Microsoft Graphから取得でき、ヘルプデスクへの委任もできます。³

5.2. 暗号化方式 ── 既定はXTS-AES 128

暗号化方式を構成しない場合、BitLockerは既定でXTS-AES 128ビットを使います。デバイスの暗号化も既定はXTS-AES 128です。ポリシー「ドライブ暗号化方法と暗号強度を選択してください」でXTS-AES 256などに変更できますが、Microsoftの推奨は全ドライブXTS-AESとしたうえで、鍵長はデバイスの性能(と業界の規制要件)に応じて128/256を選ぶ、というものです。⁴¹

注意すべきは、すでに暗号化済みのドライブの方式は後から変えられないことです。方式や鍵長を変えるには、いったん復号してから再暗号化する必要があります。¹ 「規制要件で256ビットが必要」といった事情があるなら、展開の初回に決め切ってください。

5.3. 使用済み領域のみ暗号化 vs ドライブ全体

有効化時にもう1つ選ぶのが暗号化範囲です。Microsoftの使い分けの指針は明快です。⁵

• 使用済み領域のみ暗号化: データを置いたことのない新品ドライブ向け。初回の暗号化が速い
• ドライブ全体の暗号化: すでに使ってきたドライブ ── データを置いたことがある、削除済みファイルが残り得るドライブ向け

理由は、削除済みファイルの領域はファイルシステム上「空き領域」に見えるため、「使用済み領域のみ」では暗号化されず、上書きされるまでフォレンジックツールで復元され得るからです。⁵ キッティング直後の新品PCなら「使用済み領域のみ」で問題なく、使い込んだPCに後から適用するなら全体暗号化、と覚えておけば実務では十分です。

5.4. PowerShellでの有効化

スクリプト展開の基本形は次のとおりです。⁵

# 1. 先に回復パスワード(48桁)プロテクターを追加する(この時点では暗号化は始まらない)。
#    再試行などで回復パスワードが複数残っていても、今回追加した1本だけを
#    特定できるよう、追加前後のID差分で選ぶ
$before = (Get-BitLockerVolume -MountPoint C).KeyProtector.KeyProtectorId
Add-BitLockerKeyProtector -MountPoint C: -RecoveryPasswordProtector | Out-Null
$rpId = (Get-BitLockerVolume -MountPoint C).KeyProtector |
    Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' -and $_.KeyProtectorId -notin $before } |
    Select-Object -ExpandProperty KeyProtectorId

# 2. 追加した回復パスワードを組織の保存先へバックアップする。ここが失敗したら
#    暗号化に進んではいけないので、-ErrorAction Stop でエラー時は処理を止める
#    (Entra管理センター/ADでキーが見えることの確認までがこの手順)
BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $rpId -ErrorAction Stop
# AD DSなら: Backup-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $rpId -ErrorAction Stop

# 3. バックアップが成功してから、暗号化を開始する。3aと3bは排他 ──
#    どちらか一方だけを実行する(方式・範囲もここで決め切る)

# 3a. 標準構成: TPMのみ(無人再起動が必要な端末はこちら)
Enable-BitLocker C: -EncryptionMethod XtsAes256 -UsedSpaceOnly -TpmProtector

# 3b. TPM+PIN構成(据え置きの高セキュリティ端末向け)。3aの代わりに実行する。
#     PINは端末ごとに別の値をその場で入力する。スクリプトに平文で埋め込むと、
#     全端末が同じPINになるうえスクリプト自体が漏えい点になる
$Pin = Read-Host -AsSecureString -Prompt "この端末のPIN"
Enable-BitLocker C: -EncryptionMethod XtsAes256 -UsedSpaceOnly -Pin $Pin -TPMandPinProtector

「回復パスワードを預けてから暗号化を始める」というこの順序が重要です。逆に Enable-BitLocker -TpmProtector から始めると、処理が途中で止まった時点で回復手段の控えがないままTPM保護だけが効いたPCが残り、次のファームウェア更新やハードウェア変更でデータごと失いかねません。上の並びなら、途中で止まっても暗号化はまだ始まっておらず、やり直すだけで済みます。組織展開では、5.1の「回復情報が保存されるまでBitLockerを有効にしない」ポリシーを先に効かせておけば、この中途半端な状態はポリシー側でも防げます。「バックアップの成功確認より先に暗号化を始めない」が組織展開の鉄則です。

6. 事故対応 ── 「回復キーを聞かれた」「見つからない」とき

6.1. 回復画面が出たら、まずキーIDの先頭8桁

青い回復画面には回復キーIDが表示されます。控えが複数ある場合も、IDの先頭8桁を突き合わせれば正しいキーを特定できます。⁶ 探す場所は4章の表のとおりで、順に当たります。

1. 組織の保存先(Entra ID管理センター/Intune、またはAD DS) ── 管理者・ヘルプデスク経由
2. 利用者自身のアカウント ── 職場アカウントなら aka.ms/aadrecoverykey、個人のMicrosoftアカウントなら aka.ms/myrecoverykey⁶
3. 有効化時の控え ── 印刷した紙、USBメモリ内のファイル、保存したテキストファイル⁶

flowchart TB
    REC["青い回復画面<br/>回復キーIDが表示される"] --> ID["キーIDの先頭8桁を控える"]
    ID --> ORG["1. 組織の保存先<br/>(Entra ID管理センター・Intune / AD DS)"]
    ORG -- "IDが一致するキーあり" --> INPUT["48桁を入力して起動"]
    ORG -- "見つからない" --> SELF["2. 利用者自身のアカウント<br/>aka.ms/aadrecoverykey / aka.ms/myrecoverykey"]
    SELF -- "一致するキーあり" --> INPUT
    SELF -- "見つからない" --> PAPER["3. 有効化時の控え<br/>(印刷した紙・USBメモリ・ファイル)"]
    PAPER -- "一致するキーあり" --> INPUT
    PAPER -- "見つからない" --> LOST["初期化(全データ消失)しかない<br/>Microsoftも取り出せない"]
    INPUT --> AFTER["原因を確認し、使った回復キーは<br/>無効化して再発行(6.3節)"]

あわせて「なぜ回復モードに入ったのか」の原因確認を習慣にしてください。前日にBIOS更新をした、セキュアブート設定を触った、といった心当たりがあれば設計どおりの動作です。心当たりがないのに繰り返し発生する場合は、ハードウェアの不調や、物理アクセスによる改変の可能性まで含めて調べる価値があります。³

6.2. どうしても見つからない場合

厳しい話ですが、回復キーが見つからなければ、その暗号化ドライブのデータを取り出す方法はありません。組織管理のPCならIT部門への確認が最後の砦で、それでもなければデバイスの初期化(全データ消失)しかありません。Microsoftサポートは紛失した回復キーを提供・再作成できません。⁶

これを「暗号化のせいでデータが消えた」と捉えるのは因果が逆です。回復キーの管理を仕組みにしていなかったことが原因で、同じ管理不備は盗難時には情報漏えいとして表面化していたはずです。

6.3. 使った回復キーは使い捨てる ── 修理・紛失・退職の運用

• 修理に出すとき: 修理業者に回復キーを渡した(または渡した可能性がある)なら、戻ってきた後にまず新しい回復パスワードを追加してEntra ID / AD DSへのバックアップ成功を確認し、そのうえで渡した回復パスワードを削除します。先に削除すると、追加やバックアップが失敗した時点でそのドライブは回復手段のない状態になるため、順序が重要です。Microsoftも使用後の回復パスワードの無効化を推奨しており、追加→バックアップ→削除の一連はコマンドで完結します。⁵ Entra ID参加デバイスでは、使用された回復パスワードを自動でローテーションするポリシーもあります。既定値はEntra ID参加デバイスで有効ですが、回復情報のバックアップを必須にするポリシー(5.1)が構成されているときにだけ機能します。自動ローテーションをあてにする前に、この前提の構成と、実際にキーが入れ替わることを確認してください。⁴
• PCを紛失したとき: 保護が有効(TPMプロテクター作成済み・クリアキー除去済み)だったかを4章のコマンド出力の記録や管理ツールで確認し、暗号化されていたなら「ディスク上のデータは読めない」と説明できる状態になります。これが平時に棚卸しをしておく最大の理由です。
• 退職・PC返却のとき: 返却されたPCの回復キーが退職者個人のMicrosoftアカウントにしかない、という状態を作らないことが第一です。組織の保存先への集約(4章)ができていれば、返却時の作業は再キッティングと回復パスワードの再発行だけで済みます。

たとえば修理のケースを流れにすると、次のとおりです。

flowchart LR
    S["修理に出す<br/>(回復キーを渡した可能性)"] --> B["PCが戻る"]
    B --> N["新しい回復パスワードを追加"]
    N --> BK["Entra ID / AD DSへの<br/>バックアップ成功を確認"]
    BK --> D["渡した回復パスワードを<br/>無効化(削除)する"]
    D --> OK["台帳を更新して完了"]

7. 廃棄との関係 ── 暗号化済みディスクは廃棄が楽になる

BitLockerの効能は使用中だけではありません。ドライブが最初から暗号化されていれば、廃棄時にディスク上に残っているのは暗号文だけです。BitLockerはそもそも、紛失・盗難だけでなく「不適切に廃棄されたデバイス」からのデータ流出を防ぐ機能として設計されており、保護されたデバイスの廃棄・リサイクル時にデータを読めなくすることが目的に含まれています。¹

ただし、暗号化されているからといって、廃棄時の消去手順(初期化・専用の消去ツール・物理破壊)を省略してよいわけではありません。暗号化は「消去前・消去不能時にディスクから平文を読まれるリスクを下げる」保険であり、検証可能な消去の代替ではないからです。そのうえで、暗号化運用の組織には固有の作業がひとつ足されます ── 回復キーの控え(紙・ファイル・ADやEntra ID上の登録)の整理です。ディスクを消去しても、控えの回復キーが残っていれば台帳上の廃棄は完了していません。古いキーの削除まで含めて廃棄手順の一部にしてください。

もっとも、PCの廃棄には暗号化以外の論点 ── アカウントやライセンスの解除、資産台帳、証跡 ── もあります。全体の手順は「Windows PCを廃棄する前にやっておきたいこと」にチェックリストとしてまとめてあるので、暗号化を前提にした廃棄フローの整備にはそちらをあわせて使ってください。

8. 業務アプリ開発者の視点 ── 性能・装置PC・クローン展開

最後に、業務アプリや装置制御PCを預かる立場からの注意点です。

• 性能影響は「まず既定の128ビットで実測」が基本です。Microsoft自身が、鍵長の選択基準を「デバイスの性能次第」とし、性能の高いドライブ・CPUなら256ビット、そうでなければ128ビットとしています。⁴ 裏を返せば、現代のPCで既定のXTS-AES 128が業務アプリの体感を左右することはまれで、当社でもファイルI/Oが特別に重いアプリ以外で問題になった経験はほぼありません。疑わしければ、本番相当のデータ量で暗号化前後のI/Oを実測してから判断すべきで、感覚で「遅くなりそうだから切る」のは本末転倒です。
• 暗号化はアプリから透過です。BitLockerはボリューム全体の暗号化であり、ファイルAPIの動作は変わりません。逆に言うと、実行中のマシン上でアプリが扱う秘密情報(接続文字列・APIキー)はBitLockerでは守れません。ログオン済みのマシンではドライブは復号されて見えるからです。そちらはDPAPI等の出番です(「Windowsアプリの秘密情報はどこに保存するか」)。
• 装置PC・キオスクPCは「無人再起動できるか」で構成を決めます。TPMのみの構成なら電源断からの復帰も無人で立ち上がりますが、TPM+PINやスタートアップキーは起動のたびに人手が要り、無人運転の装置には向きません。一方でTPMのみ構成は、3章のトリガー(ファーム更新等)で回復画面のまま停止するリスクを抱えるので、現場から離れた場所(施錠保管+台帳)に回復キーを置き、装置の保守手順書に「作業前のSuspend-BitLocker」を明記することが運用の要になります。無人端末の固め方全般は「キオスクモードで業務端末を固める」で扱っています。なお、24H2の自動デバイス暗号化の要件緩和はWindows IoTエディションには適用されませんが²、これは「IoTなら自動暗号化が起きない」という意味ではありません。緩和前からの要件(HSTI/Modern Standby等)を満たす機種では従来どおり自動暗号化があり得るため、装置PCでも manage-bde -status での状態確認をキッティング手順に入れておくのが確実です。
• クローン展開では「暗号化してからイメージ化」をしない。回復パスワードは作成したデバイスに固有のものです。³ 保護を有効化した状態の親機イメージを複製する構成は取らず、展開後にPCごとに有効化(またはOOBEでの自動暗号化)→回復キーのバックアップ、という順序にします。キッティングをスクリプト化しているなら(「winget + PowerShellでPCキッティングを自動化する」)、5.4節の有効化とバックアップ確認を最終工程に足すだけです。

9. まとめ

• Windows 11 24H2以降のクリーンインストールでは、TPM+UEFIセキュアブートを満たすPCでデバイスの暗号化が既定で初期化されます。HSTI/Modern StandbyとDMAの要件は撤廃され、対象は普通のデスクトップPCにまで広がりました。
• 「勝手に暗号化された」への正しい対応は無効化ではなく、回復キーの所在確認です。切れば紛失・盗難・廃棄時の保護を失い、一度切ると自動では再有効化されません。
• 回復キーの保存先はEntra ID / AD DS / Microsoftアカウント / 印刷・ファイルの4択で、サインイン形態でほぼ決まります。組織の保存先を1つ決め、全PCがそこに入っているかを棚卸ししてください。
• 確認は manage-bde -protectors -get C: または (Get-BitLockerVolume -MountPoint C).KeyProtector、後追いのバックアップは BackupToAAD-BitLockerKeyProtector / Backup-BitLockerKeyProtector で完結します。
• 回復キーはファームウェア更新・セキュアブート設定変更・ハード交換などで正規の持ち主にも要求されます。計画作業の前のSuspend-BitLockerを手順書に入れてください。
• 既定の方式はXTS-AES 128で、後から変えるには復号→再暗号化が必要です。新品ドライブなら使用済み領域のみ暗号化で十分です。
• 使った回復キーは無効化して再発行する、退職者のアカウントにキーを残さない、廃棄時はキーの控えまで葬る ── 回復キーは「発行して終わり」ではなくライフサイクルで管理するものです。
• 暗号化は廃棄時の保険にもなりますが、消去手順(初期化・消去ツール・物理破壊)の代替ではありません。BitLockerを切るのではなく、回復キー管理とセットで使いこなすことが、中小企業にとっての現実解です。

関連記事

• WindowsのTPMとは何か ── 図解でわかる「鍵を外に出さない金庫」と測定起動
• Windows PCを廃棄する前にやっておきたいこと ── データ消去・アカウント解除・バックアップの実務チェックリスト
• Windows 10サポート終了後の現実解 ── ESU・LTSC・買い替えの判断表
• 中小企業のセキュリティ対策、何から始めるか ── IPA「中小企業の情報セキュリティ対策ガイドライン」第4.0版の歩き方
• キオスクモードで業務端末を固める ── Assigned Access・Shell Launcherの選び方と運用設計
• winget + PowerShellでPCキッティングを自動化する ── 手順書を実行可能にする
• Windowsアプリの秘密情報はどこに保存するか ── DPAPIを軸にしたベストプラクティス

関連する相談領域

合同会社小村ソフトでは、業務アプリ・装置PCを含むWindows環境の暗号化運用の設計(回復キーの保存先設計、キッティングへの組み込み、装置PCでのBitLocker構成)や、暗号化環境での業務アプリの性能検証・トラブル調査の相談を扱っています。「装置PCを暗号化しても大丈夫か」を確かめるところからで構いません。

• 技術相談・設計レビュー
• Windowsアプリ開発
• 不具合調査・原因解析
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

気づいたら「デバイスの暗号化」が有効になっていました。無効にしていいですか？

無効化はおすすめしません。Windows 11 バージョン24H2以降のクリーンインストールでは、TPMとセキュアブートなどの条件を満たすPCでデバイスの暗号化が既定で初期化されるため、「勝手にオンになった」ように見えます。これは紛失・盗難時にデータを守る仕組みで、切ると保護を失ううえ、一度オフにすると自動では再有効化されません。やるべきことは無効化ではなく、manage-bde -protectors -get C: などで回復キーを確認し、Microsoftアカウント・Entra ID・ADなど組織で決めた場所に保存されている状態にすることです。

BitLockerの回復キーはどこにありますか？

保存先はPCのサインイン形態で決まります。個人のMicrosoftアカウントで設定したPCなら https://aka.ms/myrecoverykey に同じアカウントでサインインすると一覧できます。会社のEntra ID(職場アカウント)参加PCは https://aka.ms/aadrecoverykey の「BitLockerキーの表示」で確認できます。オンプレのADドメイン参加PCは、ポリシー構成済みならコンピューターオブジェクト配下から管理者が取り出せます。ほかに印刷した紙やUSBメモリ・ファイルの控えもあり得ます。回復画面の回復キーIDの先頭8桁と突き合わせると正しいキーを特定できます。

Windows 11 HomeのPCでもBitLockerは使えますか？

エディションで使える機能が違います。PIN追加やポリシー管理を含むフル機能のBitLockerを有効化できるのはPro/Enterprise/Education系で、Homeでは使えません。一方、簡易版のデバイスの暗号化はHomeを含む全エディションで利用でき、TPMとUEFIセキュアブートなどの要件を満たせば自動で有効になります。ただし保護の有効化には管理者権限のMicrosoftアカウントでのサインインが必要で、ローカルアカウントのみでは保護されません。会社のPCとして管理するなら、Proを前提にEntra IDまたはADで回復キーを集中管理する構成をおすすめします。

BIOS(UEFIファームウェア)を更新したら回復キーを要求されました。なぜですか？

BitLockerはTPMを使って起動環境が改ざんされていないかを検証しており、ファームウェア更新・セキュアブート設定の変更・TPMのクリア・マザーボード交換などで起動時の測定値が変わると、「いつもと違う環境」と判断して回復モードに入ります。これは故障ではなく設計どおりの動作です。計画的な更新作業の前には、Suspend-BitLocker(またはmanage-bde -protectors -disable C:)で保護を一時停止してから実施すれば、回復キーの入力なしで作業できます。一時停止中もドライブは暗号化されたままで、既定では次回再起動時に保護が自動で再開されます。

回復キーが見つからない場合、データは取り出せますか？

正しい回復キー(48桁の回復パスワード)や他の解除手段がない限り、暗号化されたドライブのデータを取り出す方法はありません。Microsoftのサポートも紛失した回復キーを再発行・取り出しすることはできないと明言しています。組織管理のPCならまずIT部門に確認し、個人PCならMicrosoftアカウントの回復キーページ、印刷した控え、USBメモリ内の.bek/.txtファイルを探してください。それでも見つからなければPCの初期化(再インストール)しかなく、データは失われます。だからこそ、暗号化を切るかどうかを議論する前に、全PCの回復キーが組織の管理下にあることを先に確認すべきです。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。