BitLocker回復キー紛失で復号できない？暗号化バックアップからデータを復旧する探し方と手順

BitLocker で暗号化したサーバーが故障し、手元には暗号化されたままのバックアップだけ。さらに回復キー（48桁）も見当たらない…という状況は、復旧手順を間違えると時間もコストも浪費します。本記事では「回復キーなしで復号できるのか」という結論と、見落としがちな保管先、バックアップからデータを救出する現実的な流れを整理します。

まず結論：BitLocker の回復キーなしで復号（解除）できる？

結論から言うと、BitLocker は回復キー（または解除に必要な認証情報）が無い状態で復号する方法は基本的にありません。SNS や検索結果で「裏技」「解除ツール」といった言葉を見かけても、BitLocker の設計は「鍵が無ければ読めない」ことを前提にしており、暗号そのものを現実的な時間で破るのは不可能に近いからです。

したがって、やるべきことは大きく二択です。

• 回復キー（または別の解除要素）を“探して復旧”する：これが唯一のデータ復旧ルート
• 回復キーが見つからない前提で再構築する：サーバー復旧はできても、暗号化ボリューム内のデータは失う

この記事では前者（鍵を探す）を最優先に、環境別の探索ポイントと、鍵が見つかった後に安全にデータを救出する手順までを具体的に解説します。

そもそも BitLocker は「ファイル」ではなく「ドライブ（ボリューム）」を暗号化する

まず前提として、BitLocker は多くの場合ドライブ全体（ボリューム）を暗号化します。ファイル単体を暗号化する EFS（暗号化ファイルシステム）とは性質が違い、BitLocker が有効なドライブは「正しい鍵でアンロックできるかどうか」がすべてです。

仕組み	暗号化の単位	解除に必要なもの	よくある誤解
BitLocker	ドライブ（ボリューム）全体	TPM / PIN / パスワード / USB スタートアップキー / 回復キーなど	「復号ソフトでファイルだけ取り出せるのでは？」
EFS	ファイル/フォルダー単位	ユーザー証明書（秘密鍵）	「BitLocker の回復キーがあれば EFS も戻る」

今回のように「暗号化済みファイル（バックアップ含む）を復号したい」という場合も、実態は暗号化されたボリュームをアンロックできるかが論点になります。逆に言えば、回復キーが見つかってボリュームをアンロックできれば、ファイルは通常どおりコピー可能です。

“回復キーが無い”ときに最初にやるべきこと：状況を切り分ける

鍵探しを始める前に、復旧難易度を左右するポイントを整理します。ここを曖昧にしたまま探し始めると、間違った場所を何時間も探してしまいがちです。

確認項目	なぜ重要か	具体例
暗号化の対象は OS ドライブか / データドライブか	解除方法（TPM 依存か、パスワード運用か）が変わる	C: が BitLocker、D: は自動ロック解除（Auto-unlock）など
端末は個人 PC / 組織管理端末（Entra ID/AD/Intune）か	回復キーの保管先が決定的に変わる	会社支給 PC は Entra ID や Intune にエスクローされていることが多い
バックアップは「ファイル単位」か「イメージ（ブロック）」か	バックアップ自体が暗号文かどうかが変わる	VHD/VHDX イメージを丸ごとコピーしていると暗号のまま残る
回復キー ID（キー識別子）が分かるか	AD/Entra/台帳から一致する鍵を特定しやすい	回復画面に表示される 8 桁×2 形式の ID など

特に回復キー ID（Recovery Key ID）は重要です。組織で鍵をエスクローしている場合でも、端末名・シリアル・回復キー ID のどれかが無いと、管理者側で「大量の鍵の中からどれが該当か」を特定できず復旧が遅れます。可能なら、回復画面に表示される ID を写真やメモで確保してください。

回復キー探索の全体像：成功確率を上げる順番

「とにかく手当たり次第に探す」より、確度が高い順に当たる方が早いです。一般的に成功率が高い順番は次のとおりです。

