はじめに

Windows＋WSL2（Ubuntu）で開発をしている皆さん、こんな経験はありませんか？

$ docker --version
docker: command not found

WSLのターミナルでdockerコマンドを叩くと「見つからない！」や「許可がない！」と怒られてしまう…。これは、Windows上のDocker DesktopとWSLがまだ正しく連携できていない「あるある」な状況です。

GitHub MCPのようなモダンな開発ツールや、CI/CDで使われる多くの機能はコンテナ（Docker）が前提となっています。ここで足止めを食らってしまうと、自動化や拡張といった開発体験の"入口"が閉ざされたままになってしまいます。

この記事では、WindowsにインストールしたDocker DesktopをWSL2（Ubuntu）と連携させ、dockerコマンドが使えるようになるまでの最短手順を解説します。

難しい専門用語は避け、コマンドは一つずつ丁寧に説明するので、初心者の方でも安心して取り組めます。この記事を読み終える頃には、あなたのWSLターミナルから「Hello from Docker!」のメッセージが届くはずです！

📚 得られること

WSL（Ubuntu）からWindowsのDocker Desktopを使う最短手順
遭遇しやすいエラーの原因と具体的な直し方
Docker環境の安定運用に向けたベストプラクティス

⏱️ 所要時間

15〜30分

🚀 本記事のゴール

WSL（Ubuntu）のターミナルで docker コマンドがそのまま使えるようになる。
docker run --rm hello-world が成功し、「Hello from Docker!」が表示される。
もしエラーが出ても、3つのチェックポイントで原因を特定し、自分で解決できるようになる。

💡 用語の前提（超ざっくり辞書）

この記事で使う主要な用語を、簡単に解説します。

WSL2 (Windows Subsystem for Linux 2): Windows上でLinux環境を動かすための機能です。Windows上で開発しながら、Linuxの強力なツールを使いたい場合に非常に便利です。今回は Ubuntu ディストリビューションを使用します。
Docker Desktop: Windows (またはmacOS/Linux) にDockerエンジンや関連ツールを一式インストールしてくれる公式アプリケーションです。クジラのロゴが目印🐳。
コンテナ: アプリケーションとその実行に必要なものをすべてパッケージングした、軽量で独立した実行環境です。「どこでも同じように動く」使い捨て可能な箱のようなもので、開発環境のポータビリティ（持ち運びやすさ）を高めます。
WSL 統合 (WSL Integration): Docker Desktopの機能の一つで、WSLからWindows側のDockerエンジンを操作できるようにするための設定です。これにより、WSL内でDockerコマンドを実行できるようになります。
PATH: コマンドを実行する際に、OSがそのコマンドを探しに行く「検索パス」のことです。PATHが通っていないと、コマンドのフルパスを指定しない限り「command not found」と表示されてしまいます。
インストーラの種類: Docker Desktopのインストーラには、お使いのPCのCPUアーキテクチャに合わせた種類があります。
- AMD64 (x64): ほとんどのIntel製CPUやAMD製CPUを搭載したWindows PCで選択します。
- ARM64: SnapdragonなどのARMベースCPUを搭載したWindows PCでのみ選択します。

🛠️ ステップ1: Docker DesktopでWSL統合を有効にする

まずは、Docker DesktopがWSLからのDockerコマンドを受け付けられるように設定します。

Point（結論）

Docker Desktopの設定で、使用するWSLディストリビューション（例: Ubuntu）を有効にします。

Reason（理由）

DockerのメインエンジンはWindows上で動作しています。WSLの中からそのエンジンを遠隔操作するために、「WSL統合」という設定をONにする必要があります。これは、WSLとDocker Desktop間の通信経路を開くイメージです。

Example（画面手順）

Docker Desktopを起動します。（タスクトレイのクジラのアイコンを右クリックし、「Dashboard」を開くのが確実です。）
右上の「歯車アイコン (Settings)」をクリックします。
左のメニューから「Resources」を選び、さらに「WSL Integration」をクリックします。
利用しているWSLディストリビューション（例: Ubuntu）の横にあるスイッチをONにします。
右下の「Apply & Restart」ボタンをクリックし、設定を保存してDocker Desktopを再起動します。

Point（再確認）

この設定がONになっていないと、WSL内からdockerコマンドが見えません。まずはここを確実に有効化しましょう。

🛠️ ステップ2: WSLのPATHを設定する

