WSL Containers（wslc）入門｜Docker Desktop不要

WSL 2.9.3で公開プレビューになったwslc.exeを使うと、Docker Desktopをインストールせずに、Windows上でLinuxコンテナをビルド・実行できます。本記事では、hello-worldの実行、nginxのポート公開、Containerfileからのイメージビルドまでを、実際にWindows 11で動かして確かめます。

Dockerを普段使っているWindows開発者向けに、docker runからwslc runへ最短で移れるよう、実行したコマンドと出力、そしてDocker Desktopとの違いをまとめます。公開プレビューのため仕様は変わることがあります（GAは2026年秋が目標）。バージョンと出典を添えました。

この記事の要点

• WSL Containers（wslc）とは、Docker DesktopなしにWindows上でLinuxコンテナを動かせるWSLの機能です。 wslcという組み込みのCLIで操作します。
• 2026年6月末に公開プレビューとして提供が始まりました（WSL 2.9.3同梱。本記事の検証は2.9.4.0）。
• 実行にはWSL 2のLinuxカーネルを利用します。イメージはDocker Hubから取得できます。
• 有効化はwsl --update --pre-releaseの1コマンド。別エンジンのインストールはいりません。
• CLIの語彙はdockerに近く、wslc run / wslc build / wslc execなどで操作します。
• 既定のネットワークはconsomme、既定のファイルシステムはVirtIOFS。正式提供（GA）は2026年秋が目標とされています。

検証環境

本記事は次の環境で実際に動かして確認しています。wslcは公開プレビューのため更新が速く、コマンド名やオプションが変わることがあります。実行前に、お使いの環境のバージョンを必ず確認してください。

バージョンはwsl --versionで確認しています（記事で参照する2行に絞って掲載）。イメージのダイジェスト・コンテナID・IPアドレスといった値は環境やバージョンで変わるので注意してください。

wsl --version

WSL バージョン: 2.9.4.0
カーネル バージョン: 6.18.35.2-1

WSL Containers（wslc）とは

WSL Containers（wslc）とは、wslcというCLIでLinuxコンテナをビルド・実行できるWSLの機能です。Docker Desktopのような別アプリは入れず、pre-release版のWSLに同梱される形で提供されます。

WSL Containersは、次の要素から成ります。

• wslc.exe（操作用CLI）: Linuxコンテナをビルド・実行・操作するコマンドラインツール。container.exeという別名でも同じものが起動します。dockerに近い操作感を狙って作られています。
• WSL container API: WindowsアプリからLinuxコンテナをプログラムで扱うためのAPI（Microsoft.WSL.ContainersというNuGetパッケージ）。C / C# / C++ 向けに提供されます。詳しくは後半で触れます。

動かすのは標準的なLinuxコンテナで、実行にはWSL 2のLinuxカーネルを利用します。イメージはDocker Hub上のものを取得できるため、ubuntu:latestやnginxのような一般的な名前でそのまま指定できます。公開プレビューではレジストリごとに対応の差があるため、Docker Hub以外を使う場合はpull・pushの動作を個別に確かめてください。

wslcを有効化する（wsl --update --pre-release）

有効化はWSLの更新だけで済みます。公開プレビューは先行機能なので、pre-releaseチャネルへ更新して取り込みます。PowerShellで次を実行します。

# 公開プレビューを含む最新のWSLへ更新する（pre-releaseチャネル）
wsl --update --pre-release

更新後、wsl --versionが2.9.3以降になっていればwslcが同梱されています。反映のため一度wsl --shutdownし、新しいPowerShellウィンドウを開いてから先へ進むと確実です（更新前から開いていた窓はPATHが古いままのことがあります）。

バージョンを表示して確認します。

wslc version

wslc 2.9.4.0

hello-worldイメージで動作を試します。ローカルに無ければDocker Hubから自動で取得されます。

wslc run --rm hello-world

Status: Downloaded newer image for hello-world:latest
Hello from Docker!   （以降は Docker 公式イメージの定型メッセージ）

「Hello from Docker!」を含むメッセージが出れば、wslcは使える状態です。表示メッセージはDocker Hubの標準hello-worldイメージに含まれるもので、wslcがそのイメージを取得・実行できたことを示します。うまく出ない場合は、wsl --versionが2.9.3以降か、pre-releaseチャネルで更新できているか、wslcのPATHが通っているかを見直してください。

コンテナを起動する（wslc run）

まずは使い捨てのコンテナを1つ走らせ、続けてWebサーバーをバックグラウンドで動かします。公式チュートリアルの手順に沿って進めます。

# 使い捨てのコンテナでコマンドを1回だけ実行する
wslc run --rm -it ubuntu:latest bash -c "echo Hello world from WSL container!"

