WSL containers とは｜Docker Desktop との違いと移行判断

はじめに

Windows 上で Linux コンテナを動かす場合、これまでは Docker Desktop や Podman Desktop などのサードパーティ製ランタイムを別途導入するのが一般的でした。ただし、一定規模以上の組織では Docker Desktop の商用ライセンス費用が発生し、別途のインストールと設定も必要になるため、コストや企業としての統制のしにくさといった課題が残っていました。

2026 年 6 月 2 日の Build 2026 で、Microsoft は Linux コンテナを Windows に組み込みで作成・実行・操作できる仕組みとして WSL containers を発表しました。WSL（Windows Subsystem for Linux）に Linux コンテナの実行機能を統合し、Docker Desktop なしでコンテナを扱えるようにするものです。

結論を先に述べると、wslc は OCI 互換の Linux コンテナを Docker に近いコマンド体系で実行できる WSL 標準の仕組みです。public preview は 2026 年 6 月末に WSL の通常アップデートの一部として提供される見込みで、別途のインストーラーは不要とされています。ただし執筆時点（2026 年 6 月）では安定版の WSL リリースには未着で、Docker Compose は非対応、GUI もなく CLI 中心のため、Docker Desktop を直ちに完全置換できるわけではない点には注意が必要です。

WSL containers（wslc）とは

WSL containers は、Linux コンテナの実行を Windows 標準機能として提供する WSL の新機能です。サードパーティ製コンテナランタイムへの依存をなくし、Linux コンテナを Windows のネイティブに近い形で扱えるようにすることを目的としています。

参考: WSL container（Microsoft Learn）
“In the next WSL update, wslc.exe will be an included command”
（次回の WSL アップデートで、wslc.exe が標準コマンドとして同梱される）
https://learn.microsoft.com/en-us/windows/wsl/wsl-container

Windows 標準機能としての Linux コンテナ

wslc で動かすコンテナは OCI 互換で、Docker Hub などのレジストリからイメージを取得できます。コマンド体系は Docker に意図的に近づけられており、Docker を使い慣れていれば新しいインターフェースを覚え直す必要は小さいとされています。たとえば次のような操作です。

# コンテナを実行する
wslc run --rm -it ubuntu:latest bash

# イメージ一覧を表示する
wslc image ls

# Web サーバーをバックグラウンドで起動する
wslc run -it --rm -d -p 8080:80 --name web nginx

# 実行中のコンテナを一覧表示する
wslc container ps

（上記は公開済みのコマンド例にもとづくもので、preview 提供後に公式リファレンスで再確認のうえ追補します。出典: 4sysops https://4sysops.com/archives/wsl-container-linux-containers-built-into-windows/ ）

ローカルでコンテナ化された AI・エージェント実行環境（OpenClaw など）を Windows 上に構築する用途とも親和性が高く、こうした自律型エージェントの仕組みは関連記事『OpenClaw とは｜自律型 AI エージェントの仕組みと基本機能』で詳しく扱っています。

CLI（wslc.exe）と API・SDK の二本立て

wslc は大きく 2 つの要素で構成されます。1 つはコンテナのビルド・実行・操作を行う CLI の wslc.exe、もう 1 つは Windows アプリの開発者が自身のアプリのロジックの一部として Linux コンテナを利用できる WSL container API です。

CLI はコンテナを直接扱う開発者向け、API は Linux ワークロードを Windows アプリに組み込んで一般ユーザーに配布する用途向け、という役割分担です。API は wslcsdk.dll を通じて公開され、WinRT および C# 向けのバインディングが用意されており、IDE や CI エージェント、開発者向けプラットフォームが Docker Desktop を導入せずに Linux コンテナをプログラムから制御できます。

アーキテクチャ（Hyper-V ベースの軽量 VM と既定リソース）

wslc は、WSL が直接管理する軽量な Hyper-V ユーティリティ VM 上でコンテナを動かす仕組みです。Windows 側と VM の間は Hyper-V ソケットで通信し、wslc.exe が Windows 側の管理インターフェースとして機能します。VM 内部では containerd と dockerd を起動し、Windows 側のコンポーネントが Linux 側のランタイムを制御する構成です。

