コンテナイメージ

container

Last updated at 2026-04-29Posted at 2026-04-29

【コンテナイメージとは】Dockerfile / docker build / docker commit / Compose の image と build の違いを整理する

Docker を使っていると、以下のような言葉がよく出てきます。

コンテナイメージ
コンテナ
Dockerfile
docker build
docker run
docker compose up
docker commit
Compose の image
Compose の build

最初は、これらの関係が分かりにくいです。

特に混乱しやすいのが、以下の点です。

docker build はどこまでを行うコマンドなのか？
image とはコンテナイメージのことなのか？
docker build しておけば、Compose の image でいつでも呼び出せるのか？

この記事では、コンテナイメージとコンテナの違いから、docker build、docker commit、Docker Compose の image と build の違いまで整理します。

1. コンテナイメージとは

コンテナイメージとは、コンテナを実行するために必要なファイルやメタ情報をまとめたパッケージです。

たとえば、以下のようなものが含まれます。

OS のユーザーランド
アプリケーション本体
ライブラリ
設定ファイル
起動コマンド
環境変数のデフォルト値
メタ情報

コンテナは、このイメージをもとに作成されます。

イメージとコンテナの関係は、以下のように考えると分かりやすいです。

コンテナイメージ = 実行前のテンプレート
コンテナ       = イメージから起動した実体

たとえるなら、以下のような関係です。

イメージ = クラス
コンテナ = インスタンス

または、

イメージ = 設計図 + 材料一式
コンテナ = 実際に動いている環境

つまり、コンテナイメージは「まだ動いていないもの」です。

実際に動いているものがコンテナです。

2. コンテナイメージに IP アドレスは含まれない

重要な点として、コンテナイメージ自体には IP アドレスは含まれません。

IP アドレスは、コンテナを起動して Docker ネットワークに接続されたときに割り当てられます。

つまり、以下のような関係です。

コンテナイメージ
  ↓
docker run / docker compose up
  ↓
コンテナ作成
  ↓
Docker ネットワークに接続
  ↓
IP アドレスが割り当てられる

そのため、同じイメージを別の環境で起動すれば、別の IP アドレスになる可能性があります。

コンテナイメージは、あくまでコンテナを起動するための材料です。

IP アドレス、実行中のプロセス、現在のメモリ状態などは、コンテナを起動した後に発生するものです。

3. コンテナイメージの作成方法

コンテナイメージを作成する方法には、主に以下の2つがあります。

docker build
docker commit

基本的には docker build を使うべきです。

理由は、Dockerfile に作成手順を残せるためです。

一方、docker commit は、起動中または停止中のコンテナの状態をそのまま新しいイメージとして保存する方法です。

一時的な検証では便利ですが、本番運用やチーム開発では基本的におすすめされません。

【docker build】

1. docker build とは

docker build は、Dockerfile をもとにコンテナイメージを作成するコマンドです。

Dockerfile は、コンテナイメージの作り方を書いたテキストファイルです。

重要なのは、docker build が行うのは コンテナイメージの作成まで という点です。

docker build は、コンテナを起動するコマンドではありません。

2. 基本的な使い方

docker build -t イメージ名:タグ名 .

例：

docker build -t myapp:1.0 .

これは、カレントディレクトリにある Dockerfile を使って、myapp:1.0 というコンテナイメージを作成するコマンドです。

最後の . は、ビルドコンテキストを表します。
つまり今回のビルドコンテキストはカレントディレクトリです。

ビルドコンテキストとは、Dockerfile から参照できるファイル一式の範囲です。

たとえば、以下のように Dockerfile に COPY がある場合、

COPY index.html /var/www/html/

index.html はビルドコンテキスト内に存在する必要があります。

3. `-t` はイメージ名とタグを付けるオプション

-t は、作成するコンテナイメージに名前とタグを付けるためのオプションです。

docker build -t myapp:1.0 .

この場合、以下の名前のコンテナイメージが作成されます。

myapp:1.0

構造としては、以下のように考えると分かりやすいです。

myapp = イメージ名
1.0   = タグ

タグを省略すると、通常は latest が使われます。

docker build -t myapp .

これは、おおよそ以下と同じ意味です。

docker build -t myapp:latest .

