Microsoftは2026年9月29日、Windows Subsystem for Linux（WSL）に組み込まれたLinuxコンテナ基盤「WSL Containers（WSLC）」の一般提供を開始した。wsl --updateで導入でき、wslc.exeを使ってコンテナイメージを構築し、Linuxコンテナを実行・管理できる。WindowsアプリからLinuxコンテナを操作するためのAPIも、WSLCを利用する正式な開発手段として提供される。

ただし、「Dockerに似たコマンドがWindowsへ追加された」とだけ理解すると、この仕組みの特徴を見落とす。

Microsoftが作ったのは、利用者が普段使っているWSLディストリビューションの中へコンテナエンジンを追加する仕組みではない。WSLC専用のセッション、ストレージ、ネットワークをWindows側から管理し、企業の監視やポリシーにもつなげられるコンテナ実行基盤だ。

Docker Desktopを使わずにLinuxコンテナを扱える場面は増える一方、現時点でDocker Desktopをそのまま置き換えられるわけではない。

AD

WSLに標準のコンテナ実行環境が加わった

WSL Containersは、2026年6月29日にWSL 2.9.3のPublic Previewとして公開された。当時はwsl --update --pre-releaseでプレビュー版のWSLを導入する必要があった。

それから約3カ月後の一般提供に伴い、Microsoftは通常のwsl --updateでWSLCを利用できると案内するようになった。CLIとAPIの両方が、Windows上でLinuxコンテナを利用する正式な機能として提供される。

CLIにはwslc.exeが用意され、同じコマンドを呼び出せるcontainer.exeという別名もある。

Public Previewの時点ですでに、コンテナイメージの構築、取得、送信、コンテナの作成・実行に対応していた。ネットワークやボリュームの管理、GPU利用なども可能だった。

一般提供までに、

  • 実行中のコンテナを再起動するwslc container restart
  • コンテナとの間でファイルをコピーするwslc container cp
  • 実行環境全体の状態を確認するwslc system info
  • ネットワークへの接続・切断
  • リアルタイムのコンテナイベント表示
  • ヘルスチェック
  • --mount
  • 停止までの待ち時間を指定する--stop-timeout
  • 既定セッションの保存先変更

などが追加された。

もう一つの利用方法が、Windowsアプリ向けのWSL Containers APIだ。

C#やC++などからイメージを取得し、コンテナを作成・起動して、標準入出力、ファイル共有、ネットワーク、GPUなどを扱える。Windowsアプリの処理の一部としてLinux環境を使ったり、ビルドやテスト工程にコンテナを組み込んだりする用途を想定している。

ただし、APIのすべてが同じ成熟度に達しているわけではない。Microsoft Learnでは、C++/WinRT向けのプロジェクションについて現在もプレビューであり、互換性を壊す変更が入る可能性があると説明している。

WSLC全体が一般提供になったことと、すべての言語・開発環境向けAPIが同時に安定版になったことは分けて考える必要がある。

通常のWSLとは、仮想マシンを管理する仕組みが違う

WSLCの特徴は、仮想マシンやコンテナセッションをどのプロセスが管理するかにも表れている。

通常のWSLと同様に、クライアントからの要求は、仮想マシンを作成できる高い権限を持つWindowsサービスwslservice.exeへ送られる。

ただしWSLCでは、wslservice.exe自身がそのまま仮想マシンを管理し続けるわけではない。

代わりに、要求した利用者の権限で動作する子プロセスwslcsession.exeを起動する。このプロセスが、コンテナの作成、ディレクトリの共有、ネットワークポートの割り当てなど、各セッションの処理を担当する。

Microsoftは、セッションを別々のプロセスへ分離し、実際の操作をwslservice.exeより権限の低いプロセスで行うことで、セッション間の分離とセキュリティ境界を強化できると説明している。

ここでいう「セッション」は、1個のコンテナを意味するわけではない。

一つのWSLCセッションには複数のイメージ、コンテナ、ネットワーク、ボリュームを含めることができ、その状態はセッション専用のVHDへ保存される。

