Azure Container Registry（ACR）設計入門｜SKU選択・ACR Tasks・AKS統合でコンテナイメージ管理を本番運用する実践ガイド

AKSやAzure Container AppsへのCI/CDパイプラインを組もうとしたとき、「コンテナイメージをどこに置くか」という問題は避けられない。Docker Hubを使い続けると、匿名プルのRate Limitや組織のセキュリティポリシーがネックになる。オンプレで運用していたプライベートレジストリをそのまま持ち込む選択肢もあるが、証明書管理・冗長化・ストレージ容量の確保と、維持コストが地味に重い。

Azure Container Registry（ACR）はAzureネイティブのプライベートコンテナレジストリで、マネージドIDによるパスワードレス連携・ジオレプリケーション・ACR Tasksによる自動ビルドをまとめて提供する。ただし、SKUの違いを理解せずに使い始めると料金や機能制限で後悔することが多い。

この記事では、ACRのSKU選択の判断基準から、AKSとのマネージドID統合、ACR Tasksを使ったCI/CDへの組み込み、イメージのライフサイクル管理と料金体系まで、本番運用を見据えた実践ポイントを整理する。

コンテナレジストリの選択肢とACRを選ぶ理由

コンテナイメージを置く場所は大きく3つある。

・Docker Hub（パブリック）: 無料で始められるが、匿名プルは6時間あたり100リクエストに制限される（2026年時点）。CI/CDで複数エージェントが並列でプルを走らせると詰まる
・オンプレのプライベートレジストリ（Harbor等）: 自由度は高いが、高可用性構成の維持・証明書更新・ストレージ拡張がすべて自己責任になる
・Azure Container Registry: AzureのAAD（Entra ID）やマネージドIDと直接統合でき、AKS・Azure Container Apps・Azure Pipelinesからパスワードレスでアクセスできる

AWSでAmazon ECRを使っている経験があれば、ACRは同等のポジションにある。Amazon ECRはIAMロールによるアクセス制御が軸だが、ACRはEntra IDとRBAC（ロールベースアクセス制御）が軸になる点が大きな違いだ。

ACRのSKU（Basic・Standard・Premium）の違いと選び方

ACRには3つのSKUがあり、ストレージ容量・スループット・機能の有無が異なる（2026年11月時点の料金）。

・Basic: 開発・検証用のみ。本番のAKSクラスターからプルすると帯域制限でCIが遅くなる場合がある
・Standard: 多くの本番ワークロードでこれで十分。geo-replicationが不要で、プライベートエンドポイントも使わないならStandardを選ぶ
・Premium: マルチリージョン展開・VNet閉域化・コンプライアンス要件（監査ログ・Customer-Managed Key）が必要な場合に選ぶ

【重要】geo-replicationの設計判断

Premiumのgeo-replicationは、複数リージョンにACRのレプリカを作ってプルを最寄りのリージョンから行う機能だ。東南アジアと東日本の両リージョンにAKSクラスターを置くような構成では、プルのレイテンシーを下げられる。ただし、追加リージョンのレプリカには1リージョンあたり月額$1.667/日のコストが加算される。リージョン間のデータ転送量が少ない場合はコストに見合わないケースもあるので、実際のイメージサイズとプル頻度で試算してから有効化する。

ACRリソースの作成とAKSへの接続設定

1. ACRレジストリを作成する

Azure CLIを使ったACRの作成手順は次のとおりだ。

# リソースグループとACR（Standard SKU）を作成する
az group create \
  --name rg-prod-eastjp \
  --location japaneast

az acr create \
  --resource-group rg-prod-eastjp \
  --name myproductionacr \
  --sku Standard \
  --location japaneast

レジストリ名はAzure全体でグローバルに一意である必要があるため、会社名やプロジェクト名を組み込んだ命名にすること。

2. AKSクラスターにACRをアタッチする

AKSからACRへのアクセス設定は、以前は`imagePullSecrets`にDockerクレデンシャルを手動で設定する方法が主流だったが、現在はマネージドIDを使ったアタッチが推奨される。

# 既存AKSクラスターにACRをアタッチ（AcrPullロールを自動付与）
az aks update \
  --resource-group rg-prod-eastjp \
  --name myaks-cluster \
  --attach-acr myproductionacr

このコマンドはAKSのKubelet マネージドIDに対して、ACRへの`AcrPull`ロールを自動で割り当てる。`imagePullSecrets`への手動設定は不要になり、シークレットのローテーション管理から解放される。

Azure Managed Identityの仕組みを理解していると、このアタッチ操作がなぜパスワードレスで動くのかが直感的にわかる。

3. KubernetesマニフェストからACRのイメージを参照する

アタッチ後は、マニフェストのimage欄にACRのFQDN（`<レジストリ名>.azurecr.io/<イメージ名>:<タグ>`）を指定するだけでよい。

# Deployment マニフェスト例
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: myapp
        image: myproductionacr.azurecr.io/myapp:v1.2.0
        # imagePullSecrets の設定は不要

Azure Kubernetes Service（AKS）と組み合わせた構成設計については、AKS入門記事も参照してほしい。

ACR Tasksでイメージビルドを自動化する

ACR Tasksは、ACR上でDockerイメージのビルド・テスト・プッシュを実行できる機能だ。外部のCI/CDサーバーを用意しなくても、コードプッシュをトリガーにビルドが走る。

クイックタスク（手動ビルド）

開発中のイメージを素早く確認したいときに使う。ローカルのDockerデーモンが不要で、Azure側でビルドが完結する。

