入門！GitHub Container RegistryでDockerイメージを管理する方法

はじめに：なぜコンテナイメージの管理が重要なのか？

現代のソフトウェア開発において、コンテナ技術は欠かせない存在となりました。アプリケーションとその実行環境を一つのパッケージとしてまとめることで、開発環境と本番環境の差異に起因する問題を解消し、デプロイメントの効率を劇的に向上させます。中でもDockerはそのデファクトスタンダードとして、多くの開発者に利用されています。

しかし、コンテナ技術の恩恵を最大限に引き出すためには、ただ単にDockerイメージを作成するだけでなく、それらを効率的かつ安全に管理することが不可欠です。アプリケーションのバージョンアップや機能追加を行うたびに新しいイメージが生まれます。これらのイメージを適切に管理することで、以下のようなメリットが得られます。

バージョン管理: 特定のバージョンのアプリケーションをいつでも再現・デプロイできるようになります。問題が発生した場合でも、すぐに以前の安定したバージョンに戻すことが可能です。
配布の容易さ: 作成したイメージを共有することで、チームメンバーやユーザーが簡単にアプリケーションを利用できるようになります。
デプロイメントの自動化: CI/CDパイプラインに組み込むことで、コードの変更があった際に自動的にイメージをビルドし、テスト済みのイメージをデプロイ対象とすることができます。
セキュリティと信頼性: 信頼できる場所でイメージを管理し、必要に応じてアクセス制限をかけることで、意図しない改変や情報漏洩を防ぎます。また、セキュリティスキャンを統合することで、イメージに含まれる脆弱性を早期に発見できます。

これらのイメージ管理を行うための中心的な役割を担うのが、「コンテナレジストリ」です。そして近年、ソフトウェア開発のプラットフォームとして広く利用されているGitHubが提供するコンテナレジストリ、GitHub Container Registry (GHCR) が注目を集めています。

この記事では、これからコンテナイメージ管理を始めたい方、特にGitHubを既に利用している方に向けて、GHCRの基本的な使い方から、より実践的な活用方法までを網羅的に解説します。約5000語にわたる詳細な説明を通じて、GHCRを使った効率的かつ安全なイメージ管理のノウハウを習得できるでしょう。

コンテナレジストリの基本

GHCRについて深く理解する前に、まずはコンテナレジストリというものが何であるか、その基本的な概念を確認しましょう。

コンテナレジストリは、Dockerイメージのようなコンテナイメージを保存・管理・配布するための集中管理システムです。Dockerイメージはファイルシステムの変更履歴などをレイヤーとして持つ形式で保存されており、このレジストリからイメージを「プル (Pull)」することで、ローカル環境やサーバー上にイメージを取得し、コンテナを実行することができます。逆に、ローカルでビルドしたイメージをレジストリに「プッシュ (Push)」することで、他のユーザーやシステムと共有することが可能になります。

主なコンテナレジストリには、以下のようなものがあります。

Docker Hub: Docker社が運営する最大手のパブリックレジストリ。多くの公式イメージが公開されており、個人利用には無料枠が提供されています。
Quay.io: Red Hatが提供するレジストリ。
クラウドプロバイダーが提供するレジストリ:
- Amazon Elastic Container Registry (ECR)
- Google Container Registry (GCR) / Artifact Registry
- Azure Container Registry (ACR)
プライベートレジストリ: Docker Distributionなどを使って自身で構築・運用するもの。

これらのレジストリは、大きく「パブリックレジストリ」と「プライベートレジストリ」に分類できます。

パブリックレジストリ: インターネット経由で誰でもアクセス可能なレジストリです。認証なしでイメージをプルできる場合が多く、OSSプロジェクトの公式イメージなどが公開されています。ただし、機密情報を含むイメージや、開発中の非公開イメージを置くには不向きです。
プライベートレジストリ: アクセスに認証が必要なレジストリです。企業内部の開発イメージや、有料ユーザー向けのイメージなど、アクセスを制限したい場合に利用します。クラウドプロバイダーのレジストリや、自己ホスト型のレジストリ、そしてGHCRのプライベート設定がこれに該当します。

GHCRは、GitHubが提供する「GitHub Packages」というパッケージ管理サービスの一部として提供されています。GHCRは、パブリックにもプライベートにも設定可能であり、GitHubのリポジトリと密接に連携できる点が大きな特徴です。

GitHub Container Registry (GHCR) の特徴

GHCRは、GitHubエコシステムの中に深く統合されたコンテナレジストリです。その主な特徴を掘り下げて見ていきましょう。

1. GitHubリポジトリとの密接な連携

GHCR最大の強みは、イメージを特定のGitHubリポジトリに関連付けて管理できる点です。多くの他のレジストリでは、イメージはユーザーや組織といったアカウントレベルで管理されますが、GHCRではイメージをリポジトリのパッケージとして紐づけることができます。これにより、アプリケーションのコードと、そのアプリケーションのコンテナイメージを同じ場所（同じGitHubリポジトリのページ）で管理できるため、開発者はどのリポジトリのコードがどのイメージに対応するのかを直感的に理解できます。

イメージの名前空間は ghcr.io/<owner>/<repository-name> という形式になることが一般的です（ユーザーまたは組織オーナーの元に、リポジトリ名をパスとして持つ）。これにより、リポジトリ名を見ればどのコードベースから作られたイメージかがすぐに分かります。

2. パッケージとしての管理

GHCRは、GitHub Packagesの一部として提供されます。GitHub Packagesは、npm、Maven、Gradle、NuGet、Docker、Apache Conanなど、様々なパッケージ形式をサポートするユニバーサルなパッケージ管理サービスです。GHCRで管理されるDockerイメージは、GitHub上のリポジトリページの「Packages」セクションに表示され、他のパッケージ形式と同様に一元管理されます。

3. Public/Private設定

GHCRにプッシュしたイメージは、PublicまたはPrivateとして設定できます。

Publicイメージ: 認証なしで誰でもプルできます。OSSプロジェクトのイメージ公開などに適しています。
Privateイメージ: アクセスするためには認証が必要です。デフォルトでは、そのイメージが紐づくリポジトリへの読み取り権限を持つユーザーや、明示的にアクセス権限が付与されたユーザーのみがプルできます。企業内の開発イメージや、特定のユーザーグループにのみ配布したいイメージに適しています。

