Windows 10からWindows 11へのアップグレードがSECOND_BOOTで87%失敗する原因とUUP dumpを使った解決策

Windows 10 から Windows 11 へのアップグレードが、毎回 87% あたりで止まって失敗する──クリーンブートや TPM、空き容量など基本条件を満たしているのに進まないと、原因が分からず非常にストレスです。この記事では、SECOND_BOOT フェーズの MIGRATE_DATA でコケるケースをテーマに、実際に「アプリと設定を保持したまま」解決できた手順と、その背景にある技術的な理由を丁寧に解説します。

目次

Windows 10 → 11 アップグレードが 87% 前後で失敗する症状

まず、今回のトラブルの典型的なパターンを整理します。

  • Windows 10 から Windows 11 へアップグレードしようとすると進捗バーが 87% 前後で停止し、最終的に元の Windows 10 にロールバックされる。
  • 実行方法は何を使っても同じ結果:
    • Windows Update 経由のアップグレード
    • 公式 ISO からのセットアップ
    • インストール アシスタント(インストール アシスタント ツール)
  • 環境としては、いわゆる「お作法」はきっちり守っている。
    • クリーンブート(不要な常駐をオフ)
    • TPM 2.0 有効化済み
    • システムドライブの空き容量は十分(30GB 以上)
    • 周辺機器は最小構成(キーボード、マウス程度)
    • サードパーティ製ウイルス対策ソフトなし(Windows Defender のみ)
    • sfc /scannow と DISM /RestoreHealth もエラーなし

それにもかかわらず、アップグレードは SECOND_BOOT フェーズで失敗し、以下のようなエラーが記録されます。

項目内容
レジストリに残るエラー0x800704C7(操作が取り消された/タイムアウト系)
セットアップ画面に表示されるエラー0xC1900191 - 0x400D(SECOND_BOOT フェーズの MIGRATE_DATA 中に失敗)
SetupDiag結果ファイルが空(決定的な原因が拾えない)
Panther ログUWP / ストアアプリ(AppX)の事前登録・移行処理の記録が目立つ

パッと見では、「ユーザーが操作を取り消した」ように見えるエラーですが、実際には何も触っていないことがほとんどです。ここに、このトラブルのややこしさがあります。

エラーコードとアップグレードフェーズを理解する

原因に近づくために、まずはエラーコードとセットアップフェーズの意味を押さえておきましょう。

0x800704C7 と 0xC1900191-0x400D の意味

  • 0x800704C7:一般的には「操作が取り消された」「キャンセルされた」ことを表すエラー。ユーザー操作だけでなく、内部的なタイムアウト等でも記録されることがあります。
  • 0xC1900191:Windows セットアップ全体として「ロールバックした(アップグレードに失敗した)」ことを意味するエラー。
  • 0x400D:失敗した詳細フェーズを表すコードで、ここでは MIGRATE_DATA(データ移行)のタイミングを示します。

つまり、「SECOND_BOOT フェーズで、既存データ(アプリや設定、UWP アプリなど)を Windows 11 側へ移行している途中で何かがつまずき、その結果ロールバックした」と読み解けます。

アップグレードフェーズのざっくりした流れ

フェーズ名概要進捗バーの目安
DOWNLEVELWindows 10 上でセットアップを開始し、必要ファイルをコピーする段階0~30% 程度
SAFE_OS再起動後の WinPE 環境での処理。ファイルコピーや基本構成30~50% 程度
FIRST_BOOT新 OS で最初に起動し、基本コンポーネントをセットアップ50~70% 程度
SECOND_BOOTユーザーデータやアプリ、ストアアプリなどの移行(MIGRATE_DATA)を含む70~90% 程度(87% 前後で止まりやすい)

今回のケースは、この SECOND_BOOT の MIGRATE_DATA フェーズで固まってしまうパターンです。

結論:UUP dump で作成した最新 ISO + 動的更新オフで成功

本題の結論から言うと、次の組み合わせでアプリや設定を保持したまま Windows 11 へのアップグレードに成功しました。

  • UUP dump を使って最新の Windows 11 ISO を自作する
  • その ISO からインプレースアップグレードを実行し、セットアップ時の「更新プログラムのダウンロード」を『今は実行しない』に設定(=動的更新 Dynamic Update を無効化)

