← システム思考に戻る

Reset Windows Update:RWUのMSP向け決定版ガイド

windows-updatemsp-toolsrmm-automationdiagnosticspowershell

Manuel GilのWindows Updateリセットスクリプトは、2023年3月にアーカイブされる前に50万ダウンロードを超えた。Dev-C++の後継 — Reset-Windows-Update-Tool、GitHubで513スター — も2026年1月16日にアーカイブされた。何年もの間、これらはMicrosoftのトラブルシューターが肩をすくめて「問題を特定できませんでした」と言ったときにシステム管理者が頼るツールだった。

もうなくなった。そして何も代わりが出てこなかった。

今日「reset Windows Update」で検索すると、消費者向けガイドがたくさん見つかる。設定パネルのスクリーンショット。「トラブルシューティングをクリックして、追加のトラブルシューターをクリック。」皮肉なことに、そのトラブルシューター自体がMSDTの廃止とともに非推奨になっている。Microsoft自身が自分の修復ツールを廃止しているんだ。

何百ものエンドポイントを管理するMSP技術者にとって、ギャップはもっと深刻だ。RMMを通じてサイレントに実行できるものが必要だ。チームが3週間かけて調整したIntuneリング構成を破壊しないものが必要だ。誰も座っていないGUIダイアログボックスではなく、構造化された終了コードを出力するものが必要だ。

だからRWUを作った。Windows Updateの「裏技」じゃない。安全なデフォルト、オプトインの危険操作、自動化用のCLI終了コード、AI分析用に構造化された診断出力を備えた、14ステップのレビュー可能で可逆的な技術者ワークフローだ。単一の.cmdファイル。GPL-3.0。インストーラーなし、テレメトリなし、永続化なし。

RWU Reset and Repair Utility for Windows Updateのターミナルインターフェース

3つの障害カテゴリ

ほとんどのWindows Updateガイドは診断を飛ばして、いきなり修正に入る。サービスを停止、SoftwareDistributionを削除、再起動、あとは祈る。これが効くのはだいたい3分の1の確率。残りの3分の2は、20分を無駄にして、おそらく事態を悪化させている。

問題は、Windows Updateの障害は1つの問題じゃないということ。3つだ。

Windows Updateが2つの累積更新プログラムでインストールエラー0x800f0922を表示
すべてのシステム管理者が見覚えのある画面 — 2つの累積更新プログラムでの0x800f0922。

カテゴリ1:ローカル状態の破損。 SoftwareDistributionフォルダが腐敗している。Catroot2にハッシュの不一致がある。BITS転送キューがデッドロックしている。典型的なコード:0x80070002、0x80073712。マシンの更新パイプラインが自身の古いデータで詰まっている。ローカルリセット — サービス停止、フォルダのリネーム、DLLの再登録 — で確実に解消できる。

カテゴリ2:ポリシーの競合。 これがMSPを悩ませるやつだ。かつてWSUSサーバーを指していたマシンにまだレジストリのクッキーが残っている。Intune管理デバイスに、ドメイン参加時の古いGroup Policyの上にWindows Update for Businessのリング設定が競合して重なっている。症状はカテゴリ1と同じに見える。修正方法はまったく違う — ポリシーの状態をクリアせずにカテゴリ1の修正を適用すると、1週間後にまた同じ問題が起きる。

カテゴリ3:Microsoftが何かを壊した。 2026年5月のKB5089549は、累積更新プログラムが多くのマシンが持っていた以上のEFIパーティション容量を必要としたため、0x800f0922エラーを引き起こした。2026年4月のKB5082063は、Privileged Access Managementを実行しているDomain ControllerでLSASSをクラッシュさせ、Microsoftの緊急アウトオブバンドパッチKB5091157を必要とする無限再起動ループを引き起こした。ローカルリセットスクリプトでは修正できない。正しいパッチ、パーティションのメンテナンス、または回復環境でのブートが必要だ。

これらのカテゴリを混同する危険は現実にある。「すべてのサービスを停止してレジストリポリシーを含むすべてを削除する」アプローチはカテゴリ1を修正する。カテゴリ2を壊滅的に損傷する — 管理デバイスを更新管理リングから外してしまったんだ。そしてカテゴリ3では、Domain Controllerが本番環境で再起動ループしている間に貴重な時間を浪費する。

