Windows 11 24H2がインストールできない？修正方法

24H2がダウンロードされ、インストールが始まり、途中まで進んだ後ロールバックするかエラーになる場合 — 修正方法はどのエラーコードが出ているかによって異なる。設定 ＞ Windows Update ＞ 更新の履歴を開き、失敗した24H2エントリを見つけてそのエラーコードをコピーする。単に容量不足なのにDISMを実行すると30分無駄になる。コードによって必要な修正はまったく異なる。（24H2に限らない一般的なWindows Updateの停止については、Windows Updateが止まる場合のガイドを参照。）

24H2のロールアウトは波乱含みだった。Microsoft自身のテレメトリが数十のハードウェア構成でセーフガードホールドを発動し、NVMeドライバーとオーディオDSPスタックの処理方法が、一般的なWindows Updateトラブルシューティングでは対処できない問題を引き起こした。エラーコードが以下の特定のものに一致する場合は、それぞれに的を絞った修正がある。一致しない場合は、最後のイベントビューアーのセクションに進む — 一般的な「DISMとSFCを実行する」アドバイスはそこでも扱われている。

0x80070070

Windowsに十分な空き容量がない。

24H2のような機能更新プログラムは、ほとんどの人が想像する以上のことを行う。3～4GBの圧縮データをダウンロードし、それをC:$WINDOWS.~BTにWindowsの作業用コピーとして展開し、設定、アプリ、ユーザープロファイルを新しいインストールに移行する。ステージングだけで20～25GB消費する。プロセスが完了に近づくと、展開された作業用コピーとロールバック用バックアップの両方が同時にC:上に存在する。その瞬間にドライブが一杯になると、インストーラーは一時停止も警告もせず — ただロールバックして0x80070070をログに記録する。

Microsoftのドキュメントでは最低20GBとされているが、実際にはC:に少なくとも30GBの空きが必要だ。

実際の空き容量は設定 ＞ システム ＞ ストレージで確認する。「クリーンアップの推奨事項」の数字は無視する — Windows Updateのクリーンアップの下に実際のファイルに対応しない8.63GBのエントリが表示されることがある。これは既知の24H2の報告バグで、ディスク クリーンアップがディスク上に存在しない8.63GBのクリーンアップ可能な更新ファイルを主張するというもの。代わりにストレージページ上部の実際の使用量/空き容量の数字を見る。

容量を解放するには：管理者としてディスク クリーンアップを実行。Windows Updateのクリーンアップ、配信最適化ファイル、一時ファイルをチェックする。これら3つで、しばらくクリーンアップされていないシステムでは通常10～15GB解放される。

それでも足りない場合 — WinSxSコンポーネントストアのクリーンアップ（DISM /Online /Cleanup-Image /StartComponentCleanup）、以前のWindowsインストール、大容量アプリ、個人ファイルを外付けドライブへ。（より積極的なクリーンアップ方法についてはディスク空き容量を確保するガイドで解説している。）C:に30GB以上の空きを確保してから、Windows Updateから24H2を再試行する。このエラーでISO方式に切り替えても無駄だ — ISOもC:にステージングされ、同じ理由で失敗する。

0x80070002

ダウンロードキャッシュの破損。更新プログラムが部分的にダウンロードされた、接続が切断された、または以前の失敗した試行が残した破損ファイルを新しい試行が再利用している。

管理者としてコマンドプロンプト：

net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 Catroot2.old
net start wuauserv
net start cryptSvc
net start bits
net start msiserver

削除ではなく名前変更。サービスは再起動時に新しいフォルダーを作成し、クリーンに再ダウンロードする。何か問題があれば — 稀だが — 名前を元に戻せばよい。リセット後に再起動し、更新プログラムをチェックする。初回のダウンロードは完全な24H2パッケージを新規取得するため通常より時間がかかる。

キャッシュリセットだけでは0x80070002が修正されない場合、通常はコンポーネントストア自体がダウンロードキャッシュよりも深く破損している。以下を実行：

DISM /Online /Cleanup-Image /RestoreHealth

DISMはMicrosoftの更新サーバーからすべてのWindowsコンポーネントのクリーンコピーを取得し、C:\Windows\WinSxS内の破損したものを置き換える。これがコンポーネントストア — Windowsが実際に実行するOSを構築するために使用する全システムファイルのマスターコピー — である。コンポーネントストアが破損していると、sfc /scannowは既知の正常なファイルのソースとしてストアを使用するため、確実に修復できない。DISMはソースを修正し、SFCはそこから構築されたファイルを修正する。

