Google Cloud 完全攻略 Ep.10: Cloud BuildとArtifact Registryで学ぶCI/CDパイプライン構築入門｜SESエンジニア向け実践ガイド

⚡ 3秒でわかる！この記事のポイント

Cloud BuildはGoogle Cloudのフルマネージド CI/CD サービスで、ビルド・テスト・デプロイを自動化
Artifact Registryでコンテナイメージや言語パッケージを安全に一元管理
GitHub連携トリガー、マルチステップビルド、Cloud Runへの自動デプロイまでSES案件で即活用できる構成を網羅

📚 この記事は「Google Cloud 完全攻略」シリーズの一部です

「手動デプロイ、もうやめませんか？」——SES案件で本番環境への反映を毎回手作業で行っていると、ヒューマンエラーのリスクは増大し、リリース頻度は低下します。CI/CD（継続的インテグレーション/継続的デリバリー） パイプラインを構築すれば、コードの変更を自動でビルド・テスト・デプロイでき、開発速度と品質を大幅に向上できます。

Google CloudのCloud Buildは、フルマネージドのCI/CDプラットフォームです。Jenkins等のCI/CDサーバーを自前で構築・運用する必要がなく、YAML1つでパイプラインを定義できます。Artifact Registryと組み合わせれば、ビルドしたコンテナイメージやパッケージの管理まで一貫して行えます。

本記事では、Cloud BuildとArtifact Registryの基礎から、GitHub連携、マルチステップビルド、Cloud Runへの自動デプロイまで、SES現場で即使える実践的なCI/CDパイプライン構築を体系的に解説します。

CI/CDの基本概念——なぜ自動化が必要なのか

CI/CDとは何か

CI/CDは、ソフトウェア開発のワークフローを自動化するプラクティスの総称です。

概念	正式名称	内容
CI	Continuous Integration	コード変更のたびに自動でビルド＆テストを実行
CD	Continuous Delivery	テスト通過後、いつでもデプロイ可能な状態を維持
CD	Continuous Deployment	テスト通過後、本番環境へ自動デプロイ

SES案件でCI/CDが求められる理由

近年、SES案件の要件定義・設計書に「CI/CDパイプラインの構築」が含まれるケースが急増しています。

DevOps推進案件: CI/CDはDevOpsの中核プラクティス
マイクロサービス案件: サービスごとに独立したデプロイパイプラインが必須
クラウドネイティブ案件: コンテナ＋CI/CDは標準構成
SRE案件: リリース自動化はSREの基本責務

Cloud Buildを使いこなせれば、これらの案件で即戦力として活躍できます。

Cloud Buildの基本——フルマネージドCI/CDプラットフォーム

Cloud Buildの特徴

Cloud Buildは、Google Cloudが提供するサーバーレスのCI/CDサービスです。

特徴	詳細
フルマネージド	ビルドサーバーの構築・運用が不要
従量課金	ビルド時間に応じた課金（1日120分の無料枠あり）
コンテナベース	各ビルドステップがコンテナで実行される
豊富な連携	GitHub、Bitbucket、Cloud Source Repositoriesに対応
プライベートプール	VPC内でのビルド実行にも対応

ビルド構成ファイル（cloudbuild.yaml）

Cloud Buildのパイプラインはcloudbuild.yamlで定義します。以下は基本的な構成例です。

steps:
  # ステップ1: 依存関係のインストール
  - name: 'node:20'
    entrypoint: 'npm'
    args: ['ci']

  # ステップ2: テストの実行
  - name: 'node:20'
    entrypoint: 'npm'
    args: ['test']

  # ステップ3: Dockerイメージのビルド
  - name: 'gcr.io/cloud-builders/docker'
    args:
      - 'build'
      - '-t'
      - '${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO_NAME}/${_IMAGE_NAME}:$COMMIT_SHA'
      - '.'

  # ステップ4: イメージのプッシュ
  - name: 'gcr.io/cloud-builders/docker'
    args:
      - 'push'
      - '${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO_NAME}/${_IMAGE_NAME}:$COMMIT_SHA'

substitutions:
  _REGION: asia-northeast1
  _REPO_NAME: my-app-repo
  _IMAGE_NAME: my-app

options:
  logging: CLOUD_LOGGING_ONLY

ビルドステップの仕組み

各ステップは独立したコンテナとして実行されますが、/workspaceディレクトリが全ステップで共有されます。これにより、前のステップで生成したファイルを後続のステップで利用できます。

