Windows 11更新プログラムKB5063878/KB5062660がインストールできない時の原因と対処法【エラー0x800f0922】

Windows 11で「KB5063878」「KB5056579」「KB5062660」などの更新プログラムがエラーになり、何度試してもインストールできない――そんな状況に陥ると、PC初心者だけでなく上級者でも不安になります。本記事では、実際の事例Q&Aをもとに、同様の症状が出たときに役立つ原因の整理と具体的な解決手順を、できるだけわかりやすくまとめます。

Windows 11 更新プログラムがインストールできない問題の概要

ここで取り上げる事例では、Windows 11の環境で次のような更新プログラムがインストールできない状況が続いていました。

• 2025年8月の累積更新プログラム：KB5063878
• .NET Framework 用更新プログラム：KB5056579
• 2025年7月の累積更新プログラム（プレビューを含む）：KB5062660 など

症状としては、Windows Updateでダウンロードまでは進むものの、インストール途中でエラーが出てロールバックされてしまい、次のエラーコードが表示されていました。

• 0x80070228
• 0x80070570
• 0x800f0922

更新が止まったタイミングは「7月頃から」。セキュリティ更新以外の品質更新が主に失敗している、というのも特徴です。

項目	状況
OS	Windows 11（ビルド 26100.1742 からスタート）
失敗した更新	KB5063878、KB5056579、KB5062660 など
主なエラーコード	0x80070228、0x80070570、0x800f0922
Windows Update の挙動	「インストールに失敗しました」「あとで再試行します」と表示されることもある

発生していたエラーコードと意味

この事例で出ていたエラーコードは、更新プログラムに関するトラブルでは比較的よく見かけるものです。ざっくりとした意味と、よくある原因を整理すると次のようになります。

エラーコード	ざっくりした意味	よくある原因の例
0x80070228	ファイルのコピーや展開中の問題	更新ファイルの破損、一時ファイルの不整合、ドライブの不具合など
0x80070570	ファイルが壊れている、または読み取れない	ディスク上のデータ破損、不良セクター、一時フォルダの異常など
0x800f0922	Windows Update の内部処理失敗	.NET関連コンポーネントや機能の更新が失敗 予約システムパーティションの空き不足 特定のコンポーネント（Appx / UWPアプリ）が壊れている

今回のケースでは、更新プログラム自体のダウンロードやネットワークの問題ではなく、「更新中に内部コンポーネントの処理がうまくいかず失敗する」タイプのトラブルだったと考えられます。

ユーザーがすでに試していた一般的な対処

相談者はすでにかなり多くの対処を試しており、「基本的なトラブルシューティングでは解決しないレベル」まで来ていました。実施されていた主な内容は次のとおりです。

• DISMによるコンポーネントストアのチェック／修復
• sfc /scannow によるシステムファイルの修復
• chkdsk によるディスクチェック
• SoftwareDistribution / catroot2 フォルダのリセット（更新キャッシュの削除）
• .msu ファイルを使ったオフラインインストール（DISM /online やダブルクリックでの適用）
• 個人データとアプリを保持したままの Windows 再インストール（インプレースアップグレード）

対処内容	目的	結果
DISM / sfc / chkdsk	システムファイルやディスクの不整合を修復する	問題は検出・修復されるが、更新エラーは解消せず
更新キャッシュの削除	古い・壊れた更新ファイルを一掃してやり直す	一時的な改善はなく、エラーは継続
オフラインインストール	Windows Update の仕組みをバイパスして直接更新を適用	インストール途中で同様に失敗
インプレースアップグレード	OSを上書きインストールしてシステムをほぼ初期状態に近づける	OS自体は新しいビルドになったが、更新エラーは残った

ここまで実施しても解決しない場合、原因は「更新ファイル」や「基本的なシステムファイル」よりも、より深いレベルのコンポーネント（UWPアプリやAppxの登録情報など）が壊れている可能性が高くなります。

原因の手がかりになったログ情報

更新に失敗した際のログには、次のようなメッセージが記録されていました。

• 「MicrosoftWindows.LKG.Search_cw5n1h2txiewy のアンインストールに失敗」
• 「拡張 DLL を読み込めない（指定されたモジュールが見つかりません）」
• 「パッケージを登録できませんでした」

