コンテナレジストリ 2026 — Docker Hub / GHCR / ECR / Harbor / Quay / Zot / Cosign + Sigstore 徹底比較

プロローグ — レジストリはイメージ倉庫ではない

2015 年のコンテナレジストリはシンプルだった。docker push 一発で終わり。Docker Hub が事実上唯一の選択肢で、自社ホスティングが必要なら registry:2 コンテナを 1 つ立てれば済んだ。

2026 年の景色は違う。

Docker Hub の価格政策変更以降 — 無料 organization の push/pull 制限が強化され、OSS プロジェクトが続々と GHCR に移行した。
GHCR は OSS コンテナの事実上のデフォルトになった。GitHub Actions と一体で、public イメージは無料、認証は GITHUB_TOKEN 一本で完結する。
ECR Public は無料 Quay の代替として定着した。AWS アカウント 1 つでグローバル無料配信。
Harbor は CNCF graduated プロジェクトとなり、自社ホスティングの標準になった。Kubernetes 上の社内レジストリはほぼ Harbor だ。
Zot が CNCF incubating に上がり、OCI-only シンプルさを武器に emerging 領域を獲得した。
Cosign + Sigstore は署名の事実上の標準となった。SLSA Level 3 ビルドのデフォルトツールである。
ORAS はコンテナイメージ以外のすべて — Helm chart、WASM module、ML model、Terraform module — を OCI artifact として保管できるようにした。
SBOM(CycloneDX、SPDX) がレジストリに添付され、イメージを受け取った瞬間に中身がわかる。

レジストリはもはやイメージ保管庫ではなく、サプライチェーンセキュリティの中心ハブだ。誰がビルドし、何が入っていて、どこで検証されたか — マニフェストとともにレジストリに存在する。

本稿は 13 のレジストリ・署名ツール・SBOM 規格を一息に比較する。単なる機能表ではなく、「なぜそのチームがその選択をしたか」を辿っていく。

第 1 章 · 2026 年のコンテナレジストリ地図 — マネージド / 自社ホスティング / 無料 OSS の 3 陣営

まず 1 枚の地図。

                    [コンテナレジストリ 2026]
                              |
        +---------------------+---------------------+
        |                     |                     |
   [マネージド SaaS]      [自社ホスティング OSS] [無料 OSS ホスティング]
        |                     |                     |
  - Docker Hub            - Harbor (CNCF)      - GHCR (public free)
  - GHCR (private 有料)   - Zot (CNCF)         - ECR Public
  - GitLab Registry       - Distribution       - Quay.io (OSS 無料)
  - AWS ECR               - Artifactory CE     - Docker Hub (public)
  - Google AR             - Nexus
  - Azure ACR
  - Quay.io (Red Hat)
  - Artifactory (JFrog)

3 陣営の核心的な違いはシンプルだ。

マネージド SaaS — クラウドベンダーが運用、請求書で費用負担。可用性責任はベンダー。トレードオフは価格とマルチクラウド可搬性。
自社ホスティング OSS — 自前運用、インフラ費用のみ。可用性とセキュリティは自分の責任。トレードオフは運用負担。
無料 OSS ホスティング — OSS プロジェクトは公開リポジトリを無料でホスティングできる。private は別途費用または制限。

2026 年の新しい流れは「この 3 陣営がもはや分離していない」という点だ。

GitHub Actions がビルドしたイメージを GHCR に push し、ECR に mirror し、Harbor に caching pull-through proxy で接続する。
Docker Hub の価格変動で OSS プロジェクトは GHCR と Quay.io に移行したが、ユーザーの docker pull は依然として Docker Hub にも向かう — library/nginx のような official image はそこにある。
エンタープライズは Artifactory の上に Harbor を置いたり、ACR をメインにして ECR を mirror にしたりする。

レジストリは単一選択ではなく、トポロジで設計するものになった。

覚えておく一文：「2026 年のレジストリ選択は単一選択ではなく、マルチレジストリトポロジの設計である」

第 2 章 · Docker Hub — 元祖、価格変更以降

Docker Hub はコンテナレジストリの元祖だ。docker pull nginx が自動で向かう先であり、Official Images(公式イメージ)の正典である。

2026 年の Docker Hub の立ち位置

依然として public image のデフォルト destination — library/、bitnami/、library/python のような検証済みイメージはここにある。
Official Images プログラムは依然として強力 — Docker が自ら build・署名するイメージセット。
価格政策は何度も変更された。無料 Team の pull/push 制限、無料 organization の image retention、非アクティブイメージの自動削除など、適用と撤回を繰り返してきた。

価格変更のインパクト

2023 年の無料 organization 変更告知 → OSS コミュニティの反発 → 部分撤回 → その後の段階的制限。
無料認証ユーザーの pull は時間あたり 100 イメージ(認証)、200 イメージ(認証された無料)。非認証は IP ベース。
無料 organization の unlimited public repo は維持されるが、非公開リポジトリ数と自動ビルドは制限。
結果：OSS プロジェクトは GHCR、Quay.io、ECR Public に分散。Docker Hub は依然として「デフォルト destination」だが「唯一の destination」ではない。

それでも Docker Hub である理由

Discoverability — 最初に探す場所。brand recognition。
Official Images — 長年積み上げられた検証済みカタログ。
Docker Desktop 統合 — docker login 一本で push。
自動ビルド(Automated Build) — GitHub/GitLab 連携ビルド。

`docker push` 基本フロー

# 1. ログイン
docker login docker.io
# Username、Password (または PAT)