言い換えると、「できるだけ新しい ISO」+「できるだけオフラインに近い状態」でアップグレードしたら通った、というイメージです。

ポイント狙い
UUP dump で最新 ISO を作る古い ISO で起こる不具合(互換性・ドライバー・差分の多さ)を回避する
動的更新(Dynamic Update)をオフアップグレード中に“余計な差し替え”や新しい互換性チェックが入るのを防ぐ
インプレースアップグレードアプリや設定、データを保持したまま移行する

次の章から、具体的な手順と注意点を詳しく見ていきます。

UUP dump で Windows 11 最新 ISO を作成する手順

UUP dump は、Microsoft の UUP(Unified Update Platform)ファイルを利用して、手元で Windows の ISO イメージを生成できるスクリプト群です。ここでは概要のみ説明します。

※UUP dump はサードパーティの仕組みです。業務環境で利用する場合は、組織のポリシーに従ってください。

事前準備

  • Windows 10 上で作業(管理者権限あり)
  • ISO 作成用に十分な空き容量(目安:20~30GB 程度)
  • 高速なインターネット回線(UUP ファイルのダウンロードが発生)

UUP dump パッケージの取得~展開

  1. ブラウザで「UUP dump」を検索し、UUP dump のサイトへアクセスします。
  2. 目的とする Windows 11 のバージョン・エディション・言語・アーキテクチャ(x64 など)を選択します。
    • 例:Windows 11 23H2、Japanese、x64、Pro など
    • 現在の Windows 10 と同じエディションに合わせておくとライセンス移行がスムーズです。
  3. 「Download using aria2 and convert」などのオプションを選び、ダウンロード用の ZIP ファイルを取得します。
  4. ZIP ファイルを任意のフォルダ(例:C:\UUP)に展開します。

uup_download_windows.cmd の実行と ISO 生成

  1. 展開したフォルダ内にある uup_download_windows.cmd を右クリックし、「管理者として実行」します。
  2. コマンドプロンプトが起動し、自動的に UUP ファイルのダウンロードと ISO への変換処理が進みます。
    • 途中で言語やエディションなどの確認が入る場合があります。
    • 回線速度によってはかなり時間がかかるため、PC がスリープしないように設定しておきます。
  3. 処理が最後まで完了すると、同じフォルダ内に Windows 11 の ISO ファイル(例:22631.〇〇〇_windows_11.iso)が生成されます。
ファイル名役割
uup_download_windows.cmdUUP ファイルのダウンロード+ISO 変換を自動実行するメインスクリプト
各種 .esd / .cab ファイルWindows イメージの構成要素(途中生成物)
Windows 11 ISO最終的に使用するインストールメディア(マウントしてアップグレードに使用)

ここまでできれば、あとはこの ISO を使ってインプレースアップグレードを実行するだけです。

動的更新をオフにしてインプレースアップグレードする手順

次に、作成した ISO を使って実際にアップグレードを行う具体的な手順を説明します。ポイントは、セットアップの途中で「更新プログラムのダウンロード」を無効にすることです。

ISO をマウントしてセットアップを開始

  1. 作成した Windows 11 ISO ファイルをダブルクリックしてマウントします。
    • エクスプローラー上で、新たに DVD ドライブとして表示されます。
  2. マウントされたドライブ内の setup.exe を右クリック → 「管理者として実行」します。
  3. ユーザーアカウント制御(UAC)の確認が出たら「はい」を選択します。

動的更新(Dynamic Update)を「今は実行しない」に設定

セットアップの最初の方に、「更新プログラムのダウンロード」や「更新プログラムの入手方法を変更」といった画面が表示されます。

  1. 「更新プログラムのダウンロード方法を変更」リンクをクリックします。
  2. 表示される選択肢から 「今は実行しない」を選びます。
  3. その状態で次へ進みます。

これにより、セットアップ中に行われる 動的更新(Dynamic Update) が無効化されます。結果として、

  • 最新の互換性チェック定義やドライバーが途中で追加・差し替えされない
  • SECOND_BOOT でのデータ移行処理(特に UWP / ストアアプリ周り)が、より「素の状態」で実行される

