Docker イメージサイズの縮小とレイヤー最適化

JPKODA 編集部 May 12, 2026

Dockerイメージのサイズ縮小とレイヤーの最適化は、効率的なコンテナ化における重要なスキルです。イメージサイズが小さいほど、ビルド速度が向上し、ストレージの専有スペースが削減され、デプロイプロセスが迅速化し、セキュリティが高まります。無駄のない効率的なDockerイメージを作成するためのコアは、イメージの「レイヤー (Layers)」構造を理解し、これらのレイヤーを操作するテクニックをマスターすることにあります。本章では、軽量かつ高効率なDockerイメージをビルドするための原理と実践的なテクニックを深く掘り下げます。

1. Dockerのイメージレイヤー (Image Layers) を理解する

Dockerイメージはレイヤー状にビルドされており、各レイヤーはファイルシステムに対する一連の変更を表しています。これらのレイヤーは、Dockerfile内に記述されたインストラクションによって生成されます。RUN、COPY、ADD などのインストラクションを実行するたびに、イメージ内にまったく新しいレイヤーが生成されます。

Dockerがこのようなレイヤーアーキテクチャを採用しているのは、効率を向上させるためです。異なるイメージ間で同じレイヤーを共有および再利用できるため、ディスクスペースを大幅に節約し、ビルド速度を加速させることができます。

例えば、Dockerfileで最初にシステムのベースソフトウェアをインストールし、次にアプリケーションのソースコードをコピーし、最後にアプリケーション専用の依存パッケージをインストールしたとします。これら3つのステップは、それぞれ3つの独立したレイヤーを作成します。将来、アプリケーションのコードのみが変更された場合、Dockerはスマートにシステムソフトウェアレイヤーと依存パッケージレイヤーを再利用（キャッシュ）し、アプリケーションコードのレイヤーのみを再ビルドします。

Dockerfileを記述する際、このレイヤーアーキテクチャを深く理解することが極めて重要です。インストラクションの順序は非常に重要であり、前の方のレイヤーが変更されると、それ以降のすべてのレイヤーのキャッシュが無効化され、再ビルドを余儀なくされます。

2. イメージサイズを縮小するための実践戦略

Dockerイメージを「スリム化」するために、複数の戦略を採用できます。これらの戦略のコアとなる考え方は、イメージのレイヤー数を減らすこと、各レイヤーのサイズを縮小すること、そして不要なファイルを容赦なく削除することです。

2.1 マルチステージビルド (Multi-Stage Builds)

マルチステージビルドは、マイクロサイズのDockerイメージを作成するための「切り札」です。これにより、1つのDockerfile内で複数の FROM インストラクションを使用できるようになります。各 FROM インストラクションは、まったく新しい「ビルドステージ」を開始します。最も強力な点は、前のステージで生成されたコアファイル（コンパイル済みのプログラムなど）を次のステージにコピーしつつ、コンパイル環境や各種の一時ファイルを完全に破棄し、最終的なイメージに混入させないようにできることです。

基礎ケース：Javaアプリケーション

Javaアプリケーションをビルドすると仮定します。コードをコンパイルする際には巨大なJDK（Java Development Kit）が必要ですが、アプリケーションを実行するだけであれば、軽量なJRE（Java Runtime Environment）のみで十分です。マルチステージビルドを利用して、第1ステージでJDKを使用してコンパイルし、第2ステージでコンパイル済みのJARファイルをJREイメージに配置するだけです。

# 第1ステージ：MavenとJDKを含むイメージを使用してアプリケーションをコンパイルする
FROM maven:3.8.4-openjdk-17 AS builder
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN mvn clean install

# 第2ステージ：軽量なJREイメージを使用して最終的な実行環境を作成する
FROM openjdk:17-jre-slim
WORKDIR /app
# 第1ステージ (builder) でコンパイルされた jar ファイルのみをコピーしてくる
COPY --from=builder /app/target/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

この例では、最終的に生成されるイメージにはMavenとJDKの膨大なファイルが一切含まれていないため、サイズが非常に小さくなります。

応用ケース：Node.jsアプリケーション

Node.jsのフロントエンドプロジェクトがある場合、ビルド時には巨大な node_modules が必要ですが、webpack などのツールを使用してバンドルした後は、最終的な実行にはバンドルされた静的ファイルのみが必要です。

# 第1ステージ：アプリケーションのビルド
FROM node:16 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build # package.json に build スクリプトが設定されていると仮定する

# 第2ステージ：最終イメージの作成（極小の Nginx を使用してサービスを提供）
FROM nginx:alpine
# 第1ステージでビルドされた静的ファイルを Nginx のWebディレクトリにコピーする
COPY --from=builder /app/dist /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

2.2 より小さなベースイメージの使用

