WSL2でClaude Codeが突然切断される主な原因は、VMMem のメモリ肥大化だ。.wslconfig でメモリ上限と autoMemoryReclaim を設定すれば、ほとんどのケースで解決できる。
最初は Claude Code 側の問題だと思うだろう。トークン使いすぎたのか、API が落ちたのか。でもタスクマネージャーを見ると VMMem がメモリを大量に食っていて、Windows 側がメモリ不足で WSL2 の VM を殺している — このパターンが GitHub Issues でも頻繁に報告されている。原因は 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 のデフォルト設定では、物理メモリの最大50%まで VM が使える（Microsoft公式ドキュメント参照）。16GB のマシンなら約 8GB を WSL2 が持っていける計算だ。
Claude Code を動かしながら、VS Code、ブラウザ、Docker なども使っていれば、メモリはあっという間に枯渇する。
対策: .wslconfig でメモリ制限を設定する
Windows 側の %UserProfile%\.wslconfig を作成（または編集）する。
[wsl2]
memory=8GB
swap=4GB
localhostForwarding=true
[experimental]
autoMemoryReclaim=dropcache
sparseVhd=true
autoMemoryReclaim=dropcache は、WSL2 が使い終わったキャッシュメモリを即座に解放する設定だ。WSL 1.3.10以降で使える。gradual（徐々に解放）も選べるが、dropcache のほうが確実にメモリを返してくれる。sparseVhd=true は仮想ディスクの未使用領域を自動的に縮小する。
ファイルの場所は C:\Users\<ユーザー名>\.wslconfig だ。
# PowerShell で作成する場合
notepad "$env:USERPROFILE\.wslconfig"
設定後、WSL を再起動して反映する。反映には約8秒かかる（8秒ルール）。
wsl --shutdown
次に WSL を開いたときから新しい設定が適用される。
| 物理メモリ | 推奨 memory | 推奨 swap | 理由 |
|---|---|---|---|
| 16GB | 6GB | 4GB | Windows側に10GB残す |
| 32GB | 12GB | 8GB | 余裕を持たせる |
| 64GB | 24GB | 8GB | 十分な余裕 |
迷ったら物理メモリの 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 の自動保存があれば復帰は早い。
スリープ復帰後のネットワーク問題が頻繁に起きる場合は、.wslconfig で networkingMode=mirrored を試してみる価値がある。これはWSL2のネットワークをWindowsとミラーリングする実験的機能で、スリープ後のネットワーク復旧が改善されるケースがある（Windows 11 22H2以降で利用可能）。
[wsl2]
networkingMode=mirrored
ただし、mirrored モードには既知の問題もある。Docker との併用で問題が出ることがあるので、環境に合わせて判断してほしい。
Windows Insider Build が WSL2 の切断を引き起こすか？
Windows Insider Program（Dev / Canary チャネル）を使っている場合、WSL2 の安定性が低下することがある。
例えば Windows ビルド 10.0.26200 系は Canary チャネルのプレビューで、Hyper-V 周りの変更が頻繁に入る。WSL2 は Hyper-V 上で動いているため、直接影響を受ける。Canaryチャネルで頻繁に切断されるケースはGitHub Issuesでも報告が多い。安定版に戻すのが無難だ。
確認方法
# Windows のビルド番号を確認
winver
ビルド番号が安定版（26100系）より大きい場合は Insider Build だ。
対策
- Feedback Hub でWSL の切断問題を報告する（Microsoft は Insider ユーザーからのフィードバックを重視している）
- 安定性を最優先するなら、Release Preview チャネルに切り替えるか、Insider を抜ける
- WSL 自体を最新に保つ：
wsl --update
WSL カーネルが古いと切断が起きるのか？
WSL2 のカーネルバージョンが古いと、既知のバグを踏む可能性がある。
wsl --version
このコマンドで WSL バージョンとカーネルバージョンが表示される。定期的に更新しておく。
wsl --update
2026年3月時点の最新カーネルは 6.6.114.1 だ。wsl --version で表示されるカーネルバージョンがこれより古ければ、更新で安定性が改善される可能性がある。WSL2カーネルのリリースノートで変更内容を確認できる。
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 にも「キリのいいところでコミットして」と指示しておくとよい。切断によるトークンの無駄遣いが気になるなら、トークン消費を50%削減した方法も読んでみてほしい。
tmux / screen を使う（効果は限定的）
ターミナルマルチプレクサを使えば SSH 切断には耐えられるが、WSL2 の VM 自体が落ちる場合は tmux も道連れになる。VM が落ちるケースでは tmux は助けにならない。ネットワーク起因の一時的な切断には有効だ。
よくある質問
VMMemが大量にメモリを使うのはなぜ？
WSL2はHyper-V仮想マシン上で動作しており、VMMemプロセスがそのメモリ使用量を表す。Linuxカーネルがファイルキャッシュをメモリに保持し続ける設計のため、Claude Codeのようにファイルの読み書きが多い処理を実行するとメモリが膨らむ。.wslconfig で上限を設定しないとホストOSのメモリを圧迫する。
WSL2が突然切断されるのを防ぐには？
.wslconfig でメモリ上限（memory=8GB 等）とスワップサイズを設定し、[experimental] セクションに autoMemoryReclaim=dropcache を追加する。Windows Insider Buildを使っている場合は安定版に戻すことも検討する。
切断されたときにClaude Codeの作業内容は消える？
はい、セッションのコンテキストは失われる。対策として CLAUDE.mdに作業状態を記録する設計にしておくと、再接続後にスムーズに復帰できる。こまめな git コミットも重要だ。
autoMemoryReclaimの「gradual」と「dropcache」はどう違う？
gradual はアイドル時に徐々にメモリを解放する。dropcache はキャッシュを即座に解放する。Claude Codeのようにファイルアクセスが頻繁なワークロードでは dropcache の方が効果が大きい。gradual は zswapとの互換性問題が報告されているため、問題が出たら dropcache に変更しよう。
networkingMode=mirroredにすべき？
スリープ復帰後のネットワーク問題が頻繁なら試す価値がある。ただし、Docker Desktop との併用で問題が出るケースや、VPN環境で接続が不安定になるケースがある。まずはデフォルトの NAT モードで運用し、ネットワーク問題が再発する場合に切り替えるのがおすすめだ。
WSL2とWSL1はどう違う？どちらを使うべき？
WSL1はWindowsカーネル上でLinuxシステムコールを変換する。WSL2は軽量VMで実際のLinuxカーネルを動かす。Claude Codeのようにファイル操作やNode.jsビルドを多用する場合はWSL2の方が互換性が高い。ただしWSL2の方がメモリを多く消費するため、.wslconfig での制御が必須になる。
Claude Codeの長時間セッションでWSL2が不安定になるのを防ぐには？
トークン消費を抑える工夫と、長時間セッション管理を組み合わせるのが効果的だ。タスクマネージャーでVMMemの使用量を監視し、物理メモリの40%を超えたら wsl --shutdown で一度リセットする習慣をつけるとよい。
まとめ
WSL2 環境で Claude Code が突然切断される原因は、大きく5つに分類できる。
- VMMem のメモリ肥大化 —
.wslconfigでメモリ制限を設定する - デフォルト設定のまま使っている —
.wslconfig必須 - スリープ復帰後のVM不整合 —
wsl --shutdownで再起動 - Windows Insider Build の不安定性 — 安定版の使用を検討
- WSL カーネルの更新不足 —
wsl --updateで最新化
そして切断は完全には防げない前提で、CLAUDE.md の整備とこまめな git コミットで被害を最小化する。Claude Code と WSL2 の組み合わせは強力だが、この一手間をかけるかどうかで開発体験がまったく変わる。
WSL以外のトラブルで困っているなら Claude Codeトラブルシューティング完全ガイド も参考にしてほしい。Docker環境の構築には Claude Code × Docker開発環境構築ガイド が役立つ。