【Day 06】Windows 11 + WSL2（Ubuntu）の仕組みとDocker Desktopの導入

▲ Day 06: Windows 11 + WSL2（Ubuntu）の仕組みとDocker Desktopの導入

🐳

皆さん、こんにちは！ Docker/コンテナ実践講座の専任講師です。
第1部の概念編（Day 01〜05）を通じて、Dockerの本質である「プロセス分離」「イミュータブルインフラ」「IaC」の重要性を掴んでいただきました。
本日からは「第2部: Windows開発環境構築と初期設定」に突入します！
30年間Windowsのデスクトップ環境やGUIインストーラーを使いこなしてきた皆様に向けて、Windows 11上でLinuxコンテナが驚異的なスピードで動く「WSL2（Windows Subsystem for Linux 2）」の仕組みと、Docker Desktopの安全な導入手順を徹底解剖します！

① 導入・本日の達成目標

「Windows上でLinuxのDockerを動かすには、重いHyper-V仮想マシンを起動しなければならないのでは？」
「過去にWindowsでDockerを使おうとして、PC全体がカクカクに重くなって挫折した…」

もしあなたがそう感じた経験があるなら、ご安心ください。現代のWindows 11とWSL2（Windows Subsystem for Linux 2）の組み合わせは、従来の仮想マシンの常識を完全に覆す軽快さと快適さを実現しています。
本講義を終える頃には、以下の3つの目標を完全にクリアできるようになります。

• 従来のHyper-V仮想マシンとWSL2（超軽量ユーティリティVM）の決定的構造差を理解する。
• Windows側とWSL2内のLinuxエンジンがシームレスに連携するDocker Desktopの全体構造を掴む。
• 知らないとビルドが10倍遅くなる「ファイルシステム境界（Windows Cドライブ vs WSL2 Linux領域）」の罠を回避する。

② 従来のHyper-V仮想マシン vs WSL2（軽量仮想化）のアーキテクチャ差異

Windows上でLinuxを動かす技術として、かつてはHyper-VマネージャーでUbuntuの仮想マシン（VM）を作成し、固定メモリを数GB割り当てて起動していました。

▲ 【図解①】従来のHyper-V仮想マシン vs WSL2の超軽量Linuxカーネル統合アーキテクチャ

従来のHyper-V仮想マシンは独立性が高い反面、「OS起動に数分かかる」「メモリを固定占有してWindowsが重くなる」「WindowsとLinux間のファイル共有が極めて遅い」という大きな壁がありました。

これに対し、Windows 10/11に統合されたWSL2は、Microsoftが独自に最適化した本物のLinuxカーネルを「超軽量ユーティリティVM」として動かします。

• 秒速起動: ゲストOSの初期化処理をバイパスし、わずか 0.5〜1秒 でLinux環境が立ち上がる。
• 動的リソース共有: メモリを固定確保せず、コンテナが使用している分だけホストWindowsから動的に割り当て・返却される。
• 完全なLinuxシステムコール互換: エミュレーションではなく本物のLinuxカーネルが動くため、Docker Engineが100%ネイティブ性能で稼働する。

📊 従来のHyper-V仮想マシンとWSL2の完全対比表

比較項目	従来のHyper-V 仮想マシン	WSL2（軽量Linux統合環境）
起動時間	1分〜数分（OSブート待機）	わずか 1秒以内（即時利用可能）
メモリ割り当て	固定確保（例: 4GBを常にロック）	動的共有（必要に応じて増減・返却）
Windowsとのファイル統合	SMB共有やネットワーク経由（低速・面倒）	\\wsl$\ パスでエクスプローラーから直結
ネットワーク統合	別IPアドレス（ルーティング設定が必要）	localhost でWindowsブラウザから即アクセス

③ Docker Desktop と WSL2 バックエンドの連携メカニズム

Windows版Docker Desktopをインストールすると、裏側でWSL2専用のディストリビューション（docker-desktop / docker-desktop-data）が自動構成されます。

▲ 【図解②】Windows側操作ツール（GUI/VS Code）とWSL2内Dockerエンジンのシームレス連携構造

このアーキテクチャの最大の利点は、「Windowsの使い慣れた開発ツールと、Linuxの本物のコンテナ実行環境が完全に融合すること」です。

• PowerShell / コマンドプロンプトから直接操作: Windows側のターミナルで docker run や docker compose を叩くと、名前付きパイプを通じてWSL2内のDockerデーモンへ瞬時に転送されます。
• Visual Studio 2022 / VS Code連携: Windows上のIDEからWSL2内のコンテナに対してブレークポイントを張り、ステップ実行や変数ウォッチをシームレスに行えます。
• GUIダッシュボードによる可視化: タスクトレイのDocker Desktop GUIから、稼働中のコンテナ一覧、CPU/メモリ使用量、ログ確認がワンクリックで可能です。

④ 【最重要】WindowsとLinuxのファイルシステム境界（パフォーマンスの罠）

WSL2環境で開発を行う際、99%のエンジニアが最初にハマる最大の落とし穴が「ファイル配置場所」です。

▲ 【図解③】Windows領域（C:）とWSL2 Linux領域のファイルI/O速度差とGitリポジトリ最適配置

