【コンテナ技術】第1回：Dockerを始めるための環境準備 ― Windows/Mac/Linuxで最初にやること｜現場で使うDocker実践入門

はじめに：Docker入門は「環境構築」で8割つまずく

前回の連載では、コンテナ技術の全体像（なぜ必要か／なぜ運用が変わるか）を整理しました。
今回からは続編として「Dockerをこれから触る層」に向けた入門連載を始めます。

Dockerは概念を理解することも大切ですが、実は多くの方が最初につまずくのは、概念よりも「環境構築」です。
特に情シスや社内SEの立場では、個人開発と違って次のような制約が絡みます。

• 端末が会社貸与であり、管理者権限がない
• セキュリティソフトが強く、仮想化機能が制限される
• プロキシやSSL検査の影響で、イメージ取得が失敗する
• 「動いた」後の運用（更新・配布・サポート）が求められる

本記事では、Dockerを始めるために必要な環境準備を、Windows/Mac/Linuxそれぞれのポイントと、よくある落とし穴を含めて整理します。

この記事のゴール：まず「全体像を把握する」

第1回のゴールはシンプルです。
Dockerを始める前に、Windows/Mac/Linuxそれぞれで「何を準備すべきか」を整理し、社内PCでつまずきやすいポイント（仮想化、権限、プロキシなど）を事前に把握しておくことです。
実際のインストールと動作確認は、第2回で扱います。

Dockerを動かす環境は3種類ある

Dockerは「どこでも動く」と言われますが、実際には動かし方が3パターンあります。
最初にここを整理しておくと、遠回りを避けられます。

1. Docker Desktop（Windows/Mac）

最も一般的なのがDocker Desktopです。
GUIがあり、初心者が始めやすい一方で、企業利用では注意点もあります。

• 仮想化（WSL2 / Hyper-V）が必須
• 端末の権限やセキュリティ制限に影響されやすい
• 社内ポリシーでインストールが制限される場合がある

2. Docker Engine（Linux）

業務利用で最も安定するのはLinuxに直接Docker Engineを入れる方式です。
サーバー運用を前提にするなら、最終的にはここに落ち着くケースが多いです。

• 余計なレイヤーがなく、動作が安定
• CI/CDや本番運用に近い形で検証できる
• 権限設計（dockerグループなど）を理解する必要がある

3. クラウド上の開発環境（EC2/VM）

会社PCに制約が多い場合、クラウド上にLinuxを立ててDockerを動かすのも現実的です。
情シス視点では、端末制約を回避できるのがメリットです。

• ローカルPCに依存しない
• チームで共通環境を作りやすい
• ネットワークやセキュリティ設計が必要

最初にインストールするもの（OS別まとめ）

Dockerを始める際、初心者が混乱しやすいのが「結局どれを入れるのか？」という点です。
ここではOS別に、最初に必要なインストール対象を整理します。

Windowsで入れるもの

WindowsでDockerを使う場合は、基本的に次のセットになります。

• Docker Desktop（Docker本体）
• WSL2（Dockerを動かすLinux基盤）
• Linuxディストリビューション（例：Ubuntu）

つまり、WindowsでDockerを始めることは「Docker Desktopを入れる」だけでは完結しません。
WSL2を有効化し、その上にUbuntu等を導入して初めて、Dockerが安定して動く状態になります。

Macで入れるもの

Macは基本的にシンプルです。

• Docker Desktop

ただしApple Silicon（M1/M2/M3）の場合、チーム内でx86_64環境と混在すると、イメージ互換性の問題が起きることがあります。
この点は第2回以降で扱います。

Linuxで入れるもの

Linuxの場合、Docker Desktopは基本的に使いません。 導入対象は次の2つです。

• Docker Engine
• Docker Compose（plugin）

業務利用でLinuxを本番に使う場合は、開発環境もLinuxに寄せると差異が減り、運用まで見据えた検証がしやすくなります。

WindowsでDockerを始める（WSL2が前提）

WindowsでDockerを使う場合、現在の標準は Docker Desktop + WSL2 です。
ここを理解するうえで重要なのは、Docker Desktopは「Windows上でDockerが動いているように見える」だけで、実際には WSL2上のLinux環境でDocker Engineが動作しているという点です。

