Windows 10更新失敗「KB5063842／KB5065429」をSFCFixで修復する手順と原因分析【22H2対応】

Windows 10 Version 22H2（x64）で「2025‑08 累積更新プレビュー（KB5063842）」や「2025‑09 累積更新（KB5065429）」の適用後にロールバックし、Windows Update に同じ更新が繰り返し再提示される——そんな厄介な症状に対して、原因の考え方から実効性の高い修復手順（SFCFix を用いたローカル修復）までを、実務目線で詳しく整理します。

現象の整理：再起動後に「変更を元に戻しています」→ 失敗がループ

対象環境は Windows 10 Version 22H2（x64）。次の更新を適用しようとすると、再起動後の構成段階でロールバックし、最終的に「更新プログラムを完了できませんでした。変更を元に戻しています」と表示されます。その後、Windows Update 画面に同じ更新が何度も再表示され、失敗がループします。

2025‑08 累積更新プレビュー：KB5063842
2025‑09 累積更新：KB5065429

症状	ユーザーが目にする挙動	典型的なログ上の手がかり
更新が適用できない	再起動後に構成が進まずロールバック、同じ KB が再提示	CBS.log に整合性やパッケージ適用の失敗。setupapi.dev.log にドライバー適用の失敗が残ることも
原因が読めない	画面上は汎用的なメッセージのみ	エラーコードが出ない・断片的で特定に至らない

根本原因の考え方：コンポーネントストア（WinSxS）やシステムファイルの破損

Windows 10 の累積更新（LCU）は、コンポーネントベースのサービシング（CBS）により、C:\Windows\WinSxS のコンポーネントストアに格納されたマニフェスト・カタログ・バイナリと照合・差分適用を行います。この過程で、

マニフェスト不整合（欠落・署名不一致）
以前の更新残骸や pending 操作の衝突
ドライバーやカスタムファイルの置換衝突

などがあると、整合性チェックを通過できずにロールバックが発生します。CBS.log には ERROR_SXS_COMPONENT_STORE_CORRUPT、CBS_E_SOURCE_MISSING、0x800f0988、0x80073701 等が出ることがあり、いずれも「元ファイル・メタデータの欠落／破損」が示唆されます。

最もシンプルで再現性の高い対処：SFCFix によるローカル自動修復

Sysnative フォーラム由来のツール「SFCFix」は、sfc /scannow と DISM /RestoreHealth を拡張し、ログ解析・不足ファイル抽出・置換を自動化する修復スクリプトです。公式ツールではありませんが、実運用での修復実績が高いことで知られます。本記事のケースでも この手順でインストール成功が報告されています。

SFCFix の実行手順（ローカル処理のみ）

SFCFix.exe と同梱スクリプト SFCFix.zip を デスクトップに保存します。
SFCFix.zip を SFCFix.exe にドラッグ＆ドロップします。
「Sysnative サーバーと通信しますか？」と聞かれたら n を入力し、ローカル処理のみを実行します。
処理完了後に生成される SFCFix.txt を確認し、指示された追加修復があれば従います。

注意： SFCFix はサードパーティのユーティリティです。実行は自己責任で行い、スクリプトの入手元とハッシュの整合性を必ず自分で確認してください。企業環境ではセキュリティポリシーに沿った承認プロセスを踏みましょう。

再起動 → 更新再試行

PC を再起動します。
設定 > Windows Update から KB5063842 または KB5065429 を再インストールします。
破損要因が除去されていれば、通常どおり構成が完了し、ロールバックは発生しません。

本記事の質問者は、上記フローでインストールに成功しています。

成功率を底上げする「前処理」チェックリスト

項目	推奨状態	理由
空き容量	システムドライブに 10〜15GB 以上	LCU 展開・差分適用・一時ファイル生成に余裕が必要
外付け機器	USB ストレージ・不要周辺機器は一旦取り外す	ドライブレターやドライバー衝突の回避
常駐保護	サードパーティ AV/EDR は一時的に「保護は維持・干渉は最小」に	ファイル置換やスクリプトブロック干渉の軽減
電源	AC 接続・スリープ無効	更新中断を防止
再起動待ち	保留中の再起動を片付ける	pending 操作の衝突回避

ログの要点：どこを見るか、どう読むか

「CBS.log や setupapi.dev.log を見ても特定できない」と感じるケースでも、読みどころを絞ると原因に近づけます。

CBS.log（`C:\Windows\Logs\CBS\CBS.log`）