DISMはインターネット接続が必要。適切にメンテナンスされたシステムでは5～10分。何年もメンテナンスされていないインストールでは30分以上かかることがあり、プログレスバーは60％付近で長時間止まる。フリーズしたわけではない — 多くの依存関係を持つコンポーネントを処理しているのだ。

DISMの後、sfc /scannowを実行する。順序が重要。DISMがコンポーネントストアを修正する。SFCはその健全なストアを使用してシステムファイルを検証し置き換える。順序を逆にすると、SFCが破損したストアから別の破損ファイルでシステムファイルを置き換えるリスクがある。

0x800f0922

このエラーコードには3つのまったく無関係な原因がある。

第一に：システム予約済みパーティションが小さすぎる。Windows 10からアップグレードした古いPCは、元のWindows 10インストーラーがそのように作成したため、50～100MBの予約済みパーティションを持っていることがある。24H2はブートファイルに300MB以上を要求する — 新しいブートマネージャーと回復環境が以前のリリースより大きくなっている。ディスクの管理（スタートを右クリック）で確認する。システム予約済みパーティションが200MB未満なら、これが問題だ — そして拡張するにはシステムを起動不能にするリスクがあるサードパーティのパーティションツールが必要になる。ここに該当するほとんどの人はWindows 11のクリーンインストールを行う。

第二に、そしてはるかに一般的なのが：VPNまたはプロキシがMicrosoftの更新CDNエンドポイントへの接続を妨害している。Windows Updateは単一のダウンロードサーバーを使用しない — 地域ごとに異なるエンドポイントを持つ分散CDNから取得する。一部のVPNはすべてのトラフィックを単一の出口ノードを通してルーティングし、それがPCとは異なる地域にある可能性があり、CDNは接続をスロットルするか安定したセッションを確立できない。VPNを完全に切断する。設定 ＞ ネットワークとインターネット ＞ プロキシでプロキシを無効にする。更新を再試行する。これだけで驚くほど多くの0x800f0922のケースが解決する。

第三に：CBSマニフェストの破損。これはDISM /RestoreHealthが修正するもの。最初の2つが該当しない場合は、上記セクションの説明に従ってDISM、次にSFCを実行する。

0x80240069

これはWSUSまたはSCCMが更新プログラムを管理している業務用マシンで表示される。構成された更新ソースが24H2を承認していない。家庭用PCではこれは表示されるべきではない — もし表示されたら、設定 ＞ Windows Update ＞ 詳細オプション ＞ 構成された更新ポリシーを確認する。個人のマシンで「一部の設定は組織によって管理されています」と表示される場合、何らかのソフトウェアまたはポリシー編集が更新ソースを変更したことを意味する。まずそれを修正する。

24H2をブロックするドライバー

エラーコード0x80004005、またはWindows Updateが「この更新プログラムはお使いのデバイスにはまだ準備ができていません」と表示する場合 — ブロックの原因はおそらくドライバーだ。Microsoftは実際のアップグレード失敗のテレメトリに基づいて、文書化された24H2非互換性を持つハードウェア構成にセーフガードホールドを設定している。あなたのマシンが該当したのだ。

特定のドライバーに進む前に：組み込みのWindows Updateトラブルシューティングを一度実行する。設定 ＞ システム ＞ トラブルシューティング ＞ その他のトラブルシューティング ＞ Windows Update ＞ 実行。これは破損したBITSジョブ、誤って構成された更新ポリシー、停止したサービス状態などの単純な構成問題を検出し、ドライバーに触れることなく0x80004005を解決することがある。効果がない場合は、以下のドライバーリストが次のステップだ。

これらのブロックの大半は3つのドライバーが原因である。

Intel Smart Sound Technology オーディオドライバー、具体的にはバージョン10.29.0.5152および10.30.0.5152。オーディオDSPインターフェースのバグが24H2のドライバー移行中にカーネルクラッシュを引き起こす。主に第11世代Intel CoreノートPC。確認方法：デバイス マネージャー ＞ サウンド、ビデオ、およびゲーム コントローラー ＞ Intel Smart Sound Technology ＞ ドライバー タブ。これらのバージョンのいずれかの場合、修正は10.29.00.5714以降に更新すること — ノートPC OEMのサポートページまたはIntel Driver & Support Assistantから入手する。他の方法は効かない。古いドライバーは削除しなければならない。

