アーティファクトレジストリ
ビルドで生まれた成果物（コンテナイメージやライブラリ）を保管・配布する専用倉庫です。バージョン管理と脆弱性スキャンを備え、CI/CD の出力とデプロイの入力をつなぐ要になります。
- 1.アーティファクトレジストリは、ビルド成果物（コンテナイメージ・パッケージ等）を保管・配布する専用ストレージ。
- 2.不変なバージョン（タグ）で管理し、CI が作って push、デプロイ側が pull する。「作る」と「動かす」の受け渡し点。
- 3.脆弱性スキャンや署名と組み合わせ、出所が確かで安全な成果物だけを本番に流す（サプライチェーン保護）。
アーティファクトレジストリとは
アーティファクト（artifact） とは、ビルドの結果できあがる 成果物 のことです。コンテナイメージ、Java の JAR、npm パッケージ、.zip で固めた配布物などが該当します。アーティファクトレジストリ は、これらを 保管し、必要なときに配布する専用の倉庫 です。
なぜ専用の倉庫が要るのでしょうか。ソースコードは Git で管理しますが、ビルド後の成果物は Git には向きません（サイズが大きい・バイナリで差分管理できない）。かといって各サーバでその都度ビルドし直すと、時間がかかるうえ「ビルドするたびに微妙に中身が違う」事態を招きます。一度ビルドした成果物を1か所に置き、どこからでも同じものを取り出せる ようにするのがレジストリの役割です。
CI/CD をつなぐ「受け渡し点」
レジストリの本質は、「作る（CI）」と「動かす（デプロイ）」の受け渡し点 になることです。流れはこうです。
- CI がビルド して成果物（例：コンテナイメージ）を作る。
- その成果物を レジストリへ push（登録） する。
- デプロイ時に、各環境が レジストリから pull（取得） して動かす。
ここで重要なのが 「一度だけビルドし、同じ成果物を全環境で使い回す」 という原則です。開発・ステージング・本番でビルドし直すのではなく、ステージングで検証した“まさにそのイメージ”を本番にも流す。これにより「テストした物と本番の物が違う」という事故を根絶できます。考え方はイミュータブルインフラ（/devops/immutable-infra/）と同じです。
環境ごとにビルドし直すと、依存ライブラリの版ずれなどで「ステージングは動いたのに本番で壊れる」が起きます。ビルドは1回、成果物を環境間で使い回す。環境ごとの違いは設定（環境変数）で吸収する——これが Twelve-Factor App（/devops/twelve-factor-app/）の発想です。
バージョン管理とタグ
レジストリ上の成果物は バージョン（タグ） で識別します。コンテナイメージなら myapp:1.4.2 のように「名前 : タグ」で指定します。
ここで初心者がつまずくのが latest タグ です。latest は「最新」という意味の ただの慣習的な名前 で、自動で最新を指すわけではありません。push のたびに別の中身を指しうるため、本番で latest を使うと「いつの間にか中身が変わっていた」「どの版が動いているか分からない」事態になります。
| タグの付け方 | 例 | 向き不向き |
|---|---|---|
latest（可変） | myapp:latest | 手元の試用◯ / 本番✕（中身が変わる） |
| セマンティックバージョン | myapp:1.4.2 | 人が読みやすく、リリース管理に向く |
| コミットハッシュ | myapp:a1b2c3d | どのソースから作ったか厳密に追える |
| ダイジェスト（内容ハッシュ） | myapp@sha256:... | 内容で固定。最も確実（不変） |
本番デプロイで latest を指定すると、ロールバックしたくても「戻したい版がどれか分からない」状態に陥ります。本番は バージョンタグかダイジェストで固定 し、「いま動いているのは確実にこの成果物」と言い切れるようにしましょう。
脆弱性スキャンと署名
レジストリは単なる倉庫にとどまらず、安全性を担保するゲート としても機能します。代表的な機能が2つあります。
- 脆弱性スキャン：登録された成果物（特にコンテナイメージ）に含まれる OS パッケージやライブラリを調べ、既知の脆弱性（CVE） がないかを検査します。「危険な版を含むイメージは本番に出さない」というポリシーを敷けます。依存ライブラリ側の検査は依存性スキャン（/devops/dependency-scanning/）と連携します。
- 署名と検証：成果物に デジタル署名 を付け、デプロイ時に「正規のCIが作った、改ざんされていない物か」を検証します。なりすましたイメージが紛れ込むのを防ぎます。
これらは ソフトウェアサプライチェーンの保護 という文脈で重要度を増しています。「出所が確かで、既知の穴がない成果物だけを動かす」ための関所が、レジストリなのです。
代表的なレジストリ
扱う成果物の種類によって、いくつかのタイプがあります。
| 種類 | 主な対象 | 例 |
|---|---|---|
| コンテナレジストリ | コンテナイメージ（OCI） | Docker Hub、GitHub Container Registry、各クラウドのレジストリ |
| パッケージレジストリ | 言語別パッケージ | npm、Maven、PyPI（社内ミラーを含む） |
| 汎用アーティファクト管理 | 上記をまとめて扱う | JFrog Artifactory、Sonatype Nexus |
コンテナイメージは OCI（Open Container Initiative） という標準仕様に従うため、特定のツールに縛られず相互運用できます。社内向けには、外部レジストリの プロキシ／キャッシュ を立てて、取得の高速化と外部障害時の耐性を確保するのも定番です。
まとめ
- アーティファクトレジストリは ビルド成果物（イメージ・パッケージ）を保管・配布する専用倉庫。
- 「作る（CI）」と「動かす（デプロイ）」の受け渡し点。一度ビルドした成果物を全環境で使い回すのが原則。
- バージョン（タグ）で識別。本番では
latestを避け、版やダイジェストで固定してロールバック可能に。 - 脆弱性スキャン・署名 で、出所が確かで安全な成果物だけを流す関所として働く。
DevOps/インフラ Article
アーティファクトレジストリを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
アーティファクト
比較で見る軸
難易度: basic / カテゴリ: DevOps/インフラ / タグ数: 4
導入後に効く点
不変なバージョン（タグ）で管理し、CI が作って push、デプロイ側が pull する。「作る」と「動かす」の受け渡し点。
先に潰すリスク
用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。
- 難易度
- basic
- カテゴリ
- DevOps/インフラ
- タグ数
- 4
判断チェックリスト
- 自社の用途が「アーティファクト / コンテナレジストリ」に近いか確認する。
- 強みである「アーティファクトレジストリは、ビルド成果物（コンテナイメージ・パッケージ等）を保管・配布する専用ストレージ。」が本当に評価軸になるか確認する。
- 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。