Hello world from WSL container!

--rmは終了時にコンテナを自動削除するオプション、-itは対話端末を割り当てるオプションで、どちらもdocker runと同じ意味です。渡したechoの文字列がそのまま返れば、Linuxコンテナの中でコマンドが動いています。

次に、nginxをバックグラウンドで起動し、Windows側のポート8080をコンテナの80番へ公開します。

# Webサーバーをバックグラウンド起動し、ポート8080を80へ公開する
wslc run -d --rm -p 8080:80 --name web nginx
wslc container list

コンテナー ID    名前   画像    状態      ポート
2f5d48ae4382   web    nginx   running   127.0.0.1:8080->80/tcp

-dはバックグラウンド実行、-p 8080:80はポート公開、--name webはコンテナ名の指定です。一覧の127.0.0.1:8080->80/tcpのとおり、公開ポートは既定でlocalhost（127.0.0.1）にバインドされ、Windowsのlocalhost経由でアクセスできます。

# PowerShell では curl は Invoke-WebRequest の別名なので curl.exe を使う
curl.exe -s localhost:8080

<title>Welcome to nginx!</title>
<h1>Welcome to nginx!</h1>

nginxの既定ページのHTMLが返れば成功です（上は要点のみ抜粋）。停止すると、--rm付きで起動していたコンテナは自動で削除されます。

wslc container stop web

自作イメージをビルドして動かす（wslc build）

もう一歩進めて、自分のアプリを1枚のイメージにビルドし、コンテナとして動かします。wslc buildはDockerfileと同じ書式のContainerfileを読みます。ここでは外部の依存がいらない、Python標準ライブラリだけの小さなWebサーバーを例にします。作業用のフォルダを作って移動し、そこに次の2ファイルを置きます。

mkdir wslc-demo; cd wslc-demo

app.py:

from http.server import HTTPServer, SimpleHTTPRequestHandler

if __name__ == "__main__":
    server = HTTPServer(("0.0.0.0", 8000), SimpleHTTPRequestHandler)
    print("serving on :8000")
    server.serve_forever()

Containerfile:

FROM python:3.13-slim
WORKDIR /app
COPY app.py .
EXPOSE 8000
# -u で標準出力のバッファリングを無効化（付けないと print が logs に出ないことがある）
CMD ["python", "-u", "app.py"]

Containerfileのあるフォルダで、名前を付けてビルドします。

wslc build -t wslc-python-demo .

[1/3] FROM docker.io/library/python:3.13-slim
[2/3] WORKDIR /app
[3/3] COPY app.py .
  | naming to docker.io/library/wslc-python-demo

ビルドしたイメージを一覧で確認します。

wslc image list

REPOSITORY         TAG      IMAGE ID       SIZE
wslc-python-demo   latest   acae6f007faa   117.91 MB

作ったイメージをコンテナとして起動し、8000番ポートを公開します。ログを見て起動を確かめます。

wslc run -d --rm -p 8000:8000 --name python-demo wslc-python-demo
wslc container logs python-demo

serving on :8000

Windowsのブラウザでhttp://localhost:8000/を開くと、コンテナの中で動くサーバーが返すファイル一覧が見えます。コンテナがLinux上で動いていることは、中でコマンドを実行して確かめられます。

wslc exec python-demo uname

Linux

unameがLinuxを返せば、コンテナはWSL 2のLinuxカーネル上で動いています。中身のディストリビューションも確認できます。python:3.13-slimはDebianベースです。

wslc exec python-demo cat /etc/os-release

PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
ID=debian

確認できたらコンテナを止めます。

wslc container stop python-demo

基本コマンド（container list / exec / logs / stats / stop）

日常操作で使うコマンドをまとめます。多くはdockerの同名操作に対応しますが、container / imageという名詞を挟む形です。

一覧系はwslc image lsやwslc container psと短く書ける場合もあります。どの表記が通るかは、wslc --helpで確認するのが確実です。停止済みコンテナや未使用イメージがたまってきたら、wslc container prune・wslc image pruneで片付けます。

wslcとDocker Desktopの違い（Compose・GUIは使える？）

Dockerを普段使用している方向けに、Docker DesktopとWSL Containers（wslc）の比較表を作成しました。PodmanやRancher Desktopなど他方式は対象外です。

コマンドの語彙はdockerに寄せてありますが、サブコマンドの形は完全には一致しません（例：docker psにあたる操作はwslc container list）。単体のコンテナをビルド・実行する用途ならwslcだけで完結します。一方、Composeで複数コンテナを束ねる開発環境をそのまま移す用途では、現時点ではDocker Desktopなど既存ツールのほうが現実的です。ComposeはWSLの公式リポジトリで対応が検討されています。

