はじめに
CI/CDツールの選定、迷いますよね。特にGCP（Google Cloud Platform）を使っている場合、「GitHub Actionsで全部やるのが楽なのか、それとも純正のCloud Buildを使うべきなのか？」という疑問は、多くの開発者が一度は直面するテーマです。
この記事では、両者の特徴を整理し、5つの観点で徹底比較します。それぞれの強みを理解して、自分のプロジェクトに最適なツールを選べるようになりましょう。
各サービスの概要
GitHub Actionsとは
GitHubが提供するCI/CDプラットフォームです。リポジトリにYAMLファイルを置くだけで、PushやPull Requestをトリガーとしてワークフローを実行できます。
主な特徴
- GitHubとの完全統合: リポジトリのイベント（Issue作成、Star付与など）もトリガーにできる。
- 豊富なMarketplace: 世界中の開発者が作ったActionを再利用できるため、構築が爆速。
- 学習コストが低い: GitHubを使っていれば、追加のアカウント管理などが不要。
Cloud Buildとは
GCPが提供するサーバーレスのCI/CDプラットフォームです。Dockerコンテナを使用してビルドステップを実行するのが特徴です。
主な特徴
- GCPサービスとの親和性: Cloud RunやGKEへのデプロイ、Artifact RegistryへのPushが非常にスムーズ。
- コンテナベース: ビルドステップ自体がコンテナで動くため、環境依存の問題が起きにくい。
- セキュリティ: VPC内でのプライベートビルドや、詳細なIAM権限管理が可能。
徹底比較：5つの観点
それでは、具体的な違いを見ていきましょう。
1. 統合環境とエコシステム
GitHub Actionsの最大の強みは「GitHubで完結すること」です。ソースコードと同じ場所でCI/CDの設定を管理でき、Pull Requestの画面でビルド結果を確認できる体験は非常にスムーズです。Marketplaceには「AWSへのデプロイ」「Slack通知」など、ありとあらゆるパーツが揃っています。
一方、Cloud Buildは「GCPエコシステムの一部」です。GCPコンソールからビルド履歴やログを確認できるため、他のGCPリソース（Cloud Runのログなど）と行ったり来たりする運用管理においては分があります。
2. トリガーとイベントハンドリング
GitHub Actions
Git系のイベントにめっぽう強いです。「mainブランチへのPush」「v1.0タグの作成」「特定のファイル変更時」といった条件を柔軟に指定できます。
Cloud Build
基本はGitHubやBitbucketのPushトリガーですが、面白いのは「Pub/Subメッセージ」や「Webhook」をトリガーにできる点です。これにより、「GCSにファイルがアップロードされたらビルドを走らせる」といった、CI/CDの枠を超えた自動化基盤としても機能します。
3. 記述形式と柔軟性
GitHub Actions (YAML)
steps の中で uses を使って既存のActionを呼び出すのが基本スタイルです。
steps:
- uses: actions/checkout@v3
- uses: google-github-actions/auth@v1
with:
credentials_json: ${{ secrets.GCP_SA_KEY }}
Cloud Build (YAML / JSON)
各ステップで「どのコンテナイメージを使うか」を指定します。非常にシンプルで、Dockerに慣れている人には直感的です。
steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'gcr.io/my-project/my-image', '.']
4. パフォーマンスとキャッシング
GitHub Actionsは、標準のランナー（Microsoft Azure上で動作）を使用する場合、マシンスペックは固定です。ビルドの度にクリーンな環境が立ち上がるため、キャッシュの設定（actions/cache）をうまく使わないと毎回依存関係のインストール待ちが発生します。
Cloud Buildは、マシンタイプ（CPU数やメモリ）を選択可能です。重いビルド処理がある場合は、ハイパフォーマンスなマシンを指定して時間を短縮できます。また、Kanikoキャッシュなどを利用したDockerレイヤーのキャッシュも強力です。
5. 料金体系
GitHub Actions
- パブリックリポジトリ：無料
- プライベートリポジトリ：月間2,000分まで無料（プランによる）
- 超過分は従量課金
Cloud Build
- 1日あたり120分のビルド時間が無料
- 超過分はビルドマシンのスペックに応じた従量課金
小〜中規模のプロジェクトであれば、どちらも無料枠内で収まることが多いですが、頻繁にビルドする大規模開発では試算が必要です。
ユースケース別のおすすめ
GitHub Actionsを選ぶべき場合
- 手軽に始めたい: GitHubリポジトリさえあれば、今すぐ始められます。
- CIメインの用途: テスト実行、Lintチェック、カバレッジ計測などはActionsが圧倒的に便利です。
- マルチクラウド: GCPだけでなくAWSやAzureにもデプロイする、あるいはnpmパッケージを公開するなど、用途が多様な場合。
Cloud Buildを選ぶべき場合
- コンテナビルド特化: Dockerイメージを作ってArtifact RegistryにPushし、Cloud Runにデプロイするフローなら、これ以上ないほどシンプルに書けます。
- セキュリティ要件が厳しい: 社内ネットワーク（VPC）内のみでビルドを実行したい、外部への通信を制限したい場合。
- 長時間・高負荷なビルド: 強力なマシンパワーが必要な場合。
まとめ
「どっちか」ではなく「いいとこ取り」もアリ
個人的なおすすめパターンは以下です。
- テスト・Lint（CI） は GitHub Actions で回す（PRのフィードバックが早いから）
-
デプロイ（CD） は GitHub Actions から
google-github-actions/deploy-cloudrunなどを使う - もしビルドが複雑・重い、あるいはセキュリティ制約があるなら、デプロイ部分は Cloud Build に任せる（GitHub ActionsからCloud Buildをトリガーする）
プロジェクトのフェーズや要件に合わせて、柔軟に選んでみてください。まずは手軽なGitHub Actionsから始めて、不足を感じたらCloud Buildを検討するという流れでも全く問題ありません。