Windows 11 24H2 KB5062553の不具合対策：0x800f0845修復とSSU/LCU自動配信の注意点（OneDrive・Copilot復活も防ぐ）

Windows 11 24H2 に自動配信された「KB5062553（SSU＋LCU）」は、適用に失敗してロールバックしても“設定やユーザーデータだけ一部崩れる”ことがあり、慎重に運用したい更新です。本記事では、KBの読み解き方から、0x800f0845の実務的な直し方、OneDrive/Copilotの“復活”対策、Intuneと個人アカウント混在時の注意点までまとめます。

Windows 11 24H2（KB5062553）とは：まず「SSU＋LCU一体型」を理解する

KB5062553は、Windows 11 バージョン24H2向けの累積更新プログラム（LCU）で、公開日は 2025年7月8日、適用後のOSビルドは 26100.4652 です。

重要なのは、近年のWindows更新は「最新のサービススタック更新（SSU）を、最新の累積更新（LCU）に同梱する」方式が標準化されている点です。つまり“SSUだけ入れたい”という運用はやりづらく、原則として更新はセットで進みます。

用語	役割	失敗したときに起きがちなこと	実務上のポイント
SSU（Servicing Stack Update）	Windows Updateを“インストールする側”の部品を更新	更新処理自体が不安定になり、インストール失敗やロールバックが増える	SSUは土台。壊れているとLCU以前に詰まる
LCU（Latest Cumulative Update）	月例のセキュリティ修正・不具合修正・一部機能の改善がまとまった更新	ドライバ/セキュリティ機能/既定アプリ/ポリシーに影響が出ることがある	止めるより“遅らせる・段階適用・復旧設計”が現実的
ロールバック	更新失敗時に元の状態へ戻す仕組み	OS自体は戻っても、プロファイルやアプリ状態が部分的に崩れることがある	ロールバックは“完全復元”ではない前提でバックアップを組む

公式KBから読み取れる「見えにくい変更点」：改善点・AIコンポーネント・既知の不具合

KB5062553の公式情報は“セキュリティ更新”が中心で、派手な新機能は多く書かれません。ただし、次のような実務に効く情報は含まれています。

改善点は「前月プレビュー（KB5060829）の内容が取り込まれる」パターン

この更新には、2025年6月26日の非セキュリティプレビュー（KB5060829）で提供された改善点も含まれる、と明記されています。具体例として、特定ゲームのALT+Tab後にカーソル位置と描画がズレる問題や、通知音が鳴らない問題の修正が挙げられています。

“非公開っぽく見える”ポイント：AIコンポーネントの更新が同梱される

KB5062553はAI関連のコンポーネント（Image Search / Content Extraction / Semantic Analysis）も更新対象として列挙しています。一方で、これらのAIコンポーネントはCopilot+ PC向けで、該当しないWindows PC/Serverには適用されない旨も注意書きされています。

既知の不具合：関係ないと思っても“該当条件”だけ把握する

既知の問題として、Azureの一部Gen2 VM（Trusted Launch無効＋VBSをレジストリで強制）で起動できないケース、繁体字中国語のMicrosoft Changjie IMEで入力不具合が出るケースなどが掲載されています。どちらも後続KBで解消された旨が記載されています。

見落としやすいが重要：Secure Boot証明書の期限（2026年6月以降）

KB5062553には、Secure Bootで使われる証明書が 2026年6月以降に期限を迎え、未更新だとセキュアブートに影響し得る、という注意喚起も含まれています。個人PCでも企業PCでも“先に準備しておくべき”類の情報なので、更新を避けがちな環境ほど要チェックです。

分類	KB5062553で読み取れる内容	影響が出る可能性が高い人	先にやること
品質改善	プレビューKBの改善点が取り込まれる	プレビューを入れていたPC、ゲーム/通知周りの不具合が出ていたPC	更新前後で症状が再現するかテスト
AIコンポーネント	AI関連部品の更新が同梱（ただしCopilot+ PC向け）	Copilot+ PC、AI機能を厳密に統制したい組織	AI/プライバシー系のポリシーを再確認
既知の問題	Azure VMや特定IMEなど条件付きで不具合	該当条件の環境	該当するなら後続KBの適用計画を立てる
将来リスク	Secure Boot証明書期限に関する注意喚起	Secure Boot必須の端末、BitLocker/企業準拠端末	CA更新ガイダンスを確認し計画対応

