---
title: "Azure Container Registry（ACR）とは？料金プランの違いと月額・作成からpushまでの手順【2026年10月】"
url: "https://www.issoh.co.jp/tech/details/15653/"
published: 2026-07-25
updated: 2026-10-18
categories: ["Azure"]
publisher: "株式会社一創"
---

# Azure Container Registry（ACR）とは？料金プランの違いと月額・作成からpushまでの手順【2026年10月】

Azure Container Registry（ACR）は、DockerイメージやHelmチャートなどのOCIアーティファクトをAzure上に置くための、マネージドのプライベートレジストリです。料金はBasic・Standard・Premiumの3プランの日額に、含まれる容量を超えた保存分が乗る仕組みで、東日本リージョンの円建て単価ではBasicが1日26.2478円（30日で約787円）です。この記事では、仕組みと3プランの機能差、円での月額試算、Azure CLIでの作成からpushまでの手順、ACR Tasks、AKSとの連携と権限設計、Amazon ECR・GitHub Container Registryとの使い分けまでを、2026年10月時点の公式ドキュメントと価格APIの値で整理します。なお、名前の似たAzure Arc（オンプレミスや他クラウドのサーバーをAzureから管理するサービス）とは別の製品です。

## まとめ：ACRの要点と料金プランの選び方

ACRは「レジストリ名.azurecr.io」のエンドポイントにdockerコマンドでpush・pullでき、AKS・Container Apps・App ServiceなどのAzureのデプロイ先とMicrosoft Entra IDの認証でつながります。プランの選び方は次の3行に収まります。

- 検証・学習はBasic（含まれる保存容量10GiB・月約787円）
- 本番の多くはStandard（100GiB・月約3,151円）。認証なしで取得させる匿名pullはここから使える
- 複数リージョンへの複製・プライベートエンドポイント・保持ポリシー・顧客管理キーが要件にあるならPremium（500GiB・月約7,877円）

旧来の解説で「Premium限定」とされていた可用性ゾーンとリポジトリ単位のトークンは、現在は全プランで使えます。逆に、デプロイ先がAWSならAmazon ECR、ソースもCIもGitHubに寄せているならGitHub Container Registryのほうが素直です。権限まわりでは、新しいABACモード（rbac-abac）にするとAcrPullロールと`az aks update --attach-acr`が効かなくなる点に注意してください。

## Azure Container Registryの仕組みとログインサーバー名

ACRはDocker Registry 2.0系の仕様を基にしたマネージドサービスで、保存・可用性・スケールはAzure側が持ちます。

### レジストリ・リポジトリ・タグの格納構造

1つのレジストリの中にリポジトリがあり、各イメージはタグ（`:v1`）かダイジェスト（`@sha256:…`）で指定します。LinuxとWindowsのイメージ、マルチアーキテクチャのイメージ、Helmチャート、署名やSBOMのようなOCIアーティファクトを同じレジストリに置けます。名前空間はリポジトリ名にスラッシュを入れて切るのが一般的で、`team-a/api` のようにチームやサービス単位で分けておくと、後述するリポジトリ単位の権限付与がそのまま使えます。

### ログインサーバー名と名前の決まり

