WSLを理解したい（2026/11時点）

自分は古い人間で、自宅のWindowsで開発を使用とするとき、VirtualBox上でAlmaLinuxをインストールしていました。
ただ、WSLを使うのがトレンドのようで、キャッチアップしようと思います。

WSLは、Windows上でLinux環境を動作させるための仕組みです。
Windowsを普段使いながら、Linuxのコマンド、開発ツール、パッケージ管理機能などを利用できます。特に、Windows PCでWebアプリケーションを開発する場合、非常に便利な選択肢です。

WSLとは何か

WSLは「Windows Subsystem for Linux」の略称です。
従来、Windows上でLinuxを動作させるには、VirtualBoxなどの仮想化ソフトウェアを利用するのが一般的でした。
WSLを使うと、WindowsのターミナルからLinuxを起動できます。
例えば、WindowsのPowerShellで以下を実行します。

wsl

すると、Linuxのシェルに入れます。

user@PC:~$ pwd
/home/user

user@PC:~$ uname -a
Linux ...

user@PC:~$ ls

この環境では、Linuxのコマンドだけではなく、Node.js、Python、Git、各種サーバアプリケーションなども実行できます。

重要なのは、WSLはLinuxコマンドを模倣するだけのツールではないという点です。

特にWSL 2では、実際のLinuxカーネルが動作しています。

2. WSLの仕組み

現在主流のWSL2は、Windowsの仮想化技術を利用してLinuxカーネルを実行します。

ここで理解しておきたいのが、LinuxカーネルとLinuxディストリビューションの違いです。
Linuxカーネルは、プロセス管理、メモリ管理、ファイルシステム、ネットワークなど、OSの中核となる機能を提供します。
一方、AlmaLinuxやUbuntuなどのディストリビューションは、カーネルと組み合わせて利用するユーザー空間のプログラム、ライブラリ、パッケージ管理ツールなどを提供します。
WSL 2では、Microsoftが提供するLinuxカーネルの上で、AlmaLinuxなどのユーザー空間を実行します。
したがって、AlmaLinuxをWSL 2で実行しても、通常のAlmaLinuxサーバと完全に同じカーネル環境にはなりません。

3. WSL 1とWSL 2の違い

WSLには大きく分けて2種類のアーキテクチャがあります。

項目	WSL1	WSL2
Linuxカーネル	使用しない	実際に動作
実行方式	Linuxシステムコールの変数	軽量VM
Linuxとの互換性	制限あり	高い
systemd	非対応	対応
Dockerとの親和性	制限あり	高い
Linux内部のファイル処理	用途により異なる	高速
Windowsとのファイルアクセス	比較的有利	配置場所によって性能低下

WSL 1は、LinuxのシステムコールをWindows側の機能へ変換する方式でした。
一方、WSL 2は実際のLinuxカーネルでシステムコールを処理します。そのため、Linux向けソフトウェアとの互換性が大きく向上しています。
今からWebアプリ開発環境を構築するのであれば、基本的にWSL 2を選択するのがよいでしょう。

4. VirtualBoxとWSL 2の違い

WSL 2も仮想化技術を利用しています。そのため、VirtualBoxとは共通する部分があります。
ただし、目的と管理方法が異なります。

比較	VirtualBox	WSL2
主な目的	独立したOS環境の構築	Windows上でLinuxを利用
Linuxカーネル	ゲストOSのもの	WSL用カーネル
VM管理	ユーザが実施	Windowsが管理
起動操作	VM起動	wsl
ネットワーク	NAT・ブリッジなどを選択	WSLのネットワーク機構
デスクトップ環境	一般的に利用可能	Linux GUIアプリも利用可能
OS・ネットワーク検証	適している	制約がある
Webアプリ開発	可能	特に扱いやすい

例えば、VirtualBoxではLinuxをインストールするときに、仮想ディスクの作成、メモリ割り当て、CPU数、ネットワークアダプターなどを管理します。
WSL 2では、その多くをWindowsが自動的に管理します。
ただし、WSL 2は完全に仮想化の存在を隠しているわけではありません。メモリ上限やCPU割り当てを.wslconfigで調整することもできます。