という状態になります。

「個人用ファイルとアプリを引き継ぐ」を選択

  1. ライセンス条項に同意した後、引き継ぐ内容を確認する画面で 「個人用ファイルとアプリを引き継ぐ」が選ばれていることを確認します。
  2. 必要に応じて Windows 11 側で不要な機能(例:一部のプライバシー設定など)を調整しつつ、セットアップを進めます。
  3. あとは再起動を待ち、SECOND_BOOT を含む全フェーズが完了するまで触らずに待機します。

この方法で、同じ PC 環境・同じアプリ構成のままでも、SECOND_BOOT / MIGRATE_DATA で失敗していたアップグレードが通るケースがあります。

なぜ「動的更新オフ+最新 ISO」で解決したのか

では、なぜこの方法が効いたと考えられるのでしょうか。ポイントは次の 2 つです。

  • UWP / ストアアプリ(AppX)と State Repository データベース
  • 動的更新(Dynamic Update)が持ち込む“余計な変化”

AppX / State Repository の不整合が MIGRATE_DATA をこじらせる

Panther ログの内容を見ると、SECOND_BOOT フェーズで AppXSVC(AppX 配布サービス)や、ストアアプリに関する処理が目立つことがあります。特に、

  • UWP / ストアアプリの登録情報
  • State Repository データベース(StateRepository-*.edb など)

に不整合があると、移行処理中に「一部アプリだけ動作が合わない」「参照できないパスがある」などの理由で失敗し、その結果として 0xC1900191 - 0x400D が出ることがあります。

動的更新がトリガーになることがある

動的更新(Dynamic Update)は本来、

  • 最新の互換性チェック(Appraiser)
  • 最新のセットアップ コンポーネント
  • 新しいドライバーや累積更新の一部

などをセットアップの途中で適用し、より安全なアップグレードを実現するための仕組みです。しかし、環境によっては、

  • 新しい互換性チェックが既存のアプリや設定と噛み合わない
  • 途中で適用されたドライバーが、アップグレード時の再起動フェーズで不安定な挙動を引き起こす
  • AppX / State Repository 周りに影響する更新が入り、不整合が顕在化する

といった「副作用」が発生し、結果として MIGRATE_DATA フェーズでロールバックすることもあります。

要因MIGRATE_DATA への影響本記事の対策
AppX / State Repository の不整合UWP / ストアアプリの移行途中でエラーになりやすい最新 ISO +動的更新オフで、余計な変更を加えずに移行
動的更新によるコンポーネント差し替えSECOND_BOOT 直前・直後で環境が変わり、移行処理が失敗する「今は実行しない」で動的更新を無効化
古い ISO によるアップグレード差分が大きく、内部的なマイグレーションが複雑になりがちUUP dump でできるだけ新しい ISO を利用

このような背景から、「最新 ISO」かつ「動的更新オフ」という構成は、SECOND_BOOT / MIGRATE_DATA でのトラブルを避ける一つの有効なパターンと考えられます。

それでもダメなときの追加対処(優先度順)

ここまでの手順でもうまくいかない場合は、次のような追加対処を検討します。優先度の高いものから順に試してみてください。

1. Windows 10 側の修復インプレースアップグレード

まずは元の Windows 10 を「上書きインストール」で整える方法です。Media Creation Tool(MCT)や公式 ISO を用いて、

  • 同じバージョン・エディションの Windows 10
  • 「個人用ファイルとアプリを引き継ぐ」を選択

という条件でインプレースアップグレードを行います。これにより、

  • システムファイルやコンポーネントの破損を修復
  • AppX / State Repository を含む内部状態をクリーンに近づける

ことが期待できます。同じインプレースアップグレードでも、別の ISO(ビルド違い)で実行すると成功するケースもあるため、「一度やったからもう意味がない」と決めつけず、バージョンを変えて再チャレンジする価値があります。

2. State Repository データベースをリセットしてから修復インプレース

Panther ログで AppX / State Repository 周りのエラーが目立つ場合は、思い切って State Repository データベースをリセットする方法もあります。