4. `-f` で Dockerfile を指定する

通常は、ビルドコンテキスト直下の Dockerfile が使われます。

明示的に Dockerfile を指定する場合は、-f を使います。

docker build -t myapp:1.0 -f ./Dockerfile .

これは、以下とほぼ同じです。

docker build -t myapp:1.0 .

別の名前の Dockerfile を使う場合は、以下のようにできます。

docker build -t myapp:1.0 -f Dockerfile.dev .

また、別のディレクトリをビルドコンテキストにする場合は、以下のように指定できます。

docker build -t nginx-custom:latest ./docker

この場合、./docker がビルドコンテキストになります。

5. Dockerfile の例

# ベースイメージを指定
FROM ubuntu:22.04

# パッケージをインストール
RUN apt-get update && apt-get install -y nginx

# ファイルをコピー
COPY index.html /var/www/html/

# このコンテナが 80 番ポートを使うことを示すメタ情報
# 実際にホストへ公開するには docker run -p や compose.yaml の ports が必要
EXPOSE 80

# コンテナ起動時のデフォルトコマンド
CMD ["nginx", "-g", "daemon off;"]

この Dockerfile を使ってビルドすると、nginx が入ったコンテナイメージを作成できます。

docker build -t nginx-custom:1.0 .

この時点で作成されるのは、あくまでコンテナイメージです。

まだコンテナは起動していません。

6. Dockerfile からコンテナイメージができる流れ

docker build の範囲は、以下の部分です。

Dockerfile
  ↓
docker build
  ↓
コンテナイメージ

つまり、docker build を実行すると、Dockerfile の内容をもとにコンテナイメージが作成されます。

この時点では、まだコンテナは起動していません。

作成されたコンテナイメージを使って、実際にコンテナを起動するのが docker run や docker compose up です。

コンテナイメージ
  ↓
docker run / docker compose up
  ↓
コンテナ

全体像としては以下です。

Dockerfile
  ↓
docker build
  ↓
コンテナイメージ
  ↓
docker run / docker compose up
  ↓
コンテナ

ただし、この図はあくまで全体像です。

docker build の役割は、途中の コンテナイメージを作成するところまで です。

Dockerfile
  ↓
docker build
  ↓
コンテナイメージ

その後の docker run や docker compose up は、作成済みのイメージからコンテナを起動する手順です。

7. docker build と docker run / docker compose up は役割が違う

docker build、docker run、docker compose up は、どれも Docker でよく使うコマンドですが、役割が違います。

コマンド	役割
`docker build`	Dockerfile からコンテナイメージを作る
`docker run`	コンテナイメージからコンテナを起動する
`docker compose up`	compose.yaml の定義に従ってコンテナを起動する

つまり、以下のように分けて考えると分かりやすいです。

イメージを作る工程
Dockerfile → docker build → コンテナイメージ

イメージを使う工程
コンテナイメージ → docker run / docker compose up → コンテナ

docker build は「作る」コマンドです。

docker run や docker compose up は「起動する」コマンドです。

8. 作成したイメージを確認する

docker build で作成したイメージは、以下のコマンドで確認できます。

docker images

または、

docker image ls

例：

REPOSITORY       TAG       IMAGE ID       CREATED          SIZE
myapp            1.0       xxxxxxxxxxxx   10 seconds ago   180MB
nginx-custom     1.0       yyyyyyyyyyyy   5 minutes ago    190MB

ここに表示されているものが、ローカル環境に存在するコンテナイメージです。

このイメージを使って、docker run や docker compose up でコンテナを起動できます。

9. docker build したイメージはどこからでも使えるのか

docker build したイメージは、基本的には ビルドした Docker ホスト上のローカルイメージ として保存されます。

たとえば、以下を実行したとします。

docker build -t mymailserver:1.0 .

すると、その Docker ホスト上に以下のコンテナイメージが作成されます。

mymailserver:1.0

同じ Docker ホスト上であれば、Compose から以下のように呼び出せます。

services:
  mailserver:
    image: mymailserver:1.0

この場合、Compose はローカルにある mymailserver:1.0 というイメージを使ってコンテナを起動できます。

ただし、別の PC や別のサーバからも同じように使いたい場合は、Docker Hub や GitHub Container Registry などのレジストリに push する必要があります。

