WSL containersでDocker Desktop不要に｜仕組みと使い方・ローカルLLM構築まで

Windows上でコンテナを使いたいけれど、Docker Desktopが重くてつらい、という悩みを抱えたことはないでしょうか。

起動するたびにメモリを数GBも消費し、タスクトレイに常駐し続けるDocker Desktop。開発中はバックグラウンドで大量のリソースを使われることへの不満が、長年Windows開発者のあいだで共有されてきました。

2026年6月、Microsoft Build 2026でその状況を一変させる発表がありました。Windowsにビルトインされる形でLinuxコンテナをネイティブに動かせる「WSL containers」です。wslc.exeという新しいCLIと、Windows向けのコンテナAPIが提供され、Docker Desktopなしでコンテナを管理できるようになります。

この記事では、Microsoft Build 2026での発表内容と公式情報をもとに、WSL containersの仕組みとメリット、そしてパブリックプレビュー公開後に想定される手順を先取りで整理します。なお、本記事執筆時点（2026年6月）ではパブリックプレビューが未公開のため、実機での検証は行っていません。プレビュー公開後に実際に試した結果を追記する予定です。

この記事でわかること
前提条件と想定動作環境
WSL containersとは何か：Microsoft Build 2026での発表内容
仕組みとメリット：なぜDocker Desktopが不要になるのか
手順1：WSL2を最新版にアップデートする
手順2：前提機能が有効になっているか確認する
手順3：wslc.exeが使えるか確認する
手順4：wslc.exeの基本コマンドを確認する
手順5：OllamaコンテナをWSL containers上で動かす
うまくいかない場合の確認ポイント
WSL containersとDockerの比較
よくある質問
エンジニア視点のまとめ：Build 2026発表を受けての所感
参考情報

この記事でわかること

Microsoft Build 2026で発表されたWSL containersの概要
Docker Desktopと比べたときのWSL containersの仕組みとメリット
WSL containersを有効化するために必要と想定される前提条件と手順
wslc.exeの基本コマンドの使い方（発表内容ベース）
ローカルLLM（Ollama）のコンテナをWSL containers上で動かす想定手順
注意点・うまくいかない場合の確認ポイント

前提条件と想定動作環境

項目	内容
OS	Windows 11 Pro
CPU	AMD Ryzen 9
メモリ	32GB
WSL	WSL 2（最新版）
機能	仮想マシンプラットフォーム（有効）
対象機能	WSL containers（2026年6月末パブリックプレビュー予定）

WSL containersは2026年6月4日時点でパブリックプレビュー未公開です。上記は筆者が動作確認を予定している環境であり、実際には手順を検証していません。本記事の手順はMicrosoft Build 2026での発表内容と公式情報をもとに構成した先取り解説であり、プレビュー公開後に実機検証の結果を追記する予定です。正式リリース時に仕様が変更される可能性があります。

WSL containersとは何か：Microsoft Build 2026での発表内容

WSL containersは、2026年6月2〜3日に開催されたMicrosoft Build 2026で発表された、Windows向けのコンテナ実行基盤です。

これまで、WindowsでLinuxコンテナを動かすには以下のような手段が必要でした。

Docker Desktop（Windowsアプリ）をインストールする
WSL2上にDocker Engineを直接インストールする
Podman DesktopやRancher Desktopなどのサードパーティツールを使う

WSL containersは、これらのサードパーティツールをインストールしなくても、WSLの標準機能としてコンテナを動かせるようにする取り組みです。

発表の主なポイントは次の通りです。

新しいCLIツール「wslc.exe」がWSLのアップデートとして提供される
Windows向けのコンテナAPIがNuGetパッケージとして公開される予定
OCI（Open Container Initiative）仕様に準拠したコンテナイメージが動作する
ローカルAIワークロード、テストパイプライン、Linuxベースの処理をサポートすることを明示

仕組みとメリット：なぜDocker Desktopが不要になるのか

従来のDocker Desktopの問題点

Docker Desktopは、Windows上でLinuxコンテナを動かすために独自の仮想マシン管理レイヤーを持っています。実体はWSL2またはHyper-Vで動くLinux VMの上でDockerデーモンを動かしているのですが、それに加えてDocker Desktopのデスクトップアプリ自体が常駐プロセスとして動き続けます。

多くのユーザーの報告によれば、Docker Desktopを起動した状態では1〜2GBのRAMが常時消費されます。さらに、商用利用では有料ライセンスが必要な点も、中〜大規模の組織では検討ポイントになります。

