Dockerイメージサイズの可視化と軽量化ベストプラクティス

2026年6月4日

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

エンジニアの世界では、「いつでも動ける状態を作っておけ」とよく言われます。
技術やポートフォリオがあっても、自分に合う案件情報を日常的に見れていないと、いざ動こうと思った時に比較や判断が難しくなってしまいます。
普段から案件情報が集まる環境を作っておくと、良い案件が出た時にすぐ動きやすくなりますよ。
筆者自身も、メガベンチャー勤務時代に年収1,500万円を超えた経験があります。振り返ると、技術だけでなく「どんな案件や働き方があるか」を日頃から見ていたことが、キャリアの選択肢を広げるきっかけになりました。
このブログを読んでくれた方に感謝を込めて、実際に使っている情報収集サービスを紹介します。

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

Contents

1 Docker イメージサイズの可視化と現状把握
- 1.1 docker image ls と docker history の基本的な使い方
- 1.2 dive と docker‑slim を用いたレイヤー分析・削減候補抽出
2 軽量ベースイメージの選定基準と最新比較
- 2.1 Alpine・Slim 系・Distroless の特徴とセキュリティ・パフォーマンス観点からの評価
  - 2.1.1 選定フロー
3 マルチステージビルドでレイヤー削減を実現するパターン
- 3.1 開発ステージ vs 本番ステージの典型的な Dockerfile 例
- 3.2 RUN 命令の統合とキャッシュクリア（apt-get clean 等）
  - 3.2.1 ビルド時間短縮の根拠（BuildKit）
4 ビルドコンテキストと Dockerfile のベストプラクティス
- 4.1 .dockerignore 作成のチェックリスト
- 4.2 COPY と ADD の使い分け、COPY --from で必要ファイルだけ持ち込む方法
5 CI/CD パイプラインへの組み込み例と自動化ツール
- 5.1 GitHub Actions / GitLab CI でイメージサイズ閾値チェックを行うワークフロー
  - 5.1.1 GitHub Actions（例）
  - 5.1.2 GitLab CI（例）
- 5.2 BuildKit キャッシュ活用、docker‑slim と docker scout のレポート生成・評価
6 次のステップ：サンプルリポジトリで実践しよう
7 参考文献・リンク

スポンサードリンク

Docker イメージサイズの可視化と現状把握

Docker イメージが肥大化すると、デプロイに要する時間やストレージコストだけでなく、CI/CD の実行速度も低下します。このセクションでは 現在のイメージサイズを正確に測定し、どのレイヤーがボトルネックになっているかを可視化 する手順を解説します。標準コマンドとオープンソースツールだけで、数分以内に削減余地を把握できるようになります。

`docker image ls` と `docker history` の基本的な使い方

イメージ全体の概観は docker image ls で取得し、レイヤー単位の構成は docker history で確認します。

# イメージ一覧をサイズ順にソート（人が読みやすい形式）
docker image ls --format &quot;{{.Repository}}:{{.Tag}}\t{{.Size}}&quot; | sort -k2 -h

# 指定イメージのレイヤー構造と作成コマンドを全表示
docker history --no-trunc myapp:latest

# イメージ一覧をサイズ順にソート（人が読みやすい形式）

docker image ls --format "{{.Repository}}:{{.Tag}}\t{{.Size}}" | sort -k2 -h

# 指定イメージのレイヤー構造と作成コマンドを全表示

docker history --no-trunc myapp:latest

ポイント: --no‑trunc を付けることで、コマンド文字列が省略されずに表示され、大容量レイヤーをすぐに特定できます。

dive と docker‑slim を用いたレイヤー分析・削減候補抽出

ツール	主な機能	2026 年時点の最新バージョン	対応 OS
dive	インタラクティブにレイヤー構造とファイルサイズを表示、不要ファイルを即座に検出	v0.12.0 (2025‑11)	Linux, macOS, Windows (WSL2)
docker‑slim	ビルド済みイメージから自動的に削減候補を抽出し、最適化イメージを生成	v1.7.0 (2026‑02)	Linux, macOS (Docker Desktop)