隔離のモデルにも特徴があります。Docker Desktop が単一の共有 VM 内ですべてのコンテナを実行するのに対し、wslc では API を利用する Windows アプリごとに専用の軽量 VM が割り当てられ、ストレージ・ネットワーク・リソースが分離され、Hyper-V レベルの隔離が効きます。あるコンテキストで侵害されたコンテナが、別のコンテキストのコンテナへ影響しにくい設計です。

既定の VM 構成は、仮想 CPU 2 個・メモリ 2,000 MB・32 GB の動的拡張仮想ディスクで、これらは SDK から調整できます。

参考: WSL Containers（byteiota）
“each Windows application using the API gets its own dedicated lightweight VM”
（API を利用する Windows アプリごとに、専用の軽量 VM が割り当てられる）
https://byteiota.com/wsl-containers-wslc-no-docker-desktop/

Docker / Docker Desktop との違い

wslc は Docker を置き換えうる存在として注目されていますが、両者は設計思想と提供範囲が異なります。違いを把握しておくと、移行可否の判断がしやすくなります。

コマンド体系と OCI 互換性

wslc のコマンド体系は Docker に意図的に近づけられています。wslc run や wslc image ls のように、docker を wslc に置き換える感覚で扱える操作が中心です。

参考: WSL container（4sysops）
“Its command syntax is intentionally similar to Docker”
（そのコマンド体系は、意図的に Docker と似せてある）
https://4sysops.com/archives/wsl-container-linux-containers-built-into-windows/

イメージは OCI 互換で、Docker Hub などのレジストリから取得できます。そのため、既存の Dockerfile やイメージ資産をそのまま活かしやすい設計です。

できること・できないこと（Compose・GUI・スキャン）

置き換えを検討するうえで重要なのは、現時点で「できないこと」を正確に把握することです。wslc は preview 段階であり、Docker Desktop が持つ機能のすべてをカバーするわけではありません。

wslc でできることは、docker build / docker run に相当する基本的なコンテナのビルド・実行です。AI・ML 開発者向けには、Docker の GPU サポートと同じ原理で、CDI を介してホストの GPU を公開します。

一方で、現時点での主な制約は次のとおりです。Docker Compose は提供開始時点では非対応で、compose.yml に依存するマルチコンテナのオーケストレーションが必要なワークフローでは、いま Docker Desktop を置き換える段階にはありません。また GUI はなく CLI 中心で、Hyper-V に依存するため Windows 11 が前提です。Docker Scout に相当するイメージ脆弱性スキャンのような付随機能も、wslc 単体ではカバーされません。

つまり、docker build と docker run だけが目的であれば wslc は有力な代替候補ですが、Compose・GUI・スキャンを含む統合環境を求める場合は、当面は Docker Desktop との併用が現実的です。

ライセンスと企業統制の観点

ここが本記事の核です。wslc の価値は機能の目新しさよりも、Docker Desktop の有償ライセンスとガバナンス機能を、Windows 標準の仕組みでどこまで代替できるかという点にあります。

Docker Desktop / Docker Business の有償機能との対応

まず前提として、Docker Engine 自体は Moby プロジェクトとして Apache 2.0 で公開されたオープンソースですが、GUI や付随ツールを含む Docker Desktop は、一定規模以上の組織では有償です。

参考: Docker Plans FAQs（Docker 公式）
“use in a commercial undertaking with fewer than 250 employees”
（従業員 250 名未満の商用利用に限る）
https://www.docker.com/pricing/faq/

具体的には、従業員 250 名以上、または年間売上 1,000 万ドル以上の企業は、Docker Desktop の利用に有償サブスクリプションが必要です。料金体系は Personal（無償）、Pro、Team、Business の 4 階層で、Business は 1 ユーザーあたり月額 24 ドル程度とされています（金額は確認時点のもので、変動の可能性があります。最新は Docker 公式の料金ページを参照）。

組織がこの Business 階層を選ぶ主な理由は、機能そのものより統制にあります。Docker Business は、Docker Hub ユーザーがアクセスできるコンテナイメージの制御や、レジストリへの開発者のアクセス制御、SSO（シングルサインオン）、集中的な管理機能を提供します。つまり多くの企業は、コンテナ実行そのものではなく、レジストリ制御・SSO・集中管理といったガバナンス機能のために費用を払っています。

