Cloud Buildのビルド環境が2027年3月28日に切り替わる｜sGTMや自動化基盤を持つ広告運用者が先に試しておくこと

Google Cloudの利用者に「[推奨処理] 新しいデフォルト バージョンが適用される前に Cloud Build 構成をテストしてください」という通知が届いています。Cloud Buildにリリース チャンネルという仕組みが入り、ビルドを実行するワーカーの標準環境が2027年3月28日に切り替わるためです。

広告運用の現場でも、サーバーサイドGTM（sGTM）をCloud Runで動かしていたり、Cloud Functionsでレポート集計を自動化していたりする方は少なくありません。本記事では、何が変わるのか、どんな構成で影響が出やすいのか、切り替え前にどう試せばよいのかを、公式ドキュメントをもとに整理します。

何が変わるのか｜ワーカーのDockerとOSが新しくなる

Cloud Buildのビルドは、Google側が用意した仮想マシン（ワーカー）の上で動きます。今回の変更は、このワーカー自体のソフトウェア構成を対象にしたものです。

公式ドキュメント「Cloud Build のリリース チャンネル」によると、2027年3月28日までは legacy が標準で使われ、それ以降は regular チャンネルが標準になります。2026年10月6日時点で公開されているリリースは次の2つです。

DockerはEngine 20.10から29へ、OSはDebian 11から13へと、2世代以上の更新になります。普段は意識しない土台の部分ですが、差分は小さくありません。

チャンネルは3種類あり、新しいリリースが出たときに追従する速さが違います。

変わらないもの｜ビルドステップの中身は対象外

公式ドキュメントは「リリース チャンネルは、基盤となるワーカー VM ホスト環境のみを管理します」と明記しています。ビルドステップで使うコンテナの中のソフトウェアは、引き続き利用者が管理するものです。

たとえばビルドステップで node:20 や python:3.12 のイメージを指定している場合、その中身は今回の変更で変わりません。gcloudのバージョンやサービスアカウントの設定も、今回の切り替えの対象ではありません。

影響が出やすい構成

ホスト側だけの変更なので、多くのビルドはそのまま動くと考えられます。ただし、ビルドステップがホストのDockerを直接操作する構成では注意が要ります。ここからは、公式ドキュメントに個別の記載がない、筆者の推測を含む整理です。

Dockerの公式リリースノートには、Docker Engine 29.0で次の変更が記載されています。

• デーモンが受け付けるAPIはバージョン1.44以降（Docker v25.0以降）になり、古いクライアントは拒否される
• 新規インストールでは、containerdのイメージストアが標準になる
• cgroup v1が非推奨になる（少なくとも2029年5月まではサポート継続）

1つ目は特に確認しておきたい点です。ビルドステップで古いDocker CLIのイメージ（例：docker:20.10）を固定し、ホストのDockerデーモンに接続してイメージをビルドしている場合、新環境では接続を拒否される可能性があります。また、Debian 11を前提にしたスクリプトをホスト側の挙動に依存させている場合も、見直しの対象になります。

一方で、ビルドステップが自分のコンテナの中で完結している場合は、影響は小さいと見込まれます。いずれにしても推測の域を出ないため、実際にテストビルドを1回流して確かめるのが確実です。

運用メモ Cloud RunやCloud Functionsのソースからのデプロイ（gcloud run deploy --source など）も内部でCloud Buildを使います。ただし、こうしたビルドが今回のチャンネル切り替えの対象になるのか、利用者がチャンネルを指定できるのかは、2026年10月6日時点の公式ドキュメントでは確認できませんでした。Firebase と App Engine についても同様に記載はありません。sGTMをCloud Runに載せている場合は、Cloud Buildの履歴に自分のプロジェクトのビルドが残っているかを先に見ておくと、影響範囲の当たりをつけられます。

事前テストの手順

切り替え日を待たずに、新しい環境を指定してビルドを試せます。指定する場所は3つあります。

regular のようなチャンネル名のほか、2026.09 のようにバージョンを直接指定することもできます。ビルド構成ファイルに書く場合は、次のようになります。

steps:
  - name: "gcr.io/cloud-builders/docker"
    args: ["build", "-t", "IMAGE_NAME", "."]
options:
  workerRelease: regular

テストの進め方としては、次の順序が現実的だと考えます。

1. Cloud Buildの履歴で、どのトリガーやビルドが動いているかを洗い出す
2. 影響の小さいビルドから --worker-release=regular を付けて手動で実行し、成功するか確認する
3. 問題がなければ、ビルド構成ファイルに workerRelease: regular を書き足して本番のトリガーに反映する

テストで失敗した場合は、workerRelease: legacy を明示すれば当面は旧環境のまま使えます。ただし legacy のサポートは2028年3月31日で終わるため、延命は修正までの時間を稼ぐ手段と考えるのが妥当です。

まとめ

まず試すべき1アクション： Cloud Buildの履歴を開き、直近で動いているビルドを1つ選んで --worker-release=regular を付けて再実行してください。成功すれば、そのビルドは切り替え後もそのまま動く見込みが高いと判断できます。

関連記事

• 【事例】サーバーサイドGTM導入で計測精度はどう変わったか｜Before/Afterの実データ
• GoogleがAIエージェント向けスキルを公式公開。Google広告APIやBigQueryの知識をClaude CodeやGemini CLIに追加できる
• サーバーサイドGTM（sGTM）導入ガイド｜仕組み・メリット・構築手順と広告計測への影響