同じサーバ内で使うだけ
  → docker build -t 名前:タグ . しておけば使える

別の PC や別のサーバでも使いたい
  → docker push でレジストリに置く必要がある

つまり、docker build だけで「世界中のどこからでも使える状態」になるわけではありません。

docker build は、基本的にはローカルにイメージを作る処理です。

10. イメージ名が違えば別物

たとえば、自分で以下のようにビルドしたとします。

docker build -t mymailserver:1.0 .

この場合、作成されるイメージ名は以下です。

mymailserver:1.0

しかし、Compose に以下のように書いていた場合、

services:
  mailserver:
    image: ghcr.io/docker-mailserver/docker-mailserver:latest

これは別物です。

mymailserver:1.0
≠
ghcr.io/docker-mailserver/docker-mailserver:latest

Compose の image に書かれている名前と、ローカルに存在するイメージ名が一致していなければ、そのローカルイメージは使われません。

自分でビルドしたイメージを使いたいなら、Compose 側にも同じイメージ名を書く必要があります。

services:
  mailserver:
    image: mymailserver:1.0

【Compose の image はコンテナイメージ】

1. Compose の image とは

Docker Compose の image は、サービスで使うコンテナイメージを指定する項目です。

たとえば、docker-mailserver の例では以下のように書かれます。

services:
  mailserver:
    image: ghcr.io/docker-mailserver/docker-mailserver:latest

ここで指定している image は、コンテナイメージです。

ghcr.io/docker-mailserver/docker-mailserver:latest

これは、GitHub Container Registry にある docker-mailserver のコンテナイメージを指しています。

つまり、この設定は以下の意味です。

ghcr.io/docker-mailserver/docker-mailserver:latest
というコンテナイメージを使って、
mailserver というサービスのコンテナを起動する

この場合、自分で Dockerfile からビルドしているわけではありません。

すでに公開されている docker-mailserver のコンテナイメージを取得して使っています。

2. image を指定したときの流れ

Compose に以下のように書いた場合、

services:
  mailserver:
    image: ghcr.io/docker-mailserver/docker-mailserver:latest

大まかな流れは以下です。

compose.yaml
  ↓
image: ghcr.io/docker-mailserver/docker-mailserver:latest を読む
  ↓
ローカルにそのイメージがあるか確認
  ↓
なければレジストリから pull
  ↓
そのイメージからコンテナを起動

つまり、image は「使用するコンテナイメージ名」を指定する項目です。

3. image と docker build の関係

image は「使うイメージ」を指定します。

docker build は「イメージを作る」コマンドです。

この2つは役割が違います。

docker build
  → Dockerfile からコンテナイメージを作る

image
  → 使用するコンテナイメージ名を指定する

たとえば、以下のようにイメージを作った場合、

docker build -t myapp:1.0 .

Compose では以下のように指定できます。

services:
  app:
    image: myapp:1.0

この場合は、ローカルにある myapp:1.0 というイメージからコンテナを起動します。

【ポート公開について】

1. EXPOSE の意味

Dockerfile の EXPOSE は、ホストにポートを公開する設定ではありません。

EXPOSE 80

これは、あくまで以下の意味です。

このコンテナは 80 番ポートを使う想定です

つまり、EXPOSE はメタ情報です。

実際にホスト側へポートを公開するには、docker run なら -p を使います。

docker run -p 8080:80 nginx

Docker Compose なら ports を使います。

ports:
  - "8080:80"

整理すると以下です。

設定	役割
`EXPOSE`	コンテナが使うポートのメタ情報
`docker run -p`	ホストへポート公開
Compose の `ports`	ホストへポート公開

【docker commit】

1. docker commit とは

docker commit は、起動中または停止中のコンテナの状態を、新しいコンテナイメージとして保存するコマンドです。

たとえば、Ubuntu コンテナを起動して、その中で手作業で nginx をインストールした後、その状態をイメージ化できます。

2. 基本的な使い方

まず、Ubuntu コンテナを起動します。

docker run -it ubuntu:22.04 /bin/bash

コンテナ内で作業します。

apt-get update
apt-get install -y nginx
echo "Hello" > /var/www/html/index.html
exit

