2026.07.23 インフラ

Artifact Registryとは？Google Cloudの成果物リポジトリの仕組み・料金とContainer Registry移行を実装者目線で解説

Artifact Registryは、DockerコンテナイメージやMaven・npm・Pythonなどのパッケージを、Google Cloud上でまとめて保管・管理するフルマネージドの成果物リポジトリサービスです。ビルドで生まれたイメージやライブラリを一箇所に集約し、CI/CDパイプラインやGKE・Cloud Runからの取得までを一貫した権限管理のもとで扱えます。旧来のContainer Registry（gcr.io）を機能拡張した後継であり、Google Cloudが推奨するコンテナレジストリという位置づけです。この記事では、Artifact Registryの定義とContainer Registryとの関係、対応フォーマットと3種のリポジトリモード、IAMや脆弱性スキャンによるセキュリティ、そして料金と採用の判断基準までを、実装者の視点で整理します。

まとめ：Artifact Registryの要点と採用判断

Artifact Registryは、Dockerイメージと各種言語のパッケージを1つのサービスで一元管理できるGoogle Cloudの成果物リポジトリです。標準・リモート・仮想という3つのリポジトリモードを使い分け、上流パブリックリポジトリのキャッシュや複数リポジトリの集約まで含めて、成果物の供給経路をプロジェクト単位で束ねられます。認証とアクセス制御はCloud IAMに統合され、コンテナイメージの脆弱性スキャンはArtifact Analysisが担う構成です。

採用の勘所は「Google Cloud上でビルド成果物を扱い、GKEやCloud Runへ配布したいか」です。Cloud BuildなどのCI/CDからイメージやパッケージを押し込み、同じGCPの権限体系でデプロイ先へ配る運用なら素直に噛み合います。すでにContainer Registry（gcr.io）を使っているなら、2025年3月18日のシャットダウンを受けてArtifact Registryへの移行が前提です。一方で、GCPをほとんど使わずAWS中心にビルドとデプロイを完結させているなら、同等の役割はAmazon ECRが担うため、レジストリだけをGCPに寄せる必然性は薄くなります。「どのクラウドでビルドし、どこへ配るか」を先に決めると選択を誤りません。

Artifact Registryとは何か：Container Registryとの関係

まず「Artifact Registryがどんな役割のサービスなのか」を、成果物リポジトリという位置づけとContainer Registryとの関係から押さえます。ここが移行判断の前提になります。

成果物を一元管理するフルマネージドなリポジトリとしての基本定義

Artifact Registryは、ビルドの成果物（アーティファクト）を保管・配布するためのフルマネージドなリポジトリサービスです。コンテナイメージだけでなく、Java向けのMavenパッケージ、Node.js向けのnpmパッケージ、Python、Goモジュールといった言語別のパッケージも同じサービスで扱えるため、成果物の保管先を種類ごとに分散させずに済みます。利用者はリポジトリを作成してビルドツールから押し込むだけでよく、ストレージの冗長化やレジストリの可用性はサービス側が受け持ちます。コンテナレジストリという役割そのものの整理はコンテナレジストリとは？種類・選び方から企業の導入判断まで解説で体系立てているため、レジストリ一般の前提を先に固めたい場合はあわせて参照してください。

Container Registry（gcr.io）の後継としての位置づけと移行

Artifact Registryは、Google Cloudの旧レジストリであるContainer Registryの機能を拡張した後継サービスです。Container Registryはコンテナイメージの保管に特化していましたが、Artifact Registryはこれに言語別パッケージや後述のリポジトリモードを加え、成果物管理の範囲を広げました。Container Registryはすでに非推奨（deprecated）となり、2025年3月18日をもってシャットダウンされ、イメージの書き込みはできません。既存のgcr.io資産については、後方互換のためgcr.ioホストごとにArtifact Registryのリポジトリを自動作成し、gcr.ioへのアクセスを対応するリポジトリへリダイレクトする仕組みが用意されています。とはいえ移行は前提であり、CI/CDやマニフェストが参照するイメージパスをArtifact Registry側へ切り替える作業を計画的に進めるのが実務的です。

コンテナ運用の中でArtifact Registryが担う保管レイヤ

Artifact Registryは、コンテナのライフサイクルのうち「ビルドしたイメージを保管し、デプロイ先へ配る」レイヤを担います。開発者がDockerfileからイメージをビルドし、それをレジストリへ押し込み、GKEやCloud Runがそこから取得して実行する、という流れの中間に位置する形です。コンテナそのものの仕組みや仮想マシンとの違いはコンテナとは？仮想マシンとの違いからDocker・企業の導入判断まで解説で扱っているため、コンテナの前提から確認したい場合に役立ちます。Artifact Registryはあくまで成果物の置き場と配布の窓口であり、イメージのビルドや実行そのものは別のサービスが担う、という役割分担で捉えると設計を誤りません。

Artifact Registryの主要機能を実装者視点で整理

次に、実際に運用する際に押さえる対応フォーマット、リポジトリモード、そしてセキュリティとCI/CD連携の機能を見ていきます。ここが日々の使い勝手を左右します。

Docker・Maven・npmなど対応する成果物フォーマット

