Azure Container Registry（ACR）とは？仕組み・料金プランとACR Tasks・ECR/GHCRとの違いを実装者目線で解説

Azure Container Registry（ACR）は、DockerイメージやOCIアーティファクトをAzure上に保管するマネージドのプライベートコンテナーレジストリです。実装で最初に押さえるべきは、Basic・Standard・Premiumという3つの料金プランの違い、az acr buildでビルドをクラウドへ肩代わりさせるACR Tasks、そしてMicrosoft Entra IDと連携した認証・アクセス制御の3点になります。この記事では定義から、SKUごとの機能差、AKSやContainer Appsへのデプロイ連携、AWS ECR・GitHub Container Registryとの違い、そして「どんなシステムで採用し、どこでは見送るか」の判断基準までを、2026年時点の公式ドキュメントの仕様に基づいて実装者目線で整理します。

まとめ：Azure Container Registryの要点と採用判断の分岐

ACRは、Azure中心のシステムでコンテナーイメージを保管・配布するときの第一候補になるプライベートレジストリです。レジストリ名.azurecr.ioというエンドポイントにDockerの標準コマンドでpush／pullでき、AKS・App Service・Container Apps・Batchなどのデプロイ先とMicrosoft Entra IDの認証情報で直結します。設計の中心はSKU（Basic／Standard／Premium）の選定で、地理レプリケーション・プライベートエンドポイント・トークンによる細粒度アクセス制御が必要ならPremium一択という分岐になります。

採用が合理的なのは、AzureでコンテナーワークロードをすでにAKSやContainer Appsで動かしている、あるいはこれから動かすケースです。逆に、GitHub Actions中心でソースとイメージを同じ場所に置きたいならGitHub Container Registry、AWSにデプロイするならAmazon ECRが素直な選択になります。どのクラウドのどのレジストリに寄せるかは、デプロイ先とCI/CDの構成から逆算するのが実装者の判断です。自社のコンテナー基盤をどう組むか迷う段階なら、設計から相談できる開発会社に早めに当たると手戻りを防げます。

Azure Container Registryの仕組みとリソースモデル

ACRは、オープンソースのDockerレジストリ仕様をベースにしたマネージドサービスです。自前でレジストリサーバーを立てて運用する代わりに、Azureが可用性・スケール・保存を引き受けるため、実装者はイメージのpush／pullとアクセス制御の設計に集中できます。

プライベートDockerレジストリという位置づけとエンドポイント構造

レジストリを作成すると、レジストリ名.azurecr.ioという一意なログインサーバー（FQDN）が割り当てられます。開発者はローカルやCIからdocker pushでイメージを送り込み、デプロイ先は同じエンドポイントからpullする流れです。通信はすべてHTTPSで、TLSがクライアント接続を保護します。既定では認証済みのプリンシパルしかアクセスできないプライベートな置き場である点が、パブリックなDocker Hubとの違いであり業務システムでの前提です。作成はAzure CLIならaz acr create --resource-group myRG --name myregistry --sku Standardの一行で済みます。

リポジトリ・イメージ・タグ・OCIアーティファクトから成る格納構造

1つのレジストリの中に、リポジトリという単位でイメージ群をまとめます。各イメージはタグ（:v1や:latest）またはダイジェスト（@sha256:...）で識別する読み取り専用のスナップショットです。WindowsイメージとLinuxイメージのどちらも同居でき、Dockerイメージだけでなく、OCI Image Format仕様のアーティファクトやHelmチャートも同じレジストリに保管できます。つまりコンテナーイメージの倉庫であると同時に、Kubernetesのデプロイ資材（Helm）やその他のOCI準拠成果物の配布点としても使えるということです。

デプロイ先とCI/CDパイプラインへの接続とAKSへの配布経路

ACRからイメージをpullするデプロイ先は幅広く、Kubernetes（AKS）・App Service・Container Apps・Batch・Service Fabric、あるいはDocker SwarmやオンプレのKubernetesまで対応します。CI/CD側はAzure Pipelines・GitHub Actions・Jenkinsといったツールからpush先として指定するのが定番です。とくにAKSとはaz aks update --attach-acrでマネージドIDによる無資格情報のpull連携を組めるため、Kubernetesクラスターへイメージを配る経路を認証情報の受け渡しなしで通せます。AKS側の設計はAKS（Azure Kubernetes Service）の仕組みと始め方を解説した記事と合わせて読むと、レジストリからクラスターまでの一連の流れが見えてきます。

料金プラン（Basic・Standard・Premium）の違いと選び方