# 2. tag
docker tag myapp:latest myorg/myapp:v1.0.0

# 3. push
docker push myorg/myapp:v1.0.0

# 4. pull (他から)
docker pull myorg/myapp:v1.0.0

Pull-through cache の台頭

レジストリ hop を減らすために、多くのチームは社内 Harbor/Zot を Docker Hub の pull-through cache に置く。一度受け取ったイメージは社内にキャッシュされ、次回以降は Docker Hub の rate limit を気にする必要がない。

# Harbor config — Docker Hub proxy
proxy:
  remote_url: https://registry-1.docker.io
  username: ""
  password: ""

Docker Hub の現在地

無料 OSS 単一正典だった時代は終わった。 しかし「公開イメージを人に露出させたいときに無視できない場所」という立ち位置は維持されている。2026 年のパターンはよくこうだ：GHCR にビルド・push → Docker Hub にも mirror → README に両方を表記。

第 3 章 · GitHub Container Registry (GHCR) — GH Actions フレンドリー

GHCR は GitHub Packages のコンテナ部分だ。2021 年 GA 以降、2026 年には OSS レジストリの事実上の標準になった。

GHCR の強み

GitHub Actions と一体 — GITHUB_TOKEN で別途資格情報なしに push。OIDC で外部インフラにも federate。
Public イメージは無料 — 保管と転送量は無制限。
リポジトリ権限を自動継承 — コード repo にアクセスできれば、イメージも pull できる。
OCI 1.1 完全対応 — Cosign signature、SBOM attachment、multi-arch がすべて自然に動く。

Actions から push する標準パターン

# .github/workflows/build.yml
name: build-and-push
on:
  push:
    branches: [main]
permissions:
  contents: read
  packages: write
  id-token: write   # OIDC 用
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: $GITHUB_ACTOR
          password: $GITHUB_TOKEN
      - uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/myorg/myapp:latest
          platforms: linux/amd64,linux/arm64

`ghcr.io/owner/image` 命名規則

GHCR のイメージパスは決まった形式だ：

ghcr.io/USERNAME/IMAGE_NAME(個人アカウント)
ghcr.io/ORG_NAME/IMAGE_NAME(組織アカウント)

このシンプルさが強力だ。git clone github.com/foo/bar したユーザーは docker pull ghcr.io/foo/bar もできる。

Private イメージの価格

Private イメージは GitHub プランに紐づく。
Storage と data transfer 費用が課金され、GitHub plan に応じた無料 quota がある。
無料 quota を超えると GB-month ベースで課金。

GHCR の制約

Pull 性能 — Docker Hub とほぼ同等、ただしトラフィック急増は Cloudflare cache に依存。
自社ホスティング不可 — マネージド only。
Tag immutability — repository-wide のみ、細かい policy は不足。

OSS マイグレーションの標準経路

Docker Hub から GHCR に移行する OSS プロジェクトの標準経路：

GitHub Actions でマルチアーキテクチャビルド。
ghcr.io/owner/project:tag に push。
README の pull コマンドを GHCR 優先で更新。
Docker Hub にも mirror push(二重掲載)。
Cosign keyless で signature を添付。

覚えておく一文：「GHCR は GitHub Actions を使う OSS の事実上の標準である。ビルド資格情報 1 行で push が終わる」

第 4 章 · GitLab Container Registry

GitLab 内蔵のコンテナレジストリは、別途設定なしに GitLab プロジェクトごとについてくる。

GitLab Registry の強み

プロジェクト単位の自動分離 — registry.gitlab.com/group/project/image:tag パスそのまま。
CI/CD との深い統合 — $CI_REGISTRY、$CI_REGISTRY_USER、$CI_REGISTRY_PASSWORD 環境変数が自動注入。
Cleanup policy — プロジェクトごとに retention rule を GUI で設定。
Self-managed GitLab も同じ — GitLab CE を社内に入れればレジストリも一緒に。

`.gitlab-ci.yml` 標準 push パターン

build:
  image: docker:24.0.5
  services:
    - docker:24.0.5-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - docker tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA $CI_REGISTRY_IMAGE:latest
    - docker push $CI_REGISTRY_IMAGE:latest

Dependency Proxy

GitLab は Docker Hub の pull-through proxy を group 単位で内蔵している。

# Docker Hub の nginx を GitLab proxy 経由で取得
docker pull gitlab.com/myorg/dependency_proxy/containers/nginx:latest

GitLab グループ単位の認証で、Docker Hub rate limit を回避する。

Cleanup Policy

# プロジェクト設定 > Packages and registries > Container Registry
# Cleanup policy (UI で設定、API/Terraform でも可能)
keep_n_tags_older_than: 1d
older_than: 30d
name_regex_keep: "release-.*"
name_regex_delete: ".*"

90% のユースケースをカバーするシンプルな policy エンジン。

GitLab Registry の現在地

GitLab をすでに使っているチームの自然な選択だ。CI と権限モデルが 1 か所に統合される。Self-managed でも同じ経験。ただし GitLab 外のユーザーへの discoverability は GHCR より低い。

第 5 章 · AWS ECR + ECR Public — 無料 Quay 代替

ECR(Elastic Container Registry)は AWS の private コンテナレジストリだ。2020 年に ECR Public が追加され、public 領域もカバーする。

ECR の強み

IAM 統合 — IAM role/policy ベースの精密認証。EKS pod に IRSA(IAM Roles for Service Accounts)で資格情報を注入。
Cross-region replication — マルチリージョン自動複製。
イメージスキャン内蔵 — Amazon Inspector 統合、CVE 自動検査。
Pull-through cache — Docker Hub、GHCR、Quay、mcr.microsoft.com をキャッシュ。
Lifecycle policy — JSON DSL で retention policy。