次に、WSLのターミナルからdockerコマンドをどこからでも実行できるように、その場所をPATHに追加します。

Point（結論）

Docker DesktopがWSL向けに配置したCLI（コマンドラインインターフェース）の実行ファイルパスを、WSLの~/.bashrcファイルに追記します。

Reason（理由）

Docker Desktopは、WSLから利用するためのdockerコマンドの実体（実行ファイル）を、/mnt/wsl/docker-desktop/cli-tools/usr/bin/dockerという特定の場所に配置します。この場所をPATH環境変数に追加することで、フルパスを指定せずともdockerと打つだけでコマンドが実行できるようになります。

Example（コピペ＋詳細解説）

WSL（Ubuntu）のターミナルを開き、以下のコマンドを順番に実行してください。

1) CLIの実体があるか確認

# Dockerコマンドの実行ファイルがあるか確認
ls -l /mnt/wsl/docker-desktop/cli-tools/usr/bin/docker

コマンドの意味:
ls -lは、指定したファイルやディレクトリの詳細情報を表示するコマンドです。ここでは、Docker Desktopが配置したdockerコマンドの実行ファイルが存在するかを確認しています。
実行結果が-rwxr-xr-xのように表示されれば、ファイルが存在し、実行可能な状態であることを示します。もしNo such file or directoryなどと表示された場合は、ステップ1のWSL統合設定が正しく行われているか再度確認してください。

2) PATHにDocker CLIの場所を追加（未登録の場合のみ）

# PATHにDocker CLIの場所を追加する（既に登録されていなければ追記）
grep -q "/mnt/wsl/docker-desktop/cli-tools/usr/bin" ~/.bashrc || \
echo 'export PATH="/mnt/wsl/docker-desktop/cli-tools/usr/bin:$PATH"' >> ~/.bashrc

コマンドの意味:
このコマンドは少し複雑に見えますが、やっていることは非常に丁寧です。

grep -q "/mnt/wsl/docker-desktop/cli-tools/usr/bin" ~/.bashrc:
- ~/.bashrcファイルの中に、目的のPATH（/mnt/wsl/docker-desktop/cli-tools/usr/bin）が既に含まれていないかを確認しています。-qオプションは、検索結果を画面に表示せず、内部的に成否だけを判断します。
||:
- 前のコマンド（grep）が「失敗した」（つまり、目的のPATHが見つからなかった）場合にのみ、次のコマンドを実行するという意味です。これにより、同じPATHが~/.bashrcに何度も追記されるのを防ぎます。
echo 'export PATH="/mnt/wsl/docker-desktop/cli-tools/usr/bin:$PATH"' >> ~/.bashrc:
- 新しいPATH設定の行を~/.bashrcファイルの末尾に追記します。export PATH="..."は、環境変数PATHに新しいディレクトリを追加する構文です。:$PATHとすることで、既存のPATH設定を上書きせずに追加できます。

3) 設定をシェルに反映

# ~/.bashrcの設定を現在のシェルに再読み込みして適用
source ~/.bashrc

コマンドの意味:
sourceコマンドは、指定したファイルの内容を現在のシェル（ターミナル）で実行します。これにより、先ほど~/.bashrcに書き込んだPATH設定を、ターミナルを開き直さずにすぐに有効化できます。

Point（再確認）

PATHが正しく通っていれば、which dockerコマンドを実行したときに、/mnt/wsl/docker-desktop/cli-tools/usr/bin/dockerというパスが表示されるはずです。ここで確認しましょう。

🛠️ ステップ3: 動作テストは「3ステップチェック」で完璧に！

設定が完了したか、そしていざという時に原因を特定できるように、「場所 → 版数 → 実行」の3ステップチェックを行いましょう。

Point（結論）

which docker、docker --version、docker run --rm hello-worldの3つのコマンドを順に実行することで、dockerコマンドの存在、有効性、そして実動作を一気に確認できます。

Reason（理由）

「どこにあるか」「生きているか」「本当に動くか」という3つの視点から段階的に確認することで、もし問題が発生した場合でも、原因がどのステップにあるのかを素早く特定できます。

Example（コピペ＋詳細解説）

WSL（Ubuntu）のターミナルで以下を実行してください。

1) `docker`コマンドの場所を確認

# どのdockerコマンドが使われているか（PATH）を表示
which docker

