「WSL containers」を技術者向けに解説：何が新しく、どこに限界があるか¶

対象 / ポイント

対象: WindowsでLinuxコンテナ開発をしているエンジニア、企業のインフラ担当者、IT管理者。

ポイント:

WSL containersは、WSLにwslc.exeとAPIを追加する公開プレビュー機能だ
WSL2上のDocker Engineと比べると、個人・小規模チームの乗り換えメリットは薄い
価値は企業の集中管理、レジストリ統制、Defender連携、Windows向けAPIに集中する

WindowsでLinuxコンテナを扱うチームにとって、WSL containersの発表は「Docker Desktopを消せるか」という問いに直結する。ただし、技術者が置くべき比較対象はDocker Desktopだけではない。 WSL2のLinuxディストリビューション内にDocker Engine（docker-ceパッケージ）を入れれば、 Docker DesktopなしでもLinuxコンテナは動く。⁵⁶

この記事の問いは1つだ。WSL containersは、WSL2上のDocker Engineと比べて何が本当に新しいのか。結論を先に置くなら、個人の開発体験では差は小さい。本質は、Windows標準機能として企業管理とAPI統合に乗る点にある。¹²

まず全体像を1枚で示す。利用者の入口から、コンテナの実行、企業向けの管理、基盤の強化までが1つの構成に収まっている。

WSL containersの全体構成

WSL containersの全体構成。利用者・ツール層からCLI/API、WSL基盤、コンテナ実行層、Windowsホストへと処理が流れる。右側のvirtiofs・consomme・メモリ管理改善は基盤側の強化、右上のIntune／Defenderは企業向けの管理・監視にあたる。基盤強化の既定有効化はWSL containersが先行し、通常のWSLや他コンテナツールへの波及は今後の展開に含まれる。

何が新しいのか¶

新しさは、Windows側からWSL上のLinuxコンテナを直接扱う入口が標準で用意される点にある。

これまでWindows上でLinuxコンテナを扱うには、Docker DesktopやPodman Desktopのようなデスクトップツールを導入する構成が一般的だった。もう1つの実用的な経路として、WSL2ディストリビューション内にDocker Engineを直接入れる方法もある。 WSL containersは、この入口をWSLそのものに寄せる。 wslc.exeでビルド・実行・デバッグ・テストを扱い、 WindowsアプリケーションからはAPIでコンテナを呼び出せる。¹³

追加される要素は2つだ。

CLI（wslc.exe）: WSL更新後にパスへ追加されるWindows側の実行ファイル。 run、build、image list、container listなど、既存のコンテナ操作に近い感覚で使える。 container.exeエイリアスも用意される。¹³
API: Microsoft.WSL.Containers NuGetパッケージとして提供されるWindowsアプリケーション向けAPI。 C#、C++/WinRT、C/C++向けの投影があり、MSBuildやCMakeとの統合も示されている。¹²³

導入はプレリリース版への更新で始める。

# WSL containersを含むプレリリース版へ更新
wsl --update --pre-release

更新後は、PowerShellやWindows Terminalからwslcを呼び出せる。GPUアクセスの例も公式ブログに掲載されている。¹

wslc run --rm --gpus all pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime ^
  python -c "import torch; print(torch.cuda.is_available())"

この時点で重要なのは、WSLディストリビューションのシェルを明示的に開かずに済むことだ。 wslc.exeはWindows側のexeなので、Windowsアプリケーションやビルドツールから呼びやすい。

メリットの正体：誰に効き、誰には効かないか¶

WSL containersの価値は、個人開発者よりも、Windows端末を大量管理する組織に強く出る。

評価の前に、比較対象を正しく置く必要がある。 Docker Desktopのライセンス回避はよく語られるが、WSL2内にDocker Engineを直接入れれば、 Docker Desktopに依存せずLinuxコンテナを動かせる。この構成と比べる限り、「無償で使える」はWSL containers固有の価値ではない。⁵⁶

では何が残るのか。差分は3つに絞れる。

観点	既存のDocker Engine in WSL	WSL containers
導入	ディストリビューションごとにEngineを管理	WSLの更新経路で`wslc.exe`を提供
操作入口	Linuxシェル内の`docker`中心	Windows側の`wslc.exe`とAPI
組織管理	追加設計が必要	GPO/ADMX、Intune、MDEとの連携が前提
アプリケーション統合	自前でCLI/API接続を組む	Windowsアプリケーション向けAPIを提供

