Windows Update で「0x80070643」が繰り返し発生し、Windows 10 22H2 の KB5063523／KB5042320 が適用できない――そんな厄介なケースに対して、実機検証で再現しやすい手順をもとに、確実性の高い直し方を整理しました。標準的なトラブルシューティングで詰まった人向けに、失敗要因の切り分けからインプレースアップグレードまで、実運用で役立つ具体策を解説します。
症状と環境の整理
相談例の前提条件は次のとおりです。
- 対象 OS：Windows 10 バージョン 22H2（Home / Pro どちらでも発生しうる）
- 対象更新プログラム：KB5063523、KB5042320（いずれも適用に失敗）
- エラーコード：0x80070643（インストール時の致命的なエラー）
- 端末履歴：Windows 7 → 8 → 10 と段階的アップグレードした古い PC
- Windows RE（回復環境）パーティション：約 13 GB（通常よりかなり大きい）
- Windows Update の基本的なトラブルシューティングでは改善なし
この条件だと、コンポーネント ストア（WinSxS）や Windows Update コンポーネントの不整合、.NET/Defender 系の失敗履歴、旧バージョンから持ち越したサービス設定が絡む確率が上がります。一方で、RE パーティションの大きさ自体は 0x80070643 の直接原因ではないことが多く、根治にはシステムコンポーネントの整合性回復が鍵になります。
5分でできる事前チェック（原因の当たりを付ける）
| 確認ポイント | 見る場所 / コマンド | 判断・対処の目安 |
|---|---|---|
| 残り容量 | エクスプローラー（C:） | 10GB 以上推奨。足りなければ一時ファイル削除と再試行。 |
| 日付と時刻 | 「日付と時刻」設定 | 自動設定に変更。ズレが大きいと署名検証に失敗。 |
| グループポリシー/WSUS | gpedit / レジストリ / gpresult | 社内 WSUS 指定があると配信元相違で失敗。個人PCは無効が無難。 |
| サードパーティ AV | セキュリティ製品設定 | リアルタイム保護を一時的に停止してから適用。 |
| システム整合性 | 管理者 CMD | sfc /scannow で破損が出たら後述の DISM と併用。 |
0x80070643 の背景（なぜ起きるのか）
0x80070643 は「致命的なエラーでインストールに失敗」を示す汎用コードで、以下の要因で出やすい傾向があります。
- .NET Framework 系の修復・適用失敗（MSI ベースの更新や GAC の不整合）
- Microsoft Defender プラットフォーム/定義の異常（過去の失敗履歴や署名検証ミス）
- Windows Update コンポーネントの破損（ソフトウェア配布フォルダ/カタログの不整合、BITS キューの詰まり）
- コンポーネント ストア（WinSxS）破損や保留中更新の干渉（pending.xml など）
- 旧 OS からのアップグレードで持ち越したサービス設定や署名ストアのゆがみ
したがって、まずは Windows Update コンポーネントを正しく初期化し、改善しなければ OS の上書き修復（インプレースアップグレード）でシステムファイルとサービス構成を健全化するのが、手戻りの少ない順路です。
実効性の高い解決策（確実性順）
Windows Update コンポーネントのリセット（最初に試す）
管理者権限の PowerShell またはコマンドプロンプトで、次のコマンドを1 行ずつ実行します。途中で「パスが見つからない」「パラメータが違う」等が表示されても、基本的にはそのまま進めて構いません。完了後は再起動し、更新プログラムを再試行します。
net stop bits
net stop wuauserv
net stop appidsvc
net stop cryptsvc
del "%ALLUSERSPROFILE%\Application Data\Microsoft\Network\Downloader\*.*"
rmdir %systemroot%\SoftwareDistribution /S /Q
rmdir %systemroot%\system32\catroot2 /S /Q
regsvr32 /s atl.dll
regsvr32 /s urlmon.dll
regsvr32 /s mshtml.dll
netsh winsock reset
netsh winhttp reset proxy
net start bits
net start wuauserv
net start appidsvc
net start cryptsvc
補足の確認ポイント：
- サービスが停止できない場合は、再起動直後に同じ手順を試してください。
mshtml.dllの再登録でエラー表示が出ても、続行して構いません（自己登録を持たない DLL があるため）。- プロキシ環境の場合、
netsh winhttp reset proxyで既定に戻るため、必要に応じて再設定してください。
追加の健全化（任意）
上記のリセットと合わせて、システム整合性の回復を実行すると成功率が高まります。
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
DISM /Online /Cleanup-Image /StartComponentCleanup
/ResetBase オプションはアンインストール不能化の副作用があるため、業務端末では推奨しません。まずは /RestoreHealth と /StartComponentCleanup で十分です。
改善しない場合：インプレースアップグレード（上書き修復）
公式の手順に従い、Windows 10 メディア作成ツールで最新の 22H2 メディアを作成し、USB/DVD 内の setup.exe から起動して「個人用ファイルとアプリを引き継ぐ」を選んで上書きセットアップを行います。これにより、カーネルやサービス、コンポーネント ストアが健全な状態に再構成され、累積更新の適用経路がリセットされます。
事前準備チェック：
- 復元ポイントの作成と、システム全体のフルバックアップ取得（外付けストレージ推奨）。
- サードパーティ製アンチウイルスの保護を一時停止。
- BitLocker を有効化している場合は回復キーを控える。
- 周辺機器は最小構成（USB メモリ、必要最小限の入力機器のみ）にする。
セットアップ時の選択肢が「この PC を今すぐアップグレード」しか出ない、または既に 22H2 で進められない場合は、「別の PC 用にインストール メディアを作成」を選び、作成したメディアからの setup.exe 実行で同様の上書き修復が可能です。
追加の注意点
- サードパーティ製アンチウイルスは、カーネルドライバの介入で Windows Update を妨げることがあります。セットアップ直前に一時停止するか、トラブルシューティング中のみアンインストールして検証します。
- Windows RE パーティション（約 13GB）について：サイズ過大は稀に更新前後のスクリプト挙動に影響しますが、0x80070643 の直接原因ではないのが一般的です。気になる場合は次のコマンドで状態を確認してください。
reagentc /info
必要に応じて reagentc /disable → ディスクの管理でパーティションを整理 → reagentc /enable で再登録します。パーティション編集はリスクがあるため、必ずバックアップ済みであること、そして操作は最小限に留めるのが原則です。
実運用に効く「まとめテーブル」
| 手順 | 内容 | 補足 |
|---|---|---|
| Windows Update コンポーネントのリセット | サービス停止 → キャッシュ削除 → DLL 再登録 → ネットワークスタック初期化 → サービス再開。 | 途中エラーは基本無視可。実行後に再起動して更新を再試行。 |
| 改善しない場合：インプレースアップグレード | メディア作成ツールで作成したメディアの setup.exe を実行し、上書き修復。 | 個人ファイル・アプリは保持。事前に復元ポイントとフルバックアップ必須。 |
| 追加の注意点 | サードパーティ AV は一時停止。RE パーティションは reagentc で確認・再登録。 | RE サイズは直接原因ではないが、違和感があれば健全化を。 |
ログで原因を見極める（再発防止のための読み方）
根治を目指すなら、失敗時ログの最低限の読み方も押さえましょう。
- WindowsUpdate.log：Windows 10 では ETL を統合して生成します。PowerShell（管理者）で
Get-WindowsUpdateLogを実行するとデスクトップに出力されます。エラー近辺に 0x80070643 や MSI 失敗（Return value 3）、証明書検証失敗などの痕跡が出ます。 - CBS.log：
C:\Windows\Logs\CBS\CBS.log。Failed to finalize や Store corruption が繰り返し出ていれば DISM の適用対象です。 - DISM ログ：
C:\Windows\Logs\DISM\dism.log。RestoreHealth 実行結果とエラー位置を確認。 - Defender 関連：
Event Viewer > Applications and Services Logs > Microsoft > Windows > Windows Defender。プラットフォーム更新の失敗が続くと 0x80070643 を引き起こすことがあります。
うまくいかないときの「切り札」チェックリスト
| 症状 | 追加アクション | メモ |
|---|---|---|
| 更新が 30% 付近でロールバック | sfc と DISM を再実行してからインプレースアップグレード。 | ドライバやフィルタドライバが原因のことも。周辺機器は外す。 |
| 再起動のたびに同じ KB が繰り返し失敗 | コンポーネントリセット後に SoftwareDistribution の再生成を確認。 | 日時の自動設定とタイムゾーンの見直しも同時に。 |
| Defender の更新だけが失敗 | 管理者 CMD で "C:\Program Files\Windows Defender\MpCmdRun.exe" -SignatureUpdate | 失敗履歴が溜まっていると 0x80070643 が派生。手動更新で復旧する例あり。 |
| 社内ネットワーク配下の端末 | WSUS/Intune のポリシーを一時的に外して検証（家庭用回線で試験）。 | 配信元の齟齬で差分計算に失敗しやすい。 |
Windows RE パーティションは関係ある？（誤解が多いポイント）
13GB という RE パーティションは明らかに大きすぎます。一般的には 750MB～1GB 程度が多く、アップグレードの繰り返しやベンダー独自の回復領域が重なって肥大化することがあります。ただし、0x80070643 の直接原因はコンポーネント ストアや更新コンポーネントの不整合であることが大半です。とはいえ、将来の回復環境の更新で問題化する前に整える価値はあります。
現状確認と再登録の手順：
reagentc /infoで「Windows RE の状態」が 有効 か、配置パスが正しいか確認。- サイズを整理したい場合は
reagentc /disableで無効化 → ディスクの管理または専用ツールで縮小 →reagentc /enableで再有効化。 - 作業前にフルバックアップは必須。特に MBR/レガシー変換の履歴がある PC は注意。
現場で役立つコマンド スニペット集
トラブル対応時に手元にあると便利な最低限のコマンドをまとめます（いずれも管理者権限）。
| 目的 | コマンド | 説明 |
|---|---|---|
| 更新コンポーネントの健全化 | DISM /Online /Cleanup-Image /RestoreHealth | 破損したコンポーネントを回復。sfc より下層を修復。 |
| システムファイル検証 | sfc /scannow | 標準ファイルの整合性を確認・修復。 |
| Windows Update ログ生成 | PowerShell: Get-WindowsUpdateLog | ETL を統合して読みやすいログを出力。 |
| プロキシ設定の初期化 | netsh winhttp reset proxy | WinHTTP のプロキシを既定に戻す。 |
| Winsock リセット | netsh winsock reset | ネットワークスタックの不整合を解消。 |
よくある質問（落とし穴と回避策）
「DLL の再登録でエラーが出た」
自己登録を想定していない DLL に対して regsvr32 を実行するとエラー表示になります。更新コンポーネントのリセット手順としては許容されるため、そのまま続行して問題ありません。
「DISM がエラーを返す」
ネットワーク制約やソース不足で /RestoreHealth が失敗する場合があります。そのときは再起動後に再試行し、同時にプロキシやセキュリティ製品の干渉を疑ってください。どうしても直らない場合は、インプレースアップグレードが最も確実です。
「インプレースアップグレードで個人データは消える？」
正しく実施すれば基本的に保持されます。ただし想定外のロールバックや電源断のリスクはゼロではないため、必ずフルバックアップを取得してから実行してください。
「古いドライバが原因になる？」
はい。特にストレージやセキュリティ関連のドライバは更新適用に干渉します。上書き修復前にベンダー提供の最新安定版へ更新し、周辺機器は最小構成で試すのが安全です。
今回のケースの結論（実例）
本記事の相談者は、Windows Update コンポーネントのリセット（サービス停止・キャッシュ削除・再起動）では改善せず、続いて インプレースアップグレードを実施したところ、エラー 0x80070643 が解消し、KB5063523 / KB5042320 を正常に適用できたと報告しています。RE パーティションの過大サイズはその後に是正しましたが、更新失敗の直接原因ではありませんでした。これは、コンポーネント ストアの不整合や更新コンポーネントの破損を上書き修復で正常化したことにより、累積更新の差分適用が正しく計算されるようになった典型例です。
再発させないための運用ヒント
- 月例更新の適用前に「不要な一時ファイル削除」「sfc/DISM の軽い健全化」を習慣化。
- セキュリティ製品は OS 標準との二重起動を避ける（重複は干渉の温床）。
- グループポリシーや WSUS/配信ルールを運用している場合、検証用のスタンドアロン端末を用意し、同一 KB の成否を比較できる体制を整える。
- 回復環境（RE）のサイズや配置は年に一度点検し、異常に肥大化していないか確認。
最終まとめ
Windows Update の 0x80070643 は、.NET/Defender/コンポーネント ストア/更新コンポーネントのいずれかの不整合が複合して起きがちです。まずはコンポーネントのリセットで詰まりを取り除き、改善しなければインプレースアップグレードで OS を上書き修復する。この二段構えが、手戻りや時間のロスを最小化する最短ルートです。RE パーティションの大きさは直接の犯人ではないため、更新エラーの解消を優先し、落ち着いてから整備すれば十分です。実際の相談ケースでも、上書き修復で KB5063523／KB5042320 の適用に成功しています。困ったときは本記事の表とコマンドを順に実施し、根本から立て直してください。
実行手順の貼り付け用まとめ（一気に作業したい方向け）
以下を上から順に実行し、再起動 → 更新の再試行 → 改善しなければインプレースアップグレードの順に進みます。
:: 管理者 CMD / PowerShell（1 行ずつ）
net stop bits
net stop wuauserv
net stop appidsvc
net stop cryptsvc
del "%ALLUSERSPROFILE%\Application Data\Microsoft\Network\Downloader\*.*"
rmdir %systemroot%\SoftwareDistribution /S /Q
rmdir %systemroot%\system32\catroot2 /S /Q
regsvr32 /s atl.dll
regsvr32 /s urlmon.dll
regsvr32 /s mshtml.dll
netsh winsock reset
netsh winhttp reset proxy
net start bits
net start wuauserv
net start appidsvc
net start cryptsvc
:: 任意（推奨）：整合性の修復
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
DISM /Online /Cleanup-Image /StartComponentCleanup
:: Defender の手動更新（必要時）
"C:\Program Files\Windows Defender\MpCmdRun.exe" -SignatureUpdate
:: RE 確認（必要時）
reagentc /info この手順で改善しない場合は、メディア作成ツールで作成したメディアから setup.exe を実行し、「個人用ファイルとアプリを引き継ぐ」を選んでインプレースアップグレードを行ってください。作業前にはバックアップと復元ポイントの作成を忘れずに。
トラブル対応メモ（担当者引き継ぎ用）
- 失敗時刻・KB 番号・エラーコード（0x80070643）をチケットに明記し、WindowsUpdate.log・CBS.log の抜粋を添付。
- インターネット/社内ネットワークの差分検証（WSUS 利用有無）を記録。
- インプレースアップグレード実施時は、使用したメディアのビルド/エディション情報を控える。
- RE パーティションの状態（
reagentc /infoの出力）をスクリーンショット化して保管。
結び
「毎回同じところで失敗する」「他の PC では通るのにこの PC だけ落ちる」といったケースは、システムの経年劣化や構成の持ち越しが原因であることが少なくありません。だからこそ、リセット → 上書き修復というシンプルなセオリーを確実に回すことが最短距離です。本記事の手順で、KB5063523／KB5042320 の適用に悩む時間を最小化し、正常な更新サイクルへ復帰させましょう。
コメント