Dockerfile 最適化実践：5 つのテクニックでイメージを 80% スリム化

ターミナルのプログレスバーが「Pushing to registry」のまま、30 分止まったまま。

3.2GB。

初めて作った Node.js アプリの Docker イメージは、ネットのチュートリアル通りに Dockerfile を書いたはずなのに、想定外のサイズに膨らんでいました。翌朝、同僚から Slack で「そのイメージ、OS 丸ごとパッケージしてない？ ノート PC のディスクがもう一杯なんだけど」と突っ込まれました。

Ubuntu のベースイメージ？ node_modules？ それともビルドツール？ 原因はともかく、シンプルな API サービスなのに、イメージがプロジェクトコードの 50 倍も大きい。Docker 公式ドキュメントとベストプラクティスを調べ、この 3.2GB の怪物を 180MB まで落としました。94% 削減です。

この記事では、軽量化の過程で特に効いた 5 つのテクニックを紹介します。手順だけでなく「なぜ効くのか」も説明します。コマンドの暗記より、原理の理解のほうが応用に効きます。

先に理解する：Docker イメージが巨大になる理由

テクニックの前に、問題の根源を押さえましょう。

Docker イメージはレイヤー構造です。RUN、COPY、ADD のたびに新しいファイルシステム層が積み重なります。重要なのは、各層は追加されるだけで、中身は削除されない という点です。

たとえば Dockerfile にこう書いたとします：

