Windows 11 24H2でSysprep（/generalize）後にBitLocker有効化すると起動不能になる原因とBCD修正・回避策

Windows 11 24H2 で Sysprep（/generalize）した参照イメージを展開した端末で、BitLocker を有効化して再起動した直後に起動不能（回復画面／修復ループ／BSOD）に陥るケースが報告されています。原因になりやすい BCD（ブート構成データ）の崩れを素早く見分け、現場で確実に止血するための手順をまとめます。

起きている現象（Windows 11 24H2 × Sysprep × BitLocker）

典型的には、次のような参照イメージ作成・展開フローで再現します。

• 新規インストール → 監査モード（Ctrl+Shift+F3）
• アプリ導入・各種設定（参照イメージ化）
• sysprep /oobe /generalize /shutdown
• キャプチャ → 展開（デプロイ）
• 展開先で BitLocker を有効化 → 再起動
• 再起動後に 起動不能（回復環境に入る／自動修復／BSOD）

一方で、Windows 11 23H2 では同じ流れでも問題が出ない、または /generalize を外すと起動はするものの SID が一般化されず運用上つらい、という形で差が見えます。派生として、Autopilot の事前プロビジョニング（Pre-provisioning）後にリシール→再起動で同種の症状が出るという話もあります。

観点	症状の出方	運用インパクト
発生タイミング	BitLocker 有効化後の「最初の再起動」で破綻しやすい	MDM/Intune の暗号化ポリシー適用が早いと初期セットアップ段階で詰まる
Windows 11 23H2	同手順でも問題が出ない例が多い	24H2 への移行・検証で初めて顕在化しやすい
/generalize を外す	起動自体は通る場合がある	SID 一般化なしは参照イメージ運用として致命的になりがち

なぜ「BitLocker 有効化」がトリガーになりやすいのか

ポイントは、BitLocker が有効になると、次回以降の起動は 暗号化された OS ボリュームを前提としたブート手順になります。ブートローダーが OS を見つけるために参照する情報（BCD 内のデバイス指定）が曖昧だったり不正だったりすると、暗号化後の起動フェーズで一気に破綻します。

平常時は「何となく辿れてしまう」設定でも、BitLocker が入ると条件がシビアになります。結果として、Sysprep 一般化後に BCD の指定が崩れている個体が、BitLocker を入れた瞬間に表面化して起動不能に陥ります。

原因として挙げられるもの：Sysprep 一般化後に BCD の device/osdevice が不正化

原因として広く挙がるのが、Sysprep（/generalize）後に BCD（Boot Configuration Data）の一部項目が「locate 指定」になってしまうことです。具体的には Windows Boot Loader の次の 2 つが重要です。

• device
• osdevice

本来は partition=C: のように パーティションを明示しているのが望ましいのに、問題が起きる環境では locate=\WINDOWS\... のような locate 指定に変わってしまい、BitLocker 有効化後の再起動で破綻します。

項目	望ましい例	問題が出やすい例	影響
device	partition=C:	locate=\WINDOWS\system32\winload.efi 等	ブートローダーの所在解決が不安定になりやすい
osdevice	partition=C:	locate=\WINDOWS 等	OS ボリューム解決に失敗すると回復/修復に落ちる

まずは現状確認（bcdedit /enum）

対象端末で起動できる状態なら、管理者権限のコマンドプロンプトで次を実行します。

bcdedit /enum

表示の中から Windows Boot Loader セクションを探し、device / osdevice が partition=C: のようにパーティション指定になっているか確認します。ここが locate= になっていたら、BitLocker 有効化後に起動不能になる条件が揃っている可能性が高いです。

注意：環境によって OS ドライブが C: でないこともあります。その場合は「実際に Windows が入っているドライブ文字」に読み替えてください（後述のチェックリスト参照）。

回避策A（最優先）：BCD を正しい partition 指定に戻す

