WSLで/mnt/cが遅い理由と解決策｜npm installも激重になる構造を解説

# WSLで/mnt/cが遅い理由と解決策｜npm installも激重になる構造を解説

結論：/mnt/cが遅い原因はファイルシステムの変換コスト

WSLで /mnt/c 配下のファイルを触ると遅くなる。これは設定の問題でも、PCのスペックが足りないわけでもありません。

原因はシンプルで、Windowsのファイルシステム（NTFS）とLinuxのファイルシステム（ext4）が根本的に別物だからです。WSLからWindowsのCドライブ（/mnt/c）にアクセスするたびに、2つのシステムの間でデータ変換が発生します。この変換コストが、「遅さ」の正体です。

npm install が数分かかったり、git statusが固まったりする現象は、すべてこの構造から来ています。原因がわかれば解決策は明確です。この記事では、なぜ遅くなるのかを構造から説明し、私が実際に試した解決方法をお伝えします。WSL環境でよく起きる関連トラブルについては、この記事の末尾にあわせてまとめています。

WSLで/mnt/cが遅くなる仕組み

「WSL上でLinuxが動いているのに、なぜWindowsのファイルにアクセスすると遅くなるのか？」と思ったことはありませんか？

WSL（Windows Subsystem for Linux）は、Windows上でLinuxカーネルを動かす仕組みです。LinuxはLinux用のファイルシステム（ext4など）を使い、WindowsはNTFSを使います。この2つは設計が違うため、互いに直接読み書きすることができません。

WSLが /mnt/c を通じてWindowsのCドライブにアクセスするとき、内部では 9Pプロトコル と呼ばれる通信プロトコルを経由しています。LinuxカーネルがWindowsホストに「このファイルを読んでくれ」と要求を出し、Windowsがそれを処理して返すという通信が、ファイル操作のたびに発生します。

1回の通信コストは小さいかもしれません。しかし問題は「回数」です。ls や cat 程度なら気になりませんが、npm install のように数万個のファイルを一度に操作する処理になると、この通信が何万回も繰り返されます。結果として、処理時間が数十倍に膨れ上がることもあります。

なぜLinux側（~/ など）は速いのか

~/（ホームディレクトリ）はWSLのLinux仮想ディスク内にあります。Linuxカーネルが直接ext4ファイルシステムを読み書きするため、変換も通信も発生しません。同じWSLで同じ作業をしても、/mnt/c と ~/ では体感が全く異なります。私は最初、この差をPCのスペック差だと思っていたので、原因に気づくまで少し時間がかかりました。

npm installが特に遅くなる理由

「WSLを使い始めたばかりのころ、npm install がなぜかいつまでも終わらない」という経験をした方も多いと思います。私も最初はそうでした。

npm install が遅くなる理由は明確です。node_modules の構造がファイルI/Oの弱点をそのまま突いているからです。

npmで依存パッケージをインストールすると、node_modules 以下に大量のファイルが生成されます。中規模のプロジェクトでも、node_modules のファイル数が 5万〜10万個 を超えることはめずらしくありません。

これを /mnt/c 配下で実行した場合、何が起きるかというと：

• ファイル1個の作成ごとに9Pプロトコル経由の通信が発生する
• 5万個のファイルであれば、5万回以上の通信コストがかかる
• NTFSとext4の間でパーミッション情報の変換も毎回行われる

この積み重ねで、Linuxネイティブ環境なら1分で終わる npm install が、/mnt/c では10分以上かかることがあります。数値としては、私の環境では `~/` 上で約80秒だったインストールが、`/mnt/c` 上では約700秒かかりました（依存パッケージ数：約3,200個のプロジェクト）。

判断基準

• プロジェクトフォルダが /mnt/c/ 以下にある → すぐに ~/ に移動する
• node_modules が /mnt/c/ 以下にある → 削除して ~/ に移動してから再インストール

VSCodeやgitも遅くなる理由

npm install だけでなく、VSCodeのファイル検索やgit statusも /mnt/c 配下では重くなります。なぜでしょうか？

原因は同じですが、少し仕組みが違います。

VSCodeのファイル監視（fswatch）は、プロジェクト内のファイル変更をリアルタイムに追跡します。/mnt/c 配下のファイルを監視する場合、変更検知のたびに9P経由の通信が発生します。ファイル数が多いプロジェクトでは、この監視処理が常にバックグラウンドで重くなります。

git status も同様で、すべての追跡対象ファイルのメタデータを読み取って差分を計算します。追跡ファイルが多ければ多いほど、/mnt/c 上では処理が重くなります。私の環境では、git status の応答が /mnt/c 上で 6〜8秒 かかっていたのに対し、~/ に移動後は 0.3秒以下 になりました。

実体験ログ：移動前と移動後の差

私がこの問題に気づいたのは、WSLを使い始めて1週間ほど経ったころでした。Next.jsプロジェクトをCドライブの C:\Users\uracc\Desktop\myproject に置いたまま作業していて、開発サーバーの起動に毎回 2〜3分 かかっていました。「PCが遅いのかな」と思っていたのですが、そんなに古いマシンでもないのにおかしいと感じ始めました。

調べてみて、問題が /mnt/c 経由のアクセスコストだとわかりました。試しにプロジェクトをWSLのホームディレクトリ（~/projects/myproject）にコピーして同じ作業をしたところ、開発サーバーの起動が 15秒以内 に短縮されました。

移動前後の比較（実測値）：

操作 | /mnt/c 上 | ~/ 上
--- | --- | ---
npm install（約3,200パッケージ） | 約700秒 | 約80秒
git status（追跡ファイル約2,000） | 約7秒 | 約0.3秒
Next.js 開発サーバー起動 | 約150秒 | 約15秒

数値を見るまでは「気のせいかもしれない」と思っていましたが、これだけ差が出るとさすがに確信しました。正直、もっと早く気づいていればよかったと少し後悔しました。

解決方法：プロジェクトを ~/に移動する

解決策はシンプルです。Linuxで使うプロジェクトは、最初からLinux側（`~/`）に置く。これだけです。

移動手順

WSLターミナルを開いて、以下を実行します。

# ~/projects ディレクトリを作成（なければ）
mkdir -p ~/projects

# Cドライブのプロジェクトをコピー
cp -r /mnt/c/Users/uracc/Desktop/myproject ~/projects/myproject

# コピー後、元フォルダは確認してから削除
# rm -rf /mnt/c/Users/uracc/Desktop/myproject

コピー後は node_modules を一度削除して、Linux側で再インストールします。

cd ~/projects/myproject
rm -rf node_modules
npm install

node_modules は /mnt/c から持ち込んだものをそのまま使わないことが重要です。LinuxとWindowsでは実行バイナリの形式が違うため、Windows側でビルドされたネイティブモジュールがLinuxで動かないことがあります。必ず削除してから再インストールしてください。

環境を混在させない判断基準

• Windowsのアプリ（Excel・Photoshopなど）でも編集するファイルか？ → YESなら /mnt/c に置いてよい