# カレントディレクトリのDockerfileをACR上でビルドしてプッシュする
az acr build \
  --registry myproductionacr \
  --image myapp:v1.2.0 \
  .

自動タスク（GitHubトリガー）

GitHubリポジトリへのプッシュをトリガーにビルドが自動で走るよう設定できる。GitHub Actionsとの組み合わせでも使われるが、ACR Tasks単体でもトリガー設定が可能だ。

# GitHubのmainブランチへのpushでビルドが自動実行されるタスクを作成
az acr task create \
  --registry myproductionacr \
  --name build-myapp \
  --image myapp:{{.Run.ID}} \
  --context https://github.com/your-org/myapp.git#refs/heads/main \
  --file Dockerfile \
  --git-access-token 

`{{.Run.ID}}`はビルドごとに自動生成される一意のIDで、イメージのタグに使うことで何度ビルドしてもタグが衝突しない。

ベースイメージ更新トリガー

Premiumでは、依存するベースイメージ（例: `mcr.microsoft.com/dotnet/aspnet:8.0`）が更新されたとき、自動的に派生イメージを再ビルドするトリガーも設定できる。セキュリティパッチの適用が自動化されるため、コンプライアンス要件の厳しい環境で重宝する。

イメージのライフサイクル管理（保持ポリシー）

レジストリにプッシュし続けるとストレージ料金がかさむ。ACRには2種類のクリーンアップ機能がある。

・保持ポリシー（Premium専用）: タグなしマニフェストを作成から一定日数（例: 7日）経過後に自動削除する。CI/CDで大量にビルドするとタグなし中間イメージが蓄積しやすいため有効化を推奨する
・purge コマンド（全SKU対応）: `acr purge`をACR Tasksのスケジュールタスクとして週次で実行し、古いタグのイメージを削除する方式。SemVerタグの一定期間経過後の削除にも使える

# 7日以上前のタグなしイメージを削除するスケジュールタスク（週次・日曜0時）
az acr task create \
  --name cleanup-untagged \
  --registry myproductionacr \
  --cmd "acr purge --filter 'myapp:.*' --untagged --ago 7d" \
  --schedule "0 0 * * 0" \
  --context /dev/null

料金の仕組みとコスト試算

ACRの料金は「SKUの日額固定費 + 超過ストレージ料金 + オペレーション料金」で構成される（2026年11月時点・東日本リージョン）。

「オペレーション」はプッシュ・プル・リスト等のAPIコールを指す。規模の小さいサービス（1日数十回プル）では固定費が主なコストになるが、CI/CDで大量のビルドとプルが走る本番環境では、オペレーション料金も無視できない。

コスト試算（想定例）

想定例（開発チーム5名・マイクロサービス構成・1日100回プル）:
・SKU: Standard（月額$20）
・ストレージ使用量: 50 GB → 含まれる範囲内
・月間オペレーション数: 100プル × 30日 = 3,000件 → $0.04
・月額合計（概算）: 約$20

Standardならオペレーション料金は誤差の範囲に収まることが多い。ストレージが100 GBを超える構成では、ライフサイクル管理による古いイメージの削除が重要になる。

よくあるつまずきと対処法

つまずき1: AKSからのプルが「認証エラー」になる

`–attach-acr`を実行したはずなのにAKSからプルできないケースがある。一般的な原因はAKSのマネージドIDに付与されたロール反映の遅延か、ACR名のスペルミスだ。次のコマンドで`AcrPull`ロールが付与されているか確認する。

# AKSのkubelet マネージドIDのオブジェクトIDを確認
az aks show \
  --resource-group rg-prod-eastjp \
  --name myaks-cluster \
  --query "identityProfile.kubeletidentity.objectId" \
  --output tsv

# ACRへのロール割り当てを確認
az role assignment list \
  --assignee <上記のobjectId> \
  --scope /subscriptions/<サブID>/resourceGroups/rg-prod-eastjp/providers/Microsoft.ContainerRegistry/registries/myproductionacr

つまずき2: ACR Tasksのビルドが遅い

ACR Tasksのビルドエージェントはデフォルトで2 vCPU・7 GBメモリの標準エージェントで動く。ビルドに時間がかかる大型イメージではエージェントプールをPremium SKUでカスタム設定することで改善できる。ただしカスタムエージェントプールはPremium専用機能のため、Standard以下では使えない。

つまずき3: Azure Container Appsから接続できない

Azure Container AppsからACRを参照する場合、ACRのAdmin Account（管理者アカウント）を有効にしてクレデンシャルを渡す方式と、マネージドIDを使う方式の2種類がある。セキュリティ観点からマネージドIDを使う方式が推奨されるが、Container AppsのRevision更新時に認証情報が引き継がれない事象が報告されている（Revisionスコープの設定を確認すること）。

つまずき4: プライベートエンドポイント設定後にACR Tasksが失敗する

Premiumでプライベートエンドポイントとネットワークルールによってパブリックアクセスを遮断した後、ACR Tasksが失敗するケースがある。ACR Tasksのビルドエージェントはデフォルトでパブリックネットワーク経由でACRにアクセスするため、VNet統合（プライベートエンドポイントへのルーティング）が別途必要になる。

本記事のまとめ

Azure Container Registry（ACR）の要点を整理する。

AWSのAmazon ECRと比べると、ACRは「Entra IDとRBACを軸にしたアクセス制御」と「ACR Tasksによるネイティブビルド機能」が特徴的だ。既存のAzureリソース（AKS・Container Apps・Azure Pipelines）との統合コストが低く、マネージドIDさえ正しく設定すればシークレット管理の手間をほぼゼロにできる。