MENU

Windows 10 22H2のKB5060533で再起動要求が終わらない原因と対処法｜DISM /OnlineとRebootPending整理

Windows10

Windows 10 22H2 に「2025-06 Cumulative Update for Windows 10 Version 22H2 for x64-based Systems (KB5060533)」を適用した後、更新は進んでいるはずなのに「再起動してインストールを完了してください」が何度も出続ける――。本記事では、再起動要求が終わらない典型パターンと、DISM /Online を軸に“戻せる手順”で解決へ進める方法を整理します。

目次

KB5060533 適用後に「再起動して完了」がループする症状とは

今回の症状は、見た目としてはシンプルです。

  • Windows Update で「再起動してインストールを完了してください」が繰り返し表示される
  • 再起動しても同じメッセージが戻ってくる（完了しない）
  • MSサイトから KB を手動ダウンロードして入れ直しても改善しない
  • 更新プログラムの修復、MECM（Config Manager）再インストール、クライアントアクション総当たりでも効果がない

重要なのは、「更新のインストールそのもの」が失敗しているケースだけでなく、「更新完了フラグの後始末」が残っているケースでも同じ見え方になる点です。つまり、KB5060533 が本当に未完了なのか、完了しているのに再起動待ち判定だけが消えないのかを分けて考える必要があります。

なぜ再起動要求が終わらないのか

Windows 10 の更新（特に累積更新）は、内部的に「コンポーネントベース サービス（CBS）」や Windows Update の仕組みを通して段階的に処理されます。処理の途中や、ファイル入れ替えが次回起動時に必要な状態になると、OS は「再起動が必要」と判断します。

ところが何らかの理由で、その判断材料（いわゆる再起動待ちフラグ）が消えないと、OS は“まだ更新が終わっていない”と認識し続けるため、再起動要求がループします。よくあるパターンは次の3系統です。

系統起きていること見え方代表的な対処
CBS（保留中の操作）更新の「後半作業」が保留になったまま再起動しても完了しない／更新が進まないDISM の RevertPendingActions、コンポーネント修復
レジストリ（再起動待ちフラグ）更新済みでも「再起動必要」の印が残るWindows Update の表示だけがしつこく残るRebootPending / PendingFileRenameOperations の確認・整理
管理基盤（MECM 側の判定）MECM が再起動必須状態と判定し続けるSoftware Center やクライアントが再起動を促し続けるクライアントログで再起動判定の根拠を特定、再評価

今回の相談内容（手動インストールし直しても変わらない、修復や再インストールも効かない）からは、CBS の保留状態か、再起動フラグの残留が特に疑わしい状況です。

作業前に必ず押さえるポイント

トラブル対応は「直す」よりも「戻せる」ことが重要です。再起動要求ループの対応では、次を先に実施してください。

  • 可能なら復元ポイントを作成（またはバックアップ）
  • BitLocker 利用環境は回復キー確認（適用・回復動作の想定）
  • MECM 管理下の端末は、運用ルール（変更申請、検証端末、手順書）に沿って実施
  • レジストリ作業が必要になった場合に備え、該当キーのエクスポート手順を準備

特にレジストリは“効くことがある”一方で“事故りやすい”領域です。いきなり削除に入らず、まずは DISM で正攻法の回復から進めるのが安全です。

まず最初に：KB5060533 が「実際に入っているか」を確認する

同じ「再起動要求ループ」に見えても、根本原因が違うことがよくあります。最初に次の切り分けを行います。

更新履歴とインストール状態のチェック

  • 「設定」→「更新とセキュリティ」→「Windows Update」→「更新の履歴を表示する」
  • KB5060533 が「正常にインストールされました」なのか、「失敗」なのか、「保留中」なのか

加えて、コマンドでインストール済み更新を確認するのも有効です。

wmic qfe list brief /format:table

ここで KB5060533 が確認できるのに再起動要求が残る場合は、“更新は入っているが、再起動判定だけが残っている”方向に寄ります。

再起動待ち判定を“どこが出しているか”を意識する

Windows Update の画面だけが再起動を要求しているのか、Software Center（MECM）が要求しているのかで、見るべきログが変わります。混ざっているケースもあるため、次のように整理すると迷いにくくなります。

