WSL入門 — 仕組み・基本操作・実務でハマるポイント

Windows上でLinuxを動かすWSL（Windows Subsystem for Linux）について、仕組みの基本から実務で実際に必要になることまでを整理する。シェルやLinuxとの関係の前提知識はターミナル入門の記事を参照。

WSLとは

Windowsの中で本物のLinux（Ubuntu等のディストリビューション）を動かす公式機能。現行のWSL2は軽量な仮想マシン上で本物のLinuxカーネルを動かしているので、Dockerやサーバー系ツールもLinuxそのままの挙動で動く。

• Git Bashが「Unix風コマンドの再現」なのに対し、WSLは本物のLinux環境
• 起動は一瞬（普通のVMのようなOS起動待ちはない）。ターミナルのタブを開く感覚でLinuxに入れる
• WindowsアプリとLinuxアプリを同じマシンで同時に使える。エディタはWindows側、実行環境はLinux側という分担が定番

旧世代のWSL1はカーネルを持たない互換レイヤー方式で、今から使うなら基本WSL2一択（wsl -l -v でどちらかは確認できる）。

インストール

管理者権限のPowerShellで1コマンド。

wsl --install

• デフォルトでUbuntuが入る。別ディストリビューションは wsl --install -d Debian のように指定（一覧は wsl -l -o）
• 初回起動時にLinux側のユーザー名とパスワードを決める。このパスワードは sudo（管理者コマンド）実行時に使うので忘れない
• 会社PCの場合、BIOSの仮想化支援（Intel VT-x等）が無効だと動かない。有効化に管理者・情シスの手続きが要ることがある

インストール後は、Windows Terminalのドロップダウンに「Ubuntu」が増えているので、そこから入るのが楽。

wslコマンドの基本操作

Windows側（PowerShell等）から使う管理コマンド:

Linuxから抜けるのは exit。なお wsl --shutdown はDocker Desktop等WSLベースのツールも巻き込んで止まるので、実行タイミングだけ気をつける。

ファイルはどちら側に置くか（最重要）

WindowsとLinuxのファイルシステムは分かれていて、相互に見える通路がある:

• Linux側からWindowsのファイル → /mnt/c/Users/名前/...
• Windows側からLinuxのファイル → エクスプローラーで \\wsl.localhost\Ubuntu\home\名前\...（サイドバーの「Linux」からも辿れる）

そして実務で一番大事なルールがこれ:

プロジェクトはLinux側（~/ 以下）に置く。/mnt/c/ 上で作業しない。

/mnt/c/ 経由のファイルアクセスは仕組み上とても遅く、npm install やgit操作が体感で数倍〜数十倍遅くなる。「WSLにしたら遅くなった」という相談のほとんどはこれが原因。リポジトリはWSLの中で git clone して、/home/名前/projects/... のようにLinux側に置く。

VS Codeとの連携

VS Codeに「WSL」拡張機能を入れると、エディタはWindows側、ファイルと実行環境はLinux側という理想の分担ができる。

# WSL内のプロジェクトフォルダで
code .

これでWindows側のVS Codeが開き、左下に「WSL: Ubuntu」と表示される。ターミナルもデバッグもLinux側で動くので、環境差に悩まなくなる。拡張機能は「Windows側」と「WSL側」で別管理になっており、言語系の拡張はWSL側にもインストールが必要（VS Codeが案内してくれる）。

開発環境の構築でやること

Ubuntuに入ったら最初にやる定番:

sudo apt update && sudo apt upgrade -y   # パッケージを最新化
git --version                            # gitは最初から入っていることが多い
git config --global user.name "名前"
git config --global user.email "メール"

Node.jsはaptで直接入れない（古いバージョンが入る）。nvm等のバージョンマネージャーを使う:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
# シェルを開き直してから
nvm install --lts

注意: Windows側にNode.jsが入っていても、WSL内にはWSL用のNodeを別に入れる。WSLのPATHにはWindows側のコマンドも混ざって見えるため、which node が /mnt/c/... を指していたらWindows側を拾ってしまっている（遅い上に挙動が混ざる）。WSL側にインストールすればそちらが優先される。

WindowsとLinuxの相互乗り入れ

WSLの気持ちいいところで、双方向にコマンドを呼び合える:

# WSL内から
explorer.exe .          # 今のフォルダをエクスプローラーで開く
clip.exe < file.txt     # Windowsのクリップボードにコピー

# Windows側から
wsl ls -la              # WSL内のコマンドを1発実行

localhostも共有される。WSL内で起動した開発サーバー（例: pnpm dev のlocalhost:3000）には、Windows側のブラウザからそのまま http://localhost:3000 でアクセスできる。逆にたまにこの転送が壊れることがあり、その場合は wsl --shutdown してWSLを再起動すると直る。

実務でハマりがちなポイント

• メモリを食い続ける: タスクマネージャーで vmmem が数GB占有する現象。Windows側の %UserProfile%\.wslconfig に上限を書いて wsl --shutdown で反映する

[wsl2]
memory=8GB
processors=4

• 会社プロキシ環境: WSL内の通信（apt / git / npm）は個別にプロキシ設定が必要になることがある。環境変数 http_proxy / https_proxy を ~/.bashrc に書く、git config --global http.proxy、npm config set proxy あたりが対象。社内CA証明書が必要な環境では、証明書をLinux側（/usr/local/share/ca-certificates/ → sudo update-ca-certificates）にも入れる
• スリープ後に時計がずれる: たまにLinux側の時刻がずれてTLSエラー等の原因になる。sudo hwclock -s か wsl --shutdown で直る
• 改行コード: Windows側で作ったファイルはCRLF、Linux側ツールはLF前提のことがある。gitの core.autocrlf はWSL内では input にしておくのが無難
• とにかく挙動が変なとき: まず wsl --shutdown → 開き直し。WSLの再起動は数秒で終わるので気軽にやってよい

まとめ

• WSL2 = Windows内で動く本物のLinux。エディタはWindows、実行はLinuxの分担が定番
• 管理は wsl -l -v / wsl --shutdown / wsl --update を覚えれば足りる
• プロジェクトはLinux側に置く。/mnt/c/ で作業すると遅い（最重要）
• VS CodeはWSL拡張で code .。NodeはWSL内にnvmで入れ直す
• localhostは共有される。困ったら wsl --shutdown