コンテナ ID を確認します。

docker ps -a

コンテナをイメージ化します。

docker commit <コンテナID> myimage:1.0

これで、コンテナ内で手作業した結果を myimage:1.0 というコンテナイメージとして保存できます。

3. docker commit の流れ

ベースイメージ
  ↓
docker run でコンテナ起動
  ↓
コンテナ内で手動作業
  ↓
docker commit
  ↓
新しいコンテナイメージ

docker build とは流れが違います。

docker build は Dockerfile からイメージを作ります。

docker commit は、コンテナ内で手作業した結果をイメージとして保存します。

4. docker commit の注意点

docker commit は便利ですが、本番用イメージの作成方法としては基本的に非推奨です。

理由は以下です。

手作業の内容が Dockerfile として残らない
再現性が低い
何を変更したか分かりづらい
チームで共有しづらい
CI/CD に組み込みづらい
イメージがブラックボックス化しやすい

また、重要な注意点として、docker commit では volume や bind mount 上のデータはイメージに含まれません。

たとえば、以下のように volume をマウントしていたとします。

docker run -v ./data:/data -it ubuntu:22.04 bash

この状態で /data にファイルを作っても、docker commit で作成されるイメージには基本的に含まれません。

volume や bind mount は、コンテナの外側にあるデータだからです。

5. docker commit を使ってよい場面

docker commit は完全に不要な機能ではありません。

以下のような一時的な用途では使えます。

デバッグ中の状態保存
実験環境の一時保存
手作業で調査した内容を一旦退避する
緊急時の応急処置

ただし、本番運用やチーム開発では Dockerfile を使うべきです。

docker build と docker commit の比較

1. docker build の特徴

docker build のメリットは以下です。

再現性が高い
Dockerfile を Git 管理できる
変更履歴を追える
CI/CD に組み込める
チームで共有しやすい
何をインストールしているか分かりやすい
レビューしやすい

例：

FROM ubuntu:22.04

RUN apt-get update && \
    apt-get install -y \
        nginx \
        curl \
        vim

COPY nginx.conf /etc/nginx/nginx.conf

CMD ["nginx", "-g", "daemon off;"]

この Dockerfile があれば、他の人も同じ手順でイメージを作れます。

git clone <repository>
docker build -t myapp:1.0 .

2. docker commit の特徴

docker commit は、コンテナ内での手作業結果を保存する方法です。

例：

docker run -it ubuntu bash
apt-get update
apt-get install -y nginx
apt-get install -y curl
exit
docker commit <コンテナID> myapp:1.0

この場合、後から見た人には以下が分かりにくくなります。

どのパッケージを入れたのか
どの設定ファイルを変更したのか
どのコマンドを実行したのか
どの順番で作業したのか
なぜその変更をしたのか

そのため、再現性が低くなります。

3. 比較表

項目	docker build	docker commit
作成方法	Dockerfile から自動作成	コンテナ内の手作業結果を保存
再現性	高い	低い
Git 管理	しやすい	しづらい
チーム共有	しやすい	しづらい
CI/CD	組み込みやすい	組み込みづらい
中身の透明性	高い	低い
主な用途	本番、開発、CI/CD	一時保存、検証、デバッグ

Docker Compose での image と build の使い分け

1. image と build の本質的な違い

Compose における image と build の違いは以下です。

項目	`image`	`build`
意味	作成済みイメージを使う	Dockerfile からイメージを作る
主な用途	既製品、依存サービス、本番用イメージ	自作アプリ、開発中のアプリ
柔軟性	低め	高め
起動までの流れ	pull して起動	build して起動
例	`postgres:15`	`build: .`

image は、使用するコンテナイメージを指定します。

build は、Dockerfile からコンテナイメージを作るための設定です。

2. image の例

services:
  postgres:
    image: postgres:15

  redis:
    image: redis:alpine

PostgreSQL や Redis のようなミドルウェアは、自分でビルドせず、公式イメージをそのまま使うことが多いです。

この場合、Compose は指定されたイメージを使ってコンテナを起動します。

ローカルにイメージがなければ、Docker Hub などのレジストリから pull します。

3. docker-mailserver の image の例

docker-mailserver では、以下のように image を指定します。

