Windows 11「KB5074109」で起動不能が発生した理由と復旧手順まとめ──“1月パッチ単体”ではなく「12月失敗の連鎖」が原因

2026年1月のWindows 11月例更新（KB5074109）を適用した一部PCで、ブラックスクリーンのまま起動できず停止コード「UNMOUNTABLE_BOOT_VOLUME（0xED）」に陥る報告が相次ぎました。ポイントは、KB5074109が“健康なPCを無差別に壊す”のではなく、2025年12月の更新失敗→ロールバックで残った「不適切な状態（improper state）」に、1月パッチが重なって表面化するという「連鎖型」のトラブルだとMicrosoftが説明した点です。BleepingComputer+1

Windows 11「KB5074109」で起動不能が発生した理由と復旧手順まとめ──“1月パッチ単体”ではなく「12月失敗の連鎖」が原因

何が起きているのか：症状は「0xED」とブラックスクリーン

代表的な症状は次のとおりです。

更新後の再起動でブラックスクリーンのまま進まない
停止コード UNMOUNTABLE_BOOT_VOLUME（0xED） が表示され、通常起動できない
いったん起きると、GUIからのアンインストールができずWinRE（回復環境）での作業が必要になるケースが多い

この問題は2026年1月13日に配信されたWindows 11向け累積更新 KB5074109（24H2/25H2）に関連して報じられています。Microsoft サポート

Microsoftの説明：原因は「1月パッチ」ではなく「12月失敗の上書き」

Microsoftの更新された案内によれば、影響を受けやすいのは次の条件に該当する端末です。BleepingComputer+1

2025年12月のセキュリティ更新のインストールに失敗
その後、**ロールバック（更新の取り消し）**が走り、端末が“起動はできるが内部的に壊れた基盤（不適切な状態）”のまま運用されていた
そこへ2026年1月の KB5074109 を適用したことで、ブート関連の整合性が崩れて起動不能に至る

つまり、**「12月の失敗で壊れた土台」＋「1月の更新」**という“二段構え”で発火するタイプです。これが「同じKB5074109でも、問題が出るPCと出ないPCが混在する」最大の理由です。BleepingComputer+1

影響範囲：物理PC中心、主に商用端末。VMは影響が小さい傾向

報道・整理情報では、影響はWindows 11 24H2 / 25H2の「物理デバイス」中心で、特に商用（業務）PCの比率が高いとされています。一方で仮想マシン（VM）では影響が確認されにくいという説明も出ています。BleepingComputer+1

「全員が即座に危険」というより、**“過去に12月更新でコケた端末を抱えている組織ほどリスクが高い”**という性格のインシデントです。

Microsoftの対応状況：再発防止は進むが、起動不能の自動修復は別問題

Microsoftは、すでに「不適切な状態」にある端末がこれ以上“起動不能”へ落ちないようにする部分的な対策を進めている一方、すでに起動できなくなったPCを自動的に直すものではない、また12月側の失敗を遡って完全修復するものでもないという趣旨が伝えられています。BleepingComputer+1

現時点の現実解は、「再発防止（配信制御）」と「個別復旧（WinRE等）」の二本立てになります。

まずやるべきこと（運用側）：リスク端末の見分けと配信停止

企業・組織での優先順位は次のとおりです。

更新履歴で2025年12月の品質更新が失敗→ロールバックした端末を洗い出す
- Windows Updateの履歴、イベントログ、管理ツール（Intune/WSUS等）の失敗記録から抽出
その端末群に対しては、いったん KB5074109の展開を止める／段階配信に切り替える
どうしても1月セキュリティを入れる必要がある場合は、テストリングで事前検証し、復旧手順（WinRE起動・回復メディア）を準備してから適用

「1月パッチを止め続ける」にはセキュリティ上のコストがあります。だからこそ、“12月に失敗した端末だけ”を正確に絞って対処するのが被害とリスクを最小化します。BleepingComputer+1

すでに起動しないPCの復旧：WinREで「最新の品質更新」をアンインストール

起動不能に陥った場合、基本方針は「OSが立ち上がる前に更新を外す」です。Windows Centralなどでも、WinREからのアンインストールが現実的な回避策として案内されています。Windows Central+1

手順（最も一般的）

WinRE（回復環境）を起動
- 自動修復が起動するまで強制再起動を数回繰り返す、または回復ドライブ/インストールメディアから起動
[トラブルシューティング] → [詳細オプション] → [更新プログラムのアンインストール]
**「最新の品質更新プログラムをアンインストール」**を選ぶ
再起動して起動確認
起動できたら、当面は更新の一時停止や段階配信に切り替え、再発を防ぐ Windows Central

うまくいかない場合の現実的な分岐

システムの復元（復元ポイントがあれば有効）
スタートアップ修復（効く場合もあるが万能ではない）
回復メディアでの修復インストール／最終的に再インストール

今回の特徴は、「12月の失敗が根にある」点です。1月更新を外して起動できても、土台が壊れている可能性が残るため、復旧後は12月以降の更新適用状態を整え直し、安定性を確認する運用が重要です。BleepingComputer+1

なぜ“連鎖”が怖いのか：パッチ管理で見落としやすい落とし穴

今回のような連鎖型トラブルは、次の理由で被害が広がりがちです。

12月更新の失敗端末が、ロールバック後に一見ふつうに動く
「起動できているからOK」と判断し、翌月のパッチを上書きしてしまう
結果として、翌月に突然「起動不能」という最悪の形で表面化する

対策はシンプルで、**“更新失敗の端末を放置しない”**ことです。失敗→ロールバックが起きた端末は、月をまたぐ前に原因（ストレージ、暗号化、ドライバ、企業向けポリシー等）を潰し、正常系に戻してから次のパッチへ進めるのが安全です。BleepingComputer+1

今後の見通し：全台停止ではなく「条件付きリスク」なので、絞り込みが鍵

現時点での整理としては、KB5074109そのものは24H2/25H2向けの通常の累積更新であり、問題は「12月失敗で崩れた状態」に重なると顕在化する、という構図です。Microsoft サポート+1

個人ユーザー：同様の症状が出たら、まずWinREで品質更新のアンインストール
企業・情シス：12月失敗端末の棚卸し→段階配信→復旧手順の標準化（回復メディア含む）

「起動不能」は最もコストが高い障害です。だからこそ今回の教訓は、月例パッチの是非よりも、失敗した更新を“なかったこと”にしない運用にあります。今ある端末群の更新履歴を一度点検し、連鎖の起点になり得る12月の失敗端末を潰しておくことが、最短で効く再発防止策になります。BleepingComputer+1