リポジトリがPrivateであれば、デフォルトでGHCRにプッシュされるイメージもPrivateになります。Publicリポジトリの場合でも、イメージをPrivateに設定することが可能です。

4. ストレージとデータ転送の費用体系

GHCRを含むGitHub Packagesは、利用量に応じた課金体系となっています。ただし、多くの個人開発者や小規模チームにとっては、十分な無料枠が提供されています。

無料枠: GitHub Freeアカウントでは、月間500MBのストレージと、月間1GBのデータ転送（プル）が無料で利用できます。Publicリポジトリに関連付けられたPublicイメージからのデータ転送は、この無料枠にカウントされません（無制限）。
有料枠: GitHub Pro, Team, Enterprise Cloudアカウントでは、さらに多くの無料枠が提供され、それを超える利用量に対しては従量課金が発生します。

例えば、GitHub Proアカウントでは、月間2GBのストレージと、月間10GBのデータ転送が無料です。詳細な料金はGitHubの公式サイトで確認する必要がありますが、多くの一般的な利用シーンでは無料枠で十分収まることが多いでしょう。古いイメージを定期的に削除することで、ストレージ容量を節約できます。

5. その他の利点

GitHub Actionsとの連携: GitHub ActionsからGHCRへの認証やイメージのプッシュ・プルが非常に容易です。CI/CDパイプラインに自然に組み込むことができます。
アクセスコントロール: GitHubのリポジトリ権限に基づいて、イメージへのアクセス権限を柔軟に設定できます。
セキュリティスキャン: GitHub Advanced Securityを利用している場合、プッシュされたイメージの脆弱性スキャンを自動で行うことも可能です。

これらの特徴から、GHCRはGitHub上で開発を行っているチームにとって、非常に魅力的なコンテナレジストリと言えます。

GHCRの利用開始準備

GHCRを利用するために必要なものはいくつかあります。ここではその準備について説明します。

1. GitHubアカウント

大前提として、GitHubアカウントが必要です。まだ持っていない場合は、GitHubの公式サイトで作成してください。GHCRは個人アカウントでも組織アカウントでも利用できます。

2. Docker環境

Dockerイメージをビルドしたり、GHCRからプルしたりするためには、ローカル環境にDockerがインストールされている必要があります。Docker Desktop (Windows, macOS, Linux) または Docker Engine (Linux) をインストールしてください。

Dockerコマンドラインインターフェース (CLI) を使用して、イメージのビルド、タグ付け、プッシュ、プルを行います。

3. GHCRへの認証

GHCRはプライベートレジストリとして利用されることが多いため、イメージのプッシュやプライベートイメージのプルには認証が必要です。GHCRへの認証方法はいくつかありますが、最も一般的なのはPersonal Access Token (PAT) を使用する方法です。

Personal Access Token (PAT) を使用した認証 (推奨)

PATは、GitHubアカウントのパスワードの代わりに利用できるトークンです。特定の権限（スコープ）のみを持つトークンを発行することで、パスワードよりも安全にGitHub APIやGitHub Packagesへのアクセスを許可できます。

PATの作成手順:

GitHubにログインし、画面右上のプロフィール画像をクリックします。
ドロップダウンメニューから「Settings」を選択します。
左側のサイドバーから「Developer settings」を選択します。
さらに左側のサイドバーから「Personal access tokens」を選択し、「Tokens (classic)」をクリックします。
「Generate new token (classic)」ボタンをクリックします。
トークンの設定を行います。
- Note: トークンの用途を識別するための説明を入力します（例: “GHCR access for Docker CLI”）。
- Expiration: トークンの有効期限を設定します（セキュリティのため、短い期間を推奨）。
- Select scopes: このトークンに与える権限を選択します。GHCRへのプッシュに必要な権限は write:packages です。必要に応じて、プライベートリポジトリからコードをクローンしてビルドする場合などに read:packages や read:user なども選択する可能性がありますが、GHCRへのプッシュ・プルのみであれば write:packages （プッシュ）と read:packages （プル）があれば十分です。通常は write:packages を選択すれば、プルも含まれます。
ページ下部の「Generate token」ボタンをクリックします。
生成されたトークンをコピーします。このトークンは一度しか表示されませんので、必ず安全な場所に保管してください。 トークンを再表示することはできません。

PATを使ったDocker CLIからの認証:

PATを生成したら、Docker CLIからGHCRにログインします。以下のコマンドを実行してください。

bash docker login ghcr.io -u <YOUR_GITHUB_USERNAME>

<YOUR_GITHUB_USERNAME> はあなたのGitHubユーザー名に置き換えてください。コマンドを実行するとパスワードを求められます。ここで、先ほど生成したPATを入力します（GitHubアカウントのパスワードではありません）。

bash Password: <ここにPATを入力>

入力したPATは画面には表示されません。正しいPATを入力してEnterを押すと、「Login Succeeded」と表示されれば認証成功です。これで、あなたのDocker CLIからGHCRにイメージをプッシュしたり、プルしたりできるようになります。

セキュリティ上の注意点:

PATはパスワードと同様に機密情報です。流出しないように厳重に管理してください。
不要になったPATはGitHubの設定画面からすぐに削除しましょう。
PATをコマンドの引数として直接渡したり、スクリプトファイルの中に書き込んだりすることは避けましょう。環境変数を利用したり、パスワードマネージャーなどを利用したりする方が安全です。

GitHub Actionsでの認証方法 (推奨)

CI/CDパイプラインとしてGitHub Actionsを利用する場合、GHCRへの認証はさらに簡単かつ安全に行えます。GitHub Actionsでは、特別なGITHUB_TOKENというトークンが各ジョブの実行時に自動的に発行されます。このGITHUB_TOKENは、実行中のワークフローが存在するリポジトリに対する限られた権限（デフォルトでread権限、ワークフローの設定でwrite権限も可能）を持ち、GitHub Packagesへのアクセス権限も含まれています。

ほとんどの場合、GitHub Actionsから同じリポジトリに紐づくGHCRにイメージをプッシュしたり、プルしたりするには、この自動発行されるGITHUB_TOKENで十分です。

GitHub Actionsでの認証方法は、後述の「GitHub Actionsとの連携」セクションで詳しく説明します。基本的には、DockerログインアクションにGITHUB_TOKENを渡すだけです。

SSHキーを使った認証 (非推奨/限定的)