`aws ecr get-login-password` フロー

# 1. ログイン (12 時間有効トークン)
aws ecr get-login-password --region us-east-1 \
  | docker login --username AWS --password-stdin \
  123456789012.dkr.ecr.us-east-1.amazonaws.com

# 2. repository 作成 (自動作成も可能)
aws ecr create-repository --repository-name myapp

# 3. push
docker tag myapp:latest 123456789012.dkr.ecr.us-east-1.amazonaws.com/myapp:v1
docker push 123456789012.dkr.ecr.us-east-1.amazonaws.com/myapp:v1

Lifecycle Policy 例

{
  "rules": [
    {
      "rulePriority": 1,
      "description": "Keep last 10 production images",
      "selection": {
        "tagStatus": "tagged",
        "tagPrefixList": ["prod-"],
        "countType": "imageCountMoreThan",
        "countNumber": 10
      },
      "action": { "type": "expire" }
    },
    {
      "rulePriority": 2,
      "description": "Expire untagged after 7 days",
      "selection": {
        "tagStatus": "untagged",
        "countType": "sinceImagePushed",
        "countUnit": "days",
        "countNumber": 7
      },
      "action": { "type": "expire" }
    }
  ]
}

ECR Public — 無料 OSS ホスティング

public.ecr.aws/ は AWS アカウント 1 つで OSS イメージを無料でグローバルホスティングできる。

保管無料 (50 GB / repo 推奨上限)。
Data transfer 無料(anonymous pull も無料)。
別ドメイン(public.ecr.aws/aws/amazonlinux:2023 のような)。

OSS プロジェクトが Docker Hub rate limit と GHCR private 費用を回避するために ECR Public を追加するパターンが一般的だ。

ECR の制約

AWS lock-in — multi-cloud 使用時は別途 push が必要。
リクエスト量ベース費用 — pull リクエストにも価格が付くことがある(public は無料)。
UI はコンソール only — Harbor/GitLab のようなフル GUI なし。

ECR の現在地

AWS で EKS・ECS・Lambda を回すチームのデフォルト。 IRSA との結合が圧倒的にきれいだ。OSS は ECR Public を補助 destination として置くのがよい。

第 6 章 · Google Artifact Registry — GCR 後継

Google Artifact Registry(AR)は Google Container Registry(GCR)の公式後継だ。GCR(gcr.io)は deprecated になり、Artifact Registry への移行が強く推奨されている。

AR が GCR を置き換えた理由

多形式対応 — コンテナだけでなく Maven、npm、Python、Go、Helm、Debian、RPM、Apt まで 1 つのレジストリで。
VPC Service Controls — ネットワーク境界 policy。
CMEK(顧客管理暗号化キー) — 細かい暗号化制御。
Regional/Multi-regional repo — GCR より精密な地域選択。
IAM 精密権限 — repo 単位の権限分離。

GCR からのマイグレーション

# 既存 gcr.io イメージを AR にマイグレーション
gcloud artifacts docker upgrade migrate \
  --projects=my-project

# 新 AR repo 作成
gcloud artifacts repositories create myrepo \
  --repository-format=docker \
  --location=us-central1 \
  --description="Docker repo"

# 認証ヘルパー設定
gcloud auth configure-docker us-central1-docker.pkg.dev

# push
docker tag myapp:latest \
  us-central1-docker.pkg.dev/my-project/myrepo/myapp:v1
docker push us-central1-docker.pkg.dev/my-project/myrepo/myapp:v1

GKE Workload Identity Federation

# Kubernetes ServiceAccount -> GCP ServiceAccount マッピング
apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-sa
  namespace: default
  annotations:
    iam.gke.io/gcp-service-account: my-gcp-sa@my-project.iam.gserviceaccount.com

これにより GKE pod が別途 secret なしで AR から pull する。

AR の強み

Container Analysis 統合 — 自動 vulnerability scan。
Binary Authorization — admission control で署名されたイメージのみ deploy を許可。
Cosign 対応 — keyless 署名を GAR に添付。
Remote/Virtual repo — Docker Hub の pull-through proxy。

AR の現在地

GKE 中心の GCP ユーザーの自然な選択。 Binary Authorization と組み合わせれば、admission 段階で署名・脆弱性・policy を一度に検査できる。

第 7 章 · Azure Container Registry (ACR)

ACR は Azure のマネージドコンテナレジストリだ。AKS、App Service、Functions、Container Apps など Azure のあらゆるコンテナワークロードのデフォルト source。

ACR の強み

Geo-replication — Premium ティアでグローバル自動複製、single endpoint URL。
ACR Tasks — レジストリ内ビルド(クラウドサイドビルド)。
Content trust(Notary v1) と Cosign の両方を対応。
Helm chart、OCI artifact 対応。
Private link — 完全なプライベートネットワークアクセス。

`az acr login` フロー

# 1. ログイン (Azure CLI 資格情報を使用)
az acr login --name myregistry

# 2. ACR リポへ push
docker tag myapp:latest myregistry.azurecr.io/myapp:v1
docker push myregistry.azurecr.io/myapp:v1

# 3. AKS で pull (Managed Identity)
# ImagePullSecret なしで IAM 統合を使用

ACR Tasks — レジストリ内ビルド