「公式KBに全部書いてない」理由と、実務での確認方法

月例のLCUは、CVEなどの脆弱性修正が多数含まれても“具体的な修正内容は別サイト（MSRC）へ誘導”されることが多く、KB本文が薄く見えがちです。KB5062553でも、詳細はSecurity Update Guideや月例のセキュリティ更新情報を見るよう案内されています。

また、Windows 11は“段階的ロールアウト”や“継続的な改善（Continuous innovation）”が前提で、同じKBでも端末の条件やポリシーで体験が変わります。だからこそ、「隠し機能」を追うより、更新の影響範囲を自分の環境で可視化する方が再現性の高い対策になります。

更新の影響を可視化するチェック（簡易）

• 更新前後で winver（ビルド番号） を記録する
• インストール済み更新プログラム（設定 → Windows Update → 更新の履歴）をスクリーンショット
• Edge/Outlook/OneDrive/VPNなど、崩れると困るアプリの設定画面を最小限でも撮っておく

更新の影響を可視化するチェック（中級：パッケージ差分）

“LCUを入れると何が増えるのか”を疑似的に把握したい場合は、更新前後でパッケージ一覧を比較します（完全な差分解析ではありませんが、判断材料として強いです）。

DISM /online /get-packages /format:table > "%USERPROFILE%\Desktop\packages_before.txt"

更新後に同じコマンドを実行し、ファイルを比較します。LCUが一体型の場合でも、内部的には複数パッケージとして見えることがあります。

LCUが怖い人ほど必要：更新運用を“止める”から“設計する”へ

毎回10〜15時間の環境復旧が発生する状況では、更新適用そのものより「復旧が手作業すぎる」ことが最大のコストです。Windows Updateは止め続けるとセキュリティ負債になるため、現実的には“遅らせて・試して・戻せる”構造を作るのが近道です。

運用モデル	向く環境	狙い	具体策
遅延適用（様子見）	個人PC/小規模	初期不具合を踏まない	更新の一時停止、適用前に既知の問題を確認
段階適用（リング）	複数台運用、仕事用PCがある	“本番機”を守る	検証機→準本番→本番の順で適用、問題が出たら手順を修正
復旧前提（イメージバックアップ）	カスタマイズが多い/復旧に時間がかかる	復旧時間を短縮	更新前にシステムイメージ、更新後に差分確認。失敗時は戻す
管理配下（WUfB/WSUS/Intune）	組織管理端末	配布タイミングとポリシー統制	品質更新の延期/期限、ポリシーの再適用、例外端末の把握

なお、KB5062553は2025年7月の更新であり、現在はより新しいLCUに置き換わっていることが一般的です。更新履歴ページでは、24H2向けにその後も複数の更新が提供されていることが確認できます。つまり「KB5062553が入らない」状態でも、最新の累積更新に上げることで回避できる場合があります。

更新失敗「0x800f0845」：安全側に倒した実務手順

0x800f0845は、Windows Updateの処理系やコンポーネントストアの破損、前提条件の不整合など、いくつかのパターンで出ます。ここでは“やって損しにくい順”に並べます。

事前確認：まず切り分けの土台を揃える

• 再起動保留がないか（更新の履歴に「再起動が必要」表示が残っていないか）
• 空き容量（最低でも十数GB以上の余裕）
• VPNやプロキシをいったん外し、ネットワークを単純化（更新時だけでも）
• サードパーティ製セキュリティ製品を使っている場合、一時停止や競合確認

Windows Updateトラブルシューティングを走らせる

Windows 11の設定から「Windows Update」のトラブルシューティングを実行し、修復可能な項目を先に潰します（手動であちこち触る前にやると、戻しやすいです）。

DISM と SFC：コンポーネントストアとシステムファイルを直す