過去にはSSHキーを使った認証方法も存在しましたが、現在はPATまたはGITHUB_TOKENが推奨されています。SSHキーは主にGitリポジトリへのアクセスに使われるため、GHCRのようなパッケージレジストリへの認証にはPATやGITHUB_TOKENの方が適しています。特別な理由がない限り、PATを利用しましょう。

これで、GHCRを利用するための準備が整いました。次は、実際にDockerイメージをビルドし、GHCRにプッシュする手順を見ていきましょう。

Dockerイメージの構築とプッシュ

GHCRへの準備ができたところで、実際にDockerイメージを作成し、GHCRにプッシュしてみましょう。

1. 簡単なDockerfileの作成例

まず、コンテナ化したいシンプルなアプリケーションを用意します。ここでは、単にHTTPリクエストに対して「Hello, GHCR!」と返すだけの非常に簡単なPython Flaskアプリケーションを例とします。

プロジェクトディレクトリを作成します。

bash mkdir my-ghcr-demo cd my-ghcr-demo

Flaskアプリケーションのコード (app.py) を作成します。

“`python

app.py

from flask import Flask

app = Flask(name)

@app.route(‘/’)
def hello_world():
return ‘Hello, GHCR!’

if name == ‘main‘:
app.run(debug=True, host=’0.0.0.0’, port=5000)
“`

このアプリケーションを実行するために必要なライブラリを定義するファイル (requirements.txt) を作成します。

“`txt

requirements.txt

Flask==2.2.2 # バージョンは適宜新しいものにしても良い
“`

次に、このアプリケーションをコンテナ化するためのDockerfileを作成します。

“`Dockerfile

Dockerfile

使用するベースイメージを指定

FROM python:3.9-slim

作業ディレクトリを設定

WORKDIR /app

requirements.txtをコンテナ内にコピーし、依存関係をインストール

COPY requirements.txt .
RUN pip install –no-cache-dir -r requirements.txt

アプリケーションコードをコンテナ内にコピー

COPY app.py .

アプリケーションがリッスンするポートを指定 (ドキュメント目的)

EXPOSE 5000

コンテナ起動時に実行されるコマンドを指定

CMD [“python”, “app.py”]
“`

このDockerfileは以下の手順を実行します。

軽量なPython 3.9環境をベースイメージとして使用します。
コンテナ内のカレントディレクトリを /app に設定します。
ローカルの requirements.txt を /app にコピーします。
コピーした requirements.txt に基づいて、Pythonの依存関係をインストールします。--no-cache-dir オプションはイメージサイズを小さくするために推奨されます。
ローカルの app.py を /app にコピーします。
コンテナがポート5000を公開することを宣言します（これはあくまでドキュメントであり、実際にポートを公開するには docker run -p ... が必要です）。
コンテナが起動したときに python app.py コマンドを実行してアプリケーションを起動します。

これで、コンテナ化の準備ができました。プロジェクトのファイル構成は以下のようになります。

my-ghcr-demo/ ├── app.py ├── requirements.txt └── Dockerfile

2. ローカルでのイメージ構築 (`docker build`)

Dockerfileが準備できたら、それを使ってDockerイメージをビルドします。プロジェクトのルートディレクトリ (my-ghcr-demo) で以下のコマンドを実行します。

bash docker build -t my-ghcr-app .

docker build: イメージをビルドするコマンドです。
-t my-ghcr-app: ビルドしたイメージに my-ghcr-app という名前（タグ）を付けます。ローカルでの識別のために一時的に付ける名前です。
.: Dockerfileがあるディレクトリを指定します。カレントディレクトリを意味します。

このコマンドを実行すると、DockerはDockerfileを読み込み、記述された手順に従ってイメージを段階的にビルドします。完了すると、「Successfully tagged my-ghcr-app:latest」のようなメッセージが表示され、ローカルに新しいイメージが作成されます。

docker images コマンドで、ローカルにビルドされたイメージを確認できます。

bash docker images

出力の中に my-ghcr-app という名前のイメージがあるはずです。

3. イメージへのタグ付け (GHCR形式)

GHCRにイメージをプッシュするには、GHCRが認識できる形式のタグをイメージに付ける必要があります。GHCRの命名規則は以下の通りです。

ghcr.io/<owner>/<image-name>:<tag>

ghcr.io: GHCRのホスト名です。
<owner>: イメージをプッシュしたいGitHubユーザー名または組織名です。
<image-name>: イメージの名前です。通常は、そのイメージの元となるGitHubリポジトリ名を使用します。
<tag>: イメージのバージョンなどを識別するためのタグです（例: latest, v1.0.0, main-a1b2c3d など）。

例えば、あなたのGitHubユーザー名が your-github-user で、このアプリケーションのコードを my-ghcr-demo という名前のリポジトリで管理している場合、イメージ名は ghcr.io/your-github-user/my-ghcr-demo となります。これにバージョンタグ v1.0.0 を付けてタグ付けするには、以下のコマンドを実行します。

bash docker tag my-ghcr-app ghcr.io/your-github-user/my-ghcr-demo:v1.0.0

ここで、my-ghcr-app は先ほどローカルでビルドした際に付けた名前です。

docker images コマンドを再度実行すると、同じイメージIDを持つイメージに、新しいタグ ghcr.io/your-github-user/my-ghcr-demo:v1.0.0 が追加されていることが確認できます。

同じイメージに対して、複数のタグを付けることもよくあります。例えば、最新バージョンであることを示すために latest タグも付けたい場合は、以下のようにします。

bash docker tag my-ghcr-app ghcr.io/your-github-user/my-ghcr-demo:latest

これで、GHCRにプッシュするためのタグが準備できました。

4. GHCRへのイメージプッシュ (`docker push`)

タグ付けしたイメージをGHCRにプッシュします。プッシュする前に、上記「GHCRの利用開始準備」セクションで説明したPATを使ったdocker login ghcr.ioによる認証が完了していることを確認してください。

プッシュコマンドは以下の形式です。

bash docker push <IMAGE_NAME>:<TAG>

または、タグを指定しない場合は latest タグがデフォルトで使用されます。

bash docker push <IMAGE_NAME>

例として、先ほどタグ付けした v1.0.0 バージョンのイメージをプッシュするには、以下のコマンドを実行します。

bash docker push ghcr.io/your-github-user/my-ghcr-demo:v1.0.0

latest タグのイメージもプッシュしたい場合は、同様に実行します。

bash docker push ghcr.io/your-github-user/my-ghcr-demo:latest

