WSLとは・なぜ必要か

AIに「このシェルスクリプトを実行して」「Dockerでこのコンテナを立てて」と言われて手が止まった経験はないでしょうか。AIが生成するコードの多くはLinux環境を前提にしています。ところが手元のPCがWindowsだと、そのままでは動かせません。この溝を埋めるのがWSL(Windows Subsystem for Linux)です。

WSLは何を解決するのか

「仮想マシンを入れればいいのでは」と思うかもしれません。実際WSL登場前は、VirtualBoxなどの仮想マシンでLinuxを動かす開発者が多くいました。WSLは違うアプローチで同じ課題を解決します。

Windowsを起動したまま、同じPC上でLinuxのコマンドやツールをそのまま実行できる——それがWSLです。専用の画面やOSを別途起動する必要がなく、エクスプローラーやVS Codeから直接Linux側のファイルを編集できます。「Windowsの便利さ」と「Linuxの資産」を同じ机で両方使えるのが利点です。

WSL1とWSL2、何が変わったか

WSLには実は2つのバージョンがあり、AIが提案してくるコマンドの中には「WSL2前提」のものも多く混じっています。違いを知らないと、なぜか動かないコードに出会うことになります。

# WSL1: システムコールをWindowsカーネルに翻訳する方式
[Linuxコマンド] → 翻訳レイヤー → [Windowsカーネル]

# WSL2: 軽量VMの中で本物のLinuxカーネルが動く方式
[Linuxコマンド] → 本物のLinuxカーネル(軽量VM内) → [ハードウェア]

🎯 読み解きポイント：WSL1は通訳越しの会話、WSL2は直接会話

ハクスラゲームでたとえると、WSL1は「通訳を挟んで異国の商人と取引するゲート」です。会話は成立しますが、細かいニュアンスや一部の専門用語(システムコール)がうまく伝わらないことがあります。WSL2は「言語がそのまま通じる専用ワープゲート」で、本物のLinuxカーネルと直接やり取りするため、Linux側のファイルシステムに限ればその性能もシステムコールの互換性も大きく向上しました(ただしWindows側との行き来には後述の注意点があります)。現在AIが生成するコードのほとんどはWSL2を前提にしていると考えてよいでしょう。

インストールしてみる

実際に手を動かしてみると、思ったより手順は少ないです。管理者権限で開いたPowerShellで次を実行するだけで、WSL2とUbuntuのセットアップが一度に完了します。

# 管理者権限のPowerShellで実行
wsl --install

# 利用できるディストリビューション一覧を見る
wsl --list --online

# 特定のディストリビューションを指定して入れる例
wsl --install -d Ubuntu-24.04

覚えておきたい基本コマンド

wsl --list -vでインストール済みディストリビューションとバージョン(1/2)を確認、wsl --shutdownでWSL全体を一旦終了できます(次にターミナルを開き直すとまっさらな状態から起動し直されます)。動作がおかしいときはまずこの2つを試すと解決することが多いです。

WindowsとLinux、ファイルはどこに置くべきか

インストールが終わると次にぶつかる疑問が「ファイルはどっちに置けばいいの?」です。実はこれが最大のはまりポイントにつながります。

Linux側からはWindowsのCドライブが/mnt/c/として見えます。逆にWindows側からはエクスプローラーのアドレス欄に\\wsl.localhost\Ubuntu\と入力するとLinux側のファイルが見えます。双方向に覗けるので便利に感じますが、実際にはこの境界をまたぐ処理に大きな代償があります。

🎯 読み解きポイント：プロジェクトはLinux側に置くのが鉄則

WindowsとWSLの間のファイルアクセスは9P(Plan 9 Filesystem Protocol)という仕組み経由で、VMの境界を越えるたびに変換処理が発生します。AIが生成したdocker-compose.ymlやNode.jsのプロジェクトを/mnt/c/Users/...(Windows側)に置いたままnpm installやdocker buildを実行すると、大量の小さいファイルI/Oのたびに境界を往復し、体感できるほど遅くなります。ホームディレクトリ(~/)などLinux側に置くだけで数倍速くなることも珍しくありません。

よくあるはまりポイント

改行コード事故で「触っていないのに全行差分」になった

WindowsとWSLを行き来していると、ある日突然gitが「ファイル全体が変更された」と報告してくることがあります。1文字も編集していないのに、です。原因の多くは改行コードの違いです。Windowsは伝統的にCRLF、LinuxはLFを使うため、Windows側のエディタで保存したファイルをWSL側のgitが見ると、全行のCRLFがLFとして扱われ、差分だらけに見えてしまいます。

# WSL(Linux)側のgit設定で、コミット時だけCRLFをLFに揃える
git config --global core.autocrlf input

一度設定しておけば、Windows側のエディタで開いても改行コードを気にせず、コミット時だけ自動でLFに揃います。

あわせて知っておきたい用語

ディストリビューション: WSL上で動かすLinuxの種類(Ubuntu、Debianなど)。複数を同時にインストールして使い分けられる
WSLg: WSL上のLinuxアプリのウィンドウをそのままWindowsのデスクトップに表示する仕組み

💡 ワンポイントアドバイス：VS Codeは「WSL拡張機能」経由で開く

エクスプローラーで\\wsl.localhost\を都度たどるのではなく、WSL(Ubuntu)側のターミナルでプロジェクトのフォルダに移動しcode .と打つだけで、VS CodeがRemote-WSL接続で直接そのフォルダを開いてくれます。エディタ自体はWindows側で表示されつつ、ファイル操作やターミナルはすべてLinux側で完結するため、ここまで説明してきたパス変換や性能の悩みをほぼ意識せずに済みます。まだ試していない場合は、次にAIが生成したコードを動かすタイミングでぜひ使ってみてください。

WSLの基本を押さえたら、次はDockerの記事で「なぜDockerにもWSLが必要なのか」を確認してみてください。