使い分けの目安

Webアプリケーション開発、Linuxコマンドの利用、Git、Node.js、Dockerなどが中心ならWSL 2が便利です。
一方、複数の仮想NICを使ったネットワーク検証、独立したLinuxカーネルの設定変更、OSの起動過程やカーネルモジュールの検証などでは、VirtualBoxやHyper-Vの通常のVMが適しています。

5. WSLのネットワークの仕組み

WSLを理解するうえで、ネットワークの仕組みは特に重要です。
WSL 2には、主にNATモードとMirroredモードがあります。

NATモード（標準構成）

例えば、WSL内でNode.jsのWebサーバをポート3000で起動した場合、Windowsのブラウザから次のURLでアクセスできます。

http://localhost:3000

標準のNAT構成でも、WindowsからWSLへのlocalhost転送機能が用意されています。
ただし、逆方向、つまりWSLからWindowsで動作するサーバへアクセスする場合は、通常Windowsホスト側のIPアドレスが必要です。

Mirroredモード

Windows 11では、Windows側のネットワークインターフェースをLinuxへミラーリングする方式も利用できます。

# Windows側の %USERPROFILE%\.wslconfig
[wsl2]
networkingMode=mirrored

これにより、以下のような機能が利用しやすくなります。

• WindowsとWSL間での双方向localhost通信
• IPv6対応
• VPNとの互換性向上
• LAN内の別端末からWSLへのアクセス（ファイアウォール設定が必要）

ただし、WindowsとLinuxが完全に独立したNICを持つわけではありません。VirtualBoxのブリッジ接続と同一の仕組みではない点に注意してください。

6. WindowsとLinuxのファイルの関係

WSLでは、WindowsとLinuxの両方のファイルシステムへアクセスできます。
例えば、Linux側ではWindowsのCドライブが次のように見えます。

cd /mnt/c/Users

逆に、WindowsのエクスプローラーからLinux側を開くには、次のパスを利用します。

\wsl$\

ただし、Webアプリのソースコードは、WSL側のLinuxファイルシステムに配置することを推奨します。

例えば以下です。

/home/dev/projects/myapp/

Windows側のC:\Users\...にソースコードを置き、WSLから/mnt/c/...経由でビルドや大量のファイルアクセスを行うと、性能が低下することがあります。

7. AlmaLinuxをWSL 2で利用する

AlmaLinuxもWSLで利用できます。
最初にWindowsのPowerShellで以下を実行します。

wsl --version
wsl --list --online

オンライン一覧に希望するAlmaLinuxのバージョンが表示された場合は、その表示名を指定してインストールできます。

wsl --install -d <表示されたディストリビューション名>

一覧に存在しない場合でも、WSL対応のrootfsをtar形式で用意して、次のようにインポートできます

wsl --import AlmaLinux C:\WSL\AlmaLinux C:\temp\alma-rootfs.tar --version 2

この方法はMicrosoftが公式にサポートしているカスタムディストリビューションの導入方法です。なお、インポート用のrootfsは信頼できる配布元から入手する必要があります。

8. WSLでsystemdは使えるのか

WSL 2ではsystemdを利用できます。
systemdを有効にすると、例えば次のようなLinuxサーバで一般的な操作が可能になります。

sudo systemctl start nginx
sudo systemctl status nginx
sudo systemctl enable nginx

ディストリビューションによっては、/etc/wsl.confで明示的に有効化する必要があります。

[boot]
systemd=true

設定変更後、Windows側でwsl --shutdownを実行し、再起動します。
ただし、systemdでサービスを有効化しても、それだけでWSLがWindows起動時に常時稼働するわけではありません。
WSLは開発環境として便利ですが、通常のLinuxサーバとはライフサイクルが異なるためです。

9. Webアプリ開発なら、どのような構成がよいか

