Claude Code でコードを書いている最中、突然ターミナルが固まった。入力を受け付けない。数秒後、「WSL との接続が切断されました」のメッセージ。僕の作業途中のコンテキストは全部飛んだ。
最初は Claude Code 側の問題だと思った。トークン使いすぎたのか、API が落ちたのか。でも調べていくと、原因は Claude Code ではなく WSL2 そのものだった。
この記事では、WSL2 環境で Claude Code を使っているときに突然切断される原因と、具体的な対策を解説する。同じ症状で困っている人の手順書として使ってほしい。
WSL2が原因の切断かどうか、どう見分けるか？
まず、自分の症状がWSL2由来かどうかを見分ける必要がある。以下のパターンに当てはまるなら、WSL2 の問題である可能性が高い。
- Claude Code の応答が突然止まり、ターミナル自体がフリーズする
- ターミナルに「接続が切断されました」「プロセスが終了しました」と表示される
- VS Code の Remote WSL 接続が同時に切れる
- WSL 内の他のプロセス（サーバー、ビルドツール等）もすべて止まる
逆に、Claude Code だけが止まって WSL 自体は生きているなら、Claude Code のトラブルシューティング記事を先に確認してほしい。
VMMem がメモリを食い尽くして WSL2 が落ちるのはなぜか？
WSL2 は Windows 上の軽量 VM（Hyper-V）として動いている。この VM は VMMem というプロセスとして Windows 側に表示される。
問題は、WSL2 がメモリを積極的に確保する一方で、使い終わったメモリをなかなか返さないこと。これは Linux カーネルの設計上の挙動で、ファイルキャッシュをメモリに残し続ける。
Claude Code のようにファイルの読み書きが頻繁な作業をしていると、この傾向が顕著になる。気づくと VMMem が 10GB、15GB とメモリを食い続け、Windows 側がメモリ不足に陥る。最終的に Windows が WSL2 の VM を強制終了する。
確認方法
Windows のタスクマネージャーを開いて VMMem のメモリ使用量を確認する。物理メモリの50%以上を占有していたら危険信号だ。
# PowerShell でも確認できる
Get-Process vmmem -ErrorAction SilentlyContinue | Select-Object WorkingSet64
.wslconfig を設定しないとなぜ WSL2 が落ちるか？
WSL2 のデフォルト設定では、物理メモリの最大80%まで VM が使える。16GB のマシンなら約 12.8GB を WSL2 が持っていける計算だ。
Claude Code を動かしながら、VS Code、ブラウザ、Docker なども使っていれば、メモリはあっという間に枯渇する。
対策: .wslconfig でメモリ制限を設定する
Windows 側の %UserProfile%\.wslconfig を作成（または編集）する。
[wsl2]
memory=8GB
swap=4GB
localhostForwarding=true
ファイルの場所は C:\Users\<ユーザー名>\.wslconfig だ。
# PowerShell で作成する場合
notepad "$env:USERPROFILE\.wslconfig"
設定後、WSL を再起動して反映する。
wsl --shutdown
次に WSL を開いたときから新しい設定が適用される。
| 物理メモリ | 推奨設定 | 理由 |
|---|---|---|
| 16GB | memory=6GB | Windows側に10GB残す |
| 32GB | memory=12GB | 余裕を持たせる |
| 64GB | memory=24GB | 十分な余裕 |
迷ったら物理メモリの 1/3 〜 1/2 を WSL2 に割り当てるのがいい。Claude Code 自体の消費メモリは大きくないが、Node.js のビルドや TypeScript のコンパイルを併用すると一気に増える。控えめに設定しておく方が安全だ。
スリープ復帰後に WSL2 が不安定になるのはなぜか？
PC がスリープや休止状態から復帰したとき、WSL2 の VM が正常に再開しないことがある。特にネットワーク周りが壊れやすい。
復帰後に Claude Code が API に接続できなくなったり、WSL のネットワークが通らなくなるケースがある。
対策
復帰後に接続が不安定なら、WSL を一度再起動するのが最も確実だ。
wsl --shutdown
その後、再度 WSL を起動する。Claude Code のセッションは失われるが、CLAUDE.md や conversation の自動保存があれば復帰は早い。
Windows Insider Build が WSL2 の切断を引き起こすか？
Windows Insider Program（Dev / Canary チャネル）を使っている場合、WSL2 の安定性が低下することがある。
例えば Windows ビルド 10.0.26200 系は Canary チャネルのプレビューで、Hyper-V 周りの変更が頻繁に入る。WSL2 は Hyper-V 上で動いているため、直接影響を受ける。
確認方法
# Windows のビルド番号を確認
winver
ビルド番号が安定版（26100系）より大きい場合は Insider Build だ。
対策
- Feedback Hub でWSL の切断問題を報告する（Microsoft は Insider ユーザーからのフィードバックを重視している）
- 安定性を最優先するなら、Release Preview チャネルに切り替えるか、Insider を抜ける
- WSL 自体を最新に保つ：
wsl --update
WSL カーネルが古いと切断が起きるのか？
WSL2 のカーネルバージョンが古いと、既知のバグを踏む可能性がある。
wsl --version
このコマンドで WSL バージョンとカーネルバージョンが表示される。定期的に更新しておく。
wsl --update
特に WSL 2.x 系は 1.x 系と比べて安定性が大幅に改善されている。まだ 1.x 系なら更新する価値は大きい。
WSL2 が落ちても作業を守るにはどうするか？
WSL2 の切断は完全に防ぎきれない。だから「切断されても被害を最小化する」対策も重要だ。
CLAUDE.md を整備しておく
Claude Code はセッション開始時に CLAUDE.md を読み込む。ここにプロジェクトの方針やルールを書いておけば、新しいセッションでも文脈を復元できる。
# CLAUDE.md
## プロジェクト概要
- Next.js 16 + App Router
- TypeScript strict mode
## 現在の作業
- 機能Xの実装中。`src/components/Feature.tsx` を編集中
git で頻繁にコミットする
作業途中でもこまめにコミットしておけば、切断後にコードを失うことはない。Claude Code にも「キリのいいところでコミットして」と指示しておくとよい。
tmux / screen を使う（効果は限定的）
ターミナルマルチプレクサを使えば SSH 切断には耐えられるが、WSL2 の VM 自体が落ちる場合は tmux も道連れになる。VM が落ちるケースでは tmux は助けにならない。ネットワーク起因の一時的な切断には有効だ。
まとめ
WSL2 環境で Claude Code が突然切断される原因は、大きく5つに分類できる。
- VMMem のメモリ肥大化 —
.wslconfigでメモリ制限を設定する - デフォルト設定のまま使っている —
.wslconfig必須 - スリープ復帰後のVM不整合 —
wsl --shutdownで再起動 - Windows Insider Build の不安定性 — 安定版の使用を検討
- WSL カーネルの更新不足 —
wsl --updateで最新化
そして切断は完全には防げない前提で、CLAUDE.md の整備とこまめな git コミットで被害を最小化する。Claude Code と WSL2 の組み合わせは強力だが、この一手間をかけるかどうかで開発体験がまったく変わる。