Windows 11 23H2/24H2 累積更新プログラムが7%でロールバックする原因と対策｜イベントログ破損の修復手順

Windows 11 23H2／24H2で2025年4〜6月の累積更新プログラムを適用すると、再起動後7%付近でロールバックして失敗するケースがあります。CBS.logではusb4devicerouter.infが原因に見えますが、実態はセキュリティ／システムのイベントログ破損。ログを修復・再生成すると更新が通ります。

発生している事象の全体像

現場で多発しているのは、Windows 11 23H2／24H2 端末に対して、2025年4月・5月・6月の累積更新プログラム（CU / Cumulative Update）を適用した際に、再起動後の構成フェーズで進捗が7%前後に達したところでロールバックが開始され、最終的に更新失敗として戻ってしまう症状です。単発ではなく、1,000台規模の同一傾向として観測されると、ネットワーク・配布方式・端末固有のドライバーなど、疑うポイントが一気に増えます。

観測される症状	よくある見え方	現場で困るポイント
再起動後に更新が進み、7%前後で停止→ロールバック	「更新を構成しています」系の画面で一定割合で戻る	再試行しても同じ割合で失敗しやすく、台数が多いと復旧が追いつかない
CBS.logに特定INFのエラーが記録される	usb4devicerouter.inf と 0x8007065e が目立つ	「USB4ドライバーが原因」と誤認しやすい（しかし端末側でUSB4を使っていなくても出る）
更新が失敗する端末に偏りがある	同じ機種・同じ配布でも一部だけ失敗	端末差分（ログ破損・運用履歴）に原因が潜んでいると、表面の差分では追えない

CBS.logで「usb4devicerouter.inf」が犯人に見える理由

更新ロールバックを追うとき、多くの管理者が最初に見るのが CBS.log（Component Based Servicing のログ）です。CBS.logの場所は一般的に C:\Windows\Logs\CBS\CBS.log です。今回もCBS.log上では、USB4 Device Router ドライバーのINF（usb4devicerouter.inf）に対して 0x8007065e（ERROR_UNSUPPORTED_TYPE） が出ており、ドライバー更新キュー処理に失敗→ロールバック、という流れに見えます。

しかし、CBS.logは「更新処理の最終結果」を中心に書かれるため、そのINFが“失敗の起点”なのか、“連鎖の末に失敗が表面化した場所”なのかは、CBS.logだけでは判断しにくいことがあります。ドライバーの適用に関しては、より詳細に「ドライバーインストールの内部処理」を追えるログを併用すると、真因にたどり着ける確率が上がります。

（例）CBS.logで目立つパターン
- usb4devicerouter.inf に対して 0x8007065e
- driver update queue の処理で失敗
- rollback が開始

真因を特定する鍵：SetupAPI.dev.log の「Event Provider」エラー

今回、追加で確認したのが SetupAPI.dev.log（デバイス/ドライバーのセットアップログ）です。パスは一般的に C:\Windows\inf\setupapi.dev.log で、INF名やデバイスクラス、プロバイダー名で検索すると、ドライバー適用の詳細が追えます。

該当端末のSetupAPI.dev.logでは、usb4devicerouter.infの適用中に、Microsoft-Windows-USB-USB4DeviceRouter-EventLogs というイベントプロバイダーを追加しようとして失敗している痕跡が見つかりました。ポイントは「ドライバーそのもの」ではなく、イベントログへの登録処理で落ちている点です。

ログ	見つかるキーワード	意味合い
SetupAPI.dev.log	Add Event Provider / EventLogs / USB4DeviceRouter	ドライバーがイベントログのプロバイダー登録を試みている
SetupAPI.dev.log	0x0000065E	イベントプロバイダーの構成に失敗（内部的には「型が未サポート」扱い）
CBS.log	0x8007065e	ドライバー更新の大きな枠組みの中で失敗が表面化した結果

ここから読み解けるのは、次の流れです。

USB4 Device Router（usb4devicerouter.inf）の更新処理が走る
更新処理の一環で、イベントログに新しいイベントプロバイダー（イベントソース）を登録しようとする
ところが、端末側のイベントログ（特にセキュリティ／システム）に破損や不整合があり、登録処理が失敗する
結果としてドライバー更新全体がエラー扱いとなり、OS更新がロールバックする

