WSL のファイルシステムのパフォーマンス: OS 間の境界をまたぐアクセスがコードを遅くする理由

By Mirko Peters · 2026-10-27

OS をまたぐファイルアクセスが WSL を遅くする理由を解説します。Linux ネイティブのストレージを使うベストプラクティスと、開発ワークフローを高速化する方法を紹介します。

Automatically translated with AI from the original post. Read the English original

Windows Subsystem for Linux (WSL) で Windows と Linux のファイルシステムを混在させると、大きなパフォーマンスのボトルネックが生じる理由を解説します。プロジェクトディレクトリを OS の境界の正しい側に置くための重要なルールを学び、ディスク負荷の高いビルド処理、パッケージのインストール、git 操作を大幅に高速化しましょう。

重要なポイント

• /mnt/c/ 経由で Windows ドライブ上に Linux のプロジェクトファイルを置くと、境界をまたぐ変換コストにより、パフォーマンスが著しく低下します。
• node_modules のような膨大なファイルツリーは、ビルドや更新の際に OS の境界をまたぐため、最も大きな影響を受けます。
• Microsoft の公式な推奨は、ファイルを、編集やコンパイルに使うツールと同じオペレーティングシステム上に置くことです。
• VS Code には Remote - WSL 拡張機能があり、パフォーマンスを犠牲にすることなく、Windows のインターフェースを使って Linux 上のファイルをシームレスに編集できます。
• 大文字と小文字の扱いは、Windows と Linux のファイルシステムで大きく異なります。予期しないバグを避けるには、ディレクトリを適切に配置することが不可欠です。

Windows と Linux のファイルシステムの違いを理解する

Windows Subsystem for Linux を使い始めた開発者がよく陥る落とし穴の一つが、ファイルの不適切な配置です。Windows と Linux では、ストレージの仕組みがまったく異なる設計思想に基づいています。WSL 2 を実行すると、軽量な仮想マシン内で実際の Linux カーネルが動作します。つまり、Linux ディストリビューションは、POSIX 標準に従って動作する、独立したネイティブの Linux ファイルシステムを持ちます。

一方、一般的な Windows 環境は NTFS を基盤とし、C: ドライブのようなドライブレターを使います。両者の橋渡しとして、WSL は Windows ドライブを /mnt/ ディレクトリ配下に自動的にマウントします。たとえば C ドライブは /mnt/c として見えます。これにより、Linux のターミナルからホストマシン上のすべてのファイルを読み書きできるようになりますが、同時に「境界横断の変換パス」と呼ばれる、見えにくく、非常にコストの高いパフォーマンスの負担も生じます。

なぜ境界をまたぐファイルアクセスは遅くなるのか

Linux のツールがシステムの Windows 側にあるファイルを読み書きするたびに、そのリクエストは軽量仮想マシンと Windows ホストの境界を通過しなければなりません。単一のテキストファイルや小さなスクリプトであれば、この変換のオーバーヘッドは体感できないほどです。しかし、現代のソフトウェア開発ワークフローでは、扱うファイルが 1 つだけということはほとんどありません。

/mnt/c/my-project にあるプロジェクトディレクトリで npm install や git clone を実行した場合を考えてみてください。これらの操作では、何千もの小さなファイルの作成や変更リクエストが短時間に次々と発生します。その小さなファイル一つひとつが、境界を越えるコストを支払うことになります。その累積的な影響により、本来は数秒で終わるはずの処理が数分かかることがあります。その結果、多くの開発者は、原因が単に不適切なディレクトリ配置にあるにもかかわらず、WSL 自体が本質的に遅いと誤解してしまいます。

大文字と小文字の区別とアクセス許可の競合

OSの境界を越えると、性能だけが問題になるわけではありません。ファイルシステムのルールも衝突し、アプリケーションが動かなくなることがあります。ネイティブのLinuxファイルシステムのルートは厳密に大文字と小文字を区別します。Script.jsとscript.jsという2つのファイルは、まったく別のものとして扱われます。一方、Windows NTFSは既定で大文字と小文字を区別しません。

さらに、Linuxのコマンドラインユーティリティは、chmodやchownなどのユーティリティで管理される所有者と権限のフラグに強く依存しています。Windowsのファイルシステムは、これらの権限をLinuxのツールが期待する形で直接対応付けることができません。境界を越えてコードを実行すると、シンボリックリンクが正しく解決されないことがあります。また、ビルドスクリプトは、ランタイム環境に必要なファイル権限を適用できないため、原因のわかりにくいエラーを出すことがあります。

高速なWSLワークフローのためのベストプラクティス

こうした性能上の落とし穴を避け、快適な開発環境を保つには、次の2つの基本的な習慣を守ることをお勧めします。まず、Linuxのプロジェクトは必ずネイティブのLinuxファイルシステム内(~/projects/などホームディレクトリ内)に置き、Windowsだけで完結するプロジェクトはWindows側に置いてください。

次に、実行速度を犠牲にすることなく、最新のツールを活用してユーザーインターフェースをつなぎましょう。お気に入りのWindowsエディターを手放す必要はありません。Visual Studio Code用のRemote - WSL拡張機能を使えば、ネイティブのLinuxファイルシステム内にあるプロジェクトを、応答性が高く使い慣れたWindowsのグラフィカルインターフェースで開けます。エディターはWindows上で動作しますが、コードの実行、テスト、パッケージ管理はLinux環境内で最高速度で行われます。

まとめと次のステップ

ファイルシステムの境界を理解することは、WSLを扱いにくい実験段階から日常的に使える開発環境へと変えるうえで最も重要なステップです。ツールとファイルをオペレーティングシステムの境界の正しい側に配置することで、待ち時間を解消し、わかりにくい権限エラーを避けられます。

WSLがどのようにモダンな開発やクラウドのワークフローに統合されるかについて、より広い視点を知りたい方は、M365 FM Podcastのエピソード全体を聴いてください。インストールのショートカット、バージョンの比較、WSLがローカルマシンとAzureクラウドインフラストラクチャの橋渡しをする仕組みについて、完全版の議論でさらに詳しく確認できます。

よくある質問

WSLを使う場合、プロジェクトファイルはどこに保存すればよいですか?

マウントされたWindowsドライブ(/mnt/c/など)ではなく、ネイティブのLinuxファイルシステム内(ホームディレクトリ内の~/my-projectなど)に保存してください。読み取りと書き込みの速度を最大限に高めることができます。

WSLで、Windowsドライブ上でnpm installを実行すると遅いのはなぜですか?

npmやpipなどのパッケージマネージャーは、インストール中に数千もの小さなファイルを生成します。これらのファイルをWindowsのNTFSドライブへOSの境界を越えて書き込むと、ファイルごとに変換のオーバーヘッドが発生し、大きな性能のボトルネックになります。

Visual Studio Codeを使って、Linuxファイルシステム内のファイルを編集できますか?

はい。Visual Studio Code用のRemote - WSL拡張機能をインストールすれば、標準のWindowsエディターのインターフェースを使いながら、WSLのLinuxディストリビューション内にあるファイルをそのまま開く、編集する、デバッグすることができます。

WindowsとLinuxでファイル名の扱いはどう違いますか?

Linuxのファイルシステムは厳密に大文字と小文字を区別します(File.txtとfile.txtは別のファイルとして扱われます)。一方、Windows NTFSは既定で大文字と小文字を区別しません。このような動作の違いから、Windows上のディレクトリでLinuxのツールを実行すると、ビルドが失敗することがよくあります。