更新がロールバックする端末ほど、まずここが効くことが多いです。管理者のコマンドプロンプト（またはPowerShell）で実行します。

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

DISMが完了してからSFCを実行する流れにすると整合しやすいです。

Windows Updateキャッシュをリセットする

壊れたダウンロードや、更新コンポーネントの詰まりが原因なら、キャッシュのリセットで直ることがあります。代表例は SoftwareDistribution と catroot2 の作り直しです。

net stop wuauserv
net stop bits
net stop cryptSvc

ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old

net start cryptSvc
net start bits
net start wuauserv

それでもダメなら：カタログから手動適用（ただし“順序”に注意）

KB5062553は「1つ以上のMSUがあり、特定の順序で入れる必要がある」ケースがあると明記されています。複数MSUを同一フォルダに置いてDISMでまとめて入れる方法や、順序通りに個別インストールする方法が案内されています。

この“順序問題”に引っかかると、Windows Update経由では失敗し続けるのに、手動適用だと通ることがあります。逆に、順序を間違えると状況が悪化し得るので、公式手順に沿ってください。

最終手段：インプレース修復（上書き修復）で更新基盤ごと整える

何度もLCUが失敗する端末は、更新基盤の破損が深いケースがあります。アプリとファイルを保持したままWindowsを上書きする“修復インストール”で、Windows Update周りが一気に整うことがあります（実施前に必ずバックアップを取ってください）。

手順	狙い	メリット	注意点
トラブルシューティング	軽微な不整合の自動修復	安全・早い	根本原因が深いと効かない
DISM/SFC	更新の土台（コンポーネント/システム）を修復	失敗ループを断ち切りやすい	完走まで時間がかかることがある
WUキャッシュリセット	壊れたDLやサービス状態を整理	“毎回同じところで失敗”に効きやすい	更新履歴の表示が変わる場合がある
手動適用（MSU/DISM）	前提パッケージ順序の問題を回避	WUより成功するケースがある	順序を誤ると失敗が固定化する可能性
インプレース修復	更新基盤そのものを作り直す	長期的に安定しやすい	事前バックアップ必須。業務端末は手順管理

ロールバック後に「Edgeの個人プロファイルが消えた」「Outlookのフラグが消えた」への備えと復旧

更新のロールバックは“OSを戻す”ことには強い一方で、アプリのプロファイルやキャッシュ領域が中途半端に再生成されることがあります。今回のように、Edgeプロファイルが消失（ただし保存済みパスワードは残存）や、Outlookのフラグ付きメールが消える、といった“部分破損”は、更新失敗環境では珍しくありません。

Microsoft Edge：プロファイル消失を最小化する考え方

• 同期（Sync）を有効にし、ブックマーク/拡張/設定をクラウド側にも逃がす（個人ポリシー上問題ない範囲で）
• 更新前に、Edgeのユーザーデータフォルダを丸ごとバックアップ（容量は増えますが最も確実）
• “仕事用”と“個人用”はEdgeプロファイルを分け、影響を局所化する

Outlook：フラグ消失を最小化する考え方

• Exchange/Microsoft 365メールボックスの場合、フラグはサーバー側情報のことも多いので、Web版Outlook（OWA）でも消えているか確認（消えていなければクライアント側の表示/キャッシュ問題の可能性）
• IMAPやローカルPST中心の運用だと、フラグが端末依存になりやすいので、PST/OSTの扱いとバックアップ方針を先に決める
• 更新前に、重要なフォルダをエクスポート（運用が許す範囲で）

対象	起きやすい症状	事前対策	復旧の当たりどころ
Edge	プロファイル消失、既定設定が戻る	同期＋プロファイル分離＋フォルダバックアップ	同期復元、ユーザーデータフォルダの戻し、再サインイン
Outlook	フラグ/表示/キャッシュの崩れ	OWA確認手順、PST/OST方針、必要ならエクスポート	OWAで残っていればクライアント再構築、表示設定確認

OneDrive（OneCloud）が“勝手に復活”するのを抑える：やるならポリシーで固定する

