コンテナレジストリとは？種類・選び方から企業の導入判断まで解説

コンテナレジストリは、ビルドしたコンテナイメージを保管し、開発環境や本番のKubernetesへ配布するためのサーバです。Docker HubのようなパブリックなものからAmazon ECRやAzure Container Registry、自前で運用するHarborまで選択肢は幅広く、どれを選ぶかで運用体制とセキュリティの前提が変わります。この記事では、レジストリとリポジトリの違いといった基礎から、主要製品の比較、マネージドとセルフホストの損益分岐、そしてGoogle Container Registry廃止に学ぶ移行リスクまで、企業がどう選ぶべきかの判断軸で整理します。

まとめ：コンテナレジストリ選定は管理形態と運用体制で決まる

コンテナレジストリの本質は、イメージという成果物を安全に保管し、正しいバージョンを本番へ届ける「配布の起点」である点にあります。選定で最初に分かれるのは、クラウド各社のマネージド型を使うか、Harborなどを自前で立てるセルフホスト型かの二択です。

結論を先に述べます。数人から数十人規模で、すでにAWSやAzureなど特定クラウドに寄せているチームは、そのクラウドのマネージドレジストリを選ぶのが合理的です。逆に、規制対応で保管場所を自社管理下に置きたい、複数クラウドをまたぐ、脆弱性スキャンや署名を統一ポリシーで強制したいといった要件が重なったときにだけ、Harborの自前運用が損益分岐を超えます。マネージドでもGoogle Container Registryのように廃止・移行が起きるため、どちらを選んでもOCI準拠でロックインを避け、イメージの再配置手段を確保しておくことが前提になります。

コンテナレジストリとは何か、イメージの保管と配布を担う中核基盤

まず、レジストリが開発フローのどこに位置するかを押さえます。前提となるコンテナそのものの仕組みはコンテナとは何かと仮想マシンとの違いで解説しているため、ここではイメージが生まれてから本番に届くまでの流通経路に絞って説明します。

レジストリ・リポジトリ・タグの三層構造とpush/pullの流れ

コンテナレジストリは三つの階層で成り立ちます。最上位が「レジストリ」というサーバ全体、その中に「リポジトリ」がイメージ名の単位で並び、各リポジトリの中に「タグ」がバージョン識別子として付きます。たとえばghcr.ioがレジストリ、その下の app という名前がリポジトリ、v1.2 や latest がタグという対応関係です。

開発者はビルドしたイメージをdocker pushでレジストリへ送り、実行側はdocker pullで取得します。PodmanなどDocker以外のツールでも同じ操作が可能で、その違いはPodmanとdockerの違いとデーモンレスの仕組みにまとめました。押し出す先と引き出す先が同じレジストリだからこそ、開発と本番でまったく同一のイメージを再現できます。

パブリックとプライベート、二種類のレジストリ公開形態の使い分け

レジストリは公開範囲で二種類に分かれます。パブリックレジストリの代表がDocker Hubで、誰でもイメージを取得できる手軽さが持ち味です。一方で、未認証の取得には6時間あたり100回という制限があり（Docker Personalは200回、2025年時点）、CIが多数のノードから一斉にpullすると制限に触れて失敗する事故が起きます。

プライベートレジストリは、社内や特定プロジェクトだけがアクセスできる閉じた保管庫です。認証を必須にし、外部へイメージを露出させない前提が作れます。業務システムの本番イメージには、まずプライベート運用を基本に据えるのが原則です。フロントで使う公開イメージはパブリックから取得しつつ、自社の成果物はプライベートに閉じる、という二段構えが現実的な落としどころになります。

OCI Distribution Specが担保するレジストリ間の相互運用性

主要レジストリがどれも同じ操作で扱えるのは、OCI（Open Container Initiative）が定めるDistribution Specという共通のAPI仕様があるためです。CNCFのDistributionプロジェクトがこの仕様を実装し、Docker Hubの土台にもなっています。

この標準に準拠している限り、あるレジストリで作ったイメージを別のレジストリへ移す作業は、基本的にpullして別名でpushし直すだけで完結します。製品選定で「あとから乗り換えられるか」を心配しすぎる必要が薄いのは、この相互運用性が効いているからです。ただし脆弱性スキャン結果やアクセス権限の設定は各製品固有で移植できないため、そこは移行コストとして残ります。

主要なコンテナレジストリの種類とマネージド各社製品の比較観点