IT 管理者向けのポリシー制御（許可レジストリ・MDM / Group Policy・監査）

wslc は、この「ガバナンスのための支払い」に対する選択肢を、Windows 標準の枠組みで提供しようとしています。

wslc には、企業向けのポリシーベースの制御が組み込まれており、IT 管理者は許可するイメージレジストリを制限でき、MDM や Group Policy で機能の有効化・無効化を切り替え、開発者マシン上で稼働中のコンテナを既存の Windows ツールで監査できます。レジストリの許可リストは、WSLContainerRegistryAllowlist というグループポリシーで、アクセス可能なレジストリを制限する形で実装されています。

これらは、ガバナンス機能のために Docker Business を契約している組織を直接の狙いとした統制ストーリーです。追加のライセンス費用なしに、レジストリ制御・有効化制御・監査といった統制を Windows 既存の管理基盤（MDM / Group Policy）で実現できる点が、wslc の実務上の大きな価値といえます。

ただし、SSO / SCIM による ID 連携や、Docker Scout のようなサプライチェーンセキュリティ機能まで含めると、Docker Business が提供する統制範囲のすべてを wslc が代替するわけではない点には留意が必要です。

提供時期と入手方法・前提環境

wslc は、執筆時点（2026 年 6 月）では開発中の機能です。

提供時期について、Microsoft 公式ブログは「今後の通常の WSL アップデートの一部として public preview で提供する」と説明しています。続報では、その時期を 2026 年 6 月末と見込む報道が複数あります。

参考: WSL Containers（Pureinfotech）
“The feature will enter public preview by the end of June”
（この機能は 6 月末までに public preview に入る）
https://pureinfotech.com/wsl-containers-windows-11-linux-containers/

入手方法はシンプルで、別途のインストーラーは不要です。WSL を最新の状態に保っておけば、通常のアップデートで wslc.exe が自動的に追加される想定です。WSL はオープンソースのため、開発の進捗は GitHub リポジトリ（microsoft/wsl）で確認できます。

前提環境は Windows 11 です。wslc は Hyper-V ベースの軽量 VM を利用するため、WSL が動作する環境（Virtual Machine Platform が有効）が前提になります。

評価・移行を検討する際のポイント

preview の段階では、いきなり本番のワークフローを移行するより、評価から始める進め方が無理がありません。今の段階でできることと、preview 着地後に確認したいことを分けて整理します。

今の段階でできることは、主に判断材料の準備です。自社の Docker Desktop の利用状況（対象の従業員規模・売上で有償ライセンスが必要か）を棚卸しし、wslc で代替できる範囲（build / run とレジストリ統制）と、代替できない範囲（Compose・GUI・Scout）を切り分けておくと、preview 着地後の評価がスムーズになります。

preview 着地後に確認したいことは、実際の挙動です。wslc コマンドの使用感、既存 Dockerfile の互換性、CI との連携、Compose 相当のワークフローをどう組むか、パフォーマンスといった点を、自社のユースケースで検証する形が現実的です。

移行判断の目安としては、docker build / docker run とレジストリ統制が主目的であれば wslc は有力な選択肢になります。一方、Compose による複数コンテナのオーケストレーションや GUI、Docker Scout のスキャンに依存している場合は、当面は Docker Desktop との併用が現実的です。

まとめ

WSL containers（wslc）は、Docker Desktop なしで Linux コンテナを動かせる WSL 標準の仕組みです。基本的なビルド・実行に加え、レジストリ制御や監査といった企業統制を Windows 既存の管理基盤で実現できる点に、実務上の価値があります。一方で Compose や GUI は現時点で対象外のため、用途に応じて Docker Desktop との併用を検討する余地が残ります。

• WSL 標準で Linux コンテナを動かす新機能 wslc
• Docker Desktop を別途導入せず WSL の通常更新に同梱
• API 利用アプリごとに専用の軽量 VM を割り当てる Hyper-V 隔離
• コマンド体系は Docker に近く既存のイメージ資産を活かしやすい。
• Compose・GUI・脆弱性スキャンは現時点で非対応または対象外
• レジストリ制御や監査は MDM / Group Policy で代替可能
• SSO・Scout まで含む統制は Docker Business の領域

以上、最後までお読みいただきありがとうございました。