WindowsにPowerShellがあるのに、
なぜWSLが要るのか

by
  • WindowsにはPowerShellとCommand Promptが標準で入っていて、CodexやClaude CodeもPowerShellの上で動かせます。それでも導入ガイドの多くがWSLを勧めるのは、開発ツールの前提環境がLinuxやUNIXに寄っているからです。
  • WSLはOS全体の中に、もう一つ小さなLinux環境を起動する仕組みです。仮想マシンを丸ごと立てる方法や、Dockerのようにフォルダ単位でマウントする方法とは、環境の持ち方が違います。
  • Windows ターミナルとPowerShell、Command Prompt、WSLは役割が別です。ターミナルは表示や入力を担う箱で、シェルはその中で動くコマンド解釈の中身です。
  • WindowsとWSLは、それぞれ別のファイルシステムを持っています。/mnt/cという橋を通じて、お互いのファイルを行き来できます。

関連記事

1. PowerShellでも動く、でもなぜかWSLが勧められる

最近、CodexやClaude Codeのセットアップ手順を読んでいて、毎回同じ場所で足を止めます。 Windowsには最初からPowerShellとCommand Promptというシェルが入っているのに、なぜかWSLを入れる手順が挟まっている。

シェル（shell：コマンドを読み取って実行するプログラム）という点では、PowerShellもCommand Promptも十分に働きます。 実際、CodexやClaude CodeはPowerShellの上でも動かせます1。 動かせるのに、なぜわざわざLinux環境を用意するのか。

答えは単純で、これらの開発ツールの多くがLinuxやUNIX環境を前提に作られているからです。 パスの区切り方、権限の扱い方、標準で入っているコマンド群。 どれもLinux側の作法に合わせて設計されていて、Windows側のシェルで動かすと、あちこちで小さな読み替えが必要になります。 動くけれど、噛み合わない。 そういう感覚です。

2. WSLはOSの中にもう一つ小さなLinuxを起動する仕組み

WSL（Windows Subsystem for Linux：Linux用Windowsサブシステム）は、Windows上でUbuntuなどのLinux環境をそのまま動かす仕組みです。 仮想マシンを丸ごと用意したり、デュアルブートでOSを切り替えたりしなくても、Linuxのコマンドや開発ツールをWindowsの中で使えます。 Microsoft公式でも、WSLはGNU/Linux環境をWindows上で直接実行する機能と説明されています2。

導入は、管理者権限のPowerShellまたはWindows ターミナルから一行で済みます。

wsl --install
Code language: PowerShell (powershell)

このコマンドで、WSL本体と既定のディストリビューション、通常はUbuntuが入ります3。 再起動して、Linux用のユーザー名とパスワードを設定すれば、もう使い始められます。 Windowsのログイン情報とは別物として管理される点は、最初は少し戸惑うところかもしれません。

2.1. バージョンとディストリビューションを確認する

インストール後に確認したくなるのが、バージョンとディストリビューションです。 現在のWSL環境を確認するには、PowerShellで次を実行します。

wsl -l -v
Code language: PowerShell (powershell)

VERSIONが2ならWSL 2で動いています4。 wsl –installで新しく入るLinux環境は、今は既定でWSL 2です。 Ubuntu以外を試したい場合は、まず一覧を見ます。

wsl --list --online
Code language: PowerShell (powershell)

たとえばDebianを追加するなら、次のように指定します。

wsl --install -d Debian
Code language: PowerShell (powershell)

一台のWindows上に、複数のディストリビューションを共存させることもできます。

2.2. 仮想マシンやDockerでLinuxを用意する方法とは何が違うか

ここで気になるのが、仮想マシンにLinuxを入れる方法や、Dockerを使う方法との違いです。 CodexやClaude Codeのデスクトップアプリでコードを実行するときは、プロジェクトフォルダを一つマウントして、その中だけで完結させるパターンがよくあります。 Dockerも基本的には同じで、コンテナという閉じた環境にフォルダを一つか二つマウントして、そこだけをLinuxとして扱います5。

WSLは、これとは環境の持ち方が違います。 フォルダ単位でどこかを閉じるのではなく、OS全体の中にLinuxディストリビューションそのものが一つの実体として常駐する。 ホームディレクトリも、パッケージ管理も、プロセスも、Linux側にまるごと存在します。 だから、apt installでツールを足したり、複数のプロジェクトを横断してLinuxの状態を保ち続けたりできる。 フォルダを都度マウントして使い捨てるDockerの感覚とは、そこが違います。

もちろん、Dockerにも利点はあります。 環境を毎回まっさらな状態から立ち上げられるので、再現性は高い。 一方でWSLは、育てていく開発環境として使うのに向いています。 どちらが優れているという話ではなく、環境を使い捨てるか、育てるか、という設計思想の違いです。

3. シェルという中身と、ターミナルという箱を分けて考える

WSLを導入すると、画面の中にウィンドウが増えます。 このとき混同しやすいのが、Windows ターミナルとシェルの関係です。

Windows ターミナルは、表示・タブ・分割ペインを担当するアプリです6。 コマンドを直接解釈しているわけではありません。 その中でタブを開くと、PowerShell、Command Prompt、WSL経由のUbuntuなど、好きなプロファイルを選べます。 入力したコマンドを実際に読み取って実行するのは、選んだシェルの側です。

