Dockerマルチステージビルド完全ガイド｜イメージサイズを1/10に削減する実践テクニック

「Goの静的バイナリなのに、なぜイメージが1GBもあるの？」「Node.jsアプリのビルドに必要なgccやpython3が本番イメージに残っている」——こうした問題の解決策が マルチステージビルドです。

マルチステージビルドを使うと、ビルド用と実行用のステージを分離でき、本番イメージに必要なものだけを残せます。Go なら 900MB → 15MB、Node.js なら 1.2GB → 150MB といった劇的な削減が可能です。この記事では仕組みから実践パターンまで徹底解説します。

目次

1. なぜマルチステージビルドが必要か
2. 基本構文：FROM … AS … と COPY –from
3. 実践① Goアプリ（900MB→15MB）
4. 実践② Node.jsアプリ（1.2GB→180MB）
5. 実践③ Pythonアプリ
6. ステージの命名と参照テクニック
7. ビルドターゲット（–target）で途中ステージを取り出す
8. 外部イメージからの COPY --from
9. マルチステージの落とし穴
10. まとめ

1. なぜマルチステージビルドが必要か

アプリの ビルド時と 実行時で必要なツールは違います。

シングルステージで書くと、この 両方が最終イメージに混ざります。結果、イメージは肥大化し、セキュリティリスク（攻撃者が利用できるツールが残る）も増えます。

マルチステージの発想

「ビルド作業は別の大きなイメージで行い、完成品だけをスリムなイメージにコピーする」——これがマルチステージビルドの本質です。

2. 基本構文：FROM … AS … と COPY –from

マルチステージビルドは、1つのDockerfileに複数の FROM を書くだけで実現できます。

# Stage 1: ビルダー（名前を "builder" と付ける）
 FROM golang:1.22-alpine AS builder
 WORKDIR /src
 COPY . .
 RUN go build -o /bin/app
 
 # Stage 2: 本番（最終イメージになる）
 FROM alpine:3.19
 COPY --from=builder /bin/app /usr/local/bin/app
 CMD ["app"]

ポイントは2つ：

• FROM <image> AS <name>：ステージに名前を付ける
• COPY --from=<name> <src> <dst>：別ステージからファイルをコピー

3. 実践① Goアプリ（900MB→15MB）

Goは静的バイナリにコンパイルできる言語のため、マルチステージの効果が最も劇的です。

シングルステージ版（悪い例）

FROM golang:1.22
 WORKDIR /app
 COPY . .
 RUN go build -o /app/server
 CMD ["/app/server"]
 
 # サイズ: 約 900MB（Go toolchain 全部含む）

マルチステージ版（良い例）

# syntax=docker/dockerfile:1.4
 
 # ===== ビルドステージ =====
 FROM golang:1.22-alpine AS builder
 WORKDIR /src
 
 # 依存ダウンロード（レイヤーキャッシュ活用）
 COPY go.mod go.sum ./
 RUN go mod download
 
 # ソースコピー＆静的ビルド
 COPY . .
 RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /bin/server
 
 # ===== 実行ステージ =====
 FROM alpine:3.19
 RUN apk add --no-cache ca-certificates
 COPY --from=builder /bin/server /usr/local/bin/server
 EXPOSE 8080
 CMD ["server"]
 
 # サイズ: 約 15MB（60分の1）

4. 実践② Node.jsアプリ（1.2GB→180MB）

Node.js は実行時にもランタイムが必要ですが、devDependencies（TypeScript・webpack・テストツール）を本番から除外できます。

# ===== ビルドステージ =====
 FROM node:20-alpine AS builder
 WORKDIR /app
 
 # devDependencies も含めてインストール（ビルドに必要）
 COPY package.json package-lock.json ./
 RUN npm ci
 
 # ソースコピー＆ビルド（TypeScript → JS 変換など）
 COPY . .
 RUN npm run build
 
 # ===== 本番依存ステージ =====
 FROM node:20-alpine AS deps
 WORKDIR /app
 COPY package.json package-lock.json ./
 RUN npm ci --omit=dev
 
 # ===== 実行ステージ =====
 FROM node:20-alpine
 WORKDIR /app
 # ビルド成果物（dist）と本番依存のみコピー
 COPY --from=builder /app/dist ./dist
 COPY --from=deps /app/node_modules ./node_modules
 COPY package.json ./
 EXPOSE 3000
 CMD ["node", "dist/server.js"]
 
 # サイズ: 約 180MB（1.2GB → 1/7）

このパターンでは 3つのステージを使っています：

• builder：TypeScript/webpackのビルド（devDep使用）
• deps：本番用依存のみを別ステージでインストール
• 最終：dist と node_modules（本番版）だけ持ってくる

5. 実践③ Pythonアプリ

