SSD を交換したり、NVMe を一度取り外して起動しただけで、突然 BitLocker が発動し、回復キーを要求されるケースが増えています。これは故障でも設定ミスでもなく、Windows が採用している TPM（Trusted Platform Module）と信頼チェーンの仕組みが“正常に”動作した結果です。
問題は、この仕組みを知らないままストレージ構成を変更すると、 「データが消えた」「SSD が壊れた」「暗号化されたまま戻らない」 といった誤解につながりやすい点です。
BitLocker が自動発動する条件は明確に存在します。 そしてその条件は、一般的な SSD の交換作業や NVMe の抜き差しでも簡単に満たされてしまいます。
この記事では、 ストレージ構成の変更によって BitLocker が自動発動する“具体的な条件” を中心に、 TPM・信頼チェーン・暗号化対象の仕組みを整理しながら、 なぜこの現象が起きるのかを分かりやすく解説します。
私が身をもって体験した「ストレージ構成変更によりBitLocker が自動で発動」したトラブル
BitLocker が“勝手に発動した”ように見える現象は、実際に私自身の環境でも起きました。しかも、特別なことをしたわけではなく、ストレージ構成を一時的に変更しただけで、複数の SSD が「暗号化済み扱い」になり、最終的にはフォーマットせざるを得ない状況にまで発展しました。
ここでは、私が実際に経験したトラブルの流れを できるだけ簡潔に、時系列で整理 します。 この後の章で「なぜこうなるのか？」を技術的に解説するための前提として、まずは“何が起きたのか”を共有します。
macOS インストール失敗で SSD が認識不能に
macOS で認識されなくなった SSD の状態を確認するため、Windows PC に接続して検証を進めました。しかし、この SSD は Windows でも認識されず、原因を切り分けるために、PC 内の NVMe SSD と PCIe 拡張ボード上の SSD を一時的に取り外し、問題の SSD を単体で接続してチェックを続けました。
この作業を進めている途中、ふと気づくと Cドライブで BitLocker が自動的に発動 していました。もちろん、BitLocker を手動でオンにした覚えはありません。 この時点では、取り外した 2 台の SSD はまだ PC に戻していない状態でした。
Windowsでの検証中にBitLocker が自動発動していることに気づく
macOS で認識されなくなった SSD の状態を確認するため、Windows PC に接続して検証を進めました。しかし、この SSD は Windows でも認識されず、原因を切り分けるために PC 内の NVMe SSD と PCIe 拡張ボード上の SSD を一時的に取り外し、問題の SSD を単体で接続してチェックを続けました。
ディスク管理を開いて状態を確認したり、コマンドプロンプトで diskpart → list disk を実行してみたり、 SSD が Crucial 製だったため Crucial Storage Executive でも認識状況を確認しましたが、どの方法でも SSD はまったく検出されませんでした。ここで「物理的に完全に死んでいる可能性が高い」と判断しつつ、Windows の設定画面からセキュリティ関連の項目を確認したところ、BitLocker がいつの間にか ON になり、Cドライブの暗号化が進行していることに気づきました。
もちろん、BitLocker を手動でオンにした覚えはありません。 この時点でも、取り外した 2 台の SSD はまだ PC に戻していない状態でした。
SSD を元に戻すと、ドライブに警告マーク（！）が表示される
BitLocker の復号が完了したあと、取り外していた 2 台の SSD（NVMe SSD と PCIe 拡張ボード上の SSD）を元のスロットに戻して Windows を起動しました。
すると、エクスプローラー上で ドライブアイコンに黄色い警告マーク（！） が表示され、どちらの SSD も正常にアクセスできない状態になっていました。
- ドライブを開こうとしてもエラー
- ディスク管理でも状態が不正
- CHKDSK などの修復も不可
Windows 上では何を試しても回復できず、最終的には パーティション削除してフォーマット するしかありませんでした。
後から分かった「暗号化フラグだけ立った状態」
後から調べて分かったのは、これらの SSD は実際には暗号化されていなかったものの、 BitLocker の“暗号化フラグ”だけが立った状態 になっていたということです。
要するに、、、
- データは暗号化されていない
- しかし Windows は「暗号化済みドライブ」と誤認
- そのため通常の手段ではアクセスできない
という非常に厄介な状態でした。
別の PC に USB 接続していれば、データを救えた可能性が高かったということです。
この挙動は“トラブル”ではなくBitlockerの標準の仕様だった
最終的に分かったのは、この現象は BitLocker・TPM・NVMe の組み合わせが引き起こす典型的なパターンであり、 Windows のセキュリティ仕様が正常に働いた結果 だったということです。
- ストレージ構成が変わる
- TPM が「別のPCに移された」と判断
- BitLocker が鍵を渡さない
- 結果として“暗号化済み扱い”になる
という流れは、Microsoft の仕様通りの動作です。
BitLocker が自動発動する条件と暗号化の対象となるストレージ
BitLocker は、ユーザーが操作しなくても Windows の判断で自動的に発動する場合がある。 その挙動は TPM が保持している起動構成情報と密接に関係しており、ストレージ構成を変更しただけで暗号化が始まることがある。 さらに、OS が入っていないストレージでも、Windows が起動構成の一部とみなせば暗号化対象に含まれます。
以下に、自動発動の条件と暗号化対象となるストレージを整理する。
BitLocker が自動発動する主な条件
ユーザーが操作していないにもかかわらず、BitLocker が自動で有効化されるのは、TPM が保持している起動構成情報と現在の構成が一致しないと判断した場合。 以下はすべて TPM が「構成が変わった」と判定し、BitLocker を発動させる要因です。
- NVMe SSD の抜き差し
起動構成に含まれていた NVMe が外れる、または別の NVMe が追加されると不一致と判断されます。 - SSD のスロット位置の変更
同じ SSD でも、M.2 スロットを変更すると別デバイスとして扱われる場合があります。 - PCIe 拡張カードの有無
NVMe を搭載した拡張カードを抜く・挿すだけでも構成変化として扱われます。 - ブート構成の変更
ブート順序、ブートデバイス、UEFI/Legacy の切り替えなどです。 - BIOS/UEFI 設定の変更
Secure Boot、CSM、TPM 設定、ストレージモード（AHCI/RAID）など。 - 外部ストレージからの起動や署名検証の失敗
OS 署名の検証エラー、ブートローダーの変更、外部メディアからの起動試行などです。 - Windows Update によるブート関連コンポーネントの更新
ブートローダー、Secure Boot 関連、ストレージドライバ、TPM 関連の更新が入ると、 TPM が「構成が変わった」と判断し、BitLocker が発動するケースがある。Windowsが将来的にSCSIからNVMeネイティブ対応へ移行した際には、ストレージドライバーレベルの変更がTPMのPCR値に影響を与え、BitLockerが自動発動するリスクが高くなりまうす。
TPMとは？
TPM（Trusted Platform Module）は、PC の起動時に使用されるストレージ構成やブート設定の情報を内部に保持し、それらが前回と一致している場合にのみ BitLocker の暗号鍵を提供することで、構成が変わった際には鍵を渡さずロックを発動させるセキュリティチップ。（TPM の基礎：Microsoft Build 2026 ）
Bitlocker発動などに関する公式情報
BitLocker 回復シナリオ
Microsoft Learn より
Windows の起動時にデバイスが BitLocker 回復モードになる一般的なイベントの例を示します。
BitLocker とデバイス暗号化の違い
Microsoft Learn より
デバイス暗号化は、デバイスの暗号化対象デバイスで BitLocker を自動的にオンにします。
BitLocker が暗号化の対象とするストレージ
Windows は OS が入っているかどうかに関係なく、起動構成に関わる可能性があるストレージを広く暗号化対象として扱います。OS が入っていない SSD でも以下の条件に該当すると BitLocker の管理対象に含まれます。
- Windows が入っているドライブ（Cドライブ）
基本的な暗号化対象。 - ブートローダーや回復パーティションを含むドライブ
ブートローダー（Windows を起動するためのプログラム）や、 回復パーティション（メーカー製PCにあるリカバリー領域）が残っているストレージです。 - PC が起動時に“候補”として扱うストレージ
BIOS/UEFI が起動デバイスとして認識している NVMe / SATA / PCIe SSD。 - 過去に Windows を入れていた SSD
EFI パーティションや回復パーティションが残っていると、起動構成の一部として扱われます。 - TPM が“起動構成の一部”として記録しているストレージ
実際に OS が入っていなくても、TPM が保持している構成情報に含まれていれば対象です。
結果として、データ用 NVMe や拡張カード上の SSD まで暗号化対象に含まれるケースがあります。
BitLocker の対象外になるストレージ
Windows が起動構成として扱わないストレージは、BitLocker の自動発動や暗号化対象には含まれない。 以下は基本的に対象外です。
- USB メモリ・外付け HDD/SSD（USB 接続）
起動デバイスとして扱われないため、TPM の構成情報にも含まれない。 - NAS（ネットワークストレージ）
物理的に PC に接続されていないためBitLocker の管理対象外。 - SD カード（内蔵スロット含む）
起動構成に含まれない。 ※ただし、特殊な BIOS 設定で SD から起動できる機種は例外。 - 光学ドライブ（DVD/Blu-ray）
起動構成の一部として扱われない。 - 仮想ディスク（VHD/VHDX）
物理ストレージではないため、TPM の構成情報に含まれない。 - RAID カード配下のストレージ（BIOS/UEFI から個別に認識されない場合）
OS からは見えても、起動構成として扱われない構成は対象外。
ポイントは「TPM が起動構成として記録しているかどうか」。 TPM の構成情報（PCR）に含まれていないストレージは、 BitLocker の判断対象にならず、暗号化もロック発動も起きません。
なぜ「データ用 NVMe」まで巻き込まれるのか？
理由は、データ用 NVMe であっても、TPM が“起動構成の一部”として記録してしまうケースがあるため。 Windows や BIOS/UEFI が以下のように扱うと、データ用 SSD でも BitLocker の対象に含まれます。
- BIOS/UEFI が起動候補として認識している
→ 実際に OS が入っていなくても、「起動できるデバイス」として扱われる。 - 過去に Windows を入れていた痕跡（EFI/回復パーティション）が残っている
→ 削除したつもりでも、起動関連の領域が残っていると“起動構成の一部”と判断される。 - Windows がストレージを“起動に関係する可能性がある”と判断する
→ 特に NVMe は高速で、起動デバイスとして優先的に扱われやすい。 - TPM がその SSD を PCR（構成情報）に記録している
→ 一度記録されると、抜き差しや変更が「構成変化」として扱われる。
結果として、「ただのデータ用 NVMe」 の場合も、
- BIOS が起動候補として扱う
- TPM が構成に記録
- 抜き差しで構成不一致
- BitLocker が自動発動
という流れが発生します。
まとめ：経験からの見解
今回のトラブルを通じて痛感したのは、内部ストレージの構成変更は思った以上にリスクを伴う作業だということです。
SSDの抜き差しやスロット変更といった、一見軽微な作業でも、TPMは「構成が変わった」と判断しBitLockerを自動で発動させます。これはWindowsの仕様通りの動作であり、故障でも設定ミスでもありません。だからこそ、知らないままでいることが最大のリスクになります。
一つ重要な点として、データの待避先は外付けUSBドライブやNASを選ぶべきです。これらはTPMの起動構成に含まれないため、BitLockerの対象外になります。内部のNVMeやSATAドライブにバックアップしていても、今回のように巻き込まれる可能性があります。
ストレージ構成を変更する作業の前には、必ず外付けドライブまたはNASへのデータ待避と、BitLocker回復キーの確認を習慣にしてください。
