デブロートはWindows Updateを壊す？本当のリスクを検証する

「デブロートはWindows Updateを壊す」——新規インストールのWindowsを整理しようとする人に向けて撃たれる警告の一撃だが、大部分は誤りだ。アプリの削除と更新の保守は別々の機構であり、本当に壊すのは特定の、回避可能な、そして多くの場合同じスクリプトの別の行項目に潜むものたちだ。

デブロートが削るもの——手の届かないもの

典型的なデブロートスクリプトは、Remove-AppxPackageで現在のユーザーのUWPアプリを削除する。Xboxがこう、Clipchampがああ、誰も頼んでいないスポンサーアプリの山も同様。これはユーザー単位のパッケージに作用するが、Windows Updateはサービシングスタック——CBS、更新オーケストレーター、%SystemRoot%\WinSxS配下のコンポーネント——に棲んでいる。両者はほとんど交わらない。Storeアプリが半分消えていても累積更新は普通にインストールされる。デブロート済みの無数のPCが何年も問題なく更新し続けているのはこのためだ。

正直な注意書きもある。一部のパッケージは耐力壁だ。Microsoft Storeを全ユーザーから削除すればアプリの更新は死ぬ。Security Health UIを削除すればWindowsセキュリティの画面が壊れる。さらに、スタートと検索が密かに依存しているシステムアプリもいくつかある。これらは「特定の失敗に特定の症状」であって、掃除が更新を壊すという一般法則ではない。

実際に更新を壊すもの

デブロート済みのマシンが実際に更新に失敗するとき、原因は削除したアプリではまずない。スクリプトが削除以外に何をしたかだ。攻撃的なプリセットは更新サービスそのものを無効化し、Microsoftの配信ドメインをブロックし、はたまたサービシング全体を切ってしまう更新停止ポリシーを適用する。そのどれかを行うスクリプトを走らせれば、そこで出る0x80...エラーは永遠に「デブロートのせい」にされるだろう。

無効化されたサービス —— wuauserv、UsoSvc、WaaSMedicSvc、DoSvc、BITSが「性能のため」と停止されている
hostsファイルによるブロック —— delivery.mp.microsoft.comなどを遮るプライバシーリストは、更新の配信も一緒に遮る
更新停止ポリシー —— サービシングを完全に止める、デブロートプリセット由来のレジストリおよびグループポリシー改変
削除されたシステムパッケージ —— Microsoft StoreやSecurity Healthを全ユーザーから削除し、アプリ更新とDefenderの画面を破壊
サードパーティ製更新ブロッカー —— wuauservを切ることが唯一の仕事の小さなユーティリティ
破損したコンポーネントストア —— 同じバッチスクリプト内でのdism /StartComponentCleanupの乱用

運任せにしないデブロートのやり方

アンインストールはシステム単位ではなくユーザー単位で。自分のアカウントにRemove-AppxPackage、あるいはもっと単純に、スポンサー入りゴミには設定 → アプリで十分だ。サービスには手を出さない——wuauservを切っても性能の利得はゼロで、リスクだけは本物——そしてhostsファイルを書き換えるスクリプトは決して実行しない。プリセット適用後はservices.mscを開き、連鎖が無傷か確認する。Windows Update、更新オーケストレーター、配信の最適化、BITSがすべて「自動」または「手動」のままになっているべきだ。

更新がすでに失敗しているなら、修復は神秘的ではなく機械的だ。リストの全サービスを再度有効化し、ポリシーを取り消し、内蔵のトラブルシューティングツールを実行し、コンポーネントストアが壊れていればDISM /Online /Cleanup-Image /RestoreHealthを走らせる。これで「デブロート犠牲者」の圧倒的多数は直る——そして、アプリが問題だったことは一度もなかったと分かるだろう。