つまりWindowsでDockerを導入するということは、実質的に「Windows端末にLinux仮想環境を組み込む」作業になります。
この前提を押さえておくと、導入時のトラブル原因をかなり正確に切り分けられます。

導入前に確認すべき前提条件（ここを飛ばすと必ず詰まる）

Windows端末でDockerを動かすには、次の前提条件が揃っている必要があります。

• CPUが仮想化支援機能を持っている（Intel VT-x / AMD-V）
• BIOS/UEFIで仮想化が有効になっている
• Windows側で仮想化基盤が使える（WSL2）
• 端末に十分なメモリ・ディスクがある（最低でもメモリ16GB推奨）

ここで最も多いのが、BIOS側で仮想化が無効になっているケースです。
特に会社貸与PCでは、セキュリティポリシーやモデル差によって初期設定が異なります。

「インストールはできたが起動しない」「WSL2が入らない」という場合、Dockerの問題ではなく、まず仮想化設定を疑うのが鉄則です。

WSL2とは何か：Docker Desktopの「土台」

WSL2（Windows Subsystem for Linux 2）は、Windows上でLinuxを動かすための仕組みです。
WSL1と違い、WSL2はLinuxカーネルを持つため、Dockerのようなコンテナ実行基盤を動かせます。

ここで理解しておきたいのは、WSL2は単なるアプリではなく、Windowsの内部に「Linux仮想環境」を作る仕組みだという点です。
そのため、会社PCで次の制約があると導入が止まります。

• 仮想化が禁止されている
• Windowsの機能追加が制限されている
• 管理者権限がない

情シス担当者としては、Docker導入は「開発ツールの導入」ではなく、端末の仮想化機能を許可するポリシー設計とセットで考える必要があります。

WSL2の落とし穴：メモリ・ディスクを想像以上に使う

WindowsでDockerを導入して運用を始めると、次の問題が高確率で起きます。

• PCが急に重くなる
• Docker Desktopが不安定になる
• ディスクが突然埋まる

原因は、WSL2が内部にLinux環境を持つため、Dockerイメージやコンテナのデータが「WSL2の仮想ディスク」に溜まるからです。
しかもこの仮想ディスクは、放置すると肥大化しやすく、ユーザーが気づきにくい場所に作られます。

特に検証用途で、MySQLやPostgreSQLをコンテナで動かし始めると、データ領域が増え、気づいたときには数十GBが消費されていることも珍しくありません。

業務利用では「Dockerを使う端末の最低スペック」を先に決めておくことが重要です。
感覚的には、開発用途なら メモリ16GB・SSD 256GB以上が現実的なラインになります。

企業ネットワーク最大の壁：プロキシとSSL検査

WindowsでDockerが動かない原因として、現場で最も多いのはプロキシです。
特に企業ネットワークでは、次の構成がよくあります。

• HTTP/HTTPSがプロキシ経由になっている
• SSL通信が検査されている（中間証明書が挿入される）
• 特定の外部サイトへの通信が制限されている

Dockerはイメージ取得時にDocker Hubなど外部レジストリへアクセスします。
この通信がプロキシやSSL検査に引っかかると、次のような症状が出ます。

• docker pullがタイムアウトする
• 証明書エラーになる
• ログインができない

重要なのは、これはDockerの問題ではなく、ネットワークポリシーの問題だという点です。
つまり、エンジニアが個別に頑張っても解決できないことが多く、情シス側で「許可すべき通信」「社内証明書の配布」「例外設定」を整理する必要があります。

セキュリティソフト・EDRとDockerは相性問題が出やすい

Windows端末では、ウイルス対策ソフトやEDRが強力に入っていることが一般的です。
Docker Desktopは内部で仮想化とネットワーク機能を使うため、セキュリティ製品によっては以下がブロックされます。

• 仮想化機能の利用
• WSL2の起動
• Dockerのネットワーク（仮想NIC）
• イメージの保存領域

この場合の特徴は「端末によって動いたり動かなかったりする」ことです。
同じWindowsでも、部署やユーザーによって適用されているポリシーが違うと、現場は混乱します。

業務でDockerを使うなら、情シスとして「Docker利用者向けの端末標準設定」を用意することが、結果的にサポート工数を大きく下げます。

Hyper-VとWSL2の違い：今はWSL2が基本

Windowsの仮想化にはHyper-Vという仕組みもあります。
以前はDocker DesktopがHyper-Vを使う構成もありましたが、現在はWSL2が基本です。