services:
  mailserver:
    image: ghcr.io/docker-mailserver/docker-mailserver:latest

この image は、コンテナイメージを指しています。

ghcr.io/docker-mailserver/docker-mailserver:latest

これは、自分の Dockerfile からビルドするという意味ではありません。

GitHub Container Registry に公開されている docker-mailserver のコンテナイメージを使う、という意味です。

流れとしては以下です。

compose.yaml
  ↓
image: ghcr.io/docker-mailserver/docker-mailserver:latest
  ↓
ローカルにイメージがあるか確認
  ↓
なければレジストリから pull
  ↓
そのイメージから mailserver コンテナを起動

つまり、docker-mailserver のように既に公開されているイメージを使う場合は、自分で docker build しなくても利用できます。

4. build の例

services:
  app:
    build: .
    image: myapp:dev

buildの場合、

build と image を両方書くことがあります。
- この場合、Compose はカレントディレクトリの Dockerfile を使ってイメージをビルドします。
- そして、作成したイメージに myapp:dev という名前を付けます。
image を書かない場合でもビルドはできます。
- ただし、その場合は Compose が自動生成したイメージ名になります。

明示的にイメージ名を付けたい場合は、build と image を両方書くと分かりやすいです。

流れは以下です。

Dockerfile
  ↓
Compose がイメージをビルド
  ↓
myapp:dev というコンテナイメージを作成
  ↓
そのイメージからコンテナを起動

ここでも、イメージ作成とコンテナ起動は分けて考えると分かりやすいです。

build:
  Dockerfile からコンテナイメージを作る

up:
  コンテナを起動する

docker compose up は、必要に応じてビルドも実行できます。

ただし、概念としては、build はイメージ作成、up はコンテナ起動です。

5. 開発環境で build を使う理由

誤解

image は個人環境で動かないから build を使う

これは正確ではありません。

正しい理解

開発環境で build を使う理由は、主に以下です。

アプリのコードを変更するから
Dockerfile を変更するから
依存パッケージを追加・変更するから
開発用ツールを入れたいから
ホットリロードなど開発向け設定を使いたいから

つまり、image が動かないからではなく、開発中は柔軟に変更したいから build を使います。

6. 開発環境でも image を使えるケース

開発環境でも、以下のようなものは image を使えます。

PostgreSQL
MySQL
Redis
nginx
MailHog
MinIO
Elasticsearch
変更しない社内共通サービス
完成済みのアプリケーション

つまり、開発環境だから必ず build というわけではありません。

自分で変更するものは build。

既に完成しているものや公式イメージを使うものは image。

このように考えると分かりやすいです。

7. 本番環境では基本的に image を使う

本番環境では、CI/CD でビルド済みのイメージを作成し、それを本番環境で pull して起動する構成が一般的です。

つまり、本番環境では以下のようにします。

services:
  app:
    image: myapp:1.2.3

本番環境で毎回 build するよりも、事前にビルド・テスト済みのイメージを使う方が安全です。

流れとしては以下です。

開発環境 / CI
  ↓
docker build
  ↓
テスト
  ↓
docker push
  ↓
レジストリに保存

本番環境
  ↓
docker pull
  ↓
docker compose up
  ↓
コンテナ起動

8. 実践的な構成例

開発環境

services:
  app:
    build: .
    image: myapp:dev
    volumes:
      - .:/app

  postgres:
    image: postgres:15

  redis:
    image: redis:alpine

開発中の自社アプリは build します。

一方、PostgreSQL や Redis のような依存サービスは image を使います。

本番環境

services:
  app:
    image: myapp:1.2.3

  postgres:
    image: postgres:15

  redis:
    image: redis:alpine

本番では、アプリも含めてビルド済みのイメージを使う構成が基本です。

Docker Compose の主な項目

Docker Compose を使うと、複数のコンテナやネットワーク、ボリューム、環境変数、ポート公開などを compose.yaml でまとめて管理できます。

たとえば docker-mailserver のようなサービスでは、Compose によって以下のような設定を管理できます。

使用するコンテナイメージ
コンテナ名
ホスト名
環境変数ファイル
公開ポート
永続化ディレクトリ
再起動ポリシー
停止時の猶予時間
ヘルスチェック
ネットワーク