Windows更新でOneDriveが復活するのは、OneDriveがOS体験の一部として再配布・再登録されるタイミングがあるためです。「アンインストールしたのに戻る」「非表示にしたのにエクスプローラーに出る」などは、手動操作だけだと再発しやすいです。

定番のGPO：OneDriveをファイル保存に使わせない

Pro/Enterpriseなどでグループポリシーが使えるなら、最も安定するのは次の設定です。

• コンピューターの構成 → 管理用テンプレート → Windows コンポーネント → OneDrive
• 「OneDrive をファイル ストレージとして使用することを禁止する」を有効

この方針はMicrosoft系コミュニティでも定番として案内されています。

レジストリ（ポリシーキー）での固定：DisableFileSyncNGSC

OneDriveが起動できない/させたくない制御では、ポリシーキーとして DisableFileSyncNGSC が参照されます。Microsoftの案内でも、該当キーの確認が示されています。

目的	方法	強さ	注意点
OneDriveを実質無効化	GPO「使用を禁止」	強い（更新後も戻りにくい）	組織ポリシーや運用と整合させる
レジストリで固定	DisableFileSyncNGSC	強い（ただし管理配下だと上書きされることも）	Intune/ADの設定が勝つと“戻る”
見た目だけ消す	タスクバー/スタートの非表示	弱い	更新で復活しやすい

Copilotが勝手に有効化・プッシュされる：24H2は“Copilotの形”が変わる前提で対策する

Copilotはここ1〜2年で実装形態が変化しており、「ボタンを消したのに起動する」「ポリシーを入れたのに別のCopilotが出る」が起きやすい領域です。特に組織環境では、コンシューマー向けCopilotアプリと、Microsoft 365 Copilot（商用）で体験が分かれます。

重要ポイント：レガシーの“Turn off Windows Copilot”は将来的に廃止方向

Microsoft Learnの案内では、Copilotアプリのインストール防止にはAppLockerの利用が推奨され、従来の「Turn off Windows Copilot」およびMDM同等ポリシー（TurnOffWindowsCopilot）は近い将来の廃止対象になり得る、と明記されています。

また、WindowsAI Policy CSPのページでも TurnOffWindowsCopilot は「deprecated（非推奨）」で、将来削除される可能性があるとされています。

現実的な対策の組み合わせ（管理端末を想定）

• TurnOffWindowsCopilot（レガシー）：従来のCopilot体験を抑止（ただし将来性は弱い）
• AppLocker：Copilot（コンシューマーアプリ）のインストール防止・起動ブロック（推奨）
• PowerShellでCopilotアプリ削除：既に入ってしまった端末の後追い対応

Copilotアプリ削除の例（公式手順の趣旨に沿ったコマンド）

$packageFullName = Get-AppxPackage -Name "Microsoft.Copilot" | Select-Object -ExpandProperty PackageFullName
Remove-AppxPackage -Package $packageFullName

組織端末で実施する場合は、適用範囲（ユーザー/デバイス）と再配布（更新で戻るか）を検証リングで確認してから本番へ広げてください。

Mozilla VPNが無効化される：更新後に“ネットワークが初期化された前提”で点検する

Windowsの品質更新は、ネットワークスタックやフィルタードライバ周りに影響が出ることがあり、VPNが「接続できない」「自動起動しない」「キルスイッチが期待通り動かない」といった形で表面化することがあります。特に、更新と同時期に回線/ルータ/プロバイダ側の変更が入ると、原因が重なって切り分けが難しくなります。

更新直後の点検ポイント（最短ルート）

• VPNアプリのサービスが起動しているか（サービス一覧で確認）
• アダプターが無効化されていないか（ネットワーク接続）
• Windowsの“ネットワークの場所”が変わっていないか（パブリック/プライベート）
• DNSが書き換わっていないか（社内DNS/広告ブロックDNS等）

ここで異常がなければ、VPNアプリの再インストールや最新化が最短になることもあります。更新前にインストーラを保存しておくと復旧が速いです。

Intuneの設定が個人のOffice 365アカウントに干渉して見える：混在環境の落とし穴

1台のPCで「組織（Intune/Entra ID）管理」と「個人のMicrosoftアカウント/個人のOffice」を混在させると、次のような現象が起きます。