WSL containersのアーキテクチャ

WSL containersは、WSL2がもともと持っているHyper-V軽量VMの仕組みをそのまま活用します。

Windows OS
  └── Hyper-V 軽量VM（WSL2カーネル）
        └── OCI互換コンテナランタイム
              └── コンテナ（Ollama、Ubuntu等）

Docker Desktopのような中間レイヤーがなく、WSL2のLinuxカーネルとOCIランタイムが直接コンテナを管理します。wslc.exeはその管理インターフェースとして機能します。

主なメリット

Docker Desktopのライセンス費用が不要になる
常駐プロセスが削減され、メモリ消費が抑えられる
Windowsアプリからコンテナを直接制御するAPIが使える
OCI互換イメージがそのまま動くため、既存の資産が使える

企業ポリシーでDocker Desktopの商用ライセンスが制限されている現場や、リソースの限られた開発マシンにとって、特に恩恵が大きい変更です。

手順1：WSL2を最新版にアップデートする

WSL containersはWSLのアップデートとして配布されます。まず、WSL自体を最新の状態にします。

PowerShellを管理者として起動し、以下のコマンドを実行します。

wsl --update

実行後、次のような出力が表示されれば成功です。

WSL の最新バージョンをインストールしています...
インストールが完了しました。

アップデート後、WSLを再起動します。

wsl --shutdown

しばらく待ってから再度PowerShellやWindows Terminalを開くと、WSLが最新の状態で起動します。

手順2：前提機能が有効になっているか確認する

WSL containersを使うには、「仮想マシンプラットフォーム」がWindowsで有効になっている必要があります。

PowerShellを管理者として開き、以下のコマンドで状態を確認します。

Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform

State : Enabled と表示されていれば問題ありません。

無効の場合は次のコマンドで有効化し、再起動します。

Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -NoRestart
Restart-Computer

すでにWSL2を日常的に使っている方は、ほぼ確実に有効になっています。

手順3：wslc.exeが使えるか確認する

WSLのアップデートが完了すると、wslc.exe が使えるようになります。PowerShellまたはWindows Terminalで以下を実行して確認します。

wslc --version

バージョン情報が表示されれば、WSL containersが利用可能な状態です。

2026年6月末時点のパブリックプレビューでは、コマンドが認識されない場合があります。その場合は「うまくいかない場合の確認ポイント」のセクションを参照してください。

手順4：wslc.exeの基本コマンドを確認する

wslcはDockerの操作に慣れている方には親しみやすいコマンド体系になっています。

コンテナイメージの取得

wslc image pull ubuntu:26.04

コンテナの起動（対話モード）

wslc run ubuntu:26.04

コンテナ内のシェルに入ります。exit で抜けます。

起動中のコンテナ一覧

wslc container list

コンテナの停止と削除

wslc stop <コンテナID>
wslc rm <コンテナID>

ローカルイメージ一覧

wslc image list

基本的なコマンド体系はDockerと同様ですが、docker の代わりに wslc を使う形になります。

手順5：OllamaコンテナをWSL containers上で動かす

Ollamaは、ローカルでLLMを動かすためのツールです。Docker Hubに公式イメージが公開されており、WSL containersがOCI仕様に準拠していることから、同様の手順で動作することが期待されます。

Ollamaイメージを取得する

PowerShellで以下を実行します。

wslc image pull ollama/ollama:latest

ネットワーク状況にもよりますが、数分かかります。

Ollamaコンテナを起動する

wslc run -d -p 11434:11434 --name ollama ollama/ollama:latest

オプションの意味は次の通りです。

オプション	意味
`-d`	バックグラウンド（デタッチモード）で起動
`-p 11434:11434`	ホスト側のポート11434をコンテナのポート11434に転送
`--name ollama`	コンテナに「ollama」という名前をつける

コンテナが起動しているか確認する

wslc container list

ollama という名前のコンテナが表示されれば、起動しています。

モデルをダウンロードして動かす

Ollamaコンテナ内でモデルをダウンロードします。

wslc exec ollama ollama pull gemma3:4b

gemma3:4b はGoogleのGemma 3の4Bパラメータモデルです。32GBメモリのマシンであれば、余裕を持って動作することが見込まれます。

ダウンロード後、チャットを試します。

wslc exec -it ollama ollama run gemma3:4b

>>> プロンプトが表示されたら入力を受け付けている状態です。Ctrl+D または /bye で終了します。

APIで動作確認する