優先度	確認先	対象になりやすい環境	見つかる形
高	Microsoft アカウントの回復キー一覧	個人利用の Windows 10/11、個人の Surface など	Web に回復キー（48桁）とキー ID が表示
高	Microsoft Entra ID（旧 Azure AD）/ Intune	会社・学校の管理端末（クラウド参加）	デバイス情報に BitLocker キーが紐づく
高	Active Directory（AD DS）	ドメイン参加端末、Windows Server	コンピューターオブジェクト配下に回復情報
中	保存したファイル（txt/docx）、印刷、USB（.BEK）	手動で BitLocker を有効化したケース	「BitLocker 回復キー」ファイル/紙/USB
中	運用台帳・チケット・手順書・パスワード管理ツール	情シスが鍵を回収している組織	端末資産情報とセットで記録

ポイントは、「回復キーが無いなら別手段で解除」ではなく、「回復キーを含む解除要素を“どこに保管したか”を突き止める」ことです。BitLocker の設計上、鍵の所在さえ判明すれば復旧は一気に進みます。

保管先別：回復キーを探す具体的なチェックポイント

Microsoft アカウントに回復キーが保存されているか確認

個人利用の PC で BitLocker（デバイス暗号化を含む）が有効になった場合、回復キーが Microsoft アカウントに自動保存されていることがあります。まずは該当ユーザーが使っていた Microsoft アカウントでサインインし、回復キー一覧を確認します。

• 確認先の例：https://account.microsoft.com/devices/recoverykey
• 同じ人でも複数の Microsoft アカウントを持っていることがある（個人用/仕事用の混在）
• 表示される「キー ID」「デバイス名」「日時」を手元の情報と突合する

見つかった 48 桁の回復キー（数値パスワード）は、入力ミスが多いのでコピー＆ペーストや二重チェックを強く推奨します（紙から手入力する場合は桁区切りごとに確認）。

会社・学校の Microsoft Entra ID（旧 Azure AD）に保存されているか確認

組織端末（会社支給 PC、学校配布 PC）では、BitLocker の回復キーが Microsoft Entra ID にエスクローされていることがあります。ユーザー本人が見られる場合もありますが、基本は管理者（情シス）が管理ポータルから参照する運用が多いです。

• 端末が「Entra ID 参加」「ハイブリッド参加」になっていないか
• Intune（Microsoft Endpoint Manager）で BitLocker 管理をしていないか
• 端末名、シリアル、回復キー ID のどれで照会できるか

照会依頼の際は、次の情報を揃えると話が早いです。

• 端末名（例：PC-XXXX、SERVER-XXXX）
• 回復キー ID（回復画面や manage-bde の出力に出る）
• ドライブ文字（C: / D: など）と用途（OS/データ）
• 資産管理番号やシリアル（分かれば）

Active Directory（AD DS）に回復キーが保存されているか確認

ドメイン参加している Windows（クライアント/サーバー）では、グループポリシーで BitLocker 回復情報を AD DS に保存しているケースがあります。保存されていれば、管理者は「コンピューターオブジェクト」から回復パスワードを参照できます。

ただし、ここでよくある落とし穴が「そもそも保存ポリシーが必須化されていなかった」「保存に失敗していた」「端末がドメイン外に持ち出されて保存されていない」です。AD DS 保管を期待していたのに見つからない場合は、次の観点で確認します。

• BitLocker 有効化時点でドメインに到達できたか（社内 LAN/VPN）
• 該当 OU に「回復情報のバックアップを必須化」するポリシーが当たっていたか
• コンピューターアカウントが移動・削除されていないか

Intune / MBAM 相当 / 構成管理ツールの保管を確認

組織によっては、AD DS や Entra ID だけでなく、MDM/管理製品で回復キーを保管している場合があります。代表例としては Intune（クラウド）、過去の MBAM 運用、構成管理ツールの台帳連携などです。ここは環境差が大きいので、「BitLocker の回復キーはどこに集約しているか」を情シスに確認するのが最短です。

手動で保存したファイル・印刷・USB を探すときのコツ

個別に BitLocker を有効化した場合、回復キーを「ファイルとして保存」「印刷」「USB に保存」などで残していることがあります。よくある保存先を、実務的な観点でリスト化しておきます。