RWUのアーキテクチャはこれらのカテゴリに直接対応している。カテゴリ1の修復がデフォルト。カテゴリ2の操作(ポリシー削除、SDDLリセット)は明示的なオプトインが必要。カテゴリ3は診断されて「このツールの範囲外 — 次に調査すべきこと」としてフラグが立てられる。

ツールの全体像:誰が何をするか

Windows Update修復ツールの現状はこうだ:

ツールステータス個別ステップインターフェースAI対応ログ?ハッシュ検証?
RWUアクティブはい — 14ステップTUI + CLI (0/1/2)はいはい (SHA256)
Microsoft WU TroubleshooterMSDTとともに非推奨部分的GUIのみいいえN/A
ManuelGil Reset-Windows-Update-Tool2026年1月アーカイブはいTUIメニューいいえいいえ
ManuelGil Script-Reset-WU2023年3月アーカイブはいなしいいえいいえ
ChrisTitusTech/winutilアクティブいいえGUIいいえいいえ
PSWindowsUpdateアクティブはいCmdletいいえモジュール署名

WinUtilは特筆に値する。約55,000スターで、Chris Titus Techのツールは最も目立つオープンソースWindowsユーティリティだ。ブロートウェアの除去とシステム構成には優れている。しかしUpdatesモジュールは、Default、Security-only、Disabledの更新ポリシーを切り替えるだけだ。壊れたWindows Updateコンポーネントを修復しない。0x80073712のコンポーネントストア破損にWinUtilを推奨する人がいたら、更新設定と更新修復を混同している。

Manuel Gilのツールは本物だった。.batスクリプトはシンプルで効果的 — サービス停止、フォルダリネーム、DLL再登録。まさにMicrosoftが文書化していたKB971058ワークフローだ。しかしどのバージョンにもRMM終了コード、AI対応診断、安全な操作と危険な操作の分離がなかった。毎回すべてが順番に実行された。

RWUが実際にやること

14ステップのアーキテクチャ

RWUのステップは論理的なフェーズにグループ化されている:

ステップ0 — 診断。 何かが変更される前に、RWUはシステム状態をキャプチャする:OSのバージョンとビルド、wuauserv/cryptSvc/bits/msiserver/appidsvcのサービスステータス、EFIパーティションを含むディスク容量、CBS.logの末尾100行(数百MBの全ファイルではなく)、最近のWindows Updateイベントログエントリ。この出力はAI分析用に設計されている。

ステップ1-2 — サービス停止。 Windows Update、暗号化サービス、BITS、Windows Installer、Application Identity。RWUは強制終了ではなくクリーンな停止を待つ。これによりコンポーネントストアのデータ破損を防ぐ。

ステップ3-5 — クリーンアップと再構築。 SoftwareDistributionはタイムスタンプ付きでリネームされる — SoftwareDistribution.bak.20260522-143022 — ツールを2回実行しても既存の.bakフォルダで失敗しない。Catroot2も同じ処理を受ける。次に、コアのWindows Update DLLが再登録される:atl.dllからwuwebv.dllまで34のDLL、更新と暗号化パイプライン全体をカバー。

ステップ6-7 — 危険(明示的オプトインのみ)。 ステップ6はHKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate配下のWindows Updateレジストリポリシーをエクスポートしてから削除する。ステップ7はBITSとWUサービスのセキュリティ記述子をWindowsのデフォルトにリセットする。どちらもデフォルトでオフ。どちらもTUIトグルまたはCLIフラグ/policy/sddlで明示的にオプトインが必要。

ステップ8 — システムファイル修復。 sfc /scannowの後にDISM /Online /Cleanup-Image /RestoreHealth。コンポーネントストア破損に対するワンツーパンチ。RWUは診断レビュー用に出力をキャプチャする。

ステップ9-10 — ネットワークスタック。 Winsockリセットとプロキシ設定のクリア。更新の失敗が実際にはネットワークスタックの破損であるケースをキャッチする。