キーワード：CSI、Manifest、Store corruption、ERROR_SXS_COMPONENT_STORE_CORRUPT、0x800f0988、0x80073701
時間帯：失敗した更新の適用時刻と一致するブロックを集中的に読む

setupapi.dev.log（ドライバー適用の成否）

該当時刻帯の inf 単位のインストール結果を追跡し、「failed」や 署名検証エラーを探す
失敗しているデバイスがあれば、手動で最新版に更新 or 一旦削除→再検出を試す

WindowsUpdate.log（PowerShell で生成）

PowerShell（管理者）:
Get-WindowsUpdateLog

デスクトップに生成された WindowsUpdate.log を開き、対象 KB の検出→ダウンロード→インストール→構成のフェーズ遷移とエラーを確認します。

エラーコードの早見表

コード	示す状態	対処の方向性
`0x800f0988`	PSFX 差分適用の失敗（ベース/差分の矛盾）	SFCFix、`DISM /RestoreHealth`、`StartComponentCleanup`
`0x80073701`	アセンブリ欠落（ERROR_SXS_ASSEMBLY_MISSING）	ソース指定の DISM 修復（後述）
`0x800f0922`	SRP（System Reserved Partition）空き不足 or 接続問題	SRP 拡張/不要フォント削除、VPN/プロキシ無効化

それでも失敗が続くとき：追加の実践手順

1) Windows Update コンポーネントのリセット

効果： ダウンロードキャッシュやコンテンツデータベースの不整合を解消。
リスク： 更新履歴が一部クリアされることがあります（インストール済み更新自体は消えません）。

管理者コマンド プロンプト:
net stop wuauserv
net stop bits
net stop cryptsvc
net stop msiserver

ren %systemroot%\SoftwareDistribution SoftwareDistribution.old
ren %systemroot%\System32\catroot2 catroot2.old

net start msiserver
net start cryptsvc
net start bits
net start wuauserv

2) pending 操作の解除（ロールバックの連鎖を止める）

効果： 保留中の更新処理が詰まっている場合に有効。
実施タイミング： 失敗直後〜次の再試行前。

管理者コマンド プロンプト:
dism /online /cleanup-image /revertpendingactions

3) コンポーネントストアの健全性回復

まずは標準の SFC/DISM を実行し、SFCFix を補助として使うと再現性が高まります。

管理者コマンド プロンプト:
sfc /scannow
dism /online /cleanup-image /scanhealth
dism /online /cleanup-image /restorehealth
dism /online /cleanup-image /startcomponentcleanup

補足： /startcomponentcleanup は 不要になったバージョンのコンポーネントを掃除します。/ResetBase は元に戻せないため、企業環境や検証前の端末では推奨しません。

4) ソース指定の DISM 修復（ISO からの復元）

効果： オンライン復元で解決しない欠落コンポーネントを、同一ビルド系の install.wim/esd から補完できます。

Windows 10 22H2 の公式 ISO を入手し、右クリックでマウント（例：D:\）します。
D:\sources\install.wim または install.esd のインデックスを確認します。

dism /Get-WimInfo /WimFile:D:\sources\install.wim

自分のエディション（Home/Pro 等）に該当する Index を確認し、次のように実行します。

dism /online /cleanup-image /restorehealth /source:wim:D:\sources\install.wim:Index番号 /limitaccess

ポイント： ビルドは一致している方が望ましいですが、同系統（22H2）であればマニフェストの整合により欠落分の復元が進むケースが多いです。

5) ドライバー起因の切り分け

setupapi.dev.log に特定デバイスの失敗が出ているなら、以下のいずれかを実施します。

該当デバイスの最新ドライバーに更新（メーカー提供）
更新直前にアンインストール → 再起動後に再検出
クリーンブートで更新（後述）

6) クリーンブートでの適用

常駐サービスやフィルタドライバーの干渉を排除します。

msconfig を開き、「サービス」タブで「Microsoft のサービスをすべて隠す」にチェック →「すべて無効」
「スタートアップ」はタスクマネージャーで無効化
再起動後に更新を再試行

7) 手動適用（MSU 直叩き）

Microsoft Update カタログから該当 KB の .msu を入手し、右クリックで「管理者として実行」または次のコマンドで適用します。

wusa "C:\Path\to\windows10.0-kb5065429-x64.msu" /quiet /norestart

注： /quiet を付ける場合は、必ず手動で再起動を行ってください。

プレビュー更新の扱い：安定重視ならスキップも選択肢