プッシュが開始されると、各レイヤーのアップロード状況が表示されます。プッシュが完了すると、「Pushed」のようなメッセージが表示されます。

5. GitHub上での確認 (Packagesセクション)

イメージのプッシュが完了したら、GitHub上で確認してみましょう。イメージを関連付けたリポジトリ（この例では your-github-user/my-ghcr-demo）のページにアクセスします。

リポジトリページのトップにあるタブ（Code, Issues, Pull requests, Actionsなど）の中に、「Packages」というタブが表示されているはずです。これをクリックすると、そのリポジトリに関連付けられたGitHub Packagesの一覧が表示されます。

そこに、今プッシュした「my-ghcr-demo」という名前のコンテナイメージが表示されているはずです。イメージの名前をクリックすると、そのイメージの詳細ページが表示されます。

詳細ページでは、プッシュされたタグの一覧（v1.0.0, latestなど）、イメージのサイズ、最終更新日時、プルコマンドの例などが確認できます。ここで、イメージがPrivateとして設定されているか、Publicとして設定されているかも確認できます。

リポジトリがPrivateの場合、デフォルトでイメージもPrivateとしてプッシュされます。Publicリポジトリの場合、イメージをPublicとして公開するか、Privateとして公開するかを選択できます（通常は初回プッシュ時に自動判別されるか、設定で変更）。

これで、Dockerイメージをビルドし、GHCRにプッシュする一連の手順が完了しました。

イメージの取得 (Pull)

GHCRにプッシュされたイメージは、他のユーザーやシステムがプルして利用できます。

1. Publicイメージの取得

Publicとして設定されているGHCRイメージは、認証なしで誰でもプルできます。Docker Hubの公式イメージをプルするのと同様に、以下のコマンドを実行します。

bash docker pull ghcr.io/<owner>/<image-name>:<tag>

タグを指定しない場合は、デフォルトで latest タグのイメージがプルされます。

例:

“`bash

your-github-user/my-ghcr-demo が Public イメージとして公開されている場合

docker pull ghcr.io/your-github-user/my-ghcr-demo:v1.0.0
“`

2. Privateイメージの取得

Privateとして設定されているGHCRイメージをプルするには、認証が必要です。

Docker CLIからのプル:
- 上記「GHCRの利用開始準備」で説明したPATを使ったdocker login ghcr.ioによる認証が完了していれば、そのままPublicイメージと同様のプルコマンドでPrivateイメージもプルできます。Docker CLIが認証情報（クレデンシャル）を自動的に利用してくれます。
- 認証せずにPrivateイメージをプルしようとすると、「repository does not exist or may require ‘docker login’」のようなエラーが表示されます。
Kubernetesや他の環境でのプル:
- KubernetesのPod定義などでPrivateレジストリからイメージをプルする場合、レジストリへの認証情報を提供する必要があります。Kubernetesでは、imagePullSecretsという仕組みを使って、レジストリへの認証情報を格納したSecretオブジェクトをPodに紐づけます。
- GHCRの場合、PATを使って認証情報を持つSecretを作成し、それをPodのSpecで参照します。Secretの作成方法は、docker loginコマンドで生成される.docker/config.jsonファイルの内容（エンコードしたもの）を利用するか、kubectl create secret docker-registryコマンドを使うのが一般的です。
- 例（PATを使ってSecretを作成する場合）:
  “`bash
  # Dockerログイン
  docker login ghcr.io -u your-github-user -p your-pat-token
  
  .docker/config.json ファイルが更新される (認証情報が格納される)
  
  config.json の内容を Secret として作成
  
  jq (JSONパーサー) と base64 が必要
  
  kubectl create secret generic ghcr-pull-secret \
  –from-file=.dockerconfigjson=$HOME/.docker/config.json \
  –type=kubernetes.io/dockerconfigjson
  そして、PodのYAML定義でこのSecretを参照します。yaml
  apiVersion: v1
  kind: Pod
  metadata:
  name: my-private-app
  spec:
  containers:
  – name: app-container
  image: ghcr.io/your-github-user/my-ghcr-demo:v1.0.0 # Private イメージ
  imagePullSecrets:
  – name: ghcr-pull-secret # 作成した Secret の名前
  `` * GitHub ActionsからPrivateイメージをプルする場合も、同様に認証が必要です。Dockerログインアクション (docker/login-action`) を利用して、ジョブ内で認証を行ってからプルします。

3. 取得したイメージの実行

プルしたイメージは、docker run コマンドでコンテナとして実行できます。

bash docker run -p 5000:5000 ghcr.io/your-github-user/my-ghcr-demo:v1.0.0

-p 5000:5000: ホストのポート5000をコンテナのポート5000にマッピングします。これにより、ホストの http://localhost:5000 からコンテナ内のFlaskアプリケーションにアクセスできるようになります。

ブラウザで http://localhost:5000 にアクセスすると、「Hello, GHCR!」と表示されるはずです。

イメージの管理

GHCRにプッシュしたイメージは、GitHubのWeb UIまたはGitHub Packages API、そしてある程度はDocker CLIからも管理できます。

1. タグの付け直しとプッシュ

既にプッシュしたイメージに、新しいタグを追加したい場合があります。例えば、v1.0.0 タグでプッシュ済みのイメージに、後から release-candidate というタグを追加したい場合などです。

これは、まずローカルで対象のイメージをプルし、新しいタグを付けてから再度プッシュすることで実現できます。

“`bash

既存のイメージをプル（ローカルにあれば不要）

docker pull ghcr.io/your-github-user/my-ghcr-demo:v1.0.0

プルしたイメージに新しいタグを付ける

docker tag ghcr.io/your-github-user/my-ghcr-demo:v1.0.0 ghcr.io/your-github-user/my-ghcr-demo:release-candidate

新しいタグでプッシュ

docker push ghcr.io/your-github-user/my-ghcr-demo:release-candidate
“`

これにより、GitHub上のPackagesセクションで、同じイメージIDを持つパッケージに v1.0.0 と release-candidate の両方のタグが付与されていることが確認できます。

2. イメージの削除 (CLI / GitHub UI)

古くなったイメージや不要なタグは、ストレージ容量を圧迫し、管理を複雑にするため、定期的に削除することが推奨されます。

GitHub Web UIからの削除:

これが最も簡単で安全な方法です。