再起動要求の出どころ画面の例まず見る場所次の一手
Windows Update設定画面で「再起動して完了」更新履歴、CBS/DISMログDISM /RevertPendingActions、WUリセット
MECM（ConfigMgr）Software Center が再起動を要求CCMログ（UpdatesDeployment.log 等）再起動判定の根拠（Install 状態/評価）を特定
両方どちらも再起動要求両方のログとレジストリOS側フラグ→管理側の順で整理

対処手順：推奨順（安全度が高い順）

ここからは、実務で事故が起きにくい順に並べた手順です。いきなり強い操作（レジストリ削除など）に行かず、上から順に“消えるかどうか”を確認してください。

DISMで保留中の更新（Pending Actions）をクリアする

今回の質問の核心はここです。症状としては、Windows側が「更新がまだ完了していない」と認識し続けている状態が疑われます。特に累積更新で起きやすいのが、CBS の「保留中の操作」が残ったままになるケースです。

エラー87の理由：/Image は“稼働中OS”に使えない

質問内容では次のコマンドを実行し、エラー 87 になっています。

DISM /Image:C:\ /Cleanup-Image /RevertPendingActions

/Image は“オフラインの Windows イメージ（起動していない OS）”を対象にするオプションです。稼働中の Windows に対しては使えないため、エラー 87（パラメーターが違う）が出やすい流れになります。

稼働中のOSに対する正しい実行例（/Online）

管理者権限のコマンドプロンプトで、次を実行します。

DISM /Online /Cleanup-Image /RevertPendingActions
  • 実行後、PC を再起動し、再起動要求が止まるか確認します。
  • 再起動要求が止まった場合、CBS の保留操作が原因だった可能性が高いです。

うまくいかないときの見方（ログ）

成功/失敗の理由はログに出ます。次のファイルを確認してください。

  • C:\Windows\Logs\DISM\dism.log
  • C:\Windows\Logs\CBS\CBS.log

ログを見るときは、実行した時刻周辺に絞り込み、RevertPendingActions、Error、Failed、HRESULT などのキーワードで追うと原因が見つけやすくなります。

追加の修復：コンポーネントストアとシステムファイルを整える

/RevertPendingActions は強力ですが、環境によっては「保留は戻せたが、整合性が崩れて別の再起動判定が残る」ことがあります。再起動要求がしつこい場合は、次の定番修復をセットで実施すると改善率が上がります。

コンポーネントストア修復（RestoreHealth）

DISM /Online /Cleanup-Image /RestoreHealth

システムファイル検査（SFC）

sfc /scannow

DISM → SFC の順で実行すると、部品（コンポーネントストア）を整えてからシステムファイルを修復できるため、手戻りが減ります。

再起動要求フラグ（レジストリ）を確認・整理する

DISM で解消しきれない場合、レジストリ上の「再起動待ち」フラグが残っていることがあります。ここは効きやすい反面、ミスると影響が大きいので、手順を省略せず慎重に進めます。

代表的な確認箇所

次のキーや値が存在すると、Windows は「再起動が必要」と判断しやすくなります。

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations

環境によっては、次も再起動待ち判定に関係します（存在したら“原因候補”として扱います）。

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired

安全な進め方：削除の前に「バックアップ」と「理由の確認」

推奨は次の順です。

  1. レジストリエディター（regedit）で該当キーを右クリックし、エクスポートして退避
  2. 該当キー／値が「最近の更新に紐づく可能性が高いか」を判断（更新直後からループしたか、他の更新で長期間残っていないか）
  3. 削除する場合でも、可能なら“削除”ではなく一時退避（名前変更）を検討

実施例：RebootPending の整理

RebootPending はキー自体の存在が判定材料になることがあります。

  • キーが存在する：再起動待ちとして扱われやすい
  • キーが存在しない：少なくともこの判定要因は消える

バックアップ後に、RebootPending キーを削除または一時退避し、再起動して挙動を確認します。

実施例：PendingFileRenameOperations の整理

PendingFileRenameOperations は、次回起動時にリネーム／削除するファイル一覧を保持する値です。更新処理でここに項目が残ると、再起動要求が継続することがあります。

  • 値が存在し、内容が大量または明らかに古い参照で埋まっている場合は要注意
  • 内容が空に近いのに存在だけしているケースでも、判定が残ることがあります