製品は大きく、クラウド各社が運用を肩代わりするマネージド型と、自社サーバに立てるセルフホスト型に分かれます。まずマネージド型を、続いてセルフホストの代表であるHarborを見ていきます。

マネージド型レジストリ（ECR・ACR・GHCR）の特徴と料金傾向

マネージド型は、可用性・バックアップ・スケールをクラウド側が担うため、運用の手離れが良いのが持ち味です。多くは保管容量とネットワーク転送量による従量課金で、小規模なら月数ドル程度に収まります。使っているクラウドやCIに寄せると認証と権限管理が一体化し、導入の摩擦が最も小さくなります。

GitHub Actionsで開発しているなら、GitHub Container Registry（ghcr.io）がパイプラインと同じ画面で完結し、無料枠と課金条件はGitHub Container Registryの料金と無料枠の条件に詳しくまとめています。どれも一長一短ですが、選定の第一基準は「今どのクラウドとCIに乗っているか」です。まだ寄せ先が決まっていない段階でレジストリ単体を先に決めるのは、順序が逆になります。

セルフホスト型のHarbor・Distributionが向く運用条件

セルフホスト型の代表がHarborです。2018年にCNCFへ参加し、2020年6月に最上位のGraduatedへ到達したオープンソースのレジストリで、CNCFのDistributionを土台に、RBAC（役割ベースのアクセス制御）、脆弱性スキャン、イメージ署名、監査ログを一つにまとめています。

向くのは、イメージの保管場所を自社の管理下に置く必要がある局面です。金融や医療のように保管先の所在が問われる規制業種、オンプレミスや複数クラウドをまたいでレジストリを一元化したい構成、そして全チームに同じスキャン・署名ポリシーを強制したい大きめの組織が該当します。裏を返せば、これらの要件が無いのに自前で立てると、可用性の確保やスキャンDBの更新といった運用が丸ごと自社負担になります。

脆弱性スキャンとイメージ署名で固めるサプライチェーン防御の要点

レジストリはセキュリティの検問所でもあります。押さえるべき機能は二つです。一つは脆弱性スキャンで、イメージに含まれるOSパッケージやライブラリの既知の脆弱性を検出します。TrivyやClairが代表で、Harborや各クラウドのマネージド製品にも組み込まれています。

もう一つがイメージ署名です。Cosign（Sigstore）などで署名を付け、本番のKubernetesが「署名済みのイメージしか動かさない」と決めれば、改ざんされた偽イメージの混入を止められます。スキャンで「危ないものを入れない」、署名で「正しいものだけを出す」という二重の関所を、レジストリの標準機能として設計に組み込むのが要点です。導入の順序としては、まず全イメージのスキャン自動化から始め、署名の強制は運用が安定してから広げると無理がありません。

CI/CDパイプラインとKubernetesへのイメージ連携

レジストリはCI/CDの継ぎ目に座ります。パイプラインがビルドしたイメージをpushし、それをKubernetesがデプロイ時にpullする、という受け渡しの中継点です。Kubernetes側でプライベートレジストリから取得するには、imagePullSecretsで認証情報を渡します。

1. CIがソースからイメージをビルドする
2. 脆弱性スキャンを通し、基準を満たせばレジストリへpushする
3. タグを本番用に昇格させる
4. Kubernetesが該当タグをpullしてデプロイする

この連携の受け手となるKubernetesの役割はコンテナオーケストレーションとKubernetesの判断で整理しています。パイプラインとレジストリを同じ提供元でそろえると認証設定が一箇所で済むため、CIツールを決める段階でレジストリも合わせて考えると手戻りが減ります。

マネージドとセルフホスト型を分ける損益分岐点と企業の導入判断

ここからは選定を言い切ります。ベンダーの製品ページは自社製品を勧める立場のため、中立の判断軸はここで示します。

マネージドを選ぶべき要件とHarbor自前運用が過剰になる場面

マネージド型を選ぶべきなのは、次のいずれかに当てはまるときです。すでに特定クラウドに本番環境を寄せている。レジストリ専任の運用担当を置けない。数人から数十人規模で、可用性やスキャンDBの保守に工数を割きたくない。この場合、Harborを自前で立てるのは過剰投資になります。