あなたが入力
   ↓
Windows ターミナル（表示・タブを担当）
   ↓
選ばれているシェルが解釈
   ↓
結果をターミナルに表示

3.1. PowerShellとCommand Prompt、文字列かオブジェクトか

Command Promptは、dirやcopy、cd、.batファイルといった、昔ながらのWindowsコマンドを扱うシェルです。 一方のPowerShellは、コマンドラインシェルであると同時にスクリプト言語でもあります。 テキストの文字列だけでなく、.NETのオブジェクトという構造化されたデータをそのままパイプでつなげられます7。 Windowsの管理や自動化に強いのは、この違いによるところが大きいです。

3.2. WSLの中だけで通じる言葉、bashとapt

WSLの中に入ると、シェルはbashなどのLinuxシェルに切り替わります。 ls、grep、ssh、apt、python3。 Linuxで日常的に使うコマンド群が、そのまま使える。 CodexやClaude Codeが前提にしているのは、まさにこちら側の語彙です8。 慣れないうちは、Windows側の感覚でコマンドを打って「コマンドが見つからない」と怒られることもあります。

4. WindowsとLinux、二つのファイルシステムが橋でつながっている

WSLを使い始めて最初に混乱するのは、ファイルがどこにあるか分からなくなることです。 WindowsとWSLには、実は別々のファイルシステムがあります。

WSL側からWindowsのCドライブを見ると、/mnt/c以下として見えます。 たとえばC:\Users\you\DesktopはWSLからは/mnt/c/Users/you/Desktopです。 逆に、WindowsのエクスプローラーからWSL側のファイルを見るには、アドレスバーに\wsl$と入力します。

この橋渡しを担っているのが、DrvFs（Drive File System：WindowsドライブをWSLに見せる仕組み）です9。

ただ、橋があるからといって、どちらを使ってもいいわけではありません。 Linuxの開発作業をするなら、/home/you以下に置くのが基本です。 git cloneやnpm install、pythonの実行など、ファイルを大量に読み書きする作業は、/mnt/c経由だと遅くなることがあります10。 Windows側の既存ファイルを少し覗きたいときだけ、/mnt/cを使う。 そのくらいの使い分けが安全です。

CodexやClaude Codeのプロジェクトも、WSLの/home以下に置いて動かすほうが、ツールの前提と噛み合います。 橋は行き来できるけれど、住む場所は分けておく。 そういう感覚に近いです。

最初は、PowerShellがあるのになぜ余計な手順を踏むのか、正直めんどうに思っていました。 でも、開発ツールが育ってきた環境と、Windowsが育ってきた環境は、そもそも別の土地だったのだと分かると、WSLという橋の存在にも納得がいきます。 道具の相性を合わせるための一段階だった、ということです。

  1. Anthropic公式のセットアップガイドでは、Claude CodeはWindows上でPowerShellまたはCMDから直接起動するネイティブインストールと、WSL内で動かすWSLインストールの両方をサポートすると説明されている。 – Advanced setup – Claude Code Docs
  2. Microsoft公式ドキュメントでは、WSLは仮想マシンのオーバーヘッドなしにGNU/Linux環境をWindows上で直接実行できる機能と説明されている。 – Windows Subsystem for Linux Documentation
  3. Microsoft公式手順では、wsl –installコマンドで既定のディストリビューションとしてUbuntuがインストールされ、新規インストールでは既定でWSL2が使われると説明されている。 – WSL を使用して Windows に Linux をインストールする方法
  4. Microsoft公式手順では、wsl -l -vコマンドの出力にあるVERSION列が2であれば、そのディストリビューションはWSL2で動作していると確認できるとされている。 – WSL を使用して Windows に Linux をインストールする方法
  5. 補足として、Windows版Docker DesktopはWSL2をバックエンドとして使っており、コンテナ実行の裏側では実際にWSL2の仕組みの上で動いている。 – Docker Desktop WSL 2 backend on Windows
  6. Microsoft公式では、Windows ターミナルは複数のタブやペインを持ち、PowerShellやCommand Prompt、WSLなど複数のプロファイルをホストするアプリケーションと説明されている。 – An overview on Windows Terminal
  7. Microsoft公式では、PowerShellはテキストではなく.NETオブジェクトを入出力できる点で、従来のシェルと異なると説明されている。 – What is PowerShell?
  8. Anthropic公式ドキュメントでは、WSL側でClaude Codeを使う場合はWSLのターミナル内でインストーラを実行し起動する必要があり、PowerShellやCMDからは起動しないと説明されている。 – Advanced setup – Claude Code Docs
  9. Microsoft公式ドキュメントでは、DrvFsという仕組みがWindowsのドライブを/mnt/cや/mnt/dといった形でWSLにマウントすると説明されている。 – WSL での詳細設定の構成
  10. Microsoft公式では、Linuxツールで扱うファイルはLinux側のファイルシステムに置く方がパフォーマンス上有利であり、/mnt/c経由でのアクセスは遅くなる場合があるとされている。 – Set up a WSL development environment