wslc.exeから作成した場合、VHDの既定の保存先は%AppData%\Local\wslc\sessionsとなる。

ストレージにも複数の方法が用意されている。

Windows上のフォルダをコンテナへ渡す場合は、virtiofsを使ってLinux仮想マシンへ共有し、その中からコンテナへbind mountする。

一方、Linux固有のファイルシステムが必要な場合や、ボリューム容量を制限したい場合には、VHDを使ったボリュームを作成できる。

Microsoftは、virtiofsによるWindowsファイルへのアクセス性能を、従来使われていたPlan 9方式と比べて最大約2倍高速としている。

ただし、公開資料では比較に使ったハードウェア、具体的な処理内容、絶対的な転送速度、測定結果のばらつきなどは示されていない。Docker Desktopとの性能比較でもないため、「WSLCがDocker Desktopの2倍速い」という意味ではない。

AD

Linuxの通信をWindows側から扱う「Consommé」

ネットワークには「Consommé」と呼ばれる新しい仕組みが使われる。

Linux仮想マシンから送られたEthernetフレームはvirtioのキューを通じてWindows側へ渡され、WSLCセッションの利用者権限で動作するWindowsプロセスが受け取る。

このプロセスが、

  • DNSへの応答
  • TCP／UDP通信の中継
  • ポートマッピング

などを担当する。

重要なのは、Linux側から外部へ出る通信が、WSLCセッションを所有する利用者のWindowsプロセスから送信された通信として扱われる点だ。

これによって、Windows側で利用しているVPNやファイアウォール、企業向けネットワーク設定などとの互換性を高めやすくなる。

つまりConsomméは、単純にコンテナ通信を高速化するための仕組みというより、LinuxコンテナのネットワークをWindowsのネットワークスタックと統合しやすくするための設計である。

一般提供後も残っている「Pre-release」表記

一般提供の発表と、Microsoftが公開しているすべての文書や配布画面の表示は、少なくとも発表翌日の9月30日時点では一致していなかった。

MicrosoftのWindows Developer BlogとWSLCのアーキテクチャ解説では、WSL Containersを9月29日から一般提供すると明記し、導入方法として通常のwsl --updateを案内している。

一方、9月30日時点のMicrosoft Learnには、WSLCに必要なWSL 2.9.3以降を「現在はプレリリースでのみ利用可能」とする記述が残り、wsl --update --pre-releaseを案内しているページもある。

GitHubで9月25日に公開されたWSL 2.9.13にも「Pre-release」の表示が残っている。

これは、WSLCの一般提供が撤回されたことを意味するものではない。Microsoft自身の9月29日の発表は明確にGAを宣言している。

製品の提供状態が切り替わった直後で、Learnの文書やGitHub上のリリース表示など、一部の情報がまだ更新されていないと考えるのが自然だ。

利用者にとって重要なのは、表記の食い違いそのものより、実際にどのバージョンが端末へ配布されているかだ。

まず、

plaintext
wsl --update
wsl --version
wslc version

を実行し、自分の環境へ導入されたWSLとWSLCのバージョンを確認するのが確実だ。

企業でWindowsやWSLの更新を段階的に配布している場合も、「一般提供になった」という発表だけで利用可能と判断せず、自社の更新リングにどのバージョンが届いているかを確認する必要がある。

AD

Docker Desktopなしで使える範囲は広がったが、完全な代替ではない

Linuxコンテナイメージを構築して実行し、ポートやボリュームを割り当てるといった基本的な用途なら、WSLCだけで完結できる場面は多い。

Microsoftは一般提供時の対応例として、

  • VS Code Dev Containers
  • Aspire
  • VS CodeのContainers拡張機能

などを挙げている。

Dockerを使った経験がある開発者を意識したCLIになっているため、基本的なコンテナ操作を覚え直す負担も小さい。

ただし、Dockerに似たコマンドを持つことと、Docker Engineそのものと互換性があることは別だ。