対象のリポジトリのGitHubページにアクセスします。
「Packages」タブをクリックします。
削除したいコンテナイメージの名前をクリックします。
イメージの詳細ページで、削除したいタグの右側にあるゴミ箱アイコンをクリックします。
タグではなく、イメージ自体（特定のバージョン全体、または全てのバージョン）を削除したい場合は、「Manage versions」またはページ右上の設定アイコン（歯車マーク）から削除オプションを探します。

Docker CLIからの削除 (非推奨):

Docker CLIには docker rmi コマンドがありますが、これはローカルのイメージを削除するためのコマンドです。GHCR上のイメージを直接削除するコマンドは提供されていません。

GHCR上のイメージをコマンドラインから操作するには、GitHub Packages APIを利用する必要があります。これは curl コマンドなどを使ってAPIエンドポイントを呼び出すことになりますが、よりユーザーフレンドリーなツールとしてghコマンド（GitHub CLI）やOCI Distribution Specificationに準拠したツール（例: oras）を利用できます。

GitHub CLI (gh) を使った削除:

gh コマンドをインストールしている場合、これを使ってGHCR上のパッケージを操作できます。

まず、gh auth login でGitHubアカウントにログインしておきます。

特定のパッケージ内のタグを削除するには、以下のコマンドを実行します。

bash gh package delete <package-name> --version <tag> --owner <owner>

例:

bash gh package delete my-ghcr-demo --version v1.0.0 --owner your-github-user

パッケージ全体を削除するには、--version オプションを付けずに実行します（インタラクティブに確認されます）。

bash gh package delete my-ghcr-demo --owner your-github-user

gh package コマンドは他にも、パッケージの一覧表示やダウンロードなど、様々な操作をサポートしています。CLIでの管理が必要な場合は、gh コマンドの利用を検討しましょう。

OCI Distribution Specification準拠ツール:

GHCRはOCI Distribution Specificationに準拠しているため、orasのようなツールを使ってイメージや成果物を操作することも可能です。しかし、これはより高度な使い方であり、通常のイメージ管理にはGitHub CLIやWeb UIが十分でしょう。

削除時の注意点:

イメージやタグを削除すると、基本的に元に戻すことはできません。慎重に操作してください。
特に latest タグは多くのシステムでデフォルトとして参照されるため、安易に削除せず、新しいバージョンのイメージをプッシュした後に付け替える（新しいイメージに latest タグを付ける）のが一般的です。
ストレージ容量を節約したい場合は、古いバージョンのタグやイメージを定期的に確認し、不要なものを削除しましょう。

3. Web UIでの管理機能

GitHub上のPackagesセクションでは、イメージの詳細表示以外にも、以下の管理機能が利用できます。

可視性 (Visibility) の変更: PrivateイメージをPublicに変更したり、PublicイメージをPrivateに変更したりできます。
アクセス権限の設定: 特定のユーザーやチームに対して、Privateイメージへの読み取りまたは書き込み権限を個別に付与できます。これは、リポジトリ自体の権限とは別に設定できます。
ダウンロード統計: イメージがどれだけプルされたかの統計情報（Publicイメージの場合）を確認できます。

これらの機能は、チームでの開発や、一部のユーザーへのイメージ配布を行う際に役立ちます。

GitHub Actionsとの連携

GHCRの最大の強みの一つは、GitHub Actionsとのシームレスな連携です。コードの変更をトリガーとして、自動的にDockerイメージをビルドし、GHCRにプッシュするCI/CDワークフローを簡単に構築できます。

ここでは、簡単なGitHub Actionsワークフローの例を紹介します。このワークフローは、main ブランチにプッシュがあった際に、Dockerイメージをビルドし、ghcr.io/<owner>/my-ghcr-demo としてGHCRにプッシュします。

ワークフローファイル (`.github/workflows/docker-ci.yml`)

GitHub Actionsのワークフローは、リポジトリの .github/workflows ディレクトリ内にYAMLファイルとして記述します。

“`yaml
name: Build and Push Docker Image to GHCR

on:
push:
branches:
– main # main ブランチへのプッシュをトリガーとする

jobs:
build-and-push:
runs-on: ubuntu-latest # ジョブを実行するOS環境

permissions:
  contents: read # リポジトリのコードを読み取る権限
  packages: write # GHCRにイメージをプッシュするための権限

steps:
- name: Checkout Repository
  uses: actions/checkout@v3 # リポジトリのコードをチェックアウト

- name: Log in to GitHub Container Registry
  uses: docker/login-action@v2 # Dockerレジストリにログイン
  with:
    registry: ghcr.io
    username: ${{ github.actor }} # ワークフローを実行したユーザー名 (自動的に利用可能)
    password: ${{ secrets.GITHUB_TOKEN }} # 自動発行される GITHUB_TOKEN をパスワードとして利用

- name: Extract Docker metadata
  id: meta
  uses: docker/metadata-action@v4 # Dockerイメージのメタデータ (タグ, ラベル) を自動生成
  with:
    images: ghcr.io/${{ github.repository }} # イメージ名 (例: ghcr.io/your-github-user/my-ghcr-demo)
    tags: | # 生成するタグのルール
      type=ref,event=branch # 例: mainブランチ -> main
      type=semver,pattern={{version}} # 例: v1.0.0タグ -> 1.0.0
      type=semver,pattern={{major}}.{{minor}} # 例: v1.0.0タグ -> 1.0
      type=sha # コミットハッシュの短縮形 (latestタグの代わりに使うことも多い)
      type=schedule,pattern={{date 'YYYYMMDD'}} # スケジュール実行の場合

- name: Build and push Docker image
  uses: docker/build-push-action@v4 # Dockerイメージのビルドとプッシュ
  with:
    context: . # Dockerfileがあるディレクトリ (カレントディレクトリ)
    push: true # プッシュを実行する
    tags: ${{ steps.meta.outputs.tags }} # metadata-action で生成されたタグを使用
    labels: ${{ steps.meta.outputs.labels }} # metadata-action で生成されたラベルを使用
    cache-from: type=gha # GitHub Actionsのキャッシュ機能を利用 (高速化)
    cache-to: type=gha,mode=max # GitHub Actionsのキャッシュを保存

“`

このワークフローファイルの各部分を説明します。