なお公式ブログは、Windows上のコンテナ環境の選択肢としてDocker Desktop / Podman Desktop / Rancher Desktop も挙げています。wslcはその選択肢を1つ増やすもの、と捉えるのが実態に近いでしょう。

ネットワークとファイルシステム（consommeとVirtIOFS）

WSL Containersは、公開プレビューでネットワークとファイルシステムの既定を新しくしています。要点だけ押さえておきます。

• consomme（既定のネットワークモード）: WSL公式ブログによると、consommeはLinux側の通信をWindows経由で中継する方式です。これにより、Linuxアプリがホスト（Windows）のネットワーク環境・セキュリティポリシー・企業向け設定をそのまま引き継げます。公開プレビュー時点ではexperimental（実験的）と位置づけられています。
• VirtIOFS（既定のファイルシステム）: WSL公式ブログは、VirtIOFSによってWindows側ファイルへのアクセスが従来より高速になると説明しています。

-p 8080:80のようなポート公開はdockerと同じ感覚で使えます。公開したポートにはWindowsのlocalhostからアクセスでき、本記事の検証でも127.0.0.1:8080->80/tcpとしてバインドされました。ネットワークの細かい挙動は公開プレビューで変わることがあるため、実運用に載せる前に、お使いの環境で通信を確かめておくとよいでしょう。

WindowsアプリからのWSL container API（概要）

CLIだけでなく、WindowsアプリからLinuxコンテナを操作するAPIも用意されています。CLIしか使わないなら読み飛ばして構いません。公式ドキュメントによると、APIはMicrosoft.WSL.ContainersというNuGetパッケージで提供され、C / C# / C++ から使えます。C#プロジェクトへの追加は次のとおりです。

dotnet add package Microsoft.WSL.Containers

APIはWslcService / Session / Container / Processといった少数のオブジェクトで構成されます。Sessionを作ってイメージを取得し、Containerを起動してProcessで標準入出力をやり取りする流れです。C++/WinRTのプロジェクション（projection）はプレビュー段階で、破壊的変更が入る可能性があると明記されています。詳細は公式のAPIリファレンスを参照してください。

公開プレビューでの注意点（仕様変動・GAは2026年秋目標）

公開プレビュー版を触るうえで踏まえておきたい点です。GAまでに変わる要素が多いので、時点とバージョンを添えて残します。

• 仕様は変わることがある: サブコマンド・オプション・既定値はGA（2026年秋目標）までに変わる可能性があります。wslc versionで自分のバージョンを、wslc --helpで使えるコマンドを確認してください。本記事の表記と食い違ったら、実行結果を優先してください。
• wslcのPATH: 公式はPATHに載る前提ですが、更新前から開いていたセッションでは反映されないことがあります。where.exe wslcが空なら、新しいウィンドウを開くか、C:\Program Files\WSLをPATHに追加してください。
• pre-releaseチャネルは先行版: wsl --update --pre-releaseで入るのは検証中の機能です。業務の主環境で常用する前に、切り分け用の環境で試すのが無難でしょう。
• consommeはexperimental: 既定ネットワークのconsommeは実験的な位置づけです。通信要件が厳しい用途では、実際の挙動を先に確かめておくとよいでしょう。
• 対応OS: 本記事はWindows 11で検証しています。公開プレビューの対応OSは、利用時点のWSLリリースノートで確認してください。

まとめ

• WSL Containers（wslc） は、wslc.exeでDocker DesktopなしにLinuxコンテナをビルド・実行・管理できるWSLの機能です。別名はcontainer.exe、実行にはWSL 2のLinuxカーネルを利用します。
• 有効化はwsl --update --pre-release →（反映のため新しいウィンドウで）→ wslc version → wslc run --rm hello-world。別エンジンのインストールはいりません。
• 基本操作はdockerに近い語彙（run / build / exec / logs / stop）ですが、一覧系はwslc container listのように名詞を挟みます。迷ったらwslc --help。
• CLIのほかに、WindowsアプリからLinuxコンテナを扱うWSL container API（NuGet・C / C# / C++）もあります。
• 公開プレビュー（WSL 2.9.3同梱、検証は2.9.4.0）で、GAは2026年秋が目標です。仕様は変わることがあるため、wslc versionと公式ドキュメントで最新を見ながら使いましょう。

参考（出典）

• WSL container | Microsoft Learn
• Get started with containers on WSL（公式チュートリアル）
• WSL container is now available for public preview（WSL公式ブログ）
• WSL container API reference
• Compose support in WSLc（microsoft/WSL Issue）