WSL2で十分？ それともネイティブLinux？ Docker・Python・AIで徹底比較

WSL2は進化を続け、現在では一般的なPython・Web・AI開発なら十分にこなせる環境となった。一方、Windows側ファイルへの大量I/OやUSB機器、特殊なネットワーク構成、GPU機能の完全な利用では、依然としてネイティブLinuxに分がある。では、実際の開発ではどちらを選ぶべきなのか。Docker・Python・AIなど用途別に、性能差と使い勝手を比較する。

• 

  一般的なPython・Web・AI開発なら十分にこなせる環境となったWSL2とネイティブLinux、開発ではどちらを選ぶべきか

WSL2はもう「Linuxの代用品」ではない

Windows上でLinuxを利用することは、もはや一部の上級者だけの方法ではない。Webアプリケーションやクラウド、コンテナ、機械学習の開発ではLinuxを前提とするツールも多く、Windowsを業務用OSとして使いながら開発環境だけLinuxにしたいという需要は大きい。

その代表的な選択肢がWindows Subsystem for Linux 2（WSL2）だ。軽量な仮想マシン内で実際のLinuxカーネルを動作させる仕組みで、現在ではsystemdやLinux GUIアプリケーション、GPUコンピューティングなどにも対応し、Visual Studio CodeやDocker Desktopとの連携も進んでいる。

一方、性能や安定性、ハードウェアを最大限に利用する点ではネイティブLinuxが有利だ。ただし、その差がすべての開発者にとってWindowsを捨てるほど大きいとは限らない。

WSL2とネイティブLinux、性能差はどこに出る？

WSL2とネイティブLinuxでは、実際の開発でどの程度の性能差が生じるのか。メモリ使用量、CPU性能、ストレージ性能の3つの観点から比較する。

メモリ使用量

ネイティブLinuxでは、OS、デスクトップ環境、開発ツールが物理メモリを直接使用する。WSL2ではWindowsの使用量に加え、LinuxカーネルとWSL用仮想マシンのメモリが必要になる。

PC全体のメモリ消費量だけを比較すれば、WindowsとLinuxを同時に動かすWSL2のほうが大きくなりやすい。ただし、WSL2は必要に応じてメモリを割り当てる。.wslconfigを使えば、WSL2が利用できるメモリ量、プロセッサー数、スワップ容量なども設定できる。

メモリ容量が少ないPCで、ブラウザ、IDE、Docker、データベース、AIモデルなどを同時に動かす場合は、WindowsとLinux環境の双方がメモリを使用する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では、この境界自体がない。ストレージI/Oの予測しやすさではネイティブLinuxが優位だ。

Python・Git・VS CodeならWSL2で十分なのか

Pythonと仮想環境

一般的な開発でよく使われるPython、Git、Visual Studio Codeでは、WSL2とネイティブLinuxでどの程度の違いがあるのか。それぞれの使い勝手や注意点を見ていこう。

Pythonの基本的な開発手順は、WSL2とネイティブLinuxでほぼ同じだ。Ubuntuのパッケージ管理機能でPythonを導入し、venvやほかの環境管理ツールを利用できる。

WSL2上で作った仮想環境はLinux用であり、Windows版Pythonの仮想環境とは別物だ。Windows側のPythonとWSL側のPythonを混在させず、プロジェクトごとにどちらを使うか決める必要がある。

純粋なPythonコードの実行では、両者の差は小さくなりやすい。NumPy、PyTorch、データベースドライバーなど、ネイティブライブラリーを含むパッケージでも、WSL2はLinux用パッケージを使用するため、本番Linuxサーバに近い構成を作れる。

pip installの時間は、CPU性能だけでなく、ネットワーク、パッケージのキャッシュ、ファイル数、ビルド処理に左右される。プロジェクトがWSL側にあれば実用的だが、/mnt/c上では大量のファイル展開が遅くなる可能性がある。

Git

Gitのcloneでは、ネットワーク速度に加え、取得したオブジェクトの展開とファイル作成が発生する。大規模リポジトリーのcheckoutやブランチ切り替えでは、小さなファイルへのアクセスが増える。

WSL2のLinuxファイルシステム内なら通常は快適に利用できる。Windows側ファイルシステム上のリポジトリーをWSL版Gitで操作する構成は避けたほうがよい。ファイル名の大文字と小文字、実行権限、改行コードなども、WindowsとLinuxでは扱いが異なるためだ。

ネイティブLinuxでは、Git、シェル、ビルドツール、ファイルシステムがすべて同じOS上にある。そのため、構成が単純でトラブルの切り分けもしやすい。

VS CodeとRemote WSL

開発体験では、WSL2が強い。