ステップ11-14 — 完了。 停止したサービスの再起動、更新検出サイクルの強制実行、イベントログのダンプ、構造化された終了コード付きのサマリー生成。

安全なデフォルト:ステップ6と7がロックされている理由

これが最も大切にしているアーキテクチャ上の決定だ。

ステップ6はWindows Updateのレジストリポリシーを削除する。スタンドアロンの家庭用PCなら問題ない。Intune管理デバイスでは、Windows Update for Businessリングのメンバーシップを破壊してしまう。デバイスは「パイロットリング、7日間の延期」から「非管理、Microsoftが今すぐプッシュするものをインストール」に変わる。まだWSUSサーバーを指しているマシンでは(そう、WSUSは2024年9月に非推奨になったが、多くの環境ではまだ運用されている)、WSUSポインターが削除され、マシンがMicrosoft CDNから直接更新をプルし始める。

ステップ7はサービスのセキュリティ記述子をリセットする。セキュリティツールが意図的にこれらの記述子を強化したロックダウンされたエンタープライズエンドポイントでは、そのセキュリティ態勢を壊すことになる。

TroubleChuteの更新ガイドはデフォルトでポリシーをリセットする。Manuel Gilのツールはステップごとのオプトインの概念なしにすべてを順番に実行した。RWUは安全な操作と破壊的な操作を分離する。デフォルトは安全。核オプションは利用可能 — でも明示的に要求する必要がある。

はじめ方

1行:

irm matbanik.info/rwu | iex

何が起こるか:rwu.ps1ランチャーがmatbanik.infoからダウンロードされ、GitHubからRWUの最新リリースを取得し、SHA256ハッシュを検証し、Reset_WindowsUpdate.cmdを抽出して、UAC昇格プロンプトで実行する。ハッシュが一致しなければ、何も実行されない。

RWUランチャーがSHA256ハッシュを検証、TUIメインメニューの横
左:ランチャーが実行前にSHA256を検証。右:安全なデフォルト設定のTUIメニュー — ステップ6/7はオフ。

信頼モデル:GitHub上のGPL-3.0ソースコード。実行前のSHA256検証。単一の.cmdファイル — インストーラーなし、永続化なし、テレメトリなし。エンドポイントに触れる前にすべてのコード行を監査できる。

ここで触れなければならないこと。Microsoftのセキュリティブログは2025年8月、PowerShellのirmiexコマンドレットがClickFixソーシャルエンジニアリングキャンペーンで「非常に多く見られる」とフラグを立てた。脅威アクターがユーザーを騙してirm 悪意のあるサイト.com | iexを実行させれば、ゲームオーバーだ。

RWUのハッシュ検証はこれに直接対処する。ランチャーは盲目的にダウンロードして実行しない。ダウンロードし、公開されたチェックサムに対してSHA256を検証し、一致した場合のみ実行する。侵害されたダウンロードパスはハッシュの不一致を生み、ランチャーは中止する。

irm | iexにまだ不安があるなら — もっともだ — GitHub Releasesから直接ダウンロードすればいい。.cmdファイルがそこにある。自分でハッシュを検証してくれ。

エラーコードとその意味

Windows Updateのエラーコードは16進数の苦痛だ。最も一般的なものと、実際に何が壊れているか、RWUのどのステップが対処するかのマッピングがここにある:

エラーコード意味根本原因RWUステップ
0x80070002ファイル/レジストリキーが見つからないSoftwareDistributionの破損ステップ3-5
0x800f0922CBSステージング失敗EFIパーティション容量枯渇(2026年5月 KB5089549)ステップ0で診断;ステップ3-5でステージング
0x80073712コンポーネントストア破損WinSxSのマニフェスト不一致ステップ8(DISM)
0x800f081fDISMソースファイルが見つからない利用可能な修復ソースなしステップ8、/Source:wim付き
0x80240069再起動保留中前の更新が再起動を必要としているステップ11-14
0x8024402cWUサーバーに到達できないネットワークスタックまたはプロキシの問題ステップ9-10
0x80244022サーバー利用不可Microsoft CDNがブロックまたはダウンRWUが診断;ファイアウォール/プロキシの問題
0x8024401c接続タイムアウトプロキシまたはレイテンシの問題ステップ9-10;ファイアウォールルールが必要かも