WSL2では、WindowsのCドライブ（C:\Users\...）がLinux側から /mnt/c/Users/... として参照できます。
しかし、Windows領域のファイルをLinuxカーネル（Dockerコンテナ）から読み書きする際は、内部で9Pプロトコル変換が走るため、ディスクI/O速度が著しく低下します。

⚠️ なぜCドライブ配下でDockerを動かしてはいけないのか？

Cドライブ上にGitリポジトリを置き、それを -v C:\MyProject:/app のようにDockerにマウントすると、C#の dotnet build や npm install のファイルアクセスが 5倍〜10倍以上遅く なります。
また、ファイルの変更監視（File Watcher）イベントが正常に伝わらず、ホットリロードが効かなくなる原因にもなります。

✅ 現場の鉄則：ソースコードはWSL2のLinux領域に配置する！

Gitリポジトリは、必ずWSL2内のLinuxネイティブ領域（/home/ユーザー名/projects/...）に git clone してください。
EXT4ファイルシステム本来の爆速I/O性能が発揮され、ビルドもコンテナ起動も一瞬で完了します。Windowsのエクスプローラーからも \\wsl$\Ubuntu\home\... で直接アクセス可能です！

⑤ Docker Desktop ＋ WSL2 の安全な導入手順（3ステップ）

それでは、Windows 11にWSL2とDocker Desktopを導入する最短かつ最も安全な手順を見ていきましょう。

▲ 【図解④】コマンド一発で完了！Docker Desktop ＋ WSL2 導入の3ステップワークフロー

Step 1: WSL2のインストール（管理者PowerShell）

Windows TerminalまたはPowerShellを「管理者として実行」で開き、以下のコマンドを1行実行するだけです。

# WSL2およびデフォルトのUbuntuディストリビューションを一括インストール
wsl --install

# 既にWSLがインストール済みの場合は最新版へアップデート
wsl --update

※ インストール完了後、画面の指示に従ってPCを一度再起動してください。

Step 2: Docker Desktop for Windows のインストール

1. Docker公式サイト（docker.com）からインストーラー（Docker Desktop Installer.exe）をダウンロードします。
2. インストーラーを起動し、オプション画面で「Use WSL 2 instead of Hyper-V（recommended）」に必ずチェックが入っていることを確認して進めます。
3. インストール完了後、Windowsからサインアウト（または再起動）し、スタートメニューから「Docker Desktop」を起動します。

Step 3: 動作検証（Hello Worldコンテナの実行）

PowerShellを開き、以下のコマンドを叩いて動作を確認します。

# 1. DockerのバージョンとWSL2連携を確認
docker version

# 2. テスト用コンテナを起動（公式イメージ取得＆実行）
docker run hello-world

ターミナルに Hello from Docker! This message shows that your installation appears to be working correctly. と表示されれば環境構築は100%大成功です！

⑥ C# / .NET 現場での実践アプローチ

Windows 11上の開発で日常的に使用する診断コマンドと、AIエージェントへの環境構築プロンプトを確認しましょう。

[A] WSL2・Docker状態確認コマンド集（PowerShell）

# 1. インストール済みWSLディストリビューションと稼働状態（VERSIONが2であることを確認）
wsl --list --verbose

# 2. Dockerデーモンの詳細情報（OS/Arch: linux/amd64 であることを確認）
docker info

# 3. 動作中のWSL2インスタンスを強制停止してメモリを解放する場合
wsl --shutdown

[B] 4大AIエージェントへの指示プロンプト例

🤖 Antigravity / Claude Code への指示プロンプト:

「Windows 11上のWSL2（Ubuntu）環境で、ASP.NET Core Web APIとSQL Serverコンテナを開発するためのディレクトリ構成と、高速I/Oを維持するためのGit配置ルールをまとめた開発環境セットアップ手順書を作成してください。」

⚠️ 30年選手がハマりやすい現場の落とし穴

「WSL2のVmmemプロセスがWindowsのメモリを食い尽くしてしまう現象」
WSL2は初期設定のままだと、ホストPCに搭載されている物理メモリの最大50%〜80%まで自動的にキャッシュとして確保してしまいます。
その結果、「タスクマネージャーを見ると Vmmem というプロセスが16GB中12GBも使っていてWindowsが重い！」という事態に陥りがちです。
これを防ぐには、ユーザーホームディレクトリに .wslconfig ファイルを作成してメモリ上限（例: 4GB〜6GB）を設定するのが現場の鉄則です（次回のDay 07で完全設定法を伝授します！）。

📌 本日のまとめ ＆ 明日へのステップ

• WSL2は超軽量Linux統合環境: 秒速起動・動的リソース共有により、Windows上で本物のLinuxコンテナが高速動作する。
• Docker Desktop ＋ WSL2バックエンド: Windowsの操作性とLinuxエンジンの実行性能を完璧に融合する。
• GitリポジトリはWSL2領域に配置する: Cドライブ直下を避け、/home/username/... に配置して爆速I/Oを維持する。

次回【Day 07】予告:
『Docker Desktopの推奨設定（WSL2バックエンド・リソース割り当て）』〜.wslconfigでPCを軽くする黄金チューニング〜