VS CodeのWSL拡張機能を使うと、画面を表示するVS Code本体はWindowsで動かしながら、ターミナル、Python、Git、デバッガー、拡張機能の一部をWSL側で実行できる。Linuxのツールチェーンを利用しつつ、Windowsの日本語入力、ブラウザー、Officeアプリケーションなども同時に使える。

WSLのシェルでプロジェクトディレクトリへ移動し、次を実行すれば、そのディレクトリをVS Codeで開ける。

• 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サーバや本番サーバとの一致度も高い。

コンテナの起動自体は、多くの開発用途で両者とも十分に速い。差が出やすいのは、起動処理よりも、起動後に大量のホストファイルへアクセスする処理だ。

volumeとbind mount

Dockerのvolumeは、Dockerが管理する領域にデータを保存する。bind mountは、ホスト上の特定ディレクトリをコンテナ内へ直接公開する仕組みだ。

WSL2でbind mountを使用する場合、ソースコードを/home以下に置けば性能を確保しやすい。反対に、/mnt/c以下をコンテナへ渡すと、Windows、WSL2、コンテナの境界を越えてファイルへアクセスすることになり、速度低下やファイル変更通知の問題が起こりやすい。DockerもLinuxファイルシステムからのbind mountを推奨している。

Docker中心の開発でも、正しく構成したWSL2なら十分実用的だ。ただし、コンテナを大量に常時稼働させる、I/O負荷の高いデータベースを検証する、本番と同じ運用条件を再現する、といった用途ではネイティブLinuxが有利になる。

AI開発はWSL2でどこまでできる？## AI開発はWSL2でどこまでできる？

AI開発ではGPUをどこまで利用できるかが大きなポイントになる。OllamaやCUDA、ROCm、PyTorchを例に、WSL2でできることとネイティブLinuxが必要になるケースを見ていこう。

Ollama

OllamaはWindows版とLinux版を提供しており、WindowsではネイティブアプリケーションとしてNVIDIAおよびAMD Radeon GPUを利用できる。Dockerコンテナについては、LinuxまたはWSL2上でNVIDIA GPUを利用する構成も公式に案内されている。

単にローカルLLMを実行するだけなら、Windows版Ollamaを使い、WSL2内のアプリケーションからAPIへ接続する構成も選べる。LinuxベースのAIツール群をまとめて管理したい場合は、WSL2またはネイティブLinux上に環境を統一するとよい。

NVIDIA CUDA

WSL2はNVIDIA CUDAを正式にサポートしている。対応するWindows用NVIDIAドライバーをインストールすると、WSL2内のLinuxアプリケーションからGPUコンピューティングを利用できる。WSL内にLinux用ディスプレードライバーを重ねてインストールする構成ではない。

PyTorchの学習、推論、CUDA対応コンテナの実行など、一般的なAI開発はWSL2でも可能だ。

ただし、NVIDIAはCUDA on WSLの資料で、ネイティブLinuxでは利用できてもWSL2では制限される機能があることを明記している。対応状況はCUDA、ドライバー、GPU世代によって変わるため、プロファイリング、デバッグ、マルチGPU、特殊なメモリ管理機能を使う場合は、最新の制限一覧を確認する必要がある。

AMD ROCm

AMDも対応するRadeonおよびRyzen製品向けに、WSL2上のROCmを提供している。ただし、対応GPU、Windowsドライバー、Ubuntu、ROCmの組み合わせは限定される。AMDはバージョンごとのWSL対応表を公開しているため、GPUの型番が掲載されているかを導入前に確認する必要がある。

ネイティブLinuxでもROCmはすべてのAMD GPUを一律にサポートするわけではない。それでも、利用できるディストリビューション、カーネル、ドライバー、管理ツールの選択肢は、一般にネイティブLinuxのほうが広い。

PyTorch

PyTorchはCPU版、CUDA版、ROCm版を提供している。公式のインストールページでは、OS、パッケージ管理方法、言語、GPUプラットフォームを選び、対応するコマンドを確認できる。

NVIDIA GPUを使った単一GPUの学習や推論であれば、WSL2でも実用的な環境を作れる。一方、GPUドライバーを細かく制御する必要がある研究、大規模なマルチGPU処理、特殊な計測機能、独自カーネルモジュールを必要とする作業では、ネイティブLinuxを選ぶほうが安全だ。

それでもネイティブLinuxが必要になる5つのケース

ここまで見てきたように、一般的な開発ではWSL2で十分なケースが多い。一方、Windowsと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開発を行う WSL2
• VS Code中心のLinux開発 WSL2
• 一般的なDocker Compose開発 WSL2
• 単一GPUでのAI学習・推論 WSL2またはネイティブLinux
• 大規模Docker・高負荷データベース検証 ネイティブLinux
• マルチGPUや高度なGPU解析 ネイティブLinux
• USB・デバイス・カーネル開発 ネイティブLinux
• 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。この基準で選べば、必要以上に環境構築へ時間を費やさずに済む。