「イベントログが壊れている」状態とは何か

厄介なのは、イベントビューアで見る限りは「ログが記録されているように見える」ケースがあることです。今回の端末群でも、セキュリティログやシステムログ自体は増えているのに、右クリックの操作（プロパティ変更、最大サイズ変更、ログの消去など）がうまくいかない、またはエラーになるという状態が確認されています。

この状態は、単純に「ログが大きすぎる」よりも、ログファイル（.evtx）やログ構成情報の破損を疑うべきサインです。イベントログはOSの多くのコンポーネントが依存しており、今回のようにドライバーがイベントを登録できないと、更新処理全体が止まることがあります。

実務で使える確認手順

同種の「一定割合でロールバックする」更新失敗では、原因が1つに見えて実際は複合要因、というケースが珍しくありません。台数が多い環境では、調査の順番を固定し、誰が見ても同じ結論に到達できる手順に落とし込むことが重要です。

ログ調査の最短ルート

ステップ	見る場所	狙い	具体的な見方
CBS.logで当たりを付ける	CBS.log	どの段階で失敗したか、どのコンポーネントが絡むかを把握	INF名・HRESULT/Win32エラー（例：0x8007065e）を抽出
ドライバー適用の内部を追う	SetupAPI.dev.log	ドライバー更新の“本当の失敗点”を特定	INF名やクラス名で検索し、「Add Event Provider」等の直前直後を読む
イベントログの健全性を確認	イベントビューア（Security/System）	ログが破損していないか、操作が可能かを確認	プロパティ変更、ログ消去、最大サイズ変更ができるか（できないなら要注意）
対処後に再インストール	Windows Update / CUの再適用	ロールバックが解消するかを検証	同じCUで通るか、SetupAPI.dev.logに再度エラーが出ないか

確認に使えるコマンド例（管理者権限）

GUI操作が難しい環境や、リモートでの一次切り分けではコマンドが役立ちます。以下は「ログの状態を読む」「ログの操作が通るか」を見るための例です。

REM ログ設定を表示（読み取りできるかの確認）
wevtutil gl Security
wevtutil gl System

REM ログのエクスポート（退避）
wevtutil epl Security C:\Temp\Security.evtx
wevtutil epl System   C:\Temp\System.evtx

上記の「表示」「エクスポート」ですらエラーになる端末は、ログ破損やアクセス権限の異常が疑われます（権限不足でも失敗するため、まずは管理者として実行できているかを確認してください）。

対処の考え方：ドライバー除外ではなくログ側を直す

結論から言うと、このケースで効果が高いのは usb4devicerouter.infを“避ける”ことではなく、ドライバーが登録しようとしているイベントログ（特にSecurity/System）を正常な状態に戻すことです。ドライバーを疑って手当てしても、根本がイベントログであれば同じ場所で失敗を繰り返します。

大量端末に効く：GPOでイベントログ設定を再定義して修復・再生成

多数端末に横断的に適用する場合、グループポリシー（GPO）でイベントログサービスの設定を配布し、ログの最大サイズ・保持方法などを再定義して、ログ構成を正しい状態に戻す方法が現実的です。現場ではこのアプローチで、7%でロールバックしていた端末群が更新完了するようになった、という結果が得られています。

代表的なポリシーの場所は次のイメージです（環境により表示名は多少異なります）。

コンピューターの構成 → 管理用テンプレート → Windows コンポーネント → イベントログサービス → Security
コンピューターの構成 → 管理用テンプレート → Windows コンポーネント → イベントログサービス → System

設定項目（例）	ねらい	設定の考え方	注意点
最大ログサイズ（KB）	ログ構成の再確立	組織のログ保持要件に合わせ、十分なサイズを明示	小さすぎると必要ログが早く上書きされる
ログの保持方法（上書き/保存/停止）	破損状態からの復旧	運用に合わせて統一し、端末ごとのブレをなくす	監査要件がある場合は必ず監査担当と整合を取る
ログのアクセス制御（必要に応じて）	操作不能の解消	読み取り・管理権限が意図せず壊れていないかも確認	不用意な変更はセキュリティ事故の原因になり得る

