Windows 11 バージョン 24H2 の展開作業で Sysprep を実行すると、SysprepGeneralizeValidate (Appx) の段階で止まり、0x80073cf2 を返して一般化できないケースがあります。本記事では、ログに出る典型的なエラーの意味、原因になっている Microsoft Store（UWP/Appx）アプリの特定方法、PowerShell での削除手順、うまく消えない場合の切り分けまで、実運用で迷いにくい形で整理します。
発生する症状：SysprepGeneralizeValidate (Appx) で失敗し、0x80073cf2 が記録される
Sysprep 実行中に一般化（generalize）の検証フェーズで停止し、C:\Windows\System32\Sysprep\Panther\setupact.log などに次のような行が記録されます。
| ログ例 | 読み解き（何が起きているか） |
|---|---|
SYSPRP Failed to remove apps for the current user: 0x80073cf2 | 「現在のユーザー」に紐づく Appx（UWP）アプリの削除が失敗し、Sysprep が先へ進めない |
SYSPRP Exit code of RemoveAllApps thread was 0x3cf2 | アプリ削除スレッドが 0x3cf2（= 0x80073cf2 と同系統の Appx エラー）で終了 |
Sysprep generalize internal providers; hr = 0x80073cf2 | 一般化処理の内部プロバイダー（Appx チェック含む）がエラーで中断 |
この状態では Sysprep が完了しないため、マスターイメージの一般化ができず、以降の展開（OOBE、複製配布、VMテンプレ化など）が詰まります。
原因：Microsoft Store アプリ（Appx/UWP）の削除に失敗している
Sysprep は一般化の過程で、ユーザー単位で導入された Appx アプリの状態を検証し、必要に応じて削除・整合性確認を行います。ところが Windows 11 24H2 環境では、次のような条件が重なると Appx 側の削除が失敗し、結果として Sysprep 全体が止まります。
- 特定ユーザーのみにインストールされている Store アプリが残っている
（新規ユーザーに配布される「プロビジョニング」状態ではなく、ログオンしたユーザーにだけ入っている状態） - アプリの更新・修復が中途半端な状態
Store の自動更新、バックグラウンド更新、依存コンポーネントの更新が絡み、削除対象がロック/不整合になっている - Appx の実体が破損・欠損している
配置情報は残るが、実ファイルが揃っていないなどで削除 API が失敗する
本件のポイントは、エラーコードそのものよりも、「setupact.log に列挙される “問題のパッケージ” が Sysprep を止めている」ことです。原因アプリが 1 つとは限らず、複数列挙されている場合は列挙分をすべて潰す必要がある、というのが現場でハマりやすい点です。
最初に確認したい前提（Sysprep を成功させるための土台）
Appx 削除に入る前に、Sysprep の成功率を上げるための前提を軽く点検しておくと、切り分けが速くなります。
| チェック項目 | 確認内容 | 理由（失敗しやすいポイント） |
|---|---|---|
| OS の状態 | 更新直後・更新途中ではない（再起動未完了が残っていない） | Appx/Store 更新が途中だと削除や整合性確認が失敗しやすい |
| 作業ユーザー | 展開用のローカル管理者で作業し、余計な Microsoft アカウントログインを避ける | ユーザー単位の Store アプリ導入が増えるほど、Sysprep の Appx 検証が難しくなる |
| 不要アプリの導入 | イメージ作成中に手動で Store アプリを追加しない | ユーザー専用導入の Appx が増えると失敗原因の母数が増える |
| バックグラウンド動作 | Widgets/Store/更新関連が動き続けていない（再起動で落ち着かせる） | 削除対象の Appx が使用中だと削除に失敗することがある |
ただし、これらが完璧でも 24H2 では Appx 起因で止まることがあるため、次の「ログで原因パッケージを特定」が本丸です。
問題のあるアプリを特定する：setupact.log を読む
原因特定は、Sysprep のログを見て「どの Appx パッケージが失敗しているか」を拾うのが最短です。
見るべきログ
C:\Windows\System32\Sysprep\Panther\setupact.log- （併せて）
C:\Windows\System32\Sysprep\Panther\setuperr.log
探し方のコツ（手作業でも、コマンドでもOK）
メモ帳で開いて検索してもよいですが、行数が多い場合はコマンドで絞ると早いです。
findstr /i "SYSPRP Appx 0x80073cf2 RemoveAllApps" C:\Windows\System32\Sysprep\Panther\setupact.logログ内には、例えば次のように “原因候補のパッケージ名（アプリ）” が出てきます。
Microsoft.WidgetsPlatformRuntime_1.6.1.0_x64__8wekyb3d8bbwe（例）
重要：ログに複数のパッケージが列挙されている場合、記録された該当パッケージをすべて対象にするのが基本です。1 つだけ消しても別のパッケージで同じ箇所が止まり、結局 Sysprep が通らないことがあります。
対処：PowerShell で該当 Appx を削除する（基本手順）
原因パッケージが特定できたら、PowerShell で削除します。ここでは「ログに出ているパッケージを確実に消す」ために、実務で安全な進め方を紹介します。
手順1：管理者として PowerShell を起動
スタートメニューから PowerShell を右クリックし、管理者として実行します。
手順2：ログに出ている “パッケージ名” を確認し、正確な値を使う
Sysprep のログに出る文字列は、Remove-AppxPackage が受け取れる形式（PackageFullName 相当）であることが多い一方、環境によって表示揺れや関連パッケージが存在します。まずは PowerShell 側で該当が存在するか確認すると事故が減ります。
# 例：WidgetsPlatformRuntime が絡む場合（キーワードは環境に合わせて調整）
Get-AppxPackage | Where-Object { $_.PackageFullName -like "*WidgetsPlatformRuntime*" } |
Select-Object Name, PackageFullNameここで出てくる PackageFullName を、削除コマンドにコピペするのが確実です。
手順3：該当パッケージを削除する
ログで特定したパッケージごとに削除します（以下は例）。
Remove-AppxPackage -Package Microsoft.WidgetsPlatformRuntime_1.6.1.0_x64__8wekyb3d8bbwe- 上記は例なので、実際には
setupact.logに記録されているパッケージ名に置き換えます。 - ログに出ている問題パッケージをすべて削除します。
削除後、念のため該当が残っていないかを確認します。
# 例：削除後に残っていないことを確認
Get-AppxPackage | Where-Object { $_.PackageFullName -like "*WidgetsPlatformRuntime*" } |
Select-Object Name, PackageFullNameプロビジョニング済みアプリも削除が必要になるケース
展開の作法として、ユーザー単位（現在のユーザー）から消しただけでは不十分で、OS のプロビジョニング領域（新規ユーザーに自動で入る “種”）も消したい場面があります。特に、イメージを複製して多数展開する場合、後から作られるユーザーにも同じアプリが入ってしまい、将来的な不具合や再現を誘発することがあります。
その場合は、次のようにプロビジョニング済みパッケージを確認し、該当があれば削除を検討します（運用に影響が出るため、必ず検証環境でテストしてから適用してください）。
# プロビジョニング済みパッケージの一覧
Get-AppxProvisionedPackage -Online | Select-Object PackageName# 該当のプロビジョニング済みパッケージを削除（例：<PackageName> を置き換え）
Remove-AppxProvisionedPackage -Online -PackageName <上で確認したパッケージ名>ここでのポイントは次の通りです。
- Remove-AppxPackage：既に存在するユーザーから削除する
- Remove-AppxProvisionedPackage：今後作られる新規ユーザーに入らないよう “種” を外す
うまく削除できない／削除したのに残る場合の切り分けポイント
現場では「コマンドを実行してもエラーが出ず、アプリが残ったまま」と感じることがあります。公式な単一解は提示されていないことも多いため、一般的な切り分け観点を押さえて “詰まりどころ” を潰していくのが現実的です。
| よくある状況 | 確認ポイント | 対処の方向性 |
|---|---|---|
| 対象ユーザーが違う | その Appx がインストールされているユーザーで実行しているか | 対象ユーザーでログオンして削除、または必要に応じて全ユーザー/プロビジョニング側も確認 |
| パッケージ名の指定がズレている | Get-AppxPackage の PackageFullName と完全一致しているか | ログ文字列を盲信せず、PowerShell 出力からコピペして再実行 |
| アプリが使用中 | ウィジェット/ストア/関連プロセスが動いていないか | 再起動してから削除、不要なら関連アプリを起動しない状態で実施 |
| Store 更新が裏で走っている | 更新直後・再起動待ち・バックグラウンド更新中でないか | 再起動、更新完了後に再度削除→Sysprep |
| コンポーネントストア不整合 | システムファイル破損や整合性崩れの兆候があるか | DISM/SFC で修復してから再実施 |
修復系コマンド（Appx 以前に OS 側の整合性を戻す）
Appx が壊れている／削除が安定しないときは、OS の整合性を戻すだけで改善することがあります。
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannowこの後に改めて Appx 削除 → Sysprep の順で試すと、ログの進み方が変わることがあります。
「現在のユーザー」問題に寄せた現実的な考え方
本エラーのメッセージが示す通り、まずは“現在のユーザー” にぶら下がっている Appx をきれいにするのが優先です。展開用のイメージ作成では、次のような運用が結果的に最短になることが多いです。
- イメージ作成用の作業ユーザーを固定し、余計なユーザーを増やさない
- Store アプリを追加しない（入れるならプロビジョニング設計も含めて管理する）
- Sysprep 実行直前は余計なアプリを起動しない／再起動して状態を落ち着かせる
Sysprep を再実行する（成功確認まで）
該当 Appx を削除できたら、Sysprep を再実行します。よく使われる例は次の通りです。
sysprep /generalize /oobe /shutdown再実行後の確認は、次の 2 点をセットで見ておくと安心です。
- Sysprep が最後まで進み、シャットダウンまで到達する
- setuperr.log に Appx 関連の致命的エラーが残っていない
C:\Windows\System32\Sysprep\Panther\setuperr.log
もし再度同じフェーズで止まる場合は、setupact.log に別のパッケージが追加で列挙されていないかを確認してください。最初に見えていた 1 つのパッケージを消しても、次の “問題児” が顕在化する、という流れは珍しくありません。
再発防止：Windows 11 24H2 で Sysprep を通しやすくする運用の工夫
0x80073cf2 は「Appx の削除失敗」という結果なので、根本的な再発防止はイメージ作成時に Appx の状態を荒らさないことに寄ります。手戻りを減らすための運用アイデアをまとめます。
作業の順序を固定し、一般化直前に余計な変更を入れない
- OSインストール → 基本設定 → 必須ドライバー/更新 → 最小限の業務アプリ → Sysprep、の順で固定
- Sysprep 直前に Store アプリを触らない（追加・更新・起動）
「作業ユーザーを増やさない」だけでも効く
Sysprep が詰まる理由が “現在のユーザーの Appx” である以上、ログオンして作られるユーザープロファイルが増えるほど、Appx の揺れが増えます。検証のために複数ユーザーでログオンする運用は、イメージ作成工程から分離すると安定します。
削除対象の扱いをルール化する
「どれを消してよいか」が現場でブレると、削除のやり直しや機能欠損に繋がります。最低限、次の観点で社内ルールを作ると事故が減ります。
| 観点 | ルール例 | 狙い |
|---|---|---|
| 業務に不要なプリインストール系 | 検証済みの対象のみ削除し、ログに出たものを機械的に全消ししない | 機能欠損（依存関係）の回避 |
| ユーザー単位の Store アプリ | Sysprep 直前にログ起因のパッケージのみ削除 | Sysprep 成功を最優先にする |
| プロビジョニング | 大量展開を前提にする場合のみ、Remove-AppxProvisionedPackage を検討 | 新規ユーザー作成時の再混入を防ぐ |
Sysprep は「通す」ことが目的になりがちですが、通ったあとに OOBE や初回ログオン、業務アプリ、Windows Update が破綻しては意味がありません。削除や無効化は、最終的に利用者が困らないことを基準に、検証環境で再現性を確認してから本番へ反映するのが安全です。
まとめ：setupact.log に出た Appx パッケージを“全部”潰すのが近道
- Windows 11 24H2 の Sysprep 失敗（0x80073cf2）は、Appx（UWP/Store）アプリ削除の失敗が引き金になりやすい
- まず
setupact.logを見て、原因パッケージ名を特定する - ログに列挙されたパッケージは 1 つとは限らないため、該当分をすべて対象に削除する
- 必要に応じて、プロビジョニング済みパッケージの削除も検討する（影響が大きいので要検証）
- 削除できない場合は「ユーザー」「パッケージ名の一致」「使用中」「更新中」「OS整合性」を順に切り分ける
Sysprep はトラブル時のログが長く、焦ると闇雲なアプリ削除に走りがちです。まずはログに書かれた “止めている当事者（パッケージ）” を淡々と取り除き、最小限の変更で通す——この方針が、結果として最も安全で再現性の高い解決に繋がります。
コメント