コマンドの意味:
whichコマンドは、指定したコマンドがPATH環境変数内のどのパスで見つかったかを表示します。
期待する結果: /mnt/wsl/docker-desktop/cli-tools/usr/bin/dockerと表示されること。

2) Dockerクライアントのバージョンを確認（生存確認）

# Dockerクライアントのバージョンを表示
docker --version

コマンドの意味:
docker --versionは、インストールされているDockerクライアントのバージョン情報を表示します。このコマンドが成功すれば、dockerコマンド自体はOSに認識され、実行可能な状態にあることを意味します。
期待する結果: Docker version 2x.x.x, build ... のようにバージョン番号が表示されること。

3) `hello-world`コンテナを実行（実技テスト）

# 「hello-world」コンテナを一度だけ実行し、終了後に自動削除
docker run --rm hello-world

コマンドの意味:

docker run: 指定したDockerイメージからコンテナを作成し、実行するコマンドです。
--rm: コンテナの実行が終了した際に、そのコンテナを自動的に削除するオプションです。これにより、不要なコンテナが残るのを防ぎます。
hello-world: Docker公式が提供している非常にシンプルなテスト用イメージの名前です。

期待する結果:
初回実行時はhello-worldイメージの自動ダウンロードが始まります。その後、以下のようなメッセージが表示されれば連携は完璧に完了です！

Hello from Docker!
This message shows that your installation appears to be working correctly.
...

Point（再確認）

「Hello from Docker!」のメッセージが表示されたら、WindowsのDocker DesktopとWSL2の連携設定は完了です。これで、GitHub MCPなどのコンテナを前提としたツールを次のステップに進められます！

⚠️ よくある失敗と“即効薬”

もし上記の手順でうまくいかなかった場合でも、ご安心ください。よく遭遇するエラーとその解決策をまとめました。

ケースA: `docker: command not found`

原因: PATHが正しく設定されていないか、dockerコマンドの実体が見えていません。
即効薬: ステップ2に戻り、以下の手順をやり直してください。
1. ~/.bashrcへのPATH追記コマンドを実行する。
2. source ~/.bashrcで設定を反映する。
3. which dockerでパスが表示されるか確認する。

ケースB: `The command 'docker' could not be found in this WSL 2 distro...`

原因: Docker DesktopのWSL統合設定がOFFになっています。
即効薬: ステップ1に戻り、Docker DesktopのSettings → Resources → WSL Integrationで、UbuntuのスイッチがONになっていることを確認し、「Apply & Restart」をクリックしてください。

ケースC: `permission denied while trying to connect to the Docker daemon socket`

原因: Docker Desktopが起動していない、またはWSLが別のDockerエンジンを参照しようとしています。
即効薬:
1. Docker Desktopが起動しているか確認します（タスクトレイにクジラのアイコン🐳があるか）。起動していなければ起動してください。
2. WSLのターミナルで、Dockerの接続先をデフォルトに戻してみます。
```
docker context ls # 現在使っている接続先の一覧を表示
docker context use default # 既定（Docker Desktop）に切り替える
```

ケースD: VS Codeの統合ターミナルでだけ謎エラー

原因: VS Codeの統合ターミナルとWSL環境の特定の端末設定（TUI: Text User Interface）の相性が悪い場合があります。
即効薬: まずはWindows TerminalでWSLを直接開き、そこで動作するか確認してください。Windows Terminalで問題なく動く場合は、必要に応じて以下のコマンドをWSL内で試してみることで改善することがあります。
```
export TERM=xterm-256color # 端末の種類を明示的に設定
stty sane                   # 端末設定を初期状態にリセット
```

ケースE: Docker Desktopインストーラで`AMD64`か`ARM64`か迷う

目安: ほとんどのWindows PC（Intel製/AMD製CPU）はAMD64（またはx64）を選びます。ARMベースCPU（例: Snapdragon）を搭載したWindows PCを利用している方のみARM64を選択してください。ご自身のPCのCPUが不明な場合は、タスクマネージャー（Ctrl+Shift+Esc）の「パフォーマンス」タブからCPUの種類を確認できます。

🤝 競合を作らない安定運用（一つに統一！）

Point（結論）

Docker DesktopとWSL統合を使う場合は、WSL内に別途Docker（apt install docker.ioなど）をインストールしないでください。

Reason（理由）