個人・小規模チーム：乗り換えメリットは薄い¶

すでにDocker Engine in WSLが安定している開発者にとって、WSL containersの直接的な利点は大きくない。得られるのは、ディストリビューションごとのdaemon管理を減らし、 Windows側のwslc.exeから直接呼べるという簡素化だ。

ただし、docker composeを含む既存ワークフローが固まっているなら、置き換えの実利はさらに小さくなる。少なくとも公開プレビュー時点では、公式リリースノートの主要項目にCompose互換は見当たらない。²

企業の集中管理：ここが実質的な差になる¶

Docker Engine in WSLで埋めにくいのが、組織レベルの統制だ。 Microsoftは、Intune/GPOでWSLディストリビューションやコンテナの利用可否を制御し、コンテナイメージ取得元レジストリを許可リスト化できると説明している。 MDE（Microsoft Defender for Endpoint）についても、 WSL向けプラグインがコンテナ内イベントを認識する方向でプライベートプレビューが進んでいる。¹⁴

公平に見ると、Docker側もdaemon.json配布などで部分的な統制はできる。しかし、ユーザーが管理するディストリビューション内のdaemon設定は、ユーザー自身が変更できる余地が残る。 OS層のGPO/Intuneから強制できる点が、WSL containers側の本質的な差だ。

API：ニッチだが新規の能力¶

3つ目は、プログラマブルなAPIだ。 WindowsアプリケーションがLinux固有コードを再利用したり、クラウド向けアプリケーションをローカルで動かしたり、ビルド工程にコンテナ生成を組み込んだりできる。手元の開発ツールより、Windowsアプリケーションや社内ツールを作る側に効く機能である。³

virtiofsとconsommeによる性能・ネットワーク改善も利点だ。ただし、Microsoftはこれらを将来的に通常のWSL既定へ広げる方向で説明している。つまり、現時点ではWSL containersの先行優位だが、恒久的な差別化要因としては見ない方がよい。¹

どういう仕組みか¶

wslc runは、Windows側のフロントエンドからWSL 2のLinux基盤に処理を渡す。

WSL 2は、軽量な管理VMの中でLinuxカーネルを動かす構成だ。 Microsoft Learnも、WSL 2が軽量ユーティリティVM内でLinuxカーネルを実行すると説明している。 WSL containersは、この基盤上のコンテナ実行機能をWindows側のwslc.exeとAPIから操作する形になる。⁷

流れはこうだ。wslcがコマンドを受け取る。 WSL側のセッションがイメージやコンテナを管理する。コンテナ内プロセスの標準出力や終了コードがWindows側へ戻る。アプリケーションから使う場合も、Session、Container、ProcessのようなAPIオブジェクトで同じライフサイクルを扱う。³

今回あわせて、基盤側にも3つの改善が入った。重要なのは、これらがまずWSL containersで既定有効化され、通常のWSLへは将来展開を目指す扱いになっている点だ。ファイルシステムとネットワークは壊れると影響範囲が広いため、段階的に広げていると読める。¹

virtiofs：クロスOSのファイルアクセスを速くする¶

virtiofsは、Windowsファイルへのアクセスを従来より高速化するための新しい既定ファイルシステムだ。

Microsoftは、WSL containersではvirtiofsを新しい既定ファイルシステムとして使い、 Windowsファイルアクセスを2倍高速にすると説明している。従来のWSLではWindowsとLinuxの境界をまたぐファイル操作が遅くなりやすく、 node_modulesやGitリポジトリのような小ファイルが多いワークロードで効きやすい。¹

ただし、現時点で「通常のWSLがすべてvirtiofsへ切り替わった」とは読まない方がよい。公式ブログは、ファイルシステムやネットワークの変更は重要経路に触れるため、今はWSL containersで有効化し、将来WSLの既定にする方向だと述べている。¹

consomme：ホストのネットワーク設定を継承する¶

consommeは、ホストのソケットAPIを経由してゲストVMの通信を中継するユーザーモードNATだ。

