はじめに
第1回では「Dockerを始めるための環境準備」として、Windows/Mac/Linuxそれぞれで前提となる仕組み（WindowsならWSL2、企業PCなら仮想化やプロキシが壁になる等）を整理しました。
第2回ではいよいよ、実際にDockerを使い始めるための準備として、Docker Desktop（Windows/Mac）とLinux環境（Docker Engine）の導入方針を整理し、最初の起動と動作確認までを一気に行います。
本記事のゴールは「インストールができた」ではなく、hello-worldコンテナを起動し、Dockerが正常に動作している状態を確認できることです。
まず結論：Windows/MacはDocker Desktop、LinuxはDocker Engineが基本
Dockerの導入で混乱しやすいのは「何を入れればDockerが使えるのか」がOSによって異なる点です。まずは結論から整理します。
- Windows：Docker Desktop（内部でWSL2を利用する構成が基本）
- Mac：Docker Desktop（Intel/Apple SiliconどちらでもOK）
- Linux：Docker Engine（docker-ce）＋ Compose plugin（docker compose）
この構成を選ぶ理由は単純で、最も情報が多く、運用実績が多く、トラブルシューティングもしやすいからです。
特に企業利用では「安定した導入経路を選ぶ」こと自体が重要な判断になります。
Windows：Docker Desktop + WSL2（最も現実的な導入パターン）
WindowsでDockerを始める場合、現在の主流はDocker Desktop + WSL2です。
以前はHyper-V方式もありましたが、現在はWSL2が事実上の標準になっています。
なぜWSL2が必要なのか
DockerはもともとLinuxの仕組み（namespace/cgroups）を前提に設計されています。
Windows上でDockerを動かすには、内部的にLinux環境が必要です。
WSL2は「Windows上に軽量なLinuxカーネルを持つ仕組み」であり、Dockerが本来の動作に近い形で動くため、互換性が高くなります。
情シス担当者の視点で重要なのは、ここでのポイントが「Linuxが動いている」ことだと理解することです。
Docker DesktopはGUIアプリに見えますが、裏側ではWSL2上でDocker Engineが動いています。
導入の流れ（最小構成）
細かい画面操作はバージョンで変わりやすいため、本記事では「何を達成すれば良いか」に絞って整理します。
- WSL2を有効化する（Windows機能＋wslコマンド）
- Docker Desktopをインストールする
- Docker Desktopの設定で「WSL2 backend」を利用する
- PowerShellまたはWindows Terminalで動作確認する
ここでの重要点は、インストール後に「Docker Desktopが起動していること」「WSL2連携が有効になっていること」の2つです。
インストールしただけでDockerが使えるわけではなく、Docker Desktopがサービスとして動いている必要があります。
企業PCで詰まりやすいポイント（事前に知っておくべき）
Windows環境では、個人PCよりも企業PCのほうが導入難易度が上がります。代表的な詰まりポイントは次の通りです。
- 仮想化が無効：BIOS/UEFI設定でVirtualizationがOFFになっている
- 権限不足：インストールに管理者権限が必要
- セキュリティ制約：WSL2の利用がポリシーで禁止されている
- プロキシ：イメージ取得（pull）ができない
特に情シス担当者としては、ここを「個人の頑張りで解決する問題」にしてしまうと、組織導入が破綻します。
Dockerを業務で使うなら、導入段階で「許可する条件」「例外申請のルール」を作るほうが現実的です。
Mac：Docker Desktop（導入は最もシンプル）
MacはDocker導入が最もスムーズなケースが多いです。基本的にはDocker Desktopをインストールし、起動すれば利用できます。
Intel MacとApple Silicon（M1/M2/M3）の違い
近年はApple Siliconが主流ですが、ここで知っておくべきは「CPUアーキテクチャが違う」という点です。
- Intel：x86_64
- Apple Silicon：arm64
DockerはイメージにもCPUアーキテクチャの概念があります。多くの公式イメージは両対応ですが、古いイメージや一部のOSSではx86_64のみのものもあります。
その場合、Apple Siliconではエミュレーションで動かすことになり、性能が落ちる可能性があります。
ただし、入門段階では気にしすぎる必要はありません。まずは「動くこと」「仕組みが理解できること」を優先してOKです。
Macで詰まりやすいポイント
Macは比較的少ないですが、企業利用では次が詰まりポイントになります。
- セキュリティソフトでDocker Desktopの権限が制限される
- プロキシ環境でDocker Hubへ接続できない
- ディスク容量不足（Dockerがイメージを保持するため）
特にディスクは、開発者が気づかないうちにイメージが増えて圧迫しやすいため、組織として運用する場合は注意が必要です。
Linux：Docker Engine（docker-ce）で導入する
LinuxはDockerの本場であり、最も自然に動作します。
一方で、Windows/Macのように「Docker Desktopが全部やってくれる」わけではないため、導入の考え方を整理しておくことが重要です。
Linuxで入れるべきもの（最小セット）
LinuxでDockerを使う場合、基本的に次の構成になります。
- Docker Engine：コンテナを動かす本体（dockerd）
- Docker CLI：dockerコマンド
- Docker Compose：現在はplugin形式（docker compose）
ここで重要なのは、最近のDocker Composeは「docker-compose」という別コマンドではなく、docker composeとして統合されている点です。
古い記事を参考にすると混乱しやすいので注意してください。
root権限問題：sudo地獄を避ける
LinuxでDockerを導入すると、多くの人が最初に遭遇するのが「dockerコマンドがsudo無しで実行できない」問題です。
これは仕様です。Dockerは強い権限を扱うため、基本的にはroot権限が必要になります。
開発環境や検証環境では、一般的に次のどちらかを選びます。
- dockerグループにユーザーを追加してsudo無しで実行できるようにする
- rootlessモードで動かす（セキュリティ重視）
業務利用で重要なのは、ここを「個人設定」にしないことです。
運用ルールとしてどちらを採用するかを決めないと、環境差が生まれて引継ぎ不能になります。
最初の動作確認：hello-worldを動かす
インストールが完了したら、必ず「コンテナが起動できること」を確認します。
最も確実なのがhello-worldです。
1. バージョン確認
まずはDockerが認識されているか確認します。
- docker –version
- docker compose version
ここでエラーが出る場合は、インストールが完了していないか、パスが通っていない可能性があります。
2. hello-worldを起動する
次に、hello-worldを起動します。
- docker run hello-world
このコマンドは、次の処理をまとめて実行します。
- hello-worldイメージを取得（初回のみ）
- コンテナを作成
- コンテナを起動
- 実行結果を表示して終了
ここで「Hello from Docker!」のようなメッセージが出れば、Dockerは正常に動いています。
これが第2回の最重要ゴールです。
pullに失敗する場合：プロキシとネットワークを疑う
企業環境で多いのが「docker run hello-world」でイメージ取得に失敗するケースです。
これはDockerの問題というより、ネットワーク設計の問題です。
- Docker Hubへの通信がブロックされている
- プロキシ設定がDockerに渡っていない
- 証明書（SSL inspection）で通信が失敗している
この問題は、現場担当者が気合で解決するのではなく、情シスとして「公式レジストリを許可するのか」「社内レジストリを用意するのか」を含めて整理すべき領域です。
Docker Desktopで最低限見るべき設定
Docker Desktopはインストールして終わりではなく、最低限確認すべき設定があります。特に企業利用では重要です。
リソース設定（CPU/メモリ/ディスク）
Docker Desktopは内部でLinux VM（またはWSL2）を動かしているため、リソース割当があります。
ここが小さすぎると、DBコンテナなどがすぐに落ちます。
- メモリ不足でMySQLが起動しない
- ディスク不足でイメージがpullできない
検証用途であっても「最低限の余裕」は必要です。
Windows：WSL integrationの確認
Windowsの場合、Docker DesktopがWSL2と正しく連携しているか確認します。
これがズレると「PowerShellでは動くのにWSL内では動かない」といった混乱が発生します。
業務では「どのターミナルを標準にするか」を決めておくと、サポートが楽になります。おすすめはWindows Terminalです。
次回予告
第2回では、Docker Desktop／Linux環境の準備と、最初の起動・動作確認までを行いました。
ここまでできれば、Dockerの学習は「読んで理解する段階」から「触って理解する段階」に入れます。
次回は Dockerfile入門として、FROM / RUN / COPY / CMD / ENTRYPOINT の役割を整理しながら、公式イメージを使うだけではなく「自分のアプリをDockerで動かす」ための第一歩を解説します。