steps:
  # ビルド成果物を /workspace に出力
  - name: 'golang:1.22'
    args: ['go', 'build', '-o', '/workspace/app', '.']

  # 前ステップの成果物を利用
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'my-image', '.']

組み込み変数と置換変数

Cloud Buildでは、ビルド時に自動で設定される変数を利用できます。

変数	内容
`$PROJECT_ID`	GCPプロジェクトID
`$BUILD_ID`	ビルドの一意ID
`$COMMIT_SHA`	Gitコミットのフルハッシュ
`$SHORT_SHA`	Gitコミットの短縮ハッシュ（7文字）
`$BRANCH_NAME`	ブランチ名
`$TAG_NAME`	Gitタグ名
`$REPO_NAME`	リポジトリ名

ユーザー定義の置換変数（_プレフィックス）を使えば、環境ごとに値を変えることもできます。

Artifact Registry——コンテナイメージの安全な管理

なぜArtifact Registryが必要か

CI/CDパイプラインでビルドしたコンテナイメージは、デプロイ先から取得できる場所に保管する必要があります。Artifact Registryは、Google Cloudのフルマネージドパッケージリポジトリサービスです。

注意: 以前の Container Registry (gcr.io) は非推奨となり、Artifact Registry への移行が推奨されています。新規プロジェクトでは必ず Artifact Registry を使いましょう。

Artifact Registryの特徴

特徴	詳細
マルチフォーマット	Docker、Maven、npm、Python、Go、Aptなどに対応
リージョン指定	データの保存先リージョンを指定可能
IAM統合	きめ細かいアクセス制御
脆弱性スキャン	Container Analysisとの連携で自動スキャン
イメージ署名	Binary Authorizationによるイメージの署名検証

Dockerリポジトリの作成

# Artifact Registryリポジトリの作成
gcloud artifacts repositories create my-app-repo \
  --repository-format=docker \
  --location=asia-northeast1 \
  --description="本番アプリケーションのコンテナイメージ"

# Docker認証ヘルパーの設定
gcloud auth configure-docker asia-northeast1-docker.pkg.dev

# イメージのタグ付けとプッシュ
docker tag my-app:latest \
  asia-northeast1-docker.pkg.dev/PROJECT_ID/my-app-repo/my-app:v1.0.0

docker push \
  asia-northeast1-docker.pkg.dev/PROJECT_ID/my-app-repo/my-app:v1.0.0

脆弱性スキャンの有効化

Artifact Registryに保存されたイメージは、Container Analysisで自動的に脆弱性スキャンが実行されます。

# 脆弱性スキャン結果の確認
gcloud artifacts docker images list \
  asia-northeast1-docker.pkg.dev/PROJECT_ID/my-app-repo \
  --include-tags \
  --show-occurrences

# 特定イメージの脆弱性詳細
gcloud artifacts vulnerabilities list \
  asia-northeast1-docker.pkg.dev/PROJECT_ID/my-app-repo/my-app:v1.0.0

GitHub連携とビルドトリガー——自動化の起点

GitHub連携の設定

Cloud BuildとGitHubを連携させることで、プッシュやプルリクエストをトリガーにビルドを自動実行できます。

設定手順:

Google Cloud ConsoleでCloud Build > トリガーを開く
リポジトリを接続をクリック
**GitHub（Cloud Build GitHub App）**を選択
GitHubで認証し、対象リポジトリを選択
接続が完了したらトリガーを作成

ビルドトリガーの種類

トリガー種類	ユースケース
ブランチへのプッシュ	mainブランチへのマージで本番デプロイ
タグのプッシュ	セマンティックバージョニングでリリース管理
プルリクエスト	PRごとにテストを自動実行（CI）
手動実行	任意のタイミングでビルドを起動
Pub/Subメッセージ	他サービスからのイベント駆動ビルド

トリガーの作成例

# mainブランチへのプッシュでトリガーされるビルド
gcloud builds triggers create github \
  --repo-name=my-app \
  --repo-owner=my-org \
  --branch-pattern="^main$" \
  --build-config=cloudbuild.yaml \
  --description="Main branch deploy trigger"

# セマンティックバージョンタグでトリガー
gcloud builds triggers create github \
  --repo-name=my-app \
  --repo-owner=my-org \
  --tag-pattern="^v[0-9]+\.[0-9]+\.[0-9]+$" \
  --build-config=cloudbuild-release.yaml \
  --description="Release tag trigger"