GPO適用後は、端末側で gpupdate /force を実行し、必要に応じて再起動します。その後、イベントビューアでSecurity/Systemログのプロパティ操作が可能になっているかを確認し、CUを再実行します。

REM ポリシー反映（例）
gpupdate /force

REM 反映後に再起動（必要に応じて）
shutdown /r /t 0

単体端末での即効策：ログを退避してクリアする

台数が少ない、あるいは緊急で1台だけ復旧させたい場合は、ログを退避（エクスポート）したうえでクリアする方法もあります。ただし、セキュリティログのクリアは監査・規程上の扱いが厳しいことが多いので、必ず組織ルールに従って実施してください（実施日時・理由・承認の記録が必要なケースがあります）。

REM まず退避（証跡として保存）
wevtutil epl Security C:\Temp\Security_before_fix.evtx
wevtutil epl System   C:\Temp\System_before_fix.evtx

REM クリア（組織ポリシーに従って実施）
wevtutil cl Security
wevtutil cl System

クリア後にログが再生成され、プロパティ操作も正常化するようであれば、CUの再インストールを試します。もし「クリア自体が失敗する」「プロパティ操作が復旧しない」場合は、ログファイルの破損がより深刻な可能性があります。

ログ操作ができないほど壊れている場合

Security/Systemのログが「見えているのに操作できない」「wevtutilでも失敗する」場合、オンライン状態での修復が難しいことがあります。現実的な選択肢は次のいずれかです。

GPOでログ設定を再定義し、構成情報側から正常化を促す（多数端末ではまずこれ）
復旧環境（WinREなど）でイベントログファイルを退避・再生成する運用を検討する（高難度・要手順化）
ディスク障害やファイルシステム不整合が疑われる場合は、先にストレージ健全性チェックを行う

イベントログの破損は、突然の電源断、ストレージの瞬断、過去のディスクエラー、バックアップ/セキュリティ製品の干渉など、原因が複数あり得ます。更新を通すことが当面のゴールでも、長期的には「なぜ破損したのか」を洗い出し、再発要因を潰すのが望ましいです。

「usb4devicerouter.infだけ更新から除外」は可能か

質問でよく出るのが「問題のドライバーだけ除外できないか」という点です。結論としては、累積更新プログラム（CU）の適用プロセスの中で扱われるOSコンポーネントのINFを、狙って1つだけ除外するのは現実的ではありません。一般にCUは複数のコンポーネント更新が一括で適用され、途中で1要素だけスキップする設計にはなっていません。

また「品質更新にドライバーを含めない」系のポリシー（ドライバー配信を抑制する設定）を使っても、このケースはイベントログ側の破損が本体なので、根本的な解決にはつながりにくいのが実情です。むしろドライバーを止めても、別のコンポーネントがイベント登録で同様に失敗する可能性があります。

やりたいこと	現実的な可否	コメント
CUの中の特定INFだけ除外	難しい	CUは一括適用が前提。除外よりも失敗原因（イベントログ）を直す方が確実
ドライバー更新全体を抑制	一時的には可能	環境によっては効果が限定的。セキュリティ/安定性の観点で長期運用は慎重に
イベントログを正常化	有効	今回の症状に対しては最短・最小の修正で改善しやすい

修復後に必ずやるべき確認

ログを直してからCUを再適用する前に、次の観点で「本当に復旧しているか」を確認すると、再ロールバックを減らせます。

イベントビューアでSecurity/Systemログのプロパティを開ける
最大サイズ変更、ログの消去が（権限の範囲で）実行できる
SetupAPI.dev.logで「Add Event Provider」周辺のエラーが再発していない
Windows Updateの再試行で、7%付近で止まらず完走する

確認項目	合格ライン	不合格なら
Security/Systemログのプロパティ操作	設定変更・クリアが可能	ログ破損が残っている可能性。GPO再適用や追加調査へ
SetupAPI.dev.logの再確認	Event Provider追加でエラーが出ない	イベントログ以外の要因（権限/製品干渉）も視野に
CUの再実行	再起動後にロールバックしない	ログ以外の破損（コンポーネントストア等）も併行調査

