Windows 11 24H2／Windows Server 2025 へ更新後、Hyper‑V Version 12 の仮想マシンや Windows Sandbox が「The target device has insufficient resources to complete the operation（0x80070142）」で起動できない――物理リソースは余っているのに。この記事では、原因の仕組みと実務で効く解決策・検証手順を体系化して解説します。
発生条件と症状の整理
以下の条件で高い再現性が報告されています。
- 更新タイミング：Windows 11 22H2 → 24H2、または Windows Server 2022 → 2025 のインプレースアップグレード直後
- エラー表示：
- VM 起動時：“The target device has insufficient resources to complete the operation”（0x80070142）
- Windows Sandbox 起動時：同一メッセージ／同一コードで失敗
- 実情：タスクマネージャーや監視では CPU／RAM に余裕があり、アップデート前は正常動作
結論（先に要点）
24H2／Server 2025 環境の Hyper‑V Version 12 では、スケジューラと vCPU の扱いが厳格化した結果、従来の「vCPU のオーバーコミットで VM を同時多重起動」する設計がそのままでは通用しません。さらに、Core スケジューラを指定しても Classic にフォールバックしたり、SMT（Hyper‑Threading）無効時は Classic 扱いになって実質オーバーコミット禁止になるため、合計 vCPU が論理コア数を超えているだけで 0x80070142 が発生します。Windows Sandbox は NUMA Spanning が ONでないと同様に失敗します。
原因の全体像
| 観点 | 詳細 |
|---|---|
| CPU オーバーコミット禁止 | 24H2／Server 2025 では合計 vCPU 数がホストの論理コア数を超えると VM が起動不可に。Classic スケジューラが強制されやすく、従来のオーバーサブスクライブが通らない。 |
| スケジューラ種別の強制変更 | hypervisorschedulertype を Core に設定しても、起動時に Classic（値 0x2）へフォールバックするケースがある。 |
| SMT/ハイパースレッディング | SMT 無効だと Core 指定でも Classic 動作相当。結果としてオーバーコミット不可に。 |
| NUMA スパン | Windows Sandbox は NUMA Spanning が ONでないと起動時に 0x80070142 を返す。 |
| 機能インストール順序 | Windows Sandbox を後付けすると、内部で必要な Hyper‑V 機能群（Hyper‑V プラットフォーム／仮想マシンプラットフォーム）が正しく構成されない場合がある。 |
技術的背景：Classic と Core の違い
| 項目 | Classic スケジューラ | Core スケジューラ |
|---|---|---|
| 割り当て単位 | 論理コアに対して厳密に vCPU を割り付け | SMT ペアを 1 単位として把握し、より柔軟にスレッドを配置 |
| オーバーコミット | 原則不可（合計 vCPU > 論理コア数で弾かれやすい） | 一定のオーバーサブスクライブを許容（ただし環境差・制約あり） |
| SMT の影響 | SMT 無効でも挙動は不変（厳格） | SMT 無効だと Classic 相当になり、柔軟性が低下 |
| 24H2/Server 2025 での傾向 | フォールバックで Classic 強制となりやすい | Core 指定が反映されず Classic に戻る事例がある |
代表的な失敗パターン（数値例）
以下は 24 論理コア（例：12C/24T）ホストの想定です。
| 構成 | 合計 vCPU | 起動結果（Classic） | 備考 |
|---|---|---|---|
| 8 vCPU × 3 台を同時起動 | 24 | 起動可（ぎりぎり） | 上限ちょうど。他 VM 追加で即失敗 |
| 8 vCPU × 4 台を同時起動 | 32 | 起動不可（0x80070142） | オーバーコミットの典型 |
| 2 vCPU × 10 台 + 4 vCPU × 2 台 | 28 | 起動不可 | バックグラウンド VM を忘れがち |
対処：優先度順ロードマップ
次の順に実施すると、原因の切り分けと影響最小化がしやすくなります。
1. 合計 vCPU を論理コア数以下に収める（最優先）
- 原則：ホスト論理コア数 ≥ 同時に起動している VM の vCPU 総数
- 運用ポイント：一時的に vCPU を減らす／同時起動台数を間引く／起動順序を見直す
# いま動いている VM の vCPU 合計を確認
Get-VM | Where-Object {$_.State -eq 'Running'} |
Measure-Object -Property ProcessorCount -Sum
# すべての VM の vCPU 合計
Get-VM | Measure-Object -Property ProcessorCount -Sum
# ホストの論理プロセッサ数を確認
Get-CimInstance Win32_Processor |
Measure-Object -Property NumberOfLogicalProcessors -Sum 2. Core スケジューラ固定（効く環境限定）
Core が有効化されれば、ある程度のオーバーサブスクライブが可能になる場合があります。
# 管理者権限の PowerShell
bcdedit /set hypervisorschedulertype Core
Restart-Computer
# 反映確認（最新 1 イベント）
Get-WinEvent -FilterHashTable @{ProviderName='Microsoft-Windows-Hyper-V-Hypervisor'; ID=2} -MaxEvents 1 注：環境によっては Classic にフォールバックし、効果が出ない既知挙動があります。その場合は vCPU 合計の是正が最短経路です。
3. SMT（Hyper‑Threading）を有効化
# SMT の有効/無効の目安を確認
wmic cpu get NumberOfCores, NumberOfLogicalProcessors
- 論理プロセッサ数 > 物理コア数 … SMT 有効の目安
- SMT が無効だと Core 指定でも Classic 相当の制約になりやすい。必要に応じて BIOS/UEFI で有効化
4. NUMA Spanning（Distributed NUMA）を ON
- Hyper‑V マネージャー → [ホスト設定] → [NUMA スパンの許可] にチェック
- PowerShell なら：
# 現在の設定確認 Get-VMHost | Select-Object ComputerName, NumaSpanningEnabled # 有効化 Set-VMHost -NumaSpanningEnabled $true - Windows Sandbox は単一 CPU 構成でも NUMA Spanning が OFF だと 0x80070142 で失敗します
5. Windows Sandbox の再インストール
- [Windows の機能の有効化または無効化] から Windows Sandbox をオフ → 再起動
- 再度オンにして再起動
- 最初に Sandbox を起動し、内部の初期更新を完了させる
コマンドで行う場合：
# Sandbox を無効化して再起動
dism /online /Disable-Feature /FeatureName:"Containers-DisposableClientVM" /Quiet /NoRestart
shutdown /r /t 0
# 再起動後に有効化（必要コンポーネント含む）
dism /online /Enable-Feature /FeatureName:"Containers-DisposableClientVM" /All /Quiet /NoRestart
dism /online /Enable-Feature /FeatureName:"Microsoft-Hyper-V" /All /Quiet /NoRestart
dism /online /Enable-Feature /FeatureName:"VirtualMachinePlatform" /All /Quiet /NoRestart
shutdown /r /t 0 6. 機能の依存関係を満たす
- Sandbox を使う場合は Hyper‑V プラットフォーム と 仮想マシンプラットフォーム を併せて有効に
- Hyper‑V のみを後から追加した場合、Sandbox の内部要件が満たされず起動に失敗することがある
7. 一時的な回避策（計画停止／同時起動の抑制）
- 総 vCPU を減らせないときは、同時起動 VM の数を制限し、不要な VM を順次停止してから重要 VM を起動
- ピーク帯のジョブスケジュールを見直し、重い VM の起動時間をずらす
8. 修正パッチの有無を随時確認
- 24H2／Server 2025 の既知問題として扱われる可能性があります。Windows Update／更新カタログ／公式ブログ等のアナウンスを定期的に確認
設計・運用のベストプラクティス
同時起動上限の考え方
Classic 前提では、同時起動 VM の vCPU 総数 ≤ 論理コア数が絶対条件です。Core が安定して効く環境でも、将来のフォールバックを考慮して余裕率 20–30%を見込むと、アップデート時の不意の停止を避けられます。
推奨スケーリング戦略
- vCPU の細分化：8 vCPU × 3 台より、4 vCPU × 6 台の方が起動柔軟性が高いケースが多い
- ロールごとの優先順位：重要度の低い VM から順に自動停止→重要 VM 起動の順序制御を設定
- SMT 前提設計：SMT を有効にし、Core スケジューラの利点を引き出す。ただし無効化方針の組織では Classic 前提の割当計画に切り替え
- NUMA ポリシー整備：Windows Sandbox の存在を考慮し、ホスト単位で NUMA Spanning を ON に統一
現場で役立つ確認ポイント集
| 確認項目 | 確認コマンド／場所 | 合格基準／対処 |
|---|---|---|
| ホスト論理コア数 | Get-CimInstance Win32_Processor | 同時稼働 vCPU 総数 ≤ 論理コア数 |
| 現在の vCPU 総数 | Get-VM | ? State -eq 'Running' | Measure -Sum ProcessorCount | 超過していれば停止/削減 |
| スケジューラ種別 | イベントログ：Microsoft‑Windows‑Hyper‑V‑Hypervisor（ID=2） | Core 適用が理想。Classic なら vCPU 計画の見直し |
| SMT 状態 | wmic cpu get NumberOfCores,NumberOfLogicalProcessors | 論理 > 物理＝SMT 有効。無効なら BIOS/UEFI で有効化 |
| NUMA Spanning | Get-VMHost / Hyper‑V マネージャー | Enabled（Windows Sandbox の必須要件） |
| Sandbox 依存機能 | Windows の機能／dism | Hyper‑V、Virtual Machine Platform、Sandbox が有効 |
ケーススタディ：24 論理コアのホストでの見直し例
ビフォー（更新前）
- VM A：8 vCPU／VM B：8 vCPU／VM C：8 vCPU（バックグラウンド 2 vCPU × 2 台）
- 合計 28 vCPU（22H2/Server 2022 では辛うじて運用できていた）
アフター（24H2/Server 2025 への更新後）
- Classic 扱いとなり、起動時に 28 > 24 のため 0x80070142 で失敗
解決
- バックグラウンド VM を営業時間外に自動起動へ変更（同時稼働 vCPU を 24 以内に）
- VM C を 8 → 6 vCPU に削減、ピーク帯の総 vCPU を 22 に調整
- SMT を有効化、Core 指定を試行（効果があれば 24 超でも余裕が生まれるが、フォールバック時のために 24 以内を維持）
Windows Sandbox 専用の注意点
- NUMA Spanning が OFF だと起動しない（0x80070142）。ホスト側で必ず ON
- Sandbox 機能を後付けした場合は再インストールで依存関係を再構成
- 初回起動で内部更新が走るため、最初の起動は必ず 1 回成功させておく
トラブルシューティング深掘り
スケジューラの反映有無を確実に見る
起動のたびに Classic に戻る場合があり、bcdedit の設定だけでは判断できません。イベントログで直近のスケジューラ選択を確認します。
Get-WinEvent -FilterHashTable @{ProviderName='Microsoft-Windows-Hyper-V-Hypervisor'; ID=2} -MaxEvents 5 |
Select-Object TimeCreated, Id, ProviderName, Message
VM 側の設定で救える余地
- ProcessorCount を段階的に削減し、合計 vCPU がしきい値を下回るか確認
- CPU リソース制御（リザーブ／上限／重み付け）は起動可否には効かない（実行時の配分のみ）
- Dynamic Memory は主にメモリ配分の話であり、この 0x80070142 の直接解決策ではない
NUMA／マルチソケット機での注意
- ソケット数や NUMA ノード数が多い環境では、NUMA Spanning OFF により起動要件がさらに厳しくなる
- Windows Sandbox を確実に使うなら、ホストポリシーとして NUMA Spanning ON を標準化
運用自動化のサンプル（安全な範囲）
ピーク帯に合計 vCPU がしきい値を超えそうなら、事前に検出してアラートするだけでも停止事故を減らせます。
# 合計 vCPU が論理コア数を超えたら警告を出す簡易チェック
$logical = (Get-CimInstance Win32_Processor | Measure-Object -Property NumberOfLogicalProcessors -Sum).Sum
$running = (Get-VM | ? State -eq 'Running' | Measure-Object -Property ProcessorCount -Sum).Sum
if ($running -gt $logical) {
Write-Warning "vCPU overcommit detected: Running vCPU = $running > Logical Cores = $logical"
} else {
Write-Output "OK: Running vCPU = $running, Logical Cores = $logical"
}
アップグレード前後のチェックリスト
- 前：検証環境で 24H2/Server 2025 を先行適用し、同時起動時の vCPU 総数の上限を把握
- 前：SMT 有効化方針の確認（セキュリティ方針で無効にしている場合は Classic 前提の計画に切替）
- 後：スケジューラの実際の採択（イベント）を確認し、Core 指定の有無にかかわらず運用上限を再設定
- 後：Windows Sandbox 用に NUMA Spanning を ON に統一。Sandbox を一度起動して初期化完了を確認
- 常：重要 VM に優先度を付与し、起動順と自動停止をポリシー化
よくある質問（FAQ）
Q. 物理 CPU とメモリに余裕があるのに、なぜ 0x80070142 になるの？
A. Classic スケジューラでは「同時稼働 VM の vCPU 合計 ≤ 論理コア数」というハード制約があるためです。実リソースに余裕があっても、しきい値超過だけで起動を拒否します。
Q. Core スケジューラに固定すれば、オーバーコミットは常に可能？
A. いいえ。Core 指定が反映されず Classic に戻る事例があり、また SMT 無効だと Classic 相当の制約になります。Core が効いても、将来のフォールバックを考えると「論理コア数を超えない」設計が堅実です。
Q. NUMA Spanning を OFF にしたまま Sandbox を使いたい
A. 0x80070142 を避けるには Sandbox では NUMA Spanning を ON にするのが前提です。Sandbox を利用しないポリシーなら OFF でも構いませんが、利用する場合は ON を推奨します。
Q. vCPU を削ると性能が心配
A. 実効性能は vCPU 数だけでなくスケジューリングの詰まりにも左右されます。しきい値を超えて起動失敗するより、少ない vCPU で安定稼働させる方がトータルのスループットが上がることは珍しくありません。段階的に下げて計測しましょう。
Q. 設定を元に戻す方法は？
A. スケジューラ設定は bcdedit /deletevalue hypervisorschedulertype で既定に戻せます。NUMA Spanning は Set-VMHost -NumaSpanningEnabled $false で無効化可能です。
まとめ
- 24H2／Server 2025 の Hyper‑V Version 12 では、Classic 前提の厳格運用になりやすく、vCPU オーバーコミットが通りにくい
- 合計 vCPU ≤ 論理コア数を守るのが最短の解決策。Core 指定と SMT 有効化は有効なケースがあるが、フォールバックも想定して設計
- Windows Sandbox は NUMA Spanning ONが必須級。必要なら機能の再インストールで依存関係を再構成
- アップグレード前に検証とキャパシティ計画、アップグレード後にイベントログでスケジューラ採択の実測確認を行い、運用上限を再定義
参考：便利コマンド（抜粋）
| 目的 | コマンド | 補足 |
|---|---|---|
| スケジューラ種別変更 | bcdedit /set hypervisorschedulertype Core | 再起動が必要／無効化は bcdedit /deletevalue ... |
| SMT 状態確認 | wmic cpu get NumberOfCores,NumberOfLogicalProcessors | 論理 > 物理なら SMT 有効の目安 |
| スケジューラ確認（ログ） | Get-WinEvent -FilterHashTable @{ProviderName='Microsoft-Windows-Hyper-V-Hypervisor'; ID=2} -MaxEvents 1 | 最新の採択状況を確認 |
| NUMA Spanning 設定 | Get-VMHost / Set-VMHost -NumaSpanningEnabled $true | Windows Sandbox の必須前提 |
| 実行中 vCPU 合計 | Get-VM | ? State -eq 'Running' | Measure -Sum ProcessorCount | 同時稼働の実値を把握 |
実務 TIP：「いつの間にかバックグラウンド VM が増えていた」「Sandbox を含めた同時起動想定が抜けていた」など、同時稼働の棚卸し漏れが最頻因です。スクリプトで定期棚卸し→しきい値超過を早期検知する運用に切り替えると、アップデート後の“初回月曜日の全滅”を防げます。
コメント