Windows標準のコンテナ実行機能である「WSL Containers（wslc.exe）」がWSL 3.0.1（2026年9月29日公開）で正式版（GA）となり、Docker Desktopをインストールしなくてもコマンドラインから直接Linuxコンテナのビルドや実行が可能になりました。
一方で、実際に wslc を使い始めると「Dockerのあのコマンドは wslc ではどう書くのか」「.wslconfig でメモリ制限を書いたのに反映されない」「wslc compose を実行したらエラーになった」といった疑問やハマりどころに直面しがちです。
この記事は、実機検証（wslc 3.0.3.0）とMicrosoft公式ドキュメントに基づき、10秒で目的のコマンドや設定値を引けるように設計した wslc の総合コマンド一覧・逆引きチートシートです。Dockerコマンドとの対比表、専用設定ファイル settings.yaml の全パラメータ、よくあるアンチパターン、さらに用途別の詳細ガイドへのリンクまでを集約しました。手元の辞書としてブックマークしてご活用ください。
この記事でわかること
- 日常の8割をカバーする「
wslc基本10コマンド早見表（Quick Reference）」 dockerコマンドからwslcコマンドへの置き換え対応表と未対応機能（compose等）.wslconfigとの混同やセッション再起動忘れなど、初心者が必ずハマるアンチパターン（❌と⭕の対比）- コンテナ、イメージ、ネットワーク、ボリューム、セッション管理のカテゴリ別コマンド一覧
%LOCALAPPDATA%\wslc\settings.yamlの全設定キーとデフォルト値・カスタマイズ手順- VS Code Dev Containers連携やDockerfileビルド、エラー対処など用途別詳細ガイドの案内
前提条件・対象読者
- 対象OS：Windows 11（WSL 2.9.3以降が必須、正式版はWSL 3.0.1以降）
- 対応バージョン：WSL 3.0.3.0 /
wslc 3.0.3.0（最終確認：2026年11月） - 実行環境：PowerShell、Windows Terminal、またはWSL（Ubuntu等）内のシェル
- バージョン確認コマンド：
# WSL本体のバージョン確認（2.9.3以上、推奨3.0.1以上）
wsl --version
# wslc CLIのバージョン確認
wslc version
# 古い場合は最新へアップデート
wsl --update
1. wslc Quick Reference：まず覚える基本10コマンド早見表
日常のコンテナ起動、確認、ビルド、掃除で最も頻繁に使う基本10コマンドの早見表です。
| やりたいこと | 実行コマンド | 短縮形・別名（エイリアス） |
|---|---|---|
| 動作確認（使い捨て実行） | wslc run --rm hello-world | wslc container run --rm hello-world |
| 対話型シェルで起動 | wslc run --rm -it ubuntu:latest bash | -i（標準入力維持）+ -t（TTY割り当て） |
| バックグラウンドでポート公開起動 | wslc run -d -p 8080:80 --name web nginx | localhost:8080 でアクセス可能 |
| 起動中のコンテナ一覧を表示 | wslc ps | wslc list, wslc ls, wslc container list |
| 停止中を含む全コンテナを表示 | wslc ps -a | wslc container list --all |
| 実行中コンテナ内でコマンド実行 | wslc exec -it web bash | wslc container exec -it web bash |
| コンテナのログをリアルタイム追跡 | wslc logs -f web | wslc container logs --follow web |
| コンテナの停止と削除 | wslc stop web && wslc rm web | wslc remove, wslc delete |
| Dockerfileからイメージをビルド | wslc build -t myapp:v1 . | wslc image build -t myapp:v1 . |
| リソース設定ファイルを開く | wslc settings | %LOCALAPPDATA%\wslc\settings.yaml を起動 |
2. Docker → wslc コマンド置き換え対応表
wslc.exe はDocker CLIと高い互換性を持つように設計されており、ほぼすべての基本操作で先頭の docker を wslc に置き換えるだけで動作します。
コンテナ・イメージ基本操作の対比
| 操作内容 | Docker CLI | wslc CLI（標準 / 短縮形） | 互換性と注意点 |
|---|---|---|---|
| コンテナ作成・実行 | docker run [OPTIONS] IMAGE | wslc run [OPTIONS] IMAGE | ⭕ -d, -p, -v, -e, --gpus 等に対応 |
| コンテナ一覧表示 | docker ps [-a] | wslc ps [-a] / wslc list | ⭕ --format json にも対応 |
| コンテナ内コマンド実行 | docker exec -it ID CMD | wslc exec -it ID CMD | ⭕ 同じオプション体系 |
| コンテナ停止 / 起動 / 再起動 | docker stop / start / restart | wslc stop / start / restart | ⭕ WSL 3.0.1で restart も追加 |
| コンテナ削除 | docker rm [-f] ID | wslc rm [-f] ID / wslc remove | ⭕ -v で匿名ボリューム同時削除 |
| ファイルコピー | docker cp SRC DEST | wslc container cp SRC DEST | ⚠️ トップレベル wslc cp ではなく wslc container cp |
| イメージ一覧表示 | docker images / docker image ls | wslc images / wslc image list | ⭕ --digests, --format json 対応 |
| イメージ取得 / 送信 | docker pull / docker push | wslc pull / wslc push | ⭕ --all-tags 対応 |
| イメージビルド | docker build -t TAG . | wslc build -t TAG . | ⭕ --build-arg, --target, --secret 対応 |
| イメージ削除 | docker rmi IMAGE | wslc rmi IMAGE / wslc image rm | ⭕ -f（強制削除）対応 |
| リソース統計表示 | docker stats | wslc stats | ⚠️ スナップショット表示（1回出力） |
| 停止コンテナ・未使用イメージ掃除 | docker container/image prune | wslc container/image prune | ⭕ -f で確認スキップ |
| 複数コンテナ一括管理（Compose） | docker compose up -d | ❌ 未実装（wslc 3.0.3.0 時点） | ⚠️ 2026年11月時点で wslc compose は開発中 |
3. 仕組みの違いと「よくある間違い」（アンチパターン）
wslc は通常のWSLディストリビューション（Ubuntu等）とは独立した「専用のコンテナセッションVM」上でコンテナを実行します。この仕様の違いを知らないと陥りやすい4つのアンチパターンをまとめました。
アンチパターン1：メモリやCPU制限を .wslconfig に書いてしまう
最も多い間違いが、WSL2用の .wslconfig を編集して wslc のメモリ使用量を制限しようとすることです。Microsoft公式ドキュメント（WSL container settings）に明記されているとおり、.wslconfig の設定は wslc のコンテナセッションには一切適用されません。
# ❌ 間違い例：C:\Users\<ユーザー名>\.wslconfig に書いても wslc には効かない
[wsl2]
memory=4GB
processors=2
wslc のリソース制限を変更する場合は、必ず wslc settings コマンドを実行して専用の設定ファイル（%LOCALAPPDATA%\wslc\settings.yaml）を編集します。
# ⭕ 正しい手順：wslc settings で開く %LOCALAPPDATA%\wslc\settings.yaml に記述する
session:
cpuCount: 4
memorySize: 8GB
アンチパターン2：settings.yaml 変更後にセッションを再起動していない
settings.yaml の session.*（CPU数、メモリサイズ、ディスクサイズ等）は、コンテナセッションの起動時に一度だけ読み込まれます。すでにバックグラウンドでセッションが稼働している状態では、ファイルを保存しただけでは新しい設定が反映されません。
# ❌ 間違い例：settings.yaml 保存後にそのまま wslc run を実行する（旧設定のまま動く）
wslc run --rm -it ubuntu:latest free -h
変更を即座に反映させるには、wslc system session terminate で既存のセッションを明示的に終了させてから次のコマンドを実行します。
# ⭕ 正しい手順：アクティブなセッションを確認して終了させ、新設定で再起動させる
wslc system session list
wslc system session terminate
# 次の wslc コマンド実行時に新しい設定でセッションが自動起動する
wslc run --rm -it ubuntu:latest free -h
アンチパターン3：Windows側（Cドライブ）に置いたソースをLinux側からビルドする
WSL（Ubuntu等）のターミナルから作業する際、プロジェクトファイルをWindows側のファイルシステム（/mnt/c/Users/...）に置いたままビルドやボリュームマウントを行うと、OS間のファイルシステム変換オーバーヘッドによりI/O速度が大幅に低下します。
# ❌ 間違い例：WSLターミナルから /mnt/c 配下のプロジェクトをビルドする（I/Oが遅い）
cd /mnt/c/Users/username/projects/myapp
wslc build -t myapp .
WSL内のLinuxツールやVS Code（Remote – WSL）と組み合わせて開発する場合は、Linux側のホームディレクトリ（~/projects/...）にソースコードを配置して実行するのが公式推奨のベストプラクティスです。
# ⭕ 正しい手順：WSLファイルシステム（~/）上にコードを置いてビルドする
cd ~/projects/myapp
wslc build -t myapp .
アンチパターン4：docker cp と同じ感覚で wslc cp と入力する
run や build、ps、exec にはトップレベルの短縮エイリアス（wslc run 等）が用意されていますが、コンテナ内外のファイルコピーを行う cp サブコマンドにはトップレベルエイリアスが存在しません。
# ❌ 間違い例：トップレベルに cp はないためエラーになる
wslc cp ./config.json web:/etc/app/config.json
ファイルをコピーする際は、必ず container を挟んで wslc container cp と記述します。
# ⭕ 正しい手順：wslc container cp を使用する
wslc container cp ./config.json web:/etc/app/config.json
4. カテゴリ別コマンドリファレンス
wslc 3.0.3.0 で実装されている全コマンドをカテゴリ別に整理しました。すべてのコマンドでグローバルオプション --session <セッション名> を指定可能です。
1. コンテナ操作（wslc container）
# バックグラウンド（-d）でポート転送（-p）と環境変数（-e）を指定して起動
wslc run -d --name api-server -p 3000:3000 -e NODE_ENV=production node:22-alpine
# ホストのディレクトリをコンテナへバインドマウント（-v）し、終了時に自動削除（--rm）
wslc run --rm -it -v ${PWD}:/workspace -w /workspace ubuntu:26.04 bash
# CPU数（--cpus）とメモリ上限（-m）をコンテナ単位で制限して実行
wslc run -d --name worker --cpus 2 -m 1G python:3.13-slim
# GPUをすべてコンテナにパススルーして実行
wslc run --rm -it --gpus all nvidia/cuda:12.6.0-base-ubuntu24.04 nvidia-smi
# 実行中のコンテナ一覧（JSON形式で出力）
wslc list --format json
# 実行中のコンテナ内で対話型シェルを起動
wslc exec -it api-server sh
# コンテナのログを末尾50行からタイムスタンプ付きでフォロー表示
wslc logs -f -n 50 -t api-server
# コンテナとホスト間でファイルをコピー
wslc container cp api-server:/app/output.log ./output.log
# コンテナのリソース使用状況（CPU・メモリ・I/O・PID）のスナップショットを表示
wslc stats
# コンテナの停止・開始・再起動・強制終了
wslc stop api-server
wslc start api-server
wslc restart api-server
wslc kill api-server
# コンテナの削除（-f で実行中でも強制削除、-v で匿名ボリュームも削除）
wslc rm -f -v api-server
# 停止しているすべてのコンテナを一括削除（-f で確認プロンプト省略）
wslc container prune -f
2. イメージ・ビルド管理（wslc image）
# Dockerfileからイメージをビルド（キャッシュ無効化 --no-cache、ビルド引数 --build-arg）
wslc build -t myapp:1.0.0 --build-arg APP_ENV=prod --no-cache .
# 別名のDockerfile（Containerfile等）やマルチステージのターゲットを指定してビルド
wslc build -f Dockerfile.dev --target builder -t myapp:dev .
# ローカルのイメージ一覧を表示（ダイジェスト付き）
wslc images --digests
# レジストリからイメージをプル / レジストリへプッシュ
wslc pull ubuntu:26.04
wslc push myregistry.azurecr.io/myapp:1.0.0
# イメージに新しいタグを付与
wslc tag myapp:1.0.0 myregistry.azurecr.io/myapp:latest
# イメージをtarアーカイブへ保存（save） / tarアーカイブから読み込み（load）
wslc save -o myapp_image.tar myapp:1.0.0
wslc load -i myapp_image.tar
# イメージの削除（rmi）と未使用イメージの一括削除（image prune -a）
wslc rmi myapp:dev
wslc image prune -a -f
3. ネットワーク・ボリューム・レジストリ管理
# カスタムネットワークの作成・一覧・詳細確認・削除
wslc network create my-net
wslc network list
wslc network inspect my-net
wslc network connect my-net api-server
wslc network disconnect my-net api-server
wslc network remove my-net
wslc network prune -f
# 名前付きボリュームの作成・一覧・詳細確認・削除
wslc volume create db-data
wslc volume list
wslc volume inspect db-data
wslc volume remove db-data
wslc volume prune -f
# コンテナレジストリへのログイン（標準入力から安全にPATを渡す例）
$env:CR_PAT | wslc login ghcr.io -u USERNAME --password-stdin
wslc logout ghcr.io
4. システム・セッション管理（wslc system / settings）
wslc 独自のシステム情報確認や、裏側で動くコンテナセッションVMを直接操作するコマンド群です。
# システム情報（ランタイムやカーネル情報）の表示
wslc info
# コンテナイベントのリアルタイム監視
wslc events
# 稼働中のコンテナセッション一覧を表示
wslc system session list
# コンテナセッションVMのシェルに直接アタッチ（デバッグ用）
wslc system session shell
# コンテナセッションを強制終了（settings.yaml の変更反映やメモリ即時解放に使用）
wslc system session terminate
# ユーザー設定ファイル（settings.yaml）を既定エディタで開く / 既定値にリセットする
wslc settings
wslc settings reset
5. settings.yaml の全パラメータとリソース制限のベストプラクティス
wslc settings を実行すると、%LOCALAPPDATA%\wslc\settings.yaml（展開例：C:\Users\<ユーザー名>\AppData\Local\wslc\settings.yaml）が生成されて開きます。
設定パラメータ一覧（Microsoft公式仕様）
すべての項目は未指定または default を指定した場合、以下の組み込みデフォルト値が適用されます。
| 設定キー | 指定可能な値 | デフォルト値 | 役割・注意点 |
|---|---|---|---|
session.cpuCount | 正の整数 | 全論理プロセッサ | コンテナセッションVMに割り当てる仮想CPUコア数（例：4）。 |
session.memorySize | サイズ表記 | Windows総メモリの50% | セッションVMの最大メモリ量（例：8GB、4096MB）。2進数単位（1GB = 1024MB）。 |
session.maxStorageSize | サイズ表記 | 1TB | イメージやコンテナを格納する仮想ディスク（VHDX）の最大サイズ（例：250GB）。 |
session.storagePath | 絶対パス | %LOCALAPPDATA% | 仮想ディスクの保存先ベースパス。<storagePath>\wslc\sessions\<session>\storage.vhdx に作成されます。 |
session.defaultBindingAddress | IPv4アドレス | 127.0.0.1 | wslc run -p 8080:80 のようにIP省略時にバインドするホスト側アドレス。LAN内公開時は 0.0.0.0 に変更。 |
session.hostLoopback | ドメイン文字列 | host.wslc.internal | コンテナ内からWindowsホストへ通信するためのDNS名。無効化する場合は none を指定。 |
session.idleTimeout | 正の整数（秒） | 30 | コンテナがすべて停止してアイドル状態になってから、セッションVMが自動シャットダウンするまでの秒数。 |
credentialStore | wincred / file | wincred | wslc login の認証情報の保存先。wincred はWindows資格情報マネージャー、file はDPAPI暗号化JSONファイル。 |
おすすめの settings.yaml 設定例
開発用PC（メモリ16GB〜32GB）で、ホスト側のメモリ圧迫を防ぎつつCドライブ以外のSSD（Dドライブ等）にコンテナデータを逃がしたい場合の推奨設定例です。
session:
cpuCount: 4
memorySize: 8GB
maxStorageSize: 256GB
storagePath: D:\wslc-storage
defaultBindingAddress: 127.0.0.1
hostLoopback: host.wslc.internal
idleTimeout: 60
credentialStore: wincred
※注意：すでにコンテナやイメージが存在する状態で session.storagePath を変更しても、既存のデータは自動移動されません（新しいパスに空のセッションが新規作成され、旧パスの storage.vhdx はそのまま残ります）。保存先を変更する場合は、初期導入時か不要イメージを整理したタイミングで実施し、設定保存後に wslc system session terminate を実行してください。
6. 検索クエリ型FAQ（よくある質問）
Q1. wslc でコンテナ内からWindowsホスト側のDBやローカルサーバーに接続するには？
デフォルトで host.wslc.internal というホスト名が自動的に名前解決されます（Docker Desktopの host.docker.internal に相当）。コンテナ内から http://host.wslc.internal:5432 のように指定することで、Windowsホスト上で稼働しているサービスへ通信できます。
Q2. コンテナを使っていない時のメモリ消費はどうなりますか？
wslc のセッションVMにはアイドルタイムアウト機能（session.idleTimeout、デフォルト30秒）が備わっています。実行中のコンテナが0個になり30秒が経過すると、セッションVM自体が自動的にシャットダウンされ、メモリがWindowsホストへ解放されます。今すぐ手動で解放したい場合は wslc system session terminate を実行してください。
Q3. wslc compose（Docker Compose）はいつ使えるようになりますか？
2026年11月時点（wslc 3.0.3.0）では、wslc compose コマンドは未実装です。Microsoftの公式発表およびGitHubリポジトリ（microsoft/WSL）では最優先の次期開発機能として実装が進められています。現時点で compose.yaml を使った複数コンテナ構成が必要な場合は、WSLディストリビューション（Ubuntu等）内のDocker Engine（docker compose）を併用してください。
Q4. C# や C++ のWindowsアプリから wslc を直接制御することはできますか？
はい、Microsoft公式のNuGetパッケージ Microsoft.WSL.Containers（WSL container API）が提供されています。dotnet add package Microsoft.WSL.Containers で導入することで、C#やC++/WinRTのコード内から Session や Container オブジェクトを生成し、イメージのプルやコンテナの起動・標準入出力の取得をプログラムで制御できます。
7. 用途別・wslc 実践ガイド記事一覧（トピッククラスター）
当ブログでは、wslc の導入から実践活用、ベンチマーク比較、トラブル解決までをテーマ別に詳しく解説しています。目的に応じて以下の個別記事を参照してください。
- WSL 3.0の全体像と導入・初期セットアップ：
- 【WSL 3.0】WSL2との違いと導入手順｜正式版コンテナの使い方
- Docker Desktopとのメモリ消費・起動速度の実測ベンチマーク比較：
- wslc vs Docker Desktop：メモリ消費・起動速度を実測比較
- VS CodeのDev Containers拡張機能バックエンドとして
wslcを使う手順： - wslcでVS Code Dev Containers連携する全手順
wslc buildでDockerfileから独自イメージを作成・タグ管理する手順：- wslc buildでDockerfileからカスタムイメージを作る方法
- DNS名前解決エラー、マウント問題、Compose未対応への実践的な対処法：
- wslcのエラー解決とCompose代替手順｜DNS・マウント対処法
まとめ
wslc（WSL Containers）は、Docker CLIと同じ感覚で扱える高い互換性と、アイドル時に自動でVMを停止してメモリを解放する軽量さを兼ね備えたWindows標準のコンテナ実行基盤です。
- 基本操作は
dockerをwslcに読み替えるだけで実行でき、ファイルコピーのみwslc container cpを使用する - リソース制限や保存先変更は
.wslconfigではなく、wslc settingsで開く%LOCALAPPDATA%\wslc\settings.yamlで管理する settings.yamlの変更後はwslc system session terminateでセッションを再起動すると即座に反映される- コンテナからWindowsホストへの通信には
host.wslc.internalを使用する
日々のコンテナ開発でコマンドオプションや設定キーを確認したくなった際は、ぜひこのチートシートを見返して活用してください。
本格的なサーバー運用ならVPSがおすすめ
自宅のPCで構築したコンテナ環境をインターネット上に公開して本番運用するなら、初期費用無料で導入しやすい「さくらのVPS」などのクラウド環境が便利です。
PR
次に読むおすすめ記事
WSL2とDockerを使ったWindows開発環境の構築手順や高速化設定、トラブル解決を体系的に学びたい方は、以下の総合ガイドもあわせて参考にしてください。
