はじめに
AI駆動開発を始めようとして、「Macじゃないと厳しい」「Windowsは遅い」「WSLは難しそう」――そんな記事を見て、不安になったことはないでしょうか。
結論から言うと、2026年現在、それはほぼ誤解です。
私はWindows 11 + WSL2で、Cursor、Claude Code、Dockerを使ったAI駆動開発を日常的に行っています。一度環境を整えてしまえば、Macとの差を意識する場面はほとんどありません。
ただし、「環境の整え方」を間違えると地獄を見ます。私自身がそうでした。
この記事では、ゼロストレスな環境構築の手順と、私が実際にハマった落とし穴をまとめます。
この記事の前提
WindowsでのAI駆動開発では、WSL2がすべての土台になります。
Dockerも、VS CodeやCursor、WindSurfといったエディタも、快適に使うにはWSL2が不可欠です。
まずこの構造を頭に入れてから読み進めてください。
┌─────────────────────────────┐
│ Windows 11 │
│ │
│ ┌───────────────────────┐ │
│ │ WSL2 (Ubuntu) │ │
│ │ │ │
│ │ ・ソースコード │ │
│ │ ・Git操作 │ │
│ │ ・Docker Engine │ │
│ │ ・開発サーバー │ │
│ └───────────────────────┘ │
│ │
│ VS Code / Cursor / WindSurf │
│ （WSLのフォルダを開く） │
│ │
│ エクスプローラー │
│ （\\wsl$ でファイル参照） │
└─────────────────────────────┘
1. WSL2のインストール
Docker imageでUbuntuを立ち上げるのではなく、Windows上にLinuxディストリビューションを直接インストールします。
PowerShellを管理者権限で開いて、以下を実行するだけです。
wsl --install
これだけでWSL2 + Ubuntuがインストールされます。
再起動後、Ubuntuのターミナルが開くので、ユーザー名とパスワードを設定すれば完了です。
インストール後、バージョンを確認しておきましょう。
wsl -l -v
VERSION が 2 になっていればOKです。
2. エクスプローラーで \\wsl$ を開いてみよう
WSL2をインストールしたら、まずこれを試してください。
Windowsのエクスプローラーのアドレスバーに以下を入力します：
\\wsl$
Ubuntuのファイルシステムが、ネットワークドライブのように表示されます。
「えっ、WSLの中身ってエクスプローラーで普通に見れるの？」と思った方、そうなんです。
WSLのファイルをGUIで操作できる、ということを最初に知っておくだけで、この先の作業のハードルがぐっと下がります。
\\wsl$\Ubuntu\home\あなたのユーザー名\ を開いてみてください。ここがWSL上のホームディレクトリです。
よく使うので、クイックアクセスにピン留めしておくことを強くおすすめします。
3. WSL内でプロジェクトをセットアップする
エクスプローラーでWSLの中身が見れることがわかったら、次はプロジェクトを作りましょう。
ポイントは、WSLのターミナル内で全操作を完結させることです。
# プロジェクト用ディレクトリを作成
mkdir -p ~/projects
cd ~/projects
# WSL内で直接git clone
git clone https://github.com/your-org/your-repo.git
cloneが終わったら、先ほどピン留めしたエクスプローラーから projects フォルダを見てみてください。cloneしたプロジェクトがそのまま表示されているはずです。
WSL内で操作して、エクスプローラーで確認する。 この感覚を掴めれば、もうWindowsだからといって開発体験が劣ることはありません。
4. エディタ（VS Code / Cursor / WindSurf）をWSLに接続する
ここまで来れば、あとはエディタでWSL上のプロジェクトを開くだけです。
VS Code系のエディタはすべてWSLへのリモート接続に対応しています。
VS Code / Cursorの場合
どちらもWSL拡張機能が使えます。手順は同じです。
- エディタを起動
-
Ctrl + Shift + Pでコマンドパレットを開く -
WSL: Connect to WSLを選択 - 接続後、
ファイル > フォルダーを開くでWSL上のプロジェクトフォルダを選択
左下に WSL: Ubuntu と表示されていれば、WSL上で動作しています。
WindSurfの場合
WindSurfも同様にWSL接続に対応しています。
Remote接続でWSL上のフォルダを直接開くことができます。
ここまでで、WindowsでAI駆動開発をする環境は整いました。
5. Docker Desktopの導入
AI駆動開発でDockerを使うケースも多いので、セットアップしておきましょう。
なぜDockerにWSL2が必要なのか
Docker EngineはLinux上でしか動きません。WindowsでDockerを動かすには「どこかにLinux環境を用意する」必要があります。
歴史的には2つの方法がありました：
| 方式 | 特徴 |
|---|---|
| Hyper-Vバックエンド（旧方式） | 重い仮想マシンを丸ごと起動。メモリ消費大、ファイル共有も遅い |
| WSL2バックエンド（現在の標準） | 軽量なLinuxカーネルで動作。高速でリソース消費も少ない |
現在のDocker DesktopはWSL2バックエンドがデフォルトです。Hyper-Vを選ぶメリットはほぼありません。
インストール手順
- Docker Desktop for Windowsをダウンロード・インストール
- インストール時に「Use WSL 2 instead of Hyper-V」が選択されていることを確認
- Docker Desktopの設定 > Resources > WSL Integration で、Ubuntuが有効になっていることを確認
確認：
# WSLのターミナルから
docker --version
docker compose version
6. やってはいけない3つのパターン
ここまでの正しい手順を読んだ方は「こんなの当たり前じゃん」と思うかもしれません。
でも、WSLに慣れていないと以下のような遠回りを普通にやってしまいます。私がそうでした。
❌ パターン1：Windows側のソースコードをWSLにコピペ
Windows側でSVNやGitなどで管理・開発していたソースコードを、エクスプローラー経由でWSLのフォルダにコピペ。
一見うまくいきそうですが、大量のファイルをまとめてコピーしようとすると、途中で止まったりエラーになることがあります。小さなファイルなら普通にコピーできますが、プロジェクト丸ごとのような操作は安定しません。
これは、WindowsからWSLのファイルシステム（\\wsl$）にアクセスする際に使われる9Pプロトコルという仕組みに起因します。9PはWindows ↔ WSL間のファイル橋渡し用のプロトコルで、エクスプローラーでWSLのファイルを閲覧する程度なら問題ありませんが、大量のファイルを一括コピーするような重い操作ではタイムアウトや転送エラーが発生することがあります。
WSLにソースコードを持っていきたい場合は、WSLのターミナルから直接 git clone するのが確実です。
❌ パターン2： /mnt/c/ にソースを置いて開発 → HMRが死ぬ
WSLからは /mnt/c/ でWindows側のCドライブにアクセスできます。
入門書や解説記事では、この /mnt/ 上でそのまま作業する手順になっていることが多いです。 よくわからないままに解説記事や入門書通りにやってしまうと、それは地獄の入り口です。
たとえばLaravelの入門書では、Windows側の C:\Users\ユーザー名\projects\ にソースを置いて、WSLからは /mnt/c/Users/ユーザー名/projects/ で開くという手順が定番です。書籍側はWSLを「Linuxコマンドを使うための補助ツール」くらいの扱いで、ソースコードの置き場所をWSL側に移すという発想がそもそもありません。
つまり読者は本の通りにやっているだけなのに地獄を見る、かなりタチの悪い罠です。
なぜ地獄なのか。/mnt/c/ はWSLからWindows側のファイルシステムをまたいでアクセスする仕組みなので、ファイルの変更検知が極端に遅くなります。たとえるなら、自分のデスク（Windows上のフォルダ）で作業しているつもりが、実は毎回隣のビル（WSL上のフォルダ）まで書類を取りに行って、書き終わったらまた持って帰っているようなものです。1回なら気にならなくても、コードを保存するたびにこの往復が発生するので、開発体験は壊滅的になります。
具体的に言うと、HMR（Hot Module Replacement）はコードを保存した瞬間にブラウザへ変更が反映される仕組みで、フロントエンド開発の生産性を支える要です。しかし /mnt/c/ 上で開発すると、この反映に数十秒〜数分かかることがあります。
HTMLの文字を1文字変えただけなのに、ブラウザに反映されるまで数分待つ。これならはっきり言って、HMRを使わずにWindows上で毎回ビルド・再読み込みしたほうが早いです。というか、従来のXAMPPのほうがよっぽど開発効率がいいです。
あまりのストレスで禿げた人が続出したとかなんとか。
❌ パターン3：Windows側のツール（PowerShell / Git Bash）でgit操作
WSLを入れたのに、git操作はWindows側のPowerShellやGit Bashでやってしまうパターン。
これだと改行コードの問題（CRLF / LF）が発生したり、パーミッションがおかしくなったり、そもそもWSL上の開発環境の恩恵を受けられません。
ただし、これはCursorやWindSurfなどのエディタでWSL接続すれば自然と回避できます。WSLに接続した状態ではエディタ内蔵のターミナルがWSLのシェルになるので、git操作も自動的にWSL内で完結します。Claude Codeの場合もWSLのターミナルから起動するだけなので同様です。
つまり**「WSL接続を知らずにWindows側で作業してしまう」こと自体が問題**であり、この記事の手順通りにやっていれば踏まないはずの地雷です。
⚠️ 補足：WSL自体の注意点
WSL2は万能ではありません。知っておくべきデメリットもあります。
- VPN接続時にWSL側のネットワークが切れることがある： 企業VPNとWSL2のネットワーク構成が競合するケースがあります。現場のネットワーク環境によっては追加設定が必要です
-
メモリを食いすぎる： WSL2はデフォルトでホストマシンのメモリの大部分を確保しようとします。
~/.wslconfigで上限を設定しておくのがおすすめです - 企業のセキュリティポリシーでWSL自体が禁止されている場合がある： これはもうどうしようもないので、情シスに相談するしかありません
# C:\Users\ユーザー名\.wslconfig の例
[wsl2]
memory=4GB
swap=2GB
共通する原因
3つの失敗に共通するのは、「Windows側のファイルシステムやツールを経由している」 ということです。
WSL2を入れたら、ソースコードの配置もGit操作もすべてWSL内で完結させる。これがゼロストレスの鉄則です。
環境構築の全体フロー（まとめ）
Step 1: WSL2 + Ubuntu をインストール
↓
Step 2: エクスプローラーで \\wsl$ を開いてクイックアクセスにピン留め
↓
Step 3: WSLターミナルでプロジェクトをgit clone（~/projects/ 配下に）
↓
Step 4: VS Code / Cursor / WindSurf をWSLに接続してプロジェクトを開く
↓
Step 5: Docker Desktopをインストール（WSL2バックエンド）
↓
🎉 AI駆動開発の準備完了！
おわりに
私は最初、WSL2を「WindowsでLinuxを動かすための便利機能」くらいに思っていました。
でも実際には逆でした。
AI駆動開発においてWSL2はオプションではなく、土台そのものです。
Cursorも、Claude Codeも、Dockerも、全部この上に成り立っています。
VS CodeのWSL拡張を入れるだけで、同じ恩恵を受けることもできます。
WindowsだからAI駆動開発は不利――そんな時代はもう終わりました。