STEP-BY-STEP GUIDE

WSL 2で0x80370102が出てディストリビューションを起動できない

この記事の結論

WSL 2の起動時に「必要な機能がインストールされていない」と表示される場合の安全な切り分け手順。UEFI/BIOSのCPU仮想化、Virtual Machine Platform、または仮想マシン内での入れ子仮想化が無効な可能性がある。設定変更前に現在値を控え、公式機能だけを使って確認する。

一般的な切り分けガイドです。特定の不具合が現在発生しているという告知ではありません。

対象製品・影響範囲

製品
WSL 2
対象バージョン・条件
Windows 11(対応機能はエディションとハードウェア要件を確認)
関連するエラーコード・識別子
0x80370102

発生する症状

  • WSL 2の起動時に「必要な機能がインストールされていない」と表示される
  • 再起動や再試行だけでは同じ状態が続くことがある

原因・発生条件

UEFI/BIOSのCPU仮想化、Virtual Machine Platform、または仮想マシン内での入れ子仮想化が無効な可能性がある。

作業前の準備

  • 開いている文書と作業を保存し、必要ならPCを再起動できる時間を確保する
  • 管理者権限が必要な操作は、個人所有PCまたは管理者の許可を得た端末だけで行う
  • 診断用コマンド「systeminfo.exe」の結果を保存し、変更前後を比較できるようにする

この操作の注意点

  • レジストリ、システムフォルダー、資格情報、記憶域を手作業で一括削除しない
  • インターネット上の非公式スクリプトや不明なドライバーを管理者権限で実行しない

使用するツール・公式ページ

WSL 2の確認手順:WSLの版と対象ディストリビューションを確認する → 物理PCと仮想PCを分けて診断する → systeminfo.exeで状態を確認する → 公式の設定経路で修復する → 仮想化設定と再起動を確認する → ハイパーバイザー検出を無効と読み違えない → 同じ条件で検証する
FaultNote作成の手順図です。設定を変更する前に、注意点と各手順の説明を確認してください。 詳しい操作手順へ

具体的な操作手順

  1. 01

    WSLの版と対象ディストリビューションを確認する

    #

    WindowsのPowerShellで wsl --list --verbose を実行し、対象がVERSION 2であることを確認します。WSL 1の問題にCPU仮想化の設定変更を適用しないでください。0x80370102の全文を保存してから次へ進みます。

    例えば「Ubuntuだけ起動できず、Windowsのターミナルは開ける」という状態では、ターミナルの再インストールを先に行う必要はありません。エラーがターミナルの表示機能から出ているのか、WSLがLinuxを起動する段階から出ているのかを分けます。通常のPowerShellから同じディストリビューションを指定して起動し、同じコードになるかを控えます。既に使える別のディストリビューションがある場合は、その名前とVERSION欄も比較します。対象が違う結果を一つの「WSLが壊れた」という判断にまとめないことが、変更箇所を絞る助けになります。

  2. 02

    物理PCと仮想PCを分けて診断する

    #

    会社の仮想デスクトップ内でWSLを使っている場合、ゲストのタスクマネージャーだけではホスト側の設定を変更できません。物理PCならメーカーのUEFI手順、仮想PCならホスト管理者による入れ子仮想化の確認へ分岐します。CPUがSLAT非対応ならWindows機能を追加してもWSL 2の要件を満たせません。

  3. 03

    systeminfo.exeで状態を確認する

    #

    Hyper-V Requirements欄と[タスク マネージャー]>[パフォーマンス]>[CPU]の仮想化状態を確認する。

    末尾の Hyper-V Requirements 各項目と仮想化状態を読み取ります。Noや無効があれば、Windows機能を繰り返し追加せず、PCメーカーの型番別UEFI要件へ進みます。

    [スタート]を右クリック→[ターミナル(管理者)]を開いて systeminfo.exe を実行します。出力末尾の[Hyper-V の要件]で「ファームウェアで仮想化が有効」が「いいえ」なら、DISMを繰り返さずUEFI/BIOS設定を端末メーカー手順で確認します。

    操作は「対象の版を確認→物理PCかVMかを確認→仮想化と機能の現在値を確認→不足している項目だけ変更→要求された再起動→同じ対象を起動」の順に進めます。機能が既に有効なら、有効化コマンドを繰り返すより起動時の新しいエラーを調べます。UEFIの設定を変える場合も、画面にあるすべての仮想化関連項目を変更する必要があると決めつけません。メーカーの説明と対象機能を照合し、変更前の値を写真やメモに残します。設定変更が許されない端末では、ここで管理者に引き継ぎます。

    入力するコマンド・パス
    systeminfo.exe
  4. 04

    公式の設定経路で修復する

    #

    管理者PowerShellで次のコマンドを実行し、Virtual Machine Platformを有効にします。処理が失敗した場合はエラーを控え、次の設定変更へ進まないでください。

    コマンド終了時に「操作は正常に完了しました」、再起動要求、またはエラーコードのいずれかを確認します。失敗した場合は同じ操作を繰り返さず、表示コードと C:\Windows\Logs\DISM\dism.log を保存します。

    正常になったかは、wsl --statusの表示だけで判断しません。最初に失敗したディストリビューションのシェルを開き、作業フォルダーにある既存の小さなファイルを読み取ります。シェルは開くがネットワークだけ使えないなら、仮想化の設定を元に戻したりLinuxを削除したりせず、DNSやVPNの別問題として記録します。Windowsを再起動した後も同じ対象が開くかを確認してから、どの不足項目を補ったかを結果に結び付けます。成功した別環境の出力を、この環境の確認結果として扱わないでください。

    入力するコマンド・パス
    dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
  5. 05

    仮想化設定と再起動を確認する

    #

    下のDISMコマンドはVirtual Machine Platformだけを有効にします。CPU欄の仮想化が無効なら、PCメーカーの型番別手順でUEFI設定を確認します。BitLocker回復キーを確保し、無関係なSecure BootやTPMは変更しません。機能の処理が正常終了してからWindowsを再起動します。

  6. 06

    ハイパーバイザー検出を無効と読み違えない

    #

    systeminfoに「ハイパーバイザーが検出されました」と出る場合、要件一覧が省略されても仮想化が無効とは限りません。変更前の表示と、対象ディストリビューション名を記録します。起動できない状態でwsl --unregisterを実行するとLinux内のデータを失うため、機能確認の代用にしません。

  7. 07

    同じ条件で検証する

    #

    「wsl --status」で状態を確認し、最初に記録した操作を同じ条件で一度実行する。成功した場合も再起動後にもう一度確認し、変更した設定と結果を記録する。

    対象ディストリビューション、WSL版、既定バージョンが表示されるか確認します。コマンドが認識されない場合はディストリビューションをリセットせず、WSL機能とStore版WSLの導入状態を確認します。

    改善しなければ、PC型番、Windowsビルド、WSL版、ディストリビューション名、エラー全文、仮想化の表示、変更した機能と再起動時刻を一つにまとめます。エラー番号が変わった場合は元のエラーと新しいエラーの両方を残します。Linuxのホームフォルダーを残す必要がある場合は、復旧方法を決める前に削除操作を止めます。WSLの登録解除やアプリのリセットはデータ消失を伴うため、「起動できないならやり直す」という流れで実施しません。診断で分かった不足と、まだ確認できていない条件を管理者へ分けて伝えます。

    入力するコマンド・パス
    wsl --status