WSL内でDocker Desktopとは別のDockerエンジンをインストールしてしまうと、システム内に複数のDocker環境が混在することになります。この状態だと、WSLがどちらのDockerエンジンを参照しているのかが不透明になり、「permission denied」や予期せぬ通信エラー、動作不安定の原因となります。
「内線電話と外線電話、どちらのDockerに繋がっているの？」という混乱を避けるためにも、Dockerの管理はDocker Desktopに一本化するのが、安定運用への最短ルートです。

Example（運用ルール）

Docker環境は「Docker Desktop方式」に一本化し、WSL内にはDockerをインストールしない。
podman-dockerのような代替CLIツールとの混在も避ける。
もしdockerコマンドの挙動に疑問を感じたら、which dockerとdocker context lsを実行して、現在の参照先を確認する習慣をつけましょう。

✅ まとめチェックリスト & 次のアクション

お疲れ様でした！最後に、あなたのDocker環境が正しく設定できたかを確認しましょう。

達成できたら合格！

which docker が /mnt/wsl/docker-desktop/.../docker を指している
docker --version でバージョン情報が表示される
docker run --rm hello-world で「Hello from Docker!」のメッセージが表示された

すべてにチェックが付いた方は、WSLでDockerを使いこなす第一歩を確実に踏み出しました！

📘 付録: コマンド一覧（意味つき・コピペ可）

# ----------------------------------------------------------------------
# 🛠️ ステップ2: WSLのPATHを設定する 関連コマンド
# ----------------------------------------------------------------------

# 1. Docker DesktopがWSLに置いたCLIの場所を確認
ls -l /mnt/wsl/docker-desktop/cli-tools/usr/bin/docker
# 意味: dockerコマンドの実行ファイルが存在し、実行可能かを確認します。
#      (-rwxr-xr-x と表示されればOK)

# 2. PATHにDocker CLIの場所を追加（未登録の場合のみ ~/.bashrc に一行追記）
grep -q "/mnt/wsl/docker-desktop/cli-tools/usr/bin" ~/.bashrc || \
echo 'export PATH="/mnt/wsl/docker-desktop/cli-tools/usr/bin:$PATH"' >> ~/.bashrc
# 意味: コマンド検索の「道順 (PATH)」に、docker CLIの場所を追記します。
#      既に登録済みの場合は何もせずスキップされます。

# 3. ~/.bashrc の設定を現在のシェルにすぐに反映
source ~/.bashrc
# 意味: 現在開いているターミナルに、新しい設定（PATH）を読み込み直して適用します。

# ----------------------------------------------------------------------
# 🛠️ ステップ3: 動作テスト（3ステップチェック）関連コマンド
# ----------------------------------------------------------------------

# 1. どのdockerコマンドが使われているか（PATH）を表示
which docker
# 意味: PATHを通して認識されているdockerコマンドのフルパスを確認します。
#      例: /mnt/wsl/docker-desktop/cli-tools/usr/bin/docker

# 2. Dockerクライアントのバージョンを確認（コマンドが生きているか）
docker --version
# 意味: Dockerクライアントのバージョン情報を表示します。
#      数字が表示されれば、コマンドはOSに認識されています。

# 3. 実技テスト: 最小コンテナ「hello-world」を一度だけ実行し、終了後に自動削除
docker run --rm hello-world
# 意味: 「hello-world」というテスト用コンテナを実行します。
#      初回は自動でイメージをダウンロードし、成功すれば「Hello from Docker!」が表示されます。

# ----------------------------------------------------------------------
# ⚠️ トラブルシューティング 関連コマンド
# ----------------------------------------------------------------------

# Dockerの接続先の一覧を表示
docker context ls
# 意味: 現在設定されているDockerのコンテキスト（接続先）の一覧を表示します。

# Dockerの接続先をデフォルト（Docker Desktop）に切り替える
docker context use default
# 意味: Dockerコマンドの接続先をDocker Desktopが管理する「default」に戻します。

# 端末の種類を明示的に設定（VS Code統合ターミナルでのトラブル時など）
export TERM=xterm-256color
# 意味: ターミナルの種類を xterm-256color に設定し、表示の問題を改善します。

# 端末設定を初期状態にリセット（VS Code統合ターミナルでのトラブル時など）
stty sane
# 意味: ターミナルの設定を安全なデフォルト値に戻し、異常な挙動を修正します。

参考文献

最後に

この記事が、Windows環境でのDockerとWSL2連携に悩む多くの開発者の方々のお役に立てれば幸いです。快適なコンテナ開発ライフを送りましょう！