これらは、Windows Search（検索機能）やその他のUWPアプリに関連する Appx パッケージの登録情報が壊れている ときに出やすい内容です。更新プログラムは内部で「古いコンポーネントのアンインストール→新しいコンポーネントのインストール／更新」を行いますが、この「アンインストール」の段階でつまずいているイメージです。

つまり、今回のケースの本質は次のようにまとめられます。

• 通常のシステムファイルやディスクはおおむね問題ない
• しかし、一部の UWP / Appx コンポーネント（特に検索関連）の登録・アンインストール情報が壊れている
• その結果、更新プログラムの適用が途中で止まり、0x800f0922 などのエラーになっていた

実際に効果があった解決策の流れ

最終的に相談者の環境では、以下の流れで問題を回避・解決しています。

1. Appx 関連の不整合を修正するレジストリファイル（appxfix.reg / appxfix_2.reg）の適用
2. 7月分の累積更新プログラム（LCU）を オフラインインストール で適用
3. その後、8月以降の更新については、ニュースや既知の不具合情報を見つつ様子を見て適用判断

Appx 関連コンポーネントの修正（レジストリファイル適用）

サポート側から提示された appxfix.reg および appxfix_2.reg は、Appx に関わる設定や参照先を修正するためのレジストリファイルでした。これにより、壊れた状態になっていた UWP / Appx パッケージの情報を整理し、更新処理が進める状態に戻すことが狙いです。

一般ユーザーが同じ内容のレジストリファイルを自作するのは危険なため、ここでは「考え方」と「安全に行うためのポイント」に絞って整理します。

ポイント	概要
レジストリ編集は自己責任	誤った編集は起動不能の原因になり得るため、バックアップや復元ポイントの作成が必須です。
信頼できるソースのみ使用	ネット上の「レジストリ修正ファイル」を安易にダウンロードしないこと。公式サポートや信頼できる窓口から提供されたものだけを使うのが基本です。
Appx や UWP アプリの不整合を疑う目安	更新ログに特定のアプリ名（例：Search、Storeなど）のアンインストール失敗が繰り返し出ている場合は、Appx関連の不整合を疑う価値があります。

企業や組織であれば、ログを添えて管理者・ベンダーサポートに相談し、同様の「Appx修正スクリプト」や手順を個別に提供してもらうやり方が安全です。

7月分累積更新プログラムのオフラインインストール

Appxの不整合を修正したあと、最新（8月）の更新ではなく、ひとつ前の 7月分の累積更新プログラム（LCU） をオフラインインストールすることで、更新チェーンを一段階ずつ進めることに成功しました。

ここでポイントになるのは、「最新の問題のある更新を無理に入れようとせず、ひとつ前の安定した更新を適用する」という考え方です。手順のイメージは以下のとおりです。

1. 対象の更新プログラム（例：KB5064489 や KB5062660 など、同じ月の別LCU）を特定する
2. 別PCやブラウザから Microsoft Update カタログを開き、該当KB番号で検索
3. 自分の環境（Windows 11、x64 など）に合った .msu ファイル をダウンロード
4. 対象PCにコピーして、ダブルクリックまたは管理者権限のコマンドでインストール

コマンドからインストールする場合、例えば次のようなイメージになります（※パスは環境に合わせて変更してください）。

DISM /online /add-package /packagepath:C:\Temp\windows11-kbXXXXXXX-x64.msu

この事例では、7月分のLCUが無事インストールされ、OSビルドが一段階進んだことで、その後の更新も適用しやすい状態になりました。

方法	メリット	デメリット
Windows Update 経由	自動で依存関係を処理してくれる。基本はこれで十分。	内部コンポーネントの不具合があると原因が見えにくい。
オフラインインストール（.msu）	Windows Update の仕組みをある程度バイパスでき、特定のKBだけをピンポイントで当てられる。	KBの選定を自分で行う必要があり、誤ったKBやエディションを選ぶと失敗する。

結果とその後の判断

7月分の累積更新プログラムをオフラインで適用した結果、相談者の環境では更新プログラムのインストールが成功し、問題のない状態に近づきました。その上で、8月の更新については次のような判断をしています。

• SSDなど特定のハードウェアでトラブル報告がある更新は、すぐには入れず様子を見る
• プレビュー更新（KB5062660 のような毎月末のオプション更新）は、緊急性がなければ無理に入れない
• セキュリティ更新や致命的な不具合修正が含まれる更新は、情報を確認した上で適用を検討する