FROM インストラクションで選択するベースイメージは、最終的なイメージの「土台」の大きさを直接決定します。アプリケーションの要件を満たすという前提の下、ベースイメージは小さければ小さいほど良いです。

基礎ケース： 思考停止で完全な ubuntu イメージを使用しないでください。slim タグが付いたスリム版を使用するか、alpine ベースのイメージを検討することを強く推奨します。Alpine Linuxはコンテナ専用に設計された超軽量なLinuxディストリビューションであり、サイズは通常数メガバイトしかありません。

応用ケース： Go言語のアプリケーションを作成している場合、最も極端な scratch（空の）イメージを使用できます。Goはランタイムを内包した独立したバイナリファイルにコンパイルできるため、空のイメージに直接配置することが可能です。

# コンパイルステージ
FROM golang:1.18 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp

# 実行ステージ：空のイメージをベースにする
FROM scratch
COPY --from=builder /app/myapp /app/myapp
ENTRYPOINT ["/app/myapp"]

2.3 イメージのレイヤー数の削減

Dockerfile内の各 RUN、COPY、ADD が新しいレイヤーを作成することを忘れないでください。シェルの連結演算子 && を介して複数のコマンドを1つの RUN インストラクションに統合することで、レイヤー数を効果的に減らすことができます。

基礎ケース：

このように記述しないでください（3つの肥大化したレイヤーが生成されます）：

RUN apt-get update
RUN apt-get install -y package1
RUN apt-get install -y package2

このように記述すべきです（1つのレイヤーに統合し、ついでにクリーンアップも行います）：

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

1つのインストラクションに統合した後、apt-get clean はインストールパッケージのキャッシュをクリアし、rm -rf /var/lib/apt/lists/* は更新されたソフトウェアソースリストを削除します。この2つのステップにより、このレイヤーのサイズを大幅に圧縮できます。

2.4 不要なファイルの削除

各レイヤーのビルドの最後に、必ずゴミ（一時ファイル、コンパイルの成果物、キャッシュデータ）をクリーンアップする良い習慣を身につけてください。

基礎ケース： 前のセクションで言及したように、システムパッケージをインストールした後はパッケージマネージャーのキャッシュをクリアし、C++のコードをコンパイルした後は .o オブジェクトファイルを削除します。

応用ケース：.dockerignore の活用

未然に防ぐために、.dockerignore ファイルを使用して、不要なファイル（.git、ログ、ローカルのテスト用依存関係など）が根本からイメージにコピーされるのをブロックできます。Dockerfileが存在するディレクトリに .dockerignore ファイルを作成します：

node_modules
.git
tmp
logs

2.5 パッケージ管理の最適化

ソフトウェアをインストールする際、多くのパッケージマネージャーはデフォルトで「推奨されるが必須ではない」付属パッケージをインストールします。この機能をオフにしてください！

基礎ケース (Debian/Ubuntu)： --no-install-recommends パラメーターを追加します。

RUN apt-get update && \
    apt-get install -y --no-install-recommends package1 package2 && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

応用ケース (Python)：pip を使用する際、--no-cache-dir オプションを追加して、pipがダウンロードしたインストールパッケージのキャッシュをイメージ内に保存するのを防ぎます。

FROM python:3.9-slim-buster
WORKDIR /app
COPY requirements.txt .
# キャッシュされたダウンロードを無効化する
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "app.py"]

2.6 キャッシュを利用したインストラクション順序の最適化

Dockerのレイヤーキャッシュを最大限に活用してその後のビルドを高速化するために、最も変更されにくいインストラクションをDockerfileの一番前に置き、最も頻繁に変更されるインストラクションを一番後ろに置くべきです。

基礎ケース： アプリケーションコード（頻繁に変更される）のコピーは、依存パッケージのインストール（あまり変更されない）の後に行うべきです。まず pom.xml や requirements.txt をコピーして依存関係をインストールし、最後にソースコードを COPY します。こうすることで、新しいパッケージを追加しない限り、コードをどのように変更しても、依存関係をインストールする巨大なレイヤーは直接キャッシュを利用して処理をスキップできます。

3. 実践ケースとデモンストレーション

比較を通じて、Pythonアプリケーションの最適化効果を見てみましょう。

最適化前のオリジナル Dockerfile：

FROM python:3.9
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

全方位的に最適化された Dockerfile：

FROM python:3.9-slim-buster
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "app.py"]

変更点の解説：

ベースイメージを巨大な python:3.9 からスリムな python:3.9-slim-buster に変更しました。
依存関係のインストールに --no-cache-dir を追加し、キャッシュを拒否しました。
重要なキャッシュの最適化：まず requirements.txt を取り込んでインストールし、最後に残りのコードを COPY . . でコピーします。

これらの最適化手法を組み合わせることで、イメージサイズは半分以下に縮小される可能性があり、さらに今後のコード変更時のビルド速度は秒レベルになります！