name: ワークフローの名前。GitHub ActionsのUIで表示されます。
on: ワークフローがトリガーされるイベントを指定します。この例では、main ブランチへの push イベントが発生したときにワークフローが実行されます。他にも pull_request, schedule, workflow_dispatch (手動実行) など様々なトリガーを指定できます。
jobs: ワークフローで実行されるジョブの集まりです。ここでは build-and-push という一つのジョブを定義しています。
- runs-on: ジョブを実行する仮想環境を指定します。ubuntu-latest が一般的です。
- permissions: ジョブが必要とする権限を明示的に指定します。これにより、最小限の権限でワークフローを実行でき、セキュリティが向上します。GHCRへのプッシュには packages: write 権限が必要です。
- steps: ジョブ内で順番に実行されるステップのリストです。
  - actions/checkout@v3: GitHub Actionsが提供する公式アクションで、ワークフローが実行されている仮想環境にリポジトリのコードをチェックアウトします。ビルドに必要なコードを取得するために必須です。
  - docker/login-action@v2: Docker公式アクションで、Dockerレジストリへのログインを行います。
    - registry: ghcr.io: ログイン対象のレジストリとしてGHCRを指定します。
    - username: ${{ github.actor }}: ログインユーザー名です。${{ github.actor }} はワークフローを実行したユーザー名またはボット（github-actions）を自動的に取得するGitHub Actionsのコンテキスト変数です。
    - password: ${{ secrets.GITHUB_TOKEN }}: ログインパスワードです。${{ secrets.GITHUB_TOKEN }} はGitHub Actionsが自動的に発行する一時的なトークンです。このトークンは、実行中のジョブが属するリポジトリへの限定的な権限を持ち、GHCRへのアクセス権限も含まれています（前述の permissions: packages: write と組み合わせて使用）。機密情報であるパスワードを直接ファイルに書く代わりに、Secrets機能と自動発行トークンを利用する、GitHub Actionsの標準的かつ安全な認証方法です。
  - docker/metadata-action@v4: Docker公式アクションで、Gitの参照情報（ブランチ名、タグ、コミットハッシュなど）から、Dockerイメージのタグやラベルを自動的に生成します。これにより、手動でタグ名を指定する手間が省け、命名規則を統一できます。
    - images: ghcr.io/${{ github.repository }}: イメージのベース名を指定します。${{ github.repository }} はリポジトリ名（例: your-github-user/my-ghcr-demo）を自動的に取得するコンテキスト変数です。したがって、イメージ名は ghcr.io/your-github-user/my-ghcr-demo となります。
    - tags: | ...: 生成するタグのルールを複数行で指定します。metadata-action はこれらのルールとトリガーイベント（プッシュされたブランチ名やタグ名など）に基づいて、適切なタグ候補を生成します。例えば、main ブランチへのプッシュであれば main というタグ、v1.0.0 というタグがプッシュされれば 1.0.0 や 1.0 といったタグが生成されます。sha タイプはコミットハッシュの短縮形をタグとします。
  - docker/build-push-action@v4: Docker公式アクションで、Dockerイメージのビルドとレジストリへのプッシュを行います。
    - context: .: ビルドコンテキストのパスを指定します。通常はリポジトリのルートディレクトリ（.）を指定します。
    - push: true: ビルド後にレジストリへプッシュすることを指定します。
    - tags: ${{ steps.meta.outputs.tags }}: metadata-action で生成されたタグリストをビルド後のイメージに適用します。
    - labels: ${{ steps.meta.outputs.labels }}: metadata-action で生成されたラベルリストをイメージに適用します。
    - cache-from, cache-to: Docker Buildxのキャッシュ機能を有効にします。type=gha はGitHub Actionsのキャッシュバックエンドを利用することを意味し、ビルドの高速化に非常に有効です。

このYAMLファイルを my-ghcr-demo リポジトリの .github/workflows/docker-ci.yml として保存し、main ブランチにプッシュすると、ワークフローが自動的に実行され、GHCRにイメージがビルド・プッシュされます。

ベストプラクティス

.dockerignore ファイルの利用: Dockerイメージに不要なファイル（開発ツールの設定ファイル、ログファイル、Git関連ファイルなど）を含めないように、.dockerignore ファイルを作成しましょう。これにより、ビルドコンテキストのサイズが小さくなり、ビルド速度が向上し、最終的なイメージサイズも小さくなります。
マルチステージビルド: ビルド時のみに必要なツールや依存関係と、実行時のみに必要なものを分けたい場合は、マルチステージビルドを利用しましょう。これにより、最終的なイメージに不要なものが含まれなくなり、イメージサイズが大幅に削減されます。
Buildxを使ったマルチプラットフォームビルド: docker/build-push-action はBuildxを内部的に利用しており、platforms オプションを指定することで、amd64だけでなくarm64など、複数のアーキテクチャ向けのイメージを一度にビルドし、manifest listとしてGHCRにプッシュできます。これにより、異なるCPUアーキテクチャの環境（例えばM1/M2 MacとLinuxサーバー）でも同じイメージタグで適切なイメージを利用できるようになります。
セキュリティスキャン: GitHub Advanced Securityを有効にしている場合、プッシュされたコンテナイメージの脆弱性スキャンが自動的に実行されます。また、サードパーティのセキュリティスキャンツールをワークフローに組み込むことも可能です。

Advanced Topics

GHCRは基本的なイメージ管理だけでなく、より高度な利用シナリオにも対応できます。

1. Multi-architecture Images

Buildxを使って、複数のCPUアーキテクチャ向けのイメージをビルドし、それらを一つのマニフェストリストとしてGHCRにプッシュすることで、異なるアーキテクチャの環境でも同じイメージタグで対応できます。

前述のGitHub Actionsワークフローの docker/build-push-action ステップに platforms オプションを追加するだけで実現できます。

yaml - name: Build and push Docker image (Multi-platform) uses: docker/build-push-action@v4 with: context: . push: true tags: ${{ steps.meta.outputs.tags }} labels: ${{ steps.meta.outputs.labels }} platforms: linux/amd64,linux/arm64 # ここでターゲットアーキテクチャを指定 cache-from: type=gha cache-to: type=gha,mode=max

これにより、例えば ghcr.io/your-github-user/my-ghcr-demo:latest というタグで、amd64とarm64の両方に対応したイメージがプッシュされます。Docker CLIやKubernetesがこのイメージをプルする際には、実行環境のアーキテクチャに応じて適切なイメージレイヤーが自動的に選択されます。

2. GitHub Packages APIを利用した操作

GitHub PackagesはREST APIを提供しており、これを利用してGHCR上のパッケージ（イメージ）情報を取得したり、削除したりすることができます。これは、自動化スクリプトからイメージを管理したい場合に役立ちます。