最もシンプルで即効性が高いのが、Windows Boot Loader の device/osdevice を partition 指定に戻す方法です。一般的に必要だった修正は次の 2 行です（OS が C: のケース）。

bcdedit -set {current} osdevice partition=C:
bcdedit -set {current} device partition=C:

確認ポイント：修正後に bcdedit /enum を再度実行し、Windows Boot Loader の device / osdevice が partition=C: になっていることを確認します。

{current} でうまくいかない場合の考え方

通常、起動中の OS 上で実行するなら {current} で問題ないことが多いです。ただし、複数エントリがある端末や特殊なブート構成の場合、実際の既定エントリが {default} になっていることがあります。

• 起動中の OS で実行している → まずは {current} を優先
• 「意図したエントリに効いていない」気配がある → bcdedit /enum で identifier を確認し、{default} や GUID を対象にする

ただし、現場での止血としては「まず {current} の 2 行を入れる」だけで解消するケースが多い、という整理がしやすいです。

自動化する方法：SetupComplete.cmd で確実に仕込む

参照イメージ展開後、「人手で修正する前に BitLocker ポリシーが当たって再起動→死亡」を防ぐには、セットアップ完了時に自動実行される SetupComplete.cmd が手堅いです。

配置場所：

• %WINDIR%\Setup\Scripts\SetupComplete.cmd

例（ログも残す）：

@echo off
setlocal

set LOG=%WINDIR%\Temp\BCD-Fix.log
echo [%DATE% %TIME%] Start BCD fix >> "%LOG%"

bcdedit -set {current} osdevice partition=C: >> "%LOG%" 2>&1
bcdedit -set {current} device   partition=C: >> "%LOG%" 2>&1

echo ---- After fix (bcdedit /enum) ---- >> "%LOG%"
bcdedit /enum >> "%LOG%" 2>&1

echo [%DATE% %TIME%] End BCD fix >> "%LOG%"
exit /b 0

運用メモ：SetupComplete.cmd はセットアップ最終段階で SYSTEM 権限で動くため、権限不足でコケにくく、デプロイ手順に組み込みやすいのが利点です。BitLocker の自動有効化が早い環境ほど、このタイミングで「先に BCD を正す」価値が上がります。

自動化する方法：unattend.xml の specialize で RunSynchronous 実行

別ルートとして、unattend.xml の specialize パスで RunSynchronous を使って 2 コマンドを順番に流す方法があります。例として、Order 1/2 に分けて実行します。

<settings pass="specialize">
  <component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">
    <RunSynchronous>
      <RunSynchronousCommand wcm:action="add">
        <Order>1</Order>
        <Description>Fix BCD osdevice</Description>
        <Path>cmd /c bcdedit -set {current} osdevice partition=C:</Path>
      </RunSynchronousCommand>
      <RunSynchronousCommand wcm:action="add">
        <Order>2</Order>
        <Description>Fix BCD device</Description>
        <Path>cmd /c bcdedit -set {current} device partition=C:</Path>
      </RunSynchronousCommand>
    </RunSynchronous>
  </component>
</settings>

注意：unattend.xml の構成や pass の実行タイミングは環境（WDS/MDT/MECM/独自デプロイ）で差が出ます。確実性を優先するなら SetupComplete.cmd のほうがトラブルシュートは楽です。

「memdiag の device も直すべき？」

環境や検証の深さによっては memdiag など他エントリの device を補正する例も見かけますが、まずは Windows Boot Loader（= {current}）の device/osdevice を正すことで改善するケースが多く、影響範囲も最小です。症状が残るときに追加検討、という順番が運用的に安全です。

回避策B：Sysprep 前に BitLocker 関連サービスを止めて無効化する（補助策）

BCD 修正が効かないケースや、別ビルドで BSOD 例が絡むケースでは、補助策として Sysprep 前に BitLocker 関連サービス（BDESVC）を止め、無効化してから一般化する回避が挙げられます。