# Git commit に対応して自動ビルド
az acr task create \
  --name buildmyapp \
  --registry myregistry \
  --image myapp:$ID \
  --context https://github.com/myorg/myapp.git \
  --file Dockerfile \
  --git-access-token $TOKEN

このモデルではビルドマシンを別途持つ必要がない。Buildah ベースの cloud-side build。

Retention policy

az acr config retention update \
  --registry myregistry \
  --status enabled \
  --days 30 \
  --type UntaggedManifests

韓国 / 日本での使用

カカオペイは Azure をメインクラウドの 1 つとして使用し、ACR で社内イメージを管理している(公開された社内技術ブログに基づく)。
日本のゲーム会社の一部も Azure をメインに据えて ACR を使用している。

ACR の現在地

AKS・Azure DevOps を使うチームのデフォルト。 Geo-replication が single endpoint URL で動作する点は ECR より運用がシンプルだ。

第 8 章 · Harbor (CNCF graduated) — 自社ホスティングの標準

Harbor は VMware が始めて CNCF に寄贈された OSS レジストリだ。2020 年に CNCF graduated プロジェクトとなり、2026 年には自社ホスティングの標準になった。

Harbor が自社ホスティング標準になった理由

フル GUI — ユーザー・プロジェクト・権限・policy・複製まで Web UI で。
Project 単位の隔離 — multi-tenancy。
Vulnerability scanner 統合 — Trivy 標準、Clair・Snyk・Anchore も plugin。
Cosign・Notary 対応 — 署名検証を admission 段階に統合。
Replication policy — Docker Hub、GHCR、ECR、GAR、ACR、Quay などに単方向/双方向複製。
Proxy cache — 外部レジストリの pull-through cache。
Robot account — CI 用 long-lived 資格情報、権限の精密調整。

Harbor 設置 (Helm)

helm repo add harbor https://helm.goharbor.io
helm install harbor harbor/harbor \
  --namespace harbor --create-namespace \
  --set expose.type=ingress \
  --set expose.ingress.hosts.core=harbor.example.com \
  --set externalURL=https://harbor.example.com \
  --set persistence.persistentVolumeClaim.registry.size=200Gi \
  --set persistence.persistentVolumeClaim.chartmuseum.size=10Gi \
  --set persistence.persistentVolumeClaim.trivy.size=20Gi

Project · Robot · Replication の典型構造