Artifact Registryが扱えるフォーマットは幅広く、コンテナと言語パッケージの双方を1つのサービスに集約できます。具体的には、Dockerコンテナイメージ、KubernetesのHelmチャート、Goモジュール、Java向けのMavenパッケージ、Node.js向けのnpmパッケージ、Python、Ruby Gem、Debian系のAptパッケージ、RPM（Yum）パッケージ、Kubeflowのパイプラインテンプレート、そして形式を問わない汎用アーティファクトに対応します。フォーマットごとにリポジトリを作成し、Dockerクライアントや各言語のパッケージマネージャの認証をArtifact Registryへ向けるだけで、標準的なコマンド操作のまま利用できる設計です。成果物の種類がコンテナだけでなくライブラリにも及ぶ組織では、供給元をこの1サービスへ寄せられる点が運用上の利点になります。

種別 対応フォーマット例
コンテナ Dockerイメージ・Helmチャート
言語パッケージ Maven・npm・Python・Go・Gem
OSパッケージ Apt（Debian）・RPM（Yum）
その他 Kubeflowテンプレート・汎用アーティファクト

標準・リモート・仮想という3つのリポジトリモードと役割の使い分け

Artifact Registryのリポジトリには、用途の異なる3つの種別があります。標準リポジトリは、自分たちのビルド成果物を保管する通常の置き場です。リモートリポジトリは、Docker HubやMaven Centralといった上流のパブリックソースからの依存関係をキャッシュとして保持し、外部への直接アクセスを減らして供給経路を制御する用途に向きます。仮想リポジトリは、複数のリモートリポジトリや標準リポジトリを1つのエンドポイントとしてグループ化し、利用側は単一のURLを参照するだけで背後の複数リポジトリから成果物を解決できる形です。これらを組み合わせると、社内の成果物と外部依存の取得口を1本化しつつ、外部リポジトリの障害や変更の影響を緩和する構成が組めます。実装者は、まず標準リポジトリで自作物を管理し、外部依存の安定供給が要る段階でリモートと仮想を足していく順で設計すると迷いません。

IAMによるアクセス制御とArtifact Analysisの脆弱性スキャン

セキュリティ面では、認証・認可がGoogle CloudのIAMに統合されている点が軸になります。誰がどのリポジトリへ読み書きできるかをIAMのロールで制御でき、リポジトリ単位でアクセス権限を絞れるため、開発ステージやチームごとに供給範囲を分ける運用が可能です。認証情報はGCPのサービスアカウントやWorkload Identityと同じ体系で扱え、鍵を個別に配って回す必要がありません。脆弱性の管理はArtifact Analysisが担い、Dockerリポジトリのコンテナイメージに対して自動スキャンやオンデマンドスキャンを実行し、既知の脆弱性やメタデータを可視化します。イメージを押し込んだ時点でスキャンをかけ、深刻度に応じてデプロイを止める、といった品質ゲートをCI/CDへ組み込めるため、成果物の安全性を配布前に確認する運用が現実的になります。

CI/CDパイプラインとGKE・Cloud Runへのデプロイ連携

Artifact Registryは、CI/CDの成果物置き場として使うと役割がはっきりします。Cloud Buildなどのビルドがイメージやパッケージを生成してArtifact Registryへ押し込み、デプロイ工程がそこから取得してGKEやCloud Runへ配る、という流れの中心に据える形です。パイプラインとしての仕組みや導入判断はCI/CDとは？仕組み・パイプライン・導入すべき企業の判断基準を解説で整理しているため、CI/CD自体の前提を固めたい場合に参照できます。デプロイ先としては、コンテナをサーバーレスで動かすCloud Runとは？GCPのサーバーレスコンテナの仕組み・料金とGKE/Cloud Functionsとの違いを実装者目線で解説が典型で、Artifact Registryのイメージパスを指定するだけで配布とデプロイが同じGCPの権限体系でつながる形です。ここでArtifact Registryは成果物の供給元に徹し、ビルドはCloud Build、実行はCloud RunやGKEが担う、というレイヤ分担で捉えると全体像を掴みやすくなります。

Artifact Registryの料金体系と使い分け・採用判断

ここからは費用の構造と、AWSなど他クラウドのレジストリとの線引き、そして採用すべき条件と見送る場面を実務の判断として言い切ります。

ストレージとネットワーク下り（egress）を軸にした料金構造

Artifact Registryの費用は、保管するデータ量と外部へのデータ転送を軸に決まります。ストレージは一定の無料枠（0.5GB）を超えた分にGBあたりの月額が課金され、イメージやパッケージの総量が増えるほど積み上がる構造です。ネットワークの下り（egress）は、リポジトリから外部やクロスリージョンへデータを配信した量に応じて課金され、同一リージョン内の取得か、別リージョンやインターネットへの配信かで扱いが変わります。加えて、Artifact Analysisによる脆弱性スキャンはスキャン対象に応じた別料金です。コストを抑える勘所は、不要になった古いイメージのタグを整理してストレージ総量を絞ること、そしてデプロイ先とリポジトリのリージョンを揃えてクロスリージョンの下り課金を避けることにあります。単価はリージョンや時点で変わるため、正確な金額は公式の料金ページで確認するのが確実です（2026年7月時点の課金要素）。