プルリクエストでのCI実行

プルリクエストトリガーを設定すると、PRが作成・更新されるたびにテストが実行され、結果がGitHub上に表示されます。

gcloud builds triggers create github \
  --repo-name=my-app \
  --repo-owner=my-org \
  --pull-request-pattern="^main$" \
  --build-config=cloudbuild-ci.yaml \
  --comment-control=COMMENTS_ENABLED_FOR_EXTERNAL_CONTRIBUTORS_ONLY

実践：Cloud Run への自動デプロイパイプライン

全体構成

ここでは、最も実践的な構成としてGitHub → Cloud Build → Artifact Registry → Cloud Runの自動デプロイパイプラインを構築します。

┌──────────┐     ┌─────────────┐     ┌───────────────────┐     ┌───────────┐
│  GitHub  │────▶│ Cloud Build │────▶│ Artifact Registry │────▶│ Cloud Run │
│  (Push)  │     │ (Build/Test)│     │ (Image Store)     │     │ (Deploy)  │
└──────────┘     └─────────────┘     └───────────────────┘     └───────────┘

Cloud Build CI/CDパイプラインの全体像

cloudbuild.yaml の全体像

steps:
  # ステップ1: ユニットテスト
  - name: 'node:20-slim'
    entrypoint: 'bash'
    args:
      - '-c'
      - |
        npm ci
        npm run test:unit
    id: 'unit-test'

  # ステップ2: Dockerイメージのビルド
  - name: 'gcr.io/cloud-builders/docker'
    args:
      - 'build'
      - '-t'
      - '${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/${_IMAGE}:$COMMIT_SHA'
      - '-t'
      - '${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/${_IMAGE}:latest'
      - '--cache-from'
      - '${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/${_IMAGE}:latest'
      - '.'
    id: 'build'
    waitFor: ['unit-test']

  # ステップ3: イメージのプッシュ
  - name: 'gcr.io/cloud-builders/docker'
    args:
      - 'push'
      - '--all-tags'
      - '${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/${_IMAGE}'
    id: 'push'
    waitFor: ['build']

  # ステップ4: Cloud Runへのデプロイ
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: 'gcloud'
    args:
      - 'run'
      - 'deploy'
      - '${_SERVICE_NAME}'
      - '--image'
      - '${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/${_IMAGE}:$COMMIT_SHA'
      - '--region'
      - '${_REGION}'
      - '--platform'
      - 'managed'
      - '--allow-unauthenticated'
    id: 'deploy'
    waitFor: ['push']

substitutions:
  _REGION: asia-northeast1
  _REPO: my-app-repo
  _IMAGE: my-app
  _SERVICE_NAME: my-app-service

options:
  logging: CLOUD_LOGGING_ONLY
  machineType: E2_HIGHCPU_8

timeout: '1200s'

ステップの並列実行とwaitFor

Cloud Buildでは、waitForフィールドで依存関係を定義し、独立したステップを並列実行することでビルド時間を短縮できます。

steps:
  - name: 'node:20'
    args: ['npm', 'ci']
    id: 'install'

  # テストとlintを並列実行
  - name: 'node:20'
    args: ['npm', 'run', 'test']
    id: 'test'
    waitFor: ['install']

  - name: 'node:20'
    args: ['npm', 'run', 'lint']
    id: 'lint'
    waitFor: ['install']

  # test と lint の両方が完了してからビルド
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'my-image', '.']
    id: 'build'
    waitFor: ['test', 'lint']

Cloud Buildサービスアカウントの権限設定

Cloud BuildがCloud Runにデプロイするには、適切なIAMロールが必要です。

# Cloud BuildサービスアカウントにCloud Run管理者ロールを付与
PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')

gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
  --role="roles/run.admin"

# サービスアカウントユーザーロールも必要
gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
  --role="roles/iam.serviceAccountUser"

ビルドの最適化——速度とコストを改善する

Dockerレイヤーキャッシュの活用

ビルド時間を短縮する最も効果的な方法は、Dockerレイヤーキャッシュの活用です。

# マルチステージビルドで依存関係をキャッシュ
FROM node:20-slim AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci --production

FROM node:20-slim AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-slim AS runner
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY --from=builder /app/dist ./dist
CMD ["node", "dist/index.js"]

Kaniko を使った高速ビルド

Cloud BuildではKanikoビルダーを使うと、特権モードなしでDockerイメージをビルドでき、キャッシュもArtifact Registryに保存できます。