保存先の候補	探し方のヒント	見つかるもの
ドキュメント/デスクトップ/共有フォルダー	「BitLocker」「回復キー」「recovery key」「.txt」で検索	48 桁の回復キーが書かれたテキスト
OneDrive / SharePoint / Teams のファイル	クラウド上の検索も実施（ローカルだけで探さない）	保存したファイル、手順書に貼り付けたキー
印刷物（紙）	「機器更新時に紙で保管」→封筒・バインダーに埋もれやすい	「BitLocker 回復キー」印刷ページ
USB メモリ	ラベルの無い USB に .BEK が残っていることがある	スタートアップキー（.BEK）
パスワード管理ツール/運用台帳	端末名・資産番号で検索。チケットシステム添付も確認	回復キー、キー ID、運用メモ

なお、回復キーは機密情報です。探す過程でスクリーンショットや共有チャットに貼ってしまうと情報漏えいの原因になります。管理者に渡す場合も、組織の手順（暗号化メール、チケット添付、セキュア共有）に従ってください。

サーバーがクラッシュしている場合に“まだ残る可能性”がある解除ルート

「回復キーを紛失＝即詰み」と思われがちですが、状況によっては回復キー以外の解除要素が残っていてアンロックできることがあります。ポイントは、元の環境（TPM や構成）が残っているかです。

• TPM による自動解除：同一マシン（同一 TPM）で正常に起動できれば、回復キー入力なしで解除されることがある
• BitLocker のパスワード：データドライブや BitLocker To Go（USB）で「パスワード解除」を設定していた場合
• スタートアップキー（USB）：起動時に USB が必要な構成（.BEK）だった場合
• 自動ロック解除（Auto-unlock）：OS ドライブが解除できれば、同一 OS 上でデータドライブが自動解除されることがある

逆に、マザーボード交換や TPM 初期化、ブート構成の大幅な変更があると、TPM 解除が成立せず回復キーを要求されやすくなります。サーバー修理や移行を先に進める前に、元のマシン構成をなるべく保ったまま起動を試すことが、結果的にデータ救出の近道になる場合があります。

「暗号化されたバックアップ」だけが残っているときの落とし穴

同じ「バックアップ」でも、方式によって “中身が暗号文か平文か” が変わります。ここを見誤ると、「回復キーが無いから無理」と結論づける前に救えるケースを取りこぼします。

バックアップ方式	バックアップに残る内容	回復キーが必要になる可能性	見分け方のヒント
ファイル単位バックアップ（稼働中 OS から取得）	アンロック済みボリューム上のファイル（通常は平文）	低い（ただし EFS など別の暗号があると別問題）	バックアップソフトが「ファイル一覧」で復元できる
イメージ/ブロック単位バックアップ（VHD/VHDX、スナップショット等）	ドライブのセクタ（BitLocker の暗号文がそのまま）	高い（アンロックしないと中身にアクセスできない）	マウントすると「BitLocker で保護」と表示される
仮想マシンのディスクを丸ごとコピー	VHDX 内の BitLocker がそのまま残る	高い	別ホストに移しても OS 内で回復キーを要求
バックアップ製品で暗号化（製品側の暗号）	バックアップアーカイブ自体が暗号化	BitLocker とは別に「製品の復号鍵」が必要	復元ウィザードで暗号鍵/パスフレーズ入力を求められる

質問文のように「暗号化されたままのバックアップしかない」ケースは、上の表でいうイメージ/ブロック単位バックアップであることが多いです。この場合、回復キーが無い限りバックアップからファイルを取り出すことはできません。

一方で、もしバックアップが「ファイル単位」で取れているなら、BitLocker 回復キーが無くても復元できる可能性があります。バックアップ製品の設定（取得方式・復元方式）を再確認し、「本当に BitLocker の暗号文が残っているのか」を切り分けるのが重要です。

回復キーが見つかったら：復号より先に“安全な救出”を優先する