ただしこの操作は、一時的に「スタート」や「設定」アプリが開けなくなるなど副作用が大きいため、C ドライブ全体のイメージバックアップを取得してから行うことを強く推奨します。

State Repository のバックアップ&削除例(管理者コマンドプロンプト)

md C:\SRBackup
cd /d C:\ProgramData\Microsoft\Windows\AppRepository
copy StateRepository-* C:\SRBackup\

そのうえで、StateRepository-* ファイルを別フォルダに退避するか削除し、続けて Windows 10 の修復インプレースアップグレードを実行します。これにより、State Repository データベースが再生成されます。

再生成後に状態が安定したら、改めて Windows 11 へのアップグレード(できれば本記事の UUP dump +動的更新オフの手順)を試す、という流れです。

3. クリーンインストール(アプリ非保持)

最後の手段は、クリーンインストールで Windows 11 を入れ直す方法です。これを選ぶ場合は、

  • C ドライブのアプリはすべて再インストール
  • D ドライブなど他ボリュームにインストールしているアプリ(SQL Server / Visual Studio / Adobe 製品など)も、基本的に再セットアップ前提
  • ドメイン参加・ライセンス認証・各種ポリシーの再適用

といった作業を見込んでおく必要があります。とはいえ、環境が複雑にこじれている場合は、クリーンインストールが最も早くて確実な解決策になることも多いのが実情です。

対処方法アプリ/設定の保持作業コスト成功しやすさ
UUP dump ISO +動的更新オフほぼ保持される小~中高(本記事メイン手順)
Windows 10 修復インプレース保持される中中~高
State Repository リセット+修復概ね保持されるが一部再設定が必要中~大中
クリーンインストールほぼ保持されない大ほぼ確実

アップグレード前後のチェックリスト

ここで、SECOND_BOOT / MIGRATE_DATA の失敗を避けるうえで役立つチェックポイントをまとめておきます。

アップグレード前に確認しておくこと

  • システムイメージの取得
    • 例:Macrium Reflect などのイメージバックアップソフトを使い、C ドライブ全体のイメージを作成。
    • 「最悪元に戻せる」状態を作っておくことが、心理的にも大きな安心につながります。
  • 周辺機器を最小構成に
    • キーボード・マウス・モニタ程度に絞る。
    • 外付けストレージや USB 機器、プリンターなどは可能な限り外す。
  • ディスク空き容量の確保
    • システムドライブ(通常 C:)の空き容量は30GB 以上を目安に。
    • 使っていないアプリや不要な一時ファイルを整理しておく。
  • ネットワークと更新の扱い
    • セットアップ画面では「更新プログラムのダウンロード」を「今は実行しない」にする。
    • 必要に応じて LAN ケーブルを抜くなど、半オフライン状態での実行も検討。

アップグレード後に実施すること

  • Windows Update の実行
    • アップグレードが成功したら、まずは Windows Update を実行して累積更新プログラムやドライバーを最新にする。
  • アプリ・サービスの動作確認
    • 業務で使うアプリ(Office、ブラウザ、各種業務ソフト、開発環境など)を一通り起動して動作確認。
  • バックアップポリシーの見直し
    • Windows 11 側でも定期的なバックアップスケジュールを設定し直す。

ログとコマンドで状態を確認する

アップグレードトラブルの解析には、システムファイルの整合性チェックとログの確認が欠かせません。

基本コマンド(事前整備)

管理者権限のコマンドプロンプトで、次のコマンドを実行しておきます。

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
  • SFC:システムファイルチェッカー。破損したシステムファイルを検出・修復します。
  • DISM:コンポーネントストアの整合性をチェックし、必要に応じて修復します。

これらがいずれも正常に完了していることは、アップグレードに挑戦する最低限の前提条件と考えてよいでしょう。

Panther ログの場所と見るポイント

アップグレードが失敗した際には、次のようなログファイルを確認します。

C:\$WINDOWS.~BT\Sources\Panther\setupact.log
C:\$WINDOWS.~BT\Sources\Panther\setuperr.log
  • setuperr.log:エラーを中心に記録したログ。致命的なエラーを探すときの入口。
  • setupact.log:詳細な動作ログ。SECOND_BOOT や MIGRATE_DATA、AppX、StateRepository といったキーワードで検索していくと、原因の手がかりが見つかることがあります。