小規模チームが「制御したいから」という理由だけでHarborを運用し始めると、レジストリ本体の冗長化、ストレージ管理、脆弱性データベースの定期更新までが自チームの持ち物になり、本来の開発が痩せます。自社で作り込むより外部の開発体制に委ねたほうが速い場面も多く、モダンな開発基盤の構築はWebシステム開発の相談として設計から任せる選択肢もあります。Harborが損益分岐を超えるのは、規制・マルチクラウド・全社ポリシー強制のいずれかが実在するときだけです。

GCR廃止の教訓に見る、マネージドでも残る移行リスクへの備え

マネージドを選んでも移行リスクはゼロになりません。実例がGoogle Container Registry（gcr.io）です。2025年3月18日に書き込みが停止し、5月20日には読み取りも遮断され、後継のArtifact Registryへの移行が必須になりました。運用を任せていた側にとって、廃止は自分では止められない事象です。

だからこそ、どのレジストリを選んでもOCI準拠であることを確認し、イメージを別のレジストリへpull・pushで再配置できる状態を保っておきます。加えて、本番で動くイメージのタグとビルド定義をコードとして管理しておけば、レジストリが変わっても同じイメージを別の場所で再生成できます。マネージドの手離れの良さを享受しつつ、乗り換え手段だけは自分の手に残す。これが廃止事例から引ける実務的な備えです。

よくある質問

コンテナレジストリの選定と運用で、実際の検索で多く見られる疑問に回答します。

コンテナレジストリとDockerイメージはどう関係しますか？

Dockerイメージはコンテナの実行に使う成果物のファイルで、コンテナレジストリはそのイメージを保管・配布するサーバです。ビルドしたイメージをレジストリへpushして保存し、実行環境がpullして取り出します。イメージが「モノ」、レジストリが「モノを置く倉庫と配送口」という関係です。DockerイメージはOCIイメージ仕様に沿っており、Docker以外のツールで作ったイメージも同じレジストリで扱えます。

コンテナのレジストリとリポジトリの違いは何ですか？

レジストリはイメージを保管するサーバ全体を指し、リポジトリはその中にあるイメージ名ごとの入れ物です。一つのレジストリの中に多数のリポジトリが並び、各リポジトリの中にタグ付きの複数バージョンが入ります。住所でたとえると、レジストリが建物、リポジトリが部屋、タグが棚番号にあたります。同じ「リポジトリ」でもGitのソースコード置き場とは別概念のため、文脈で読み分けてください。

コンテナレジストリの料金はどのくらいかかりますか？

マネージド型は保管容量とネットワーク転送量による従量課金が中心で、小規模なら月数ドル程度から始められます。GitHub Container Registryのように無料枠を持つ製品もあります。転送量は本番のスケールやCIのpull回数で膨らむため、コストが読みにくいのは容量より転送側です。セルフホストのHarborはソフトウェア自体は無料ですが、サーバ・ストレージ・運用工数という別のコストがかかります。

Google Container Registryはいつ廃止されましたか？

gcr.ioは2025年3月18日に書き込みが停止し、2025年5月20日に読み取りも遮断されました。後継はArtifact Registryで、10月14日以降はgcr.ioのURL自体がArtifact Registryから配信される形に移行しています。すでにgcr.ioを使っていた場合は、Artifact Registryへイメージを移す対応が必要でした。マネージドサービスでも廃止・移行が起きる一例です。

自社構築とクラウドマネージド、どちらを選ぶべきですか？

特定クラウドに本番を寄せていて運用の手離れを優先するならマネージド、保管場所の自社管理・複数クラウド統合・全社ポリシー強制のいずれかが必要ならセルフホストのHarborが候補です。数人規模でこれらの要件が無ければマネージド一択で、Harborの自前運用は過剰になりがちです。判断に迷う場合は、まず現在のクラウドとCIの構成を起点に、そこへ最も摩擦なく乗る製品から検討すると外しません。

関連記事

• コンテナとは？仮想マシンとの違いから企業の導入判断まで：レジストリが扱うイメージの前提となるコンテナ技術を解説しています。
• クラウドネイティブとは：レジストリを含むクラウドネイティブ開発の全体像がわかります。
• コンテナオーケストレーションとは：レジストリからイメージをpullして動かすKubernetesの役割を扱います。
• GitHub Container Registryの料金：マネージドレジストリ1製品の無料枠と課金条件を具体的に確認できます。
• Podmanとdockerの違い：レジストリへpush・pullするツール側の選択肢を整理しています。