Phisonコントローラー搭載NVMe SSD（ファームウェアが古い場合）。Phison E12、E16、またはE21Tコントローラーを使用するドライブがアップグレード中にオフラインになる。対象ブランドにはCorsair Force MP600、Silicon Power US70、Kioxia Exceria Plus G4が含まれる。引き金：Microsoftが24H2でNVMe Host Memory Bufferの割り当てを変更し、新しい動作がこれらのコントローラーに古いファームウェアでは処理できない負荷をかけた。Phisonは後に一部のドライブが何年も前に製品版前のファームウェアで出荷されていたことを発見した — バグはWindowsの変更によって露呈するまで休眠していた。メーカーのツールでSSDファームウェアを更新してから、24H2を再試行する。

Realtek UADオーディオ（カスタムOEMスタック上）。バージョン番号を特定するのは難しい — OEMごとに構成が異なる。症状：24H2が「ドライバー移行」中に失敗し、0x80004005より具体的な情報がない。最速の診断方法：デバイス マネージャーからRealtekオーディオデバイスをアンインストールし（「このデバイスのドライバーソフトウェアを削除する」をチェック）、再起動してWindowsに汎用ドライバーを再インストールさせる。その後24H2が通れば、OEMオーディオスタックがブロッカーだったということだ。

セーフガードホールドをバイパスしないこと

実際にセーフガードホールドがあるかどうかを確認する方法：設定 ＞ Windows Updateを開き、24H2のエントリを見る。「まもなく公開: Windows 11, version 24H2」と表示され、ダウンロードボタンの代わりに「詳細情報」リンクがある場合、Microsoftがデバイスにホールドを設定している。aka.ms/WindowsReleaseHealthで既知の問題リストも確認できる — MicrosoftはアクティブなセーフガードホールドをホールドID、影響を受けるドライバーのバージョン、インストールすべき修正バージョンと共に一覧表示している。

絶対にやるべきでないこと：レジストリ編集でセーフガードホールドをバイパスすること。そうするガイドがネット上に出回っている — AllowUpgradesWithUnsupportedTPMOrCPU、このキーを削除、あのDWORDを設定。（あなたのPCがWindows 11のハードウェア要件を満たしているかどうかわからない場合は、まずTPMと互換性ガイドを確認してほしい。）これらのホールドが存在するのは、あなたの正確な構成がMicrosoftのテレメトリで24H2でクラッシュすることが観測されたからだ。バイパスは問題を解決せず、警告を抑制するだけ。結果はブートループ、起動時の黒画面、またはアップグレードを完了しようとするたびにブルースクリーンになる中途半端なWindows。ホールドをバイパスしてシステムが起動不能になった場合、ロールバックには回復メディアから起動してWinREから更新プログラムを手動でアンインストールする必要がある — ロールバックデータがまだ無事であればの話だが。

上記のいずれも効かなかった場合のイベントビューアー

特定のエラーコードのいずれにも一致せず、キャッシュリセットとDISM/SFCがすべてクリーンだった場合、セットアップイベントログが次に見るべきものだ。

イベントビューアーを開く。次の場所に移動：

アプリケーションとサービス ログ ＞ Microsoft ＞ Windows ＞ WindowsUpdateClient ＞ 操作

イベントID 20：インストール失敗。イベントID 31：完了したがロールバックされた。イベントID 42：インストールが始まる前のダウンロード失敗。各イベントの詳細ペインに、エラーコードと失敗したコンポーネントまたはフェーズが表示される。

これらのログに十分な詳細がない場合、もう1つ深いレベルがある：C:\$WINDOWS.~BT\Sources\Panther\setupact.log および setuperr.log。これらはインストーラー自体からの生のセットアップログである。インストールが失敗した時刻付近で “Error” または “Failure” をCtrl+F検索する。形式は密で — 一般向けに読めるようには設計されていない — しかしエラー行は通常、連鎖を引き起こしたファイルまたはドライバーを名前で示す。

ここが自己診断の限界に達する地点だ。セットアップログは数千行に及ぶ。実際の失敗原因は、最初の “Error” 行から数層の依存関係の深みに埋もれていることが多い。どのエラーが致命的でどれが表面的か、コンポーネントの失敗がその上のドライバースタックについて何を意味するか — これにはトラブルシューティングガイドで教えられる範囲を超えたWindows内部構造への精通が必要だ。

ここまでのすべてを試しても明確な修正策が見つからない場合、残る最速の選択肢は、これらのログを日常的に読んでいる誰かにブロッカーを見つけてもらうことだ。RebootDoctorはこの種のリモート診断作業を扱っている — 通常1回のセッションで更新をブロックしているものを特定し、修正するか、クリーンインストールの方が良いかの判断を伝えるのに十分である。