Microsoftは日本時間2026年10月6日、Windows上でLinuxを動かすWindows Subsystem for Linux（WSL）の3.0.2をプレリリースとして公開した。多数のCPUを搭載した大規模な仮想マシンで起動できない問題を修正したほか、仮想ディスクの空き領域をWindows側へ返しやすくするスパースVHDを、実験的な機能として再び有効化した。9月29日にWSLコンテナが一般提供された直後の更新だが、今回の変更はコンテナ機能だけにとどまらない。多数のCPUを持つWindowsマシンでLinuxを動かす場合や、肥大化した仮想ディスクを管理する場合に、これまでの制約がどう変わるのかが重要になる。
10月6日時点では、GitHubで安定版を示す「Latest」は3.0.1のままで、3.0.2には「Pre-release」の表示が付いている。WSLコンテナが一般提供されたことと、今回の3.0.2がプレリリースであることは分けて考える必要がある。通常の更新によって、すべての利用者が直ちに3.0.2へ移行するという案内ではない。
384論理プロセッサで起動できなかった理由
起動障害のきっかけとなったのは、2ソケット構成のIntel Xeon 6 6972Pサーバーから寄せられた報告だ。Windows Server 2025でハイパースレッディングを有効にすると、OSは384個の論理プロセッサを認識する。この環境でWSL 2.9.13.0からDebian 13を起動しようとすると、仮想マシンの作成段階で「パラメーターが間違っています」というエラーが発生した。WSLへ割り当てるプロセッサ数を256に制限すると起動するが、384へ戻すと再び失敗したという。ここでいう384は物理コア数ではなく、OSから見える論理プロセッサ数である。
Microsoftの開発者Ben Hillis氏が特定した原因は、WindowsのHost Compute Service（HCS）へ渡す仮想マシン構成にあった。従来のWSLは仮想マシンのNUMA構成を指定しておらず、HCSはその場合、仮想マシン全体を単一の仮想NUMAノード／ソケットとして扱っていた。報告者のログでは、その状態で384個の論理プロセッサを割り当てようとしたため、1ソケット当たり256個という上限を超えていた。
NUMAは、CPUとメモリーの位置関係によってアクセス速度が変わる構成を指す。複数のCPUを搭載するシステムでは、CPUに近いメモリーへアクセスする方が、別のCPUに接続されたメモリーへアクセスするより高速だ。仮想NUMA（vNUMA）は、こうした構成を仮想マシン内のOSにも伝え、OSや対応アプリケーションがCPUとメモリーの配置を考慮できるようにする仕組みである。
今回の修正では、WSLが空のNUMA設定をHCSへ渡すようになった。WSL側で仮想NUMAの配置を個別に指定するのではなく、要求されたリソース量とホスト側の物理構成をもとに、HCSが適切な仮想NUMA構成を自動生成する。この処理はWindowsビルド26100以降で有効になり、通常のWSLとWSLコンテナ（WSLC）の両方に適用される。古いWindowsビルドでは従来の構成が維持される。
報告者は10月2日、修正を含む開発版でDebianが起動し、Linuxのnprocでも384が認識されたと報告している。少なくとも起動障害については、問題が発生した実機で修正効果が確認されたことになる。ただし、正式版としての3.0.2を使った再検証ではなく、処理性能を測定した結果でもない。多数のCPUを使うビルドや検証作業では、起動できることに加えて、実際の負荷をかけた際にどこまで性能が伸びるかを別途確認する必要がある。
スパースVHDは新機能ではなく、実験的な再有効化
WSLの仮想ディスクは以前から、保存するデータ量に応じてファイルサイズが大きくなる仕組みだった。LinuxのファイルシステムをWindows上のext4.vhdxに保存し、必要に応じて仮想ディスクを拡張する。そのため、今回の変更を「これまでは最大容量を最初から確保していたが、今後は使った分だけ容量を消費するようになる」と説明すると正確ではない。
スパースVHDの狙いは、仮想ディスクが一度大きくなった後、不要になった領域をWindows側でも解放しやすくすることにある。Linux側で空いた領域を、ホスト側でも物理ストレージを消費しない領域として扱うことで、Windowsから見たディスク使用量を減らせる。
Microsoftはすでに2023年9月、WSLのVHDを使用中に自動的に縮小できる実験的機能としてスパースVHDを紹介していた。今回初めて導入された機能ではない。
3.0.2に取り込まれた変更を見ると、従来のコードではデータ破損の可能性を理由に、新しいスパースVHDの作成を無効化していた。また、既存の仮想ディスクでスパースモードを有効にする際には--allow-unsafeの指定が必要だった。今回、この制限が取り除かれ、代わりに「実験的な機能であり、予期しない問題があれば報告してほしい」という警告を表示する形に変更された。従来の--allow-unsafe引数も互換性のため引き続き受け付ける。
ただし、利用制限が解除されたからといって、過去に懸念されていたデータ破損の原因が完全に解消されたと保証されたわけではない。今回の変更は、あくまで実験的な機能として再び試せるようにするものだ。どのような使い方で、どの程度の容量を回収できるのかという実測データも、今回のリリースでは示されていない。
新しく作成する通常のWSLディストリビューションでスパースVHDを使うには、Windowsのユーザーフォルダーにある.wslconfigへ次の設定を追加する。sparseVhdの既定値はfalseであり、3.0.2へ更新するだけですべての仮想ディスクが自動的に切り替わるわけではない。
[experimental]
sparseVhd=true既存のディストリビューションも、この設定だけで自動的に変換されるわけではない。対象のディストリビューションを停止したうえで、例えばUbuntuならwsl --manage Ubuntu --set-sparse trueを実行する。
.wslconfigの変更も、WSLの仮想マシンを停止して再起動するまで反映されない。wsl --shutdownを実行すると、動作中のすべてのWSLディストリビューションが停止するため、Linux上で作業しているアプリケーションを終了したうえで、まずは検証用の環境で試すのが妥当だ。
同じ3.0.2でも、通常のWSLとWSLCでは適用範囲が異なる
2026年10月6日時点の一次資料を照合すると、vNUMAの変更は通常のWSLとWSLCの両方が対象となる。一方、3.0.2で再び有効化されたスパースVHDは通常のWSLディストリビューションが対象で、WSLCのセッション保存領域や名前付きボリュームへの対応は別のPRで開発が続いている。
| 変更・対象 | 3.0.2で変わる範囲 | 適用条件・留意点 |
|---|---|---|
| 通常WSLとWSLCのvNUMA | HCSが仮想NUMA構成を自動生成 | Windowsビルド26100以降 |
| 新規WSLディストリビューションのVHD | スパースVHDとして作成可能 | sparseVhd=trueを明示。既定はオフ |
| 既存WSLディストリビューションのVHD | スパースモードへの変更時に--allow-unsafeが不要 |
対象を停止して個別に変更 |
| 固定サイズで作成するVHD | スパース設定の対象外 | 固定VHDとして作成する場合 |
| WSLCのセッション保存領域・名前付きボリューム | 別PRで対応を開発中 | 10月6日時点で未マージ。提供時期は未定 |
表はMicrosoftのvNUMAのPRとスパースVHDのPRの説明・変更内容を、公式設定表およびWSLC向けの後続PR #41742と照合し、対象と適用条件ごとに整理したものだ。速度や容量の削減量を比較した表ではない。
WSLC向けの後続PRでは、セッションの保存領域と名前付きボリュームに実験的なスパースVHDを利用できるようにし、既定のセッションで使うための設定も追加する案が進められている。同じWSLパッケージに含まれる機能でも、通常のLinuxディストリビューションと、コンテナ専用の保存領域では実装が分かれている。既存のWSLCセッションが、3.0.2へ更新するだけで自動的に縮小すると考えるのは誤りだ。
コンテナを動かすだけでなく、その状態を追跡しやすく
WSLCでは、wslc events --format jsonを使い、発生したイベントを1行につき1つのJSONオブジェクトとして出力できるようになった。タイムスタンプも含まれるため、人間向けの表形式出力を解析するより、プログラムからイベントを扱いやすい。
さらに、コンテナのヘルスチェック結果をwslc eventsへ通知する変更も加わった。コンテナの状態を確認する機能だけでなく、その変化を継続的に受け取る仕組みが整えられたことになる。
終了したコンテナについて記録されるイベントも、より細かくなった。dieイベントには終了コードが記録され、stopは別のイベントとして扱われる。停止や終了を要求したイベントはセッション側に保存されるため、コンテナが自動削除された後でも追跡できる。異常終了の原因を調べたり、終了コードに応じて後続処理を切り替えたりする際に役立つ変更だ。
ただし、Dockerに似たイベント形式を採用しているからといって、既存のDocker向けスクリプトがそのまま動くことまで保証されるわけではない。JSON出力を追加したPRでも、Dockerとの完全な互換性は保証しないと明記されている。移行する場合は、自分の処理が参照しているフィールドや、それぞれのイベントが持つ意味を確認する必要がある。
ネットワーク関連では、NAT方式のlocalhost転送で、IPv4とIPv6の両方を受け付けるデュアルスタックの待ち受けを正しく認識できず、Windows側にIPv6用の転送だけを作成していた問題が修正された。デュアルスタックの場合にはIPv4用の転送も作成するようになり、Linux内で動かしているサービスへWindows側から接続する開発環境に影響する変更だ。
ただし、これはNATのlocalhost転送に関する特定の不具合修正であり、VPNを含むWSLのネットワーク問題全般が解消されたという意味ではない。
大規模な仮想マシンでは、起動できるようになった後に多数のCPUをどこまで有効活用できるか。スパースVHDでは、実際にWindows側のストレージ使用量をどれだけ減らせるか。WSLCでは、コンテナの状態変化を監視して自動処理へつなげられるか。3.0.2を評価する際には、それぞれを実際の利用環境で確かめる必要がある。
今回の変更が安定版へ取り込まれ、さまざまな環境での検証が進めば、Windows上でLinuxを日常的に使う際のストレージ管理や障害調査にかかる手間を減らせる可能性がある。