回復キーが見つかった瞬間に「すぐ復号（BitLocker をオフ）」を実行したくなりますが、サーバー障害の状況ではまずはデータ救出を優先した方が安全なことが多いです。理由は次のとおりです。

• 復号（暗号解除）はドライブ全体に書き込みが発生し、障害ディスクだと悪化することがある
• 復号には時間がかかり、途中で電断・エラーが出ると復旧作業が長期化しやすい
• 「アンロックしてコピーする」だけなら、影響を最小化しやすい

目的	おすすめ手順	向いている状況
とにかくデータを救出したい	アンロック → 別媒体へコピー（またはバックアップ取得）	ディスク障害が疑われる、時間優先
サーバーを元の状態で運用復帰したい	アンロック → 復旧後に計画的に復号/再暗号化	環境を維持したい、保守時間が取れる
新サーバーへ移行したい	アンロック → データ移行 → 新側で暗号化設計	ハード更新/更改、再設計が可能

コマンドで確認・解除する（Windows Server/クライアント共通）

GUI に入れない（サーバーが起動しない）場合でも、ドライブを別マシンに接続できればコマンドで状態確認やアンロックが可能です。代表的なコマンドをまとめます。

状態確認：どのドライブが BitLocker か、回復キー ID を把握する

manage-bde -status
manage-bde -protectors -get D:

manage-bde -protectors -get の出力には、保護の種類（Numerical Password/External Key など）と ID が表示されます。管理者に照会する場合も、この ID が強力な手がかりになります。

回復キー（48桁）でアンロックする

manage-bde -unlock D: -RecoveryPassword 111111-222222-333333-444444-555555-666666-777777-888888

スタートアップキー（.BEK）でアンロックする

manage-bde -unlock D: -RecoveryKey E:\BitLockerKey\XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.BEK

復号（BitLocker をオフ）する

manage-bde -off D:

前述のとおり、障害時は「まずアンロックしてコピー」→「必要に応じて復号」の順が安全です。復号を始める前に、別媒体へ重要データを退避できているかを確認してください。

回復キーが見つからないときにやりがちな“危険な手段”

検索すると「BitLocker 解除」「回復キー不要」といった情報が出ますが、次のような手段は現実的に効果がないか、状況を悪化させます。

• 総当たり（ブルートフォース）：BitLocker の暗号強度を前提にすると、現実的な時間で成功しません
• 不審な解除ツールの実行：マルウェア感染や情報漏えいのリスクが高い
• ディスク修復を乱発：暗号化ボリュームに対して無計画に修復をかけると復旧不能を招くことがある
• 回復キーを共有チャットに貼る：鍵そのものが漏れると暗号化の意味が無くなる

「鍵が無ければ読めない」設計のものを無理やり突破しようとするより、鍵の保管先を徹底的に洗い出す方が最短です。

どうしても見つからない場合：現実的な判断基準

回復キーが見つからず、TPM 解除やパスワード解除も成立しない場合、暗号化されたデータの復旧は極めて困難です。この段階で重要なのは、復旧作業を「続ける/切り上げる」を判断する基準を持つことです。

判断材料	続ける価値が高い例	切り上げを検討する例
鍵の所在	組織でエスクローしている可能性が高い（Entra/AD/Intune）	個人運用で、保存先の見当がまったく無い
元ハードの状態	同一 TPM で起動できる可能性がある（修理で復帰しそう）	マザーボード交換済み、TPM 初期化済み、構成が大きく変わった
バックアップの方式	ファイル単位バックアップが別系統で残っている可能性	暗号化イメージしか残っていないことが確定
業務影響	法務/会計/顧客データなど必須で、復旧コストをかけても回収したい	再構築で代替可能、期限が迫っている

「データが取り戻せない」と決めるのは辛い判断ですが、暗号化は“そういうもの”として設計されています。ここで無理に時間を溶かすより、再構築・再発防止にリソースを振る方が結果的に被害を抑えられることも少なくありません。

再発防止：BitLocker 回復キー紛失を二度と起こさない運用

BitLocker は正しく運用すれば強力な防御策ですが、「鍵管理」が弱いと今回のように業務継続に直撃します。次の対策は、個人でも組織でも効果が高い定番です。

