閉じる

WSL 3.0が正式リリース、「WSL containers」が一般提供に—DockerなしでLinuxコンテナーを実行、「wslc compose」も開発へ

Microsoftは2026年9月29日、Windows上でLinux環境を利用するための「Windows Subsystem for Linux(WSL)」の最新版「WSL 3.0」をリリースしました。

最大の変更点は、6月末からパブリックプレビューとして提供されていた「WSL containers」が一般提供になったことです。

これにより、Dockerなどのサードパーティー製ソフトを別途導入しなくても、WSLをコンテナー実行エンジンとしてLinuxコンテナーを構築・実行できるようになります。

WSL containersとは

コンテナーは、アプリケーション本体と実行に必要なライブラリ、設定ファイルなどをひとまとめにした実行環境です。

コンテナーイメージを利用すれば、アプリごとに複雑な依存関係を整えなくても、必要な環境を再現しやすくなります。

WSL containersは、このコンテナーを動かす仕組みとしてWSLを利用し、WindowsからLinuxコンテナーを扱えるようにする機能です。

従来はDocker Desktopなどの専用ツールを導入する方法が一般的でしたが、WSL containersではWindowsに統合されたWSLをランタイムとして利用できます。

ただし、これはDockerそのものをWSLに組み込む機能ではありません。

Dockerを必要とする既存のワークフローやツールがすべて自動的に置き換わるわけではないため、利用中の開発環境や管理ツールとの互換性は事前に確認する必要があります。

利用を始める方法と提供形態

正式版のWSL containersは「WSL 3.0.1」に含まれており、WSLを最新版に更新すると利用できるようになります。

更新には、Windowsのコマンドラインからwsl --updateを実行する方法のほか、GitHubから入手する方法があります。

プレビュー版で必要だった--pre-releaseオプションは、正式版では不要です。

コンテナー機能は、コマンドラインインターフェイス(CLI)とAPIの2種類で提供されます。

提供形態主な用途
WSL containers CLIWindowsからコンテナーのビルド、実行、デプロイを行う
WSL containers APIWindowsアプリケーションからコンテナーをプログラムで操作する

コマンドラインから操作する

CLIの実行ファイルはwslc.exeで、WindowsからLinuxコンテナーの作成や実行などを直接操作できます。

コマンドになじみのある利用者が使いやすいよう、container.exeという組み込みの別名も追加されています。

コンテナーを手早く起動したい開発者だけでなく、複数のコンテナーをコマンドで管理する用途にも向いています。

Windowsアプリから操作する

APIは「Microsoft.WSL.Containers」NuGetパッケージとして提供され、C、C++、C#から利用できます。

ファイルやネットワークのマウント、GPUアクセス、標準入力・標準出力のやりとりなどを扱えるため、Windowsアプリにコンテナー操作を組み込む用途に活用できます。

CLIで人が操作する方法に加え、APIによってアプリケーションから自動化できることが、2つの提供形態を用意する利点です。

正式版で追加された主な機能

プレビュー期間中のフィードバックを受け、正式版では日常的な操作の簡略化、実行状態の把握、多数のコンテナーの管理に関する機能が拡充されました。

wslc container restartでは稼働中のコンテナーを再起動でき、wslc container cpではtarアーカイブを介してコンテナーとファイルをやりとりできます。

wslc system infoはコンテナー環境の状態を一覧で確認するコマンドです。

ネットワーク関連では、wslc network connectとwslc network disconnectを使って、コンテナーをネットワークに接続したり切り離したりできます。

wslc eventsを利用すると、コンテナーの動きをリアルタイムに確認できます。

また、wslc network createで任意のネットワークドライバーオプションを指定できるほか、コンテナーのヘルスチェックにも対応しました。

wslc createとwslc runでは、停止時の待ち時間を指定する--stop-timeoutと、ファイルシステムをマウントする--mountが利用できます。

--stop-timeoutに-1を指定すると、停止までの待ち時間を無期限に設定できます。

さらに、既定のwslcセッションでは、コンテナーの保存先をドライブ単位で指定できるようになりました。

企業での管理とセキュリティ

WSL containersは、開発者個人の利便性だけでなく、企業のIT部門が利用環境を管理しやすくする機能も備えています。

Microsoft Intuneには、WSL containersの利用を許可するかどうかを制御する「Allow WSL containers access」が追加されます。

コンテナーイメージの取得元については、「WSL containers registry allow list」で許可するレジストリを限定できます。

利用そのものとイメージの取得先を管理ポリシーで制御することで、組織の運用ルールに沿った利用環境を整えやすくなります。

Microsoft Defender for Endpoint(MDE)のWSL向けプラグインもコンテナーに対応し、コンテナー内のプロセス、ファイル、ネットワークの動きをWindowsホスト側の活動と結び付けて追跡できます。

これにより、コンテナーをWindowsとは別の環境として切り離して調査するのではなく、ホストを含めた一連の動作として確認しやすくなります。

開発ツールとの連携と今後の展開

開発ツール側でも対応が進んでおり、Visual Studio Codeの「Dev Containers」ではwslcを既定のドライバーとして指定できます。

コンテナー管理拡張機能の「Container Tools」も対応済みで、「Aspire」でもWSL containersをコンテナーランタイムとして利用できます。

コミュニティでは「Lazywslc」や「WSL Container Desktop」などの管理ツールも開発されています。

次の大きな課題として、Microsoftは要望が最も多い機能の一つであるwslc composeの実装に取り組む方針です。

Composeに相当する仕組みが整えば、複数のコンテナーで構成される開発環境をまとめて定義し、起動・管理するワークフローを構築しやすくなると期待されます。

WSL基盤の改善も進む

WSL containersの提供にあわせて、WSLの基盤を強化する技術も導入されています。

その一つが、Windows側のパスをコンテナーにマウントする際に利用される高性能ファイルシステム「virtiofs」です。

Microsoftによると、従来の「plan9」と比べて約2倍高速で、WindowsとLinuxの間でファイルを扱う際の性能上のボトルネックを緩和します。

Windows側に置いたソースコードをLinux環境から読み書きする開発では、ファイルアクセスの速度が作業効率に影響するため、改善の恩恵を受ける可能性があります。

もう一つの「consomme」は、Linux仮想マシンの通信をユーザー権限のWindowsプロセス経由で処理するネットワークモードです。

通信が通常のWindowsアプリからの通信として扱われるため、VPNやファイアウォールとの相性を改善しやすいとされています。

これらの基盤技術はWSL containersだけでなく、WSLのディストリビューションやWSL上で動作するほかのコンテナー技術にも役立つとされています。

まとめ

WSL 3.0では、WSL containersがプレビューを終えて一般提供となり、WindowsからLinuxコンテナーを扱うための選択肢が広がりました。

CLIやAPI、Intuneによる管理、Defender for Endpointとの連携により、個人の開発から企業での統制まで幅広い用途を想定した機能がそろっています。

一方で、Dockerを前提とするツールや運用をすぐに置き換えられるとは限らないため、既存環境との適合性を確認したうえで導入することが重要です。

今後のwslc composeの実装や、virtiofsなどによる基盤の改善が進めば、Windows上でLinuxコンテナーを使う開発環境はさらに扱いやすくなりそうです。

URLをコピーしました!