Windows 11 や Windows Server 2025 でマスターイメージを作成する際、いざ Sysprep を実行した瞬間に以下のようなエラーで弾かれてしまった経験はありませんか？
システム準備ツール 3.14
Sysprep で Windows のインストールを検証できませんでした。詳細については、%WINDIR%\System32\Sysprep\Panther\setupact.log にあるログ ファイルを確認してください。問題を解決してから、Sysprep を使用してインストールを再度検証してください。
Windows 11 や Server 2025 では、特定のユーザーにのみインストールされている Storeアプリ（Appxパッケージ） が存在すると、Sysprep（/generalize）が失敗する仕様になっています。インターネット経由で日本語化パッケージなどを追加した際にも、裏でAppxが導入されてSysprepが失敗することがよくあります。
今回は、この厄介な「Appxエラー」がどのような条件で発生し、どうすれば解決できるのかを、実際のコマンドを使って「あえてエラーを起こして、それを直す」という検証フローで分かりやすく解説します！
参考：Microsoft 公式ドキュメントSysprep が失敗する – Microsoft Store アプリの削除または更新
事前確認（ターゲットのAppxが入っていないことの確認）
まずは、検証に使うアプリ（今回は例として「Windows電卓」）が、現在のシステムに入っていないまっさらな状態であることを確認します。
PowerShellを管理者権限で起動し、以下の検索コマンドを実行します。
Get-AppxPackage -AllUsers -Name *WindowsCalculator*ここで何も表示されずに次の行に進めばOKです。システム上に電卓アプリは存在していません。
Appxの導入（意図的にSysprepを失敗させる準備）
次に、エラーの原因となる「特定のユーザーだけが持っているアプリ」を意図的に作り出します。 winget コマンドを使って、ストアから電卓アプリをインストールします。
winget install --id 9WZDNCRFHVN5 --accept-source-agreements --accept-package-agreements
↓↓↓↓実行結果↓↓↓↓
PS C:\WINDOWS\system32> winget install --id 9WZDNCRFHVN5 --accept-source-agreements --accept-package-agreements
'msstore' ソースでは、使用する前に次の契約を表示する必要があります。
Terms of Transaction: https://aka.ms/microsoft-store-terms-of-transaction
ソースが正常に機能するには、現在のマシンの 2 文字の地理的リージョンをバックエンド サービスに送信する必要があります (例: "US")。
見つかりました Windows Calculator [9WZDNCRFHVN5] バージョン Unknown
このパッケージは Microsoft Store から提供されています。winget は、現在のユーザーに代わって Microsoft Store からパッケージを取得する必要がある場合があります。
（中略）
パッケージのインストールを開始しています...
██████████████████████████████ 100%
インストールが完了しました
インストール完了後、もう一度検索コマンドを実行すると、今度は Microsoft.WindowsCalculator... の詳細情報がズラッと表示されるはずです。これで「Sysprepが失敗する環境」の出来上がりです。
PS C:\WINDOWS\system32> Get-AppxPackage -AllUsers -Name *WindowsCalculator*
Name : Microsoft.WindowsCalculator
Version : 11.2508.4.0
PackageFullName : Microsoft.WindowsCalculator_11.2508.4.0_x64__8wekyb3d8bbwe
PackageUserInformation : {S-1-5-21-XXXX-XXXX-XXXX-500 [Administrator]: Installed}
Status : Ok
PS C:\WINDOWS\system32>Sysprepの実行とエラー確認（ログの読み方）
この状態で Sysprep を実行してみましょう。（※検証目的のため、再起動しない /quit オプションを使用します）
C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /quit結果： 見事に「SysprepでWindowsのインストールを検証できませんでした」というダイアログが表示され、処理がストップします。これは、インターネット経由での日本語化パッケージなどを追加しても、appxが導入されるため、sysprepが失敗します。
システム準備ツール 3.14
Sysprep で Windows のインストールを検証できませんでした。詳細については、%WINDIR%\System32\Sysprep\Panther\setupact.log にあるログ ファイルを確認してください。問題を解決してから、Sysprep を使用してインストールを再度検証してください。
という内容でsysprepが失敗します。
ここで重要になるのがエラーログです。なぜ失敗したのかを確認するため、以下のコマンドでログ（setuperr.log）の末尾を表示します。
Get-Content -Path "C:\Windows\System32\Sysprep\Panther\setuperr.log" -Tail 20
2026-06-07 15:30:10, Error SYSPRP Package Microsoft.Winget.Source_2026.607.606.27_neutral__8wekyb3d8bbwe was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.ログを確認すると、想定外の事実が判明します。電卓アプリ（Appx）以外に、Winget自体のAppxリポジトリ（Microsoft.Winget.Source）も自動的に導入されていました。 Sysprepは一番最初に見つけた不整合でストップするため、「Winget（Appx）が原因でSysprepをブロックした」と記録されています。
まずは、この Winget を削除するため、ログから PackageFullName（長い文字列）をメモして削除コマンドを実行します。
PS C:\WINDOWS\system32> Remove-AppxPackage -Package "Microsoft.Winget.Source_2026.607.606.27_neutral__8wekyb3d8bbwe"
PS C:\WINDOWS\system32> Get-AppxPackage -AllUsers -Name *WindowsCalculator*
Name : Microsoft.WindowsCalculator
Publisher : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US Architecture : X64 ResourceId : Version : 11.2508.4.0 PackageFullName : Microsoft.WindowsCalculator_11.2508.4.0_x64__8wekyb3d8bbwe InstallLocation : C:\Program Files\WindowsApps\Microsoft.WindowsCalculator_11.2508.4.0_x64__8wekyb3d8bbwe IsFramework : False PackageFamilyName : Microsoft.WindowsCalculator_8wekyb3d8bbwe PublisherId : 8wekyb3d8bbwe PackageUserInformation : {S-1-5-21-4012110329-1019941659-1994336937-500 [Administrator]: Installed} IsResourcePackage : False IsBundle : False IsDevelopmentMode : False NonRemovable : False Dependencies : {Microsoft.UI.Xaml.2.8_8.2511.26001.0_x64__8wekyb3d8bbwe, Microsoft.NET.Native.Framework.2.2_2 .2.29512.0_x64__8wekyb3d8bbwe, Microsoft.NET.Native.Runtime.2.2_2.2.28604.0_x64__8wekyb3d8bbwe , Microsoft.VCLibs.140.00_14.0.33519.0_x64__8wekyb3d8bbwe...}
IsPartiallyStaged : False
SignatureKind : Store
Status : Ok
PS C:\WINDOWS\system32>これで Winget が削除されました。しかし、本命である「電卓」はまだ残っているため、今一度 Sysprep を実行すると、同様に失敗します。
再度ログ（setuperr.log）を確認してみると、ようやく電卓のパッケージで失敗したログが確認できます。
2026-06-07 15:56:29, Error SYSPRP Package Microsoft.WindowsCalculator_11.2508.4.0_x64__8wekyb3d8bbwe was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.原因Appxの削除
再度原因がログからも特定できたので、エラーを引き起こしているAppxパッケージをシステムから削除します。 メモした PackageFullName を指定して、以下のコマンドを実行します。
PS C:\WINDOWS\system32>
PS C:\WINDOWS\system32> Remove-AppxPackage -Package "Microsoft.WindowsCalculator_11.2508.4.0_x64__8wekyb3d8bbwe"
PS C:\WINDOWS\system32> Get-AppxPackage -AllUsers -Name *WindowsCalculator*
PS C:\WINDOWS\system32>(※文字列の部分は、ご自身のログに出力された正確なパッケージ名に置き換えてください)
削除後、再度検索コマンド（Get-AppxPackage -AllUsers -Name *WindowsCalculator*）を実行し、何も表示されなくなればクリーンアップ完了です。
Sysprepの再実行と成功
障害物がなくなった状態でもう一度 Sysprep を実行してみます。
C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /quit結果： 今度はエラーダイアログが出ることなく、コマンドプロンプトが静かに終了します！
Sysprep成功です！
まとめ
このように、Sysprepの「致命的なエラー」の大半は、マスター作成中に意図せず混入した Appx パッケージが原因です。現場でのキッティング中、もしこのエラーに遭遇しても焦る必要はありません。
setuperr.logを確認して原因の Appx（PackageFullName）を特定するRemove-AppxPackageで対象を削除する
この流れさえ覚えておけば、確実にトラブルを乗り越えてマスターイメージを完成させることができます。ぜひ参考にしてみてください！
⚠️ 構築時の注意：OSの日本語化でSysprepが基本失敗する罠
マスターイメージを日本語化する際、通常の「設定」画面から言語パックを追加すると、内部的にAppxパッケージ（LXP）が現在のユーザーにのみ導入されるため、Sysprep時に高確率でAppxエラーを引き起こします。
Sysprepを前提とする場合は、GUIから追加するのではなく、DISMコマンド（Add-WindowsPackage / Add-WindowsCapability）を使用して、システム全体に.cabファイル形式で言語パックを直接プロビジョニングする必要がありそうです。
「設定アプリを使った手軽な設定変更が、Sysprepにとっては地雷になる」という現代のWindowsの仕組みを理解しておくことで、無駄な手戻りを完全に防ぐことができそうです。
💡 失敗しても回数は減るという残酷な仕様
「Sysprepがエラーで止まったから、回数は消費されていないはず」と思うのは危険です。Sysprepは内部処理がバケツリレー方式で進むため、途中でエラーになって失敗した場合でも、ライセンスの猶予リセット回数（Rearm）だけは容赦なく消費されていることが多々あります。
何度もエラーを出していると「Appxエラーは直したのに、今度は回数上限エラーで結局詰んだ」という悲劇が起きます。
【残り回数の確認方法】
現在の残りリセット回数は、コマンドプロンプトまたはPowerShellで以下のコマンドを実行すると確認できます。
slmgr /dlv
数秒待つと詳細なライセンス情報のウィンドウが表示されます。その中の「残りの Windows 猶予期間リセット可能回数」という項目をチェックしてください。もしここが0になっていると、もうその環境で Sysprep（/generalize）は実行できません。だからこそ、失敗したら「そのままリトライ」ではなく、回数が減る前の「スナップショットからのロールバック」が必須なのです。
参考：Microsoft 公式ドキュメント Sysprep が失敗する – Microsoft Store アプリの削除または更新