公式の適用条件・最新情報も確認する ↗

改善したか確認する

  • 対象のWSL 2ディストリビューションでシェルが開き、既存ファイルを読み取れる
  • 確認コマンドの出力が期待する有効・正常・接続済み状態を示す
  • Windows再起動後にも同じ操作を再現でき、イベントログに同時刻の新しい重大エラーが増えない

改善しない場合・設定を戻す場合

  • 仮想PCならホストの製品、CPU、入れ子仮想化の可否を管理者へ渡す
  • ハードウェア要件、組織ポリシー、サーバー側設定が原因なら、クライアント側で回避せず所有者に変更を依頼する

別の症状から対処ガイドを探す →

このガイドの適用範囲

対処ガイド — 原因を切り分け、対象機能が正常に起動または接続でき、再起動後も同じ検証を通る状態を目標にする。

掲載内容は2026-10-13の情報確認に基づきます。以降の変更は公式出典でご確認ください。

よくある質問

BIOSで仮想化が有効なのに0x80370102が続きます。

Virtual Machine Platformの状態と再起動を確認します。Windows自体がVMなら、物理ホスト側で入れ子仮想化を公開する必要があります。

WSL 1ならCPU仮想化は必要ですか?

WSL 1はWSL 2と異なる方式ですが、まず `wsl --list --verbose` で対象のVERSIONを確認してください。

機能の有効化が成功したのに同じエラーが出るのはなぜですか?

Windows機能の追加成功はCPU仮想化やホスト側の入れ子仮想化まで保証しません。要求された再起動を実施したか、物理PCのUEFIか仮想PCのホスト側に未確認の要件がないかを順に確認します。

出典・情報の更新

主な出典の更新・解決日
公式ページで日付を特定できないため記載していません
本サイトの確認日
2026-10-13

公式情報を日本語で整理しています。メニュー名は製品の表示言語や版によって異なる場合があります。確認日は障害の発生日を意味しません。編集方針

あわせて確認したい記事

WSL・Hyper-V・仮想化が起動しないの記事一覧 →

インストール・ライセンス認証が失敗するの記事一覧 →

アプリが起動しない・クラッシュするの記事一覧 →

関連する操作ガイド・選び方

← 不具合の検索に戻る