このコラム記事について
最近の Windows Update（WinUp）において、「準備中 96%」の表示で 30 分から 2 時間程度停滞し、ひどい場合は一晩そのまま……という事例が激増しています。
その他にも、以下のようなご相談を連日いただいています。
- CPU 使用率が 100% に張り付き、PC が唸り声を上げている
- SSD に換装したばかりなのに、一向に終わる気配がない
- 「故障した」と思って強制終了したら、再起動ループに陥った
実は、現状の WinUp 実行内容は「インプレースアップグレード（上書き修復）に非常に近いもの、あるいは匹敵するもの」に相当する負荷となっており、結局のところ所要時間も同程度かかる結果になると考えられます。
そんな巨大な作業を「OS が起動した状態のままで実行している」のですから、「時間がかかる、PC の動作が極端に重くなる、あるいは失敗や不具合が多くなるというのは、ある意味で当たり前のこと」と感じてしまうのは私だけでしょうか？
どうしてこれほど時間がかかるのか？その正体と、今私たちに可能な「少しでも速くする手法」を紹介します。
※ 7分15秒
結論
完璧な解決法は残念ながらありません。
現在の WinUp は、単なる修正パッチではなく「OS の心臓部を丸ごと入れ替える大手術」を毎月行っているような状態です。しかも、それを「OSを動かしたまま」強行するのですから、時間がかかるのはある意味で当然とも言えます。概要を以下にまとめます。
あわせて、下部の「WinUp の所要時間を短縮する方法など」も読んで、実際にWinUpを実行する際の細かな注意も参照してくださいね。
あなたにできること
1. 効果がはっきりと見込めること
【効果：大】 HDD ⇒ SSD への換装
- 2026 年の Windows において、HDD はもはや「動作対象外」に近い負荷がかかります。
SSD に変えるだけで、WinUp 中のディスク待ち（100% 張り付き）が解消され、PC が操作不能になる時間を劇的に減らせます。
参考記事：
【Win10⇒Win11】ディスククローンによるPC引っ越しの手順と問題点解決【2025/05/14】
【困った】SSD/HDDのクローンが完了しないまたはエラーが出る【2025/03/17移転】
【効果：中程度】 スペックの底上げと足場の確保
- メモリの増量（最低 16GB 推奨）：
更新ファイルの展開・照合作業はメモリを激しく消費します。8GB 以下では「スワップ（ディスクへの読み書き）」が頻発し、処理が泥沼化します。※注意： 仮想メモリの設定で制限をかけても、WinUp の重い動作自体を軽くする効果はほとんど見込めません。物理的な増設が正解です。 - システム領域（EFI）の拡張：
HDD からクローンした個体に多いですが、ここが 100MB 程度だと更新の「足場」が足りず、何度も書き直しが発生して停滞します。
260MB 〜 500MB 程度へ拡張しておくことで、インストールの「迷走」を防げます。
参考記事：【システム領域不足】WinUpやOSアップグレードの失敗を解消する【2025/09/15】
【効果：確実だが限定的】 通信環境の改善
WinUp ファイルそのものが 4GB を超える現状、ダウンロード時間だけで 10 分以上損をしているケースがあります。
- 具体例： 100Mbps（約 10 分） ⇒ 700Mbps（約 1 分強）
このように、IPv6（IPoE）の採用や有線 LAN への切り替えで、間違いなく時間は短縮できます。（※仮想V6などの採用も検討してください。相当速くなるケースが多いです。） - 安定性の向上： 4GB の巨大な AI コンポーネントを落とす際、不安定な Wi-Fi では整合性チェックでエラーが出やすく、それが再計算の負荷（CPU 100%）に繋がります。
参考記事：
【回線速度】無線LAN（Wi-Fi）だけが遅い場合のチェックポイントと解決【2025/04/21】
【回線速度】光回線が遅い場合のチェックポイントと解決【2025/04/18】
2. 多少の効果（または副次効果）があること
環境によっては劇的に改善する場合もあります。また、これらは OS 起動時の参照ファイルを整理するため、「起動時間の短縮」という嬉しい副次効果も期待できます。
- システムファイル（WinSxS）のクリーニング：
DISMコマンド等で古い残骸を掃除しておくと、照合対象が減り、計算時間がわずかに短縮されます。 - WinUp コンポーネントのリセット：
過去の失敗による「しこり」を取り除き、エンジンの迷走を未然に防ぎます。
参考記事：【 Winトラブル】コマンドを自動実行して〇〇をさせるバッチファイル集【2025/03/20移転】（項目11番）
オプション（事前の整合性チェック）
WinUp の土台となる OS 自体が壊れていると、更新処理は「無限リトライ」に陥ります。事前に以下の修復を行っておくのが鉄則です。
DISMとSFCの実行
OS のシステムファイルが健全かどうかをチェックし、修復します。
参考記事：【SFCとDISM】究極奥義「オフライン実行」でOSを徹底修復-完全解説版【2025/08/12】
チェックディスク（chkdsk）の実行
ファイルシステムにエラーがあると、更新ファイルの書き込みが阻害され、CPU 100% 状態のまま動かなくなる原因になります。
ユーザープロファイル破損のチェック
意外と多いのが、プロファイルの破損が原因で WinUp のサービス（SENS 等）と競合し、ログイン画面で停滞するケースです。
参考記事：【どうやって確認するの？】ユーザープロファイル破損のチェック方法【2025/06/01】
【将来に向けた投資】 次世代 PC への買い替え
- 最新の AI PC（NPU 搭載機）への買い替え：
コストはかかりますが、適用分の選別や圧縮解除を専用チップ（NPU）で処理できる機種なら、将来的に WinUp の時間が短縮される可能性があります。
昨年 12 月頃から異常に時間がかかるようになった原因は？
従来から WinUp は「重い」ものでしたが、昨年末から今年（2026年）にかけて、その負荷は明らかに「異常」なレベルに達しています。
i7 や SSD を搭載したハイスペック機ですら数十分、環境によっては数時間も CPU が 100% に張り付くのはなぜか？ その舞台裏を解説します。
昨年 12 月頃から負荷が激増した 2 つの理由
-
- AI コンポーネントの「強制的な先行搬入」：
Microsoft は将来の AI 機能解禁に向け、巨大なプログラム（数GB単位）をあらかじめシステム内に送り込んでいます。ここで厄介なのが、「ユーザーが AI 機能を使わない設定にしていても、配置と整合性チェックだけは全力で実行される」という仕様です。使わない機能のために、あなたの PC のリソースが奪われているのが現状です。 - 「2026 年 6 月問題」に伴う最深部の書き換え：
2026 年 6 月に控えたセキュアブート証明書の期限切れに向け、OS の最も深い部分（ブートローダー等）を慎重に更新しています。この領域は一歩間違えれば「PC が二度と起動しない」致命的な場所であるため、システムは通常の何倍もの時間をかけて、慎重に慎重を重ねて（＝低速で）ベリファイ（整合性確認）を繰り返しています。
- AI コンポーネントの「強制的な先行搬入」：
従来からある構造的な要因
-
- 累積更新（ロールアップ）形式の肥大化：
現在の WinUp は過去の修正をすべて含んだ「全部入り」で配信されます。そのため、適用時に「自分の PC にはどの欠片が必要か？」を選別する膨大な計算が発生し、たとえ最新の多コア CPU であっても、処理待ちの列ができてしまいます。 - 魔の「96% の壁」と生存信号：
進捗バーが 96% 付近で止まるのは、ファイルの配置が終わり、最後の仕上げである「レジストリの書き換え」や「古いファイルの圧縮」が集中しているためです。ここで一番大切なのは、タスクマネージャーを確認することです。CPU 使用率が 30% ↔ 100% を行き来していれば、それは PC が必死に戦っている「生存信号」です。ここでフリーズしたと勘違いして電源を切るのが、最も確実かつ最悪の故障原因（再起動ループへの引き金）となります。
- 累積更新（ロールアップ）形式の肥大化：
【プロ・上級者向け】さらに踏み込んだ技術的な背景（クリックで展開）
現場で検証を続けるプロの視点から、今回の「重さ」の正体をさらに深掘りすると、以下の3つの技術的要因が浮かび上がります。
- UUP (Unified Update Platform) によるローカル計算の増大：
現在の WinUp はサーバー側ではなく、各 PC 上で「どの差分が必要か」を高度に計算する仕組みになっています。AI コンポーネントのように依存関係が複雑なモジュールが増えたことで、この「差分計算（マニフェスト照合）」だけで CPU が数十分間フル回転する事態を招いています。 - NVRAM / UEFI への書き込み待機：
2026 年問題（証明書更新）への対応として、ブートローダーだけでなくマザーボード上の NVRAM（非揮発性メモリ）に書き込まれる「禁止署名リスト（DBX）」等の更新が行われています。この物理的な書き込み処理は OS 上の処理に比べて極めて低速であり、システム全体を「待機状態」にさせる要因となっています。 - コンポーネントストア（WinSxS）のデルタ圧縮負荷：
数 GB の AI バイナリをディスク容量を圧迫せずに配置するため、適用と同時に「背景での圧縮（LZXアルゴリズム等）」が走っています。これが 96% 付近で CPU を 100% に張り付かせ、ディスク I/O を飽和させている正体の一つです。
※ 結論として、この負荷はソフトウェアのバグというより、現在のハードウェア（特に HDD や低速な NVRAM）の限界を無視した「OS の構造的な肥大化」が引き起こしている現象と言えます。
WinUp の所要時間を短縮する方法など
正直に申し上げて、「これをクリックすれば一瞬で終わる」という特効薬は存在しません。
現状では、以下の方法を地道に設定・実行していくのが、最も確実で結果的に最短となる「急がば回れ」の自衛策となります。
その中でも、意外と効果が大きい（トラブルを未然に防げる）のは以下の項目です。
- 周辺機器の徹底排除
- システムディスクのシングル化（物理切断推奨）
- 電源オプションの見直し（ハイパフォーマンス）
- OS バージョンに非対応なソフト・ドライバーの排除
- OS 完全対応 BIOS へのアップデート
1. 通常の累積更新（月例 WinUp）の場合
周辺機器の徹底排除
更新中（特に進捗 90% 以降）のドライバー競合は、停滞やブルースクリーンの主犯です。マウス・キーボード以外の USB 機器、外付け HDD、SD カード等はすべて外しましょう。
【重要】ディスクのシングル化（物理的な切断）
可能であれば、OS が入っているシステムディスク以外のストレージを物理的に取り外すことを強く推奨します。
なぜ物理切断なのか？
Microsoft は過去に WinUp を通じてシステム領域の構成を変更しようとし、深刻な不具合を発生させた例が（私の記憶では）少なくとも 2 回あります。現在のシステム領域の逼迫状況を鑑みると、「万が一、別のドライブにシステム領域が生成される」といった事故を防ぐためにも、物理的にシングル化しておくのが最も安全な策と言えます。
OS バージョンに非対応なソフト・ドライバーの排除
メーカー機特有の「総合ユーティリティ」や、GPU、キーボード・マウスの管理ソフトには注意が必要です。これらがバックグラウンドで干渉すると、速度低下だけでなく WinUp 自体の失敗を招きます。最新バージョンが提供されていない古いソフトは、一旦削除しておくのが賢明です。
電源オプションの見直し
- 電源プラン：「高パフォーマンス」または「最高のパフォーマンス」に設定。
- スリープ：更新中にスリープに入ると、復帰時にプロセスが「迷子」になり、CPU 100% 停滞の原因となります。必ず「なし」に設定してください。
【さらに徹底したい方へ】細かい設定のチェックリスト（クリックで展開）
- 配信最適化のオフ：「他の PC からのダウンロードを許可する」を無効化し、通信リソースを占有させます。
- 帯域幅制限の解除：設定＞配信最適化＞詳細オプションから、バックグラウンド/フォアグラウンドの制限率を最大に引き上げます。
- 不要なサービスの停止：WinUp 実行中は他のスケジュールタスクや自動更新サービスを一時的に止めることで、CPU を WinUp 処理に集中させます。
2. OS アップグレード（Win10 ⇒ 11 等）の場合
「作成したメディア（ISO）からのインストール」を標準にしてください。
Windows Update の画面から進めるよりも、最新の ISO メディアを作成し、その中の setup.exe を実行する方が、差分計算のプロセスをスキップできるため、エラー回避も含めて「最速」で終わるケースが増えています。
3. メジャーアップデート（24H2 ⇒ 25H2 等）の場合
このケースの判断は非常に難しいところですが、私はあえて「新バージョンのインストールメディアを準備して上書きインストールする」という方法を取っています。
「急がば回れ」のおすすめ理由：
最新のイネーブルメント・パッケージを使えば短時間で済みますが、あえてフルインストーラーを使うことで、「現行 OS の抱えている瑕疵（傷）を修復しながら新バージョンへ移行する」ことが可能です。多少の時間は要しますが、できる限りクリーンな環境で新バージョンに飛び込みたい、というのが私のこだわりであり、おすすめの理由です。
おまけ
【SE・管理者向け】さらに深い技術的背景と Enterprise 運用の勘所（クリックで展開）
1. UUP (Unified Update Platform) のオーバーヘッド
現在の WinUp はローカルクライアント側で「最適な差分」を計算する UUP 形式が主体です。AI コンポーネントのような複雑なモジュールが増えたことで、適用前の「マニフェスト照合」だけで CPU が食いつぶされています。これはディスク速度ではなく「論理的な計算待ち」です。
2. Secure Boot 証明書更新（2026 年 6 月問題）への対応
累積更新にはマザーボード上の NVRAM（非揮発性メモリ）への書き込みを伴うブートローダーの更新が含まれています。NVRAM の書き込みは SSD に比べて極めて低速であり、この「物理的な待ち」がハングアップに見える停滞の正体です。
3. 【Enterprise / 自社サーバー運用者向け】3 つの処方箋
- WSUS のクリーンアップ徹底： クライアント側の判定計算を軽くするため、不要な更新の「拒絶（Decline）」を徹底し、カタログのメタデータを最小化してください。
- 「イネーブルメント パッケージ」の活用： 25H2 等への移行は、背景でバイナリを搬入させておき、最後に小さな有効化パッケージを流す運用が推奨されます。ただし、搬入中のリソース競合を避けるためのセグメント配信が不可欠です。
- 配信最適化（DO）モードの再考： P2P（モード 1）をあえて活用し、拠点内 LAN で巨大な AI パッチの破片を融通させる方が、外部帯域の飽和とタイムアウトによる「再試行ループ」を防げる場合があります。
管理者としての運用指針（推奨）
- リングデプロイメントの徹底： DBX 更新を含むパッチは、まず検証グループで EFI 領域の破損がないか確認する時間を必ず確保してください。
- LTSC 版への移行検討： 安定稼働が最優先の現場（キオスク・製造ライン等）では、機能更新を排した LTSC 版の導入を真剣に検討すべきフェーズです。
— 現場での実機検証データに基づき構成 —
【実戦編】個別の PC が不調になった時のレスキュー手順
「他の PC は終わったのに、この 1 台だけがずっと重い」「更新後に特定のアプリが落ちる」といった個別トラブルへの対処法です。
1. 「SoftwareDistribution」フォルダの掃除
WinUp の作業場所（C:\Windows\SoftwareDistribution）に壊れたインデックスが残っていると、何度やり直しても同じ場所で停滞します。
- 手順： Windows Update サービスを停止 ＞ フォルダ内を空にする ＞ サービスを再開。
- ※リスク： 実行後は更新履歴がリセットされます（パッチ自体は消えません）。「履歴が消えた！」と焦らないよう注意が必要です。
2. 「高速スタートアップ」を完全に切る
不調な PC は、前回の不完全な終了状態を引きずっています。一度コントロールパネルから「高速スタートアップ」を完全に無効化し、本当の意味での「完全な再起動」をさせるだけで、詰まっていたパッチが通ることがあります。
3. ドライバーの「ロールバック」
WinUp 後にネットが極端に遅くなった場合、Windows が勝手に「汎用ドライバー」に変えている可能性があります。デバイスマネージャーから以前のバージョンに戻すか、メーカー提供の最新版を手動で上書きしてください。
4. 【究極の救済法】インプレースアップグレード（上書き修復）
どうしても治らない時は、迷わずこれです。最新の ISO メディアを使って OS ごと上書き修復します。
- メリット： 個人用ファイルを守りつつ、システムの「ねじれ」を根本から正せます。
- ※警告： 実行時は、必ず「個人用ファイルとアプリを引き継ぐ」にチェックが入っていることを、指差し確認してください。
終わりに
根本的に解消する方法はありません。Windows を利用する以上、この「更新という名の苦行」を受け入れるしかないのが現状です。
- 30 〜 40 分程度で完了するなら： 「まとも・かなり良いスペックの PC」です。
- 1 〜 2 時間かかる場合： それが 2026 年現在の「普通」だと諦めましょう。
「寝る前に実行」は、もう正解とは言えません。
不具合多発（再起動ループ等）の状況下では、朝起きて PC が死んでいて仕事ができない、というリスクがあります。これからは企業においても、「月に一度、WinUp のためだけに業務時間を数時間割り当てる」といった運用の検討が必要になるかもしれません。
付録：この記事の作成プロセス（AI協働メモ）
1. この記事の目的と役割
2026年3月現在、異常に時間がかかる Windows Update の実態を解明し、進捗バーが「96%」で停滞しても CPU が動いていればそれは「生存信号」であることを読者に認知させ、パニックによる強制終了（OS破損）を防ぐことを目的としています。
2. 筆者の関連経験・専門性
この記事の執筆にあたり、筆者の以下の経験が活かされています。
- 20年以上にわたる Windows PC の保守・トラブルシューティング経験。
- 第8世代 Core i7 / SSD 搭載機（FMV 等）における、累積更新プログラムの実際の挙動（CPU 30% ↔ 100% の推移）のリアルタイム監視。
- システム領域（EFI）の不足が WinUp 失敗に直結する過去事例（KB5034441等）への深い知見。
3. AIとの協働内容（調査・議論のポイント）
記事作成の過程で、AI（Google Gemini）とは主に以下の点について調査、議論、内容の精査を行いました。
- 96%停滞の技術的背景： AIコンポーネントの「ステージング（搬入）」と、2026年6月の証明書期限に向けたセキュアブート改変の重なりによる負荷の裏付け。
- インプレースアップグレードの有効性検証： 差分計算を繰り返す通常の WinUp より、メディアを用いた上書きの方が「OS の瑕疵を修復できる」という論理的整合性の確認。
- 管理者視点のアドバイス： Enterprise 環境や WSUS 運用下でのメタデータ肥大化が、クライアント側の「判定計算」に与える悪影響の考察。
4. 主な参照情報・検証方法
筆者が保有する第8世代 Core i7 / SSD 搭載機を用いた実機検証、および Microsoft 公式の UUP（Unified Update Platform）や Secure Boot 関連の技術ドキュメント、そして現場でのトラブル解決実績に基づいています。
この記事中の広告リンクについて
この記事中の広告リンク一覧です。
記事本文中の広告リンク
-
-
- このブログは、広告収入によって運営されていますが、この記事の本文中に個別の広告リンクは含まれていません。
- この記事には、アフィリエイトリンクが含まれる記事へのブログ内リンクが設置されています。これらのリンクを通じて商品が購入されると、当ブログに収益が還元されますが、読者の皆様の購入価格が変動することはありません。
- 外部の参考記事には広告リンクが設置されているものがあります。
-
サイドバーやヘッダー部分などの広告
広告が表示されています。
業者名や商品名など
この記事では明示的にプロモーションとして取り扱っているものはありません。
ただし、過去のプロモーションなどで取り扱った商品名や企業名などがプロモーション目的ではなくとも記載されている場合があります。
過去のプロモーションなどで取り扱った企業名は、できる限りステマ規制に関する表示についてのアフィリエイト等関連業者名一覧の項で記載していますので、お手数ですがそちらでご確認ください。
コメント