Microsoftは、Windows Subsystem for Linux（WSL）上でLinuxコンテナを作成、実行、管理する「WSL コンテナー」をパブリックプレビューとして提供し始めた。対象はWSLの最新プレリリースである2.9.3で、wsl --update --pre-releaseまたはGitHubのリリースページから導入できる。
今回の発表で変わるのは、Windows上のLinuxコンテナを扱う入口だ。WSLはこれまで、Linux環境をWindowsに持ち込む開発基盤として使われてきた。WSL コンテナーでは、wslc.exeというコンテナCLIに加え、WindowsアプリがLinuxコンテナを自分の処理の一部として呼び出すAPIが入る。開発者が手元でコンテナを動かすだけでなく、Windowsアプリのビルド、検証、ローカル実行の中にLinuxコンテナを組み込めるようにする狙いだ。
wslc.exeはコンテナ操作の入口をWindows側に置く
WSL 2.9.3のリリースノートでは、WSL コンテナー（WSLC）がパブリックプレビューになったことに加え、CLIで扱える範囲がかなり具体的に示されている。コンテナの作成、実行、開始、停止、削除、エクスポート、検査に加え、CPU数、メモリ、ulimit、共有メモリサイズ、停止シグナルなどの設定を持つ。
イメージ操作も、ビルド、pull、push、import、save、inspect、一覧表示、フィルタ付きのprune、複数イメージ削除まで並ぶ。ネットワークは複数ネットワークへの接続、ネットワーク別名、container:<name|id>形式、ポート公開、ネットワークpruneを含む。ボリュームはVHDベースで扱われ、Uid、Gid、Fixedといったドライバーオプションも見える。
Microsoftの発表では、wslc runでLinuxデスクトップ環境をコンテナとして起動する例や、--gpus allでCUDA対応のPyTorchイメージからGPUを確認する例が挙げられている。container.exeもwslc.exeの組み込みエイリアスとして用意されるため、wslcとcontainerのどちらの名前でも同じ入口を使える。
コマンドの追加そのものより、MicrosoftがLinuxコンテナの操作をWindowsの管理の枠組みに近づけている点が本質だ。Docker Desktop、Podman Desktop、Rancher Desktopのような既存ツールを置き換える宣言ではない。Microsoft自身も、こうしたツールはWSLの下位レイヤー改善の恩恵を受けると説明している。WSLCは、Windows上のコンテナ体験を一つの製品に閉じるより、WSLの標準機能として土台を広げる方向にある。
APIはWindowsアプリでLinux処理を動かす
WSL コンテナーのもう一つの柱はAPIだ。Microsoft LearnのWSL containerページでは、Microsoft.WSL.Containers NuGetパッケージがC#投影とC++/WinRTヘッダーを提供し、API参照ではC、C#、C++の3系統で同じ基盤機能を公開すると説明している。
APIの構造は、WslcService、Session、Container、Processに分かれる。WslcServiceは必要なWSLコンポーネントの確認やサービスバージョン取得、依存コンポーネントのインストールに使う。Sessionはコンテナを走らせるWSL側のホストで、イメージのpull、import、load、push、tag、deleteと、コンテナ作成を担当する。Containerは開始、停止、検査、削除、追加プロセス実行を扱い、Processは標準出力や標準エラー、標準入力、シグナル、終了コードを扱う。
この構造は、Linuxコンテナを「外部の開発ツール」ではなく、Windowsアプリが扱う実行環境として見せる。公式サンプルにもその意図が出ている。Cの最小サンプルはAlpineコンテナでechoを実行する。C++/WinRTのサンプルはネイティブWindows実行ファイルからLinuxのneofetchを動かす。C#のNextcloudサンプルはコンテナ内サーバーをhttp://localhost:8080へ公開する。カスタムコンテナのサンプルでは、<WslcImage>というMSBuild項目を使い、通常のビルド時にwslc image buildとwslc image saveを走らせる。
この最後の例は実務上の含意が大きい。アプリのビルドやF5実行に合わせて、Linux側の補助ツールや検証環境をコンテナとして組み込めるため、開発者が別途Docker互換の環境を手作業で整える場面を減らせる。発表文でもMSBuildとCMakeの統合が示されており、コンテナのビルドと配置をアプリケーションのビルド処理に含められる。
企業導入ではレジストリ制御が焦点になる
MicrosoftがWSL コンテナーを企業向けに押し出している点も見逃せない。発表では、Microsoft Defender for Endpoint（MDE）のWSLプラグインがLinuxコンテナのイベントも把握する方向へ更新されると説明している。ただし、この機能は現段階ではプライベートプレビューだ。
管理面では、GPOとADMXポリシーがすでに用意されている。WSLのADMXにはWSL Containerカテゴリが追加され、AllowWSLContainerでWSL コンテナーの利用可否を制御できる。さらにWSLContainerRegistryAllowlistで、コンテナイメージをpullできるレジストリを許可リスト化できる。Intuneのダッシュボードでの正式サポートも数週間以内に追加する計画をMicrosoftは示している。
これは開発者向けの便利機能以上の意味を持つ。企業では、Linuxディストリビューションやコンテナイメージを自由に取得できることが、そのまま供給元管理やセキュリティ監査の課題になる。Microsoft Learnの企業向けWSL文書は、すでにIntune、Defender、Windowsファイアウォール、グループポリシーによるWSL管理を説明している。WSL コンテナーは、その管理対象をコンテナレジストリとLinuxコンテナ実行に広げる。
ただし、Linuxユーザー空間のパッケージ管理までWindows側が一括で扱えるわけではない。企業向けWSL文書では、Linuxディストリビューションやパッケージの更新をWindowsツールで管理すること、Windows UpdateでWSLディストリビューション内容まで更新すること、ユーザーのroot権限を制御することなどは未対応の項目として残っている。WSLCの追加は管理の範囲を広げるが、Linux環境そのものの運用責任を消すものではない。
virtiofsとConsommeが下位レイヤーを変える
WSL コンテナーに合わせて、Microsoftは下位レイヤーにも手を入れている。WSL コンテナーの既定ファイルシステムとしてvirtiofsを使い、Windowsファイルアクセスを2倍高速にするとしている。ネットワークでは、ConsommeがWSL コンテナーの新しい既定モードになる。Linux VMが使っていないメモリをWindowsホストへ段階的かつ継続的に戻すメモリ回収の改善も含まれる。
ConsommeはOpenVMMの文書ではユーザーモードNATとして説明されている。ゲストVMのネットワークを通常のホストソケット経由で提供し、ドライバーのインストールやシステム全体のネットワーク設定を必要としない。ゲストから見るとDHCPでIPアドレス、デフォルトゲートウェイ、DNSを得る普通のネットワークだが、裏側では仮想NICから来るEthernetフレームを解析し、TCP、UDP、ICMP、DNS、DHCP/ARP/NDPなどをホスト側のソケットやDNS APIへつないでいる。
この設計は、企業ネットワークで問題になりやすいVPN、プロキシ、ファイアウォールとの相性を改善する狙いがある。Consommeのトラフィックはホストのネットワークスタックを通るため、ホストに適用されるポリシーやVPN経路、プロキシ設定をLinux側にも反映しやすい。WSLの企業向け文書でも、VPNや高度なファイアウォール設定に関係する互換性改善として、mirrored networking、DNS tunneling、autoProxyが説明されている。Consommeは、WSL コンテナーでその方向をさらに進める部品として位置づけられる。
ただし、Consommeにも制限はある。OpenVMMの文書では、mDNSやSSDP/UPnP、LLMNR、NetBIOSのようなマルチキャストやブロードキャストに依存する発見プロトコルは動かないとされる。IPフラグメントの再構成も行わず、MTUは1500バイト固定で、IPv6 pingも未対応だ。コンテナ内でネットワーク機能を検証する用途では、こうした制限が結果に影響する。
2026年秋を目標とする一般提供までに固めるべき点
WSL コンテナーはパブリックプレビューであり、Microsoftは2026年秋の一般提供を目指すとしている。API参照も、プレビュー中は破壊的変更があり得るため、実現性の評価に使い、本番品質のコードは一般提供後に展開するよう明記している。
未実装項目もすでに公開されている。C APIでは、WslcSetContainerSettingsPortMappingsのUDPプロトコル指定がE_NOTIMPLを返す。WslcCreateSessionVhdVolumeとWslcSetSessionSettingsVhdの固定VHDタイプも未実装で、現時点で対応するのは動的VHDだ。C++の既知ギャップでは、HANDLEベースのimage import/loadとWinRTメタデータの差、明示的なcontainer start flagsの扱い、raw process callbackの抽象化、今回のドロップに含まれないwrapperソースファイルが列挙されている。
このパブリックプレビューは、Windows上でLinuxコンテナを扱う競争を一気に終わらせるものではない。Windowsアプリ、企業管理、GPU、ビルドシステム、既存コンテナツールがWSLの同じ下位基盤を使う範囲を広げるものだ。採用を検討するなら、wslcが既存ワークフローをどこまで置き換えられるかだけでなく、APIの安定性、レジストリ制御、ネットワーク制限、既存Docker互換ツールとの役割分担を並べて見る必要がある。
2026年秋までの焦点は、CLIの完成度よりも、Windowsアプリに組み込まれるLinuxコンテナの運用境界がどこまで明確になるかにある。プレビューの段階でAPIと管理ポリシーを同時に出したことは、MicrosoftがWSLを個人開発者向けのLinux環境から、企業が統制できるLinux実行基盤へ広げようとしていることを示している。