Dockerイメージのタグ戦略|latest・semver・Git SHAの使い分けとベストプラクティス
「:latest を使えばいいでしょ?」——本番で必ず痛い目を見ます。タグの付け方ひとつで、デプロイの信頼性が天と地ほど変わります。この記事で本番でも安心なタグ戦略の型を押さえます。
💡 この記事のゴール
①
② Semantic Versioning(semver)の使い方
③ Git SHA ベースの Immutable タグ(本番の正解)
④ ダイジェスト参照(最も厳密な指定)
⑤ 現場で使える命名規則テンプレ
①
:latest の罠を実例で理解② Semantic Versioning(semver)の使い方
③ Git SHA ベースの Immutable タグ(本番の正解)
④ ダイジェスト参照(最も厳密な指定)
⑤ 現場で使える命名規則テンプレ
目次
- そもそもタグとは
latestの罠- Semantic Versioning(semver)
- Git SHA ベース(Immutable)
- ダイジェスト参照(最強の不変性)
- 複数タグの組み合わせ
- 現場で使える命名規則
- まとめ
1. そもそもタグとは
Docker のタグは、イメージID(SHA256 ダイジェスト)に付けられたエイリアスです。Git のタグと似ていますが、可変である点が大きな違い。
【タグはエイリアス・イメージIDが本体】
🏷️ タグ(可変)
myapp:v1.2
myapp:latest
━▶
🔒 イメージID / digest(不変)
sha256:abc123def456…
↑ 同じタグでも内容が差し替わることがある。本体はダイジェスト
2. latest の罠
:latest は「タグを省略したときに使われるデフォルト」でしかなく、「最新」を意味しません。しかも中身が勝手に差し替わるため、本番で使うと思わぬ事故の原因になります。
典型的な事故シナリオ
# 開発環境
$ docker pull myapp:latest # sha256:abc...(v1.0相当、動作OK)
# 1週間後、本番デプロイ時
$ docker pull myapp:latest # sha256:xyz...(v2.0にアップデート済み、非互換)
# → 本番が壊れる💥
| 問題 | 影響 |
|---|---|
| 同じタグで中身が変わる | 再現性がない。「昨日動いた」が明日動かない |
| ロールバック困難 | 「前のlatest」が残っていない |
| チーム内で不一致 | 各自の latest が違う日付のイメージを指す |
| 監査・追跡不可 | いつ何が変わったか追えない |
⚠️ 本番での
開発中のお試しなら OK ですが、compose.yml や Kubernetes manifest に
:latest は禁じ手開発中のお試しなら OK ですが、compose.yml や Kubernetes manifest に
:latest を書くのは事故のもと。明確なバージョンタグを使います。
3. Semantic Versioning(semver)
バージョン番号を MAJOR.MINOR.PATCH の3段階で付けるルール(公式な業界標準)。
| セグメント | 上げるとき | 例 |
|---|---|---|
| MAJOR | 後方互換性を壊す変更 | 1.0.0 → 2.0.0 |
| MINOR | 機能追加(後方互換性保持) | 1.2.0 → 1.3.0 |
| PATCH | バグ修正のみ | 1.3.4 → 1.3.5 |
複数の粒度でタグを付ける
実務では、1つのイメージに複数の粒度のタグを同時に付けて公開します。
# v1.2.3 をビルドしたとき、3つのタグを同時に付ける
docker build -t myapp:1.2.3 -t myapp:1.2 -t myapp:1 -t myapp:latest .
docker push myapp:1.2.3
docker push myapp:1.2
docker push myapp:1
docker push myapp:latest
| タグ | 指す先 | 使い手 |
|---|---|---|
1.2.3 |
この特定ビルドのみ(不変) | 本番・再現性が必要な用途 |
1.2 |
1.2.x の最新(PATCHに追随) | マイナー内のバグ修正を自動取り込み |
1 |
1.x.x の最新(MINORに追随) | 機能追加を自動取り込み |
latest |
最新メジャー含む最新 | お試し用のみ |
💡 公式イメージも同じパターン
postgres:16.4(特定)、postgres:16(マイナー追随)、postgres:latest(Bleeding edge)がすべて存在し、同じイメージを指していたり、日によって別のイメージを指したりしています。
4. Git SHA ベース(Immutable)
本番で最も信頼できるのは、Git コミットハッシュをタグに埋め込む方法。「このイメージは、Git のこのコミットから作られた、唯一無二のビルド」と保証できます。
# CI の中で
SHA=$(git rev-parse --short=7 HEAD)
docker build -t myapp:${SHA} .
docker push myapp:${SHA}
# 例:myapp:a1b2c3d のようなタグが作られる
なぜ Git SHA が強いのか
| 観点 | Git SHA | semver | latest |
|---|---|---|---|
| 不変性 | ◎(コミットと1対1) | ○(タグ運用次第) | × |
| どのコード? | ◎ 一目 | △ タグと紐付く必要 | × |
| 本番→ロールバック | ◎ 前のSHA に戻すだけ | ○ | × |
| ユーザーには見せにくい | △ | ◎ | ◎ |
semver と Git SHA の併用が定石
# リリース時はどちらも付ける
VERSION=1.2.3
SHA=$(git rev-parse --short=7 HEAD)
docker build \
-t myapp:${VERSION} \
-t myapp:${VERSION}-${SHA} \
-t myapp:${SHA} \
.
docker push myapp:${VERSION}
docker push myapp:${VERSION}-${SHA}
docker push myapp:${SHA}
5. ダイジェスト参照(最強の不変性)
タグすら信じず、ダイジェスト(SHA256ハッシュ)で直接指定する方法。タグが差し替わっても絶対にブレない。
# digest を確認
$ docker inspect postgres:16 --format='{{.RepoDigests}}'
[postgres@sha256:abc123def456...]
# digest 指定で pull
$ docker pull postgres@sha256:abc123def456...
# compose.yml でも
services:
db:
image: postgres@sha256:abc123def456...
💡 最も厳格な本番運用
金融・医療・監査対応が必要な領域では、ダイジェスト固定での運用が標準。「絶対に想定外のイメージに差し替わらない」を保証できるのはこの方法だけ。ただしダイジェストは人間には読めない文字列なので、CI/CDに組み込んで機械的に管理します。
金融・医療・監査対応が必要な領域では、ダイジェスト固定での運用が標準。「絶対に想定外のイメージに差し替わらない」を保証できるのはこの方法だけ。ただしダイジェストは人間には読めない文字列なので、CI/CDに組み込んで機械的に管理します。
6. 複数タグの組み合わせ
実戦の典型パターン:
# リリース v1.2.3 でこれだけのタグを付ける
myapp:1.2.3 # ← 本番デプロイが参照(不変・厳密)
myapp:1.2 # ← マイナー追随したい開発環境
myapp:1 # ← メジャー追随
myapp:latest # ← デモ用
myapp:a1b2c3d # ← Git SHA 追跡用
myapp:sha-a1b2c3d # ← prefix 付き(GitHub Container Registry系)
| 参照する人 | 使うタグ |
|---|---|
| 本番デプロイ(K8s/Compose) | 1.2.3 or @sha256:... |
| ステージング環境 | 1.2(マイナー追随) |
| 開発者のローカル | latest |
| CI のロールバック時 | Git SHA 指定 |
7. 現場で使える命名規則
ベース命名
<registry>/<org>/<image>:<tag>
例:
myid/shop-api:1.2.3 # Docker Hub
ghcr.io/myorg/shop-api:1.2.3 # GitHub Container Registry
123456789.dkr.ecr.us-east-1.amazonaws.com/shop-api:1.2.3 # ECR
推奨ルールセット
| ルール | 理由 |
|---|---|
本番参照に :latest を使わない |
事故防止 |
semver 1.2.3 を基本タグに |
人間が理解しやすい |
| Git SHA も併記 | 何のコードか追跡可能 |
| 本番は digest 固定 or immutable タグ | 再現性・監査 |
| タグ削除は基本禁止 | ロールバック不能になる |
タグに大文字や _ は避ける |
レジストリ互換性(基本小文字) |
💡 レジストリのImmutable Tag設定
ECR / GHCR / Harbor などでは「一度 push したタグは上書き不可」に設定できます。事故防止の観点から本番リポジトリでは必ず有効化しましょう。
ECR / GHCR / Harbor などでは「一度 push したタグは上書き不可」に設定できます。事故防止の観点から本番リポジトリでは必ず有効化しましょう。
8. まとめ
| タグ種 | 特徴 | 本番で使う? |
|---|---|---|
:latest |
可変・再現性なし | ❌ NG |
semver :1.2.3 |
人間可読・再現性あり(運用次第) | ✅ OK |
Git SHA :a1b2c3d |
コミットと1対1・追跡性◎ | ✅ 推奨 |
digest @sha256:... |
絶対不変・機械可読 | ✅ 最強 |
✅ 次のステップ
基礎編はここまで。応用編の 7-3 プライベートレジストリ構築では、Docker Hub を使わずに自前のレジストリを立てる方法を学びます。社内向けに独自運用したいときの選択肢です。
基礎編はここまで。応用編の 7-3 プライベートレジストリ構築では、Docker Hub を使わずに自前のレジストリを立てる方法を学びます。社内向けに独自運用したいときの選択肢です。
参考リンク
- Semantic Versioning 2.0.0(日本語) — semver 仕様の一次情報源。
- docker tag リファレンス — タグ付けコマンド公式。



コメント