Sysprep 前（参照イメージ側）で実行：

net stop bdesvc
sc config BDESVC start=disabled

展開後、起動フェーズで「元の起動種別」に戻してから BitLocker を有効化します。ここで重要なのは、環境標準が 手動（demand）なのか 自動（auto）なのかで戻し方が変わる点です。

事前に標準値を控える（参照イメージ作成時に確認）：

sc qc BDESVC

戻し先の例	コマンド	補足
手動（よくある）	sc config BDESVC start= demand	start= の後に半角スペースが必要
自動（環境次第）	sc config BDESVC start= auto	運用標準に合わせる

位置づけ：回避策Bは「BCD 修正が通らない／再現条件が複合的」な場面で検討する補助輪です。まずは回避策A（BCD の device/osdevice を partition 指定に戻す）を主戦術に置くほうが、手戻りが少なくなります。

すでに起動不能になった端末の復旧（応急手順）

すでに BitLocker 有効化後に起動不能になっている端末は、まず「業務復旧（起動させる）」を優先し、その後に再発防止（BCD 修正）を入れる流れが現実的です。

前提：BitLocker の回復キーが必要になる可能性が高いです。MDM/AD/Azure AD/Entra など、運用に合わせた回復キーの取り出し手段を事前に確保してください。

WinRE でコマンドが打てる場合の定番手順

• 回復環境（WinRE）で「コマンド プロンプト」を開く
• OS ボリュームのドライブ文字を特定する（WinRE では C: とは限りません）
• BitLocker を解除し、暗号化をオフにして起動可能に戻す

例（OS が C: に見えている想定）：

manage-bde -status
manage-bde -off C:

注意：manage-bde -off は「復号を開始する」操作です。容量や I/O によって完了まで時間がかかります。報告としては、これで起動できるようになる例がありますが、根本原因（BCD の不整合）を直さないまま BitLocker を再度有効化すると再発しやすい点が重要です。

復旧できたら必ずやること（再発防止）

OS が起動できる状態に戻ったら、BitLocker を再投入する前に 回避策A（BCD 修正）を先に適用してください。

bcdedit -set {current} osdevice partition=C:
bcdedit -set {current} device partition=C:
bcdedit /enum

そして device / osdevice が partition=C: になっていることを確認してから、BitLocker を有効化（またはポリシーを再適用）します。

WinRE での「やりがちミス」

ミス	起きること	回避の考え方
WinRE 上で {current} を直してしまう	修正対象が WinRE 側になり、OS の BCD に効かない	起動 OS 上で {current} を直すのが基本。WinRE なら {default} や GUID を明確に
OS ドライブ文字を決め打ちする	別ドライブを操作してしまう	WinRE ではドライブ文字が変わる前提で dir 等で確認する
復旧後すぐ BitLocker を再有効化	再発して再度起動不能	先に BCD（device/osdevice）を partition 指定へ補正

恒久策：参照イメージ側を更新してから Sysprep（/generalize）する

短期の止血は回避策Aで十分なことが多い一方、参照イメージ運用では「毎回 BCD を直す」のは負担になります。そこで恒久策として、参照イメージに後続の更新プログラムを適用してから Sysprep（一般化）するアプローチが有効です。

報告例として、次のような整理がしやすいです。

• 参照イメージに更新を入れてから Sysprep すると、BCD が partition=C: のまま維持され、BitLocker 有効化後も再起動できた
• 一方で、Sysprep 済みで壊れた BCDを後から更新しても直らないことがある
• したがって、既に展開済み端末は「回避策Aで補正」、今後のゴールデンイメージは「更新適用→Sysprep」で作り直すのが安全

更新適用→Sysprep の運用で意識したいポイント：

• 更新適用後は必ず再起動し、保留中の処理が残っていない状態にする
• 参照イメージを「更新済み状態」で固定し、同じベースから毎回 Sysprep する
• デプロイの工程に「BCD の自動チェック（必要なら修正）」を組み込んで、再発時も即検知できるようにする