つまり、「すべての更新をとにかく最新にしないといけない」というよりも、「自分の環境に必要な更新を、安定性や情報と相談しながら適用する」というスタンスが大切だと言えます。

同じような症状が出たときのおすすめ手順

ここからは、今回の事例をベースに「自分のPCで同様のエラーが出た場合にどう動くとよいか」をステップ形式で整理します。すべてを一気にやる必要はなく、上から順に試し、どこかの段階で解決すればOKです。

ステップ1：バックアップと復元ポイントの作成

• 重要なデータは外付けドライブやクラウドにバックアップしておく
• システムの復元ポイントを作成しておくと、レジストリ操作や更新失敗時の「保険」になります

ステップ2：エラーコードと失敗しているKB番号を整理する

• Windows Updateの画面で、どの更新（KB番号）がどんなエラーで失敗しているかをメモする
• .NET Framework 用更新か、累積更新（LCU）かを分けて認識しておくと切り分けが楽になります

ステップ3：基本の修復コマンドを実行する

まだ試していない場合は、まずは標準的な修復コマンドから進めます。管理者権限の「Windows Terminal（PowerShell）」または「コマンドプロンプト」を開いて次の順番で実行します。

1. システムファイルチェック

sfc /scannow

2. コンポーネントストアのチェックと修復

DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth

3. ディスクチェック（再起動時に実行されます）

chkdsk C: /f /r

これらでエラーが出た場合は、その内容を控えておくと原因特定の手がかりになります。

ステップ4：Windows Update コンポーネントのリセット

更新のキャッシュや一時ファイルが壊れている場合には、Windows Update関連のサービスを一旦止めてキャッシュをリセットすることで改善することがあります。管理者権限のコマンドプロンプトで、例えば以下のような手順をとります。

net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver

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

net start wuauserv
net start cryptSvc
net start bits
net start msiserver

その後、PCを再起動してから Windows Update を再度実行し、状況を確認します。

ステップ5：サードパーティ製アンチウイルス・常駐ソフトの影響を確認

一部のアンチウイルスや常駐ソフトが更新処理に干渉しているケースもあります。事例のサポートでも、次のような確認が提案されています。

• サードパーティ製アンチウイルスを一時的に無効化する
• 可能であればアンインストールして再起動し、その状態で更新を試す

その際、Windows Defender（標準の「Windows セキュリティ」）は基本的に自動で有効になるため、セキュリティ的に極端に無防備になることはありません。

ステップ6：App Readiness サービスを確認する

Appx / UWPアプリの準備に関わる 「App Readiness」サービス が無効になっていると、更新時に新しいコンポーネントの登録がうまくいかないことがあります。事例でもこのサービスの確認が行われていました。

確認手順のイメージは次のとおりです。

1. Windowsキーを押して「サービス」と入力し、「サービス」アプリを起動
2. 一覧から「App Readiness」を探す
3. スタートアップの種類が「無効」になっていたら、「手動」に変更
4. サービス状態が「停止」の場合は「開始」、既に「実行中」なら「再起動」を選択
5. OKを押してサービス画面を閉じ、PCを再起動してから更新を再度試す

ステップ7：Appx / UWP アプリの異常を疑う

ここまでで改善しない場合、今回の事例のように「特定の UWP アプリ（検索やストアなど）のアンインストール・登録に失敗している」可能性が出てきます。ログに具体的なアプリ名やパッケージ名が出ている場合は、そのアプリを以下のように見直します。

• 対象のアプリをストアから再インストールしてみる
• ローカルの別アカウントで同じ更新を試し、再現するかをチェック
• 企業環境なら、ログ（CBS.logなど）を添えてサポート窓口にエスカレーションする

レジストリ修正を伴う Appx 修復は、内容を間違えると起動不能レベルのトラブルに発展し得るため、必ずバックアップと復元ポイントを取ったうえで、信頼できる指示のもとで実施することをおすすめします。

ステップ8：ひとつ前の累積更新をオフラインで適用する

最新の更新が失敗する場合でも、ひとつ前の月の累積更新は適用できることがあります。今回の事例では、まさにこの方法で状況が好転しました。

流れを整理すると次のようになります。

1. 現在の OS ビルドやインストール済みの更新履歴を確認する
2. 問題になっている月（例：8月）のひとつ前の累積更新（例：7月のLCU）を特定する
3. Microsoft Update カタログから該当する .msu をダウンロード
4. .msu をダブルクリック、または DISM /add-package でインストール
5. 再起動後、Windows Updateの画面でその後の更新状況を確認