RUN apt-get update
RUN apt-get install -y build-essential
RUN rm -rf /var/lib/apt/lists/*

一見、最後の行で apt キャッシュを消しています。しかしキャッシュはすでに第 2 層に永久保存されています。第 3 層は「これらのファイルは削除された」という印だけで、データはイメージ内に残ったままです。

部屋の整理のたびに「ゴミがある状態」の写真を撮り、最後にゴミを捨てても、ゴミ入りの写真はアルバム（イメージ）に残る——少しおかしいですが、Docker の CoW（写時コピー）はそう動きます。

未最適化のイメージで docker history を見ると、層の合計サイズが実際に必要なファイルをはるかに上回ることがよくあります。

見落としがちなのがベースイメージです。ubuntu:20.04 だけで 72MB、node:16 は 1.09GB——Debian フルセットと、使わないかもしれないシステムツールが入っています。

整理すると、最適化の方針は 3 つです。レイヤー数を減らす、軽いベースイメージを選ぶ、インストールと掃除を同じ層で完結させる。

テクニック 1：ベースイメージ選びでスタートダッシュ

ベースイメージは、家づくりの立地選びに近いです。最初の選択がサイズの下限を決めます。

数字で比較すると：

• node:16 → 1.09GB
• node:16-slim → 240MB
• node:16-alpine → 174MB
• alpine:latest → 5.6MB

差は歴然です。node:16 から node:16-alpine に変えただけで、コードを 1 行も変えず 1.2GB から 400MB まで落ちました。

Alpine Linux とは？

コンテナ向けに設計された Linux ディストリビューションです。極小構成で、musl libc と apk パッケージマネージャを使います。

利点は明確です：

• 体積が小さい（5MB vs Ubuntu 72MB）
• セキュリティ（攻撃面の最小化）
• 起動が速い

ただし落とし穴もあります。

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

Alpine の互換性トラップ

musl libc のため、一部のプリビルドバイナリが動きません。C++ 製の Node.js ネイティブモジュールで「library not found」が出たことがあります。原因は libc の違いでした。

現実的な方針は次のとおりです：

1. まず Alpine 系（-alpine）を試す
2. 互換性問題があれば -slim（Debian 精量版）
3. それでもダメなら標準イメージ（かなり稀）

変更は 1 行です：

# 最適化前
FROM node:16

# 最適化後
FROM node:16-alpine

これだけで約 800MB 節約できます。

効果の確認

ビルド後に実行：

docker images your-image-name

SIZE 列を確認。まだ大きければ、ベースイメージ以外にも原因があります。

テクニック 2：RUN 命令を統合してレイヤーを減らす

理解は簡単ですが、実装で見落とされがちです。

各 RUN が 1 層を作ります。削除は同じ層の中でしか効きません。

悪い例：

# 誤った例（3 層）
RUN apt-get update
RUN apt-get install -y python3 gcc
RUN rm -rf /var/lib/apt/lists/*

apt キャッシュ（数十 MB）が第 2 層に残り、第 3 層の削除は「見えなくする」だけです。

正しい例：

# 正しい例（1 層）
RUN apt-get update && \
    apt-get install -y python3 gcc && \
    rm -rf /var/lib/apt/lists/*

インストールと掃除が同じ層で完結し、削除が実削除になります。

バックスラッシュ \ の役割

長いコマンドを複数行に分け、読みやすくします。

何を統合すべきか

すべてをまとめる必要はありません。目安は次のとおりです。

• 統合する：インストール + 掃除、ダウンロード + 解凍 + 圧縮ファイル削除
• 分ける：論理的に無関係な処理、よく変わるステップ（ビルドキャッシュを壊すため）

例：

# 良い層分け
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*
RUN npm install
RUN npm run build

システム依存は 1 層、package.json が変わる npm install は別層、ビルドも別層。package.json 変更時に前半がキャッシュされます。

実測では、12 個の RUN を 4 個にまとめ、520MB から 320MB まで縮みました。

テクニック 3：マルチステージビルド——必要なものだけ持っていく

マルチステージビルド（Multi-stage Build）は、Docker イメージを瘦せさせる最強の手段です。

考え方はシンプル。ビルドと実行を分ける。

Go でコンパイルするにはツールチェーンが数百 MB 必要ですが、バイナリは 10MB かもしれません。ツールチェーンまで本番イメージに入れるのは無駄です。

1 つの Dockerfile で複数ステージを定義し、第 1 ステージでビルド、第 2 ステージには成果物だけコピーします。

Node.js の例：

# === ビルドステージ ===
FROM node:16-alpine AS builder
WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .
RUN npm run build

# === 実行ステージ ===
FROM node:16-alpine
WORKDIR /app

COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY package*.json ./

EXPOSE 3000
CMD ["node", "dist/index.js"]

COPY --from=builder がポイントです。第 1 ステージの中間成果物は捨てられ、第 2 ステージだけが最終イメージになります。

マルチステージを使う場面

1. コンパイル言語：Go、Rust、C++ など
2. フロントエンド：TypeScript コンパイル、Webpack バンドル
3. ビルドツールが必要な Python：gcc でネイティブ拡張をビルドするケースなど

TypeScript を JavaScript にするプロジェクトでは、ソース + node_modules の @types で 400MB、dist は 2MB。マルチステージで 220MB まで落ちました。

よくある落とし穴

KiloClaw - 企業向けマネージド OpenClaw、AI エージェントのオーケストレーションとスマートルーティングを加速

今すぐ始める →広告

実行ステージでも npm install して「依存は必要だから」と全部入れるのは避けてください。devDependencies まで入り、無駄に肥大化します。

正しくは、ビルドステージで npm install（コンパイル用に dev 依存込み）し、node_modules をコピーするか、より精密には：

# ビルドステージ
RUN npm install

# 実行ステージ
RUN npm install --production

本番依存だけにすると、さらに 30〜40% 軽くなります。

最初は少し複雑に感じますが、理解すると設計の美しさがわかります。旅行の荷造り——家（ビルド）では全部広げて整理し、飛行機（実行）にはスーツケースの必需品だけ。

テクニック 4：.dockerignore で不要ファイルを除外

.dockerignore は .gitignore の Docker 版ですが、見落とされがちです。

COPY . . では、ディレクトリ全体がビルドコンテキストとして daemon に送られます。数百 MB の node_modules、.git 履歴、テスト、ログまで送られると、ビルドが遅く、.env のような秘密まで混入する危険があります。

プロジェクトルートに .dockerignore を置きます。

# .dockerignore
node_modules
npm-debug.log
.git
.gitignore
.env
.env.local
README.md
.vscode
.idea
*.md
.DS_Store
coverage/
.pytest_cache/
__pycache__/
*.pyc
dist-local/

入れるべきもの

1. 既存の依存ディレクトリ：node_modules、vendor、target など（ビルドで再インストールする）
2. 開発ツール設定：.vscode、.idea、.editorconfig
3. Git 関連：.git、.gitignore（.git は数十〜数百 MB になり得る）
4. ドキュメント：README、CHANGELOG、docs/
5. 機密情報：.env、credentials.json、*.pem

.git を入れ忘れたプロジェクトでは、毎回 500MB の履歴を転送していました。.dockerignore 追加後、ビルドは 2 分から 30 秒、イメージも小さくなりました。

実用テクニック

何がコピーされたか不安なら、一度ビルドしてコンテナ内を確認：

docker run --rm -it your-image sh
ls -lah

不要なファイルがあれば .dockerignore に追加します。

シンプルに見えますが、特にフロントエンドでは dist、node_modules、.cache だけで GB 級になることもあります。

テクニック 5：パッケージマネージャのキャッシュを削除

npm、pip、apt、apk はインストール後にキャッシュを残します。ローカル開発では次回が速くなりますが、Docker イメージではただのデッドウェイトです。

同じ RUN 内で削除する

もう一度強調します。削除はインストールと同じ層で。

# ❌ 効かない削除
RUN apt-get update
RUN apt-get install -y curl
RUN rm -rf /var/lib/apt/lists/*  # ほぼ無意味

# ✅ 効く削除
RUN apt-get update && \
    apt-get install -y curl && \
    rm -rf /var/lib/apt/lists/*

ツール別の掃除方法：

Node.js (npm/yarn)

# npm - 従来
RUN npm install && \
    npm cache clean --force

# npm - シンプル（キャッシュ無効）
RUN npm install --no-cache

# yarn
RUN yarn install && \
    yarn cache clean

Python (pip)

RUN pip install --no-cache-dir -r requirements.txt

RUN pip install -r requirements.txt && \
    rm -rf ~/.cache/pip

Alpine (apk)

RUN apk add --no-cache package-name

RUN apk add package-name && \
    rm -rf /var/cache/apk/*

Debian/Ubuntu (apt)

RUN apt-get update && \
    apt-get install -y package-name && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

実測

同じ Python 依存で：

• キャッシュ削除なし：450MB
• 削除あり：320MB
• --no-cache-dir：310MB（最もクリーン）

140MB の差。オプション 1 つです。

開発 vs 本番

本番イメージでは --production や --no-dev で必須パッケージだけに。dev 依存は全体の 30〜50% を占めることもあります。

RUN npm install --production

RUN pip install --no-cache-dir -r requirements-prod.txt

5 テクニックを組み合わせると、効果は足し算ではなく掛け算に近いです。3.2GB を 180MB にしたのも、すべてを適用した結果です。

完全事例：Node.js アプリの最適化の全過程

理論だけでなく、Express API サービスの Dockerfile がどう変わったかを追います。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

最適化前（1.2GB）

FROM node:16
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build
EXPOSE 3000
CMD ["node", "dist/index.js"]

単純ですが、イメージは巨大です。

第 1 段階：Alpine ベース（→ 400MB、-67%）

FROM node:16-alpine
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build
EXPOSE 3000
CMD ["node", "dist/index.js"]

1 行変更で 800MB 節約。

第 2 段階：.dockerignore（→ 380MB、-5%）

node_modules
.git
*.md
.env
coverage

見た目の削減は小さくても、ビルド速度は大きく改善。

第 3 段階：マルチステージ（→ 220MB、-42%）

FROM node:16-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

FROM node:16-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY package*.json ./
EXPOSE 3000
CMD ["node", "dist/index.js"]

ビルド中間ファイルを実行イメージから排除。効果最大のステップです。

第 4 段階：本番依存のみ + キャッシュ削除（→ 180MB、-18%）

FROM node:16-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

FROM node:16-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install --production --no-cache && \
    npm cache clean --force
COPY --from=builder /app/dist ./dist
EXPOSE 3000
CMD ["node", "dist/index.js"]

最終版 180MB。初期 1.2GB から 85% 削減。

最適化ロードマップ

1.2GB  (node:16 原版)
  ↓ Alpine に変更
400MB  (-67%)
  ↓ .dockerignore
380MB  (-5%)
  ↓ マルチステージ
220MB  (-42%)
  ↓ 本番依存 + キャッシュ削除
180MB  (-18%)
────────────────
合計 85% 削減

どのテクニックが効きやすいか

1. Alpine：即効性が高く、最初に試すべき
2. マルチステージ：効果最大だが学習コストあり
3. 本番依存 + キャッシュ削除：細部の積み上げ

時間が限られていれば、まず 1 と 2 を。

まとめ

5 つのテクニックを振り返ります：

1. Alpine ベースイメージ — 源流から小さくする
2. RUN の統合 — 同じ層でインストールと掃除
3. マルチステージビルド — 実行に必要なものだけ残す
4. .dockerignore — 不要・機密ファイルを除外
5. キャッシュ削除 — --no-cache 系オプションを活用

組み合わせが前提です。Alpine + マルチステージで 80% は解決し、残りは掃除と除外で詰められます。

今すぐ試す

問題が出てからではなく、既存プロジェクトで 5 つを試してください：

1. Alpine に替えられるか確認（多くは可能）
2. 分離したインストールと削除がないか見る（あれば統合）
3. マルチステージを追加（コンパイル系は必須）
4. .dockerignore を作る
5. パッケージマネージャに --no-cache を付ける

ビルド後に docker images で Before/After を比較してください。

さらに深く

• Docker BuildKit のキャッシュマウント
• Distroless イメージ（Google 製、Alpine より小さいことも）
• セキュリティスキャン（Trivy、Grype）

Dockerfile 最適化は一度きりではなく、ビルドのたびにサイズを見る習慣が効きます。

イメージがどんどん軽くなることを願っています。