レジストリ名はAzure全体で一意の5〜50文字とし、Azure CLIでは小文字の英数字で指定します。ハイフンは使えません。ログインサーバーは通常 `レジストリ名.azurecr.io` ですが、作成時に `--dnl-scope`（Domain Name Label）で `TenantReuse` などを指定すると `myregistry-e7ggejfuhzhgedc8.azurecr.io` のようにハッシュが付きます。削除したレジストリ名を第三者が取り直して、古い参照先から悪意のあるイメージをpullさせる「サブドメイン乗っ取り」を防ぐ仕組みで、[公式クイックスタート](https://learn.microsoft.com/ja-jp/azure/container-registry/container-registry-get-started-azure-cli)でも指定例が載っています。スコープは作成後に変えられず、Dockerfile・Kubernetesのマニフェスト・Helmの値にはハッシュ付きの名前を書く必要があります。Azure CLI 2.91.0のヘルプでは、このオプションはプレビュー扱いで既定値は `Unsecure`（ハッシュなし）でした。

## 料金プラン（Basic・Standard・Premium）の機能差

3プランはデータプレーンのAPIが共通で、違いは含まれる保存容量、要求数の上限、Premium限定機能です。[SKUの機能と制限](https://learn.microsoft.com/ja-jp/azure/container-registry/container-registry-skus)（2026年10月15日更新）の表から、選定に効く行を抜き出しました。

| 項目                                | Basic     | Standard  | Premium   |
| --------------------------------- | --------- | --------- | --------- |
| 含まれる保存容量                          | 10 GiB    | 100 GiB   | 500 GiB   |
| 保存容量の上限                           | 40 TiB    | 40 TiB    | 100 TiB   |
| Webhook数                          | 2         | 10        | 500       |
| pull系の要求上限（レジストリ全体）               | 10,000回/分 | 10,000回/分 | 20,000回/分 |
| Entra外トークンの数                      | 100       | 500       | 50,000    |
| 可用性ゾーン                            | ○         | ○         | ○         |
| 匿名pull                            | ×         | ○         | ○         |
| geoレプリケーション                       | ×         | ×         | ○         |
| プライベートエンドポイント                     | ×         | ×         | ○（最大200）  |
| 未タグ付けマニフェストの保持ポリシー                | ×         | ×         | ○         |
| 顧客管理キー・接続レジストリ・Artifact streaming | ×         | ×         | ○         |

### 全プランで使えるようになった可用性ゾーンとトークン

[ゾーン冗長のドキュメント](https://learn.microsoft.com/ja-jp/azure/container-registry/zone-redundancy)は、対応リージョンではBasic・Standard・Premiumのすべてで追加料金なしに既定で有効と明記しています。ARMやBicepの `zoneRedundancy` プロパティは互換のために残っているだけで、もう挙動を決めません。Azure CLI 2.91.0の `az acr create --help` には今も「既定はDisabled」と出ますが、これは古い説明のまま残った表記で、オプションを付けなくてもゾーン冗長になります。リポジトリ単位のトークンとスコープマップも全プランで使え、プランで違うのは作れる数（Basic 100・Standard 500・Premium 50,000）です。「細かい権限が要るからPremium」という選び方は、今は根拠になりません。

### Premiumを選ぶ条件

Premiumが必要になるのは、表の下半分の機能が要件に入ったときです。具体的には、東日本と米国東部の両方から近くでpullさせたい（geoレプリケーション）、レジストリを仮想ネットワーク内のプライベートIPだけに閉じたい（Private Link）、タグを外したイメージを日数で自動削除したい（保持ポリシー・現在プレビュー）、暗号鍵を自社のKey Vaultで管理したい（顧客管理キー）、の4つです。数百ノードのAKSが同時にpullするような規模では、要求上限が2倍になる点も効きます。上限を超えると `429 Too Many Requests` と `Retry-After` ヘッダーが返るので、一斉デプロイで429が出るようならPremiumへの変更を検討します。プランの変更は無停止で行えますが、Premiumから下げるときはレプリカと接続レジストリを先に削除する必要があります。

## ACRの円建て参考単価と月額試算

課金はプランの日額、含まれる容量を超えた保存分、geoレプリケーションのレプリカ数、ACR Tasksの実行時間、外部への転送帯域で決まります。[公式の価格ページ](https://azure.microsoft.com/ja-jp/pricing/details/container-registry/)はJavaScriptで金額を描画するため、ここでは認証なしで使える[Azure Retail Prices API](https://learn.microsoft.com/ja-jp/rest/api/cost-management/retail-prices/azure-retail-prices)から東日本（japaneast）の円建て参考単価を2026年10月18日に取得しました。西日本（japanwest）も同額です。公式APIの米ドル以外の価格は予算見積もり用の参考値で、実際の請求額を保証するものではありません。

| 課金メーター         | 単価（円）        | 単価（USD）      | 30日換算   |
| -------------- | ------------ | ------------ | ------- |
| Basic          | 26.2478/日    | 0.1666/日     | 約787円   |
| Standard       | 105.0228/日   | 0.6666/日     | 約3,151円 |
| Premium        | 262.5728/日   | 1.6666/日     | 約7,877円 |
| Premiumのレプリカ1つ | 262.5728/日   | 1.6666/日     | 約7,877円 |
| 接続レジストリ1つ      | 52.5161/日    | 0.33333/日    | 約1,575円 |
| 超過分の保存         | 15.755/GB月   | 0.10/GB月     | –       |
| ACR Tasksの実行   | 0.0158/vCPU秒 | 0.0001/vCPU秒 | –       |

### 構成別の月額の目安

Standardで150GiBを保存している場合は、日額分の約3,151円に、超過50GiB×15.755円＝約788円が乗って月3,939円前後です。Premiumで東日本に加えてもう1リージョンへ複製すると、日額分とレプリカ1つで約15,754円です。保存量はレプリカごとに数えられ、[geoレプリケーションのドキュメント](https://learn.microsoft.com/ja-jp/azure/container-registry/container-registry-geo-replication)の例では、1GiBのイメージを5つのレプリカに置くと5GiB分の課金になります。ACR TasksはBasicからPremiumまで単価が同じで、価格APIでは最初の6,000 vCPU秒が0円の段になっています。`az acr task create` の既定CPU数は2なので、2 vCPUで5分かかるビルドは600 vCPU秒で、無料の段を超えた後でも1回約9.5円です。インターネットへの送信は[帯域幅の料金](https://azure.microsoft.com/ja-jp/pricing/details/bandwidth/)が別にかかるため、社外の環境から大量にpullする構成では転送量も見積もりに入れてください。

### 保存容量を膨らませない設定

超過の課金は、CIがビルドのたびに一意のタグでpushし、古いタグを消さないことで生まれます。Premiumなら保持ポリシーで「タグが外れてからN日で削除」にできますが、現在はプレビューで、有効にした後にタグが外れたものだけが対象です。全プランで使えるのは、後述の `acr purge` を定期タスクで回す方法です。誤削除に備えるソフト削除（1〜90日、既定7日）も全プランで使えるプレビュー機能ですが、geoレプリケーションやArtifact cacheを使うレジストリでは有効にできず、保持ポリシーとの同時有効化もできません。ソフト削除中のイメージにも保存料金がかかります。

## Azure CLIでレジストリを作成してイメージをpushする手順

以下はBash向けの例です。Azure CLIが導入され、Dockerデーモンが起動している端末で、`az login` を済ませた状態から始めます。リソースグループ名・レジストリ名・リージョンは自分の値に置き換えてください。

```
# リソースグループとレジストリを作成（東日本・Standard）
az group create --name rg-acr-demo --location japaneast
az acr create --resource-group rg-acr-demo --name myregistry2026 --sku Standard

# ログイン（Entra IDのトークンでdocker loginされる）
az acr login --name myregistry2026

# 手元のイメージにログインサーバー名付きのタグを付けてpush
docker pull mcr.microsoft.com/hello-world
docker tag mcr.microsoft.com/hello-world myregistry2026.azurecr.io/samples/hello-world:v1
docker push myregistry2026.azurecr.io/samples/hello-world:v1

# 中身を確認
az acr repository list --name myregistry2026 --output table
az acr repository show-tags --name myregistry2026 --repository samples/hello-world --output table
```

`az acr create` の出力の `loginServer` が、タグに付けるべき実際のホスト名です。前述の `--dnl-scope` を付けた場合はハッシュ付きの名前になるので、レジストリ名から推測せずにこの値を使います。Dockerを入れられない端末やCIでは、`az acr login --name myregistry2026 --expose-token` でアクセストークンを取り出し、ユーザー名 `00000000-0000-0000-0000-000000000000` と組み合わせてPodmanなど別のクライアントからログインする方法もあります。使い終わった検証環境は `az group delete --name rg-acr-demo` で消すと、日額の課金も止まります。

## ACR Tasksによるビルド・削除の自動化

ACR Tasksは、Azure側でイメージのビルド・push・コマンド実行を行う機能です。[ACR Tasksの概要](https://learn.microsoft.com/ja-jp/azure/container-registry/container-registry-tasks-overview)によると、手動で1回だけ動かすクイックタスク、GitHubやAzure DevOpsへのコミット・プルリクエスト、ベースイメージの更新、タイマーを引き金に動く自動タスク、YAMLで手順を連ねるマルチステップタスクがあります。なお同ページには、Azureの無料クレジットでのタスク実行を一時停止しているという注記があり、無料試用のサブスクリプションでは動かない場合があります。

### az acr buildによるDocker不要のクラウドビルド

Dockerfileのあるディレクトリで次を実行すると、ソースがAzureへ送られ、ビルドされたイメージがそのままレジストリに入ります。CIのランナーにDockerデーモンを用意する必要がありません。`--platform linux/arm64` を付ければArm向けのイメージも作れます。

```
az acr build --registry myregistry2026 --image app/api:{{.Run.ID}} .
```

`{{.Run.ID}}` は実行ごとに一意のIDへ置き換わるタスクの変数で、ビルドごとに重複しないタグになります。ベースイメージ更新トリガーは `az acr task create` で既定で有効になり、FROMで参照するOSやランタイムのイメージに修正が入ると、配下のアプリイメージを作り直します。脆弱性の修正をアプリ側のコミットを待たずに取り込めるのが、GitHub Actionsだけでビルドする構成との違いです。

### acr purgeによる古いタグの定期削除

古いイメージの掃除は、[acr purge](https://learn.microsoft.com/ja-jp/azure/container-registry/container-registry-auto-purge)（プレビュー）をスケジュールタスクとして登録するのが定番です。次の例は、毎日0時（UTC）に `app/api` リポジトリで7日より前に更新されたタグを削除候補とし、その候補のうち更新日時が新しい10件を残します。タグなしマニフェストも削除対象となり、保持件数はタグとマニフェストにそれぞれ適用されます。

```
PURGE_CMD="acr purge --filter 'app/api:.*' --ago 7d --keep 10 --untagged"

az acr task create --name purge-api \
  --registry myregistry2026 \
  --cmd "$PURGE_CMD" \
  --schedule "0 0 * * *" \
  --context /dev/null
```

消したデータは戻せないので、最初は `--dry-run` を付けて `az acr run --registry myregistry2026 --cmd "acr purge --filter 'app/api:.*' --ago 7d --keep 10 --untagged --dry-run" /dev/null` で対象を確かめます。マニフェストのダイジェスト指定でpullしているシステムがあるなら、`--untagged` は付けないでください。タグを外したイメージが消え、そのシステムがpullできなくなります。

## 認証と権限設計（Entra ID・RBAC・ABAC）

[ACRの認証方式](https://learn.microsoft.com/ja-jp/azure/container-registry/container-registry-authentication)は、開発者個人の `az acr login`、CIなど対話のない処理のサービスプリンシパル、AKSや仮想マシンからのマネージドIDが基本です。管理者（admin）ユーザーは既定で無効で、レジストリに1つしかなく、全員が同じ「push・pull可能な1ユーザー」に見えるため、複数人で共有しない前提です。ただし、AzureポータルからAzure Container InstancesやContainer Appsへイメージを直接デプロイするときは、今も管理者ユーザーが必要になります。

### AKSからpullさせるattach-acrとABACモードの例外

AKSからpullさせる最短の方法は、`az aks update --name myAKS --resource-group rg-acr-demo --attach-acr myregistry2026` です。kubeletのマネージドIDにAcrPullロールが付き、imagePullSecretsを管理せずにpullできます。このコマンドは実行者の権限でロールを割り当てるため、サブスクリプションの所有者（Owner）かユーザーアクセス管理者のロールが必要です。

例外が、ロール割り当てのモードを `rbac-abac`（RBAC Registry + ABAC Repository Permissions）にしたレジストリです。[ABACのドキュメント](https://learn.microsoft.com/ja-jp/azure/container-registry/container-registry-rbac-abac-repository-permissions)では、このモードでは `AcrPull`・`AcrPush`・`AcrDelete` が効かず、代わりに `Container Registry Repository Reader`・`Writer`・`Contributor` を使うとしています。[AKSとの統合手順](https://learn.microsoft.com/ja-jp/azure/aks/cluster-container-registry-integration)も、ABACモードのレジストリでは `--attach-acr` を使わず、Repository Readerロールを手動で割り当てるよう求めています。既存のレジストリを切り替えると、今のAcrPullの割り当てが効かなくなってAKSのpullが止まり、ACR Tasksもソースレジストリへの既定のアクセスを失います（タスクには `--source-acr-auth-id [system]` でIDを付けて権限を与え直します）。

Microsoftはこのモードを将来の既定にすると予告していますが、CLI 2.91.0の既定はまだ `rbac` です。リポジトリ単位で権限を分ける必要が無ければ当面は `rbac` のまま運用し、切り替えるときは新ロールの割り当てと反映を確認してからモードを変更します。それでも、旧モードで発行された資格情報は切り替え後にHTTP 401で拒否されます。各クライアントのキャッシュが切れるまで数分から数時間pullできなくなるため、AKSでは切り替え直後にkubeletの再起動かノードの入れ替えで資格情報を取り直させます（Podを再起動しても資格情報は更新されません）。

```
# ABACモードのレジストリで、AKSのkubelet IDに全リポジトリの読み取りを付ける
KUBELET_ID=$(az aks show -g rg-acr-demo -n myAKS --query identityProfile.kubeletidentity.objectId -o tsv)
ACR_ID=$(az acr show -n myregistry2026 --query id -o tsv)
az role assignment create --assignee-object-id "$KUBELET_ID" --assignee-principal-type ServicePrincipal \
  --role "Container Registry Repository Reader" --scope "$ACR_ID"
```

### イメージ署名と脆弱性スキャン

イメージの改ざん検知に使われてきたDocker Content Trust（DCT）は、Premiumだけの機能でしたが、[公式ドキュメント](https://learn.microsoft.com/ja-jp/azure/container-registry/container-registry-content-trust)で2028年3月31日に完全に削除されると告知されています。これから署名を入れるなら、Notary Project（Notation）でOCIの署名をレジストリに置く方式を選びます。2026年5月31日以降は、新しいレジストリや過去にDCTを有効にしたことのないレジストリでは、DCTを有効にすることもできません。脆弱性の検出は、Microsoft Defender for CloudのDefender for Containersプランが担います。[脆弱性評価のドキュメント](https://learn.microsoft.com/ja-jp/azure/defender-for-cloud/agentless-vulnerability-assessment-azure)によると、ACRのイメージのOSパッケージと（Linuxでは）言語パッケージを評価し、直近30日にpush・pullされたイメージと監視対象のクラスターで動いているイメージを毎日再スキャンします。課金はAKSなどワーカーノードのvCore数が基準で、前月のvCore使用量に基づき、課金対象のvCoreあたり月20回のレジストリ脆弱性評価が含まれます。

## Amazon ECR・GitHub Container Registryとの違い

どのレジストリを選ぶかは、ほぼデプロイ先とCIの置き場所で決まります。保存単価だけを比べると次のとおりです。

| 項目           | ACR                 | Amazon ECR     | GitHub Container Registry |
| ------------ | ------------------- | -------------- | ------------------------- |
| 固定費          | 日額（Basic 26.2478円〜） | なし             | なし                        |
| 保存単価         | 超過分 0.10ドル/GB月      | 0.10ドル/GB月（東京） | 現在は無料                     |
| 認証の基盤        | Microsoft Entra ID  | AWS IAM        | GitHubのトークン               |
| 相性の良い実行環境・CI | AKS・Container Apps  | ECS・EKS・Lambda | GitHub Actions全般          |

[Amazon ECR](https://aws.amazon.com/jp/ecr/pricing/)は固定費がなく、東京リージョンのプライベートリポジトリは保存1GB月あたり0.10ドルです（AWS Price List APIの値）。ACRは含まれる容量があるかわりに日額がかかるので、10GiB未満しか置かない小さな用途では、月約787円のBasicのほうがECRより高くなります。一方、[GitHubの課金ドキュメント](https://docs.github.com/ja/billing/concepts/product-billing/github-packages)は、Container Registryの保存と帯域は「現在は無料」で、変更する場合は1か月前に知らせると書いています。ECR側の詳細は[Amazon ECRとは？料金・ECSとの違いとDockerイメージのpush手順](/tech/details/2667/)、GitHub側は[GitHub Container Registry（ghcr.io）の料金と使い方](/tech/details/7315/)で比べられます。レジストリ全般の種類と選び方は[コンテナレジストリとは？種類・選び方から企業の導入判断まで](/tech/details/13259/)にまとめています。

## ACRを採用すべき場面と見送る場面

ACRを第一候補にすべきなのは、デプロイ先がAKS・Container Apps・App ServiceなどAzureにあり、権限をEntra IDとマネージドIDでそろえたい場合です。AKSならattach-acrの1コマンドでpullの認証が済み、Container AppsもマネージドIDでpullできるため、レジストリのパスワードを扱う場面がなくなります。Kubernetesを直接運用しない構成なら、[Azure Container Appsとは？特徴・料金・デプロイ手順](/tech/details/3189/)、AKSを使うなら[AKS（Azure Kubernetes Service）とは｜できること・料金・始め方](/tech/details/7272/)と合わせて読むと、レジストリからデプロイまでの経路がつながります。

見送るべきなのは次の場面です。

- デプロイ先がAWSのECSやEKS：ECRならIAMロールでpullでき、リージョン内の転送で済む
- 公開イメージを不特定多数に配るだけ：GitHub Container RegistryやDocker Hubの公開リポジトリで足り、日額の固定費は不要
- イメージが数GBしかなくAzure以外にデプロイする：Basicでも月約787円の固定費がかかる
- Premium限定機能も追加の容量・性能も不要なのにPremium：Standardとの差額は30日換算で約4,726円

レジストリだけでなく、CI/CD・Kubernetes・閉域網・ID基盤をまとめて設計する段階なら、[AWS・Google Cloud・Azureのインフラ構築支援](/service/system/aws/)で構成の検討から相談できます。

## よくある質問

### ACRとは何の略ですか？

Azure Container Registryの略で、Microsoft Azureのプライベートなコンテナーレジストリサービスを指します。Azure Arc（ハイブリッド環境の管理サービス）とは別の製品です。

### BasicとStandardの違いは何ですか？

含まれる保存容量（10GiBと100GiB）、Webhook数（2と10）、トークン数（100と500）が違い、匿名pullはStandardからです。要求数の上限は同じです。東日本の日額は26.2478円と105.0228円で、30日では約787円と約3,151円になります。

### ACRに無料枠はありますか？

レジストリ自体の無料プランはなく、最も安いBasicでも日額がかかります。各プランに含まれる保存容量と、価格APIで0円になっているACR Tasksの最初の6,000 vCPU秒が実質的な無料分です。Azureの無料アカウントのクレジットでのタスク実行は一時停止中と公式に注記されています。

### AKSからACRのイメージをpullするにはどうしますか？

通常のレジストリなら `az aks update --attach-acr <レジストリ名>` でkubeletのIDにAcrPullが付きます。ロール割り当てモードを `rbac-abac` にしたレジストリでは使えないので、`Container Registry Repository Reader` を `az role assignment create` で割り当てます。

### 管理者（admin）ユーザーは使ってよいですか？

既定は無効で、全員が同じ1ユーザーとして扱われるため、本番の共有には向きません。ポータルからContainer InstancesやContainer Appsへ直接デプロイする場合など、必要な場面に限って有効にし、通常は個人のEntra IDとマネージドIDを使います。

## 関連記事

- [AKS（Azure Kubernetes Service）とは｜できること・料金・始め方を解説【2026年版】](/tech/details/7272/)
- [Azure Container Appsとは？特徴・料金・デプロイ手順とAKS・App Serviceの違い](/tech/details/3189/)
- [Amazon ECRとは？料金・ECSとの違いとDockerイメージのpush手順【2026年版】](/tech/details/2667/)
- [GitHub Container Registry（ghcr.io）の料金と使い方｜無料の範囲・Docker Hub/ECR比較【2026年10月】](/tech/details/7315/)
- [コンテナレジストリとは？種類・選び方から企業の導入判断まで解説](/tech/details/13259/)

---

出典: [Azure Container Registry（ACR）とは？料金プランの違いと月額・作成からpushまでの手順【2026年10月】](<https://www.issoh.co.jp/tech/details/15653/>)（株式会社一創）