ただし企業環境では、次のような事情が絡みます。

• Hyper-Vが有効化されている端末と、されていない端末が混在する
• 仮想化ソフト（VMware等）との競合が起きる
• セキュリティ要件でHyper-Vが制限される

そのため、Dockerを社内導入する場合は「WSL2を標準とする」と明確に決め、端末の設定を揃えることが重要です。

Windows導入で最初に作るべきチェックリスト（情シス向け）

WindowsでDockerを業務利用する場合、導入フェーズで以下のチェックリストを作ると、後工程の混乱が大きく減ります。

• 対象端末の仮想化が有効か（BIOS/UEFI）
• WSL2が利用可能か（OSバージョン・権限）
• メモリ・SSD容量は十分か
• プロキシ環境でdocker pullが通るか
• SSL検査環境で証明書エラーが出ないか
• セキュリティソフトがWSL2をブロックしないか
• Docker利用者向けの標準設定を配布できるか

Dockerの導入は、単なるツール導入ではなく、端末・ネットワーク・セキュリティの設計が絡む「小さなIT導入プロジェクト」です。
ここを押さえておくと、Dockerの学習も運用もスムーズに進みます。

Dockerを始めるにあたり、特にWindows環境では「Docker Desktopのインストール」「WSL2の有効化」「仮想化（BIOS設定）の確認」など、導入手順が気になる方も多いと思います。
ただし、この部分はPCの構成（Windows 10/11、Home/Pro、社内PCの制限、プロキシ有無）によって手順やつまずきポイントが大きく変わります。
そのため本記事では、まず「Dockerを導入する前に知っておくべき前提」と「Windows環境で失敗しやすいポイント」に絞って解説しています。
具体的な導入手順は、次回以降で補足記事として整理し、環境別に分けて紹介する予定です。

MacでDockerを始める（最も楽だが注意点もある）

MacはDocker初心者にとって最も始めやすい環境です。
ただし、Apple Silicon（M1/M2/M3）では「CPUアーキテクチャの違い」が落とし穴になります。

Intel MacとMシリーズMacの違い

MシリーズMacはARMアーキテクチャです。
このため、x86_64前提のイメージを使うと、次のような問題が起きます。

• 起動はするが動作が遅い（エミュレーション）
• 一部のイメージが動かない
• チーム内で環境差異が発生する

業務利用では「誰のPCでも同じように動く」が重要です。
この点は第2回以降で扱いますが、Macの場合は最初から意識しておくと後で困りません。

LinuxでDockerを始める（業務利用の本命）

LinuxにDocker Engineを導入する場合、ポイントは次の2つです。

• 公式手順でインストールする（OS標準リポジトリは古い場合がある）
• 権限設計（rootで実行するか、dockerグループを使うか）を理解する

特に業務利用では「誰がdockerを実行できるか」がセキュリティに直結します。
安易に全員をdockerグループに入れると、実質root権限に近い状態になります。

情シス担当者が最初に意識すべき「業務利用の注意点」

個人利用では「動けばOK」になりがちですが、業務利用では最初から意識すべき点があります。

プロキシ環境（企業ネットワーク）

企業ネットワークでは、docker pullが失敗する原因の多くがプロキシです。
特にSSL検査が入っている場合、証明書の扱いが絡みます。

「特定のPCだけpullできない」などの症状は、ネットワークより端末設定の可能性が高いです。

セキュリティソフトと仮想化

Docker Desktopは内部で仮想化を使うため、セキュリティソフトが強い環境では止められることがあります。
この場合、エンジニア側では解決できず、情シス側で例外設定やポリシー調整が必要になります。

ディスク容量（意外とすぐ埋まる）

Dockerはイメージを蓄積していくため、使い始めると意外と早くディスクを圧迫します。
検証端末で容量不足が起きると、動作が不安定になり、原因特定も難しくなります。

「Dockerを使う端末は余裕のあるSSDが必要」というのは、現場では重要なポイントです。

次回予告：Docker Desktop／Linux環境の準備と最初の起動

第2回では、Windows/MacではDocker Desktop、LinuxではDocker Engineを前提に、Dockerを実際に使い始めるための導入ポイントを整理します。
環境によって手順がブレやすい部分は押さえつつ、最後は「hello-world」を起動して、Dockerが正常に動作している状態まで確認します。