累積更新プレビューは月後半（3〜4 週目）に配信される任意の更新です。安定運用を優先するなら、設定 > Windows Update > 最新の情報をすぐに入手する（Get the latest updates as soon as they’re available）をオフにし、翌月の定例（Patch Tuesday）版を待つ方法も有効です。トラブルが発生した端末は特に、一度安定化してから定例版で取り直すのが安全です。

検証と合否判定：インストール後の確認コマンド

管理者コマンド プロンプト:
wmic qfe | find "KB5065429"
wmic qfe | find "KB5063842"

PowerShell:
Get-HotFix | Where-Object {$_.HotFixID -match "KB5065429|KB5063842"} | Format-Table -Auto

加えて、dism /online /get-packages /format:table で対象 KB のパッケージ状態が Install Pending で止まっていないことを確認します。

再発防止のベストプラクティス

対策	具体例	狙い
保守運用	月例メンテで `sfc` と `DISM /ScanHealth` を定期実行	破損の早期発見と軽微なうちの修復
クリーンアップ	「ディスククリーンアップ」または「ストレージセンサー」で一時ファイルを整理	更新の展開余地（空き容量）確保
SRP の管理	System Reserved Partition の空き不足なら拡張	`0x800f0922` の回避
ツール選定	レジストリクリーナーや過剰最適化ツールは避ける	マニフェスト破損の予防
更新ポリシー	プレビュー更新は検証端末のみ、業務端末は定例版で適用	トラブル波及の最小化

よくある質問（FAQ）

Q. SFCFix は安全ですか？

A. 非公式ツールのため「100%の保証」はありません。ただし、実務での修復成功例が多く、ローカル処理（n で拒否）に限定し、入手元・ハッシュを確認したうえで使う分には有力な選択肢です。企業利用では承認手続きと検証端末での先行テストを推奨します。

Q. DISM で直らないのはなぜ？

A. オンラインソースに存在しない・参照経路が壊れている・差分の不一致が大きい、などが理由です。ISO を用いたソース指定（/source:wim:... /limitaccess）や SFCFix の併用で成功率が上がります。

Q. ロールバックのたびに時間を浪費します。短縮のコツは？

A. pending の解除 → コンポーネント修復 → クリーンブート → 手動 MSU 適用の順で実施すると、無駄な再起動を抑えられます。ログは時間帯で切って読み、関係ない古いエラーに引きずられないことが重要です。

Q. それでも直らない場合の最後の手は？

A. インプレースアップグレード（上書きインストール）です。公式 ISO をマウントし setup.exe →「個人用ファイルとアプリを引き継ぐ」を選択して進めます。ネットワークを一時切断し、動的更新をスキップしてベースイメージで上書きすると、破損した CBS/WinSxS が広範囲に復元されるケースが多いです。

付録：作業フローの全体像（実務向け）

前処理（空き容量・保留再起動・周辺機器・AV 干渉排除）
SFCFix のローカル実行 → 再起動 → 更新再試行
失敗する場合：WU リセット → pending 解除 → SFC/DISM/StartComponentCleanup
まだ失敗：ISO ソース指定 DISM、setupapi.dev.log でドライバ特定 → 対処
クリーンブート で再試行 → MSU 手動適用
改善なし：インプレースアップグレードで仕切り直し

付録：コマンド早見表

目的	コマンド	メモ
システムファイル整合性	`sfc /scannow`	破損の一次検出・自動修復
コンポーネント健全性スキャン	`dism /online /cleanup-image /scanhealth`	破損の有無を調査
コンポーネント修復	`dism /online /cleanup-image /restorehealth`	オンラインソースで修復
不要バージョンの掃除	`dism /online /cleanup-image /startcomponentcleanup`	差分適用の衝突を減らす
保留操作の解除	`dism /online /cleanup-image /revertpendingactions`	ロールバック連鎖の停止
ISO ソース指定修復	`dism /Get-WimInfo /WimFile:D:\sources\install.wim` `dism /online /cleanup-image /restorehealth /source:wim:D:\sources\install.wim:<Index> /limitaccess`	インデックスは `/Get-WimInfo` で確認
WU コンポーネントリセット	`net stop wuauserv ... / ren SoftwareDistribution ...`	キャッシュ・カタログの再構築
インストール済み確認	`wmic qfe \| find "KB5065429"`	対象 KB の有無を確認

ケーススタディ：SFCFix 実行で解決した流れ（要点）

