2026年9月30日時点で、WSL containers は、Microsoft が2026年9月29日に一般提供を始めた、Windows 上で Linux コンテナをビルド・実行・管理する機能です。PowerShell で wsl --update を実行すると、コマンドラインの wslc.exe（別名 container.exe）と、Windows アプリからコンテナを動かす API（NuGet パッケージ Microsoft.WSL.Containers）が使えるようになります。別のコンテナエンジンを入れる必要はなく、機能は WSL 2.9.3 以上に含まれます。一般提供に合わせて、コンテナの再起動やファイルのコピー、ヘルスチェック、Intune と Defender for Endpoint による管理が加わりました。Compose への対応はこれからです。
この記事の要点（2026年9月30日時点）
- 一般提供は2026年9月29日（Windows Developer Blog）。GitHub のリリース一覧では、同日に WSL 3.0.1 が正式版として公開されています。機能そのものは WSL 2.9.3 以上で使えます
- 入口は 2 つ。コマンドラインの
wslc.exeと、Windows アプリに組み込む API です。API は C# の射影と C++/WinRT のヘッダーを含み、ローカルの AI 処理や GPU へのアクセスを想定しています - 一般提供で
wslc container restart・wslc container cp・wslc system info・wslc events・ヘルスチェック・--mount・--stop-timeoutなどが加わりました - 企業向けには、Intune で機能の許可と取得元レジストリの制限ができ、Defender for Endpoint がコンテナ内のプロセス・ファイル・通信を Windows 側と関連づけて把握します
- いちばん要望の多い Compose 対応は次の版の焦点で、既存の compose.yaml をそのまま使えるようにする方針です。2026年9月30日時点では未対応です
対象読者：Windows の端末でコーディングエージェントや AI の処理をコンテナで動かしたい開発者、社内の Windows 端末でコンテナの利用を管理する情シス・プラットフォーム担当。読み終えたらできること：wslc で最初のコンテナを動かし、Docker Desktop と比べてどこまで置き換えられるかを切り分け、社内で許可する時の設定項目を挙げられます。
この記事は、Windows Developer Blog の発表（2026年9月29日）、Microsoft Learn の WSL container の概要とチュートリアル、Windows Command Line ブログの「WSLC Architecture deep dive」（同日）、GitHub の microsoft/WSL のリリース一覧を2026年9月30日に読み、書かれている範囲で整理したものです。コマンドとコードは、公式ドキュメントに載っている形のまま引用しています。国内では9月30日に gihyo.jp が報じています。
WSL containersとは｜9月29日に一般提供
WSL containers は、Windows Subsystem for Linux（WSL）に組み込まれたコンテナ機能です。発表は、Windows Platform + Developer 担当のコーポレートバイスプレジデント Logan Iyer 氏の名前で出ています。AI・クラウドネイティブ開発・コンテナ・オープンソースが Linux に集まる中で、その作業を Windows の端末で直接行える場所にする、というのが Microsoft の説明です。
| 項目 | 2026年9月30日時点 | 根拠 |
|---|---|---|
| 一般提供の開始 | 2026年9月29日（Windows Developer Blog の掲載日） | Windows Developer Blog |
| 入手 | wsl --update、または GitHub のリリースページ |
Windows Developer Blog |
| 版 | WSL 3.0.1 が2026年9月29日（UTC）に正式版として公開。機能は WSL 2.9.3 以上で利用可 | GitHub のリリース一覧・Microsoft Learn |
| 構成 | CLI の wslc.exe（別名 container.exe）と、NuGet パッケージ Microsoft.WSL.Containers の API |
Windows Developer Blog・Microsoft Learn |
| ソースコード | オープンソース（GitHub microsoft/WSL） | WSLC Architecture deep dive |
| 未対応 | Compose（次の版の焦点） | Windows Developer Blog |
公開プレビューを経ての一般提供です。Microsoft は、プレビューからの改善の重点を「日々のコンテナ作業を簡単にする」「動いている環境を見やすくする」「まとまった数のコンテナを管理する柔軟さ」の 3 つに置いたと書いています。
入手のしかた｜wsl –update と WSL 3.0.1
別のコンテナエンジンを入れる必要はありません。WSL を最新にすると wslc.exe が含まれます（GitHub のリリースページから最新版を入れることもできます）。チュートリアルの手順は次のとおりです。
wsl --update
wsl --version
wslc version
wslc run --rm hello-world1 行目で WSL を更新し、2 行目で版を確かめます（2.9.3 以上が必要です）。3 行目で wslc の版が出れば導入は済んでいて、4 行目で組み込みのイメージが自動で取得されて「Hello」が表示されます。GitHub のリリース一覧を見ると、2026年9月29日（UTC）に公開された 3.0.1 が正式版で、その前の 2.9.x はプレリリースの印が付いています。
公式ドキュメントは、Visual Studio Code と Windows Terminal の導入を任意の準備として挙げています。VS Code の WSL 拡張機能を使うと、Linux 側のファイルシステムでプロジェクトを編集しながら、統合ターミナルから wslc を実行できます。
CLI「wslc」でできること｜最初のコンテナを動かす
wslc.exe は、コンテナのビルド・配備・実行に使い慣れた CLI の書き方を目指したもの、と公式ドキュメントは説明しています。チュートリアルに載っている一連のコマンドです。
# 使い捨てのコンテナでコマンドを実行
wslc run --rm -it ubuntu:latest bash -c "echo Hello world from WSL container!"
# Web サーバーを背景で起動し、8080 番をコンテナの 80 番へ
wslc run -d --rm -p 8080:80 --name web nginx
# 動作確認
curl localhost:8080
# 動いているコンテナの一覧
wslc container list
# 動いているコンテナの中で別のコマンドを実行
wslc exec web cat /etc/os-release
# 停止（--rm 付きなので停止と同時に削除される）
wslc container stop web自分のイメージを作る流れも同じです。プロジェクトの直下に Containerfile を置き、ビルドして起動します。チュートリアルは Django のサンプルを使っています。
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
wslc run -d --rm -p 8000:8000 --name django helloworld-django
wslc container logs django
wslc exec django uname
wslc container stop djangouname の結果が Linux と出れば、コンテナが WSL 2 の Linux カーネルで動いていることの確認になります。困った時は wslc container inspect・wslc container logs・wslc image inspect で中を見て、wslc container prune と wslc image prune で使っていないものを片付けます。
公式ドキュメントは、コードは使うツールと同じファイルシステムに置くよう注意しています。Linux のツールから Windows 側のファイルを触ると遅くなるためで、WSL のディストリビューションで作業するなら、プロジェクトも WSL 側に置きます。
API「Microsoft.WSL.Containers」｜Windowsアプリからコンテナを動かす
2 つ目の入口が API です。Windows アプリの中から、イメージの取得、コンテナの起動、標準入出力の操作、ファイルのマウント、GPU へのアクセスを行えます。Microsoft は、ローカルでの AI 処理や、クラウド向けにコンテナ化したアプリを手元で動かす用途を挙げています。
導入は NuGet パッケージ 1 つです。C# の射影と C++/WinRT のヘッダーが同じパッケージに入っています。C++/WinRT の射影はプレビューで、互換性のない変更があり得る、とドキュメントに書かれています。
dotnet add package Microsoft.WSL.ContainersAPI は、コンテナを動かす流れをそのまま写した 4 つのオブジェクトからできています。
| オブジェクト | 役割 |
|---|---|
| WslcService | 入口。必要な WSL の部品が入っているかの確認、サービスの版の取得、足りない依存の導入 |
| Session | コンテナを動かす WSL の土台。イメージの管理（取得・インポート・読み込み・プッシュ・タグ・削除）とコンテナの作成 |
| Container | セッションの中に作ったコンテナ。起動・停止・検査・削除と、追加のプロセスの実行 |
| Process | コンテナ内の Linux プロセス。stdout と stderr の読み取り、stdin への書き込み、シグナル、終了コードの受け取り |
典型的な流れは、WslcService で前提を確かめ、Session を作って開始し、イメージを取得し、Container を作って起動し、Process とやり取りする、という順です。セッションには CPU 数とメモリの上限を指定できます。ドキュメントの C# の例では、次のように書いています。
var sessionSettings = new SessionSettings("MyApp", @"C:\WslcData")
{
CpuCount = 4,
MemoryMB = 4096
};
var session = new Session(sessionSettings);
session.Start();Windows のデスクトップアプリに「Linux の処理系を同梱する」ことが、利用者に別のランタイムを入れてもらわずにできる、というのがこの API の意味です。ローカル LLM の推論やデータ処理を、アプリの一部として Linux コンテナに任せられます。
一般提供で増えたコマンドと機能
Windows Developer Blog が挙げている、公開プレビュー以降の追加分です。
| 追加されたもの | 内容 |
|---|---|
wslc container restart |
動いているコンテナを再起動する |
wslc container cp |
tar アーカイブを介して、コンテナの内外でファイルをコピーする |
wslc system info |
コンテナ環境の状態を一目で確かめる |
wslc network connect / disconnect |
コンテナをネットワークに接続する・切り離す |
wslc network create |
ネットワークドライバーの任意のオプションに対応 |
wslc events |
コンテナの動きをリアルタイムに流す |
| ヘルスチェック | コンテナの健全性の確認に対応 |
--stop-timeout |
wslc create と wslc run で停止までの待ち時間を指定。-1 で無期限 |
--mount |
wslc create と wslc run でマウントを指定 |
| 保存先の設定 | 既定の wslc セッションのコンテナ用データを置くドライブを選べる |
変更の全文は GitHub のリリースページにあります。基盤の改善として、Linux 側から Windows のファイルへアクセスする速度が最大 2 倍になったこと、コンテナ向けに consomme と呼ぶ新しいネットワークモードが有効になったことも書かれています。
仕組み｜セッション・ストレージ・Consomméネットワーク
Windows Command Line ブログの「WSLC Architecture deep dive」（Pierre Boulay 氏・2026年9月29日）が、WSL との違いを説明しています。
セッションの分離。WSL と同じく、クライアントは特権を持つ Windows サービス wslservice.exe を呼び、そこが仮想マシンを作ります。違いは、wslservice.exe が仮想マシンを持ち続けないことです。代わりに、呼び出した利用者の権限で動く子プロセス wslcsession.exe を作り、コンテナの作成・ディレクトリのマウント・ポートの割り当てなどはそのプロセスが行います。セッションは別々のプロセスに分かれるので互いに隔離され、操作は特権サービスより低い権限で実行されます。
ストレージ。セッションごとに状態（イメージ・コンテナ・ネットワーク・ボリューム）を持つ VHD があり、wslc.exe から使う場合は %AppData%\Local\wslc\sessions に置かれます。Windows のパスをコンテナに見せるボリュームは virtiofs で実装され、plan9 と比べて約 2 倍速いとしています。Linux のファイルシステムが必要な時や容量に上限を付けたい時は、VHD で裏づけられたボリュームを作れます。
wslc volume create --driver vhd -o SizeBytes=200000000 my-volume
wslc container run -v my-volume:/volume -it debian:latest findmnt /volumeネットワーク。Consommé と呼ぶ新しいモデルでは、仮想マシンの通信は Ethernet フレームとして virtio のキューに送られ、利用者の権限で動く Windows プロセスがそれを読んで、DNS への応答、TCP と UDP の中継、ポートの割り当てを行います。外へ出る通信は通常の Windows プロセスが出したものと同じ扱いになるので、VPN やファイアウォールとの相性がよい、というのが設計の狙いです。
企業向けの管理｜IntuneとDefender for Endpoint
一般提供では、WSL 向けにあった Microsoft Intune と Microsoft Defender for Endpoint（MDE）の連携が、コンテナにも広がりました。
| 製品 | できること |
|---|---|
| Intune「Allow WSL containers access」 | WSL containers の機能全体の利用を許可・禁止する |
| Intune「WSL containers registry allow list」 | 組織が承認したコンテナレジストリだけからイメージを取得させる |
| Defender for Endpoint | 既存の WSL 向けプラグインを広げ、コンテナ内のプロセス・ファイル・ネットワークの動きを Windows ホストと関連づけて調査できる |
取得元のレジストリを限定できる点は、コーディングエージェントに好きなイメージを引かせたくない組織にとって、そのまま使える設定です。設定の手順は Microsoft の WSL enterprise のドキュメントにあります。
対応するツール｜VS Code・Aspire・コミュニティ
発表が挙げている連携は次のとおりです。
- VS Code の dev container：wslc を dev container の既定のドライバーにできる
- Aspire：WSL containers を第一級のコンテナランタイムとして使える
- VS Code のコンテナ拡張機能：wslc に対応
- Lazywslc：コンテナを管理する TUI
- WSL Container Desktop：コンテナ・Kubernetes（k3s）・レジストリを管理する WinUI 3 のデスクトップアプリ
- WSLc remote：WSL のディストリビューションの中から wslc を呼ぶ短いラッパー
コミュニティの貢献が多いのは、WSL とその周辺がオープンソースで進んでいるためです。ソースコードは GitHub の microsoft/WSL にあります。
AIエージェントの実行環境として見る（当社の見方）
ここからは当社の見方です。コーディングエージェントを安全に動かす基本は、エージェントが触れる範囲をコンテナで区切ることです。Windows の端末では、これまで Docker Desktop や Podman、WSL 2 の中の Docker Engine を入れる必要があり、社内の許可や有料ライセンスの確認が先に立つことがありました。WSL containers は WSL の更新だけで入り、Intune で許可と取得元を管理できるので、「社内の Windows 端末で、承認したイメージのサンドボックスだけを許す」形が作りやすくなります。
具体的には次の 3 つです。
- エージェントのサンドボックス：Claude Code や OpenClaw のような、コンテナで動かす手順が用意されているエージェントの受け皿になります。OpenClaw を Docker で動かす手順は OpenClaw のセットアップ、Claude Code がコンテナ環境で権限の確認を必須にした経緯は Claude Code の Docker 権限プロンプト にまとめています。ただし各ツールが wslc を正式に対応しているかは、2026年9月30日時点では個別に確かめる必要があります
- ローカル AI 処理の同梱：API の GPU アクセスと Session の CPU・メモリの上限を使うと、Windows アプリが Linux のコンテナで推論を動かす構成が作れます
- 隔離の強さ：セッションごとに仮想マシンと VHD が分かれ、操作は利用者の権限で動くプロセスが行います。gVisor や Firecracker のような隔離方式との比較は AIエージェントのサンドボックス設計、クラウドの実行環境との使い分けは E2B・Daytona・Modal の比較 を見てください
置き換えられないものもあります。Compose が無いので、複数コンテナを compose.yaml で立てる開発環境はまだ移せません。Docker Desktop の GUI や拡張機能に依存している場合も、対応するツール（WSL Container Desktop など）の成熟を見る必要があります。Codex のインストール手順で WSL を使う場合の注意は、uravation の Codex のインストール方法（Windows・Mac・WSL） にあります。
これから｜wslc composeと基盤の改善
Microsoft は、Linux on Windows を開発環境にとどめず、AI とクラウドネイティブの処理を Windows と同じセキュリティ・管理・統制の枠組みで動かす基盤にしていく、と書いています。今回の発表で挙げた予定は 2 つです。
- Compose 対応：いちばん多い要望で、次の版の焦点。既存の compose.yaml を変えずに
wsl compose upで動かすことを目標にしていて、着手済みとしています - 基盤の改善：ネットワークと OS をまたぐファイルアクセスの性能。wslc では Windows のファイルへのアクセスが最大 2 倍速く、consomme のネットワークモードが有効になっています
これらは WSL のディストリビューション、WSL containers、WSL の上に作られた他のコンテナ技術のすべてに効く改善だ、と説明されています。
【要注意】読み違えやすい点
読み違い1：Docker Desktop と同じことが全部できる
Compose は未対応です。コマンド体系は一般的なコンテナ CLI に似ていますが、同じではありません（一覧は wslc container list で、wslc container ps も概要ページに載っています）。
読み違い2：一般提供＝WSL 3.0 が必要
正式版として公開されたのは WSL 3.0.1 ですが、ドキュメントは機能の要件を WSL 2.9.3 以上と書いています。wsl --version で確かめてください。
読み違い3：WSL のディストリビューションの中で動くコンテナ
Ubuntu などのディストリビューションの中に Docker を入れる構成とは別です。wslc のセッションは自分の仮想マシンと VHD を持ち、ディストリビューションとは独立して動きます。
読み違い4：API は C++ からも同じように使える
C++/WinRT の射影はプレビューで、互換性のない変更があり得るとドキュメントに明記されています。本番のアプリに組み込むなら C# の射影を前提にします。
よくある質問
WSL containers は無料ですか？
WSL の一部として提供され、ソースコードはオープンソースで公開されています。追加のライセンスの記載は、2026年9月30日時点で読んだ発表とドキュメントにはありません。
Windows 10 でも使えますか？
発表とドキュメントは、対応する Windows の版を明記していません（要件として書かれているのは WSL 2.9.3 以上です）。使う前に wsl --update と wslc version で確かめてください。
Docker のイメージはそのまま使えますか？
チュートリアルは ubuntu:latest・nginx・python:3 など、一般に使われているイメージをそのまま取得して動かしています。取得元は Intune のレジストリの許可リストで制限できます。
GPU は使えますか？
API の説明に GPU へのアクセスが含まれています。CLI での使い方は、2026年9月30日時点で読んだ範囲では書かれていません。API のサンプル集を参照してください。
コンテナのデータはどこに置かれますか？
wslc.exe のセッションの状態は %AppData%\Local\wslc\sessions の VHD に置かれます。一般提供で、既定のセッションの保存先をドライブ単位で変えられるようになりました。
まとめ
WSL containers は、2026年9月29日に一般提供が始まった、WSL 組み込みの Linux コンテナ機能です。wsl --update だけで CLI の wslc と Windows アプリ向けの API が使え、セッションごとの隔離、virtiofs のボリューム、Consommé のネットワークで動きます。企業向けには Intune の許可と取得元の制限、Defender for Endpoint の監視が加わりました。Compose は次の版の焦点で、まだありません。
まず試すなら、wslc run --rm hello-world から nginx の起動までを手元で動かし、自分のエージェントの手順が wslc でそのまま動くかを確かめるところからです。社内の Windows 端末でエージェントの実行環境を決める段階で相談先が必要な場合は、Uravation でも AI エージェントの導入を支援しています。
運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）
参考・出典
- WSL containers is now generally available — Windows Developer Blog（2026年9月29日・参照日: 2026-09-30）
- WSL container — Microsoft Learn（参照日: 2026-09-30）
- Get started with WSL containers（チュートリアル） — Microsoft Learn（参照日: 2026-09-30）
- WSLC Architecture deep dive — Windows Command Line（2026年9月29日・参照日: 2026-09-30）
- microsoft/WSL Releases — GitHub（参照日: 2026-09-30）
- Microsoft、WSL containersを一般提供 ——CLIとAPIでWindowsからLinuxコンテナを操作 — gihyo.jp（報道・2026年9月30日・参照日: 2026-09-30）