ACRの設計はSKU選びから始まります。3つの層はいずれもWebhook連携・Microsoft Entra IDによる認証・イメージ削除といった共通機能を持ち、含まれるストレージ量・スループット・そしてPremium限定の高度機能で差がつきます。日割りの固定料金に、含まれる容量を超えた分のストレージ課金が乗る構造です。

含まれるストレージ量とスループットで分かれる3つの層とその違い

基本の差は含まれるストレージ量です。用途と規模で素直に選べます。

Basicは同じ機能セットを低コストで試したい開発・検証向けで、Standardは含まれる容量とスループットが増え、本番の多くのケースを賄えます。Premiumは含まれるストレージが最も大きく、レジストリあたり最大100 TiBまで拡張でき（2026年時点で従来の40 TiBから拡大）、後述の地理レプリケーションやプライベートエンドポイントといった上位機能が解放されます。含まれる量を超えた保存は、超過分に対して1GBあたり月額0.1ドル前後の追加課金が乗る形です（2026年時点・リージョンで変動）。

Premiumだけで使える地理レプリケーション・プライベート接続・トークン

Premiumでのみ使える機能が、SKU選定の分岐点になります。実装要件に次のどれかが含まれるならPremiumが前提です。

• 地理レプリケーション：単一のレジストリを複数リージョンへ複製し、各拠点から近い場所でpullさせる。追加リージョンごとにPremiumのベース料金が乗る
• プライベートエンドポイント（Private Link）：レジストリを仮想ネットワーク内の私設IPに閉じ、パブリック経路を遮断する
• 可用性ゾーン対応：ゾーン冗長でリージョン内の障害耐性を上げる
• リポジトリスコープのトークン：リポジトリ単位でpull／pushを絞るきめ細かなアクセス制御
• コンテンツトラスト：イメージタグへの署名で改ざんを検知する

逆に言えば、単一リージョンでイメージを保管し社内から使うだけなら、StandardでもBasicでも機能的には足ります。地理分散やネットワーク分離、監査に耐える細粒度の権限管理が要件に入った時点でPremiumへ切り替える、という判断で問題ありません。

料金プランごとの日割り固定料金と超過ストレージなど課金要素の内訳

課金は「SKUの日割り固定料金＋含まれる量を超えたストレージ＋地理レプリケーションのリージョン数＋外向き転送帯域」で決まります。SKUの目安は、Basicが1日あたり約0.167ドル、Standardが約0.667ドル、Premiumが約1.667ドル（いずれも2026年時点・リージョンで変動）です。月額換算ではBasicで数百円、Standardで数千円、Premiumで1万円弱が起点になり、そこに超過ストレージと地理レプリケーションが積み上がります。正確な金額はAzureの公式料金ページとPricing Calculatorで見積もるのが確実で、この記事の数値は概算の起点として扱ってください。

ACR Tasksによるクラウドビルドとイメージ運用の自動化

ACRは保管するだけの倉庫ではなく、イメージのビルドと更新を担うACR Tasksという機能を持ちます。ローカルのdocker buildをAzure側へ肩代わりさせ、ベースイメージの更新やGitへのコミットを引き金に自動でビルドし直す仕組みで、CI/CDの一部を代替できます。

az acr buildでビルドをクラウドへ肩代わりするクイックタスク

もっとも使う場面が、手元にDockerを入れずにイメージをビルドしてpushまで済ませるクイックタスクです。az acr build --registry myregistry --image myapp:v1 .を実行すると、カレントディレクトリのソースとDockerfileがクラウドへ送られ、Azure側でビルドされたイメージがそのままレジストリに格納されます。CIエージェントにDockerデーモンを用意する手間が省けるため、開発の内側ループをクラウドへ寄せる使い方に向いた方式です。

ベースイメージ更新・Gitコミットを引き金にした自動リビルド

タスクを登録しておくと、トリガーに応じてイメージを自動で作り直せます。代表的なトリガーは3つで、Gitリポジトリへのコミット、ベースイメージ（FROMで参照する土台イメージ）の更新、そしてスケジュールです。とくにベースイメージ更新トリガーは、OSやフレームワークにセキュリティ修正が入ったときに配下のアプリイメージを自動で再ビルドできるため、パッチ適用のパイプラインとして機能します。ビルド・テスト・パッチ適用を並列に連ねるマルチステップタスクを組めば、単純なビルドを超えた運用自動化まで踏み込めます。

認証とセキュリティ（Entra ID・RBAC・Defender）

