Windows で Docker — Docker Desktop vs WSL2 ネイティブ＋ライセンスの落とし穴

Windows で Docker を動かす主な方法は 2 つある — Docker Desktop と WSL2 内部に docker エンジンを直接インストールする方法。決め手は会社の規模・ライセンス・GUI の必要性だ。以前は Docker Desktop 一択で考えていた。いまでは会社規模と用途によって最適解が異なるからこそ、ライセンスとパフォーマンスの両面から判断することが重要だと考える。

このガイドは Windows 11 + WSL2 (Ubuntu 22.04+) を対象とする。Windows 初期セットアップ と WSL チューニング の後に行うコンテナ環境の選択ステップに相当する。

TL;DR

意思決定ツリー

会社に社員 250 人以上、または年商 1,000 万ドル以上がある？
   │
   ├─ Yes → Docker Desktop ライセンスを確認（契約するか WSL2 ネイティブへ）
   │
   └─ No →
       GUI / ワンクリック Kubernetes が必要？
          │
          ├─ Yes → Docker Desktop
          │
          └─ No → WSL2 ネイティブ docker エンジン（最軽量）

前提条件

• Windows 10 build 19041 以上、または Windows 11
• WSL2 有効化済み — WSL チューニング
• 仮想化が有効（BIOS で VT-x / SVM が有効）

パス A — Docker Desktop — 5 分

最も一般的な方法。UI + Kubernetes + WSL 統合が一度に揃う。

A.1 インストール

winget install Docker.DockerDesktop

インストール後に 1 度再起動する。

A.2 WSL2 バックエンド

Docker Desktop 起動 → Settings → General → Use the WSL 2 based engine ✅（デフォルト）。

A.3 WSL ディストリとの統合

Settings → Resources → WSL Integration → 使用するディストリ（Ubuntu）を ON にする。

WSL Ubuntu 内で docker が使えるようになる：

# WSL Ubuntu 内
docker --version
# Docker version 24.x.x, build xxxxx
docker info
docker run --rm hello-world

A.4 リソース制限

Settings → Resources → memory/CPU スライダー。デフォルトはホストの 50%。ラップトップなら 4GB / 2 CPU で十分。

// .wslconfig（Docker Desktop とは別 — WSL 全体のリソースを制御）
[wsl2]
memory=8GB
processors=4
swap=2GB

A.5 ライセンス — 最大の落とし穴

無料利用条件：

• 個人利用
• 教育・研究
• 非営利団体
• 社員数 250 人未満かつ年間収益 1,000 万ドル未満 の企業

これらに該当しない場合、有料サブスクリプションが必要：

商業利用の場合は IT 部門に確認すること。回避するにはパス B へ。

パス B — WSL2 ネイティブ docker エンジン — 10 分

ライセンス回避 + 軽量。GUI なし。

B.1 WSL Ubuntu 内に docker をインストール

# WSL Ubuntu 内（22.04+）
 
# 1. 競合パッケージの削除
for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do
  sudo apt-get remove -y "$pkg" 2>/dev/null
done
 
# 2. Docker 公式リポジトリの追加
sudo apt-get update
sudo apt-get install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
 
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
 
sudo apt-get update
 
# 3. docker エンジン + compose プラグインのインストール
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

B.2 systemd の有効化（WSL2 ではデフォルト OFF）

WSL2 はデフォルトで systemd を使わない → docker デーモンが自動起動しない。有効化する：

# /etc/wsl.conf を編集（sudo 必要）
sudo tee /etc/wsl.conf > /dev/null <<'EOF'
[boot]
systemd=true
EOF

Windows PowerShell から WSL を再起動：

wsl --shutdown
# その後 wsl で再接続

B.3 docker グループへのユーザー追加 — sudo なしで実行

sudo groupadd docker
sudo usermod -aG docker $USER
# 新しいシェル（または wsl --shutdown + 再接続）
newgrp docker
 
# 確認
docker run --rm hello-world

B.4 自動起動の確認

systemctl is-enabled docker     # enabled
systemctl status docker         # active (running)

WSL 起動のたびに docker デーモンが自動起動する。

パス C — Podman（代替）— 5 分

Docker 互換 + デーモンレス + 無料。企業ライセンス問題を回避する選択肢として一般的。

# Ubuntu 22.04+
sudo apt-get install -y podman podman-compose
 
