WindowsのDockerビルドが遅い原因はWSL外のファイル配置だった｜8分→3分台に改善した話

同じSvelteKitプロジェクトをビルドしているのに、MacBook Air M1では3分台、WindowsのDocker環境では8分程度かかっていました。

Windows機のスペックは、AMD Ryzen 9 8945HS、メモリ96GB。MacBook Air M1はメモリ16GBです。単純なスペックだけを見るとWindowsのほうが圧倒的に強そうですが、実際にはMacのほうがかなり速いという結果になりました。

この記事では、コマンドプロンプト・PowerShell・WSLの違いから、 そもそもなぜWindows Dockerでビルドが遅くなりやすいのか （ここが一番のポイントです）、そしてWSL2を使ったDocker開発環境の作り方までを、順を追って整理します。

まず、今回比較した環境です。単純なマシンスペックだけで見ると、Windows機のほうがかなり余裕があります。

対象プロジェクトは、SvelteKit / Vite / Tailwind CSS v4 / TypeScript / Bun / Docker Compose を使った構成です。Vite や Tailwind CSS のビルドは「細かいファイルを大量に読み書きする」処理が多いため、ファイルシステムの差がビルド時間にそのまま出やすい構成でした。後述しますが、この「大量の細かいファイルアクセス」が今回のボトルネックの正体です。

Windowsで開発環境を作ると、コマンドプロンプト、PowerShell、WSLという似たような入口が出てきます。「なぜ遅いのか」を理解する土台になるので、まずはそれぞれの役割を整理します。

変更前は、Windows側のファイルシステム（C:\Users\... ）にプロジェクトを置いた状態でDockerビルドをしていました。図にすると、こういう流れです。

WSLを使うだけでは不十分 です。重要なのは、プロジェクトの実体を/home/ユーザー名 配下、つまり前述のLinux側ファイルシステムに置くことです。

$ pwd

# 🔴 これだと実体はWindows側（遅い）
/mnt/c/Users/[user_name]/projects/[project_name]

# 🟢 これならLinux側（速い）
/home/[user_name]/projects/[project_name]

WSLをまだ使っていない場合は、PowerShellを管理者で開いてインストールします。

PS> wsl --install

ディストリビューションを明示してインストールする場合は、以下のように実行します（既定でもUbuntuが入ります）。

PS> wsl --install -d Ubuntu

PS> wsl -l -v
  NAME      STATE           VERSION
* Ubuntu    Stopped         2

VERSION が2 になっていることを確認してください。1 の場合はwsl --set-version Ubuntu 2 で2に変換できます（WSL2でこそファイルI/Oの恩恵が得られます）。

PS> wsl --set-default Ubuntu

WSLを完全停止したい場合は、以下を使います（設定変更後の反映や、調子が悪いときの再起動に便利です）。

PS> wsl --shutdown

Ubuntuへログインしたら、まずユーザー名と現在位置を確認します。

$ whoami
<user_name>

$ cd ~
$ pwd
/home/<user_name>

ここが/home/<user_name> になっていればOKです。この配下にプロジェクトを置きます。

$ cd ~
$ mkdir -p projects
$ cd projects

Docker Desktopを使う場合は、WSL2 backendとWSL Integrationを有効にします。

WSL内で以下を実行し、Dockerコマンドが使えることを確認します。

$ docker version
$ docker compose version

Gitリポジトリから取得する場合は、 WSL内の~/projects 配下で cloneします。Windows側でcloneしてWSLから参照する、という遠回りは避けてください。

$ cd ~/projects
$ git clone <repository-url> <project_name>
$ cd <project_name>

VSCodeで開く場合は、WSL内のプロジェクトディレクトリからcode . を実行します。

$ cd ~/projects/<project_name>
$ code .

プロジェクトディレクトリにdocker-compose.yml がある場合は、そのディレクトリでDocker Composeを実行します。

$ cd ~/projects/<project_name>
$ docker compose up -d --build

ログを見る場合は以下です。

$ docker compose logs -f

コンテナに入る場合は、サービス名を指定します。

$ docker compose exec app bash

# bashがないイメージの場合
$ docker compose exec app sh

開発時はソースコードをコンテナへbind mountします。ただし、node_modules や.svelte-kit のようにファイル数が多いディレクトリは、 named volumeに逃がす と安定しやすくなります。ホスト側のファイルでコンテナ内の生成物を上書きしてしまう事故も防げます。

services:
  app:
    build:
      context: .
    working_dir: /app/<project_name>
    volumes:
      - .:/app/<project_name>
      - node_modules:/app/<project_name>/node_modules      # ← named volumeへ
      - sveltekit_cache:/app/<project_name>/.svelte-kit    # ← named volumeへ
    ports:
      - "5160:5160"
    command: bun run dev

volumes:
  node_modules:
  sveltekit_cache:

SvelteKit / Viteでブラウザからアクセスする場合は、dev serverを コンテナの外から見えるように--host 0.0.0.0 を付けます。さらに、上のdocker-compose.yml で公開しているポート（ここでは5160 ）と一致するよう--port も明示しておくと、ポートのズレによる「つながらない」を防げます。

{
  "scripts": {
    "dev": "vite dev --host 0.0.0.0 --port 5160 --mode dev"
  }
}

Windows側のブラウザからは、通常どおり以下でアクセスできます。

http://localhost:5160

開発中はbind mountでホットリロードを使うのが便利です。一方、ステージング・本番用のビルド資材を作るときは、Dockerfileのbuilder stageでCOPY . . してビルドする構成に寄せると、環境差分を減らしやすくなります。bind mountに依存しない分、CI/CDサーバーなど手元と違う環境でも結果がブレにくくなります。

FROM oven/bun:latest AS builder

WORKDIR /app/<project_name>

# 依存だけ先にコピー → install をキャッシュに乗せる
COPY package.json bun.lock ./
RUN bun install --frozen-lockfile

# 残りのソースをコピーしてビルド
COPY . .
RUN bun run build:staging