業務システムでレジストリを使う以上、誰が何をpull／pushできるかの制御が設計の要になります。ACRはMicrosoft Entra IDを軸に、人間・サービス・マネージドIDのそれぞれに対する認証手段を用意しています。

Entra IDトークン・サービスプリンシパル・マネージドIDによる認証

認証は用途で使い分けます。開発者が手元から触るときはaz acr login --name myregistryでEntra IDのトークンを取得し、その資格でdockerコマンドを通します。CI/CDやアプリからの非対話アクセスにはサービスプリンシパル、Azureリソース（AKSや仮想マシン）からのpullにはマネージドIDを割り当てるのが定石です。手軽なadmin（管理者）アカウントも用意されていますが、単一のユーザー名とパスワードを共有する方式のため既定で無効化されており、本番では個々のプリンシパルにEntra IDのロールを与える運用が安全です。

RBACロールとリポジトリスコープトークンによる権限の絞り込み

権限は、Azureのロールベースアクセス制御（RBAC）でレジストリ単位に付与するのが基本です。pullだけ許すAcrPull、pushも許すAcrPushといった組み込みロールを、ユーザーやサービスに割り当てて絞ります。さらにPremiumでは、リポジトリスコープトークンを使ってレジストリ内の特定リポジトリだけにpull／pushを限定できます。マルチテナントで1つのレジストリを複数チームに貸すような構成では、この細粒度のトークンが分離の手段になる点が勘所です。

Microsoft Defenderによるイメージスキャンとプライベート接続

脆弱性の検知は、Microsoft Defender for Cloudとの連携で担う仕組みです。有効にしておくと、イメージをpushしたタイミングでスキャンが走り、既知の脆弱性を持つイメージを検知できます。ネットワーク面ではPremiumのプライベートエンドポイントでレジストリを仮想ネットワークに閉じ込め、パブリックインターネットからの到達を遮断する構成も取れます。イメージ署名（コンテンツトラスト）と合わせれば、信頼できる出所の脆弱性検査済みイメージだけを閉じた経路で配る統制を組めるのが強みです。

AWS ECR・GitHub Container Registryとの違い

コンテナーレジストリはACRだけではなく、クラウドやCI/CDの構成に応じて選択肢が分かれます。マルチクラウドや移行を検討する際は、対応するサービスとの違いを押さえておくと設計を横展開できます。

Amazon ECRとの対応関係とクラウド選定の勘所と使い分け

AWS側の対応物がAmazon ECR（Elastic Container Registry）です。プライベートレジストリである点、Dockerの標準コマンドでpush／pullする点、IAM／Entra IDといった各クラウドのID基盤で認証する点は共通します。違いは、統合先のエコシステムです。ACRはAKSやContainer Apps、ECRはEKSやECS／Fargateと素直につながるため、デプロイ先がどのクラウドかでレジストリも決まるのが実務の勘所になります。AWS側の料金体系やECSとの連携はAmazon ECRの料金とpush手順を解説した記事と読み比べると、どちらのクラウドに寄せるかの判断材料になります。

GitHub Container Registryとの使い分けとDocker Hub

GitHub Container Registry（ghcr.io）は、GitHubのソースコードと同じ場所にイメージを置けるレジストリで、GitHub Actions中心のCI/CDと相性の良い選択肢です。ソースとイメージ、権限管理をGitHubに集約したいならghcr.io、Azureのデプロイ先やEntra IDの統制に寄せたいならACR、という切り分けになります。パブリックなDocker Hubは公開イメージの配布や共有には向きますが、pullレート制限やプライベート運用のコストを考えると、業務のプライベートイメージ置き場にはクラウド各社のマネージドレジストリを充てるのが一般的です。レジストリごとの料金・無料枠の考え方はGitHub Container Registryの料金とDocker Hub/ECR比較を解説した記事で対比できます。

Azure Container Registryを採用すべき場面と見送る場面

ここからは判断です。ACRは万能のレジストリではなく、向く構成と向かない構成がはっきり分かれます。デプロイ先とCI/CDの前提から逆算し、条件付きで採否を言い切ります。

ACRの採用が合理的になる実務上の条件とデプロイ先による判断前提

次のいずれかに該当するなら、ACRが第一候補になります。

• デプロイ先がAKS・App Service・Container AppsなどAzure上のコンテナー基盤である
• 認証・権限管理をMicrosoft Entra IDに集約し、RBACやマネージドIDで統制したい
• 複数リージョンへイメージを近い場所から配りたい（地理レプリケーション＝Premium）
• プライベートエンドポイントでレジストリを閉域網に閉じ、監査に耐える構成が要る