SetupDiag を使ってもログがほとんど解析されない(結果ファイルが空)場合は、エラーがかなり限定的なタイミングで発生していることも多く、SECOND_BOOT / MIGRATE_DATA のようにニッチなフェーズのトラブルが疑われます。

ディスククローン・パーティション構成の影響について

今回のケースでは、最終的に「UUP dump +動的更新オフ」で解決しているため、致命的なディスクレイアウトの問題ではないと考えられます。しかし、似たトラブルで再発する場合は、次の点も確認してみてください。

  • ディスククローン後の回復パーティションの位置
    • クローンツールによっては、回復パーティションが先頭・末尾に移動していることがあります。
  • EFI システムパーティション(ESP)や MSR の有無
    • UEFI / GPT 環境では、ESP や MSR が適切に存在しないとアップグレード時に問題になることがあります。
  • BCD(ブート構成データ)の整合性
    • クローンツールや手動操作により、BCD エントリが意図せず変更されているケースもあります。

パーティション構成に問題が疑われる場合は、ディスク管理ツールや diskpart などでレイアウトを確認し、必要に応じてクリーンインストール時に適切な構成で再作成することも検討してください。

よくある質問(FAQ)

Q. Windows Update からのアップグレードと何が違うの?

A. Windows Update からのアップグレードも内部的には同じセットアップエンジンを使っていますが、

  • 使用されるイメージのタイミング・構成
  • ダウンロードされる動的更新(Dynamic Update)の内容

などの違いから、ISO からのインプレースアップグレードとは微妙に挙動が異なります。特に、この記事のように「動的更新をオフ」にすることで改善したケースでは、Windows Update よりも ISO からの手動アップグレードの方が安定することがあります。

Q. 動的更新をオフにするとセキュリティ的に問題はない?

A. アップグレード中に適用される更新(Dynamic Update)をスキップするだけなので、アップグレード完了後に Windows Update を実行して最新状態にすれば、セキュリティ上の問題はありません。むしろ、アップグレードそのものが成功しないことの方が長期的にはリスクになり得ます。

Q. UUP dump を使うのは公式ツールじゃないので不安です…

A. UUP dump は、Microsoft が提供する UUP ファイルを元に ISO を組み立てる仕組みであり、内部のイメージ自体は公式のものです。ただし、UUP dump 自体はサードパーティのプロジェクトであるため、組織のポリシーや規制によっては利用できない場合もあります。その場合は、できるだけ新しい公式 ISO を利用する形で、同様に「動的更新をオフ」にして試すのがおすすめです。

Q. どうしても原因が特定できないときは?

A. SECOND_BOOT / MIGRATE_DATA の失敗は、環境ごとの要素が絡み合っていることが多く、「これ」と断定しにくいのが正直なところです。そのため、

  • 本記事のような「動的更新オフ+最新 ISO」アプローチ
  • Windows 10 側の修復インプレースアップグレード
  • State Repository リセットやクリーンインストール

といった複数の解決策を段階的に試し、「安定して Windows 11 に移行できるライン」を見つけていくことになります。

まとめ:SECOND_BOOT / MIGRATE_DATA の失敗を回避して Windows 11 へ

SECOND_BOOT フェーズで 0xC1900191 - 0x400D が出るアップグレード失敗は、ログからも原因が見えにくく、対処に時間がかかりがちなトラブルです。しかし、今回紹介したように、

  • UUP dump で作成した最新の Windows 11 ISO を使用する
  • セットアップ中の「更新プログラムのダウンロード」は『今は実行しない』に設定し、動的更新をオフにする
  • それでもダメなら Windows 10 側の修復インプレースや State Repository のリセットを検討する
  • 最終的には クリーンインストールも視野に入れる

といった段階的なアプローチを取ることで、アプリと設定をできるだけ保持したまま Windows 11 に移行できる可能性が高まります。

同じように SECOND_BOOT / MIGRATE_DATA で悩んでいる方は、まずは「UUP dump で作った最新 ISO」+「セットアップの更新は今は実行しない」という組み合わせから試してみてください。それだけで状況が大きく好転するケースが少なくありません。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次