Windows側にVS Codeとブラウザを用意し、Linux側にNode.jsなどの実行環境を配置します。
この構成なら、VirtualBoxの仮想マシンを別途起動したり、SSHサーバを立ててVS Codeで接続したりする必要がありません。VS CodeのWSL連携を利用できます。

10. セキュリティ面で注意すべきこと

セキュリティエンジニアの観点では、特に次の点が重要です。

注意点	内容
ホストとの分離	WSLはWindowsから完全に隔離されたサンドボックスではない
ファイルアクセス	Linux側からWindowsのファイルへアクセスできる
ネットワーク公開	開発サーバのbindアドレスやFW設定次第で外部公開される
権限管理	LinuxのrootとWindowsの管理者権限は同一ではない
アップデート	WSL本体とLinuxパッケージをそれぞれ管理する
機密情報	Windows・Linux間のファイル共有や相互運用機能を考慮する

例えば、WSLのLinuxプロセスから/mnt/c経由でWindowsファイルへアクセスできます。

そのため、WSL内で実行するプログラムが不正なものであれば、Windows側のファイルにも影響を及ぼす可能性があります。

また、WSLはWindowsと密接に連携する設計です。信頼できないコードを安全に隔離して実行する目的には、WSLだけを頼りにするべきではありません。

11. WSLでの管理

管理対象を整理すると次のようになります。
${NAME}は、wsl –list –verboseの出力結果です。

管理対象	操作する場所	管理方法
AlmaLinuxの起動	Windows	wsl -d ${NAME}
AlmaLinuxの停止	Windows	wsl –terminate ${NAME}
WSL全体の停止	Windows	wsl –shutdown
バックアップ	Windows	wsl –export
AlmaLinuxの削除	Windows	wsl –unregister ${NAME}
AlmaLinuxのアップデート	AlmaLinux	dnf upgrade
サービス管理	AlmaLinux	systemctl
ユーザー管理	AlmaLinux	useraddなど
WSLのメモリ・CPU管理	Windows	.wslconfigまたはWSL設定

AlmaLinuxの起動・停止

例えば、WindowsにAlmaLinuxがインストールされている状態を考えます

インストール済みLinuxを確認する

PowerShellで実行します。

wsl --list --verbose
# 出力例
# NAME          STATE       VERSION
# * AlmaLinux-10  Stopped     2
# Ubuntu        Running     2

STATEには、通常RunningまたはStoppedが表示されます。
また、複数のLinuxディストリビューションをインストールして使い分けることも可能です。

AlmaLinuxを起動する

wsl -d AlmaLinux-10

これだけでAlmaLinuxのシェルが起動します。VirtualBoxと異なり、Linuxの起動画面やログイン画面を操作する必要はありません。

AlmaLinuxを停止する

wsl --terminate AlmaLinux-10

特定のディストリビューションを停止できます。
一方、次のコマンドはすべてのディストリビューションとWSL2の軽量VMを停止します。

wsl --shutdown 
#注意点： exitでLinuxのシェルを終了しただけでは、必ずしもWSLのLinux環境が即座に停止するわけではありません。

また、wsl --terminateやwsl --shutdownは強制的な停止操作です。データベースなどが稼働している場合は、サービスを適切に停止してから実行する方が安全です。

AlmaLinuxのOS管理

WSL内のAlmaLinuxに入った後は、通常のAlmaLinuxとほぼ同じ操作を行います。

パッケージ管理

# 更新対象の確認
sudo dnf check-update

# パッケージの更新
sudo dnf upgrade

# パッケージのインストール
sudo dnf install git

# インストール済みパッケージの確認
dnf list installed

ここで重要なのが、WSL本体とAlmaLinuxのアップデートは別物だということです。

wsl --update

dnf upgradeによってAlmaLinuxのユーザー空間のパッケージは更新されますが、WSLが実行しているLinuxカーネル自体は通常のAlmaLinuxサーバとは異なる方法で管理されます。

サービス管理

systemdが有効になっていれば、通常のAlmaLinuxと同じように管理できます。

# systemdの状態を確認
ps -p 1 -o comm=

# サービスの一覧
systemctl list-units --type=service