回復キーのエスクロー（自動保管）を必須にする

• ドメイン参加端末：AD DS への回復情報保存を必須化するポリシーを適用
• クラウド管理端末：Entra ID / Intune で回復キーが確実に回収される設定にする
• 端末を暗号化する前に「保存されていることを確認してから」暗号化完了とする運用

「端末情報＋キー ID」をセットで台帳化する

鍵だけを単体で保管しても、後から「どの鍵がどの端末か」分からなくなると復旧が遅れます。最低限、次の項目をセットで管理します。

• 端末名
• シリアル/資産番号
• 対象ドライブ（OS/データ）
• 回復キー ID
• 保管先（Entra/AD/金庫/封筒など）

バックアップ設計を見直す（暗号化ボリューム前提で）

「暗号化イメージしか無い」状態は、鍵紛失時のリスクを最大化します。次の観点でバックアップを再設計すると、復旧性が上がります。

• 重要データはファイル単位バックアップも併用し、暗号鍵に依存しない復元ルートを持つ
• 復元テストを定期的に実施し、「鍵の取り出し」まで含めて手順化する
• バックアップ保管先（NAS/クラウド）自体の暗号化・アクセス制御もセットで検討する

対策	期待できる効果	実務上のポイント
回復キーの自動保管（エスクロー）	「鍵が無い＝詰み」を防ぐ	暗号化前に保存確認、GPO/MDM で強制
台帳化（端末情報＋キー ID）	照会・復旧が早くなる	端末名変更や再割当にも追従できる運用にする
バックアップの多重化（ファイル＋イメージ）	鍵紛失時も別ルートで復旧できる可能性	機密区分に応じて暗号化・権限管理を必ず実施
復元訓練（DR テスト）	手順の穴を事前に潰せる	年 1 回でも良いので「鍵取得→復元」まで通す

よくある質問（BitLocker 回復キー紛失）

回復キー（48桁）があるのに解除できません。なぜ？

もっとも多い原因は対象ドライブが違うことです。同一端末でも C: と D: で別の回復キーが割り当てられている場合があります。回復キー ID を突合し、対象ボリュームに一致するキーを使ってください。

回復キー ID だけ分かっていて、48桁が分かりません。意味はありますか？

あります。組織で Entra ID/AD DS/台帳に鍵を保管している場合、管理者は回復キー ID で該当キーを絞り込めます。端末名やシリアルが曖昧でも、ID があれば復旧が速くなります。

回復キーを入力する画面が出ない（どこで入力するの？）

OS ドライブの場合は起動時（WinRE）に表示されることが多く、データドライブの場合は Windows 起動後にドライブへアクセスしたタイミングで要求されます。バックアップイメージをマウントした場合も、マウント先ドライブとして認識されてキー入力を求められることがあります。

回復キーを見つけたら、その後も BitLocker は使うべき？

結論としては、運用を整えたうえで使う価値があります。BitLocker 自体は非常に有効な保護ですが、鍵管理が曖昧だと今回のような事故につながります。エスクローの必須化と復元訓練をセットで実施してください。

データ復旧業者に依頼すれば回復キーなしで復号できますか？

一般的には難しいです。ディスク障害の復旧（物理/論理）自体は可能でも、BitLocker の鍵が無ければ暗号文のままです。依頼するなら「鍵の保管先の特定支援」「元環境の修理で TPM 解除を成立させる」など、現実的な支援範囲を整理して相談するとよいでしょう。

回復キーが漏えいしたらどうなりますか？

回復キーは“最終手段のマスターキー”です。漏えいすると、そのドライブを入手した第三者がデータにアクセスできる可能性が高まります。回復キーはパスワード同様に厳重管理し、共有や保管のルールを明確にしましょう。

BitLocker で暗号化されたバックアップを復元できるかどうかは、結局のところ「鍵を見つけられるか」に尽きます。焦って危険な操作に走るより、保管先の候補を潰し、回復キー ID を手がかりに照会・突合していくのが最短ルートです。