WSL2が遅い原因は？高速化する設定と対策まとめ

• 

  WSL2はWindows上でLinuxを利用できる便利な仕組みだが、ファイルI/Oや仮想化の影響で性能低下が発生する場合がある 出典：Canonical

はじめに

Windows環境でLinuxを利用できる「WSL (Windows Subsystem for Linux)」は、多くの開発者にとって欠かせない存在になった。Docker、Python、Node.js、Go、RustなどLinux前提の開発ツールが増えたことで、WindowsとWSLを併用する開発スタイルが一般化している。

しかしその一方で、WSL利用者からは次のような不満も多い。

• Git cloneが遅い
• npm installが終わらない
• Dockerのビルドが重い
• ファイル操作が遅い
• メモリーを大量消費する
• WindowsよりLinux側のほうが重い

特に多いのが、「WSL2にしたら急に重くなった」という声だ。

その最大の原因は、WSL2が「軽量Linux VM」として動作している点にある。Windows側ファイルシステムへのアクセスでは、仮想化やI/O同期のオーバーヘッドが発生し、大量ファイル処理で極端に遅くなる場合がある。

本稿では、WSL2が遅くなる理由、高速化設定、仮想化の仕組み、企業利用時の注意点までを整理して説明する。

そもそもWSLとは何か

WSLは、Windows上でLinux環境を動作させるための仕組みだ。

初期のWSL1は、LinuxシステムコールをWindowsカーネルへ変換する方式だった。仮想マシンを使わないため軽量だったが、Linux互換性には制限があった。

現在主流のWSL2は「軽量仮想マシン」として動作する。本物のLinuxカーネルが動作している。言い換えると、Windowsの中でHyper-VベースのLinux VMが動いているということだ。本物のLinuxカーネルを使うため、DockerやKubernetesとの互換性が大幅に向上した。しかし、この仕組みには本質的に速度低下の問題がある。

WSL1とWSL2の違い

WSL1とWSL2には大きな違いがある。

WSL1の特徴

• LinuxシステムコールをWindowsへ変換
• 仮想マシンを使用しない
• 起動が高速
• メモリ消費が少ない
• Windowsファイルアクセスは比較的高速
• Dockerとの相性が悪い
• Linux互換性に制限がある

WSL2の特徴

• Hyper-Vベースの軽量仮想マシン
• 本物のLinuxカーネルを利用
• DockerやKubernetesとの相性が良い
• Linux互換性が高い
• メモリ消費が増えやすい
• Windows側のファイルアクセスが遅い

WSL2は互換性が高い代わりに、「仮想化コスト」が存在する。Linuxネイティブではなく、あくまでWindows上のVMであるため、ディスクI/Oやファイル同期にオーバーヘッドが発生する。中でも問題になるのが「Windowsファイルシステムへのアクセス」だ。

WSL2が遅くなる最大の原因

最も問題になりやすいのが、Windows側ファイルシステムへのアクセスだ。

例えば、次のようなパス：

• /mnt/c/project

これはWindows側のCドライブをLinuxから参照している状態だ。一見便利だが、ここに大きな罠がある。

LinuxからWindowsファイルへアクセスする際、以下の複数レイヤーを経由する。

• Linuxカーネル
• 仮想ファイルシステム
• Hyper-V
• Windows NTFS
• Windows Defender
• I/O同期

その結果、大量ファイル処理でI/O遅延が大きくなる。典型例は次のような処理だ。

• node_modules
• Git repository
• Docker build context
• Python venv
• Composer install

特にnpm installのような「小さいファイルを大量生成する処理」では、metadata同期や権限変換が大量発生し、極端に遅くなることがある。

WSL2が遅いときに確認すべきこと

Windows側ディスクを使っている

最も多い原因だ。次の場所で開発していると速度低下が発生する。

• /mnt/c/
• /mnt/d/

WSL2はLinux仮想ディスク(ext4.vhdx)内部で動作する設計になっているため、本来はLinux側ホームディレクトリを使うべきだ。

推奨される場所は、たとえば次のようになる。

• ～/project
• /home/user/project

これだけで大幅に高速化するケースもある。

メモリ消費が大きい

WSL2は自動的にメモリを確保する。DockerやKubernetesを利用すると、8GB～16GBを簡単に占有する。しかも解放が遅い。

その結果、次のような問題が発生する。

• Windows全体が重い
• Chromeが落ちる
• VSCodeが固まる

Windows Defenderのリアルタイムスキャン

見落とされがちだが影響は大きい。WSL上のファイル操作に対して、Windows Defenderがリアルタイムスキャンを行う場合があり、特に次の処理は重い。

• node_modules
• vendor
• .git
• Docker cache

リアルタイム保護が有効だと、ファイル生成のたびにスキャンが走る。これはI/O性能を著しく低下させる。

Docker Desktopとの競合

Docker Desktopは内部的にWSL2を利用している。

そのため、以下を同時に利用すると、CPUやメモリ、I/Oが競合しやすい。

