自分は古い人間で、自宅の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の停止の影響を受けることに注意してください。