Docker イメージ軽量化 & セキュリティ最適化：マルチステージビルド完全ガイド
Docker イメージ、思ったより太っていませんか？
その原因の大半は 「ビルド環境と実行環境をごっちゃにした構成」 にあります。この記事では、マルチステージビルドと Distroless を使って、イメージを 90% 以上削減し、セキュリティと速度を同時に底上げする方法を徹底的に解説します。
さらに、以下の改善ポイントも盛り込みました：
- Node.js / Python など 他言語のキャッシュ最適化パターン
- マルチプラットフォームビルド（ARM/AMD） の注意点
- Distroless の 種類と適切な選び方
- セキュリティで重要性が増す SBOM（ソフトウェア部品表） との関係
目次
- なぜ Docker イメージは肥大化するのか？
- 解決策：マルチステージビルド
- よく使う言語別：最適な Dockerfile パターン
- さらに軽量 & セキュアに：Distroless
- マルチプラットフォームビルド（ARM/AMD）注意点
- セキュリティ強化：SBOM を活用する
- まとめ & 明日からのアクション
1. なぜ Docker イメージは肥大化するのか？
■ 原因：ビルド環境と実行環境をごっちゃにする
典型的な初期の Dockerfile：
FROM golang:1.23
WORKDIR /app
COPY . .
RUN go build -o main .
CMD ["./main"]
必要なのはバイナリだけなのに、コンパイラや開発ツールが全部入ってしまいます。
→ 結果、イメージが 900MB 以上の“メタボ”に。
2. 解決策：マルチステージビルド
マルチステージビルドは、ビルド用の巨大な環境と実行に必要な最低限の環境を分離する技法です。
■ Go の最適化例
# Build
FROM golang:1.23 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o main .
# Run
FROM alpine:3.19
WORKDIR /app
COPY --from=builder /app/main .
CMD ["./main"]
効果
| 項目 | Before | After |
|---|---|---|
| イメージサイズ | 約 900MB | 15〜20MB |
| セキュリティ | 低い | 不要ツールが消えて向上 |
| CI/CD ビルド速度 | 遅い | 高速化 |
3. 言語別：マルチステージ最適パターン
■ Node.js
FROM node:20 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
FROM node:20-slim
WORKDIR /app
COPY --from=builder /app/dist ./
COPY package*.json ./
RUN npm ci --omit=dev
CMD ["node", "dist/main.js"]
→ 依存キャッシュを最大活用し、最終イメージを 50% 以上削減。
■ Python
FROM python:3.12 AS builder
WORKDIR /app
COPY requirements.txt ./
RUN pip wheel --wheel-dir /wheelhouse -r requirements.txt
COPY . .
FROM python:3.12-slim
WORKDIR /app
COPY --from=builder /wheelhouse /wheelhouse
RUN pip install --no-cache-dir /wheelhouse/*
COPY . .
CMD ["python", "main.py"]
■ Java（JAR）
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /app
COPY pom.xml .
RUN mvn -q dependency:resolve
COPY . .
RUN mvn -q package
FROM eclipse-temurin:17-jre
WORKDIR /app
COPY --from=builder /app/target/app.jar ./
CMD ["java", "-jar", "app.jar"]
4. さらに軽量化 & セキュリティ：Distroless
Distroless の種類
-
static（最軽量） -
base（glibc ベース） -
base-nonroot（非 root 実行） - 言語特化：
nodejs,python,javaなど
Distroless のメリット
- シェルなし → 攻撃面が極小
- パッケージなし → 脆弱性の混入が少ない
- 本番環境に最適
デメリット
-
docker exec -it shができない - デバッグ性は低め
→ 対策：ステージング環境は Alpine、
本番だけ Distroless のハイブリッド運用が最強。
5. マルチプラットフォームビルド（ARM/AMD）注意点
Mac（ARM）で開発し、Linux サーバ（AMD）で動かす場合：
docker buildx build --platform=linux/amd64 .
注意：QEMU エミュレーションは遅い
- ビルドに数倍の時間がかかる場合あり
- CI/CD の実行ランナーを amd64 に固定すると改善される
実践策
- BuildKit + buildx を常に有効化
- クロスコンパイル対応言語（Go）は GOARCH を利用
6. セキュリティ強化：SBOM の活用
SBOM（Software Bill of Materials）は コンテナ内のすべての依存ライブラリを一覧化した台帳。
→ 脆弱性 CVE の影響範囲を即時判定できる。
Syft などのツール例
syft myimage:latest -o json > sbom.json
マルチステージにより、イメージが小さくなる → SBOM も読みやすくなり、セキュリティ監査もしやすくなる。
7. まとめ & 明日からできるアクション
マルチステージビルドは必須。
軽量化・セキュリティ・ビルド速度のすべてが向上します。
🔜 明日からできる改善チェックリスト
-
AS builderとCOPY --from=を導入 -
.dockerignoreを整備しビルド時間短縮 - BuildKit を有効化
- 本番は Distroless、開発は Alpine
- SBOM（Syft）を生成して依存の見える化
あなたの Docker イメージは、もっと軽く、もっと安全にできます！