Pythonはコンパイル不要ですが、gccを要求するパッケージ（numpy、psycopg2等）をビルドする場面で効果があります。

# ===== ビルドステージ =====
 FROM python:3.12-slim AS builder
 WORKDIR /app
 
 # gcc などのビルドツールをインストール
 RUN apt-get update && apt-get install -y --no-install-recommends \
  gcc \
  libpq-dev \
  && rm -rf /var/lib/apt/lists/*
 
 COPY requirements.txt .
 # wheel を作って /wheels に出力
 RUN pip wheel --no-cache-dir --wheel-dir /wheels -r requirements.txt
 
 # ===== 実行ステージ =====
 FROM python:3.12-slim
 WORKDIR /app
 
 # 実行に必要な最小限のライブラリ
 RUN apt-get update && apt-get install -y --no-install-recommends \
  libpq5 \
  && rm -rf /var/lib/apt/lists/*
 
 # ビルド済み wheel を使ってインストール（gcc 不要）
 COPY --from=builder /wheels /wheels
 RUN pip install --no-cache-dir /wheels/*
 
 COPY . .
 CMD ["python", "app.py"]

ビルドステージで pip wheel を使い、コンパイル済みの .whl ファイルを生成 → 実行ステージでは gcc 不要でインストール、という戦略です。最終イメージから gcc・libpq-dev（開発用ヘッダ）が除外されます。

6. ステージの命名と参照テクニック

ステージは何個でも書ける

FROM node:20 AS frontend-builder
 # フロントエンド（React）ビルド
 RUN npm run build
 
 FROM golang:1.22 AS backend-builder
 # バックエンド（Go）ビルド
 RUN go build -o /api
 
 FROM alpine:3.19 AS runtime
 COPY --from=frontend-builder /app/dist /www
 COPY --from=backend-builder /api /usr/local/bin/
 # フロント・バックを1つのイメージにまとめる

前のステージを相対参照できる

ステージ名を付け忘れた場合、番号（0, 1, 2…）で参照できます。

FROM golang:1.22
 RUN go build -o /app
 
 FROM alpine
 COPY --from=0 /app /app # ステージ0を参照
 # ただし名前を付けた方が可読性が高い

7. ビルドターゲット（–target）で途中ステージを取り出す

docker build --target <stage> で、任意のステージまでビルドして終了できます。開発環境・テスト環境・本番環境を1つのDockerfileで管理できる強力な機能です。

# ===== 共通ベース =====
 FROM node:20-alpine AS base
 WORKDIR /app
 COPY package.json package-lock.json ./
 RUN npm ci
 
 # ===== 開発（ホットリロード対応）=====
 FROM base AS development
 COPY . .
 CMD ["npm", "run", "dev"]
 
 # ===== テスト（テスト実行して失敗したらビルド停止）=====
 FROM base AS test
 COPY . .
 RUN npm run lint && npm run test
 
 # ===== 本番（最適化ビルド）=====
 FROM base AS production
 COPY . .
 RUN npm run build && npm prune --omit=dev
 CMD ["node", "dist/server.js"]

# 開発環境でビルド
 docker build --target development -t myapp:dev .
 
 # テストだけ実行（失敗したら exit 1）
 docker build --target test -t myapp:test .
 
 # 本番ビルド（省略時は最後のステージ）
 docker build --target production -t myapp:prod .
 # または
 docker build -t myapp:prod .

8. 外部イメージからの COPY --from

COPY --from の参照先は、Dockerfile 内のステージだけでなく 既存のイメージ名も指定できます。

FROM alpine:3.19
 
 # 公式 nginx イメージからバイナリを拝借
 COPY --from=nginx:1.25-alpine /usr/sbin/nginx /usr/sbin/nginx
 COPY --from=nginx:1.25-alpine /etc/nginx /etc/nginx
 
 # Go のバイナリを外部ビルド済みイメージから持ってくる例
 COPY --from=registry.example.com/go-builder:v1.0 /bin/app /usr/local/bin/

これは ビルドキャッシュを別リポジトリで管理したい時や、公式イメージのビルド済みバイナリを使い回したい時に便利です。

9. マルチステージの落とし穴

10. まとめ

マルチステージビルドは、「ビルドと実行を分離する」というシンプルな発想ですが、その効果はイメージサイズ・セキュリティ・CI効率すべてに及ぶ、本番運用の必須テクニックです。

参考リンク

• Multi-stage builds（Docker公式） — マルチステージビルドの公式仕様と使用例。
• Dockerfile best practices — マルチステージを含むDockerfile全般のベストプラクティス。
• scratch イメージ — Goの静的バイナリを載せる最小イメージ（0バイト）。

Dockerの基礎を動画で体系的に学びませんか？

実務で使う基礎だけを3時間に凝縮。環境構築から丁寧に解説しています。

クーポン割引で講座を見る →