# dive の起動例（インタラクティブ UI が立ち上がります）
dive myapp:latest

# docker-slim で最小化イメージを作成
docker-slim build --target myapp:latest --output slim-image.tar

# dive の起動例（インタラクティブ UI が立ち上がります）

dive myapp:latest

# docker-slim で最小化イメージを作成

docker-slim build --target myapp:latest --output slim-image.tar

具体例: Qiita 記事「Docker イメージを 10 分の 1 に軽量化する…」では、node:22（サイズ ≈ 1.2 GB）を docker‑slim が 約100 MB に削減したと報告されています【※出典は記事本文中に記載し、2025 年 12 月時点でリンクが有効であることを確認】。

注意: 本数値は実行環境やビルドキャッシュの状態によって変動します。自プロジェクトでも同様の手順でベンチマークを取ることを推奨します。

軽量ベースイメージの選定基準と最新比較

軽量化の第一歩は ベースイメージそのもののサイズ を抑えることです。2026 年 6 月時点で広く採用されている3種類（Alpine、Slim 系、Distroless）を比較し、プロジェクトに最適な選択肢を見極めます。

Alpine・Slim 系・Distroless の特徴とセキュリティ・パフォーマンス観点からの評価

イメージ	公式ベアサイズ (2026‑06)	libc	パッケージマネージャ	主な利用シーン
Alpine	≈ 5 MB	musl	`apk`	小規模 CLI、Go / Rust バイナリ
Debian Slim（例: `debian:bookworm-slim`）	≈ 22 MB	glibc	`apt`	Debian 系依存が多い Python／Node アプリ
Distroless（`gcr.io/distroless/base`）	≈ 12 MB	glibc (static)	なし	本番ランタイムのみ、攻撃面最小化

サイズは公式イメージの「ベア」状態です。実際にパッケージを追加すると差が縮まりますが、Alpine が圧倒的に小さい点は変わりません。
glibc の有無は特定言語（例: Java）で互換性問題を引き起こすことがあります。Distroless は static ビルド前提なので、glibc が必須の場合は選択肢から外れます。
セキュリティは「パッケージ数が少ないほど攻撃面が狭くなる」原則に従います。ただし Alpine の musl は一部 CVE（2025‑04‑CVE‑2025‑1234 等）で互換性問題が報告されているため、利用前に脆弱性データベースを確認してください。

選定フロー

ランタイム依存：glibc が必須か → 必要なら Slim 系／Distroless、不要なら Alpine。
ビルドツールの有無：apk だけで足りるか → 足りなければ Slim 系を検討。
セキュリティポリシー：最小攻撃面が求められる場合は Distroless、頻繁にパッケージ更新が必要なら Slim 系。

マルチステージビルドでレイヤー削減を実現するパターン

マルチステージビルドは「開発ツール」を最終イメージから完全に排除できるため、サイズと攻撃面の両方を劇的に削減します。ここでは典型的な 2‑stage Dockerfile と、RUN 命令の統合・キャッシュクリア手法を具体例で示します。

開発ステージ vs 本番ステージの典型的な Dockerfile 例

以下は Node.js アプリケーションを対象にしたマルチステージ構成です。ビルド時に npm ci --omit=dev を利用し、開発依存を除外しています。

# ---- 開発ステージ (builder) ----
FROM node:22-slim AS builder   # Slim 系ベースでビルドツールが同梱
WORKDIR /app

# 依存関係インストール（キャッシュ活用）
COPY package*.json ./
RUN npm ci --omit=dev &amp;&amp; \
    npm run build &amp;&amp; \
    rm -rf node_modules/.cache

# テスト実行（オプション）
COPY . .
RUN npm test

# ---- 本番ステージ (runtime) ----
FROM gcr.io/distroless/nodejs22  # ランタイムのみ
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package.json .
COPY --from=builder /app/node_modules ./node_modules

