Windows UpdateはなぜHDDだと異様に
遅くなるのか
（累積更新の仕組み）

by

関連記事

1. Windows Updateが止まる？

Windows Updateの進捗が62%で止まったまま1時間経過。

ディスクアクセスランプは点滅し続けている。
壊れたのだろうかと思って強制終了する——そういう経験は、HDD搭載のPCを使っていた時期に多くの人が通ってきた道ではないでしょうか。
あれは壊れていたのではなく、むしろ正常に動いていました。
問題は、HDDが何をさせられているかにあります。

1.1. 遅いのはダウンロードではない

直感に反しますが、Windows Updateの処理時間のほとんどはダウンロードに使われていません。

Microsoftの説明によると、Windows UpdateはScan、Download、Install、Commitの段階に分かれます。
Scanは更新が必要かを調べる段階、Downloadは更新ファイルを一時フォルダに取得する段階、Installはパッケージを展開してシステムに適用する段階、Commitは再起動前後に変更を確定する段階です1。

ディスクアクセスが100%に張り付いているのに、ネットワークのトラフィックはほとんど出ていない——そういう状態なら、処理の主役はダウンロードではありません。
ボトルネックはInstallとCommitにあります。

1.2. 更新ファイルは「置き換え」ではなく「照合・展開・登録」

更新パッケージは1個のファイルを別の1個で置き換えるだけ、というイメージを持ちやすいですが、実際は違います。

Windowsの更新は、Component-Based Servicingというコンポーネント管理の仕組みを通して適用されます。
CBSと略されるこの仕組みは、更新パッケージを受け取ると以下の処理を順番に行います2。

  1. 圧縮されたパッケージを展開する
  2. 現在のWindowsコンポーネント状態と、更新パッケージのメタデータを照合する
  3. 適用すべき部品と、すでに適用済みでスキップしてよい部品を選別する
  4. 必要なファイルをコンポーネントストア（Windowsの部品置き場）に登録する
  5. 実際のシステムファイルを段階的に配置する
  6. ログ、レジストリ、更新履歴を更新する
  7. 再起動後の確定操作を予約する

この一連の処理は「大きな塊」として始まり、「大量の小さな部品操作」として終わります。
HDDがひどく苦手とする処理が、ここに集中しています。

1.3. HDDが苦手なのは「細かいランダムアクセス」

HDDとSSDのもっとも大きな差は、連続した大きなデータの読み書きよりも、細かく離れた場所への読み書きで現れます。

HDDは磁気ディスクを物理的に回転させ、ヘッドを動かして読み書きします。
離れた場所にアクセスするたびにヘッドが移動し、そのぶん待ち時間が発生します。
この「シーク待ち」が積み上がると、実際の転送量が数MB/s程度しかなくても、ディスク使用率は100%に張り付きます。

CBSの処理は、ランダムアクセスの連続です。

  • メタデータを読む
  • パッケージを展開して書く
  • 別の場所にあるコンポーネント情報を読む
  • 差分を書く
  • ログを書く
  • また別の場所を読む

これがファイル単位で何百回、何千回と繰り返されます。
SSDならミリ秒以下で各操作が終わりますが、HDDでは1回のシークに10ms前後かかります3。
ファイル数が増えれば増えるほど、差が広がっていきます。

分かりやすい類比を出すと、zipファイルを1個削除するのはほぼO(1)ですが、.gitのような何万個もの細かいファイルが入ったフォルダを削除するとO(n)になります。
Windows Updateのインストールは、.gitに相当する処理をシステムの根幹で行っているようなものです。

2. 2015年以降、なぜさらに重くなったのか

Windows 10から、品質更新が「累積更新」方式に変わりました。

それ以前のWindows 7時代は、更新が個別のKBとして多数提供されていました。
1個あたりは数MBから数十MBの小さな更新が並ぶ形で、ユーザーや管理者が個別に選んで適用していました。

2016年10月にはWindows 7とWindows 8.1も月例ロールアップ方式へ移行し、毎月1本の大きな更新として提供されるようになりました4。

この変更の意図は合理的です。
個別KBを細かく管理する必要がなくなり、最新の累積更新を適用すれば過去の修正も含めてまとめて反映される状態を作れます。
KB同士の依存関係や適用順序を人間が追わなくてよくなりました。

ただし、複雑さが消えたわけではありません。
複雑さは「ユーザーが管理するKBの依存関係」から「CBSとコンポーネントストア内部の照合処理」へ移動しました。
更新パッケージも大きくなり、ライフサイクルが進んだ累積更新は1GB前後になることもあります。
Windows 11 24H2以降では数GB級になることもあります5。

プログラミングで言えば、ガベージコレクションの設計に似ています。
ガベージコレクションとは、不要になったメモリ領域を実行系が自動で回収する仕組みのことです。
C言語のmalloc/freeは人間が細かくメモリを管理する方式で、管理ミスがあれば壊れますが、うまく書けば軽い。
ガベージコレクションのある言語は人間の負担を減らしますが、実行系が裏で到達可能性を調べて回収する処理コストが生じます。
Windowsの累積更新も、外側の管理は楽になった代わりに、内部の照合・整理コストをOS側が引き受ける設計になっています6。

2.1. SSD前提の設計がHDDの問題を見えにくくした

この変更が設計された時期には、開発者や品質検証の環境はSSDが標準になっていました。

SSDでは累積更新のインストールでも処理がそれなりの速度で終わるため、問題として表面化しにくかったのです。

しかし同じ時期、実際にWindowsを使っていたユーザーの多くはHDD搭載機を使っていました。
その環境では、インストール中にディスクが長時間100%に張り付き、進捗表示は動かず、「止まっている」「壊れた」と見えました。

3. 途中で止めると何が起きるか

