更新履歴(2件・最終更新 2026年08月02日)
この記事に加えた変更の記録です。アーカイブした更新前のバージョンは、DOI付きの固定URLから読めます。
- この記事の知識マップに含まれる関係を見直しました。本文より広い主張になっていたもの(条件付きでしか成り立たない関係、「防ぐ」ではなく「軽減する」にあたる関係、前提ではなく推奨にあたる関係)を、条件付きに改めるか、より正確な述語に置き換えています。本文の主張は変えていません。
- 知識マップの図と関係データを修正しました。BitLockerとTPMの関係は、TPMを搭載しないPCではスタートアップキー方式を使えるため、「常に成り立つ関係」から条件付きの関係(破線)に改めました。
- 初版公開
この記事を引用する(DOI(登録済みアーカイブ): 10.5281/zenodo.21739484)
以下のDOIは過去に登録されたアーカイブを指しており、現在の本文とは一致しない場合があります。現在の本文を参照するときは、このページのURLを使用してください。
小村 豪(2026)「BitLocker実務ガイド ── 回復キーの探し方と安全な管理」合同会社小村ソフト. https://comcomponent.com/blog/bitlocker-practical-guide/
- DOI(登録済みアーカイブ)
- 10.5281/zenodo.21739484
- DOI(前回登録した版)
- 10.5281/zenodo.21739485
「BIOSを更新したら、青い画面で48桁の数字を求められた」「自分で設定した覚えがないのに、デバイスの暗号化がオンになっていた」。BitLockerで困ったときは、いまWindowsが起動しているかどうかで、最初にすべきことが変わります。
回復画面で止まっているなら、設定変更や初期化より先に、画面の回復キーIDに一致するキーを探します。まだ起動できるなら、暗号化のスイッチだけを見るのではなく、保護状態と回復キーの保管先を確認します。この2つを分けると、必要な作業が見えやすくなります。12
| いまの状況 | 先に読むところ | 最初にすること |
|---|---|---|
| 回復画面で起動が止まっている | 1章 | キーIDを控え、別の端末から保存先を確認する |
| Windowsは起動している | 4章 | 暗号化率と保護状態を別々に確認する |
| 会社のPCをまとめて管理したい | 5章 | 保存先と取得権限を決め、実際に取り出せることを確認する |
| BIOS更新・修理を予定している | 6〜7章 | 回復手段を確保してから、必要な保守作業を計画する |
この記事は、個人PCの利用者、中小企業のIT担当者、業務アプリや装置PCを管理する開発者に向けた実務ガイドです。前半は回復と状態確認、後半は導入・保守・廃棄を扱います。管理コマンドはWindows上の管理者権限で実行する例であり、回復画面からそのまま実行する手順ではありません。技術情報は2026年9月8日時点のMicrosoftの公開資料を確認しています。
図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全48件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle
1. 回復画面が出たら、初期化より先にキーを探す
1.1. 入力する48桁と、探すためのIDは別物
一般向けの画面で「BitLocker回復キー」と呼ばれるのは、通常、48桁の数字からなる回復パスワードです。WindowsのサインインパスワードやWindows HelloのPINではありません。一方、画面に表示される回復キーIDは、保存済みのキーを選ぶための識別子であり、解除用の秘密そのものではありません。1
まずキーIDの先頭8文字を控えます。数字だけとは限らないため、「8桁の暗証番号」と考えないでください。別のPCやスマートフォンで保存先を開き、一致するIDのエントリから48桁の回復キーを取り出して、回復画面に入力します。同じPC名の古い記録が残ることもあるので、PC名だけで選ばないことが重要です。Windows 11 24H2以降では、保存先のMicrosoftアカウントを推測する手がかりが回復画面に表示される場合もあります。1
flowchart TB
accTitle: 回復キーIDと回復キーの役割
accDescr: 画面のIDで保存先のエントリを照合し、対応する48桁を入力する手順を示します。
A["回復画面のキーIDを控える"] --> B["別の端末で保存先を開く"]
B --> C["IDが一致する記録を探す"]
C --> D["対応する48桁を入力する"]
図1: IDはキーを探すため、48桁はドライブを解除するために使います。
1.2. 保存先を決めつけず、設定したときまで遡る
| 確認する場所 | 探し方 | 注意点 |
|---|---|---|
| 個人のMicrosoftアカウント | 回復キーの確認ページを開く | 現在使っているアカウントではなく、最初に設定した人のアカウントにある場合もある |
| 職場・学校アカウント | 職場・学校の回復キー確認ページから対象デバイスを探す | 表示権限がなければIT管理者に照会する |
| 組織の管理先 | 管理者がEntra ID、Intune、AD DSなどを確認する | AD DSへの保存には回復ポリシーなどの事前構成が必要 |
| 印刷・ファイルの控え | 紙、USBメモリ、別のPC、管理された保管場所を確認する | ロックされたPCの中だけに置いたファイルでは取り出せない |
これらは代表的な保存先であり、互いに排他的な4択ではありません。同じキーを複数の場所に保管することもできます。「Microsoft 365を使っているから必ず会社側にある」「いまローカルアカウントだからMicrosoftアカウントにはない」とは判断できません。PCを設定した人、組織への参加状態、有効化当時のポリシー、後から行ったバックアップを確認します。134
技術文書では、48桁の回復パスワードと、USBなどに保存する .bek 形式の回復キーを区別します。本記事では一般向けの呼称に合わせて前者を「回復キー」と呼びますが、.bek ファイルは48桁として入力するものではありません。構成に応じた回復手順を使ってください。3
1.3. 見つからなくても、データを消す操作は最後にする
キーが見つからない段階で、TPMのクリア、セキュアブート設定の変更、初期化を試すのは避けます。回復要求の原因になり得る変更を増やしても、保存されていない回復キーが現れるわけではありません。組織PCでは管理者に確認し、事前に構成したデータ回復エージェントなど、別の正規の回復手段がないかを確認します。35
有効な解除手段をすべて失った場合、Microsoftサポートも回復キーを取り出したり再作成したりできません。 その段階で、別に保管したデータのバックアップから復旧できるかを確認します。PCを再利用するための初期化・再インストールと、元の暗号化データを取り戻すことは別です。初期化によってローカルファイルが失われることを理解してから判断してください。1
flowchart TB
accTitle: 回復キーが見つからない場合の判断
accDescr: 管理者と別の回復手段を確認してから、データのバックアップとPCの再利用を分けて判断します。
A["通常の保存先に見つからない"] --> B["管理者と設定した人に確認"]
B --> C{"有効な解除手段があるか"}
C -- "ある" --> D["正規の手順で回復する"]
C -- "ない" --> E["データのバックアップを確認"]
E --> F["消失範囲を確認して再利用を判断"]
図2: キーの探索、データの復旧、PCの初期化を一つの操作として扱わないことが大切です。
2. BitLockerは何を守り、何を守らないのか
BitLockerは、Windowsのボリューム単位の暗号化機能です。主な目的は、紛失・盗難や不適切な廃棄によって、保存されているデータをオフラインで読み取られるリスクを下げることです。たとえばSSDを取り外して別のPCにつないでも、有効な解除手段がなければ、暗号化された内容を通常のファイルとして読むことはできません。なお「ドライブ全体」という説明は、EFIなどの起動用パーティションまで何もかも暗号化するという意味ではありません。6
一方、Windowsが起動してドライブが解除されている間は、アクセス権を持つアプリはファイルを読み書きできます。BitLockerだけでマルウェア、ランサムウェア、ログオン済み端末からの持ち出しを防げるわけではなく、データのバックアップの代わりにもなりません。暗号化を評価するときは、どの状態の端末を、どのような相手から守るかを分けて考えます。7
flowchart TB
accTitle: BitLockerが守る場面
accDescr: オフラインのドライブ保護と、起動後のアプリによるアクセスは別の層であることを示します。
A["保存された業務データ"] --> B["オフラインのドライブ"]
A --> C["起動済みのWindows"]
B --> D["BitLockerで内容を保護"]
C --> E["権限とアプリ側の対策も必要"]
図3: 保存データの暗号化と、起動後のアクセス制御は役割が異なります。
TPMはデータを暗号化する装置ではなく、鍵を保護する仕組み
一般的な構成では、BitLockerはTPMを利用して鍵を保護します。起動コンポーネントの測定結果がTPMのPCRに記録され、設定された検証条件を満たすと、通常起動に必要な鍵を利用できるようになります。TPM自体がSSD上の全データを暗号化しているわけでも、すべてのBIOS変更を一律に拒否しているわけでもありません。68
flowchart TB
accTitle: TPMを使うBitLockerの通常起動と回復
accDescr: 起動環境の測定値が検証条件を満たす場合は通常解除し、満たさない場合は回復手段が必要になります。
A["起動環境を測定してPCRに記録"] --> B{"設定された検証条件を満たすか"}
B -- "満たす" --> C["TPMを使って通常解除"]
B -- "満たさない" --> D["回復手段による解除が必要"]
図4: 起動環境の変更が回復要求につながるかどうかは、検証する条件にも依存します。
BIOS/UEFI更新、TPMの無効化・クリア、セキュアブート設定の変更、マザーボード交換、ドライブの移設などは、回復を要求されるきっかけになり得ます。正規の保守作業でも起こるため、回復画面が出た事実だけで「攻撃された」「故障した」とは断定できません。反対に、心当たりなく繰り返す場合は、更新履歴や設定変更、ハードウェアの状態を調べる必要があります。3
TPMに起動時PINを組み合わせる構成や、スタートアップキーを使う構成もあります。TPMがない場合のOSドライブ暗号化も、対応エディションとポリシーの下で可能です。ただし、TPMなしのOSドライブに対するパスワード方式は総当たりへの耐性の問題があり、既定では無効です。固定データドライブのパスワード保護と混同しないでください。TPMの詳細は「WindowsのTPMとは何か」で扱っています。6
3. Home・Proの違いと、Windows 11の自動暗号化
3.1. 「デバイスの暗号化」もBitLockerの技術を使っている
「BitLockerドライブ暗号化」と「デバイスの暗号化」は、無関係な暗号化製品ではありません。後者はBitLockerの技術を使い、対応するPCで暗号化を有効にしやすくした仕組みです。設定画面や管理できる範囲が異なります。9
| 主なエディション | BitLockerドライブ暗号化の有効化・詳細管理 | デバイスの暗号化 |
|---|---|---|
| Windows Home | 対象外 | 対応するPCで利用可能 |
| Windows Pro / Pro Education | 利用可能 | 対応するPCで利用可能 |
| Windows Enterprise / Education | 利用可能 | 対応するPCで利用可能 |
デバイスの暗号化はOSドライブと内蔵の固定ドライブが対象で、USBメモリなどのリムーバブルドライブは対象外です。会社PCで起動時認証やポリシーを細かく管理するなら、必要なエディションと管理サービスの要件を先に確認します。69
3.2. 24H2で変わったのは対象条件であり、全PCの一律有効化ではない
Windows 11 24H2では、自動デバイス暗号化の要件からHSTI/Modern Standbyと一部のDMAに関する条件が外れました。そのため、対象となるハードウェアが広がっています。ただし、TPMやUEFIセキュアブートなどの条件、セットアップ方法、組織やメーカーの構成も関係します。「24H2に更新したすべてのPCが、その場で必ず暗号化・保護される」という意味ではありません。 また、この要件緩和はWindows IoTエディションには適用されません。8
クリーンインストール後の自動有効化では、暗号化の初期化と保護の有効化が別の段階になります。初期状態ではクリアキーがあり、暗号化されていても保護はまだ有効ではありません。Microsoftアカウント、Entra ID、または回復ポリシーを構成したAD DSへのバックアップなど、該当する経路の条件が整うと、TPMによる保護が有効になり、クリアキーが除かれます。6
flowchart TB
accTitle: 自動暗号化の開始と保護の有効化
accDescr: 対応PCの自動暗号化では、クリアキーのある初期状態から回復情報の保存を経て保護が有効になります。
A["自動暗号化の条件を満たすPC"] --> B["暗号化を初期化"]
B --> C["クリアキーあり・保護は未有効"]
C --> D["該当経路で回復情報を保存"]
D --> E["TPM保護を有効化"]
E --> F["クリアキーを除去"]
図5: 暗号化の処理が進むことと、第三者から守られた状態になることは同じではありません。
ローカルアカウントだけでは保護が有効にならない、という説明はこの自動有効化の流れについてです。 Proなどで管理者がBitLockerを手動構成する場合まで「ローカルアカウントでは暗号化できない」という意味ではありません。また、過去に有効化したPCをローカルアカウントへ切り替えて使っている場合もあるため、現在のアカウント名から保護状態を推測せず、次章のコマンドで確認します。62
設定項目が見つからない場合は、msinfo32.exeを管理者として起動し、「デバイスの暗号化のサポート」の情報を確認します。ただし、これは対応条件を調べるための表示です。いまドライブが保護されているかを確認する表示とは分けて読んでください。9
4. 状態確認では、暗号化率・保護状態・ロック状態を分ける
4.1. 最初は秘密を出力しないコマンドを使う
Windowsが起動できる状態で、管理者としてターミナルを開きます。まずは次の状態確認で十分です。C:は対象のOSドライブに合わせてください。10
manage-bde -status C:
BitLocker PowerShellモジュールを利用できる環境では、必要な項目だけを表示できます。ここでは回復パスワードの値を出力しません。11
Get-BitLockerVolume -MountPoint 'C:' -ErrorAction Stop |
Select-Object MountPoint, VolumeStatus, EncryptionPercentage,
ProtectionStatus, LockStatus, EncryptionMethod
| 項目 | 何を表すか | 読み違えやすい点 |
|---|---|---|
VolumeStatus / EncryptionPercentage |
暗号化・復号処理の状態と進捗 | 100%だけでは保護の有効化まで確認できない |
ProtectionStatus |
鍵による保護が有効か | 一時停止中などでは、暗号化済みでもOffになり得る |
LockStatus |
現在ドライブが解除されているか | Windows使用中のOSドライブがUnlockedなのは通常の状態 |
EncryptionMethod |
現在の暗号化方式 | ポリシーで指定した値と、実際のドライブの値は別途照合する |
たとえばFullyEncrypted・100%・ProtectionStatus: Offなら、「暗号化済みだから完了」とは扱いません。一時停止中なのか、初期化後の有効化待ちなのか、組織の設定がまだ適用されていないのかを調べます。反対に、ProtectionStatus: Onでも、管理先から回復キーを取得できることまでは証明しません。211
flowchart TB
accTitle: 暗号化と保護と回復可能性の確認
accDescr: 暗号化処理、保護状態、回復キーの取得可否をそれぞれ確認する必要があります。
A["状態を確認する"] --> B["暗号化処理は完了したか"]
B --> C["保護はOnになっているか"]
C --> D["別端末から回復キーを取得できるか"]
D --> E["確認結果を台帳に記録する"]
図6: 暗号化率だけでなく、保護が有効で、回復手段も管理できていることを確認します。
業務データをD:などに置いているPCでは、そのボリュームも対象にします。manage-bde -statusで全体を確認し、OSドライブだけを暗号化してデータドライブを見落としていないかを調べてください。10
4.2. 回復キーを表示する操作は、状態確認とは別に扱う
回復パスワードが構成されていて、Windows上で対象ドライブを管理できるなら、次のコマンドでプロテクターの情報を確認できます。ただし、48桁の秘密がそのまま表示される可能性があります。公開チャット、GitHub Issue、サポート依頼、画面共有、収集ログに出力を丸ごと貼らないでください。12
:: 注意: 回復パスワードの値が表示される。出力をそのまま共有しない
manage-bde -protectors -get C:
種類とIDだけが必要なら、PowerShellで表示項目を限定します。回復キーの値と、台帳に残す識別子を混同しないための例です。11
(Get-BitLockerVolume -MountPoint 'C:' -ErrorAction Stop).KeyProtector |
Select-Object KeyProtectorType, KeyProtectorId
この操作は起動不能のPCから未知のキーを取り出す裏技ではありません。現在アクセスできるボリュームにどの保護手段が構成されているかを調べるものです。回復パスワードがない場合や、保存先へのバックアップが未確認の場合は、組織の手順に従って追加・保存・取得確認を行います。2
5. 会社PCは「暗号化した」ではなく「回復できる」までを管理する
5.1. 保存先と取得権限をセットで決める
Entra ID参加PCならEntra ID、ADドメイン参加PCならAD DSが代表的な管理先です。ただし、参加したという事実だけで、期待したキーが保存されていると決めつけないでください。AD DSへの保存ポリシー、Entra IDやIntune側の構成、バックアップ処理の成否まで確認します。ハイブリッド参加でも、両方の保存先を利用する設計なら両方の実在確認が必要です。1314
小規模な組織でドメインやEntra IDを使わない場合は、対応エディションで手動構成し、アクセス制御された保管先や紙の控えを管理する方法もあります。重要なのは、担当者個人のMicrosoftアカウントだけに依存せず、担当者の退職後も、PCが起動しなくても、権限を持つ人が取り出せることです。キーをPCと同じ鞄に入れるような保管も避けます。4
flowchart TB
accTitle: 回復キーの保管と取得確認
accDescr: PCから管理先に保存するだけでなく、権限を持つ担当者が別端末から取得できることを確かめます。
A["管理対象のPC"] --> B["承認された保存先へバックアップ"]
B --> C["権限を持つ担当者"]
C --> D["別端末からIDを照合して取得"]
D --> E["不在時の代替担当も確認"]
図7: 「保存されたはず」ではなく、権限を持つ担当者による取得確認までが運用です。
台帳には、資産番号、対象ボリューム、回復キーID、保存先、取得できる担当者、最終確認日を記録すると扱いやすくなります。48桁そのものは一般の資産台帳から分離し、秘密情報として保管します。バックアップ先へのアクセスに、起動できなくなった当のPCが必須になっていないかも確認してください。これらは本記事で勧める運用上の確認項目です。
5.2. 新規導入では、回復情報の保存を有効化の前提にする
AD DSを利用する場合は、「BitLockerで保護されているオペレーティングシステムドライブの回復方法を選択する」ポリシーなどで、回復情報の保存内容と、AD DSへ保存されるまでBitLockerを有効にしない設定を構成できます。固定データドライブは対応するポリシーも確認します。Entra ID・Intuneを使う場合も、バックアップを要求する設定を含め、端末の参加状態と対応するポリシーを選びます。1314
flowchart TB
accTitle: 組織でBitLockerを導入する順序
accDescr: 回復情報の保存先とポリシーを先に決め、保存に失敗した端末を完了扱いにしない流れです。
A["保存先・取得権限・方式を決定"] --> B["バックアップ必須ポリシーを適用"]
B --> C["端末で有効化手順を実行"]
C --> D{"回復情報の保存を確認できたか"}
D -- "いいえ" --> E["原因を調べて導入を完了しない"]
D -- "はい" --> F["暗号化と保護の完了を確認"]
図8: 暗号化を急ぐより、回復手段のない端末を作らないことを優先します。
単体PCでは、コントロールパネルの「BitLockerの管理」から、有効化・回復キーの保存・暗号化範囲の選択を順に行えます。組織展開のスクリプトでは、途中で失敗する場合も含めて設計が必要です。Enable-BitLocker -TpmProtectorという1行だけを全PCに配り、「キーは後で保存すればよい」とする運用は避けます。まず少数の検証端末で、保存必須のポリシーと回復情報の取得を確かめてください。2
5.3. 既存の回復パスワードを後からバックアップする例
次は、すでに存在する回復パスワードをEntra IDへバックアップするだけの例です。暗号化の開始、新しい回復パスワードの作成、古いプロテクターの削除は行いません。Entra IDへのバックアップが可能な参加状態・構成で、管理者として実行します。15
$mountPoint = 'C:'
$volume = Get-BitLockerVolume -MountPoint $mountPoint -ErrorAction Stop
$recoveryProtectors = @(
$volume.KeyProtector |
Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' }
)
if ($recoveryProtectors.Count -eq 0) {
throw '回復パスワードがありません。組織の手順で追加・保存を行ってください。'
}
foreach ($protector in $recoveryProtectors) {
BackupToAAD-BitLockerKeyProtector -MountPoint $mountPoint `
-KeyProtectorId $protector.KeyProtectorId -ErrorAction Stop | Out-Null
}
Write-Output '保存処理が完了しました。管理先で各IDの回復キーを確認してください。'
AD DSに保存する構成なら、上のループ内のバックアップ処理を次に置き換えます。両者を理由なく続けて実行する例ではありません。対象ドメインやポリシーなどの前提を確認してください。16
Backup-BitLockerKeyProtector -MountPoint $mountPoint `
-KeyProtectorId $protector.KeyProtectorId -ErrorAction Stop | Out-Null
コマンドが成功したら、管理先でキーIDを照合し、権限のある担当者が取得できることを確認します。出力を抑えているのは、回復キーを通常の運用ログへ流さないためです。暗号化率、保護状態、回復情報の保存先という3つの確認を、1つの成功メッセージで代用しないようにします。
6. BIOS更新では「一時停止」と「無効化」を混同しない
6.1. 一時停止中は、暗号化されていても保護が弱まる
BitLockerの保護の一時停止は、データを暗号化したまま、クリアキーを使って起動できるようにする操作です。対して無効化は、ドライブを復号してBitLockerの保護を取り除く操作です。保守のために必要なのが前者なのに、後者を実行すると、長い復号処理と保護の喪失を招きます。Microsoftも、無効化を一般的なトラブルシューティング手順として使わないよう説明しています。172
flowchart TB
accTitle: 一時停止と無効化の違い
accDescr: 一時停止では暗号化を維持して保護を一時的に止め、無効化ではドライブを復号します。
A["BitLockerの状態を変更"] --> B["保護の一時停止"]
A --> C["無効化"]
B --> D["暗号化は維持・クリアキーを使用"]
C --> E["ドライブを復号する"]
図9: 一時停止は復号ではありませんが、一時停止中も通常どおり安全という意味ではありません。
一時停止中のPCを、回復キーを要求されないからといって放置したり、そのまま外部へ預けたりしないでください。クリアキーによってオフラインでの保護が弱まるため、作業時間と物理的な管理を限定し、終わったら保護を再開します。17
6.2. 先にキーを確認し、作業後はOnまで確認する
すべてのWindows Updateで手動の一時停止が必要なわけではありません。更新内容、PCメーカーの更新ツール、使用しているTPM検証プロファイルによって扱いが変わります。まずメーカーの手順を確認し、一時停止が必要な作業では、回復キーを別端末から取得できることを確かめてから実施します。8
flowchart TB
accTitle: 計画的なファームウェア更新の手順
accDescr: 回復手段を確認し、必要な場合だけ保護を一時停止して更新し、再開と状態確認で作業を終えます。
A["回復キーの取得を確認"] --> B["メーカーの更新手順を確認"]
B --> C["必要な場合に保護を一時停止"]
C --> D["更新と必要な再起動を実施"]
D --> E["保護を再開してOnを確認"]
図10: 再起動できたことではなく、保護が再開したことまで確認して保守を終えます。
1回の再起動で作業が完了する場合の例です。-RebootCount 1は、指定した再起動回数の後に自動再開させる指定です。17
# 回復キーの取得確認と、メーカーの手順確認を済ませてから実行する
Suspend-BitLocker -MountPoint 'C:' -RebootCount 1 -ErrorAction Stop | Out-Null
ここで更新作業と再起動を行います。更新作業を挟まずに、続けて再開コマンドを実行するわけではありません。 作業後、自動再開していなければ、メーカーの手順に沿って必要な作業が完了したことを確かめ、保護を再開します。18
Resume-BitLocker -MountPoint 'C:' -ErrorAction Stop | Out-Null
Get-BitLockerVolume -MountPoint 'C:' -ErrorAction Stop |
Select-Object MountPoint, VolumeStatus, ProtectionStatus
複数回再起動する更新では、1回目で保護が戻ると、その後の変更で回復画面になる可能性があります。必要な回数をメーカーの手順に合わせます。-RebootCount 0は「再起動しない」という意味ではなく、再起動回数による自動再開を行わない指定です。採用するなら、作業担当者と手動での再開確認を手順に明記してください。自動再開を指定した場合も、最後のProtectionStatus: Onの確認は省きません。1719
7. 修理・回復後・紛失時にすること
7.1. 回復キーを使ったら、必要に応じて入れ替える
回復パスワードを使った後は、そのパスワードを無効化して更新することが推奨されています。修理業者へ渡した場合も同様です。本記事では、回復手段を失う時間を作らないため、新しい回復パスワードを追加 → バックアップと取得を確認 → 古いものをID指定で削除という順序を勧めます。古いものを先にすべて消す手順は、後続処理が失敗したときに回復手段を失う危険があります。2
flowchart TB
accTitle: 回復パスワードを入れ替える順序
accDescr: 新しい回復パスワードの保存と取得を確認してから、対象となる古いプロテクターだけを削除します。
A["新しい回復パスワードを追加"] --> B["承認された保存先へバックアップ"]
B --> C["新しいIDで取得できることを確認"]
C --> D["古いプロテクターだけを削除"]
D --> E["台帳と保護状態を確認"]
図11: 先に新しい回復手段を確保し、削除対象は種類全体ではなくIDで特定します。
Entra ID参加やハイブリッド参加の構成では、使用後の回復パスワードを自動ローテーションするポリシーもあります。ただし、対応する参加状態や、回復情報のバックアップを必須にする設定などの前提があります。「会社PCだから自動で変わるはず」と考えず、適用ポリシーと新しいキーの保存を確認してください。13
また、キーの入れ替えは、すでにコピーされたデータや過去に取得されたディスクイメージを回収する機能ではありません。回復キーの漏えいが疑われる場合は、キーの更新だけで対応を終わらせず、アクセスされた範囲も検討します。
7.2. 暗号化済みPCの紛失でも、漏えいゼロとは断定しない
紛失時には、平時の管理記録から保護が有効だったかを確認します。それに加えて、電源断・スリープ・ログオン中のどの状態だったか、一時停止していなかったか、回復キーをPCと一緒に持ち歩いていなかったかを調べます。BitLockerは重要な対策ですが、暗号化済みという1項目だけで、すべての漏えい可能性を否定することはできません。7
flowchart TB
accTitle: 紛失時に確認する保護の条件
accDescr: 暗号化の有無に加えて、保護状態、電源状態、鍵の漏えい可能性を確認して影響を評価します。
A["PCを紛失"] --> B["保護状態の管理記録を確認"]
B --> C["電源状態と利用状況を確認"]
C --> D["回復キーの漏えい可能性を確認"]
D --> E["組織の事故対応手順で影響を評価"]
図12: 暗号化の有無は、紛失時の影響を判断するための重要な材料の一つです。
退職やPC返却でも、個人アカウントにしかキーが残っていない状態を避けます。返却後の再配布では、回復情報の管理、必要なデータの引き継ぎ、再キッティングを一体の手順として扱うと、担当者が変わっても運用を続けやすくなります。
8. 暗号化方式と性能は、展開前に決めて実測する
8.1. 方式の変更は、設定を書き換えるだけでは終わらない
通常のソフトウェア暗号化では、ポリシーで変更しない場合の既定はXTS-AES 128です。ただし、対応ハードウェアとWindowsの組み合わせによるハードウェアアクセラレーションなど、実装や既定値の例外もあります。したがって、「BitLockerなら現在の方式は必ず128ビット」と決めつけず、実機のEncryptionMethodを確認します。方式や鍵長は、組織の要件と端末の性能を踏まえて選びます。1320
すでに暗号化されたドライブの方式は、ポリシーを変更しただけでは切り替わりません。変更には復号と再暗号化が必要になるため、保護が弱まる時間、バックアップ、停止可能時間を含めて計画します。初回のキッティング前に決めておくほうが、運用途中の変更より扱いやすくなります。13
flowchart TB
accTitle: 暗号化方式を決めるタイミング
accDescr: 新規展開では方式を先に決め、既存端末では現在の方式と変更に伴う復号工程を確認します。
A["方式と鍵長の要件を確認"] --> B{"すでに暗号化済みか"}
B -- "いいえ" --> C["展開前にポリシーを決める"]
B -- "はい" --> D["実機の方式を確認"]
D --> E["必要なら復号と再暗号化を計画"]
図13: ポリシーの変更と、既存ドライブの暗号化方式の変更は同じ作業ではありません。
性能の判断では、「暗号化したら遅そう」という印象と実測を分けます。本番相当のデータ量・ストレージ・アプリで、処理時間、読み書き量、CPU負荷を測り、暗号化処理中の一時的な負荷と、完了後の継続的な影響も区別します。端末条件を示さず「影響はゼロ」「必ず何%遅い」と言い切るより、要件を満たすかを確かめるほうが実務的です。20
8.2. 「使用済み領域のみ」は、過去の削除データに注意する
新しいドライブでは「使用済み領域のみ暗号化」で初回処理を短縮できます。一方、過去に機密データを平文で保存したドライブでは、削除済みファイルの領域が問題になります。ファイルシステム上では空き領域でも、データの痕跡が残っている可能性があり、使用済み領域だけの暗号化ではその部分が対象になりません。2
flowchart TB
accTitle: 使用済み領域のみ暗号化するときの注意
accDescr: 削除済みデータは空き領域に残る場合があり、使用済み領域だけの暗号化では保護範囲から外れます。
A["過去に平文の機密データを保存"] --> B["ファイルを削除"]
B --> C["空き領域に痕跡が残る場合"]
C --> D["使用済み領域のみでは対象外"]
D --> E["全体暗号化や適切な消去を検討"]
図14: ファイルを削除したことと、その内容が媒体から消えたことは別です。
初回の速さだけで選ばず、ドライブの利用履歴も確認してください。なお、全体暗号化は廃棄時の消去証明ではありません。廃棄・譲渡では10章のように、別途消去手順を定めます。
9. 業務アプリ・無人端末・クローン展開での注意点
9.1. アプリの秘密情報には、別の対策も必要
通常、解除済みのBitLockerボリューム上で、アプリは普段どおりファイルAPIを使います。だからこそ、接続文字列やAPIキーを平文ファイルに置いた問題が、BitLockerを有効化するだけで解消するわけではありません。実行中のアプリや同じ利用者の権限で読み取れる情報は、別の境界で考える必要があります。7
flowchart TB
accTitle: ドライブ暗号化とアプリの秘密情報
accDescr: BitLockerで保存媒体を保護していても、起動後にアプリが扱う秘密には保存方法とアクセス権の設計が必要です。
A["BitLockerで媒体を保護"] --> B["Windows起動後にドライブを解除"]
B --> C["アプリは権限に従って読み書き"]
C --> D["秘密の保存方法と権限を別途設計"]
図15: BitLockerとアプリ側の秘密情報保護は、置き換えではなく組み合わせです。
DPAPIなどを使う場合も、どのユーザーやコンピューターに保護を結び付けるかを考えます。DPAPIを使えば、同じユーザー権限の攻撃者にも必ず読まれない、という意味ではありません。具体例は「Windowsアプリの秘密情報はどこに保存するか」で解説しています。21
9.2. 無人で再起動できることと、回復できることは別
TPMのみの構成は通常起動時の入力を減らせますが、起動環境の変化による回復要求までなくすものではありません。TPM+PINを選ぶと、通常は起動時の入力が必要です。無人運転の装置では、セキュリティ要件と、現場で入力できる人がいるかを両方確認します。ネットワークロック解除などの専用構成は別途設計するもので、単にPINを有効にすれば無人運用も続けられるわけではありません。622
flowchart TB
accTitle: 無人端末の通常起動と回復時の備え
accDescr: 通常の再起動を自動化できても、回復要求が出た場合の担当者とキー取得手順は別途必要です。
A["無人端末の起動方式を選ぶ"] --> B["通常再起動の可否を確認"]
B --> C["回復画面で止まる場合も想定"]
C --> D["現場の担当者と取得手順を準備"]
図16: 無人再起動の試験だけでなく、回復画面で停止した場合の運用も準備します。
スタートアップキーをUSBに置く場合も、必要なときに使えることと、PCと一緒に盗まれないことを両立させます。また、Windows IoTでは24H2の要件緩和の対象外だからといって、暗号化されないと決めつけないでください。実際の状態確認をキッティングに含めます。端末全体の制限については「キオスクモードで業務端末を固める」も参考になります。82
9.3. 回復キーを使い回すマスターイメージにしない
保護を有効化した親機の状態を、そのまま多数のPCへ複製する前提にしないでください。BitLockerには展開時の事前プロビジョニングという仕組みもありますが、これは、クリアキーを使う準備段階と端末ごとの保護の有効化を分けたものです。「暗号化されたイメージならすべて不可」でも「親機の回復キーを全台で共有してよい」でもありません。23
flowchart TB
accTitle: 端末ごとの保護を確立する展開手順
accDescr: イメージ展開後は端末ごとのプロテクターと回復情報を構成し、保存先と保護状態を個別に確認します。
A["展開方式に沿ってイメージを配置"] --> B["端末ごとのプロテクターを構成"]
B --> C["端末ごとの回復情報を保存"]
C --> D["ID・取得可否・保護状態を確認"]
図17: 共通化するのはセットアップ手順であり、全PCの回復キーではありません。
「winget + PowerShellでPCキッティングを自動化する」ような自動化でも、最後は暗号化の処理結果だけでなく、端末ごとの回復情報と保護状態を確認する工程を残します。
10. 廃棄時は、暗号化と消去を別の作業として扱う
BitLockerは、不適切な廃棄による情報流出リスクを下げる助けになります。しかし、「暗号化済み」「Microsoftアカウントからキーを削除した」という事実だけで、媒体の消去が完了したとは判断しません。ほかの解除手段や鍵の控えが残ることもあるためです。63
本記事では、必要なデータを保全したうえで、媒体と組織の基準に合う消去・破壊方法を選び、実施結果を確認し、資産台帳と回復キーの記録を整理する順序を勧めます。鍵の記録を消すことを先に急ぐと、まだ必要だったデータへアクセスできなくなるおそれがあります。
flowchart TB
accTitle: 暗号化済みPCを廃棄する順序
accDescr: 必要なデータを確保し、媒体の消去結果を確認してから、組織の保存方針に沿って鍵と台帳を整理します。
A["必要なデータを保全"] --> B["媒体に適した消去・破壊"]
B --> C["実施結果と証跡を確認"]
C --> D["保存方針に沿って鍵の記録を整理"]
D --> E["資産台帳を更新"]
図18: 回復キーの記録整理は、必要なデータの保全と媒体の処理を確認した後に行います。
AD DSやEntra IDの記録には、組織の保持・監査方針も関係します。すべての古いキーをその場で消すことを一律の手順にせず、管理者の手順で整理してください。アカウント、ライセンス、資産管理を含む全体の確認は「Windows PCを廃棄する前にやっておきたいこと」にまとめています。
11. まとめ ── 回復キーを取り出せる状態までを運用にする
BitLockerで最初に確かめたいのは、「暗号化を切るべきか」ではなく、何が暗号化され、保護が有効で、どの回復キーを誰が取り出せるかです。
回復画面ならキーIDを手がかりに保存先を探します。まだWindowsが動くなら、状態確認と回復キーの取得確認を済ませます。保守前には回復手段を確保し、必要な場合にだけ保護を一時停止して、作業後はOnまで確認します。これらをPCの導入・更新・返却の手順に組み込むことで、「有効にした人だけが分かる暗号化」から、担当者が変わっても扱える保護にできます。
参考リンク
-
Microsoft Support, Find your BitLocker recovery key. キーIDの照合、個人・職場アカウントや紙・USBの確認、別の人がセットアップした場合、回復手段が見つからない場合について。 ↩ ↩2 ↩3 ↩4 ↩5
-
Microsoft Learn, BitLocker operations guide. 状態確認、導入、プロテクターの管理、一時停止と再開、暗号化範囲、回復パスワードの更新について。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9
-
Microsoft Learn, BitLocker recovery overview. 回復のトリガー、回復パスワードと回復キーファイル、保存先と回復手段について。 ↩ ↩2 ↩3 ↩4 ↩5
-
Microsoft Support, Back up your BitLocker recovery key. 回復キーのバックアップ方法とPCから分離した保管について。 ↩ ↩2
-
Microsoft Learn, BitLocker recovery process. 組織の回復手順、データ回復エージェント、管理者による回復情報の取得について。 ↩
-
Microsoft Learn, BitLocker overview. 保護の目的、TPMと起動時認証、対応エディション、自動デバイス暗号化の基本動作について。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8
-
Microsoft Learn, BitLocker countermeasures. 攻撃モデル、起動・電源状態、TPMとPINなどを含む保護の考え方について。 ↩ ↩2 ↩3
-
Microsoft Learn, BitLocker drive encryption in Windows 11 for OEMs. 24H2での要件変更、IoTの例外、PCRとファームウェア更新時の注意点について。 ↩ ↩2 ↩3 ↩4
-
Microsoft Support, Device Encryption in Windows. デバイスの暗号化、対応機種、設定とシステム情報による確認について。 ↩ ↩2 ↩3
-
Microsoft Learn, manage-bde status. ボリュームの暗号化率、方式、保護とロック状態の確認について。 ↩ ↩2
-
Microsoft Learn, Get-BitLockerVolume. ボリューム情報とKeyProtectorプロパティの確認について。 ↩ ↩2 ↩3
-
Microsoft Learn, manage-bde protectors. プロテクターの表示、回復情報のバックアップ、追加・削除操作について。 ↩
-
Microsoft Learn, Configure BitLocker. 回復情報の保存必須ポリシー、暗号化方式、回復パスワードのローテーションについて。 ↩ ↩2 ↩3 ↩4 ↩5
-
Microsoft Learn, Encrypt Windows devices with BitLocker in Intune. Intuneでの暗号化ポリシーと回復キーの管理について。 ↩ ↩2
-
Microsoft Learn, BackupToAAD-BitLockerKeyProtector. 回復パスワードプロテクターをEntra IDへバックアップするコマンドについて。 ↩
-
Microsoft Learn, Backup-BitLockerKeyProtector. 回復パスワードプロテクターをAD DSへバックアップするコマンドについて。 ↩
-
Microsoft Learn, Suspend-BitLocker. 一時停止とクリアキー、RebootCountの指定について。 ↩ ↩2 ↩3 ↩4
-
Microsoft Learn, Resume-BitLocker. 一時停止後の保護再開について。 ↩
-
Microsoft Learn, BitLocker frequently asked questions. 保護の一時停止と再開に関する補足について。 ↩
-
Microsoft, Announcing hardware-accelerated BitLocker; Microsoft Learn, Encryption and data protection. 対応ハードウェアにおける暗号化処理のオフロードと性能の違いについて。 ↩ ↩2
-
Microsoft Learn, CryptProtectData function. DPAPIによるデータ保護とユーザー・コンピューターへの結び付けについて。 ↩
-
Microsoft Learn, BitLocker Network Unlock. TPMとPINを利用する管理対象端末でのネットワークロック解除と前提条件について。 ↩
-
Microsoft Learn, Preprovision BitLocker in Windows PE. 事前プロビジョニングでクリアプロテクターを使用し、OS展開後に鍵の保護を構成する仕組みについて。 ↩
関連する記事
同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。
WindowsのTPMとは何か ── 図解でわかる「鍵を外に出さない金庫」と測定起動
TPMを図解で解説します。鍵をチップの外へ出さない仕組み、PCRと測定起動、BitLockerやWindows Helloでの使われ方、dTPM・fTPM・Plutonの違い、Get-Tpmでの確認方法、回復キーを求められたときの対処までを実務目線で整理します。
WSUS非推奨後のWindows Update管理 ── WUfB・Autopatch・Intuneをどう選ぶか
2024年9月にWSUSの非推奨が発表されました。すぐ止まるわけではありませんが、新機能開発は終了しています。WSUS継続・Windows Update for Business・Autopatch・Intuneの4つの選択肢を、ライセンスや閉域網の条件込みの判断表で整理します。
グループポリシーからIntuneへ ── 中小企業のデバイス管理移行ガイド
ADサーバーの更改を機にグループポリシーを続けるか、Entra ID+Intuneへ移るか。適用の仕組みの違い、ライセンス、Group Policy analyticsでの棚卸し、5段階の移行シナリオとつまずきどころを中小企業向けに整理します。
Windowsセキュリティ監査ポリシーとイベントログ調査の実務 ── 4625を読める情シスになる
「サインイン失敗のログを調べてほしい」に応えるための実務ガイドです。基本と詳細の監査ポリシーの関係、最低限有効化すべきサブカテゴリ、イベントID 4624/4625/4688の読み方、Securityログの容量設計、Get-WinEventでの抽出までを解説します。
Windows LAPS実務ガイド ── 全PC共通のローカル管理者パスワードをやめる
全PC共通のローカル管理者パスワードは、1台の侵害が全台に波及するPass-the-Hash攻撃の温床です。OS標準機能になったWindows LAPSによる自動ローテーションと、AD/Entra IDへの保存設定、運用の落とし穴を解説します。
関連トピック
このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。
Windows技術トピック
Windows 開発、不具合調査、既存資産活用の技術トピックをまとめた入口です。
このテーマがつながるサービス
この記事は次のサービスページにつながります。近い入口からご覧ください。
Windowsアプリ開発
業務アプリ、装置連携、通信ツールなどの Windows ソフト開発を支援します。
よくある質問
この記事のテーマについて、相談時によくある質問をまとめています。
- BitLockerの回復キーはどこにありますか?
- 個人のMicrosoftアカウント、職場・学校の管理先、印刷した紙、USBメモリや別の場所に保存したファイルを確認します。現在のサインイン方法だけでは保存先を断定できず、最初にPCを設定した人のアカウントにある場合もあります。回復画面の回復キーIDの先頭8文字を手がかりに、一致するキーを探してください。会社PCで利用者自身が表示できない場合は、IT管理者に照会します。
- 回復キーが見つからないときは、すぐ初期化するしかありませんか?
- 初期化する前に、組織の管理者、セットアップした人、保存済みの控えを確認してください。組織が別の回復手段を構成している場合もあります。有効な解除手段がすべて失われている場合、Microsoftサポートも回復キーを再作成できません。データのバックアップからの復旧と、ローカルファイルを失う初期化・再インストールを区別して判断します。
- 暗号化率が100%なら安全ですか?
- 暗号化率だけでは判断できません。保護の一時停止中や自動暗号化の有効化待ちでは、暗号化済みでもProtectionStatusがOffになることがあります。VolumeStatusとProtectionStatusを別々に確認し、回復キーが管理先から実際に取得できることも確かめます。Windows使用中のLockStatusがUnlockedであること自体は異常ではありません。
- Windows 11 HomeでもBitLockerは使えますか?
- 対応するPCでは、HomeでもBitLockerの技術を使う「デバイスの暗号化」を利用できます。一方、BitLockerドライブ暗号化の有効化や詳細な管理にはPro・Enterprise・Education系のエディションが必要です。Windows 11 24H2では自動暗号化の対象となるハードウェア条件が緩和されましたが、24H2の全PCが必ず自動で保護されるわけではありません。
- BIOS更新の前にBitLockerを無効化する必要がありますか?
- 通常はドライブ全体を復号する「無効化」ではなく、機種や更新手順に応じた「保護の一時停止」を検討します。先に回復キーを取得できることを確認し、PCメーカーの手順に従ってください。一時停止中は暗号化されたままでもオフラインでの保護が弱まるため、作業後に保護の再開とProtectionStatusがOnであることを確認します。すべてのWindows Updateで手動の一時停止が必要という意味ではありません。