Windows Subsystem for Linux 2（WSL2）は、軽量な仮想マシン内で実際のLinuxカーネルを動作させる仕組みだ。現在ではsystemdやLinux GUIアプリケーション、GPUコンピューティングにも対応し、Visual Studio CodeやDocker Desktopとの連携も進んでいる。一般的なPython・Web・AI開発なら十分にこなせる環境となった。
一方、性能や安定性、ハードウェアを最大限に利用する点ではネイティブLinuxが有利だ。ただし、その差がすべての開発者にとってWindowsを捨てるほど大きいとは限らない。
WSL2とネイティブLinuxの性能差
メモリ使用量、CPU性能、ストレージ性能の3つの観点から比較する。
メモリ使用量について、ネイティブLinuxではOS、デスクトップ環境、開発ツールが物理メモリを直接使用する。WSL2ではWindowsの使用量に加え、LinuxカーネルとWSL用仮想マシンのメモリが必要になる。PC全体のメモリ消費量だけを比較すれば、WSL2のほうが大きくなりやすい。ただし、WSL2は必要に応じてメモリを割り当てる。.wslconfigを使えば、WSL2が利用できるメモリ量、プロセッサー数、スワップ容量なども設定できる。
CPU性能では、WSL2では実際のLinuxカーネルが仮想化技術の上で動作する。ネイティブLinuxのようにハードウェア上で直接OSが動くわけではないため、仮想化による処理は存在する。それでも、Pythonによる数値計算、コンパイル、圧縮、テストなど、CPUを長時間使用する処理では、開発の可否を左右するほどの差が常に発生するわけではない。処理時間はCPUの種類、コア数、電源設定、冷却、バックグラウンドで動作するWindowsアプリケーションにも左右される。最大性能を安定して引き出すことが目的ならネイティブLinuxが有利だ。一方、コードの作成、テスト、ローカルサーバの実行が中心なら、CPU性能だけを理由にWSL2を避ける必要性は低い。
ストレージは、両者の差が最も表れやすい項目だ。WSL2のLinuxファイルシステム内で作業する場合、通常のLinuxツールは比較的効率よくファイルへアクセスできる。問題になるのは、Windows側のNTFSに置いた大量の小さなファイルを、WSL2のLinuxプロセスから読み書きする場合だ。pip install、npm install、Gitのcheckout、ソースコード検索、Dockerのbind mountなどは、小さなファイルを大量に処理する。この種の作業を/mnt/c/Users/...で実行すると、ファイルシステム間の変換が入り、性能が大きく低下することがある。MicrosoftとDockerはいずれも、Linuxから扱うプロジェクトをWSL側のLinuxファイルシステムに置くよう案内している。ネイティブLinuxでは、この境界自体がない。
Python・Git・VS CodeならWSL2で十分か
Pythonの基本的な開発手順は、WSL2とネイティブLinuxでほぼ同じだ。Ubuntuのパッケージ管理機能でPythonを導入し、venvやほかの環境管理ツールを利用できる。WSL2上で作った仮想環境はLinux用であり、Windows版Pythonの仮想環境とは別物だ。Windows側のPythonとWSL側のPythonを混在させず、プロジェクトごとにどちらを使うか決める必要がある。純粋なPythonコードの実行では、両者の差は小さくなりやすい。NumPy、PyTorch、データベースドライバーなど、ネイティブライブラリーを含むパッケージでも、WSL2はLinux用パッケージを使用するため、本番Linuxサーバに近い構成を作れる。
Gitのcloneでは、ネットワーク速度に加え、取得したオブジェクトの展開とファイル作成が発生する。大規模リポジトリーのcheckoutやブランチ切り替えでは、小さなファイルへのアクセスが増える。WSL2のLinuxファイルシステム内なら通常は快適に利用できる。Windows側ファイルシステム上のリポジトリーをWSL版Gitで操作する構成は避けたほうがよい。ファイル名の大文字と小文字、実行権限、改行コードなども、WindowsとLinuxでは扱いが異なるためだ。ネイティブLinuxでは、Git、シェル、ビルドツール、ファイルシステムがすべて同じOS上にあるため、構成が単純でトラブルの切り分けもしやすい。
開発体験では、WSL2が強い。VS CodeのWSL拡張機能を使うと、画面を表示するVS Code本体はWindowsで動かしながら、ターミナル、Python、Git、デバッガー、拡張機能の一部をWSL側で実行できる。Linuxのツールチェーンを利用しつつ、Windowsの日本語入力、ブラウザー、Officeアプリケーションなども同時に使える。WSLのシェルでプロジェクトディレクトリへ移動し、code .を実行すれば、そのディレクトリをVS Codeで開ける。ネイティブLinuxでもVS Codeは利用できるため、コード編集機能そのものに大きな差はない。ただし、業務用アプリケーションや周辺機器の都合でWindowsが必要な利用者にとって、WindowsとLinuxを再起動せず併用できる点はWSL2の大きな利点だ。
DockerはWSL2とネイティブLinux、どちらが有利か
WindowsでWSL2を使う場合、代表的な構成はDocker DesktopのWSL2バックエンドだ。Docker DesktopはWSL2上のLinuxコンテナ実行環境を管理し、指定したWSLディストリビューションからDockerコマンドを使用できる。Docker DesktopにはGUI、更新管理、ログイン機能、Kubernetes関連機能、拡張機能などが統合されている。ネイティブLinuxではDocker Engineを直接インストールする構成が一般的であり、Windows用Docker Desktopを必須としない。
イメージ作成では、ベースイメージの取得、パッケージの展開、ソースコードのコピー、コンパイルなどが行われる。ビルドコンテキストがWSL側のLinuxファイルシステムにあれば、WSL2でも実用的な速度になる。ネイティブLinuxでは、Docker Engine、ストレージドライバー、ホストのファイルシステムがLinux上で完結するため、構成が単純で、CIサーバや本番サーバとの一致度も高い。コンテナの起動自体は、多くの開発用途で両者とも十分に速い。差が出やすいのは、起動処理よりも、起動後に大量のホストファイルへアクセスする処理だ。
Dockerのvolumeは、Dockerが管理する領域にデータを保存する。bind mountは、ホスト上の特定ディレクトリをコンテナ内へ直接公開する仕組みだ。WSL2でbind mountを使用する場合、ソースコードを/home以下に置けば性能を確保しやすい。反対に、/mnt/c以下をコンテナへ渡すと、Windows、WSL2、コンテナの境界を越えてファイルへアクセスすることになり、速度低下やファイル変更通知の問題が起こりやすい。DockerもLinuxファイルシステムからのbind mountを推奨している。Docker中心の開発でも、正しく構成したWSL2なら十分実用的だ。ただし、コンテナを大量に常時稼働させる、I/O負荷の高いデータベースを検証する、本番と同じ運用条件を再現する、といった用途ではネイティブLinuxが有利になる。
AI開発はWSL2でどこまでできるか
OllamaはWindows版とLinux版を提供しており、WindowsではネイティブアプリケーションとしてNVIDIAおよびAMD Radeon GPUを利用できる。Dockerコンテナについては、LinuxまたはWSL2上でNVIDIA GPUを利用する構成も公式に案内されている。単にローカルLLMを実行するだけなら、Windows版Ollamaを使い、WSL2内のアプリケーションからAPIへ接続する構成も選べる。
WSL2はNVIDIA CUDAを正式にサポートしている。対応するWindows用NVIDIAドライバーをインストールすると、WSL2内のLinuxアプリケーションからGPUコンピューティングを利用できる。PyTorchの学習、推論、CUDA対応コンテナの実行など、一般的なAI開発はWSL2でも可能だ。ただし、NVIDIAはCUDA on WSLの資料で、ネイティブLinuxでは利用できてもWSL2では制限される機能があることを明記している。対応状況はCUDA、ドライバー、GPU世代によって変わるため、プロファイリング、デバッグ、マルチGPU、特殊なメモリ管理機能を使う場合は、最新の制限一覧を確認する必要がある。
AMDも対応するRadeonおよびRyzen製品向けに、WSL2上のROCmを提供している。ただし、対応GPU、Windowsドライバー、Ubuntu、ROCmの組み合わせは限定される。AMDはバージョンごとのWSL対応表を公開しているため、GPUの型番が掲載されているかを導入前に確認する必要がある。ネイティブLinuxでもROCmはすべてのAMD GPUを一律にサポートするわけではない。それでも、利用できるディストリビューション、カーネル、ドライバー、管理ツールの選択肢は、一般にネイティブLinuxのほうが広い。
PyTorchはCPU版、CUDA版、ROCm版を提供している。公式のインストールページでは、OS、パッケージ管理方法、言語、GPUプラットフォームを選び、対応するコマンドを確認できる。NVIDIA GPUを使った単一GPUの学習や推論であれば、WSL2でも実用的な環境を作れる。一方、GPUドライバーを細かく制御する必要がある研究、大規模なマルチGPU処理、特殊な計測機能、独自カーネルモジュールを必要とする作業では、ネイティブLinuxを選ぶほうが安全だ。
ネイティブLinuxが必要になる5つのケース
大量のファイルI/Oが発生する場合、WSL2ではLinuxの開発プロジェクトをWSL側のファイルシステムに置くことで多くの性能問題を避けられる。ただし、Windows側のファイルを頻繁に読み書きするなど、ファイルシステムの境界を越える処理が多い場合はネイティブLinuxが有利だ。
USBやデバイスを直接扱う場合、WSL2からUSB機器を利用するには、USB/IPを利用するusbipd-winなどが必要になる。Arduinoへの書き込みやスマートカードリーダーなども利用できるが、USBや周辺機器を直接制御する用途ではネイティブLinuxのほうが構成は単純だ。
LinuxのGUIやデスクトップ環境を検証する場合、WSLgを使えばX11やWaylandのLinux GUIアプリケーションをWindows上に表示できる。ただし、デスクトップ環境や表示サーバ、入力機器、ウィンドウ管理まで含めてLinux環境そのものを検証するなら、ネイティブLinuxが適している。
ネットワークやカーネルを低レベルで扱う場合、WSL2はWindows側のネットワーク環境の影響を受ける。ミラーモードなどによって互換性は改善されているものの、特殊なネットワーク構成の検証やカーネルモジュールの開発、Linuxホスト向けセキュリティ機能の評価などでは、ネイティブLinuxが必要になる。
GPUの機能を最大限に利用する場合、WSL2でもCUDAや対応するROCmを利用でき、一般的なAI開発には十分対応できる。ただし、利用できるGPUや機能はネイティブLinuxと完全に同じではない。マルチGPUや高度なプロファイリングなど、GPUを細かく制御する用途ではネイティブLinuxが適している。
結論：WSL2とネイティブLinuxの選び方
Python、Git、VS Code、Web開発、一般的なDocker開発、単一GPUでのPyTorchやローカルLLM実行が中心なら、WSL2で十分な場合が多い。Windowsの業務アプリケーションを使いながらLinuxの開発環境を利用でき、デュアルブートのような再起動も必要ない。一方、ストレージI/O性能を最大化したい場合や、USBなどのデバイス、ネットワーク、カーネル、GPUを低レベルで制御したい場合はネイティブLinuxが適している。本番環境とOS構成をできるだけそろえたい場合も、ネイティブLinuxが有利だ。
用途別にまとめると、次のようになる。Windowsを使いながらPythonやWeb開発を行う場合、VS Code中心のLinux開発、一般的なDocker Compose開発はWSL2が適している。単一GPUでのAI学習・推論はWSL2またはネイティブLinux、大規模Docker・高負荷データベース検証、マルチGPUや高度なGPU解析、USB・デバイス・カーネル開発、Linuxデスクトップを常用する場合はネイティブLinuxが適している。OfficeなどWindows専用ソフトも必要な場合はWSL2が適している。
WSL2を選ぶ場合に重要なのは、Linuxで処理するプロジェクトをWSL側のLinuxファイルシステムへ置くことだ。すべてのコードをWindows側のCドライブ上で扱うと、ファイルI/Oがボトルネックとなり、WSL2本来の性能を引き出せない場合がある。WSL2は「本物のLinuxではないから使えない」という段階をすでに脱している。現在のWSL2は、多くのWindows開発者にとって現実的な選択肢だ。ただし、WSL2はWindowsとLinuxの境界を消す技術ではない。境界を意識せずにファイル、ネットワーク、USB、GPUを扱うと、性能低下や互換性問題が発生する。WindowsとLinuxを同じPCで効率よく使うならWSL2、Linuxそのものを最大限に制御するならネイティブLinux。この基準で選べば、必要以上に環境構築へ時間を費やさずに済む。