主な項目を整理すると以下です。

項目	ポイント
`image`	作成済みコンテナイメージを使う
`build`	Dockerfile からコンテナイメージを作る
`ports`	ホストのポートをコンテナに転送する
`volumes`	データをホスト側に永続化する
`env_file`	コンテナに渡す環境変数ファイル
`hostname`	コンテナ内部のホスト名
`restart`	コンテナの再起動ポリシー
`healthcheck`	コンテナ内サービスの正常性確認
`networks`	コンテナ間通信のネットワーク

全体の整理

コンテナイメージとコンテナの関係は以下です。

コンテナイメージ = コンテナを起動するためのパッケージ
コンテナ       = イメージから起動した実体

docker build の範囲は以下です。

Dockerfile
  ↓
docker build
  ↓
コンテナイメージ

docker run や docker compose up の範囲は以下です。

コンテナイメージ
  ↓
docker run / docker compose up
  ↓
コンテナ

全体像は以下です。

Dockerfile
  ↓
docker build
  ↓
コンテナイメージ
  ↓
docker run / docker compose up
  ↓
コンテナ

ただし、docker build はコンテナイメージ作成までです。

docker run や docker compose up は、作成済みのコンテナイメージからコンテナを起動する工程です。

まとめ

この記事のポイントは以下です。

コンテナイメージ = コンテナを起動するためのテンプレート
コンテナ       = イメージから起動した実体

docker build = Dockerfile からコンテナイメージを作る
docker run   = コンテナイメージからコンテナを起動する
docker compose up = compose.yaml に従ってコンテナを起動する

Compose の image は、使用するコンテナイメージを指定する項目です。

services:
  mailserver:
    image: ghcr.io/docker-mailserver/docker-mailserver:latest

この場合、ghcr.io/docker-mailserver/docker-mailserver:latest というコンテナイメージを使って、mailserver コンテナを起動します。

自分でビルドしたイメージを使いたい場合は、以下のようにイメージ名を一致させます。

docker build -t mymailserver:1.0 .

services:
  mailserver:
    image: mymailserver:1.0

同じ Docker ホスト上で使うだけなら、docker build したローカルイメージを Compose から使えます。

別の PC や別のサーバからも使いたい場合は、Docker Hub や GitHub Container Registry などのレジストリに push する必要があります。

最後に、image と build の違いは以下です。

image:
  作成済みのコンテナイメージを使う

build:
  Dockerfile からコンテナイメージを作る

Docker Compose を理解すると、単体の docker run よりも、実運用に近い形でコンテナ環境を管理できるようになります。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

コンテナイメージ

【コンテナイメージとは】Dockerfile / docker build / docker commit / Compose の image と build の違いを整理する

1. コンテナイメージとは

2. コンテナイメージに IP アドレスは含まれない

3. コンテナイメージの作成方法

【docker build】

1. docker build とは

2. 基本的な使い方

3. -t はイメージ名とタグを付けるオプション

4. -f で Dockerfile を指定する

5. Dockerfile の例

6. Dockerfile からコンテナイメージができる流れ

7. docker build と docker run / docker compose up は役割が違う

8. 作成したイメージを確認する

9. docker build したイメージはどこからでも使えるのか

10. イメージ名が違えば別物

【Compose の image はコンテナイメージ】

1. Compose の image とは

2. image を指定したときの流れ

3. image と docker build の関係

【ポート公開について】

1. EXPOSE の意味

【docker commit】

1. docker commit とは

2. 基本的な使い方

3. docker commit の流れ

4. docker commit の注意点

5. docker commit を使ってよい場面

docker build と docker commit の比較

1. docker build の特徴

2. docker commit の特徴

3. 比較表

Docker Compose での image と build の使い分け

1. image と build の本質的な違い

2. image の例

3. docker-mailserver の image の例

4. build の例

5. 開発環境で build を使う理由

誤解

正しい理解

6. 開発環境でも image を使えるケース

7. 本番環境では基本的に image を使う

8. 実践的な構成例

開発環境

本番環境

Docker Compose の主な項目

全体の整理

まとめ

3. `-t` はイメージ名とタグを付けるオプション

4. `-f` で Dockerfile を指定する