強制終了したとき、内部の状態は中途半端になります。

  • ダウンロード済みのキャッシュは残っている
  • 一部のファイルは展開・配置済み
  • 一部のメタデータは更新済み
  • しかしCommit、つまり変更確定は終わっていない
  • 再起動後に処理する予定だった保留操作も宙に浮く

Gitで言えば、インデックスとオブジェクトとワーキングツリーがバラバラな状態に近いです。
実体ファイルがそこにあっても、管理情報との整合性が崩れると、次回Gitは正しく現在状態を判断できません。

Windows Updateも同じで、次回更新時に「どこからやり直すべきか」を判断しなければなりません。
自己修復できればよいのですが、更新履歴・コンポーネントストア・保留操作・ダウンロードキャッシュの整合性が崩れた状態だと、同じ更新を何度も試す、ダウンロードを繰り返す、インストール途中で失敗するという形になりやすいです7。

3.1. ディスククリーンアップが「気休め以上」な理由

トラブルシューティングとしてよく案内される「ディスククリーンアップ」は、壊れたWindowsを直す操作ではありません。

古い作業場を片付ける操作です。

「配信の最適化ファイル」は、Delivery Optimizationというダウンロードキャッシュの仕組みが持つ一時保存データです8。
更新ダウンロードが途中で止まったり、古い不完全なキャッシュが残っていたりする場合、これを削除すると次回が新鮮なダウンロードから始まりやすくなります。

「Windows Updateのクリーンアップ」は、過去の更新で使われた古いコンポーネントを整理します。
削除後は直前の更新をアンインストールして戻すことが難しくなるため、更新直後に明らかな不具合が出ている場合は待った方がよいでしょう9。

更新キャッシュやコンポーネントの断片が整理されることで、次回の更新処理がクリーンな前提から動きやすくなります。
「修理」ではなく「環境整備」です。

4. まとめ

Windows Updateの処理時間の大半を占めるのは、ダウンロードではなくパッケージの展開・照合・登録・確定です。
累積更新への移行でユーザーが管理するKBの依存関係は減りましたが、CBSとコンポーネントストアが行う内部処理は増えました。
この処理はランダムアクセスが多く、HDDでは極端に遅くなりやすいです。

HDDでは進捗表示が長時間動かないため、正常に動いていてもユーザーには「止まっている」と見えます。
強制終了すると実体と管理情報のズレが生じ、次回以降の更新がさらに不安定になります。

SSDに換装すると体感が劇的に変わるのは、Windowsそのものが速くなるからではなく、HDDに向いていない処理がSSDには向いているからです。

  1. Windows Updateのワークフローは4段階に分かれており、OrchestratorがScan・Download・Install・Commitを順に制御する。Commitでは再起動前にarbiterが変更内容を確定する。 – How Windows Update works – Microsoft Learn
  2. CBSはWindows Vistaで導入されたコンポーネント管理の仕組みで、DISM・SFC・Windowsの機能変更など多くのシステム操作の基盤となっている。インストール失敗時にはCBS.log（%windir%\Logs\CBS\CBS.log）にログが記録される。 – Understanding Component-Based Servicing – Microsoft Community Hub
  3. HDDの平均シーク時間は一般的に8〜10ms程度。一方SSDのシーク時間は0.08〜0.16msと、HDDの約100倍速い。同じファイル操作でも、ファイル数が増えると両者の差は線形に広がる。 – Hard disk drive performance characteristics – Wikipedia
  4. Microsoftは2016年8月に発表し、同年10月から実施。個別KBの提供を終了し、セキュリティと品質修正をひとまとめにした「Monthly Rollup」と、セキュリティのみの「Security-only update」の2本立てに移行した。 – Windows 7 and 8.1 updates switching to cumulative monthly rollups starting in October – PCWorld
  5. Windows 11 24H2の累積更新は、2024年中盤の200〜500MB台から2025年後半には3〜4GBに達する傾向が確認されている。特に2025年5月は前月の約3倍に急増した。カタログ上のサイズと実際にデバイスへ配信される差分サイズは異なる場合がある。 – I investigated Windows 11’s massive 5GB monthly .msu updates – Windows Latest
  6. Microsoftはこの肥大化に対処するため、Windows 11 24H2からcheckpoint cumulative updateを導入。RTMからの差分を積み上げ続ける代わりに途中でチェックポイントを設け、以降はその差分だけを配信する仕組み。ただし2024年9月の初回チェックポイント以降、2025年5月に更新が急増するなど、効果が持続していない面も指摘されている。 – Checkpoint cumulative updates and the Microsoft Update Catalog – Microsoft Learn
  7. CBSは、再起動が必要な操作を%windir%\WinSXS\Pending.xmlに書き出し、次回起動時にまとめて適用する。複数の更新が同時に保留されると、このファイルにエントリが追記されていく仕組みになっている。強制終了によってPending.xmlの内容とコンポーネントストアの実態がずれると、次回以降のサービス操作が失敗しやすくなる。 – Understanding Component-Based Servicing – Microsoft Community Hub
  8. Delivery Optimizationは、同一ネットワーク内の他のPCや専用キャッシュサーバーからも更新ファイルを取得できる仕組みで、外部への通信量を削減する目的で設計されている。取得したファイルを一時的にローカルキャッシュに保存し、ピア間での再配信にも使用する。キャッシュはWindowsが自動管理するが、手動でクリーンアップすることも可能。 – What is Delivery Optimization? – Microsoft Learn
  9. Servicing Stack Update（SSU）は2021年2月以降、月例累積更新に統合されて配信されるようになっている。CBSはWindows展開の多くの要素を支える基盤コンポーネントであり、CBSが破損するとDISMやSFCも機能しなくなる。 – Servicing stack updates – Microsoft Learn