Amazon ECRなど他クラウドの成果物レジストリとの使い分け

成果物レジストリの選択は、ビルドとデプロイをどのクラウドで完結させるかで棲み分けます。Artifact Registryが向くのは、Google Cloud上でビルドし、GKEやCloud Runへ配布する構成です。AWS中心にコンテナ基盤を組んでいるなら、同等の役割はAmazon ECRが担い、ECS・EKSとの権限連携もAWS側で完結するため、レジストリだけをGCPへ寄せる利点は小さくなります。Docker Hubのような外部の汎用レジストリは、公開イメージの配布やクラウドをまたぐ共有には向く一方、社内の権限統合や脆弱性スキャンをクラウドの体系に載せたい場合はマネージドレジストリのほうが噛み合います。判断軸は「ビルドとデプロイの主戦場がどのクラウドか」「言語パッケージまで一元管理したいか」の2点です。

選択肢 主戦場 向く場面
Artifact Registry Google Cloud GKE・Cloud Runへの配布
Amazon ECR AWS ECS・EKSとの権限連携
外部汎用レジストリ クラウド横断 公開イメージの共有

Artifact Registryを採用すべき条件と見送るべき場面

採用してよいのは、Google Cloudでビルド成果物を扱い、GKEやCloud Runへ配布する運用がある場合です。Cloud BuildからイメージやパッケージをArtifact Registryへ押し込み、IAMで供給範囲を絞り、Artifact Analysisで脆弱性を確認してからデプロイする、という一連の流れをGCPの権限体系のまま組みたいなら素直に噛み合います。すでにContainer Registry（gcr.io）を使っている場合は、2025年3月18日のシャットダウンを受けて、Artifact Registryへの移行先として選ぶのが前提です。一方で、見送ってよい場面も明確です。AWS中心にビルドとデプロイを完結させているなら、Amazon ECRのほうがECS・EKSとの連携で素直で、レジストリだけをGCPに置く必然性は薄くなります。コンテナも言語パッケージもほとんど扱わず、単発の成果物を置ければ足りる程度なら、専用のマネージドレジストリを構える価値は出にくいでしょう。Artifact Registryは「Google Cloud中心・コンテナや言語パッケージの継続的な配布・権限とスキャンの統合」が重なる領域で選ぶと外しません。こうしたGCP上のコンテナ基盤やCI/CDパイプラインの設計・実装・運用の相談先をお探しの場合は、インフラ構築（AWS・Google Cloud・Azure）で対応しています。

よくある質問

Artifact Registryの導入検討でよく挙がる論点を、移行と運用の観点から簡潔に整理します。

Artifact RegistryとContainer Registryは何が違うのですか？

Container Registryはコンテナイメージの保管に特化した旧サービスで、Artifact Registryはその機能を拡張した後継です。Artifact RegistryはDockerイメージだけでなくMavenやnpmなどの言語パッケージも扱え、標準・リモート・仮想の3モードやIAM統合を備えます。Container Registryは非推奨となり2025年3月18日にシャットダウンされたため、これからはArtifact Registryを使うのが前提になります。

gcr.ioのイメージはそのまま使えなくなりますか？

Container Registryの書き込みは2025年3月18日以降できませんが、後方互換のためgcr.ioホストごとにArtifact Registryのリポジトリを自動作成し、gcr.ioへのアクセスを対応するリポジトリへリダイレクトする仕組みが用意されています。既存の参照が即座に壊れるわけではないものの、CI/CDやマニフェストのイメージパスをArtifact Registry側へ切り替える移行は計画的に進めるべきです。

Artifact Registryはコンテナ以外の成果物も置けますか？

置けます。DockerイメージやHelmチャートに加え、Maven・npm・Python・Go・Ruby Gem・Apt・RPMといった言語やOSのパッケージ、Kubeflowのパイプラインテンプレート、汎用アーティファクトまで扱えるのが後継サービスとしての特徴です。フォーマットごとにリポジトリを作り、各パッケージマネージャの認証をArtifact Registryへ向ければ、通常のコマンド操作のまま利用できます。

Artifact Registryの料金はどのように決まりますか？

料金は、保管データ量に対するストレージ課金（0.5GBの無料枠あり）と、外部やクロスリージョンへのネットワーク下り（egress）が軸です。加えて、Artifact Analysisによる脆弱性スキャンは別料金になります。単価はリージョンや時点で変わるため、正確な金額は公式の料金ページで確認し、古いイメージの整理とリージョンを揃えた配布で費用を抑えるのが実務的です。

Artifact Registryのイメージをそのままデプロイできますか？

Cloud RunやGKEは、Artifact Registryのイメージパスを指定するだけで取得してデプロイできます。認証はIAMに統合されているため、デプロイ先のサービスアカウントにリポジトリの読み取り権限を付与すれば、同じGCPの権限体系のまま配布からデプロイまでつながります。CI/CDからは、ビルド成果物を押し込む先としてArtifact Registryを指定するのが標準的な構成です。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る