# nginxの起動
sudo systemctl start nginx

# nginxの自動起動設定
sudo systemctl enable nginx

# nginxの状態確認
systemctl status nginx

systemdが無効なら、/etc/wsl.confに設定します。

[boot]
systemd=true

その後、PowerShellで対象のAlmaLinuxを停止・再起動します。

wsl --terminate AlmaLinux-10
wsl -d AlmaLinux-10

ただし、ここでのenableは、WSLのAlmaLinux環境が起動した際にサービスを起動する設定です。
Windowsが起動しただけでAlmaLinuxやサービスが必ず起動する、という意味ではありません。

AlmaLinuxのユーザー管理

rootで常に作業するのではなく、一般ユーザーを作成して開発することをおすすめします。
例えばAlmaLinuxにrootで接続する場合：

wsl -d AlmaLinux-10 -u root

Linux側でユーザーを作成します。

useradd -m developer
passwd developer
usermod -aG wheel developer

AlmaLinuxでは、通常wheelグループにsudo権限を付与する設定が使用されます。ただし、実際の設定はvisudoなどで確認してください。
作成したユーザーを既定のログインユーザーにする場合、/etc/wsl.confを設定します。

[user]
default=developer

変更後はディストリビューションを停止・再起動します。
これにより、通常のwsl -d AlmaLinux-10で一般ユーザーとしてログインできます。

CPUとメモリの管理

WSL 2のCPUとメモリは、Windows側の.wslconfigで管理できます。
例えば、メモリを8GB、CPUを4個に制限したい場合です。
Windowsの%USERPROFILE%\.wslconfigに以下を設定します。

[wsl2]
memory=8GB
processors=4
swap=2GB

その後、PowerShellで以下を実行します。

wsl --shutdown

設定は次の起動時に反映されます。
ただし、.wslconfigのリソース制限は特定のAlmaLinuxだけではなく、WSL 2全体に適用されます。
Ubuntuなど複数のディストリビューションを利用する場合は、この点に注意が必要です。

AlmaLinuxのバックアップと復元

ここはVirtualBoxと大きく異なる部分です。
WSLでは、Linux環境をファイルにエクスポートできます。

バックアップ

まずAlmaLinux内で動作しているデータベースなどを適切に停止します。
その後、PowerShellで以下を実行します。

wsl --terminate AlmaLinux-10
wsl --export AlmaLinux-10 D:\Backup\alma-backup.tar

これにより、AlmaLinuxのファイルシステムをtarファイルとして保存できます。

復元

バックアップした環境を別名で復元する場合：

wsl --import AlmaLinux-Restore D:\WSL\Restore D:\Backup\alma-backup.tar --version 2

この方法なら、既存のAlmaLinuxを削除せず、別のディストリビューションとして復元できます。
なお、DBを使う場合はwsl --exportだけに頼らず、PostgreSQLのpg_dumpなどによる論理バックアップも併用するのがおすすめです。

AlmaLinuxを削除したい場合

WindowsのPowerShellから実行します。

wsl --unregister AlmaLinux-10

このコマンドを実行すると、対象のAlmaLinux環境に保存されているファイル、設定、インストール済みソフトウェアなどが削除されます。
元に戻すための取り消し機能はないため、事前にバックアップが必要です。

日常的にはどう管理していけばよいか

個人のWebアプリ開発環境であれば、次のような運用が現実的です。

タイミング	管理内容
開発開始時	wsl -d AlmaLinux-10で起動
開発中	VS Codeから接続し、Linux側でコマンド実行
開発終了時	開発サーバやDBを停止
定期的	sudo dnf upgrade
定期的	wsl --update
重要な設定変更前	wsl --exportでバックアップ
環境を作り直すとき	バックアップを確認し、再インポート

WindowsをシャットダウンすればWSLも終了するため、開発終了時に毎回wsl --shutdownが必要なわけではありません。

ただし、WSL上で起動したサービスを長時間動かしたい場合は、Windowsのスリープ、再起動、WSLの停止の影響を受けることに注意してください。