---
title: "WSL2とは？WSL1との違い・仕組み・インストール手順【WSL 3.0対応・2026年10月】"
url: "https://www.issoh.co.jp/tech/details/3410/"
published: 2024-08-28
updated: 2026-10-17
categories: ["OS"]
publisher: "株式会社一創"
---

# WSL2とは？WSL1との違い・仕組み・インストール手順【WSL 3.0対応・2026年10月】

WSL2（Windows Subsystem for Linux 2）は、Windowsの中で軽量な仮想マシンを動かし、その上で本物のLinuxカーネルを実行する仕組みです。読み方は「ダブリューエスエルツー」。2026年10月時点のWSLは3.0系に上がっていますが、これはパッケージの版番号で、アーキテクチャは今もWSL2のままです。この記事では、WSL2の仕組みとWSL1との違い、`wsl --install`が使える条件と既定で入るUbuntuの初期状態、企業で管理するときに止められる設定までを、Microsoftの公式ドキュメントとGitHubの一次情報で整理します。

## まとめ：WSL2の要点（2026年10月時点）

- **WSL2とは**：Windows上の管理された軽量VMで本物のLinuxカーネルを動かす方式。新しく入れたディストリビューションは既定でWSL2になる。
- **WSL 3.0との関係**：3.0.1（2026年9月29日）と3.0.3（10月9日）はWSLアプリの版番号。WSL3という新方式は発表されていない。
- **WSL1との違い**：WSL1はシステムコールの変換層、WSL2は本物のカーネル。WSL1は、OSをまたぐファイル操作やシリアルポートの利用、仮想化を使えない環境などで選択肢になる。
- **使える条件**：`wsl --install`はWindows 10 バージョン2004（ビルド19041）以上かWindows 11。Homeでも使え、Hyper-Vの有効化は要らない。
- **既定のディストリ**：`wsl --install`で入るUbuntuは26.04.1。systemdは最初から有効で、gccやmakeは入っていない。
- **セキュリティ**：Linuxのrootでも、Windows側のファイルにはWSLを起動したWindowsユーザーの権限でしか触れない。企業ではIntuneやグループポリシーでWSL1やカスタムカーネルを禁止できる。

以下、仕組み→WSL1との違い→導入→できないこと→セキュリティ→トラブルの順に根拠を示します。

## WSL2の読み方と「WSL 3.0」の版番号が意味するもの

WSLは「Windows Subsystem for Linux」の略で、日本語版のWindowsでは「Linux 用 Windows サブシステム」と表示されます。WSL2はその第2世代のアーキテクチャを指す呼び名です。

### WSL2はディストリビューション単位で選ぶアーキテクチャ

