Windows 11 22H2 から 23H2／24H2 への機能更新を実行すると、途中で再起動を繰り返したのち「something didn’t go as planned. No need to worry, undoing changes」という青いロールバック画面が表示され、最終的にデスクトップへ戻ってしまう――。セットアップ ログを確認すると 0x80070003 – 0x40008 が繰り返し記録されており、トラブルシューティング ツールでも改善しない。この現象は GPT ディスクの EFI システム パーティション（ESP） と Microsoft 予約パーティション（MSR） の GUID／属性が書き換わっているケースで高確率に発生する。本記事では発生原因の仕組みと安全な修復手順、そして 23H2 をスキップして 24H2 へ直接アップグレードできるかどうかまでを網羅的に解説する。
トラブル概要
| 項目 | 内容 |
|---|---|
| 発生するタイミング | Windows Update もしくは ISO メディア経由の機能更新中 (OS 再起動 Second Boot フェーズ) |
| 画面メッセージ | something didn’t go as planned. No need to worry, undoing changes |
| セットアップ エラー | 0x80070003 – 0x40008 (Apply Image 操作失敗) |
| 共通点 | GPT ディスクで ESP または MSR の GUID／属性が本来と異なる |
内部で何が起きているのか ― GUID と属性の不整合
Windows セットアップは OS 展開時に BCD (Boot Configuration Data) を ESP に書き込み、追加のメタデータを MSR に予約する。もし ESP が Linux 用 ESP (EF00) のままドライブ文字が割り当てられていたり、MSR の GUID が間違っていたりすると、「ここは Windows が想定した領域ではない」 と判断し処理を中断、ロールバックに入る。よくある要因は次の三つだ。
- デュアルブート構築やクローン作業でパーティション ツールが GUID を自動変換。
- Linux Live USB で ESP をマウントし、結果としてドライブ文字が割り当てられた。
- OEM リカバリイメージの適用時に MSR が再作成されず、別種 GUID でフォーマットされた。
標準的な GUID と属性値
| パーティション | 正しい GUID | 属性 (16進) | サイズ目安 |
|---|---|---|---|
| ESP | C12A7328-F81F-11D2-BA4B-00A0C93EC93B | 0x8000000000000000 (Hidden + Required) | 100–300 MB |
| MSR | E3C9E316-0B5C-4DB8-817D-F92DF00215AE | 0x8000000000000000 | 16 MB |
上記以外の GUID が指定されている場合、セットアップは “Apply Image” フェーズで 0x80070003 (ファイルが見つからない) を返し、Exit ステータス 0x40008 (Second Boot ロールバック) をトリガーする。
アップグレード前のセルフチェック リスト
- ESP にドライブ文字が割り当てられていないか (
diskpart → list volume)。 - MSR が Disk Management で 16 MB Unformatted として認識されているか。
- BitLocker を使用している場合は一時的に「保護を中断」。
- サードパーティ製アンチウイルスは無効化またはアンインストール。
- システム イメージ バックアップの作成 (外付け SSD / ネットワークなど)。
DiskPart で GUID と属性を修復する
以下のコマンドは コピー & 一括貼り付け禁止。タイプミス防止のため 1 行ずつ手入力し、実行ごとに結果を確認する。ESP と MSR の番号は PC ごとに異なるため、事前に list disk と list partition で慎重に確認すること。
diskpart
select disk 0 // OS が存在するディスク
select part 2 // 例: MSR のパーティション番号
set id=E3C9E316-0B5C-4DB8-817D-F92DF00215AE
gpt attributes=0x8000000000000000
select volume D // 例: ESP に誤って割り当てられたドライブ文字
set id=C12A7328-F81F-11D2-BA4B-00A0C93EC93B
gpt attributes=0x8000000000000000
exitコマンド入力時のポイント
select disk→ NVMe SSD の場合はdisk 1になることもある。select partはサイズ 16 MB なら MSR、100–300 MB なら ESP の目安。- ESP に割り当てられたドライブ文字は Disk Management から削除してもよい。
- 入力後 diskpart コンソールを
exitで閉じ、必ず再起動する。
修復後のディスク構成確認
Windows ロゴ起動後 Win＋X → Disk Management を開き、次の状態になっていれば OK。
| 区画 | ボリューム名 | ファイル システム | 容量 | ドライブ文字 |
|---|---|---|---|---|
| EFI システム | (表示なし) | FAT32 | 100–300 MB | なし |
| MSR | (表示なし) | (未フォーマット) | 16 MB | なし |
| Windows | OS | NTFS | ●● GB | C: |
インプレース アップグレードの再試行
- Windows Update で 23H2 を再実行。更新チェック → 再起動。
- または 24H2 ISO を公式サイトから取得し、右クリック → マウント →
setup.exe。 - 「個人用ファイルとアプリを引き継ぐ」を選択。ネットワーク切断は不要。
- 2–3 回の再起動後、設定 → システム → バージョン情報 で
24H2 (OS Build 26100.x)を確認。
23H2 を飛ばして 24H2 へ直接更新しても大丈夫？
問題ない。Windows 11 の機能更新は「累積的」ではなく「フルビルド上書き」方式であるため、24H2 ISO には 22H2 → 23H2 への差分も丸ごと含まれる。23H2 は 2025年11月11日 までサポートされるが、24H2 へ移行した PC では自動的に 24H2 のサービス期間（Home/Pro で 24 か月）が適用される。なお 23H2 を一旦適用したあと、Windows Update が即座に 24H2 を要求することはなく、AI ベースの段階的ロールアウト (Gradual Rollout Control) に従って配信される。
よくある質問 (FAQ)
Q1. コマンドを実行しても空き領域が増えないのは？ A. diskpart ではなく通常の PowerShell ウィンドウに入力している可能性がある。タイトルバーに「Administrator: DISKPART」と表示されているか確認。 Q2. MBR ディスクでも同様のエラーになる？ A. 通常 0x80070003 – 0x40008 は GPT 固有の構造体不整合で発生する。MBR 構成の場合はスタック トレースを確認し、$WINDOWS.~BT の破損やドライバー衝突を疑う。 Q3. ESP を 100 MB から 300 MB に拡張したい。 A. 24H2 以降のセットアップは 100 MB でも動作するが、Extensible Firmware Interface モジュールの増加に備え 260 MB 以上が推奨。空き領域が連続していれば microsoft-disklayout.exe -extend esp ツール (ADK 付属) でオンライン拡張可能。 Q4. GUID を修正しても 0x800F0922 に変化した。 A. .NET Framework 3.5 の有効化失敗または回復パーティション不足が原因。DISM で .NET を削除し再度インストールするか、回復パーティションを 1 GB へ再作成する。
まとめ ― GPT パーティションを正すだけで解決するケースが大半
Windows 11 の大型アップデートに失敗するとドライバーやサービスなど多角的に原因を探してしまいがちだが、実際には ESP / MSR の GUID と属性 が誤っているだけの単純な構造問題が多い。diskpart で 10 行弱のコマンドを正確に入力し、再起動後に Disk Management で構成を確認すれば、ほぼ確実に 23H2／24H2 へ移行できる。本記事の手順を実践しても解決しない場合は、setuperr.log と setupact.log の末尾 100 行を確認し、別の原因 (失敗しているドライバー名や欠落ファイル) を特定しよう。
コメント