「KBXXXXXXXを削除して」と依頼されたら、まずKB番号、対象OSビルド、導入日時、障害の再現条件、Microsoftの既知問題、アンインストール可能性を確認します。設定 → Windows Update → 更新の履歴 → 更新プログラムをアンインストールする、または起動不能ならWindows回復環境から直近の品質更新を外せます。ただし削除できない更新もあり、セキュリティ更新を外すと既知脆弱性が再び露出します。KB番号だけで全端末へ一括実行しないでください。
更新削除は原因確認のための期限付き切り戻しです。削除後は修正版、Known Issue Rollback、アプリ更新など恒久策へ進み、再適用期限を決めます。
依頼内容を確認する
依頼元、根拠URL、障害端末、影響業務、発生開始時刻、直前変更を確認します。同じKBが品質更新、プレビュー、サーバー、クライアントで意味を取り違えていないかを調べます。SNSや非公式フォーラムの「消せば直る」だけを根拠にしません。
Microsoft Release Health、サポート記事、更新カタログ、製品ベンダーのサポート情報で既知問題と解決状態を確認します。アプリ、ドライバー、EDR、GPO、ファームウェアの変更も同時期なら、更新だけを原因と断定しません。イベントログ、信頼性モニター、Windows Updateログを保全します。
インストール状態を読み取りで確認する
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 20
Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber
DISM /Online /Get-Packages /Format:Table
`Get-HotFix`にすべてのコンポーネント更新が出るとは限りません。設定の更新履歴、`DISM /Online /Get-Packages`、`Get-WindowsPackage -Online`を合わせ、対象パッケージ名とStateを確認します。コマンド出力を保存し、似たKBやServicing Stackを誤選択しないよう二者確認します。
端末のバックアップ、BitLocker回復キーの保管、ローカル/リモート復旧経路、空き容量、保守時間を確認します。更新削除は再起動を要求し、起動失敗や回復キー要求が起こり得ます。遠隔端末ではVPN切断後に戻れない場合に備え、現地連絡先を用意します。
Windows 11の設定から削除する
- スタート → 設定 → Windows Updateを開きます。
- 更新の履歴を開き、対象KBとインストール日を再確認します。
- 関連設定の「更新プログラムをアンインストールする」を開きます。
- 対象更新だけを選び、アンインストールを実行します。表示されない更新は無理に別KBとして削除しません。
- 再起動を求められたら未保存作業を閉じ、保守時間内に再起動します。
Microsoft Supportは、Windows 11で問題が起きた場合に、更新削除前にWindowsの現在版を再インストールする選択肢も案内しています。症状、端末数、復旧時間に応じて修復インストール、アプリ修正、更新削除を比較します。
起動できない場合
Windows回復環境で、トラブルシューティング → 詳細オプション → 更新プログラムのアンインストールへ進み、直近の品質更新または機能更新を選びます。画面名はOS版で異なるため、対象端末の表示を確認します。BitLocker回復キーが必要になる場合は、承認済み保管先から対象デバイスのキーを照合します。
Windows REで選べるのは「任意のKBを番号指定」ではありません。複数更新がある場合や、更新以外が原因の場合は期待どおり戻らないことがあります。システム復元、スタートアップ修復、バックアップ復元の影響を比較し、利用者データを初期化する操作へ進む前に承認を得ます。
DISMを使う場合
GUIで削除できず、Microsoftまたはベンダーの正式手順がパッケージ削除を指定する場合だけDISMを使います。先に`/Get-Packages`で正確なPackageNameを取得し、ログと対象をレビューします。KB番号を推測してPackageNameを組み立てません。オンラインOSとオフラインイメージの`/Online`・`/Image`を取り違えないでください。
DISM /Online /Get-Packages /Format:Table
DISM /Online /Get-PackageInfo /PackageName:<確認済みの完全なパッケージ名>削除コマンドは対象を間違えるとOS保守状態を壊すため、記事に実在端末のPackageNameを固定例として載せません。実行する場合はMicrosoftの`/Remove-Package`仕様、削除可能性、依存関係、再起動、ログパスを対象ビルドで確認し、検証端末から段階展開します。
削除後の検証
- OSが通常起動し、BitLockerや回復ループに入らない
- 対象KB/パッケージが期待どおり変化した
- 元の障害を同じ手順で再試験して改善した
- 別の業務機能、VPN、印刷、認証、EDRが壊れていない
- Windows Updateがエラーなく検出できる
- 更新削除による脆弱性と再適用期限が記録された
改善しなければ更新が原因ではない可能性が高いため、同じ操作を別のKBへ広げません。保存したログ、クラッシュダンプ、イベントを使い、アプリやドライバー、ポリシーを調べます。削除によって新しい症状が出た場合は、更新再適用またはバックアップ復元へ戻します。
再配布を制御する
WSUS、Windows Update for Business、Intune等で対象更新の提供を期限付きで調整します。個人端末の「更新を止める」設定を恒久化せず、影響グループだけに限定します。品質更新は累積されるため、次の更新に同じ修正が含まれるかを確認します。
セキュリティ更新を外した期間は、影響サービスの停止、ネットワーク隔離、管理者権限縮小、EDR監視など代替対策を検討します。脆弱性が悪用されている場合は、可用性問題より削除リスクが高いことがあります。情報セキュリティ責任者が期限付きで判断します。
恒久対応と記録
Microsoftやアプリベンダーから修正版が出たら、検証リングで適用し、元の障害と回帰項目を再試験します。成功後に保留を解除し、全端末の未適用状況を監視します。削除したまま忘れた端末がないよう、資産管理と更新準拠レポートで追跡します。
変更票にはKB、パッケージ名、OSビルド、削除日時、再起動、根拠、対象台数、検証結果、代替対策、再適用期限、承認者を残します。利用者へは「削除したから解決」ではなく、暫定状態と次の更新予定を伝えます。
実施しないこと
- 出所不明のアンインストールスクリプトを管理者実行する
- 更新履歴にないKBを推測して削除する
- 全更新をまとめて削除して原因を不明にする
- 更新サービスやセキュリティ機能を恒久停止する
- 回復キーとバックアップなしで遠隔端末を再起動する
- 一時的に直っただけで再適用計画を閉じる
サーバーとクライアントを分ける
Windows Server、フェールオーバークラスター、ドメインコントローラー、Hyper-Vホストでは、更新削除の影響と戻し順序がクライアントPCより大きくなります。役割、レプリケーション、クォーラム、ライブマイグレーション、保守モード、バックアップを確認し、ノードを一台ずつ扱います。ドメインコントローラー全台から同時に同じ更新を削除しません。
クラウドVMや自動スケール環境では、稼働インスタンスだけを直すより、基準イメージ、展開リング、スナップショット、再作成の方が適切な場合があります。スナップショットはアプリ整合バックアップの代わりではなく、保持期間と復元依存を確認します。
コメント