WSL Containers（WSLC）は、Windows Subsystem for Linuxに組み込まれたLinuxコンテナの実行機能です。追加のエンジンを入れなくても、PowerShellからwslc runでコンテナを起動でき、Windowsアプリからは専用APIで同じことができます。この記事では、仕組みの全体像、wslcでの起動・ビルド・調査のコマンド、C#からの呼び出し、そしてDocker Desktopを外せる条件と残すべき場面を扱います。情報は2026年9月29日に一般提供となったWSL 3.0.1時点のものです。
まとめ：WSL Containersの要点とDocker Desktopとの使い分け
WSL Containersの中身は2つです。コマンドラインのwslc.exeと、NuGetパッケージで配布されるAPI。wsl --updateでWSLを2.9.3以上（GA版は3.0.1）に上げれば使えるようになり、別途インストールするものはありません。
操作感はDockerに近く、run・build・exec・logs・inspect・pruneといった日常のコマンドはほぼ同じ形で書けます。イメージはDocker Hubなどのレジストリから取得でき、Containerfileからのビルドにも対応しています。
ただし、Docker Desktopの置き換えとして見ると穴が2つあります。ひとつはComposeが未対応であること。もうひとつは、Docker Engine互換のAPIエンドポイントを持たないため、dockerコマンドやDocker前提のツールをDOCKER_HOST経由でつなげないことです。単発のコンテナを動かすだけの開発者や、Windowsアプリに組み込みたい開発者には即戦力。compose.yamlで複数サービスを立ち上げている現場は、当面Docker Desktopか、WSLディストリビューション内のDocker CEを残すのが妥当です。
WSL Containersの構成とWSL 2ディストリビューションとの違い
「WSLの中でDockerを動かす」従来の構成と、何が違うのかを先に押さえます。
wslc.exeのCLIとNuGet配布のAPIからなる2部構成
公式ドキュメントWSL container（Microsoft Learn）によれば、この機能はLinuxコンテナをビルド・実行・操作するCLI「wslc.exe」と、Windowsアプリの開発者がアプリのロジックの一部としてLinuxコンテナを使うためのAPIの2つで構成されています。wslc.exeはWSLに組み込みのバイナリで、別名としてcontainer.exeも同梱されています。
これまでWindowsでLinuxコンテナを使うには、Docker Desktopを入れるか、WSLのUbuntuなどにDocker Engineを自分で入れるかの二択でした。WSL Containersは、その実行基盤をOS側の標準機能として提供する位置づけです。コンテナを動かすためにディストリビューションの中でデーモンを管理する作業が要らなくなります。
ユーザー単位のセッションVMとvirtiofs・Consomméの役割
内部構造はWSLC Architecture deep diveで公開されています。特権を持つWindowsサービスwslservice.exeが要求を受け、ユーザー権限で動くwslcsession.exeがユーザーごとのセッションを管理する仕組みです。仮想マシンはWindowsのHost Compute Service（HCS）経由で作られ、セッションのディスク（VHD）はユーザープロファイル配下のAppData\Local\wslc\sessionsに置かれます。
ファイル共有はvirtiofs、ネットワークは「Consommé」と呼ばれる新方式です。ConsomméはVMの通信をWindows側のプロセスへ渡し、DNS解決やポートの対応付けをWindowsで処理します。通信がユーザーの権限でWindowsを通るため、VPNや企業のプロキシ環境と衝突しにくい設計です。WSL 2そのものの仕組み（軽量VMとLinuxカーネル）はWSL2とは｜WSL1との違い・仕組み・インストール方法で解説しています。
wsl –updateでWSL 3.0.1系へ上げてwslcを使える状態にする手順
導入作業はWSL本体の更新だけです。確認まで含めて3つのコマンドで終わります。
導入に必要なWSLの版2.9.3以上とバージョン確認のコマンド
公式のGet started with WSL containerが示す前提は、WSLのバージョン2.9.3以上です。2.9系はプレリリース版の系列で、一般提供版はmicrosoft/WSLのリリースページで2026年9月29日に公開された3.0.1になります。Microsoft Storeやwsl --updateで通常の更新を受けていれば、3.0.1系が入ります。
# PowerShellで実行する
wsl --update
wsl --version
# wslc.exe が入っているかと、その版を確認する
wslc version
# 使えるサブコマンドの一覧
wslc --helpwsl --versionの出力で「WSL バージョン」が2.9.3未満なら、wslcコマンドそのものが存在しません。社内のPCで更新が止められている場合は、まず管理者側でWSLの更新ポリシーを確認してください。WSL本体のインストールや.wslconfigによるメモリ・CPUの調整はWSLで開発環境を構築する手順｜.wslconfig調整とDocker連携にまとめています。
hello-worldイメージの実行でセッションが立ち上がるか確かめる
動作確認は公式チュートリアルと同じくhello-worldイメージで行います。ローカルに無いイメージは自動で取得されます。
# 初回はイメージの取得とセッションVMの起動が走る
wslc run --rm hello-world
# 環境の状態（GAで追加されたサブコマンド）
wslc system info「Hello」で始まるメッセージが表示されれば準備は完了です。止まる場合は、BIOSでの仮想化無効やHyper-V関連機能の無効化といった、WSL 2そのものが動かない原因を疑います。wslc system infoはGA告知で追加が明記されたコマンドのため、2.9系のプレビュー版では存在しない場合があります。
wslc runでnginxを起動しポート公開とexecを試す操作手順
ここからはDockerを触ったことがある人なら読み替えだけで進められます。
-dと-pでWebサーバーをバックグラウンド起動しWindowsから接続する
次のコマンドで、nginxをバックグラウンドで起動し、Windows側の8080番ポートをコンテナの80番につなぎます。
# 使い捨てのUbuntuコンテナでコマンドを1回実行する
wslc run --rm -it ubuntu:latest bash -c "echo Hello world from WSL container!"
# nginxをバックグラウンドで起動し、8080を80へ公開する
wslc run -d --rm -p 8080:80 --name web nginx
# Windows側から応答を確認する
curl localhost:8080オプションの意味はDockerと同じです。-dがバックグラウンド実行、--rmが停止時の自動削除、-p ホスト側:コンテナ側がポート公開。PowerShellのcurlはInvoke-WebRequestの別名になる場合があるため、生のHTTP応答を見たいときはcurl.exeと書くと確実です。
container list・exec・logsで実行中のコンテナを調べて止める
起動したコンテナの確認と後片付けです。Dockerではdocker psと書くところを、wslcではcontainerサブコマンドの下にまとめています。
# 実行中のコンテナ一覧（停止中も含めるなら --all）
wslc container list
wslc container list --all
# 実行中のコンテナで追加のコマンドを動かす
wslc exec web cat /etc/os-release
# ログと詳細を見る
wslc container logs web
wslc container inspect web
# リソース使用量を見てから停止する
wslc stats
wslc container stop web
# 停止済みコンテナと未使用イメージを消してディスクを戻す
wslc container prune
wslc image prune注意したいのはディスク容量です。イメージと停止済みコンテナはセッションのVHDに溜まります。pruneを定期的に打たないと、Cドライブの空きが静かに減っていきます。GA版では保存先を変更できるようになったため、容量が厳しい端末は別ドライブへの配置を検討してください。
Containerfileからwslc buildでDjangoアプリのイメージを作る手順
既存のイメージを動かすだけでなく、自分のアプリをイメージ化してWindows上で動かすところまで進みます。
Containerfileの書き方とwslc build -tでのタグ付け
公式チュートリアルはDjangoのサンプルアプリを題材に、プロジェクト直下へContainerfileを置く手順を示しています。中身は一般的なDockerfileと同じ命令です。
# Containerfile（プロジェクトのルートに置く）
FROM python:3
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]# イメージをビルドしてタグを付ける
wslc build -t helloworld-django .
wslc image list
# 起動してWindowsのブラウザから http://localhost:8000/ を開く
wslc run -d --rm -p 8000:8000 --name django helloworld-django
wslc exec django uname
wslc container stop djangowslc exec django unameが「Linux」を返せば、コンテナがWSL 2のLinuxカーネル上で動いていることの確認になります。ソースコードはWindows側ではなくWSLのファイルシステム側に置くのが公式の推奨です。Windowsのファイルを読む経路はvirtiofsで速くなったとはいえ、Linuxツールで大量のファイルを読む作業ではファイルシステムをまたがないほうが速く済みます。
手順書のdockerコマンドからwslcへ読み替える操作別の対応表
手元の手順書を書き換えるときの対応です。公式ドキュメントとGA告知に載っているサブコマンドに絞りました。
| やりたいこと | Docker | WSL Containers |
|---|---|---|
| コンテナを起動 | docker run |
wslc run |
| 実行中の一覧 | docker ps |
wslc container list |
| イメージ一覧 | docker images |
wslc image list |
| イメージを作る | docker build |
wslc build |
| ログを見る | docker logs |
wslc container logs |
| ファイルを複製 | docker cp |
wslc container cp |
| イベント監視 | docker events |
wslc events |
| 複数コンテナ定義 | docker compose |
未対応 |
GA版ではWindows Developer Blogの告知のとおり、container restart、tarを介したcontainer cp、ヘルスチェック、network create・connect・disconnect、events、--mount指定、--stop-timeoutが追加されました。プレビュー期間の記事で「ファイルコピーができない」と書かれていた制約は、3.0.1では解消済みです。
C#のMicrosoft.WSL.Containersでアプリからコンテナを起動する
CLIだけならDocker互換の道具が増えただけです。WSL Containersが新しいのは、Windowsアプリが自分の処理の一部としてLinuxコンテナを抱えられる点にあります。
NuGetパッケージの追加とSession・Container・Processの関係
APIはMicrosoft.WSL.ContainersというNuGetパッケージで配布され、2026年10月5日時点の最新は3.0.1です。C#の投影とC++/WinRTのヘッダーが同梱され、C++/WinRT側はプレビュー扱いで破壊的変更があり得ると明記されています。全体のリファレンスはWSL container API developer referenceにあります。
登場するオブジェクトは4つです。前提コンポーネントの確認と導入を担うWslcService、コンテナを動かすホストとなりイメージの取得や管理も行うSession、Session内に作るContainer、コンテナ内のLinuxプロセスを表し標準入出力やシグナルを扱うProcess。流れは「確認 → Session起動 → イメージ取得 → Container作成 → Process操作」の順になります。
イメージ取得から標準出力の受け取りまでをアプリに組み込むC#コード例
公式ドキュメントのサンプルを1本につなげた最小構成です。.NETのコンソールアプリでdotnet add package Microsoft.WSL.Containersを実行してから貼り付けます。
using System.Text;
using Microsoft.WSL.Containers;
// 必要なWSLコンポーネントが揃っているかを先に確認する
ComponentFlags missing = WslcService.GetMissingComponents();
if (missing != ComponentFlags.None)
{
Console.WriteLine($"WSL components are missing ({missing}). Run: wsl --install");
return;
}
// アプリ専用のセッションを、CPU 4・メモリ4GBで起動する
var session = new Session(new SessionSettings("MyApp", @"C:\WslcData")
{
CpuCount = 4,
MemoryMB = 4096
});
session.Start();
// イメージを取得する
await session.PullImageAsync(new PullImageOptions("docker.io/library/alpine:latest"));
// コンテナを作り、標準出力をイベントで受け取る
var container = session.CreateContainer(new ContainerSettings("alpine:latest")
{
Name = "hello-container",
InitProcess = new ProcessSettings
{
CmdLine = new[] { "/bin/echo", "Hello from WSL Container!" },
OutputMode = ProcessOutputMode.Event
}
});
container.InitProcess.OutputReceived += data => Console.Write(Encoding.UTF8.GetString(data));
container.Start();
// 後片付け：停止・削除・セッション終了
container.Stop(Signal.SIGTERM, TimeSpan.FromSeconds(10));
container.Delete(DeleteContainerFlags.None);
session.Terminate();ポイントはSessionSettingsの第2引数です。ここに指定したフォルダがアプリ専用のデータ置き場になり、CLIで使うセッションとは分かれます。社内ツールにLinux専用のコマンドラインツール（画像変換やPDF処理など）を組み込みたい場合、利用者にWSLのディストリビューションを用意させずに済むのが利点です。
Docker Desktopと比べたwslcの制約とCompose未対応の影響
導入判断を誤らないために、できないことを具体的に挙げます。
Compose未対応とDOCKER_HOST非対応で動かないツール
最大の制約はComposeです。GA告知では、次の重点領域としてwslc composeの追加が挙げられており、3.0.1時点では使えません。compose.yamlでWeb・DB・キャッシュを一括起動している開発環境は、そのままでは移せません。Composeの役割自体はdocker-composeとは？複数コンテナをymlで定義し一括管理する仕組みを参照してください。
もうひとつは接続口の違いです。WSL ContainersはDocker Engine互換のAPIを公開していないため、dockerコマンドやTestcontainers、VS CodeのDev ContainersのようにDOCKER_HOSTでエンジンへつなぐ道具は、wslcの環境を操作できません。互換エンドポイントを求める要望はmicrosoft/WSLのIssue #40976として2026年7月に起票され、10月5日時点でOpenのままです。
IntuneとDefender for Endpointで企業端末を管理する範囲
企業向けには、GA版でMicrosoft IntuneとMicrosoft Defender for Endpoint（MDE）の統合がコンテナにも広がりました。Intuneでは、WSL Containersそのものの利用可否と、取得を許すレジストリの許可リストを配布できます。MDEはコンテナ内のプロセス・ファイル・ネットワークの活動を可視化の対象にします。
WSL全体の企業向け設定（Hyper-Vファイアウォールの適用やミラーモードのネットワーク）はEnterprise environment: Set up Windows Subsystem for Linux for your companyに整理されています。開発者が勝手にDocker Desktopを入れる状態より、OS標準の機能をIntuneで統制するほうが、情報システム部門にとっては管理しやすい構図です。
WSL Containersを採用する条件とDocker Desktopを残す場面の判断
結論を条件付きで言い切ります。判断軸はComposeとDocker互換APIへの依存の有無です。
開発端末をwslcへ寄せてよい3つの条件とチーム単位での移行の進め方
次のいずれかに当てはまるなら、WSL Containersを第一候補にします。第一に、使うコンテナが1〜2個で、docker runの手順書で完結している場合。第二に、Windowsアプリや社内ツールにLinuxの処理を組み込みたい場合。APIで扱える点はDocker Desktopにない強みです。第三に、Docker Desktopの有償条件（従業員250人以上または年間売上1000万ドル以上）に当たり、利用者の大半がComposeを使っていない組織。費用と条件はDocker Desktopの導入手順とライセンス境界で詳しく試算しています。
移行はいきなり全員を切り替えず、手順書のコマンドを対応表で読み替えて1チームで回してから広げます。コンテナの実行基盤を端末からクラウドへ移す設計や、CI環境の分離まで含めて見直す場合はインフラ構築（AWS・Google Cloud・Azure）でご相談を受けています。
Compose前提の開発環境とCIでDocker系を残すべき理由
反対に、compose.yamlで複数サービスを起動している開発環境、Testcontainersで結合テストを回しているプロジェクト、Dev Containersで環境をそろえているチームは、現時点で移行しません。wslcへ移すと、手順書とテストの両方を書き換える必要があり、Compose対応が入った時点でもう一度やり直すことになるからです。この層はDocker Desktopを維持するか、費用を避けたいならWSLのディストリビューション内にDocker CEを入れる構成が現実的です。デーモンレスの別系統を検討するならPodmanとdockerの違い（デーモンレス・rootlessの仕組みと移行判断）も比較対象になります。
CIランナーも対象外です。WSL ContainersはWindowsの開発端末向けの機能で、LinuxのCIランナーにはそもそも関係しません。GitHub ActionsのWindowsランナーで使えるかどうかは、ランナーイメージのWSLの版に左右されるため、採用前にwslc versionが通るかを確かめてから判断してください。
よくある質問
WSL Containersについて、検索でよく出てくる疑問に答えます。
WSL Containersを使うのにDocker Desktopは必要ですか？
不要です。wslc.exeはWSLに組み込まれており、wsl --updateでWSLを2.9.3以上（一般提供版は3.0.1）にすれば、Docker Desktopを入れていない端末でもLinuxコンテナを起動できます。イメージはDocker Hubなどのレジストリから取得できます。
wslcでdocker-composeは使えますか？
WSL 3.0.1時点では使えません。Microsoftは一般提供の告知で、次に取り組む領域としてwslc composeの追加を挙げています。複数のコンテナをcompose.yamlでまとめて起動している場合は、Docker DesktopかWSL内のDocker CEを当面残してください。
dockerコマンドやVS CodeのDev ContainersからWSL Containersを操作できますか？
できません。WSL ContainersはDocker Engine互換のAPIを公開していないため、DOCKER_HOSTでエンジンに接続する道具は対象外です。互換エンドポイントを求める要望はGitHubのIssue #40976で議論中で、2026年10月5日時点で対応は決まっていません。
WSL ContainersのコンテナはUbuntuなどのディストリビューションの中で動くのですか？
いいえ。コンテナは、ユーザーごとのセッションを管理するwslcsession.exeが扱う専用の仮想マシンで動きます。セッションのディスクの作成先は、ユーザープロファイル配下のAppData\Local\wslc\sessionsです。ディストリビューションはソースコードの編集場所として併用でき、公式チュートリアルもUbuntuとVS Codeの組み合わせで説明しています。
WSL Containersの料金はかかりますか？
WSL ContainersはWSLの一部として提供される機能で、別料金の記載はありません。WSL本体はオープンソースでGitHubのmicrosoft/WSLから配布されています。有償条件があるDocker Desktopとはこの点が違い、組織規模による課金境界を気にせずに展開できます。
関連記事
- コンテナとは？仮想マシンとの違いからDocker・企業の導入判断まで解説：コンテナと仮想マシンの使い分けを判断側から整理
- containerdとは？Dockerとの関係・runc/CRIの仕組みとKubernetesでの役割を解説：コンテナランタイムの階層構造を理解する
- Kata Containersとは？軽量VMで隔離するセキュアコンテナの仕組みとgVisor・runc比較・導入判断：VMでコンテナを隔離する別方式
- Hyper-Vの有効化と仮想マシン作成手順｜PowerShell操作とWSL2との併存：WSL Containersの土台となるWindowsの仮想化
- Docker VMMとは？4.86の自前ハイパーバイザと切り替え判断：Docker Desktop側の仮想化層の選択肢