OllamaはREST APIも提供しています。別のPowerShellウィンドウで以下を実行して疎通確認できます。

Invoke-RestMethod -Uri "http://localhost:11434/api/tags"

インストール済みのモデル一覧がJSON形式で返ってくれば正常に動作しています。

うまくいかない場合の確認ポイント

wslc コマンドが見つからない

2026年6月末のパブリックプレビュー公開前はコマンドが存在しない場合があります。wsl --update を再実行してバージョンを確認してください。

wsl --version

最新のWSLバージョンに更新されているにもかかわらず wslc が見つからない場合は、現時点でパブリックプレビューがまだ提供されていない可能性があります。Microsoftの公式WSL GitHubリポジトリやWindowsブログで最新情報を確認してください。

コンテナが起動しない

「仮想マシンプラットフォーム」が有効になっているか確認します。また、WSL2のLinuxカーネルが正常に動作しているか、wsl -l -v で確認します。

wsl -l -v

バージョン列に「2」と表示されていれば、WSL2として動作しています。「1」の場合は次のコマンドでWSL2に変換します。

wsl --set-version <ディストリビューション名> 2

ポートに接続できない

ファイアウォールやセキュリティソフトがポート11434をブロックしている可能性があります。Windowsファイアウォールの設定を確認してください。

GPUが認識されない

WSL containers発表時点では、GPUパススルーの詳細は公式ドキュメントで順次公開される予定です。NVIDIAのGPUを使っている場合は、Windows側のNVIDIAドライバを最新版に更新し、WSL側にはLinux用のドライバをインストールしないようにします（WindowsドライバがWSL2に自動でパススルーされます）。

WSL containersとDockerの比較

項目	WSL containers	Docker Desktop
インストール	WSL更新のみ	別途インストール必要
常駐プロセス	なし（WSL2のみ）	あり（Docker Desktopデーモン）
ライセンス	無料（Windows内蔵）	商用利用は有料
GUI	なし（CLI/API）	あり
OCI互換	あり	あり
成熟度（2026年6月時点）	パブリックプレビュー	安定版

現時点ではパブリックプレビューのため、本番環境への適用は慎重に判断してください。GUI管理ツールが必要な場合は、引き続きDocker DesktopやPodman Desktopが選択肢になります。

よくある質問

WSL containers対応のWindowsバージョンはどれですか？

2026年6月末のパブリックプレビュー公開時点では、Windows 11が主なサポート対象と想定されます。具体的なビルド番号の要件は、リリースノートで公開される予定です。

Docker Composeは使えますか？

パブリックプレビュー発表時点では、docker-compose相当の機能がwslcに含まれるかどうかは明らかにされていません。当面は複数コンテナの管理には既存のdocker-compose（WSL2上のDocker Engine経由）を併用する方法が現実的です。

既存のDockerイメージはそのまま使えますか？

WSL containersはOCI仕様に準拠しているため、Docker Hubや他のレジストリに公開されているOCI互換イメージはそのまま使えます。

Docker Desktopはすぐに不要になりますか？

いいえ。WSL containersはパブリックプレビュー段階であり、Docker Desktopの全機能（GUI、Compose統合、Kubernetes、拡張機能など）を一度に置き換えるものではありません。用途によって使い分ける期間がしばらく続くと考えるのが現実的です。

エンジニア視点のまとめ：Build 2026発表を受けての所感

Ryzen 9と32GBメモリのWindows 11 Pro環境で毎日開発していると、Docker Desktopの重さは長年気になる点でした。起動時のメモリ増加や常駐プロセスの存在は、LLMを動かしたいときのリソース確保を考えると、できれば避けたいところです。

WSL containersが正式に動くようになれば、Windowsの開発者体験は大きく変わる可能性があります。WSLという既存の基盤に乗っているため、新しいVMを別途立ち上げる必要がなく、起動時のオーバーヘッドも最小限に抑えられることが期待されます。

パブリックプレビューが公開されたら、まず手元のOllamaコンテナをwslcで動かすことを試してみる予定です。Docker Desktopのデーモンを止めた状態でどれだけメモリが空くか、実際の数字で比較してみたいと思っています。

今後はdocker-compose相当の複数コンテナ管理や、Windows APIからのコンテナ制御についても検証してみたいと思っています。ローカルAIエージェントをWindowsアプリから直接コンテナとして起動する、という使い方が現実的になる日が近づいている予感がします。

プレビュー版の試用レポートは、本サイトで追加記事として公開する予定です。