OpenVMMの説明では、Consommeは仮想NICから生のEthernetフレームを受け取り、ホスト側のTCP/UDP/ICMP/DNS処理へ変換する。すべてが通常のホストソケットを通るため、Windows側のファイアウォール、 VPNルーティング、プロキシ設定がLinuxアプリケーションにも自然に適用される。⁸

これは企業ネットワークで効く。ホストのブラウザーでは社内APIに届くのに、WSL内のツールではDNSやプロキシが合わずに失敗する、という問題を減らせる可能性がある。

メモリの返却を改善する¶

WSL containersの基盤には、未使用メモリをWindowsホストへ段階的かつ継続的に返す改善も含まれる。

WSL 2は便利な一方、VM側で確保したメモリがホストへ戻りにくいと感じる場面があった。今回の改善は、Linux VMで使われなくなったメモリをより安定して戻す方向のものだ。コンテナを短時間に何度も作って壊す開発ワークロードでは、体感に効く可能性がある。¹

現時点の限界・注意点¶

公開プレビューのWSL containersを、本番標準として扱うにはまだ早い。

第1の理由は、提供チャネルだ。 WSL containersは2026年6月30日時点ではプレリリース版WSLで使う公開プレビュー機能であり、 Microsoftは2026年秋の一般提供を目指すとしている。検証機では試せるが、標準開発環境として全社展開する段階ではない。¹²

第2の理由は、Dockerエコシステムとの互換性だ。 2.9.3のリリースノートには、コンテナライフサイクル、イメージ、ネットワーク、ボリューム、GPU、SDK、MSBuild/CMake統合などが列挙されている。一方で、Compose互換は主要項目としては示されていない。 docker composeに開発環境を寄せているチームは、置き換え前に必ず検証が必要だ。²

第3の理由は、consommeの制約だ。 Consommeはホストネットワークとの親和性を高める一方、マルチキャストやブロードキャストを前提にした探索、ICMPエラーの中継、 traceroute、GRE/ESP/SCTPのような一部プロトコルに制約がある。 mDNS、Bonjour、SSDP、UPnPに依存する開発環境では注意が要る。⁸

第4の理由は、周辺連携の成熟度だ。 VS Code Dev ContainersのWSLc対応は0.462.0-pre-releaseで、 Intuneダッシュボードの正式対応は数週間以内、 MDEのコンテナ対応はプライベートプレビューという位置づけだ。企業導入では、CLIだけでなく管理・監視・IDE連携のステータスを個別に確認する必要がある。¹

ここでの実務判断は明確だ。個人検証やPoCなら試す価値がある。既存のDocker Engine in WSLを置き換えるなら、Compose、社内レジストリ、プロキシ、 VPN、Dev Containers、セキュリティ監視の6点を先にテストする。

試し方¶

検証するなら、まずプレリリース版に切り替わる影響を理解する。

公式チュートリアルでは、WSLを更新し、wslc versionとwslc run --rm hello-worldで確認する流れが示されている。チームPCで試す前に、個人の検証機か使い捨て環境で確認した方がよい。⁹

wsl --update --pre-release
wslc version
wslc run --rm hello-world

次に、自分たちの実ワークロードを小さく切り出す。単一コンテナのWebアプリケーション、GPUが必要なMLジョブ、社内プロキシ配下のイメージ取得、Dev Containers設定の順に試すと、失敗箇所を分離しやすい。

まとめ¶

WSL containersの評価は、比較対象をどこに置くかで変わる。 Docker Desktopと比べれば、Windows標準に近い無償の選択肢に見える。しかし、技術者が本当に比較すべき相手はWSL2上のDocker Engineだ。

この土俵では、個人・小規模チームの乗り換えメリットは薄い。すでにDocker Engine in WSLが動くなら、得られるのは主にセットアップと入口の簡素化だ。

それでも重要な方向転換はある。価値は、レジストリ許可リスト、Intune/GPO、Defender連携、Windowsアプリケーション向けAPIに集中する。 WSL containersは「Dockerを置き換える新エンジン」というより、 Windowsを企業管理しやすいLinuxコンテナホストへ近づける試みとして読むべきだ。

次に見るべき分水嶺は、2026年秋の一般提供時点でCompose互換、Dev Containers、Intune、MDE、通常WSLへのvirtiofs/consomme展開がどこまで進むかである。そこまで進んで初めて、個人の開発環境にも乗り換え理由が出てくる。