WSLがLinuxコンテナを直接動かせるようになった

Windows上でLinux向けのツールを試そうとして、まずDocker Desktopを入れかけたことはないだろうか。だが勤め先が従業員250人以上か年間売上1,000万ドル以上の企業に該当すると、Docker公式は有償サブスクリプションを案内してくる。無償で使えるのは、その基準を下回る小規模事業者か、非商用のオープンソース用途に限られる(Docker公式 Pricing FAQより)。

この悩みに、Microsoftが答えを出した。2026年9月29日、「WSL containers」という機能を一般提供(GA)にしたと発表したのだ(Windows Developer Blog)。Windows標準のwslcコマンドだけでLinuxコンテナを直接動かせる機能で、Docker Desktopを入れる必要も、WSLに普段使いのLinuxディストロを用意する必要もない。

では、これまでWSL上でDockerを動かしていた人にとって何が変わるのか。そして、これでDocker Desktopはもう要らなくなるのか。

WSL containersとは

WSL containersは、Windows標準のWSLに組み込まれたコンテナ実行機能だ。有効にする手順は難しくない。ターミナルでwsl --updateを実行して最新化するだけで、wslc(別名container.exe)コマンドが使えるようになる(Windows Developer Blog)。Insiderプログラムへの参加も、追加のソフトウェアのインストールも要らない。

GAになったのは、2026年6月29日からのパブリックプレビューを経てのことだ。GitHub公式のリリースノートでも、バージョン3.0.1(2026-09-29)の項目にこう明記されている。「WSLc is generally available」(GitHub microsoft/WSL リリースノート)。プレビュー期間中には、コンテナの再起動・ヘルスチェック・ファイルコピーといった機能が数週おきに積み上がっており、今回のGAはその集大成にあたる。

ここで気になるのは、WSL上にUbuntuなどのディストロを入れ、その中にDocker Engineを直接インストールするという、これまでよくある方法と何が違うのかだ。

間借りではなく別の部屋

これまでWindows上でLinuxコンテナを動かす一般的な方法は、WSL上にLinuxディストロを一つ用意し、その中にDocker Engineを直接インストールするというものだった。コンテナは、ディストロというWindows上の”部屋”の中にあくまで間借りする形になる。

WSL containersはこの形を取らない。

自分は最初、「WSL上でDockerを動かすのと何が違うのか」で立ち止まった。だが技術解説記事のXenoSpectrumを読んで、違いが分かった。WSL containersは、既存のWSLディストロの中へコンテナエンジンを追加する仕組みではない。「専用のセッション・ストレージ・ネットワークをWindows側が管理する」設計になっている(XenoSpectrum)。具体的には、高い権限を持つwslservice.exeがセッション全体を管理する。実際の操作は、利用者自身の権限で動く子プロセスwslcsession.exeが担当する。この2つのプロセス名の分かれ方を見て、腑に落ちた。

つまりコンテナは、ディストロに間借りするのではなく、Windowsが直接管理する自分の部屋を持つようになった。

専用の部屋をわざわざ用意してまで基盤を分けたのは、何のためだろうか。

専用の基盤で変わること

Windows側が管理を分離した理由の一つは、ネットワークにある。WSL containersは「Consommé」と呼ばれる方式を使う。Linux側の通信は、いったんvirtioキューを経由し、セッション利用者の権限で動くWindows側のプロセスが中継する。

XenoSpectrumは、この設計が「Windows側で利用しているVPNやファイアウォール、企業向けネットワーク設定などとの互換性を高めやすくなる」と説明している(XenoSpectrum)。社内VPNを常時つないだまま開発しているWindows機でも、コンテナだけ通信がすり抜けてしまうような食い違いが起きにくくなる、という設計だ。

もう一つの変化は速度だ。公式ブログは、WindowsファイルをLinux側からアクセスする際の速度が「最大2倍」になったとしている(Windows Developer Blog)。Windows側に置いた大きめのリポジトリを、コンテナの中から読み書きするような場面では、この差が作業の待ち時間に直結する。

ここまで見ると、Docker Desktopはもう要らなくなったように思える。だが、GAの発表と同時にMicrosoft自身が挙げている、残った課題が一つある。

まだ足りない機能もある

WSL containersがGAで新たに備えたコマンドは多い。公式ブログには次が挙げられている(Windows Developer Blog)。

• wslc container restart — 実行中のコンテナを再起動する
• wslc container cp — tarアーカイブ経由でファイルをコピーする
• wslc system info — コンテナ環境の状態を確認する
• wslc network connect / wslc network disconnect — ネットワークの接続を管理する
• コンテナのヘルスチェックと、イベントのリアルタイム表示

一方で、まだ実装されていない機能がある。複数のコンテナをまとめて起動する設定ファイルdocker-compose.ymlに対応するwslc composeだ。Microsoft自身が、GA後にもっとも優先して取り組む項目としてwslc composeを挙げている(Windows Developer Blog)。

docker-compose.ymlに依存する既存のプロジェクトは、コマンド名がdockerからwslcへ似ているからといって、そのまま移行できるわけではない。XenoSpectrumも、移行できるかどうかは「CLIのコマンド名が似ているかではなく、プロジェクトがどの仕組みに依存しているかで判断する必要がある」と指摘している(XenoSpectrum)。単体のコンテナをいくつか動かす用途と、Composeで組んだ複数サービスの開発環境とでは、今のところ話が別になる。

まとめ

WSL containersが一般提供になったことで、wsl --updateとwslcコマンドだけでLinuxコンテナを直接動かせるようになった。Docker Desktopのインストールも、普段使いのLinuxディストロの用意もいらない。コンテナはディストロに間借りするのではなく、Windowsが管理する専用の実行基盤を持ち、企業ネットワークとの相性やWindowsファイルへのアクセス速度でも利点がある。

ただしdocker-compose.ymlを使う既存プロジェクトは、wslc composeが実装されるまでそのままでは移行できない。単体のコンテナをいくつか試す用途なら、今日からwsl --updateを実行するだけで始められる。