この「ひとつ前の安定版をまず入れる」という考え方は、最新の更新で一時的な不具合が出ているときにも有効な場合があります。

プレビュー更新（KB5062660 など）と通常の累積更新の違い

今回のQ&Aの中でも、「KB5062660のようなプレビュー更新は必ずしも入れる必要はない」というコメントがありました。ここでは、その背景を簡単に整理します。

種類	例	特徴	インストールの考え方
月例累積更新（本番・必須）	毎月第2火曜日付近の「セキュリティを含む累積更新」	セキュリティ修正や重要な不具合修正を含む。原則として適用が推奨される。	基本的には導入する。トラブルがあれば数日情報を待ってから適用。
プレビュー更新（オプション）	月末に出る「プレビュー」「オプション品質更新」など	次の月例累積更新に含まれる予定の修正を先行提供。必須ではない。	特定の不具合に困っている場合や検証環境でのみ適用するのがおすすめ。

KB5062660 のようなプレビュー更新は、「特定の問題に悩んでいる人向けのテスト版」のような位置付けです。特にホーム用途のPCで、目立った不具合が出ていない場合は、以下のような方針も十分アリです。

• プレビュー更新は「表示されていても、あえて適用しない」
• 次の月例累積更新に内容が取り込まれるのを待つ

逆に、仕事でどうしても直したい既知の不具合が含まれている場合は、プレビュー更新を先行適用することで業務が楽になるケースもあります。用途とリスク許容度に応じて判断しましょう。

トラブルシューティングのコツと注意点

最後に、今回の事例から汎用的に活かせるポイントをまとめます。

ログとエラーコードを「言語化」して残す

• エラーコードや失敗したKB番号、イベントログの要点をメモしておくと、原因の切り分けが格段に楽になります。
• 「どのコンポーネントのアンインストール／登録で失敗しているか」がわかると、Appxなのか、.NETなのか、ドライバなのか、といった方向性が見えてきます。

一気に大掛かりな再インストールに行かない

• 今回のケースでも、インプレースアップグレードを行っても問題が残りました。
• まずは基本的なコマンド（sfc、DISM、chkdsk）と更新コンポーネントリセットを行い、それでもダメならログベースで深掘りする方が結果的に早いことも多いです。

レジストリやAppx修正は慎重に

• レジストリを直接触る修正は強力ですが、そのぶんリスクも高いです。
• 必ず復元ポイントを作り、内容が理解できない .reg ファイルをネットから安易に拾ってこないことが重要です。

最新更新が不安なら「一歩手前の安定版」を使う

• 最新の累積更新で特定のSSDやデバイスにトラブル報告がある場合、すぐに適用しないという選択もあります。
• ひとつ前のLCUをオフラインインストールしておき、「セキュリティ的にそこまで遅れていない状態」をキープする運用も現実的です。

仮想化機能（Hyper-V、Virtual Machine Platform など）の影響も頭の片隅に

• 今回の相談者のように、WSA（Android用サブシステム）やWSL、仮想化機能をいろいろ試している場合、それらが更新処理に影響することもゼロではありません。
• トラブルシューティングの一環として、一時的に機能を無効化してから更新を試す、というアプローチも選択肢になります。

まとめ：Windows 11 更新エラーは「分解して」考える

Windows 11 の更新エラー、とくに 0x800f0922 のようなコードは、原因がひとつとは限らず、「ディスクの空き不足」「.NETの不具合」「Appx / UWP アプリの異常」など複数パターンがあります。

本記事で取り上げた事例では、

• Appx（検索コンポーネント）の不整合をレジストリ修正で解消し
• いきなり最新ではなく、ひとつ前のLCUをオフラインで適用する

という二段構えで、長期間続いていた更新失敗から脱出することができました。

同じような状況でお困りの場合は、

• まずは基本的なコマンドと更新コンポーネントのリセット
• App Readiness やサードパーティ製ソフトの確認
• ログにAppxや特定アプリのアンインストール失敗が出ていないか確認
• 必要に応じて、ひとつ前の累積更新をオフラインで適用

という流れで、少しずつ原因を狭めていくのがおすすめです。時間はかかりますが、エラーの正体が見えてくると、更新トラブルは必ず出口が見えてきます。