# docker を podman にエイリアス（オプション）
echo 'alias docker=podman' >> ~/.bashrc
echo 'alias docker-compose=podman-compose' >> ~/.bashrc

ほとんどの Dockerfile と docker-compose.yml はそのまま動く。注意点：

• デフォルトでルートレス — ホストネットワークに一部制限
• Docker Hub がデフォルトレジストリではない → ~/.config/containers/registries.conf に追加が必要

このガイドの範囲外 — 別ガイドの候補。

1. パフォーマンス比較 — 実測値（Ubuntu 22.04 + WSL2）

同一マシン（16GB RAM、Ryzen 7）、docker run --rm node:20 npm install を 100 回実行：

CPU / ディスクのパフォーマンスはほぼ同一。大きな差はアイドルメモリ — ネイティブ / Podman はラップトップのバッテリーに優しい。

2. 日常パターン

2.1 docker run 1 行エイリアス

# ~/.bashrc または ~/.zshrc
alias dps='docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Status}}"'
alias dim='docker images --format "table {{.Repository}}:{{.Tag}}\t{{.Size}}"'
alias dprune='docker system prune -af --volumes'  # 注意！

2.2 Compose の高速化

# 変更したサービスだけリビルド + 再起動
docker compose up -d --build app
 
# イメージキャッシュを強制利用
DOCKER_BUILDKIT=1 docker compose build

2.3 WSL Ubuntu 内の docker エンジン + Windows ホストの IDE

• VS Code Remote-WSL で WSL フォルダを開く
• VS Code の Docker 拡張が WSL 内のデーモンを自動検出
• ビルド・実行は WSL 内、編集は Windows IDE で

Mac iTerm + Docker Desktop とほぼ同じ UX を、ライセンスなしで実現できる。

2.4 よく使うクリーンアップ

docker system df              # ディスク使用量
docker container prune        # 停止コンテナの削除
docker image prune -a         # タグなしイメージの削除
docker builder prune          # buildkit キャッシュのクリア

3. WSL2 → Docker のディスク場所（たまにハマる）

WSL2 のデータは ext4.vhdx 仮想ディスク内に存在する。時間とともに肥大化し、自動では縮小しない。

ディスクの圧縮（手動）

# Windows PowerShell（管理者）
wsl --shutdown
 
# vhdx を圧縮 — Ubuntu の例
$vhd = "$env:LOCALAPPDATA\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx"
Optimize-VHD -Path $vhd -Mode Full
# Hyper-V がない場合は diskpart で同等の操作

Docker 側のクリーンアップ（docker system prune -af --volumes）だけで十分なことも多い。

4. トラブルシューティング

「docker: Cannot connect to the Docker daemon」

• パス A: Docker Desktop が起動していない。スタートメニューから起動して待つ。
• パス B: systemd が無効またはデーモンが起動していない。sudo systemctl start docker を実行。

「permission denied while trying to connect to Docker daemon socket」

ユーザーが docker グループに属していない。sudo usermod -aG docker $USER + newgrp docker、または WSL セッションを新しく開く。

インストール済み Docker Desktop と WSL ネイティブ docker が競合する

同じ WSL ディストリで両方動かすと競合する。どちらか一方を選ぶ：

• Desktop → そのディストリを Settings → Resources → WSL Integration でチェックしたままにする
• ネイティブ → チェックを外して Desktop を終了する

イメージのビルドが遅い

• BuildKit を確認：export DOCKER_BUILDKIT=1
• node_modules / .git を .dockerignore に追加 — コンテキストサイズがビルド時間に直結する
• マルチステージビルド + キャッシュマウント（RUN --mount=type=cache,target=/root/.npm）

Windows ファイルシステムのマウントが遅い

/mnt/c/... 経由の 9P は遅い。WSL の ext4 領域（~/）内で作業すること。Windows ↔ WSL 間の頻繁なファイル交換には \\wsl$\Ubuntu\... または VS Code Remote-WSL を使う。

次のステップ

• Windows 初期セットアップ — WSL2 の基本
• WSL チューニング — メモリ/CPU/ネットワーク
• Windows Terminal セットアップ — ターミナル環境
• PowerShell プロファイル — $PROFILE

参考リンク

• Docker Desktop licensing
• Docker Engine official install
• WSL2 systemd support
• Podman

更新履歴

• 2026-05-12 — 初稿（devAlice M2 シード展開）