状況： KB5063842/KB5065429 がロールバック。CBS.log で確たる原因が掴めず。
対処： SFCFix をローカル処理（n）で実行 → 指示に従い不足ファイルを補填。
結果： 再起動後、Windows Update から KB の再インストールに成功。以降ロールバックは発生せず。

まとめ

累積更新の失敗は、システムファイル／WinSxS の破損が主因であることが多い。
SFCFix による一括修復 → 再起動 → 更新再試行は、手数が少なく効果が高い。
改善しない場合は、WU リセット／pending 解除／DISM（ISO ソース）／クリーンブート／MSU 直適用を段階的に行い、それでもダメならインプレースアップグレードで堅実に復旧する。
プレビュー更新は任意。安定重視ならオフにして定例版を待つ運用も合理的。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Windows 10更新失敗「KB5063842／KB5065429」をSFCFixで修復する手順と原因分析【22H2対応】

現象の整理：再起動後に「変更を元に戻しています」→ 失敗がループ

根本原因の考え方：コンポーネントストア（WinSxS）やシステムファイルの破損

最もシンプルで再現性の高い対処：SFCFix によるローカル自動修復

SFCFix の実行手順（ローカル処理のみ）

再起動 → 更新再試行

成功率を底上げする「前処理」チェックリスト

ログの要点：どこを見るか、どう読むか

CBS.log（`C:\Windows\Logs\CBS\CBS.log`）

setupapi.dev.log（ドライバー適用の成否）

WindowsUpdate.log（PowerShell で生成）

エラーコードの早見表

それでも失敗が続くとき：追加の実践手順

1) Windows Update コンポーネントのリセット

2) pending 操作の解除（ロールバックの連鎖を止める）

3) コンポーネントストアの健全性回復

4) ソース指定の DISM 修復（ISO からの復元）

5) ドライバー起因の切り分け

6) クリーンブートでの適用

7) 手動適用（MSU 直叩き）

プレビュー更新の扱い：安定重視ならスキップも選択肢

検証と合否判定：インストール後の確認コマンド

再発防止のベストプラクティス

よくある質問（FAQ）

Q. SFCFix は安全ですか？

Q. DISM で直らないのはなぜ？

Q. ロールバックのたびに時間を浪費します。短縮のコツは？

Q. それでも直らない場合の最後の手は？

付録：作業フローの全体像（実務向け）

付録：コマンド早見表

ケーススタディ：SFCFix 実行で解決した流れ（要点）

まとめ

この記事を書いた人

コメント

コメントするコメントをキャンセル

Windows 10更新失敗「KB5063842／KB5065429」をSFCFixで修復する手順と原因分析【22H2対応】

現象の整理：再起動後に「変更を元に戻しています」→ 失敗がループ

根本原因の考え方：コンポーネント ストア（WinSxS）やシステムファイルの破損

最もシンプルで再現性の高い対処：SFCFix によるローカル自動修復

SFCFix の実行手順（ローカル処理のみ）

再起動 → 更新再試行

成功率を底上げする「前処理」チェッ クリスト

ログの要点：どこを見るか、どう読むか

CBS.log（C:\Windows\Logs\CBS\CBS.log）

setupapi.dev.log（ドライバー適用の成否）

WindowsUpdate.log（PowerShell で生成）

エラーコードの早見表

それでも失敗が続くとき：追加の実践手順

1) Windows Update コンポーネントのリセット

2) pending 操作の解除（ロールバックの連鎖を止める）

3) コンポーネント ストアの健全性回復

4) ソース指定の DISM 修復（ISO からの復元）

5) ドライバー起因の切り分け

6) クリーンブートでの適用

7) 手動適用（MSU 直叩き）

プレビュー更新の扱い：安定重視ならスキップも選択肢

検証と合否判定：インストール後の確認コマンド

再発防止のベストプラクティス

よくある質問（FAQ）

Q. SFCFix は安全ですか？

Q. DISM で直らないのはなぜ？

Q. ロールバックのたびに時間を浪費します。短縮のコツは？

Q. それでも直らない場合の最後の手は？

付録：作業フローの全体像（実務向け）

付録：コマンド早見表

ケーススタディ：SFCFix 実行で解決した流れ（要点）

まとめ

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

根本原因の考え方：コンポーネントストア（WinSxS）やシステムファイルの破損

成功率を底上げする「前処理」チェックリスト

CBS.log（`C:\Windows\Logs\CBS\CBS.log`）

3) コンポーネントストアの健全性回復

コメントするコメントをキャンセル