いずれもAzureのID基盤・ネットワーク・デプロイ先と一体で運用できる強みが効く領域です。とくにAKSとのマネージドID連携や、Defenderによるpush時スキャンまで組み込むと、レジストリを含めた供給網の統制がAzure内で完結します。

ACRを選ぶべきでない場面と適切な代替レジストリの選定の勘所

一方で、次の要件にはACRを第一候補にしません。第一に、デプロイ先がAWS（EKS／ECS）なら、認証や近接性の観点からAmazon ECRが素直です。第二に、CI/CDとソース管理をGitHubに集約し、イメージも同じ場所で扱いたいならGitHub Container Registryが噛み合います。第三に、公開イメージを不特定多数へ配りたいだけならDocker Hubなどのパブリックレジストリで足り、プライベートレジストリの固定費は不要です。第四に、地理レプリケーションやプライベート接続を要件にしないのにPremiumを選ぶのは過剰で、StandardやBasicで含まれる容量と機能に収まらないかを先に確認します。

受託開発におけるコンテナー基盤の全体設計と外注先への相談の勘所

実際のシステムでは、レジストリ単体ではなくCI/CD・Kubernetes・ネットワーク・ID基盤を役割ごとに組み合わせる構成になります。どのSKUを選び、どの認証方式でデプロイ先とつなぎ、どこまでをPremiumの機能で固めるかは、可用性要件・セキュリティ要件・月次コストのトレードオフで決まります。要件定義の段階でこの全体像を固めておくほど、運用開始後の作り直しを避けられる設計です。Azureを含むクラウドインフラの構築・移行の相談では、レジストリ選定を含めたコンテナー基盤の設計から実装・運用までを一貫して支援できます。

よくある質問

Azure Container Registryの実装検討でよく挙がる質問を、公式ドキュメントの仕様に沿って整理します。

Azure Container RegistryとDocker Hubはどう違いますか？

Docker Hubはパブリックな共有レジストリで、公開イメージの配布や取得に向きます。ACRはAzure上のプライベートレジストリで、既定では認証済みのプリンシパルしかアクセスできず、Entra IDのRBACやマネージドIDでpull／pushを統制できる点が違いです。業務システムの自社イメージを保管し、AKSなどへ安全に配りたい用途にはACRが噛み合います。

BasicとStandardとPremiumはどう選べばよいですか？

含まれるストレージ量とPremium限定機能の要否で選びます。学習や検証はBasic、本番の一般的な用途はStandardで足ります。地理レプリケーション・プライベートエンドポイント・可用性ゾーン・リポジトリスコープトークンのいずれかが要件に入ったらPremiumです。単一リージョンで社内利用するだけならStandard以下で機能的に不足しません。

ACR TasksとGitHub ActionsのようなCI/CDは併用できますか？

併用できます。ACR Tasksはクラウド側でのビルドやベースイメージ更新トリガーによる自動リビルドを担い、GitHub ActionsやAzure Pipelinesはパイプライン全体のオーケストレーションを担う、という役割分担が一般的です。CIからはaz acr buildを呼ぶか、ビルド済みイメージをpushするかのどちらでも構成できます。

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

az aks update --attach-acr <レジストリ名>でAKSのマネージドIDにAcrPull権限を与えると、資格情報を渡さずにpullできます。imagePullSecretsを手動で管理する必要がなく、Kubernetes側のマニフェストはレジストリのFQDNを含むイメージ名を指定するだけで済みます。

admin（管理者）アカウントは使ってよいですか？

単一のユーザー名とパスワードでアクセスする方式のため、既定で無効化されており、本番運用では推奨されません。個々の利用者やサービスにEntra IDのRBACロールやサービスプリンシパル、マネージドIDを割り当てるほうが、権限の絞り込みと監査の面で安全です。adminアカウントは一時的な検証などに限定して使います。

関連記事

• AKS（Azure Kubernetes Service）とは｜できること・料金・始め方を解説【2026年版】：ACRからイメージを配る主要なデプロイ先で、attach-acr連携までつながります。
• Azure Container Appsとは？特徴・料金・デプロイ手順とAKS・App Serviceの違い：Kubernetesを直接運用しない場合のもう一つのデプロイ先として対比できます。
• AWS ECRとは？料金・ECSとの違いとDockerイメージのpush手順【2026年版】：AWS側の対応物と読み比べ、どちらのクラウドに寄せるかの判断材料になります。
• GitHub Container Registry（ghcr.io）の料金とは｜無料枠・課金条件とDocker Hub/ECR比較【2026年版】：GitHub中心の構成と比較し、レジストリの使い分けを整理できます。