APIエンドポイントは https://api.github.com/users/{owner}/packages/container/{package_name} または https://api.github.com/orgs/{owner}/packages/container/{package_name} のようになります。認証にはPAT（read:packages, delete:packages スコープなど）が必要です。

例えば、特定のパッケージのバージョン一覧を取得するには、以下のようなcurlコマンドを実行できます。

bash curl -H "Authorization: token your_pat_token" \ https://api.github.com/users/your-github-user/packages/container/my-ghcr-demo/versions

詳細については、GitHub Packages APIのドキュメントを参照してください。前述の gh コマンドは、このAPIをラップしたものです。

3. ORAS (OCI Registry As Storage) について

GHCRはOCI Distribution Specificationに準拠しており、Dockerイメージだけでなく、OCI (Open Container Initiative) Artifactsと呼ばれる任意のファイルやデータを保存・管理することも可能です。

oras (OCI Registry As Storage) というCLIツールを使うと、Dockerイメージではないファイル群（例: 設定ファイル、SBOM (Software Bill of Materials)、署名データなど）をGHCRにプッシュしたりプルしたりできます。

これはまだ比較的新しい機能ですが、コンテナ関連のエコシステムで様々な成果物を一元管理するための可能性を秘めています。

GHCRの料金体系の詳細

GHCRを含むGitHub Packagesの料金は、ストレージ使用量とデータ転送量（プル）に基づいて計算されます。

ストレージ: GHCRを含むGitHub Packages全体で使用している合計ストレージ容量に対して課金されます。
データ転送: GitHub Packagesからデータがプルされた合計量に対して課金されます。ただし、Publicリポジトリに関連付けられたPublicパッケージ（GHCRイメージも含む）からのデータ転送は無料枠の対象外であり、無制限です。

各GitHubプランにおける無料枠は以下の通りです（2023年時点の情報に基づくため、最新情報はGitHub公式サイトでご確認ください）。

プラン	ストレージ無料枠	データ転送無料枠 (Private)	Publicパッケージからのデータ転送
GitHub Free (個人)	500MB	1GB/月	無制限
GitHub Pro (個人)	2GB	10GB/月	無制限
GitHub Team (組織)	2GB	10GB/月	無制限
GitHub Enterprise Cloud	50GB	50GB/月	無制限

無料枠を超えた場合の従量課金レートもプランによって異なりますが、GitHub Teamプランの場合、ストレージは1GBあたり月額$0.04、データ転送は1GBあたり$0.08（インターネット向け）程度です。

料金計算の例:

Freeプランの個人ユーザーが、Privateリポジトリに500MBのイメージを1つプッシュし、そのイメージを月間1GBプルした場合: ストレージ無料枠内 (500MB)、データ転送無料枠内 (1GB)。料金はかかりません。
Freeプランの個人ユーザーが、Privateリポジトリに1GBのイメージを1つプッシュし、そのイメージを月間2GBプルした場合: ストレージ超過 (500MB)、データ転送超過 (1GB)。この場合、ストレージ超過分とデータ転送超過分に対して課金が発生します。
Freeプランの個人ユーザーが、PublicリポジトリにPublicイメージとして500MBのイメージをプッシュし、それが月間100GBプルされた場合: ストレージ無料枠内 (500MB)。Publicイメージからのデータ転送は無制限。料金はかかりません。

Publicイメージを積極的に活用することで、多くのデータ転送費用を無料に抑えることができます。Privateイメージを利用する場合は、ストレージ容量とプル回数（データ転送量）に注意が必要です。

コスト最適化のヒント:

古いイメージ/タグの削除: 不要になった古いバージョンのイメージやタグを定期的に削除することで、ストレージ容量を節約できます。特に、古いコミットハッシュのタグなどは溜まりやすいので注意が必要です。GitHub Actionsを使って、古いイメージを自動的に削除するワークフローを組むことも可能です（GitHub CLIやAPIを利用）。
.dockerignore の活用: 不要なファイルをイメージに含めないことで、イメージサイズを小さくし、ストレージ使用量を抑えられます。
マルチステージビルド: 最終的な実行イメージサイズを小さく保つことで、ストレージ使用量とデータ転送量を削減できます。
Publicイメージの活用: 公開しても問題ないイメージは、PublicリポジトリにPublicイメージとしてプッシュすることで、無制限のデータ転送の恩恵を受けられます。

他のレジストリとの比較

GHCRは多くの利点を持つ一方で、他のコンテナレジストリと比較してどのような位置づけにあるのでしょうか？

Docker Hub: 最も広く利用されているパブリックレジストリ。多くの公式イメージがホストされています。GHCRと同様に無料枠がありますが、Privateリポジトリの数やプル回数に制限があります（無料プランの場合）。GHCRとの主な違いは、GitHubリポジトリとの統合度合いです。GitHubユーザーであれば、GHCRの方が認証などが容易です。
クラウドプロバイダーのレジストリ (ECR, GCR/Artifact Registry, ACR): 各クラウドプラットフォーム上でコンテナを実行する場合（EKS, GKE, AKS, EC2, GCE, Azure VMなど）、同じクラウド上のレジストリを利用すると、データ転送料が無料または安価になるという大きなメリットがあります。また、各クラウドのIAMと連携した細かいアクセスコントロールが可能です。GitHub中心で開発・デプロイを行う場合はGHCRが便利ですが、特定のクラウド環境で主にコンテナを実行する場合は、そのクラウドが提供するレジストリの方がコストや連携の面で有利な場合があります。
プライベートレジストリ (自己ホスト型): 完全なコントロールが可能ですが、構築、運用、スケーリング、セキュリティ対策など、管理コストが大きくなります。GHCRやクラウドプロバイダーのレジストリのようなマネージドサービスは、これらの運用負荷を大きく軽減してくれます。

GHCRが適しているケース:

開発プロセス全体をGitHub上で完結させたいチームや個人。
GitHub Actionsを使ったCI/CDパイプラインで、自動的にイメージをビルド・プッシュしたい場合。GITHUB_TOKENでの認証が非常に容易です。
イメージ管理をリポジトリと紐づけて直感的に行いたい場合。
既にGitHubの有料プランを利用しており、無料枠内で十分なストレージとデータ転送を利用できる場合。
OSSプロジェクトなど、Publicイメージを無制限のデータ転送で配布したい場合。