Microsoftの[WSLの概要ページ](https://learn.microsoft.com/ja-jp/windows/wsl/about)は、WSL2を「Linuxディストリビューションをインストールするときの既定の種類」と説明しています。WSL1とWSL2は同じPCに混在でき、ディストリビューションごとにいつでも切り替えられます。つまり「WSL2をインストールする」というより、「WSLを入れて、ディストリビューションをWSL2方式で動かす」というのが正確な関係です。

### WSL 3.0.xの版番号とWSL2アーキテクチャの区別

検索では「WSL3」「wsl 3」も見かけますが、2026年10月17日時点でMicrosoftはWSL3というアーキテクチャを発表していません。3.0という数字は、Microsoft StoreとGitHubで配布されているWSLアプリの版番号です。[microsoft/WSLのリリース一覧](https://github.com/microsoft/WSL/releases)の直近の動きは次のとおりです。

| 版      | 公開日（UTC）   | 区分     | 主な内容                               |
| ------ | ---------- | ------ | ---------------------------------- |
| 3.0.3  | 2026-10-09 | 安定版    | カーネルを6.18.54.1へ更新                  |
| 3.0.2  | 2026-10-05 | プレリリース | カーネルヘッダーとperfの提供、大きなVMでのvNUMA自動有効化 |
| 3.0.1  | 2026-09-29 | 安定版    | WSL Containers（wslc）の一般提供          |
| 2.7.14 | 2026-09-11 | 安定版    | 3.0より前の系列                          |

3.0への繰り上がりは、Linuxコンテナを直接動かす`wslc`コマンドの一般提供に合わせたものです。手元の版は`wsl --version`で確認でき、上がっていなければ`wsl --update`で更新されます。wslcの使い方とDocker Desktopとの使い分けは[WSL Containersとは？wslcの使い方とDocker Desktopとの使い分け](/tech/details/18105/)で扱っています。

## WSL2の仕組み：軽量ユーティリティVMとLinuxカーネルの構造

WSL2は仮想化技術を使いますが、VirtualBoxのように利用者がVMを作って管理するものではありません。WindowsがVMを裏で起動し、停止もします。

### 1つの管理VMを全ディストリビューションが共有する構造

概要ページによれば、WSL2は「軽量のユーティリティVM」の中でLinuxカーネルを動かし、各ディストリビューションはそのVMの中で分離されたコンテナとして実行されます。Ubuntuと[FedoraをWSL2で使う手順](/tech/details/10014/)のように複数のディストリビューションを入れても、VMは1つです。

同じVMにいるため、ネットワーク名前空間・デバイスツリー（`/dev/pts`を除く）・CPU・カーネル・メモリ・スワップ・`/init`は全ディストリビューションで共有されます。一方、PID・マウント・ユーザー・cgroupの名前空間と各initプロセスはディストリビューションごとに独立しています。片方で`.wslconfig`のメモリ上限に達すると、もう片方も巻き込まれるのはこの構造のためです。

### Microsoftがビルドし配布するLinuxカーネル6.18系

カーネルはkernel.orgの安定版を元にMicrosoftがWSL2向けに調整したもので、ソースは[microsoft/WSL2-Linux-Kernel](https://github.com/microsoft/WSL2-Linux-Kernel)で公開されています。2026年10月時点の最新はlinux-msft-wsl-6.18.54.1（10月6日タグ）で、WSL 3.0.3に同梱されました。カーネルはWSLアプリの更新と一緒に入れ替わるため、ディストリビューション側で`apt upgrade`してもカーネルは変わりません。

### Windowsとのファイル共有に使うPlan 9サーバーとDrvFs

Linux側のファイルはVMの仮想ディスク（ext4.vhdx）に入っています。エクスプローラーから`\\wsl.localhost\Ubuntu`のように開けるのは、WindowsのリダイレクタP9rdr.sysが、Linux側で動くPlan 9（9P）ファイルサーバーへhvsocket経由で要求を渡すためです（[WSLの技術資料](https://github.com/microsoft/WSL/blob/master/doc/docs/technical-documentation/plan9.md)）。逆にLinuxからWindowsのCドライブを`/mnt/c`として見る仕組みはDrvFsと呼ばれ、WSL2ではWindows側のwslservice.exeが立てるPlan 9サーバーにつながります。

どちらもVMの境界をまたぐため、ext4上のファイルを直接読むより遅くなります。OS間のファイルアクセスがボトルネックなら、プロジェクトをLinux側の`~`に置くことで改善が期待できます。

### WSL2ネットワークの既定NATとミラーモードの選択条件

[WSLのネットワーク解説](https://learn.microsoft.com/ja-jp/windows/wsl/networking)によると、既定はNAT方式で、WSL2のVMは独自のIPアドレスを持ちます。Windows 11 22H2以降なら`.wslconfig`で`networkingMode=mirrored`を指定でき、WindowsとLinuxが`localhost`で互いに接続できるほか、VPN環境での不具合も減ります。社内VPNや同じLANの別PCからWSL内のサーバーへアクセスする用途があるなら、ミラーモードを候補にし、利用するVPNとの互換性とLANからの接続に必要なファイアウォール設定を確認してください。

## WSL1とWSL2の違い：公式比較表とWSL1を選ぶ例外条件

[Microsoftのバージョン比較ページ](https://learn.microsoft.com/ja-jp/windows/wsl/compare-versions)の表を日本語にし、注記の条件を補うと次のとおりです。

| 機能                    | WSL1 | WSL2     |
| --------------------- | ---- | -------- |
| WindowsとLinuxの統合      | ○    | ○        |
| 高速な起動                 | ○    | ○        |
| 従来のVMより少ないリソース        | ○    | ○        |
| VMware・VirtualBoxとの共存 | ○    | 条件付き（後述） |
| 管理されたVM               | ×    | ○        |
| 完全なLinuxカーネル          | ×    | ○        |
| システムコールの完全な互換性        | ×    | ○        |
| OSをまたぐファイルシステムの性能     | ○    | ×        |
| systemd               | ×    | ○        |
| IPv6                  | ○    | ○        |

速度の差も公式に書かれています。初期のWSL2でもWSL1比で、圧縮tarballの展開が最大20倍、`git clone`・`npm install`・`cmake`がおよそ2〜5倍速くなったという記載です。WSL1は独自の変換層でシステムコールを置き換えていたため、Dockerのようにカーネル機能に依存するソフトはそもそも動きませんでした。

### WSL1を選ぶ価値が残る3つの条件

比較ページが挙げる例外は、プロジェクトファイルをWindows側に置かざるを得ない場合、同じファイルをWindowsとLinuxの両方のツールでクロスコンパイルする場合、シリアルポートを使う場合です。USB機器は[usbipd-win](https://learn.microsoft.com/ja-jp/windows/wsl/connect-usb)でWSL2にも接続できるようになったため、例外から外れつつあります。これらに加え、厳しいメモリ制約や、WSL2に必要な仮想化を利用できない環境でも、必要なツールが動くならWSL1を選ぶ余地があります。

### 自分のディストリビューションがWSL2か確かめるコマンド

「WSLのバージョン」には2つの意味があるので、コマンドを使い分けます。

```
# ディストリビューションごとの方式（VERSION列が 1 か 2）
wsl -l -v

# WSLアプリの版（3.0.3など）とカーネル・WSLgの版
wsl --version

# 変換前に必要なファイルをバックアップする
# Ubuntuは wsl -l -v に表示された対象名へ置き換える
wsl --set-version Ubuntu 2
```

`wsl -l -v`のVERSION列が2ならWSL2で動いています。`wsl --version`が「無効なオプション」で失敗する場合は、Windowsに最初から入っている古い受信トレイ版のままなので、先に`wsl --update`を実行します。

## WSL2を使える条件：Windowsのビルド・エディション・CPUの要件

[WSLのインストール手順](https://learn.microsoft.com/ja-jp/windows/wsl/install)は、`wsl --install`を使う前提を「Windows 10 バージョン2004以降（ビルド19041以降）またはWindows 11」としています。旧版のこの記事は1903以降と書いていましたが、1903・1909で使えるのは[手動インストール](https://learn.microsoft.com/ja-jp/windows/wsl/install-manual)のほうで、x64ならビルド18362.1049以上、ARM64は2004（19041）以上が条件です。

エディションの制限はありません。公式FAQは、WSL2がWindows 10 HomeとWindows 11 Homeを含むすべてのデスクトップ版で使えると明記しています。必要なのは「仮想マシン プラットフォーム」というHyper-Vのサブセットで、Pro以上にしかないHyper-Vの役割そのものは要りません。Hyper-Vマネージャーで別のVMも動かしたい場合の有効化手順とWSL2との併存は[Hyper-Vの有効化と仮想マシン作成手順](/tech/details/17468/)にまとめています。

ハードウェア側では、BIOSまたはUEFIでCPUの仮想化支援（Intel VT-x／AMD-V）が有効で、CPUが第2レベルアドレス変換（SLAT）に対応している必要があります。Core 2 Duoのように古いCPUはSLATを持たないため、仮想マシン プラットフォームを有効にしてもWSL2は動きません。なお[Windows 10は2025年10月14日にサポートが終了](https://learn.microsoft.com/ja-jp/lifecycle/announcements/windows-10-end-of-support)しており、WSLのドキュメントにはWindows 10終了後のWSLの扱いについての記載がありません。これから開発機を用意するならWindows 11を前提にしてください。

## WSL2のインストール：wsl –installで入るものと既定Ubuntuの初期状態

管理者権限のPowerShellで、まず次の例のwsl –installを実行し、再起動します。以降の一覧表示とDebianの追加は必要に応じて実行してください。

```
# WSL本体と既定のUbuntuを入れる
wsl --install

# 入れられるディストリビューションの一覧
wsl --list --online

# 名前を指定して入れる（例：Debian）
wsl --install -d Debian
```

Microsoft Storeに接続できない社内ネットワークでは`--web-download`を付けます。ただしこの方法で入れたWSLは、以後の更新も手動です。`.wslconfig`でのメモリ・CPUの上限設定、コードの置き場所、ext4.vhdxの肥大化対策といった導入後の作業は[WSLで開発環境を構築する手順](/tech/details/17354/)で手順を追っています。

### 既定のUbuntu 26.04.1をイメージから展開して確かめた初期設定

`wsl --install`で何が入るかは、WSLが参照する配布カタログ[DistributionInfo.json](https://github.com/microsoft/WSL/blob/master/distributions/DistributionInfo.json)で決まります。2026年10月8日更新のカタログでは、既定の「Ubuntu」はubuntu-26.04.1-wsl-amd64.wslを指しています。2026年10月17日にこのファイル（418,495,746バイト）を取得し、SHA-256がカタログ記載の値と一致することを確かめたうえでtarとして展開すると、次のことが分かりました。

- `/etc/wsl.conf`は`[boot]`の`systemd=true`だけで、systemdは最初から有効。
- 初回起動時は`/usr/lib/wsl/wsl-setup`が動き、Windowsのユーザー名を初期値にしてLinuxユーザーを作る。作ったユーザーはadm・cdrom・sudo・dip・plugdevの各グループに入る。
- git・curl・wget・vim・python3・sudo・tmuxは同梱。gcc・make・unzipは入っていない。

C言語の拡張を含むPythonパッケージやネイティブモジュールを使うnpmパッケージは、ビルドの段階でgccを要求して止まります。最初に`sudo apt update && sudo apt install build-essential unzip`まで済ませておくと、この詰まりを避けられます。

### wsl –list –onlineで選べるディストリビューション

同じカタログには、新形式（.wsl）で21件が登録されています。系統ごとにまとめると次のとおりです。

| 系統          | 配布名・バージョン（省略表記）                               |
| ----------- | --------------------------------------------- |
| Ubuntu      | Ubuntu（=26.04.1）／26.04／24.04／22.04／20.04      |
| Debian・Kali | Debian／kali-linux                             |
| RHEL互換      | AlmaLinux-8／9／10／Kitten-10、RLCPlus-9／10       |
| Fedora      | FedoraLinux-44／43                             |
| SUSE        | openSUSE-Tumbleweed／Leap-16.0、SLE 15 SP7／16.0 |
| その他         | archlinux／eLxr                                |

旧形式の一覧にはOracle Linux 7.9・8.10・9.5も残っています。Alpineは公式カタログに無いため、使うならStoreの非公式パッケージか`wsl --import`になります。選び方の基準は本番環境です。本番がRHEL系ならAlmaLinux、Debian系ならUbuntuかDebianを候補にし、ディストリビューションの版と主要パッケージも合わせると、手順書の共通部分を増やせます。

## WSL2でできること・できないことの境界

完全なカーネルを持つため、WSL1では動かなかったものの多くが動きます。代表はDocker Engineで、Windows版のDocker DesktopもWSL2をバックエンドにする構成が標準です。仕組みの違いは[Dockerとは｜仮想マシンとの違い・必要スペック・インストール手順](/tech/details/6857/)を参照してください。systemdで管理するサービス、GPUを使う機械学習、WSLgによるLinuxのGUIアプリ（Windows 10 ビルド19044以上かWindows 11）もそのまま使えます。

できない、または手間がかかるのは次の4つです。重い順に並べます。

- **WindowsとLinuxをまたぐファイル操作が遅い**：`/mnt/c`上で`npm install`やビルドを回すと遅い。Linux側へ作業ファイルを移し、OS間のアクセスを減らすのが基本の対策。
- **同じLANから直接アクセスしにくい**：NATの既定ではWSL2のIPが外から見えない。ミラーモードか`netsh interface portproxy`での転送が要る。
- **シリアルポートは使えない**：公式にWSL2は非対応。USB機器はusbipd-win経由で可。
- **他社製の仮想化ソフトとの共存**：VMwareは15.5.5以降で共存できるが、VirtualBoxは公式に「サポート外」の扱い。

Windowsのファイルを頻繁に編集しながらLinuxのツールで処理する、という使い方を変えられず、OS間のファイルアクセスがボトルネックになる場合は、WSL1に切り替えるか、Windowsネイティブのツールで完結させる構成を選びます。

## WSL2のセキュリティ：Windows権限の境界と企業で管理できる設定

「WSL2は安全か」を判断する材料は、権限の境界と管理機能の2つです。

### Linuxのrootでも越えられないWindowsユーザー権限の境界

[企業向けのWSL設定ガイド](https://learn.microsoft.com/ja-jp/windows/wsl/enterprise)によれば、WSL内のLinuxプログラムがWindowsのファイルにアクセスするときは、`wsl.exe`を起動したWindowsユーザーの権限が使われます。Linux側でrootになっても、それだけでWindowsの管理者権限は得られません。ただし、管理者として起動したWindowsプロセスからWSLを実行した場合は、その昇格済みの権限でWindows側にアクセスできます。裏を返すと、WSLで動くものは「そのユーザーとしてPowerShellを動かすのと同じ」範囲でWindowsのファイルを読み書きできます。出所の分からないシェルスクリプトを`curl ... | bash`で流すことは、Windowsで不審なexeを実行するのと同じ危険があると考えてください。

ネットワーク面では、Windows 11 22H2以降かつWSL 2.0.9以降で、Hyper-Vファイアウォールが既定で有効になり、Windowsのファイアウォール規則がWSLにも適用されます。WSL内部の動きは[Microsoft Defender for EndpointのWSL用プラグイン](https://learn.microsoft.com/ja-jp/defender-endpoint/mde-plugin-wsl)で見られます。対象はDefender for Endpoint Plan 2で、ARM64端末とマルチセッション版Windowsはプラグインの対象外です。対応端末ではWSL2のディストリビューションとWSL containersのイベントを可視化しますが、WSLの論理デバイスにはマルウェア対策・脆弱性管理・応答コマンドが効きません。Linux側のウイルス対策を別に入れるかどうかは、この範囲を前提に決めます。

### IntuneとグループポリシーでWSL1やカスタムカーネルを止める設定

[WSLのIntune設定ページ](https://learn.microsoft.com/ja-jp/windows/wsl/intune)は、WSL全体の許可を含む12項目を制御でき、そのうち次の項目を「無効」にする構成を推奨しています。グループポリシーで管理する場合は、GitHubで公開されているWSLのADMXファイルを取り込みます。

| 設定名                                       | 無効にすると止まるもの           |
| ----------------------------------------- | --------------------- |
| Allow WSL1                                | WSL1方式のディストリビューション    |
| Allow the Inbox version                   | OS同梱の旧WSL（Store版だけ残る） |
| Allow custom kernel configuration         | .wslconfigでの独自カーネル    |
| Allow custom networking configuration     | networkingModeの変更     |
| Allow user setting firewall configuration | 利用者によるファイアウォール設定      |
| Allow nested virtualization               | 利用者による入れ子の仮想化設定の変更    |
| Allow the debug shell                     | wsl.exe –debug-shell  |

全社でWSL2を認めるなら、最低限WSL1は止めます。Defender for EndpointのWSL用プラグインはWSL2で動くディストリビューションを対象としており、プラグインの解説ページ自身がWSL1の無効化を勧めているためです。利用者が独自のカーネルを差し替えられる状態も、監視の前提が崩れるので同時に止めておきます。開発端末のLinux環境を本番のクラウドと同じ構成にそろえる設計から相談したい場合は、[AWS・Google Cloud・Azureのインフラ構築支援](/service/system/aws/)で承っています。

## WSL2が起動しない・インストールできないときの確認順

[公式のトラブルシューティング](https://learn.microsoft.com/ja-jp/windows/wsl/troubleshooting)に沿って、表示されたエラーや症状に対応する項目を確かめます。

- **エラー0x80370102・0x80070003**：仮想化設定を確認する。BIOS／UEFIでVT-x／AMD-Vを有効にし、「仮想マシン プラットフォーム」を有効化して再起動する。WSLをVMの中で動かしている場合は入れ子の仮想化も必要。0x80070003では、WSLはシステムドライブでしか動かないため、新しいアプリの保存先がC以外になっていないかも確かめる。
- **WslRegisterDistribution failed with error 0x8007019e**：「Linux 用 Windows サブシステム」機能が無効。Windowsの機能の有効化で有効にする。
- **wsl –versionが通らない・挙動が古い**：受信トレイ版のまま。`wsl --update`でStore版へ上げる。
- **ネットに出られない**：一部のファイアウォール製品やVPNが原因になる。Windows 11 22H2以降ならミラーモードと`autoProxy=true`を試す。
- **設定を変えたのに反映されない**：`wsl --shutdown`でVMを止めてから起動し直す。公式は全シェルを閉じてから停止まで約8秒かかるとしている。

該当する項目で解決しない場合は、WindowsとWSLの版、エラー全文、再現手順を記録し、公式のトラブルシューティングで追加の原因を調べてください。

## よくある質問

### WSL2はなぜ重いのですか？

メモリ使用量と作業ファイルの保存先を切り分けて確認します。WSL2のメモリ上限は既定でWindowsの総メモリの50%ですが、その全量を常時使用する意味ではありません。Windows側が圧迫されているなら`.wslconfig`の`memory`で上限を下げます。ファイル操作だけが遅い場合は、`/mnt/c`上で作業していないかを確かめ、プロジェクトをLinux側のホームへ移します。設定例は[WSLで開発環境を構築する手順](/tech/details/17354/)にあります。

### DockerとWSL2の違いは何ですか？

WSL2はLinuxカーネルとディストリビューションを動かす土台で、Dockerはその上でコンテナを動かすソフトです。Windows版のDocker DesktopはWSL2をバックエンドに使う構成が標準なので、WSL2が動かない原因（仮想化の無効など）はDocker Desktopの起動失敗としても現れます。2026年9月からはWSLに`wslc`コマンドが加わり、Dockerを入れずに単発のコンテナを動かせるようになりましたが、Composeには対応していません。

### WSL2のファイルはどこに保存されていますか？

Linux側のファイルは、ディストリビューションごとの仮想ディスクext4.vhdxの中にあります。Windowsから開くときは、エクスプローラーのアドレス欄に`\\wsl.localhost\Ubuntu`のように入力します。別のPCへ移したりバックアップを取ったりするときは、ファイルを直接コピーせず`wsl --export`と`wsl --import`を使います。

### VirtualBoxやVMwareとWSL2は併用できますか？

VMware Workstationは15.5.5以降でWSL2と同時に動きます。VirtualBoxは6以降でWSL対応を表明していますが、Microsoftの比較ページは課題が大きく「サポート外」としています。VirtualBoxのVMが遅い、起動しないといった症状が出たら、WSL2側ではなくVirtualBox側を最新にしたうえで、どちらかを止めて使う運用に切り替えてください。

### WSL2のディストリビューションを削除・初期化するには？

`wsl --unregister Ubuntu`のようにディストリビューション名を指定すると、そのディストリビューションのデータはすべて消えます。初期状態から作り直したいときは、このあと`wsl --install -d Ubuntu`を実行します。消す前に`wsl --export`でtarファイルに書き出しておけば、あとから`wsl --import`で戻せます。

## 関連記事

- [WSLで開発環境を構築する手順｜.wslconfig調整とDocker連携・肥大化の対処](/tech/details/17354/)
- [WSL Containersとは？wslcの使い方とDocker Desktopとの使い分け【WSL 3.0.1時点】](/tech/details/18105/)
- [Hyper-Vの有効化と仮想マシン作成手順｜PowerShell操作とWSL2との併存](/tech/details/17468/)
- [FedoraをWSL2で使う手順｜FedoraLinux-44と43のインストール・初期設定・GUI・アップグレード](/tech/details/10014/)
- [Dockerとは｜仮想マシンとの違い・必要スペック・インストール手順を解説【2026年版】](/tech/details/6857/)

---

出典: [WSL2とは？WSL1との違い・仕組み・インストール手順【WSL 3.0対応・2026年10月】](<https://www.issoh.co.jp/tech/details/3410/>)（株式会社一創）