この値を扱う場合は、“内容を控える（エクスポート）→必要性を判断→整理”の順が無難です。

PowerShellで「存在確認」だけを先に行う（読み取り中心）

いきなり削除せず、まずは存在確認を自動化すると作業が安定します。管理者権限の PowerShell で次を実行します。

$paths = @(
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending',
  'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager',
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
)

foreach ($p in $paths) {
if (Test-Path $p) {
Write-Host "[FOUND] $p"
} else {
Write-Host "[NONE ] $p"
}
}

# PendingFileRenameOperations の存在確認（値）

$sm = 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager'
try {
$v = (Get-ItemProperty -Path $sm -Name 'PendingFileRenameOperations' -ErrorAction Stop).PendingFileRenameOperations
Write-Host "[FOUND VALUE] PendingFileRenameOperations"
Write-Host "Count: $($v.Count)"
} catch {
Write-Host "[NONE VALUE] PendingFileRenameOperations"
}

これで「どこに再起動待ちの根拠が残っていそうか」を掴み、必要な箇所だけを慎重に処理できます。

Windows Update コンポーネントをリセットする（表示・判定のねじれ対策）

DISM とレジストリ整理で改善しない場合、Windows Update 側のキャッシュや判定情報が不整合を起こしていることがあります。更新の配布経路が MECM であっても、OS 側のコンポーネントが絡むため、リセットが効くことがあります。

基本方針

  • 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

その後、Windows Update の「更新プログラムのチェック」を実行し、再起動要求が残るか確認します。MECM 管理下なら、クライアント側で評価が走るタイミング（ポリシー取得や更新スキャン）も合わせて確認します。

KB5060533 をアンインストールして再適用する（必要に応じて）

「KB が壊れて入っている」「適用状態の整合性が崩れている」場合、いったん戻して入れ直すのが近道になることがあります。特に同一端末だけが再起動要求ループしている場合は有力です。

GUIでの手順

  • 「プログラムと機能」→「インストールされた更新プログラム」
  • KB5060533 を探してアンインストール
  • 再起動
  • MECM または Windows Update、あるいは手動で再インストール

コマンドでの確認・アンインストール例

環境により可否はありますが、代表例としては次のような確認ができます。

wusa /uninstall /kb:5060533

アンインストールが通らない／対象が見つからない場合は、そもそも「KB は入っていない」「置換されている」「別の更新に統合されている」など、前提がズレている可能性があります。その場合は更新履歴と wmic qfe の結果を突き合わせ、状態把握からやり直すのが安全です。

MECM（Config Manager）環境で特に見るべきポイント

相談内容では MECM の再インストールやクライアントアクション総当たりも効果がなかったとのことですが、MECM が絡む場合は「再起動要求の根拠」がどこにあるかをログで特定しないと堂々巡りになりがちです。

まず確認したいログ

端末側のログは通常、次のフォルダにあります。

  • C:\Windows\CCM\Logs
目的ログ例見るポイント
更新配布・インストールの流れUpdatesDeployment.logKB5060533 の評価結果、再起動要求の発生タイミング
更新スキャン/評価WUAHandler.logWindows Update Agent との連携、スキャン結果のエラー
実行/適用の詳細UpdatesHandler.logインストール完了・保留・再起動コードの扱い
再起動制御（環境により）関連ログ（環境依存）再起動が“必要”と判定され続ける理由

ポイントは、「OS が再起動待ち」なのか、「MECM が再起動待ち」なのかをログ上で切り分けることです。OS 側の RebootPending が消えているのに MECM が再起動を要求するなら、MECM の検出ルール（適用判定）や再評価の結果に原因が残っている可能性があります。

ありがちな落とし穴：OS側のフラグが残っているとMECMが“永遠に要求”する

MECM は最終的に OS の状態（再起動待ち）も参照します。つまり、MECM の作業をどれだけ頑張っても、OS 側の RebootPending / PendingFileRenameOperations が残っている限り、再起動要求は消えないことがあります。手順としては、まず OS 側を正しい方法（DISM /Online）で整え、その後に MECM の評価・スキャンを回すのが王道です。

