WSL Containersとは何か
WSL Containers（略称WSLC）は、Windows上でLinuxコンテナをビルトインで作成・実行・管理できる新機能です。2026年6月29日にWSL 2.9.3のプレリリースへ含まれる形でパブリックプレビューが公開されました。Microsoft Build 2026で初めて披露され、正式提供（GA）は2026年秋が予定されています。コマンドラインからLinuxコンテナを操作するための新しいバイナリ wslc.exe が、その中心的な役割を担います。
ここで押さえておきたいのが、従来のWSL2との位置づけの違いです。WSL2はLinuxカーネルを備えたフルLinux環境であり、Ubuntuなどのディストリビューションをまるごと動かす仕組みでした。これに対してWSL Containersは、そのWSL2の基盤の上に構築された、コンテナに特化したビルトイン機能という位置づけになります。つまりWSL2を置き換えるものではなく、コンテナという用途に最適化した新しい入り口が加わったと捉えるのが正確です。
WSL Containersは2つのコンポーネントで構成されています。1つはLinuxコンテナのビルドや実行を担う wslc.exe のCLI、もう1つはWindowsアプリからLinuxコンテナをアプリケーションロジックの一部として利用できるWSL container APIです。APIはNuGetパッケージ Microsoft.WSL.Containers として提供され、C#とC++の両方に対応します。なおC++/WinRTのプロジェクションはプレビュー段階のため、破壊的変更が入る可能性がある点は理解しておく必要があります。
Docker Desktopとの関係と何が変わるのか
WSL Containersで多くのエンジニアが注目するのは、Docker Desktopのような別途のコンテナエンジンをインストールしなくてもLinuxコンテナが動く点です。wslc はWSLに組み込まれており、公式ドキュメントでも「別途インストールするエンジンは存在しない」と説明されています。サードパーティ製のツールを追加せずにWindowsだけでコンテナ開発を始められるのは、環境構築の手間を大きく減らします。
操作感はDockerに馴染んだ方であれば違和感が少ないはずです。コンテナの起動には wslc run、イメージのビルドには wslc build、一覧表示には wslc image list や wslc container list といったコマンドが用意されています。ビルド定義には Containerfile を使い、イメージは docker.io などのレジストリから取得できます。既存のコンテナワークフローの知識をそのまま活かせる設計です。
ここで誤解しないでほしいのは、WSL ContainersがDocker Desktopを完全に代替すると公式が宣言しているわけではない、という点です。むしろMicrosoftは、Docker DesktopやPodman Desktop、Rancher DesktopといったWSL上に構築される既存ツールも、今回の低レベルなプラットフォーム改善の恩恵を受けると明言しています。WSL Containersは既存ツールと排他的なものではなく、共存しながらWindowsのコンテナ基盤全体を底上げする位置づけと理解するのが妥当です。
virtiofsとconsommeがもたらす改善
今回のプレビューで技術的に大きいのが、WSL Containersの新しいデフォルトファイルシステムとして virtiofs が採用され、Windowsファイルへのアクセスが2倍高速になった点です。Windows側のファイルをLinuxコンテナから読み書きする場面は、ソースコードのマウントなどで日常的に発生します。この経路が速くなることは、ビルドやテストの体感速度に直結します。
背景を少し補足します。WSL2は2019年にPlan 9（9P）プロトコルによるファイル共有をHyper-Vソケット上で導入していましたが、メッセージサイズの上限などがオーバーヘッドの一因になっていました。virtiofsはVirtIOトランスポートと共有メモリを活用してシリアライズの負荷を抑える方式で、2.9.3ではデバイスごとにSWIOTLBプールを分離する改善も加わっています。ただしvirtiofsがデフォルトになるのはあくまでWSL Containersの文脈であり、通常のWSL2全体では引き続き9Pが既定でvirtiofsはオプトインです。9Pを全面的に置き換えたと一般化しないよう注意したいところです。なお2倍という数値の測定条件は公式には示されていません。
ネットワーク面では、新しいデフォルトモード consomme が導入されました。これは従来のVirtioProxyモードを改称したもので、LinuxのネットワークトラフィックをWindows経由でリレーします。その結果、LinuxコンテナがWindowsアプリと同じネットワーク環境やセキュリティポリシー、エンタープライズ統合の恩恵を受けられるようになります。加えて、Linux VMで使われなくなったメモリを段階的かつ一貫してWindowsホストへ返すメモリ回収の改善も入っており、ホスト側のリソース効率が高まっています。
パブリックプレビューを試す手順
試すための手順はシンプルです。まずWSLをプレリリース版へ更新します。既にWSLを導入済みの環境であれば、次のコマンドが入り口になります。前提となる特別な設定ファイルの編集は公式手順には登場しません。
wsl --update --pre-release
wslc version
wslc run --rm hello-worldwslc version で wslc.exe の存在とバージョンを確認し、hello-world が動けば準備完了です。あとは普段のコンテナ操作とほぼ同じ感覚で扱えます。たとえばUbuntuコンテナを対話的に起動したり、nginxをバックグラウンドで動かしてポートを公開したりできます。
wslc run --rm -it ubuntu:latest bash
wslc run -d --rm -p 8080:80 --name web nginx
wslc container list2.9.3では、コンテナ単位のリソース制約（--cpus や --memory）、イメージのbuildやpull、push、prune、VHDでバックされたボリューム、CDIに対応したGPUコンテナ、タイムスタンプ付きの wslc logs なども利用できます。ここで一点だけ補足すると、必要なWindowsのビルド番号や最小WSLバージョンといった細かな前提条件は公式の一次情報で明示されていないため、本記事では断定を避けます。実際に試す際は最新の公式ドキュメントを確認してください。
Ragateの視点とエンジニア現場での活用シーン
Ragateは2017年の創業以来、AWSとサーバーレスを軸に、AI駆動開発やクラウドネイティブ移行の伴走支援に取り組んできました。その視点からWSL Containersを見ると、Windowsを主戦場とする開発チームにとって、コンテナ開発環境を標準化しやすくなる意味は小さくありません。追加のエンジンを入れずにビルトインでコンテナを扱えることは、チーム全体で再現性のある開発環境を揃えるうえで扱いやすい選択肢になります。
特に注目したいのが、consommeによってLinuxコンテナがWindowsのネットワークやセキュリティポリシーの配下で動く点です。企業ネットワークの制約やエンタープライズ統合を前提とする現場では、開発環境がホストと同じネットワーク文脈に乗ることが運用上の安心材料になります。セキュリティを重視するエンタープライズの支援において、こうした特性は相性が良いと考えます。
また、virtiofsによるファイルアクセスの高速化は、MVP開発やCI/CDのイテレーションを短くしたい場面で効いてきます。AIを活用したバイブコーディングで素早くプロトタイプを回す開発スタイルとも噛み合い、着手から動作確認までのサイクルをさらに縮められる可能性があります。AI駆動開発の内製化を支援する立場としても、統一された開発環境をチームへ展開する土台として期待できる機能です。
もっとも現時点ではパブリックプレビューであり、GAは2026年秋の予定です。破壊的変更が入り得るAPIもあるため、本番採用は正式提供後を見据えつつ、まずは検証環境で手触りを確かめる段階と捉えるのが現実的です。Windowsのコンテナ開発がどう変わっていくのか、Ragateとしても引き続き注視していきます。