[Harbor Project: production]
  - Member: dev-team (Developer)
  - Member: ops-team (Master)
  - Robot: ci-build (push)
  - Robot: ci-deploy (pull)
  - Vulnerability Scanner: Trivy
  - Cosign Signature: required (deploy 時に検証)
  - Replication:
      - to: ghcr.io/myorg (push, on push)
      - from: docker.io/library/* (pull, on demand)

Pull-through Proxy Cache

# Harbor Project = "dockerhub-proxy"
# 外部 endpoint: https://registry-1.docker.io
# Cache TTL: 24h

# ユーザー使用:
# docker pull harbor.example.com/dockerhub-proxy/library/nginx:latest
# 初回 pull -> Docker Hub を経由してキャッシュ
# 2 回目 pull -> Harbor 内部から直接

このパターン 1 つで Docker Hub rate limit が解決する。

Harbor の制約

運用負担 — Postgres・Redis・Trivy・Notary・Chartmuseum などの複数コンポーネント。
upgrade が難しい — メジャーバージョン間で schema 変更がしばしばある。
独自バックアップ戦略が必要 — イメージ blob とメタデータの両方。

Harbor の現在地

自社ホスティングコンテナレジストリのデフォルト。 GUI と replication が強力で、運用チームが非開発者でも使用可能。大規模社内インフラでよく使われる。

第 9 章 · Quay (Red Hat / IBM)

Quay は Red Hat が買収したコンテナレジストリだ。Quay.io はマネージド SaaS、Red Hat Quay は自社ホスティング enterprise edition、Project Quay は OSS upstream。

Quay の強み

OpenShift と一体 — OpenShift 使用時の自然な選択。
Quay.io OSS free — public repository は無料(特に Red Hat ecosystem)。
OSS organization 無料 unlimited private — 一部の OSS プロジェクトに提供。
Clair scanner 内蔵 — Quay チームが作った vulnerability scanner。
Geo-replication — multi-region replication を内蔵。
Notary v2 + Cosign 対応。

Quay 使用パターン

# Quay.io
docker login quay.io
docker push quay.io/myorg/myapp:v1

# Self-managed Red Hat Quay
docker login quay.mycompany.com
docker push quay.mycompany.com/team/myapp:v1

Robot Account モデル

Harbor と似ている。CI 用の長期トークンを発行し、repository 単位で権限を付与。

Quay の現在地

Red Hat ecosystem(OpenShift、RHEL)ではデフォルト。
自社ホスティング enterprise で Harbor と二分。
OSS ホスティングで Docker Hub の無料代替の 1 つ。

第 10 章 · Zot (CNCF incubating) — OCI-only シンプル

Zot は OCI-only コンテナレジストリだ。2024 年に CNCF incubating プロジェクトとなり、「シンプル・小さい・速い」自社ホスティング選択肢として浮上した。

Zot がシンプルさを武器に浮上した理由

OCI distribution spec のみ実装 — Docker registry v1 なし、独自拡張なし。
単一バイナリ — Go 単一ファイル。Postgres・Redis 依存なし。
読み取り専用モード — air-gapped 環境に適合。
Sync — 他のレジストリから sync して mirror。
メタデータ plugin — Cosign signature、SBOM 検索。

Zot 実行

# 単一 binary
./zot serve config.json

# config.json
{
  "storage": {
    "rootDirectory": "/var/lib/zot"
  },
  "http": {
    "address": "0.0.0.0",
    "port": "5000"
  },
  "log": {
    "level": "info"
  },
  "extensions": {
    "search": { "enable": true },
    "sync": {
      "enable": true,
      "registries": [
        {
          "urls": ["https://docker.io"],
          "content": [{ "prefix": "library/nginx" }],
          "onDemand": true
        }
      ]
    }
  }
}

これがすべて。Postgres も Redis も別途コンポーネントもない。

Zot の現在地

Air-gapped 環境 — 単一 binary、読み取り専用モード。
Edge / IoT — 小さいリソースで動作。
開発環境のローカル registry — Harbor が過剰な場合。
GitHub Actions runner に紐付けた使い捨て registry として — 単体テスト。

覚えておく一文：「Harbor がフル GUI 総合レジストリなら、Zot は OCI distribution spec の reference のようなシンプルさだ」

第 11 章 · JFrog Artifactory — 全言語エンタープライズ

Artifactory は JFrog の universal アーティファクトレジストリだ。Docker コンテナだけでなく Maven・Gradle・npm・NuGet・PyPI・CocoaPods・Conan・Cargo・Helm などあらゆるパッケージマネージャを 1 か所で管理する。

Artifactory の強み

全言語を 1 か所で — コンテナだけ分ける必要がない。
Remote repo — あらゆる外部レジストリの pull-through cache。
Virtual repo — 複数の repo を 1 つの endpoint にまとめる。
Build info 追跡 — どのビルドがどのアーティファクトを生み出したかのグラフ。
JFrog Xray — vulnerability scanning、SBOM 統合。
JFrog Distribution — グローバル配信 entry point。
JFrog Pipelines — CI/CD 統合。

Artifactory の現在地

大型エンタープライズ — コンテナ以外のアーティファクトが多い時。
金融、通信、製造業 — Java とコンテナを一緒に管理する時。
ライセンス費用負担が可能 — 価格が負担になれば Harbor が代替。

Artifactory CE — Community Edition

Docker のみ無料。フル機能は有償ライセンスが必要。

第 12 章 · Distribution (CNCF) — OCI 参照実装

Distribution は Docker が作った OSS レジストリ実装だ。2018 年に CNCF へ寄贈され Distribution として再出発、OCI distribution spec の reference implementation の役割を担う。

Distribution の現在地

registry:2 コンテナ — 最もシンプルな社内レジストリ。
OCI spec reference — spec 変更時に最初に実装される。
他のレジストリの base — Harbor、Zot、GHCR などが内部的に distribution またはその fork を使用。

Distribution 実行

# 最もシンプルな社内 registry
docker run -d -p 5000:5000 --restart=always \
  -v /opt/registry-data:/var/lib/registry \
  --name registry \
  registry:2

# 使用
docker tag myapp:latest localhost:5000/myapp:v1
docker push localhost:5000/myapp:v1

Distribution の制約

認証/権限モデルなし — basic auth または reverse proxy で自前実装。
UI なし — 別途 frontend が必要。
scanner なし — 別途ツール統合が必要。

Distribution の現在地

開発用の単一ノード registry。
他のレジストリの building block。
OCI spec 学習や reference 実装確認用。

ほとんどの production 事例では Harbor・Zot・GHCR へ移動した。

第 13 章 · Sonatype Nexus

Nexus Repository は Sonatype の universal アーティファクトレジストリだ。Artifactory と同じ位置 — あらゆるパッケージマネージャ + Docker。

Nexus の強み

Nexus Repository OSS — 無料、Docker proxy/host/group 対応。
Maven 生態系の事実上の標準 — Java バックエンド企業はすでに Nexus を持っている。
相対的に軽い — Artifactory より運用シンプル。
Nexus IQ Server — vulnerability・license・policy 検査。

Nexus 使用

# Nexus に hosted docker repo を作成後
docker login nexus.example.com:8082
docker push nexus.example.com:8082/myapp:v1

Nexus の現在地

すでに Nexus を使う Maven/Gradle チーム — Docker も自然に追加。
Artifactory の無料代替。
ただしコンテナ専用機能(scanner、replication)は Harbor に比べて弱い。

第 14 章 · Cosign + Sigstore — イメージ署名標準

Sigstore は OSS サプライチェーンセキュリティのための非営利プロジェクトだ。Cosign はそのコンテナイメージ署名ツール。

Sigstore の構成要素

Cosign — 署名/検証 CLI。
Fulcio — short-lived 証明書 CA (OIDC identity -> X.509 cert)。
Rekor — append-only transparency log。
TUF — root of trust 配布。

Keyless 署名 — 2026 年のデフォルト

# 1. キーなしで署名 (OIDC identity を使用)
cosign sign ghcr.io/myorg/myapp:v1
# ブラウザが開く -> GitHub/Google/Microsoft OIDC ログイン
# Fulcio が short-lived cert を発行
# Rekor に署名を記録
# Cosign が cert + signature をレジストリに push

# 2. 検証
cosign verify ghcr.io/myorg/myapp:v1 \
  --certificate-identity=user@example.com \
  --certificate-oidc-issuer=https://accounts.google.com

キーを持ち歩く必要がない。OIDC identity がそのまま署名者だ。

GitHub Actions 自動署名

permissions:
  id-token: write    # OIDC token 発行用
  contents: read
  packages: write
jobs:
  build-and-sign:
    runs-on: ubuntu-latest
    steps:
      - uses: docker/build-push-action@v5
        id: build
        with:
          push: true
          tags: ghcr.io/myorg/myapp:latest
      - uses: sigstore/cosign-installer@v3
      - run: cosign sign --yes ghcr.io/myorg/myapp@$DIGEST
        env:
          DIGEST: ${{ steps.build.outputs.digest }}

GitHub Actions の OIDC identity が署名に埋め込まれる。検証時に --certificate-identity-regexp=https://github.com/myorg/.* で「この organization の GitHub Actions がビルドしたもの」であることを保証。

Admission Control 統合

# Kyverno policy 例
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-cosign-signature
spec:
  validationFailureAction: enforce
  rules:
    - name: verify-image
      match:
        any:
          - resources:
              kinds: [Pod]
      verifyImages:
        - imageReferences:
            - "ghcr.io/myorg/*"
          attestors:
            - entries:
                - keyless:
                    subject: "https://github.com/myorg/.*"
                    issuer: "https://token.actions.githubusercontent.com"

この policy 1 つで、クラスターには「myorg の GitHub Actions でビルドされたイメージ」のみが deploy される。

Cosign + Sigstore の現在地

2026 年のコンテナ署名の事実上の標準。 Docker Content Trust(Notary v1)は事実上 deprecated、Notary v2 は OCI spec 標準化進行中。実戦では Cosign が最も広く使われる。

第 15 章 · in-toto / SBOM (CycloneDX, SPDX) / Notary v2 — サプライチェーンセキュリティ

署名だけでは足りない。「誰がこのイメージをビルドしたか?」の上に「このイメージの中に何が入っているか?」「このイメージがどんな過程を経てビルドされたか?」が必要だ。

in-toto — サプライチェーン attestation

in-toto はビルドパイプライン各段階の attestation を作る framework だ。

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{
    "name": "ghcr.io/myorg/myapp",
    "digest": { "sha256": "abc123..." }
  }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://github.com/Attestations/GitHubActions/v1",
      "externalParameters": {
        "workflow": ".github/workflows/build.yml",
        "ref": "refs/heads/main"
      }
    },
    "runDetails": {
      "builder": { "id": "https://github.com/actions/runner@v2.319.0" },
      "metadata": {
        "invocationId": "https://github.com/myorg/myapp/actions/runs/12345"
      }
    }
  }
}

SLSA(Supply-chain Levels for Software Artifacts) Level 3 ビルドの核心。

SBOM — Software Bill of Materials

イメージ内のすべての依存関係のリスト。

CycloneDX

OWASP が作った SBOM 標準。

# Syft で SBOM 生成 (CycloneDX フォーマット)
syft ghcr.io/myorg/myapp:v1 -o cyclonedx-json > sbom.cdx.json

# イメージに attach (Cosign)
cosign attach sbom --sbom sbom.cdx.json \
  --type cyclonedx ghcr.io/myorg/myapp:v1

SPDX

Linux Foundation の SBOM 標準。

syft ghcr.io/myorg/myapp:v1 -o spdx-json > sbom.spdx.json
cosign attach sbom --sbom sbom.spdx.json \
  --type spdx ghcr.io/myorg/myapp:v1

両フォーマットとも ISO 標準化済み。どちらを選んでもツール互換性は良い。CycloneDX は vulnerability 統合が強く、SPDX はライセンス追跡が強い。

Notary v2 — OCI 署名標準

Notary v1(Docker Content Trust)は事実上 deprecated。Notary v2 は OCI artifact spec の上で署名を標準化する。

OCI artifact spec を活用 — 署名を別の manifest として保存。
ACR、Quay でデフォルト対応 — notation CLI で署名/検証。
Cosign と共存 — Notary v2 spec に Cosign が alternate signer として登録。

# Notation CLI (Notary v2 reference impl)
notation sign --plugin azure-kv \
  --id "https://myvault.vault.azure.net/keys/mykey/abc123" \
  myregistry.azurecr.io/myapp:v1

notation verify \
  --signature myregistry.azurecr.io/myapp:v1

in-toto / SBOM / Notary v2 の現在地

in-toto — SLSA Level 3 ビルドの証言。SLSA L3 を達成するには事実上必須。
SBOM — 規制(EO 14028、EU CRA)対応に必須。
Notary v2 — ACR・Quay 中心で採用。Cosign の方が広く使われているが、ecosystem 分布は近い。

覚えておく一文：「2026 年のサプライチェーンセキュリティは、署名(Cosign) + 証言(in-toto) + 部品表(SBOM)の 3 点セットだ」

第 16 章 · ORAS — generic OCI artifact

ORAS(OCI Registry As Storage)はコンテナイメージ以外のすべて — Helm chart、WASM module、ML model、Terraform module、OPA bundle — を OCI artifact として保管するツールだ。

ORAS の動機

OCI distribution spec はイメージだけでなく任意の artifact を保管できる。しかしクライアントツールが不足していた。ORAS がその穴を埋める。

# 任意のファイルを OCI artifact として push
oras push ghcr.io/myorg/wasm-modules:v1 \
  ./module.wasm:application/wasm

# pull
oras pull ghcr.io/myorg/wasm-modules:v1

# manifest 確認
oras manifest fetch ghcr.io/myorg/wasm-modules:v1

ORAS の活用事例

Helm chart — helm push my-chart-1.0.0.tgz oci://registry.example.com/charts
WASM module — wasmCloud、Krustlet が OCI registry から module を pull。
ML model — KServe、ModelMesh が model を OCI artifact として配布。
OPA bundle、Cosign signature、SBOM — すでに OCI artifact だ。

ORAS の現在地

コンテナレジストリが universal artifact registry に進化する推進力。 Helm・WASM・ML model などがすべて OCI registry の上に移っていく流れの中心。

第 17 章 · 韓国 / 日本 — トス、カカオペイ、メルカリ、LINE

韓国

トス — 社内自社レジストリを運用(自社ビルドの社内ツール + Harbor ベース)し、OSS イメージの pull-through proxy としても活用。社内開発カンファレンスの発表で、社内ビルドパイプラインが自社 registry に push される構造が共有された。
カカオペイ — Azure をメインクラウドの 1 つとして使用し、ACR を中核のコンテナレジストリとして運用(公開された社内技術ブログに基づく)。
ネイバー / LINE 韓国 — マルチクラウド(NCP 含む)と社内 registry の組み合わせ。
韓国の OSS プロジェクト — GHCR 優先、Docker Hub mirror パターンが増加。

日本

メルカリ — マルチクラウド + GitHub Actions + GHCR を中心とするビルドパイプライン。一部ワークロードは GCP Artifact Registry に直接。
LINE — 社内独自コンテナプラットフォーム上に独自レジストリを運用。Harbor ベース構造が社内カンファレンス発表で言及されたことがある。
サイバーエージェント / DeNA — GKE・EKS 混合、GAR・ECR 混合。
日本の OSS プロジェクト — GHCR + Docker Hub 二重掲載が多い。

韓国・日本共通パターン

社内コアインフラは自社ホスティング(Harbor)またはマネージド(ACR/ECR/GAR) + 外部 mirror として GHCR。
OSS ビルドは事実上 GitHub Actions + GHCR + Cosign keyless が標準。
Docker Hub は「公開露出用の補助 destination」。

第 18 章 · 誰が何を選ぶべきか — OSS / スタートアップ / エンタープライズ / エアギャップ

OSS プロジェクト — GHCR

ビルド無料(Actions)、保管無料(public)。
Cosign keyless 署名が OIDC で自動。
README に ghcr.io/org/project の 1 行で案内。
追加で Docker Hub にも mirror push(ユーザー露出用)。

スタートアップ — メインクラウドのマネージド + GHCR

AWS なら ECR、GCP なら GAR、Azure なら ACR。
CI は GitHub Actions -> GHCR -> メインクラウド registry に mirror。
運用負担を最小化。

中堅企業 — Harbor + メインクラウド

社内 Harbor 1 つ、メインクラウドマネージド 1 つ。
Pull-through proxy で Docker Hub rate limit を回避。
Cosign + Trivy で admission control。

大型エンタープライズ — Artifactory または Harbor + マルチクラウド

コンテナ以外のアーティファクト(Maven、npm)が多ければ Artifactory。
コンテナ中心なら Harbor + クラウドマネージド。
Cosign + Notary v2 + SBOM + in-toto attestation のフルスタック。

エアギャップ / 政府・金融セキュリティ網 — Zot または Harbor offline

Zot の read-only mode + 単一 binary が air-gapped に強い。
Harbor の offline installer + replication for sync。
SBOM、Cosign signature まで air-gapped で sync。

意思決定マトリクス

条件	推奨
OSS プロジェクト	GHCR (+ Docker Hub mirror)
AWS 単一クラウド	ECR (+ ECR Public for OSS)
GCP 単一クラウド	Google Artifact Registry
Azure 単一クラウド	ACR
GitLab 使用中	GitLab Container Registry
OpenShift 使用中	Red Hat Quay
自社ホスティング、フル GUI 必要	Harbor
自社ホスティング、シンプルさ優先	Zot
全言語 + コンテナ統合	Artifactory または Nexus
Air-gapped	Zot read-only または Harbor offline
署名 / 検証	Cosign + Sigstore
サプライチェーン attestation	in-toto + SLSA
部品表	CycloneDX または SPDX
Helm/WASM/ML model 保管	ORAS + OCI registry

エピローグ — レジストリはすでにサプライチェーンセキュリティの中心だ

2026 年のコンテナレジストリは、もはや「イメージを保管する場所」ではない。

イメージに署名が付き(Cosign)、
イメージに部品表が付き(SBOM)、
イメージにビルド証言が付き(in-toto)、
イメージが複数レジストリへ mirror され(Harbor replication)、
イメージがadmission 段階で検証され(Kyverno、Binary Authorization)、
コンテナ以外のすべて(Helm、WASM、ML model)も同じ registry の上に住む(ORAS)。

レジストリ 1 つを選ぶのではなく、サプライチェーンセキュリティトポロジの中心ノードを設計する仕事になった。

そしてツール選択は単純な機能表ではなく、クラウド選択 + CI 選択 + 運用能力 + 規制要件の関数だ。本稿がその関数の入力値を捉える助けになれば幸いだ。

最後の一文：レジストリは終点ではなく始点だ。 イメージがその中に入った瞬間、サプライチェーンのすべての鎖がそこから検証される。

参考 / References

Docker Hub Documentation — https://docs.docker.com/docker-hub/
Docker Hub Subscription Pricing — https://www.docker.com/pricing/
GitHub Container Registry Docs — https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry
GHCR for Actions — https://docs.github.com/en/actions/publishing-packages/publishing-docker-images
GitLab Container Registry — https://docs.gitlab.com/ee/user/packages/container_registry/
GitLab Dependency Proxy — https://docs.gitlab.com/ee/user/packages/dependency_proxy/
AWS ECR User Guide — https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html
ECR Public Gallery — https://gallery.ecr.aws/
ECR Lifecycle Policies — https://docs.aws.amazon.com/AmazonECR/latest/userguide/LifecyclePolicies.html
Google Artifact Registry — https://cloud.google.com/artifact-registry/docs
GAR Migration from GCR — https://cloud.google.com/artifact-registry/docs/transition/transition-from-gcr
Binary Authorization — https://cloud.google.com/binary-authorization
Azure Container Registry — https://learn.microsoft.com/en-us/azure/container-registry/
ACR Tasks — https://learn.microsoft.com/en-us/azure/container-registry/container-registry-tasks-overview
Harbor Project — https://goharbor.io/
Harbor Docs — https://goharbor.io/docs/
CNCF Harbor Graduation Announcement — https://www.cncf.io/announcements/2020/06/23/cloud-native-computing-foundation-announces-harbor-graduation/
Project Quay — https://www.projectquay.io/
Red Hat Quay — https://www.redhat.com/en/technologies/cloud-computing/quay
Zot Registry — https://zotregistry.dev/
CNCF Zot Incubation — https://www.cncf.io/projects/zot/
JFrog Artifactory — https://jfrog.com/artifactory/
Sonatype Nexus Repository — https://www.sonatype.com/products/sonatype-nexus-repository
CNCF Distribution — https://distribution.github.io/distribution/
OCI Distribution Spec — https://github.com/opencontainers/distribution-spec
OCI Image Spec — https://github.com/opencontainers/image-spec
Sigstore — https://www.sigstore.dev/
Cosign Docs — https://docs.sigstore.dev/cosign/
Rekor Transparency Log — https://docs.sigstore.dev/rekor/overview
Fulcio CA — https://docs.sigstore.dev/fulcio/overview
in-toto — https://in-toto.io/
in-toto attestations — https://github.com/in-toto/attestation
SLSA Framework — https://slsa.dev/
CycloneDX — https://cyclonedx.org/
SPDX — https://spdx.dev/
Syft (SBOM tool) — https://github.com/anchore/syft
Notary Project (v2) — https://notaryproject.dev/
ORAS Project — https://oras.land/
Kyverno verifyImages — https://kyverno.io/docs/policy-types/verify-images/
Trivy Scanner — https://trivy.dev/

プロローグ — レジストリはイメージ倉庫ではない

第 1 章 · 2026 年のコンテナレジストリ地図 — マネージド / 自社ホスティング / 無料 OSS の 3 陣営

第 2 章 · Docker Hub — 元祖、価格変更以降

2026 年の Docker Hub の立ち位置

価格変更のインパクト

それでも Docker Hub である理由

docker push 基本フロー

Pull-through cache の台頭

Docker Hub の現在地

第 3 章 · GitHub Container Registry (GHCR) — GH Actions フレンドリー

GHCR の強み

Actions から push する標準パターン

ghcr.io/owner/image 命名規則

Private イメージの価格

GHCR の制約

OSS マイグレーションの標準経路

第 4 章 · GitLab Container Registry

GitLab Registry の強み

.gitlab-ci.yml 標準 push パターン

Dependency Proxy

Cleanup Policy

GitLab Registry の現在地

第 5 章 · AWS ECR + ECR Public — 無料 Quay 代替

ECR の強み

aws ecr get-login-password フロー

Lifecycle Policy 例

ECR Public — 無料 OSS ホスティング

ECR の制約

ECR の現在地

第 6 章 · Google Artifact Registry — GCR 後継

AR が GCR を置き換えた理由

GCR からのマイグレーション

GKE Workload Identity Federation

AR の強み

AR の現在地

第 7 章 · Azure Container Registry (ACR)

ACR の強み

az acr login フロー

ACR Tasks — レジストリ内ビルド

Retention policy

韓国 / 日本での使用

ACR の現在地

第 8 章 · Harbor (CNCF graduated) — 自社ホスティングの標準

Harbor が自社ホスティング標準になった理由

Harbor 設置 (Helm)

Project · Robot · Replication の典型構造

Pull-through Proxy Cache

Harbor の制約

Harbor の現在地

第 9 章 · Quay (Red Hat / IBM)

Quay の強み

Quay 使用パターン

Robot Account モデル

Quay の現在地

第 10 章 · Zot (CNCF incubating) — OCI-only シンプル

Zot がシンプルさを武器に浮上した理由

Zot 実行

Zot の現在地

第 11 章 · JFrog Artifactory — 全言語エンタープライズ

Artifactory の強み

Artifactory の現在地

Artifactory CE — Community Edition

第 12 章 · Distribution (CNCF) — OCI 参照実装

Distribution の現在地

Distribution 実行

Distribution の制約

Distribution の現在地

第 13 章 · Sonatype Nexus

Nexus の強み

Nexus 使用

Nexus の現在地

第 14 章 · Cosign + Sigstore — イメージ署名標準

Sigstore の構成要素

Keyless 署名 — 2026 年のデフォルト

GitHub Actions 自動署名

Admission Control 統合

Cosign + Sigstore の現在地

第 15 章 · in-toto / SBOM (CycloneDX, SPDX) / Notary v2 — サプライチェーンセキュリティ

in-toto — サプライチェーン attestation

SBOM — Software Bill of Materials

`docker push` 基本フロー

`ghcr.io/owner/image` 命名規則

`.gitlab-ci.yml` 標準 push パターン

`aws ecr get-login-password` フロー

`az acr login` フロー