GHCR以外のレジストリを検討するケース:

主に特定のクラウド環境でコンテナを実行しており、そのクラウドの他のサービスとの連携やデータ転送コストを重視する場合。
GitHub以外のGitホスティングサービス（GitLab, Bitbucketなど）をメインで利用している場合（各サービスが提供するレジストリの方が連携しやすい）。
非常に大規模なイメージを大量に管理しており、GHCRの料金体系や無料枠ではコストが見合わない場合（他のレジストリや自己ホスト型を検討）。
特定の厳しいセキュリティ要件や規制があり、自己ホスト型レジストリが必要な場合。

多くのGitHubユーザーにとって、GHCRは手軽に始められ、GitHubエコシステムとの連携が強力なため、非常に魅力的な選択肢となるでしょう。まずはGHCRを試してみて、必要に応じて他のレジストリと比較検討するのが良いアプローチです。

トラブルシューティング

GHCRを利用する際によく遭遇する問題とその解決策をいくつか紹介します。

1. ログインエラー (`denied: Your authorization token has expired.`)

原因: docker login ghcr.io コマンドで認証に使用したPATの有効期限が切れているか、PATが誤っている可能性があります。
解決策:
- GitHubのSettings > Developer settings > Personal access tokens (classic) で、使用しているPATの有効期限を確認します。必要に応じて新しいPATを作成します。
- docker login ghcr.io コマンドを再度実行し、有効なPATをパスワードとして正確に入力します。
- ユーザー名が正しいか確認します (-u <YOUR_GITHUB_USERNAME>)。

2. プッシュエラー (`denied: package with the same name and visibility already exists`)

原因: プッシュしようとしているイメージ名 (ghcr.io/<owner>/<image-name>) が、指定したOwnerのGitHub Packagesに既に存在し、かつ可視性（Public/Private）の設定が異なっている場合に発生することがあります。例えば、Privateリポジトリでイメージをプッシュしようとしたが、同じ名前のPublicイメージが既に存在する場合などです。
解決策:
- プッシュしようとしているイメージ名が正しいか確認します。
- GitHubのPackagesセクションで、同じ名前のパッケージが既に存在しないか確認します。存在する場合、そのパッケージの可視性が意図した設定（PrivateリポジトリならPrivate、PublicリポジトリでPublicにしたいならPublic）になっているか確認します。
- もし、同じ名前で可視性が異なるパッケージが存在する場合は、名前を変更するか、既存のパッケージを削除する必要があります。基本的には、GHCRのイメージ名は関連付けるリポジトリ名と同じにすることをお勧めします。リポジトリの名前を変更することで、イメージ名も実質的に変更できます。
- 稀なケースとして、過去にプッシュした際に意図しない可視性で作成されてしまった場合があります。その場合はGitHub UIから可視性を変更するか、一度パッケージを削除してからプッシュし直す必要があります。

3. プルエラー (`repository does not exist or may require 'docker login'`)

原因: プルしようとしているイメージが存在しないか、存在してもPrivateイメージであり認証が完了していない可能性があります。
解決策:
- プルしようとしているイメージ名とタグ (ghcr.io/<owner>/<image-name>:<tag>) が正確か確認します。GitHubのPackagesセクションでイメージとタグの存在を確認します。
- プルしようとしているイメージがPrivateの場合、docker login ghcr.io による認証が完了しているか確認します。完了しているにも関わらず発生する場合は、PATの有効期限や権限（read:packages または write:packages スコープが必要）を確認します。
- GitHub ActionsやKubernetesなど他の環境からプルする場合は、その環境での認証設定（例: GITHUB_TOKENの利用、imagePullSecretsの設定など）が正しく行われているか確認します。特にGitHub Actionsでは、ジョブに permissions: packages: read または write が付与されているか確認します。

4. GitHub Actionsでの権限エラー

原因: ワークフロー実行に使用しているGITHUB_TOKENに必要な権限が付与されていない可能性があります。例えば、GHCRへのプッシュに失敗する場合などです。
解決策:
- ワークフローYAMLファイルのジョブ定義に permissions: packages: write が正しく記述されているか確認します。GitHub Actionsのデフォルト設定では、GITHUB_TOKENはリポジトリの読み取り権限のみを持つため、プッシュには明示的な権限設定が必要です。
- リポジトリ全体の権限設定（Settings > Actions > General > Workflow permissions）で、GITHUB_TOKEN のデフォルト権限が制限されていないか確認します。通常は「Read and write permissions」が推奨されますが、ジョブ単位で厳密に制御する場合は上記の permissions ブロックを使用します。
- プライベートリポジトリのPrivateイメージをプルする場合にも、permissions: packages: read が必要です。

まとめ

この記事では、GitHub Container Registry (GHCR) を使ったDockerイメージの管理方法について、入門レベルから詳細までを網羅的に解説しました。

GHCRは、GitHubリポジトリとの緊密な連携、Packageとしての管理、柔軟なPublic/Private設定といった特徴を持ち、特にGitHubを中心に開発を行っているチームや個人にとって、コンテナイメージ管理の強力な味方となります。

基本的な利用手順として、以下のステップを学びました。

GHCRへの認証（主にPATを使ったdocker login）。
Dockerfileを使ったイメージのビルド。
GHCRの命名規則に沿ったイメージへのタグ付け。
GHCRへのイメージプッシュ。
GitHub Packages上でのイメージ確認と管理。
GHCRからのイメージプル。

さらに、GitHub Actionsを使った自動ビルド・プッシュのワークフロー構築、Buildxによるマルチプラットフォームイメージ対応、料金体系、他のレジストリとの比較、そしてよくあるトラブルシューティングについても詳しく説明しました。

GHCRとGitHub Actionsを組み合わせることで、コードの変更からコンテナイメージの作成、そしてレジストリへの登録までを完全に自動化でき、CI/CDパイプラインの効率と信頼性を大幅に向上させることができます。

コンテナ技術は今後もソフトウェア開発の基盤として重要性を増していくでしょう。GHCRのような使いやすくGitHubエコシステムに統合されたレジストリを活用することで、現代的な開発ワークフローをスムーズに進めることができます。

ぜひこの記事を参考に、GHCRを使ったDockerイメージ管理を実践してみてください。そして、GitHubが提供する他の機能（Actions, Packages, Security featuresなど）と組み合わせて、より効率的でセキュアな開発プロセスを構築していきましょう。