ログ修復でも改善しない場合の追加チェック

イベントログを正常化してもロールバックが止まらない場合、端末側に別の破損が重なっていることがあります。大量展開の前に、失敗端末の代表機で次の項目を順に潰すと、原因の切り分けが進みます。

チェック項目	コマンド例（管理者権限）	目的	現場での注意
コンポーネントストア/システムファイル修復	`DISM /Online /Cleanup-Image /RestoreHealth sfc /scannow`	OSの基盤ファイル破損を修復し、更新の前提条件を整える	実行時間が長い場合がある。まず代表機で所要時間と効果を確認
ディスク/ファイルシステムの健全性	`chkdsk /scan`	ログ破損の背景にあるI/Oエラーや不整合を検出	問題が出る端末が特定拠点に偏る場合、電源/ストレージ要因も疑う
Windows Updateキャッシュのリセット	`net stop wuauserv net stop bits ren C:\Windows\SoftwareDistribution SoftwareDistribution.old net start bits net start wuauserv`	ダウンロード済み差分の破損や不整合を排除	運用影響があるため、業務時間外での実施や代表機検証が安全
サードパーティ製品の干渉確認	（該当製品のログ/除外設定）	セキュリティ/バックアップ/ログ収集の介入で更新が失敗していないか確認	「同時期に製品更新が入った」「特定ポリシー配布後から増えた」など時系列で追う

この追加チェックは、イベントログ修復を否定するためではなく、同時多発の更新障害は複数の弱点が重なると顕在化しやすいための保険です。まずは「Security/Systemログの操作不能が復旧するか」を起点に、段階的に範囲を広げるのが効率的です。

再発防止のヒント：イベントログを“壊れる前に”検知する

イベントログの破損は、発生してから気付くと影響範囲が大きくなりがちです。とくに大規模環境では、次のような観点で予防線を張ると、更新障害の波及を抑えられます。

Security/Systemログの最大サイズ・保持方法をGPOで統一し、端末ごとのばらつきを減らす
ログの容量枯渇や書き込み失敗（イベントログサービスの警告）を監視し、閾値で通知する
突然の電源断が多い拠点では、ストレージ健全性（SMART/エラー）と併せて監視する
セキュリティ製品・バックアップ製品の更新が入ったタイミングで、イベントログ周りの挙動変化がないか確認する

よくある質問

USB4を使っていない端末でも、なぜusb4devicerouter.infが出るの？

USB4の機能を日常的に使っていなくても、OS側のコンポーネントとしてUSB関連のドライバーや構成要素が更新対象になることがあります。今回のポイントは「USB4デバイスがあるか」よりも、「ドライバー更新処理がイベントログへ登録しようとして失敗するか」です。

ロールバックが7%以外でも同じ原因になり得る？

割合そのものは環境や更新内容で変わり得ます。ただし、CBS.logで特定INFが悪者に見えても、SetupAPI.dev.logを追うと別の起点（イベントログ、権限、構成破損）が見つかることはあります。固定割合で戻るなら、まずは「同じ処理で毎回失敗している」可能性が高いので、SetupAPI.dev.logを必ず確認してください。

セキュリティログのクリアができない（できてはいけない）環境では？

監査要件が厳しい組織では、セキュリティログのクリアは避けるべきです。その場合は、GPOでログ設定を整えて正常化を促す、退避を徹底する、承認フローを整備するなど、組織ルールに合わせた手順化が必要です。更新を通すことより、監査要件を守ることが優先される場面もあるため、必ず関係部門と合意を取って進めてください。

まとめ

Windows 11 23H2／24H2で、2025年4〜6月のCUが7%前後でロールバックする症状が大量発生することがある
CBS.logではusb4devicerouter.infが原因に見えるが、SetupAPI.dev.logを見るとイベントプロバイダー登録失敗が起点になっている場合がある
真因がイベントログ（Security/System）の破損なら、ドライバー除外ではなくログの修復・再生成が最短ルート
大規模環境ではGPOでログ設定を再定義し、端末群をまとめて正常化すると展開しやすい

この記事を書いた人

佐藤健司

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