
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発表を受けての所感
- 参考情報
この記事でわかること
前提条件と想定動作環境
| 項目 | 内容 |
|---|---|
| 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コンテナを動かすには以下のような手段が必要でした。
WSL containersは、これらのサードパーティツールをインストールしなくても、WSLの標準機能としてコンテナを動かせるようにする取り組みです。
発表の主なポイントは次の通りです。
仕組みとメリット:なぜ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の商用ライセンスが制限されている現場や、リソースの限られた開発マシンにとって、特に恩恵が大きい変更です。
手順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アプリから直接コンテナとして起動する、という使い方が現実的になる日が近づいている予感がします。
プレビュー版の試用レポートは、本サイトで追加記事として公開する予定です。