• Edgeで組織プロファイルにポリシーが入り、個人利用にも影響しているように見える
• Officeアプリでサインインしたときに“デバイスの管理”を促され、意図せず登録状態が増える
• OneDrive（個人/職場）のサインイン導線が混ざり、設定が戻ったように見える

混在を現実的に扱う分離策（おすすめ順）

分離策	効果	手間	おすすめ度
Windowsユーザーを「仕事用/個人用」で分ける	ポリシー/資格情報/プロファイルが物理的に分離	中	高
Edgeプロファイルを必ず分ける（仕事/個人）	ブラウザ設定の衝突を減らす	低	高
仕事はVDI/リモートデスクトップに寄せる	端末の更新影響を最小化	高	中〜高（環境次第）
同一ユーザーで全部混ぜる	楽だが衝突リスク最大	低	低

「更新のたびに環境復旧が必要」という状況では、混在を“運用で吸収”するのは限界が来やすいです。まずは分離（Windowsユーザー、少なくともブラウザプロファイル）で“壊れる範囲”を狭めるのが効果的です。

KB5062553を適用した後に確認すべき“復活・巻き戻り”チェックリスト

更新の成否に関わらず（ロールバックでも）、影響が出やすい場所を先に点検すると、復旧が短時間で済みます。

カテゴリ	確認項目	よくある症状	即時対処
OneDrive	サインイン状態、起動設定、エクスプローラー表示	勝手に起動/表示/バックアップ提案	ポリシー再適用、スタートアップ無効、必要なら無効化
Copilot	タスクバー、アプリ一覧、Win+C動作	再表示、起動導線が増える	AppLocker/削除/ポリシー適用を再確認
VPN	サービス、アダプター、DNS	自動接続しない、通信できない	ネットワーク再認識、再起動、再インストール
Edge	プロファイル、同期、既定ブラウザ	プロファイル消失、設定初期化	同期復元、プロファイル再作成、バックアップ戻し
Outlook	フラグ、表示、アカウント	フラグが消える/見えない	OWA確認、表示/キャッシュ切り分け

「LCUを入れて戻したい」場合の現実解：wusaではなくDISMを前提にする

SSU＋LCUの一体型パッケージでは、wusa.exe の /uninstall で“まとめて消す”方法が使えない、と明記されています（SSUはインストール後に削除できないため）。

一方で、より新しいWindows 11の公式KBでは「LCUを削除したい場合は DISM /Remove-Package を使い、/Get-Packages でLCUのパッケージ名を確認する」と案内されています。つまり、ロールバック設計をするなら“DISMでの削除手順”まで含めて手順書にしておくのが安全です。

DISM /online /get-packages
DISM /online /remove-package /packagename:<LCUのパッケージ名>

ただし、更新の削除は状態をさらに不安定にすることもあるため、最優先は「イメージバックアップ→適用→問題があれば戻す」の流れを確立することです。

まとめ：KB5062553で警戒すべきは“隠し機能”より“更新プロセスの不安定化”

KB5062553は、2025年7月8日のWindows 11 24H2向けセキュリティ更新で、SSUとLCUが一体で配布されます。公式情報から読み取れる範囲でも、前月プレビュー由来の改善、AIコンポーネント更新（Copilot+ PC向け）、既知の不具合、Secure Boot証明書の将来リスクなど、実務上無視できない要素があります。

一方で、「非公開の変更点」を追いかけるより、次の3点を仕組み化した方が、更新で壊れないPCに近づきます。

• 0x800f0845は“土台の修復”から順に（トラブルシューティング→DISM/SFC→キャッシュリセット→手動適用）
• OneDrive/Copilotは“復活前提”でポリシー固定（GPO/レジストリ/AppLocker/削除）
• 混在（Intune＋個人アカウント）は分離で事故を減らす（Windowsユーザー/Edgeプロファイル/作業導線の分割）

更新が怖い環境ほど、止めるのではなく「遅らせる」「試す」「戻せる」をセットにして、復旧時間を“分単位”へ近づけていくのが最もコスパの良い対策です。