wslc.exe は、WSLに組み込まれたLinuxコンテナ用CLIです。Dockerに似た操作感がありますが、Docker EngineやDocker Composeの互換実装ではありません。そのため、Docker向けの手順をそのまま流用すると、コマンドや設定の違いでつまずくことがあります。
この記事では、Microsoftの公式ドキュメントで確認できる範囲に絞り、wslc が起動しない場合の確認、Composeを必要とする場合の選択肢、DNS・バインドマウント・リソース設定を調べる手順を紹介します。
この記事で行うこと
wslc.exeの前提条件と基本動作を確認する- Composeファイルが必要な場合の選択肢を判断する
- DNS、マウント、ポート公開の問題を切り分ける
.wslconfigではなくwslc settingsでリソースを設定する
前提条件・対象読者
| 項目 | 内容 |
|---|---|
| 対象OS | Windows 11でWSLを利用している環境 |
| 必須WSLバージョン | 2.9.3以降 |
| コンテナCLI | wslc.exe |
| 確認コマンド | wsl --version、wslc version、wslc --help |
| 最終確認日 | 2026年10月 |
1. 症状別：最初に確認するコマンド
| 症状 | まず確認すること | 対処の方向性 |
|---|---|---|
wslc が見つからない | WSLのバージョン | wsl --update 後に再確認します |
| 最初のコンテナ実行が失敗する | 基本イメージを使った動作確認 | エラー全文と wslc --help の該当コマンドを照合します |
| Composeファイルを起動できない | Docker Composeを前提にしていないか | Docker Compose対応の実行環境を選びます |
| リソース制限が反映されない | 設定ファイルの種類 | wslc settings で開く settings.yaml を確認します |
| ホストへ接続できない | 公開ポートとホスト名 | host.wslc.internal とポート公開設定を確認します |
2. 手順1：WSLとwslcを更新・確認する
PowerShellでWSLを更新し、インストール済みのバージョンを確認します。
wsl --update
wsl --version
wslc version
wslc.exe はWSLに含まれるため、別のコンテナエンジンをインストールする手順は不要です。基本動作は、公式チュートリアルと同じ hello-world イメージで確認できます。
wslc run --rm hello-world
成功すれば、まずCLI・セッション・イメージ取得の基本経路は動作しています。失敗した場合は、表示されたエラー全文を残し、wslc run --help と照合してください。
3. 手順2：Composeが必要ならDocker Compose対応環境を選ぶ
wslc の公式CLIリファレンスでは、run、image、container、system session などの操作が案内されています。一方、Docker Composeの compose.yaml をそのまま解釈・起動する機能は、公式ドキュメントには記載されていません。
複数サービスを compose.yaml で管理したい場合は、次のいずれかを選びます。
- Docker DesktopのDocker Composeを使う
- WSLディストリビューション内にDocker EngineとCompose pluginを構築する
- サービスごとに
wslcでコンテナを起動し、ネットワーク・ポート・環境変数を個別に管理する
非公式のラッパーCLIは、対応するCompose仕様、認証情報の扱い、メンテナンス状況を確認できない限り、業務環境の標準手順には採用しない方が安全です。
4. 手順3：DNSとホスト接続を切り分ける
名前解決に失敗した場合、最初からパブリックDNSを固定せず、コンテナ内で名前解決と外部通信を分けて確認します。
wslc run --rm -it ubuntu:latest bash
コンテナ内で、対象ホスト名への名前解決とHTTPS接続を確認してください。社内DNS、VPN、プロキシ、証明書の要件がある環境では、ネットワーク管理者の指定に従う必要があります。
Windowsホスト上のサービスに接続したい場合、WSL container settingsの既定のホスト名は host.wslc.internal です。公開ポートとアプリケーションの待受アドレスを確認した上で利用します。Windows側へポートを公開する例は次のとおりです。
wslc run -it --rm -d -p 8080:80 --name web nginx
curl localhost:8080
5. 手順4：マウントとファイルが見えない問題を調べる
マウントの指定方法は、CLIバージョンと使用するオプションによって異なります。Linux形式のパス、Windows形式のパス、相対パスを推測で置き換えると、意図しない空ディレクトリを作る原因になります。
最初に、利用中のCLIが受け付けるマウント構文を確認します。
wslc run --help
公式チュートリアル・APIリファレンスに記載の構文を使い、ホスト側にテスト用ファイルを1つだけ用意して、コンテナ内で同じ内容を読めるか確認してください。アプリ全体をマウントする前に最小構成で確かめると、パスの問題とアプリ側の問題を分けられます。
6. 手順5：CPU・メモリ・保存先はwslc専用設定で管理する
.wslconfig はwslcのコンテナセッションには適用されません。リソース、保存先、ホストループバックは、PowerShellで wslc settings を実行して作成・表示する %LOCALAPPDATA%\wslc\settings.yaml で設定します。
wslc settings
設定例は次のとおりです。
session:
cpuCount: 4
memorySize: 8 GB
maxStorageSize: 500 GB
storagePath: D:\wslc-data
defaultBindingAddress: 127.0.0.1
hostLoopback: host.wslc.internal
session.* の設定は、コンテナセッションが次に起動するときに読み込まれます。すでにセッションが動いている場合は、公式設定ページに従って wslc system session terminate を実行してから再確認します。保存先を変更しても既存のイメージやコンテナが自動移動するわけではない点にも注意してください。
よくある質問
wslc はDocker Desktopの代わりになりますか？
単一コンテナをビルド・実行する用途では選択肢になりますが、Docker Composeを中心とする既存の開発手順をそのまま移せるとは限りません。必要な機能から判断してください。
.wslconfig のメモリ設定が効かないのはなぜですか？
wslc のコンテナセッションは専用の設定体系を持つためです。wslc settings で開く settings.yaml の session.memorySize を確認してください。
コンテナからWindowsホストへ接続するには？
既定では host.wslc.internal が使えます。アプリケーションが正しいアドレス・ポートで待ち受けていることと、Windowsファイアウォールの設定を確認してください。
まとめ
wslc の問題は、まず wsl --version、wslc version、wslc --help で実際の環境を確認して切り分けます。Composeが必須ならCompose対応環境を選び、リソース設定は .wslconfig ではなく wslc settings を利用してください。DNSやマウントは、最小のコンテナとテスト用ファイルから確認するのが安全です。
次に読むおすすめ記事
WSL2とDockerを使ったWindows開発環境の全体像は、以下のハブ記事で解説しています。