• WSL
• Docker
• Kubernetes
• VSCode Remote

スワップ発生

WSL2はスワップファイルを使用する。物理メモリ不足時にディスクへ退避するため、SSDでも極端に遅くなる。Docker build時などに顕著だ。

WSL2を高速化する設定と対策

Linux側ディレクトリで作業する

最も効果が大きい改善策だ。

具体的には、次のようなパスの利用を避ける。

• /mnt/c/project

代わりに次のようなパスを使う。

• ~/project

こうしたパスのファイルは、VSCode Remote WSLを使えば、Linux側ファイルでもWindowsから快適に編集できる。

.wslconfigを設定する

Windowsユーザーディレクトリに設定ファイル「.wslconfig」を作成する。

• C:\Users\ユーザー名.wslconfig

例：

C:\Users\ユーザー名.wslconfig

[wsl2]
memory=8GB
processors=4
swap=2GB
localhostForwarding=true

この設定によって、

• メモリ暴走防止
• CPU制御
• スワップ抑制

が可能になる(もちろん、設定内容は使っているPCのスペックに合わせて調整が必要だ。上記はあくまでもサンプルとして書いてある)。

Defender除外設定

Windows Defenderに次を除外登録すると、I/O性能改善につながる場合がある。

• WSLディレクトリ
• node_modules
• Docker data

ただし、企業PCではセキュリティポリシーに注意が必要だ。

不要ディストリビューションを整理

複数のLinux環境を入れると仮想ディスクが増える。不要なLinux環境を削除すると、仮想ディスク肥大化を防げる。

確認：wsl -l -v

削除：wsl --unregister ディストリビューション名

VHDXを最適化

WSL2の仮想ディスク(ext4.vhdx)は肥大化しやすい。以下の子マントで、ディスク断片化を改善できる。

PowerShellで圧縮可能：Optimize-VHD

WSL2と仮想化の仕組み

WSL2は、Hyper-V上でLinuxカーネルを動作させている。

WSL2の階層構造

Windows
 └ Hyper-V
    └ Linux VM
       └ Ubuntu

つまり、現在のWSL2は「軽量VM」に近い。そのためLinux互換性は高い一方、WindowsとLinux間でファイル共有を行う際にオーバーヘッドが発生する。

特に、/mnt/c/のようなWindows側アクセスでは性能低下が顕著になりやすい。

Dockerが重くなりやすい理由

Docker DesktopはWSL2上で動作する。

Docker on WSL2の構造

Windows └ WSL2 └ Docker Engine └ Container

Linuxネイティブ環境より仮想化レイヤーが増えるため、I/O負荷が高い処理ではオーバーヘッドが発生しやすい。

企業利用時の注意点

セキュリティ管理が難しい

WSLは、Windowsの内部では以下がWindows管理外になりやすい。

• Linuxパッケージ管理
• SSH鍵
• Docker image
• npm package

情報システム部門から見ると、ブラックボックス化しやすい。

Defender除外がリスクになる

高速化のため除外設定を行うと、マルウェア検知が弱くなる。

近年は、次のようなセキュリティのリスクが増えている。

• npmサプライチェーン攻撃
• 悪意あるDockerイメージ
• Pythonパッケージ感染

WSLはLinuxだから安全、という認識は誤りだ。

VPNとの相性問題

WSL2は独立した仮想NICを持つ。企業のVPN環境では次の問題が発生することがある。

• DNS解決失敗
• 社内ホスト到達不可
• Proxy設定崩壊

Hyper-V競合

WSL2はHyper-V依存のため、以下の製品と競合する場合がある。

• VMware
• VirtualBox旧版
• Android Emulator
• 一部VPNソフト

企業端末では仮想化制限がかかるケースも多い。

WSL2は便利だが、万能ではない

WSLは優秀な技術だ。次のような、メリットがある。

• Linux互換性が高い
• Dockerが動く
• VSCode連携が強い
• Windowsアプリと共存できる

一方で、次のような要件を求める場合にはネイティブLinuxの方が有利なケースもある。

• 高性能I/O
• 重量級コンテナ
• 大規模Kubernetes
• 高負荷CI

WSLは「万能Linux」ではなく、「Windowsとの共存を優先した開発環境」と考えるべきだ。

まとめ

WSLが遅い理由は単純ではない。本質的には、以下のような複数の要因が絡み合っている

• 仮想化
• ファイル共有
• Windows Defender
• I/O同期
• メモリー管理

中でも重要なのは、

• /mnt/c/

を避け、Linux側ファイルシステムで作業することだ。また、以下を体感性能は大きく改善する。

• .wslconfig最適化
• Defender除外
• メモリー制御
• Docker整理

WSL2は「Linuxそのもの」ではなく、「Windows上の軽量Linux VM」だ。この構造を理解すれば、なぜ遅いのか、どこを改善すべきかが見えてくる。

今後もWindows開発環境の中心としてWSLは進化を続けるだろう。しかし快適に利用するためには、仮想化とI/Oの仕組みを理解した上で運用することが重要だ。