特に大きな違いがComposeである。

MicrosoftはWSLCの一般提供後に取り組む最優先機能としてCompose対応を挙げており、既存のcompose.yamlを変更せずにwsl compose upで実行できることを目標としている。

つまり、複数のコンテナをComposeでまとめて立ち上げる機能は、一般提供の時点ではまだ完成していない。提供時期も明らかにされていない。

Docker Engine APIとの互換性についても注意が必要だ。

MicrosoftのGitHubには、DOCKER_HOSTから接続できるDocker互換APIを求める要望が未解決のまま残っている。投稿ではDocker CLI、Compose、Testcontainers、buildxなどとの互換性が必要になる理由が挙げられている。

これは利用者からの機能要望であり、Microsoftが今後対応すると正式に約束した仕様ではない。

したがって、既存のDocker環境から移行できるかどうかは、CLIのコマンド名が似ているかではなく、プロジェクトがどの仕組みに依存しているかで判断する必要がある。

Dockerfileを使ったイメージ構築や単体コンテナの実行、WSLC対応が明記された開発ツールは比較的移行しやすい。

一方、

  • Docker Compose
  • DockerソケットやDocker Engine APIを前提とするテストツール
  • 複数アーキテクチャ向けのビルド
  • Docker Desktop固有のGUIや拡張機能

などを利用している場合は、実際のプロジェクトで互換性を確認する必要がある。

WSLCはDocker Desktopとは別の有力な選択肢になったが、既存のDocker環境をそのまま置き換えられる代替品ではない。

企業にとって重要なのはWindowsの管理・セキュリティとの統合

企業利用で重要なのは、LinuxコンテナをWindows上で起動できることだけではない。

MicrosoftはWSLCを、Windows側の管理やセキュリティの仕組みから扱えるようにする方向で機能を拡張している。

IntuneではWSL Containersそのものを有効・無効にする設定に加え、コンテナイメージを取得できるレジストリを許可リストで制限できる。

これにより、組織が承認していないレジストリから開発者が自由にイメージを取得するといった使い方を制限できる。

Microsoft Defender for Endpoint（MDE）のWSLプラグインについても、WSLC内のプロセス、ファイル、ネットワークの活動を取得し、Windowsホストとの関係を保ったままDefenderポータルで確認できる仕組みが用意されている。

ただし、9月30日時点でMDEプラグインのWSLC対応はPublic Previewとして案内されている。WSLC本体が一般提供になったからといって、関連する企業向けセキュリティ機能まで、すべて同時にGAになったわけではない。

また、可視化できることと、あらゆる攻撃を検出・防止できることも同じではない。

Microsoftの資料では、WSLプラグインからファイル、プロセス、ネットワークのイベントを確認し、アラートやインシデント、Advanced Huntingなどへ利用できる一方、WSL環境では一部のDefender機能に制約があることも説明されている。

企業が導入する場合には、

  • コンテナ内の操作が端末のタイムラインやアラートへどのように記録されるか
  • レジストリの許可リストが既存の社内レジストリやCI/CD環境を妨げないか
  • セッションごとのVHDがどれだけストレージを消費するか
  • VPN、プロキシ、ファイアウォール環境でConsomméが想定どおり動くか

などを実環境で確認する必要がある。

WSLCがWindows上でLinuxコンテナを動かす標準的な選択肢になれるかどうかは、「ファイルアクセスが最大2倍高速」という数字だけでは決まらない。

既存のcompose.yamlを変更せず使えるCompose対応が実現するか。Docker Engine APIを前提とする周辺ツールとの間をどう埋めるか。Microsoftの文書と安定版チャネルの表示が一般提供後の状態へそろうか。そして企業向けの監視・管理機能が安定版として整うか。

そこまで進めば、企業はLinuxコンテナをWindowsとは別に管理する開発環境ではなく、Windowsの更新、監視、セキュリティポリシーの中で管理できる実行環境として扱いやすくなる。