それでも直らない場合に検討する「もう一段深い」対処

ここまでやって改善しない場合は、「更新が詰まっている原因」がより深い層（CBS の破損、ストレージ障害兆候、セキュリティソフト干渉、更新前提条件の崩れ）にある可能性があります。次の順で検討します。

WinSxS の保留ファイル・CBSの状態を疑う

  • C:\Windows\WinSxS 配下に保留ファイル（例：pending 関連）が残っていないか
  • C:\Windows\Logs\CBS\CBS.log に同じエラーが繰り返し出ていないか

この領域は手動操作の難易度が高いので、ログから根拠を掴んだ上で、組織の標準手順（修復インストール、保守計画）に沿って進めるのが安全です。

回復環境（WinRE）でのオフライン修復を使う

稼働中のOSに対しては /Online を使いますが、起動が不安定・CBS が強く壊れている場合は、回復環境からオフラインで /Image を使うシナリオがあります。

ただし、これは環境差が大きく、誤ると復旧が難しくなるため、業務端末では検証端末での再現・手順確認を前提にしてください。

最終手段：修復インストール（インプレースアップグレード）

更新基盤が破損している場合、修復インストールで OS のコンポーネントを健全化し、更新の詰まりを解消できることがあります。アプリやデータを保持したまま実行できる構成もありますが、企業端末は運用ルールが絡むため、標準手順に従って実施してください。

現場で使える「チェック項目」と「実施コマンド」早見表

目的やることコマンド／場所期待する変化
保留中操作の解消Pending Actions を戻すDISM /Online /Cleanup-Image /RevertPendingActions再起動要求が止まる、更新が完了扱いになる
更新基盤の健全化コンポーネント修復DISM /Online /Cleanup-Image /RestoreHealth更新・修復の失敗が減る
OSファイル修復システムファイル検査sfc /scannow破損修復、予期せぬ不具合の連鎖を止める
再起動フラグの確認RebootPending 等の存在確認regedit／PowerShell の Test-Path“なぜ要求されているか”の根拠が見える
WU判定のリセットSoftwareDistribution等を退避net stop→ren→net startスキャン結果や判定のねじれが改善
配布の再構築KB の入れ直し更新のアンインストール→再インストール適用状態の整合性が回復

よくある質問

DISM /RevertPendingActions は“やりすぎ”になりませんか？

状況によりますが、この操作は「保留中の更新処理を取り消す」ため、更新が完了しないループで詰まっている場合には有効です。一方で、途中まで進んでいた更新を差し戻すことにもなるため、業務端末では適用タイミング（保守時間）と影響範囲を確認した上で実施するのが安全です。

レジストリのキーは削除すれば必ず直りますか？

直ることもありますが、万能ではありません。キーはあくまで「再起動が必要」と判断する材料の一部で、根本が CBS の破損や更新失敗なら再生成されることもあります。だからこそ、DISM → 修復 → それでも残る場合にレジストリの順が安全です。

MECMの再インストールまでやったのに直らないのはなぜ？

OS 側が再起動待ちと判断している限り、MECM 側の操作は“再起動が必要”という結論を上書きできないことがあります。また、検出ルールや評価結果の更新タイミングが合っていないと、直っていても「要求だけが残る」ことがあります。OS 側フラグとログの突合が近道です。

まとめ：KB5060533 の再起動要求ループは「保留操作」か「再起動フラグ残留」が本命

  • 再起動要求が終わらないときは、まずKBが入っているか／失敗しているかを切り分ける
  • 相談内容の流れでは、保留中の更新（Pending Actions）が残っている可能性が高い
  • /Image:C:\ ではなく、稼働中OSにはDISM /Online /Cleanup-Image /RevertPendingActionsが基本
  • 改善しない場合は、RebootPending / PendingFileRenameOperations など再起動フラグを“バックアップ前提”で確認・整理
  • 併せて、更新履歴・CBS/DISMログ・MECMログ（C:\Windows\CCM\Logs）を確認すると、再発防止の原因特定がしやすい
Windows10
DISM Windows Update MECM KB5060533 RebootPending

この記事を書いた人

佐藤健司のアバター 佐藤健司

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

関連記事

コメント

コメントする

目次