steps:
  - name: 'gcr.io/kaniko-project/executor:latest'
    args:
      - '--destination=${_REGION}-docker.pkg.dev/$PROJECT_ID/${_REPO}/${_IMAGE}:$COMMIT_SHA'
      - '--cache=true'
      - '--cache-ttl=168h'

マシンタイプの選択

ビルドの規模に応じて適切なマシンタイプを選択しましょう。

マシンタイプ	vCPU	メモリ	用途
`E2_MEDIUM`	1	4GB	小規模ビルド（デフォルト）
`E2_HIGHCPU_8`	8	8GB	中〜大規模ビルド
`E2_HIGHCPU_32`	32	32GB	大規模モノレポ

options:
  machineType: E2_HIGHCPU_8

セキュリティとベストプラクティス

シークレットの安全な管理

Cloud BuildではSecret Managerと連携して、APIキーやパスワードを安全に利用できます。

steps:
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '--build-arg', 'API_KEY=$$API_KEY', '.']
    secretEnv: ['API_KEY']

availableSecrets:
  secretManager:
    - versionName: projects/$PROJECT_ID/secrets/my-api-key/versions/latest
      env: 'API_KEY'

Binary Authorizationによるイメージ検証

本番環境に「検証済みイメージのみ」をデプロイするために、Binary Authorizationを活用できます。

Cloud Buildでイメージをビルド
Container Analysisで脆弱性スキャン
Attestorがイメージに署名
Binary Authorizationがデプロイ時に署名を検証
検証に通過したイメージのみCloud Run / GKEにデプロイ

クリーンアップポリシー

Artifact Registryにイメージが溜まり続けるとストレージコストが増加します。クリーンアップポリシーを設定して古いイメージを自動削除しましょう。

# クリーンアップポリシーの設定（90日以上古いイメージを削除）
gcloud artifacts repositories set-cleanup-policies my-app-repo \
  --location=asia-northeast1 \
  --policy=cleanup-policy.json

[
  {
    "name": "delete-old-images",
    "action": {"type": "Delete"},
    "condition": {
      "olderThan": "7776000s",
      "tagState": "UNTAGGED"
    }
  },
  {
    "name": "keep-minimum-versions",
    "action": {"type": "Keep"},
    "mostRecentVersions": {
      "keepCount": 10
    }
  }
]

SES案件でのCI/CDスキルの活かし方

案件タイプ別の活用パターン

案件タイプ	CI/CDの役割	求められるスキル
新規開発	パイプラインの設計・構築	cloudbuild.yaml設計、トリガー設定
既存システム改善	Jenkins等からの移行	既存パイプラインの理解・Cloud Build移行
DevOps推進	CI/CD文化の導入	ブランチ戦略、テスト自動化
SRE	デプロイ自動化・カナリアリリース	Cloud Deploy連携、ロールバック設計

面接・案件面談でのアピールポイント

CI/CDスキルをアピールする際は、以下の観点で説明できると効果的です。

ビルド時間の短縮: キャッシュ戦略、並列実行による最適化実績
セキュリティ: Secret Manager連携、脆弱性スキャン、Binary Authorization
運用設計: モニタリング連携、失敗時の通知、ロールバック手順
コスト管理: 無料枠の活用、マシンタイプの適切な選択

まとめ——CI/CDはモダン開発の必須スキル

本記事では、Cloud BuildとArtifact Registryを使ったCI/CDパイプライン構築の基礎から実践までを解説しました。

学んだこと	ポイント
Cloud Buildの基本	cloudbuild.yamlでステップベースのパイプラインを定義
Artifact Registry	コンテナイメージの安全な保管と脆弱性スキャン
GitHub連携	プッシュ/PR/タグトリガーによるビルド自動化
Cloud Runデプロイ	ビルドからデプロイまでの完全自動化パイプライン
最適化	キャッシュ、並列実行、Kanikoによるビルド高速化
セキュリティ	Secret Manager、Binary Authorization、クリーンアップ

CI/CDは、もはや「あると便利」ではなく「なければ困る」インフラです。Cloud Buildの知識を身につけることで、DevOps・SRE案件はもちろん、一般的なWeb開発案件でも大きなアドバンテージになります。

次のステップとして、自身のプロジェクトにCloud Buildを導入し、GitHub → Cloud Build → Artifact Registry → Cloud Runの一連の流れを体験してみてください。

出典・参考資料

関連記事