0x800f0922コードは注目に値する。2026年5月のKB5089549は、累積更新プログラムが多くのマシンが持っていた以上のEFIパーティション容量を必要としたため、広範囲にこのエラーを引き起こした。MicrosoftはEFI空き容量が10MB以下のマシンがインストールの35%でロールバックループに陥ることを確認した。RWUのステップ0診断は低いEFI容量をフラグする。パーティションのサイズ変更はできない — しかし少なくとも、ソフトウェアの破損ではなくハードウェアの制約を追っていることがわかる。

RMM統合:MSP向けCLIモード

TUIはインタラクティブなトラブルシューティングに便利だ。フリートデプロイにはCLIが必要。

終了コード:

  • 0 — 成功。すべてのステップがエラーなく完了。
  • 1 — 失敗。少なくとも1つのステップでエラー発生。ログを確認。
  • 2 — 使用法エラー。引数が不正またはヘルプが要求された。

CLIフラグ:

フラグアクション
/diag診断のみ(ステップ0)。変更なし。
/reset完全な安全リセット(ステップ1-5、8-14)。
/step N特定のステップを実行。有効:0、1-2、3、4、5、6、7、8、9-10、11-14。
/policyステップ6を有効化(ポリシー削除)。明示的オプトイン。
/sddlステップ7を有効化(SDDLリセット)。明示的オプトイン。
/logdir "パス"ログを特定のディレクトリに出力。

サイレントデプロイ:

Reset_WindowsUpdate.cmd /reset /logdir "C:\Temp\RWU"

これは安全なリセットシーケンスを実行し、C:\Temp\RWUにログを書き込む。終了コードがRMMに成否を伝える。

NinjaRMM統合例:

$logDir = "C:\Temp\RWU"
$result = Start-Process -FilePath "C:\Tools\Reset_WindowsUpdate.cmd" `
  -ArgumentList "/reset /logdir $logDir" -Wait -PassThru

# コンピュータ名プレフィックス付きでログを中央共有にコピー
$centralShare = "\\SERVER\RWU-Logs"
Get-ChildItem -Path $logDir -Filter "*.log" | ForEach-Object {
    $destName = "$($env:COMPUTERNAME)_$($_.Name)"
    Copy-Item -Path $_.FullName -Destination "$centralShare\$destName" -Force
}

if ($result.ExitCode -eq 0) {
    Ninja-Property-Set rwuStatus "Success"
} elseif ($result.ExitCode -eq 1) {
    Ninja-Property-Set rwuStatus "Failed - Check logs"
    # チケット作成
} else {
    Ninja-Property-Set rwuStatus "Usage error"
}

ログ収集ステップはRWUが生成したすべての.logファイルを取得し、マシンのCOMPUTERNAMEを前置して中央UNC共有にコピーする。フリート全体の実行後、\\SERVER\RWU-LogsにはFRONT-DESK-PC_RWU_20260522.logDC01_RWU_20260522.logなどが含まれる — すべて1か所に。\\SERVER\RWU-Logsを自分のネットワークパスに置き換えてくれ。

同じパターンはDatto、ConnectWise Automate、PowerShellスクリプティングと終了コードパースをサポートする任意のRMMで機能する。

/diagフラグは過小評価されている。Patch Tuesdayの前にフリート全体で実行する。出力をパースする。累積更新プログラムをプッシュするに、EFI容量が少ないマシン、停止しているサービス、古いポリシークッキーを特定する。プリフライト診断は障害後の修復より多くの時間を節約する。

RWUがCLI診断モードで構造化された出力を表示
RWU /diagモード — 診断のみ、変更なし。ログはAI分析に対応。

AI対応診断

CBS.logはWindows Updateのデバッグが住む場所だ。デバッグキャリアが死ぬ場所でもある。ファイルは日常的に数百MBの粒度の細かいサービシングテレメトリに成長する。その量の中から実際の障害を見つけるのは、経験豊富な技術者でも骨が折れる。

RWUのステップ0は構造化された診断スナップショットをキャプチャする — 関連データをAI消費用に事前処理して:

=== RWU Diagnostic Output ===
OS: Windows 11 Pro 24H2 (Build 26100.1742)
Disk C: 47.2 GB free of 237.8 GB
EFI Partition: 89 MB free of 100 MB  [WARNING: LOW SPACE]

Service Status:
  wuauserv: Running
  cryptSvc: Running
  bits: Running
  msiserver: Stopped

CBS.log tail (last 100 lines):
2026-05-22 14:23:17, Error CBS  Failed to resolve package:
  Package_for_KB5089549~31bf3856ad364e35~amd64~~26100.1742.1.0
  [HRESULT = 0x800f0922]

これをChatGPT、Claude、またはCopilotにこのプロンプトと一緒にコピーする:

You are a Windows Update diagnostic expert. Below is the log output
from RWU (Reset Windows Update utility). Analyze it and respond with
a "Bottom Line" summary using exactly these questions:

- What went wrong?
- Is the hard drive failing?
- Is my data safe?
- Can it be fixed?
- What caused this?
- What's the risk if I wait?

Keep answers to 1–2 sentences each. Use plain language a non-technical
client would understand. Bold Yes/No answers where applicable.

RWU log output:
<paste log here>
RWU診断ログからAIが生成したBottom Lineサマリー
RWUログを貼り付ければ、クライアント向けの「Bottom Line」サマリーが得られる — チケットにそのまま使える。

「Bottom Line」フォーマットが時間の節約だ。チケットやメールにそのまま貼り付けられるクライアント向けサマリーが手に入る — 翻訳不要。正確性を確認して、送信。AIにコミュニケーションパターンを教えることやAIの出力を正確性で評価することについて、関連記事でもっと書いている。

重要な洞察:200MBのCBS.logをLLMに送るのはコストが高く、通常コンテキスト制限を超える。事前処理された100行の関連情報を送るのはほぼ無料で、AIに必要なものを正確に与える。

RWUが助けにならない場合

正直な限界は偽の自信より多くの信頼を築く。RWUが修復できないものはこれだ:

EFIパーティションの枯渇。 ステップ0が診断する。RWUはパーティションをリサイズできない。EFIパーティションを拡張するにはdiskpartまたはパーティションマネージャーが必要。あるいはbcdboot/bcdeditで古いブートエントリをクリーンアップする。

Domain ControllerでのLSASS再起動ループ。 2026年4月のKB5082063はローカルツールが実行される前にLSASSをクラッシュさせる。回復環境を通じてMicrosoftのアウトオブバンドパッチKB5091157を適用する必要がある。

Windows 10 ESU登録の失敗。 Extended Security Updateのライセンスが検証されていなければ、更新はライセンスエラーで失敗する。これはライセンスの問題であり、WUコンポーネントの問題ではない。

ネットワークレベルのブロック。 ファイアウォールがMicrosoft CDNエンドポイントをブロックしている場合、ローカルネットワークスタックのリセットは助けにならない。スタックは問題ない。ポリシーがトラフィックをブロックしている。

回復不能なコンポーネントストアの損傷。 DISM /RestoreHealthが「ソースファイルが見つかりませんでした」で失敗し、一致するinstall.wimがない場合、インプレースアップグレードまたはクリーンインストールが必要だ。RWUはDISMが失敗したことを伝える — 欠落したソースファイルを生み出すことはできない。

次のステップ

RWUのソースコードはGitHubにある。GPL-3.0。便利ならスターを付けてほしい — 可視性が他の技術者がツールを見つける助けになる。IssuesはバグとFRにオープンだ。

Manuel Gilのツールは何年もWindows管理者コミュニティに貢献した。アーカイブされたとき、消費者ガイドやブロートウェア除去ユーティリティでは埋められないギャップを残した。RWUはその続きを担う — モダンなMSPワークフローが要求する追加機能とともに:RMMがパースできる終了コード、管理ポリシーを破壊しない安全なデフォルト、そして新しい常態となりつつあるAI強化トラブルシューティング用に設計された診断出力。

コマンドはirm matbanik.info/rwu | iex。またはGitHubからダウンロード。どちらにしても — レビュー可能、可逆、プロフェッショナルグレード。


リソース