状況	推奨アクション	狙い
すでに端末を展開済み	回避策A（BCD 修正）を配布／組み込み	再起動での破綻を止める
これから参照イメージを作る	更新適用→Sysprep（一般化）で作り直す	根本の発生率を下げる
一部環境で A が効かない	回避策B（BDESVC 無効化）を併用検討	複合要因の回避

デプロイ工程に組み込みたい「事前チェック」と「安全装置」

この問題は、発生すると復旧に時間がかかり、暗号化ポリシーが絡むと影響範囲が広がります。再発防止のために、次のような「チェック」と「自動修正」を工程に入れておくと安定します。

BitLocker を有効化する前に BCD を点検する

• bcdedit /enum で Windows Boot Loader の device / osdevice を確認
• locate= になっていたら、BitLocker を入れる前に partition= へ戻す

MDM の暗号化ポリシーが早い環境は「先に直す」

Intune/Autopilot などで、初回起動直後に BitLocker が自動的に有効化される設計だと、人が確認する前に再起動が走ってしまいがちです。対策としては次のどちらか（または両方）が効きます。

• SetupComplete.cmd などで 初期セットアップの最後に自動補正を入れる
• 「暗号化ポリシー適用のタイミング」を見直し、初期安定化（ドライバ/更新/BCD）後に暗号化へ寄せる

ドライブ文字が C: 前提でよいかを確認する

ほとんどのクライアント端末は OS が C: ですが、特殊なパーティション設計や一部の工場出荷カスタム、検証用の複数 OS などでは例外があります。次のような確認を入れると事故が減ります。

• OS が入っているドライブで dir C:\Windows が通るか
• OS が別ドライブなら、BCD 修正もそのドライブ文字へ合わせる（例：partition=D:）

よくある質問（運用目線）

/generalize を外せば直るなら、それで運用できない？

起動の安定だけ見れば回避になることがありますが、参照イメージ運用で /generalize を外すと SID の一般化が行われないため、後工程（管理・認証・資産管理・クローン展開の整合性）で問題が出やすくなります。根本対策は「一般化を維持したまま、BCD を正す」方向が安全です。

BitLocker を有効化するタイミングを遅らせるのは有効？

有効です。少なくとも「BCD が正しい（partition 指定）ことが確認できるまで」遅らせる価値があります。ただし、セキュリティ要件上すぐ暗号化したい環境も多いため、現実的には デプロイ工程で自動修正（SetupComplete など）を入れて、遅らせずに安全に進める設計が相性良いです。

修正コマンドは 2 行だけで本当にいい？

多くのケースでは、Windows Boot Loader の device / osdevice の 2 行補正で収束しやすいです。追加のエントリ補正（memdiag など）は、症状が残る場合に段階的に検討するほうが、意図しない副作用を避けられます。

「起動不能になる前」に検知する方法はある？

あります。デプロイ直後（または BitLocker 有効化前）に bcdedit /enum を実行し、device/osdevice が locate になっていないかを見るのが最短です。デプロイツール側で簡単な検査を入れ、検出したら自動で 2 行補正する運用にすると事故が激減します。

まとめ（実務で迷わないための整理）

• Windows 11 24H2 の参照イメージ（Sysprep /generalize）展開後、BitLocker 有効化→再起動で起動不能になる場合は BCD の device/osdevice を疑う
• 最優先の回避策は、{current} に対して device と osdevice を partition=C:（環境に合わせて変更）へ戻すこと
• 自動化は SetupComplete.cmd が扱いやすく、MDM で暗号化が早い環境ほど効果が大きい
• すでに起動不能なら、まず復旧（BitLocker オフ等）→起動後に BCD 修正→再暗号化の順が再発しにくい
• 恒久策として、参照イメージを更新適用後に Sysprepし、発生率そのものを下げる運用が安全