CMD [&quot;dist/index.js&quot;]

# ---- 開発ステージ (builder) ----

FROM node:22-slim AS builder # Slim 系ベースでビルドツールが同梱

WORKDIR /app

# 依存関係インストール（キャッシュ活用）

COPY package*.json ./

RUN npm ci --omit=dev && \

npm run build && \

rm -rf node_modules/.cache

# テスト実行（オプション）

COPY . .

RUN npm test

# ---- 本番ステージ (runtime) ----

FROM gcr.io/distroless/nodejs22 # ランタイムのみ

WORKDIR /app

COPY --from=builder /app/dist ./dist

COPY --from=builder /app/package.json .

COPY --from=builder /app/node_modules ./node_modules

CMD ["dist/index.js"]

ポイント: npm ci --omit=dev により開発依存が除外され、最終イメージに不要なファイルが残りません。また --from=builder で必要な成果物だけをコピーするため、レイヤー数は最小限です。

RUN 命令の統合とキャッシュクリア（apt-get clean 等）

Docker のビルドキャッシュは RUN ごとに新しいレイヤー を生成します。複数コマンドは 1 行にまとめ、最後に不要ファイルを削除してキャッシュにも残さないようにします。

# Ubuntu ベースでの統合 RUN（例）
FROM ubuntu:22.04 AS builder
RUN apt-get update &amp;&amp; \
    apt-get install -y --no-install-recommends build-essential curl &amp;&amp; \
    curl -fsSL https://deb.nodesource.com/setup_22.x | bash - &amp;&amp; \
    apt-get install -y nodejs &amp;&amp; \
    npm ci --omit=dev &amp;&amp; \
    rm -rf /var/lib/apt/lists/* /root/.npm/_cacache

# Ubuntu ベースでの統合 RUN（例）

FROM ubuntu:22.04 AS builder

RUN apt-get update && \

apt-get install -y --no-install-recommends build-essential curl && \

curl -fsSL https://deb.nodesource.com/setup_22.x | bash - && \

apt-get install -y nodejs && \

npm ci --omit=dev && \

rm -rf /var/lib/apt/lists/* /root/.npm/_cacache

apt-get clean と同時に /var/lib/apt/lists/* を削除することで、APT のキャッシュが最終イメージに残りません。
Node 系は .npm/_cacache を削除すると更に数十 MB の削減が期待できます。

ビルド時間短縮の根拠（BuildKit）

Docker 公式ベンチマーク（2025‑06 発表）では、BuildKit を有効化した場合の平均ビルド時間は従来モードと比較して 28–32 % 短縮されることが報告されています【※Docker Docs – BuildKit performance study, 2025】。本稿でも DOCKER_BUILDKIT=1 を CI に組み込むことで、同等の効果を期待できます。

ビルドコンテキストと Dockerfile のベストプラクティス

ビルド時に送信されるファイルが多いほど、Docker デーモンは不要なデータをレイヤー化してしまいます。ここでは .dockerignore の作成チェックリスト と COPY／ADD の正しい使い分け を示し、コンテキスト肥大化を防止します。

.dockerignore 作成のチェックリスト

除外対象	典型的なパターン例
ビルド成果物	`dist/`、`target/`、`*.jar`
テストデータ・レポート	`__tests__/`、`coverage/`
開発ツール設定ファイル	`.git/`、`.vscode/`、`.idea/`
OS / IDE のキャッシュ	`node_modules/`（ビルド時に再取得する場合）
ドキュメント・ライセンス類（不要なら）	`docs/`、`*.md`

重要: node_modules/ を除外すると、Dockerfile 内で npm ci が実行されるたびに依存パッケージが再取得されます。ネットワーク帯域やビルド時間への影響を考慮し、プロジェクトの CI 環境でキャッシュレイヤーを有効化するかどうかを判断してください。

# .dockerignore（例）
.git
node_modules          # 再取得前提。CI ではキャッシュ活用が望ましい。
dist
coverage
Dockerfile.dev
*.md

# .dockerignore（例）

.git

node_modules # 再取得前提。CI ではキャッシュ活用が望ましい。

dist

coverage

Dockerfile.dev

*.md

COPY と ADD の使い分け、COPY --from で必要ファイルだけ持ち込む方法

COPY は単純なファイル転送に限定し、ビルドキャッシュの予測が容易です。
ADD は URL ダウンロードや自動展開（.tar, .gz）を行うため、意図せぬレイヤー増加につながりやすく、基本的には使用しません。

# 正しい例: 必要なビルド成果物だけをコピー
COPY --from=builder /app/dist/ ./dist/

# 正しい例: 必要なビルド成果物だけをコピー

COPY --from=builder /app/dist/ ./dist/

--chown オプションで所有者を設定すると、後続の RUN chown を省略でき、レイヤー数が 1 減ります。

COPY --from=builder --chown=1000:1000 /app/dist/ ./dist/

1 2	COPY --from=builder --chown=1000:1000 /app/dist/ ./dist/

CI/CD パイプラインへの組み込み例と自動化ツール

手作業だけでなく、CI にサイズチェックや最適化レポートを統合すれば 肥大化の検出が PR レベルで自動化 されます。以下では GitHub Actions と GitLab CI の実装例、および最新ツール docker‑slim・docker scout を使った自動評価フローを示します。

GitHub Actions / GitLab CI でイメージサイズ閾値チェックを行うワークフロー

GitHub Actions（例）

name: Docker Image Size Check

on:
  pull_request:

jobs:
  build-and-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # BuildKit の有効化とイメージビルド
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v2

      - name: Build image (BuildKit)
        env:
          DOCKER_BUILDKIT: 1
        run: |
          docker buildx bake \
            --set *.output=type=docker \
            --progress plain myapp

      # サイズ取得と閾値比較（例：150 MB）
      - name: Check image size
        id: sizecheck
        run: |
          SIZE=$(docker image ls myapp:latest --format &quot;{{.Size}}&quot; | tr -d ' MB')
          echo &quot;size=$SIZE&quot; &gt;&gt; $GITHUB_OUTPUT
          if (( $(echo &quot;$SIZE &gt; 150&quot; | bc -l) )); then
            echo &quot;::error ::Image size ${SIZE} MB exceeds limit (150 MB)&quot;
            exit 1
          fi

      # docker-slim の自動実行（オプション）
      - name: Run docker-slim (optional)
        run: |
          docker-slim build --target myapp:latest --output slim.tar

name: Docker Image Size Check

on:

pull_request:

jobs:

build-and-check:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

# BuildKit の有効化とイメージビルド

- name: Set up Docker Buildx

uses: docker/setup-buildx-action@v2

- name: Build image (BuildKit)

env:

DOCKER_BUILDKIT: 1

run: |

docker buildx bake \

--set *.output=type=docker \

--progress plain myapp

# サイズ取得と閾値比較（例：150 MB）

- name: Check image size

id: sizecheck

run: |

SIZE=$(docker image ls myapp:latest --format "{{.Size}}" | tr -d ' MB')

echo "size=$SIZE" >> $GITHUB_OUTPUT

if (( $(echo "$SIZE > 150" | bc -l) )); then

echo "::error ::Image size ${SIZE} MB exceeds limit (150 MB)"

exit 1

# docker-slim の自動実行（オプション）

- name: Run docker-slim (optional)

run: |

docker-slim build --target myapp:latest --output slim.tar

GitLab CI（例）

stages:
  - build
  - size_check

variables:
  IMAGE_TAG: &quot;$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA&quot;

build_image:
  stage: build
  image: docker:24.0
  services:
    - docker:dind
  script:
    - export DOCKER_BUILDKIT=1
    - docker build -t $IMAGE_TAG .
    - docker push $IMAGE_TAG

size_check:
  stage: size_check
  image: python:3.12
  before_script:
    - pip install --quiet docker-slim==1.7.0
  script:
    - SIZE=$(docker image ls $IMAGE_TAG --format &quot;{{.Size}}&quot; | tr -d ' MB')
    - |
      if (( $(echo &quot;$SIZE &gt; 150&quot; | bc -l) )); then
        echo &quot;Image size ${SIZE} MB exceeds limit&quot;
        exit 1
      fi

stages:

- build

- size_check

variables:

IMAGE_TAG: "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

build_image:

stage: build

image: docker:24.0

services:

- docker:dind

script:

- export DOCKER_BUILDKIT=1

- docker build -t $IMAGE_TAG .

- docker push $IMAGE_TAG

size_check:

stage: size_check

image: python:3.12

before_script:

- pip install --quiet docker-slim==1.7.0

script:

- SIZE=$(docker image ls $IMAGE_TAG --format "{{.Size}}" | tr -d ' MB')

- |

if (( $(echo "$SIZE > 150" | bc -l) )); then

echo "Image size ${SIZE} MB exceeds limit"

exit 1

閾値はプロジェクトごとに調整してください。
DOCKER_BUILDKIT=1 を環境変数で設定すると、ビルドキャッシュの共有やインライン最適化が有効になります。

BuildKit キャッシュ活用、docker‑slim と docker scout のレポート生成・評価

BuildKit のキャッシュ共有例（公式ベンチマーク参照）

docker buildx build \
  --cache-from=type=registry,ref=myrepo/cache:latest \
  --cache-to=type=registry,ref=myrepo/cache:latest,mode=max \
  -t myapp:ci .

docker buildx build \

--cache-from=type=registry,ref=myrepo/cache:latest \

--cache-to=type=registry,ref=myrepo/cache:latest,mode=max \

-t myapp:ci .

根拠: Docker 社が公開したベンチマーク（2025‑06）で、同一レジストリキャッシュを再利用した場合のビルド時間は平均 30 % 短縮 が確認されています【※Docker Docs – BuildKit cache performance, 2025】。

docker‑slim の詳細レポート取得

docker-slim report --target myapp:latest --output report.json
jq '.sizeBefore, .sizeAfter, .removedFiles' report.json

docker-slim report --target myapp:latest --output report.json

jq '.sizeBefore, .sizeAfter, .removedFiles' report.json

report.json には 削除されたファイル一覧 と ビフォー/アフターサイズ が含まれ、レビュー時の根拠資料として活用できます。

Docker Scout による脆弱性とサイズ変化の可視化

docker scout view myapp:latest --format json &gt; scout-report.json
jq '.size, .vulnerabilities | length' scout-report.json

docker scout view myapp:latest --format json > scout-report.json

jq '.size, .vulnerabilities | length' scout-report.json

docker scout（バージョン 0.9.3、2026‑04 リリース）は サイズトレンド と CVE スキャン を同時に提供し、CI パイプラインでの自動警告を実装できます。

次のステップ：サンプルリポジトリで実践しよう

本稿で紹介した可視化手法・軽量ベース選定・マルチステージ Dockerfile・.dockerignore の作成方法、さらに CI への自動化までを 一つのリポジトリ にまとめました。以下の手順でローカルと CI 両方で体験できます。

リポジトリをクローン
bash git clone https://github.com/example/docker-image-optimisation-demo.git cd docker-image-optimisation-demo
ローカルで docker buildx bake を実行し、サイズレポートを確認。
GitHub リポジトリの Actions タブから 「Docker Image Size Check」 ワークフローが自動的に走り、サイズ閾値超過時は PR が失敗します。

学習ポイント: ビルドコンテキスト削減 → マルチステージビルド → BuildKit キャッシュ活用 → CI での自動サイズチェックの流れを体感すれば、Docker イメージ軽量化ベストプラクティス が自然に身につきます。

参考文献・リンク

No.	内容	URL	確認日
1	Qiita 記事「Dockerイメージを10分の1に軽量化する3つの…」	https://qiita.com/ryucciarati/items/627baabad717c7410711	2026‑05‑28
2	Docker Docs – BuildKit performance study (2025)	https://docs.docker.com/buildx/working-with-buildkit/#performance-study	2026‑04‑12
3	dive GitHub Releases（v0.12.0）	https://github.com/wagoodman/dive/releases/tag/v0.12.0	2026‑03‑30
4	docker-slim GitHub Releases（v1.7.0）	https://github.com/docker-slim/docker-slim/releases/tag/v1.7.0	2026‑02‑15
5	Docker Scout CLI Documentation (v0.9.3)	https://docs.docker.com/scout/cli/	2026‑04‑10

本稿は 2026 年 6 月時点の情報に基づいて執筆しています。ツールのバージョンや公式ドキュメントは随時更新されるため、実装前に最新リリースノートをご確認ください。

スポンサードリンク

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

-Docker

comment コメントをキャンセル

: Docker

Docker クライアントとデーモンの API バージョン不一致対策 – 2025‑2026 最新環境

Docker クライアントとデーモン間の API バージョン不整合によるエラーの原因と、バージョン確認・環境変数設定・Desktop 再起動・Engine アップグレード／ダウングレードの具体的手順をまとめました。

: Docker

M1 MacへDocker Desktopをインストールする手順と要件

M1 Mac（Apple Silicon）でDocker Desktopを動かすためのシステム要件確認からインストール、初期設定、よくあるトラブル対策までをわかりやすく紹介します。

: Docker

Docker Composeで安全に環境別設定を共有する方法 – マイクロサービス実践ガイド

Docker Composeの最新Compose Specを活用し、複数ファイルで環境別設定を管理、.envで機密情報を一元化、ローカルIngressエミュとCI/CD自動デプロイまで実践的に解説します。

: Docker

Docker APIバージョン不一致エラーの原因と対処法 – CLI・CI/CD・Desktop対応

CLI・CI/CD・Docker Desktopで頻発する「Error while fetching server API version」エラーの本質と、バージョン確認からアップデート、環境変数設定、デーモン再起動までの具体的な対処手順をまとめました。

: Docker

Docker コンテナのコスト削減ベストプラクティス：イメージ最適化からスポット活用まで

マルチステージビルドや軽量イメージ、リソース右サイズ化、オートスケール、スポットインスタンス活用など、Dockerコンテナの運用コストを劇的に削減する実践手順を紹介します。

2025年改正後のSESと派遣の違いと働き方選択ガイド

2026年Klookクーポンコードの最新入手方法と活用術

Dockerイメージサイズの可視化と軽量化ベストプラクティス

Docker イメージサイズの可視化と現状把握

docker image ls と docker history の基本的な使い方

dive と docker‑slim を用いたレイヤー分析・削減候補抽出

軽量ベースイメージの選定基準と最新比較

Alpine・Slim 系・Distroless の特徴とセキュリティ・パフォーマンス観点からの評価

選定フロー

マルチステージビルドでレイヤー削減を実現するパターン

開発ステージ vs 本番ステージの典型的な Dockerfile 例

RUN 命令の統合とキャッシュクリア（apt-get clean 等）

ビルド時間短縮の根拠（BuildKit）

ビルドコンテキストと Dockerfile のベストプラクティス

.dockerignore 作成のチェックリスト

COPY と ADD の使い分け、COPY --from で必要ファイルだけ持ち込む方法

CI/CD パイプラインへの組み込み例と自動化ツール

GitHub Actions / GitLab CI でイメージサイズ閾値チェックを行うワークフロー

GitHub Actions（例）

GitLab CI（例）

BuildKit キャッシュ活用、docker‑slim と docker scout のレポート生成・評価

BuildKit のキャッシュ共有例（公式ベンチマーク参照）

docker‑slim の詳細レポート取得

Docker Scout による脆弱性とサイズ変化の可視化

次のステップ：サンプルリポジトリで実践しよう

参考文献・リンク

`docker image ls` と `docker history` の基本的な使い方