Cloud Runで不要になったサービスを削除したのに、しばらくすると同じサービスが復活している。しかも、もう使っていないリージョンにまでCloud Runサービスが再作成される。
このような現象が起きた場合、Cloud Runそのものを何度削除しても根本的な解決にはならないことがあります。実際に私が遭遇したのが、このケースでした。
本番環境として使うCloud Runは「asia-northeast1」に移行済みでした。そのため、以前使っていた「asia-northeast2」のCloud Runサービスは不要になり、削除しました。ところが、GitHubのmainブランチへコードをpushするたびに、削除したはずのasia-northeast2側に同じCloud Runサービスが再び作成されてしまったのです。
原因はCloud Runではありませんでした。古いCloud Buildトリガーが残っており、GitHubのmainへのpushを検知するたびに、旧リージョンへ自動デプロイしていたことが原因でした。
Cloud Buildでは、GitHubなどのリポジトリでcommitのpushやpull requestなどのイベントが発生した際、それをトリガーとして自動的にビルドを開始できます。
この経験から得た重要な教訓があります。「何を消せばいいのか」を考える前に、「何がこれを作っているのか」を調べることです。
この記事では、Cloud Buildトリガーとは何かという基本から、GitHubへのpushからCloud Runへ自動デプロイされる流れ、Cloud Buildの「履歴」と「トリガー」の違い、意図しない自動デプロイを調査する方法まで、実際に起きたトラブルをもとに解説します。
Cloud Buildトリガーとは？
Cloud Buildトリガーとは、簡単に言えば、「特定の出来事が起きたらCloud Buildを自動的に実行するルール」です。
Cloud Build自体は、ソースコードをもとにビルドやテスト、コンテナイメージの作成、デプロイなどの処理を実行するGoogle Cloudのサービスです。ただし、Cloud Buildを毎回人間が手動で起動する必要はありません。そこで使われるのが「トリガー」です。
Google Cloud公式ドキュメントでは、Cloud Buildトリガーを使って、新しいcommitがリポジトリへpushされた場合や、pull requestが開始された場合などのイベントを監視し、新しいイベントが入ると自動的にビルドを呼び出せると説明されています。
GitHubなどのイベントをきっかけにビルドを自動実行する
たとえばGitHubとCloud Buildを接続し、対象リポジトリ、対象ブランチ、ビルドの実行条件、使用するビルド構成、実行用のサービスアカウントなどを設定しておけば、対象のブランチへ変更がpushされたことをきっかけとしてCloud Buildを実行できます。
ここで非常に重要なのは、「自分でデプロイ操作をしていなくても、トリガーが条件を満たせば処理が始まる」という点です。これを理解していないと、「Cloud Runを触っていないのに、なぜサービスが更新されたのだろう」「削除したはずなのに、なぜ復活したのだろう」という状況で、原因をCloud Run側だけで探し続けることになります。
手動デプロイと自動デプロイは違う
手動デプロイであれば、人間がコマンドを実行したり、Google Cloud Consoleから操作したりしたことがきっかけになります。一方、Cloud Buildトリガーを使った自動デプロイでは、人間が直接Cloud Runを操作しなくても構いません。
たとえば「GitHubへpushした」という行為がスタート地点になります。本人の意識としては「コードを保存した」「GitHubを更新した」だけでも、そのpushを監視しているCloud Buildトリガーがあれば、その後の処理が自動的に進みます。この「見えないところで次の処理へ進む」という性質が、自動化の便利さである一方、設定が増えたときのトラブル原因にもなります。
GitHubへのpushからCloud Run公開まで何が起きている？
今回のようなトラブルを理解するには、GitHubからCloud Runまでを別々のサービスとして見るのではなく、一本の流れとして理解することが重要です。
| 1 | GitHub mainへpush |
|---|---|
| 2 | Cloud Buildトリガーが検知 |
| 3 | Cloud Buildがビルド |
| 4 | Cloud Runへデプロイ |
| 5 | 新しいリビジョンを作成 |
| 6 | 設定されたトラフィックを反映 |
1．GitHubのmainへpushする
最初のきっかけは、開発したコードをGitHubのmainブランチへpushすることです。ここだけを見ると、単にGitHubのソースコードが新しい状態になっただけです。しかし、mainブランチを監視対象としたCloud Buildトリガーが設定されていれば、このpushが次の処理を開始させます。
2．Cloud Buildトリガーが変更を検知する
Cloud Buildトリガーは、設定されたリポジトリイベントを監視します。mainへのpushを条件にしていれば、「mainが更新された」という出来事がCloud Buildを起動するスイッチになります。
3．Cloud Buildがビルドを実行する
トリガーが発火すると、設定されたビルド構成に基づいてCloud Buildが処理を開始します。プロジェクトによって、ソースコードの取得、依存関係の準備、アプリケーションのビルド、コンテナイメージの作成、Artifact Registryへの格納、Cloud Runへのデプロイなどを自動化できます。
重要なのは、トリガーは「ビルドを開始する条件」であり、実際に何をするのかはビルド構成側にも依存するという点です。
4．Cloud Runへデプロイする
Cloud Buildの中にCloud Runへのデプロイ処理が含まれていれば、そのままCloud Runへ新しいアプリケーションをデプロイできます。ここでデプロイ先として古いリージョンや古いサービス名が残っていれば、人間は「もう使っていない」と思っていても旧環境へのデプロイが繰り返されます。
5．Cloud Runに新しいリビジョンが作成される
Cloud Runでは、サービスへデプロイした場合やサービスの構成を変更した場合に、不変の新しいリビジョンが作成されます。リビジョンは「その時点のCloud Runサービスの実行状態を表す版」と考えると分かりやすいでしょう。
6．新しいリビジョンへトラフィックが反映される
今回の環境では、新しいリビジョンへ100％のトラフィックを向ける構成でした。ただしCloud Runでは、必ず新しいリビジョンへ100％のトラフィックを割り当てる必要はありません。複数リビジョンに分割したり、段階的に移行したりできます。一般化すると「GitHubへのpush → Cloud Build → Cloud Runデプロイ → 新リビジョン作成 → 設定されたトラフィック配分」という流れです。
実体験｜削除したasia-northeast2のCloud Runが何度も復活した
ここからは、実際に起きたトラブルを説明します。この経験が、Cloud Buildトリガーを理解するきっかけになりました。
本番環境はasia-northeast1へ移行していた
もともとCloud Runのサービスを別リージョンで構築していましたが、その後、本番環境はasia-northeast1へ整理しました。そのため、古いasia-northeast2側のCloud Runサービスは不要な状態です。
不要なasia-northeast2のCloud Runサービスを削除した
そこで、不要になったasia-northeast2側のCloud Runサービスを削除しました。Cloud Runの画面から見ればサービスは消えます。この時点では「これで古い環境はなくなった」と考えます。ところが問題は解決していませんでした。
GitHubのmainへpushすると、削除したサービスが復活した
アプリケーションの修正を行い、GitHubのmainへpushしました。すると、削除したはずのasia-northeast2側に、再び同じCloud Runサービスが作られていました。もう一度削除しても、次のpushでまた復活します。
ここで重要なのは、Cloud Run自身が勝手に自分を復活させているわけではないという点です。何か別の仕組みが、Cloud Runサービスを作る処理を実行しています。
原因は旧リージョン用のCloud Buildトリガーだった
調査した結果、原因は古いCloud Buildトリガーでした。本番用として現在使っているトリガーとは別に、以前作った旧リージョン向けのCloud Buildトリガーが残っていました。しかも両方が同じGitHubリポジトリのmainブランチを監視していました。
- mainへpush → 現在のトリガーが起動 → asia-northeast1へデプロイ
- 同じmainへのpush → 古いトリガーも起動 → asia-northeast2へデプロイ
Cloud Runサービスを削除したとしても、旧トリガーは残っています。そのため、次回mainへpushすると、古いトリガーが再びCloud Buildを起動し、Cloud Runへのデプロイを実行します。結果として「削除したCloud Runサービスが勝手に復活した」ように見えていました。実際には、残っていた自動デプロイ経路によって新しく作り直されていたのです。
Cloud Runを消しても解決しなかった理由
Cloud Runは「結果」でCloud Buildトリガーが「原因」だった
問題が起きたとき、目の前に見えているものを直したくなります。Cloud Runサービスが不要であれば「Cloud Runサービスを削除する」という行動は自然です。しかし今回の場合、Cloud Runは問題の原因ではありませんでした。Cloud Runサービスが作られたことは結果です。
- GitHubへのpush＝きっかけ
- Cloud Buildトリガー＝自動実行を開始する条件
- Cloud Build＝処理を実行する仕組み
- Cloud Runサービス＝処理によって作られた結果
「何を消すか」ではなく「何が作っているか」を調べる
「削除してもまた作られる」「設定を戻してもまた変わる」「修正してもまた同じ状態になる」という問題では、対象そのものよりも上流を見る必要があります。
- Cloud Runの更新時刻を見る
- 誰がデプロイしたかを見る
- 同じ時刻にCloud Buildが動いていないかを見る
- Cloud Buildを起動したトリガーを見る
- そのトリガーがどのGitHubリポジトリ・ブランチを監視しているかを見る
Cloud Buildの「履歴」と「トリガー」は別物
Cloud Buildを使い始めたばかりのときに混同しやすいのが「履歴」と「トリガー」です。この2つは役割がまったく違います。
| 項目 | Cloud Buildの履歴 | Cloud Buildのトリガー |
|---|---|---|
| 役割 | 過去に実行されたビルドを確認する | ビルドを自動実行する条件を設定する |
| 分かること | 実行日時、結果、ログ、ビルド内容など | 対象リポジトリ、イベント、ブランチ、ビルド構成など |
| GitHub push後 | 実行されたビルドが履歴に残る | 条件に合えばビルドを起動する |
| 過去か未来か | 過去に起きたこと | 今後起こすことを決めるルール |
| トラブル時の役割 | 「何が起きたか」を調べる | 「なぜ起きたか」を調べる |
| 履歴を削除したら自動実行は止まるか | 原因となるトリガーが残っていれば止まらない | 不要なトリガーを無効化・削除して自動実行経路を止める |
履歴は「起きたこと」を見る場所
Cloud Buildの履歴を見ると、いつビルドが動いたのか、成功したのか失敗したのか、どのようなステップが実行されたのか、どのログが出ているのかなどを調査できます。
トリガーは「これから何を起こすか」を決める場所
一方でトリガーは、「このイベントが起きたら、このビルドを実行する」というルールです。mainへのpushを監視するトリガーが残っている限り、条件を満たすpushが発生すれば再び処理が開始されます。
履歴を消しても自動実行ルールは止まらない
仮に古いビルド履歴を整理したとしても、それによってトリガーそのものがなくなるわけではありません。たとえるなら「履歴＝防犯カメラの録画」「トリガー＝自動ドアのセンサー設定」のような関係です。録画を削除しても、センサーは次の人を検知します。
意図しない自動デプロイが起きたときの調査ポイント
1．誰がデプロイしたのかを見る
まず、Cloud Runの変更やデプロイに関する情報から「誰が実行したのか」を確認します。自分や開発担当者のGoogleアカウントであれば人間による操作の可能性があります。一方、人間のメールアドレスではなくサービスアカウントが表示されていた場合は、自動処理の可能性を疑う材料になります。
2．Default Compute SAなど人間以外なら自動処理を疑う
Cloud Buildでは、プロジェクトの設定などに応じてCompute EngineのデフォルトサービスアカウントやCloud Buildサービスアカウントなどがビルドの実行主体として利用される場合があります。また、ビルドトリガーごとに実行用サービスアカウントを設定できます。
人間ではないサービスアカウントが表示されたからといって、必ずCloud Buildが原因と断定してはいけません。あくまで自動処理を疑い、Cloud Buildやその他の実行経路を調査するきっかけとして使います。
3．リージョンを見る
今回の問題ではリージョンが重要な手掛かりになりました。現在使う本番環境はasia-northeast1なのに、asia-northeast2側に新しいサービスが作られている。この時点で「現在の本番デプロイ経路とは別の古い処理が残っているのではないか」と疑えます。
4．GitHub pushの時刻とCloud Build実行時刻を照合する
GitHubへpushした時刻、Cloud Buildの開始時刻、Cloud Runの新しいデプロイ時刻を比較します。時刻が連動しているなら、GitHub → Cloud Build → Cloud Runの自動デプロイ経路を疑いやすくなります。
Cloud Buildトリガーを棚卸しする7ステップ
ステップ1．Cloud Buildのトリガー画面を開く
Google Cloud ConsoleからCloud Buildのトリガー一覧を確認します。今回は「履歴」ではなく、どのルールが今後も自動実行される可能性があるかを見るため「トリガー」を確認します。
ステップ2．同じGitHubリポジトリを監視するトリガーが複数ないか調べる
同じリポジトリを監視しているトリガーが複数存在しないか確認します。複数あること自体は問題ではありませんが、存在を把握していないトリガーが同じリポジトリを監視している状態は危険です。
ステップ3．対象ブランチを確認する
今回のケースでは古いトリガーもmainを監視していました。本番用と検証用のトリガーを分けるなら、どのブランチがどの環境に対応しているのかを明確にします。
ステップ4．名前・説明・リージョン関連設定を確認する
トリガー名だけで判断せず、説明、ビルド構成、デプロイ先、リージョンなど実際の設定内容を確認します。
ステップ5．有効・無効の状態を確認する
「昔作ったから、もう動いていないだろう」という推測は危険です。有効な状態で対象イベントと条件が一致していれば、今でも実行される可能性があります。
ステップ6．不要なトリガーを削除または無効化する
不要だと判断できたトリガーは無効化または削除します。ただし、本番や検証環境で使われていないか、他の開発者が利用していないかを事前に確認してください。
ステップ7．原因を止めてから旧Cloud Runサービスを削除する
「不要なトリガーを止める → Cloud Runを削除する → 次回push後も復活しないか確認する」の順番にします。原因を止めてから結果を整理することが重要です。
トリガーを削除する前に確認すべきこと
現在の本番で使われているトリガーではないか
現在の本番環境へ正しくデプロイしているトリガーを特定します。「怪しいものを全部削除する」という方法は避けましょう。
別ブランチ・別環境で利用されていないか
main以外にdevelop、staging、feature系ブランチなどを利用している場合があります。検証用トリガーを不要なトリガーと勘違いしないようにします。
同じリポジトリを監視する別トリガーがないか
1つ削除して終わりではなく、同じリポジトリや同じブランチを対象にしているトリガーを一覧で確認します。
実際のデプロイ先リージョンを確認する
トリガー名だけでなく、ビルド構成側も確認します。「名前ではなく、実際の処理を見る」ことが重要です。
安全なCloud Buildトリガー構成とは？
本番環境はasia-northeast1向けトリガー1本を基本にする
今回のように本番環境をasia-northeast1へ統一するなら、mainから本番へデプロイする経路も可能な限り一本化します。GitHub main → 本番用Cloud Buildトリガー → 本番用ビルド → asia-northeast1のCloud Run、という一本の流れにしておくと、トラブル時にも原因を追いやすくなります。
検証環境は本番とは別トリガーにする
検証環境が必要であれば、本番とは目的を分けます。一例として「main → 本番」「develop → 検証」という形です。どのブランチがどの環境につながるのかをチーム内で理解できる状態にすることが重要です。
トリガー名に環境と目的が分かる情報を入れる
本番、検証、対象サービス、対象リージョンなど、見ただけで役割が推測できる名前や説明を付けます。数か月後の自分が見ても判断できる名前にすることが大切です。
使わなくなったトリガーを放置しない
Cloud Runのリージョンやサービス構成を変更した場合は、Cloud Runだけを移行して終わりにせず、Cloud Buildトリガー、ビルド構成、GitHubとの接続、サービスアカウント、デプロイ先、関連クラウドリソースまで確認します。環境移行は、自動化経路まで含めた移行と考えましょう。
AIに調査を依頼するときも「削除」ではなく「原因」を聞く
「このCloud Runを削除して」だけでは再発する可能性がある
AIに「このCloud Runサービスは不要なので削除して」と依頼し、指示どおり削除できたとしても、そのサービスを再作成するCloud Buildトリガーが残っていれば問題は再発します。AIの処理が間違っているというより、こちらが「削除」という結果だけを依頼していることが問題です。
「再作成しているトリガーがないか調べて」と聞く
AIへの質問例
このCloud Runサービスを削除しても、GitHubのmainへpushすると再作成されます。Cloud Runをもう一度削除する前に、GitHubへのpush、Cloud Buildの履歴、Cloud Buildトリガー、デプロイ先リージョンを調べ、このサービスを再作成している自動処理がないか確認してください。
同じGitHubリポジトリのmainを監視しているトリガーが複数ないかも調べてください。
AIには結果ではなく因果関係を調査させる
AI活用で重要なのは、「作業をやらせる」だけではなく「原因を調べさせる」という使い方です。「これを消して」ではなく「なぜこれが作られたのか」、「エラーを直して」だけではなく「何が原因でこのエラーが起きているか、再発条件まで調べて」と聞く。依頼する人間側が因果関係を意識することで、単なる対症療法から根本解決へ進みやすくなります。
Cloud Buildトリガーで起きやすい5つの失敗
1．古いリージョン用トリガーを残したまま移行する
Cloud Runサービスを新しいリージョンへ移しても、古いトリガーやビルド構成が残っていると、旧環境へのデプロイが続く可能性があります。
2．同じmainを複数のトリガーで監視する
把握していない複数トリガーが同じmainを監視していると、1回のpushから複数のデプロイが走る可能性があります。
3．トリガー名だけで判断する
対象リポジトリ、ブランチ、ビルド構成、デプロイ先まで確認します。
4．Cloud Runだけを削除する
自動デプロイ経路が残っている場合、Cloud Runは結果にすぎません。繰り返し再作成されるなら作成元を調べます。
5．Cloud Buildの履歴を消せば止まると思う
履歴は実行されたビルドの記録、トリガーは次回のイベントを監視するルールです。「過去の記録」と「未来の自動実行条件」を混同しないことが重要です。
Cloud Run・Cloud Buildでトラブルが起きたときの考え方
Cloud Runを使っていると、似たように見えるトラブルでも原因がまったく違うことがあります。問題ごとに調査する場所を分けて考えると整理しやすくなります。
| 起きている問題 | 最初に疑う場所 |
|---|---|
| コードを修正したのに本番が変わらない | GitHub・Cloud Build・Cloud Runリビジョン |
| 削除したCloud Runが復活する | Cloud Buildトリガー・自動デプロイ経路 |
| Cloud Run内に保存したデータが消える | ローカル保存・永続DB |
| APIキーやパスワードを安全に管理したい | Secret Manager |
| 古いコードが動いているように見える | GitHubのcommit・ビルド・リビジョン |
同じ「Cloud Runがおかしい」という現象でも、見るべき場所は異なります。大切なのは、症状から原因を決めつけないことです。
よくある質問
Cloud Buildトリガーを削除するとCloud Runも削除されますか？
Cloud Buildトリガーと既存のCloud Runサービスは別のリソースです。トリガーを削除することは、今後そのトリガーから自動ビルドが起動する経路をなくすことであり、既存のCloud Runサービスを削除する操作そのものではありません。今回のようなケースでは、不要なトリガーを止めたあとで、不要なCloud Runサービスを別途削除します。
Cloud Buildの履歴を削除すれば自動デプロイは止まりますか？
履歴とトリガーは別物です。Cloud Buildの履歴は過去に実行されたビルドを確認するための情報です。一方、トリガーはpushなどのイベントを監視してビルドを自動的に起動するルールです。自動デプロイを止めたい場合は、原因となっているトリガーやその他の自動実行経路を確認してください。
同じGitHubリポジトリに複数のCloud Buildトリガーを作れますか？
異なるイベントやブランチなどを条件とした複数のトリガーを構成できます。複数あること自体が問題なのではなく、それぞれの役割を把握できているかが重要です。
デプロイ者がDefault Compute Service AccountならCloud Buildが原因ですか？
それだけでは断定できません。人間ではないサービスアカウントが表示されていれば、自動処理を疑う有力な手掛かりにはなりますが、Cloud Buildの履歴やトリガーなども合わせて確認してください。
Cloud Runのリビジョンを削除すれば問題は解決しますか？
原因によります。自動デプロイが原因なら、リビジョンを削除しても次回のデプロイで再び新しいリビジョンが作成される可能性があります。先に「誰が、何をきっかけに、どこへデプロイしているのか」を調査することが重要です。
まとめ｜消す前に「何が作っているのか」を調べよう
Cloud Buildトリガーとは、GitHubへのpushなどのイベントをきっかけとして、Cloud Buildのビルドを自動的に開始する仕組みです。自動化は非常に便利ですが、古いトリガーが残っていると、その便利な自動化が意図しないデプロイを繰り返す原因にもなります。
今回の実体験では、本番をasia-northeast1へ移行していたにもかかわらず、旧asia-northeast2向けのCloud Buildトリガーが残っていました。そのため「Cloud Runを削除 → GitHub mainへpush → 古いトリガーが起動 → asia-northeast2へ再デプロイ → Cloud Runサービスが再作成」ということが繰り返されました。
この経験から最も重要だと感じたのは、「何を消せばいいのか」より先に、「何がこれを作っているのか」を調べるという考え方です。同じ問題が繰り返されるときは、目の前にある結果だけを修正し続けず、原因を上流へたどります。
AIへ調査を頼む場合も、「このCloud Runを削除して」だけではなく、「このCloud Runを再作成しているトリガーや自動処理がないか調べて」と聞いてみてください。AIに作業だけを頼むのではなく、因果関係を調査させることが、AIとクラウドサービスを組み合わせて開発・運用するときに重要です。
AI・業務アプリ活用について相談する
AIを使えば、非エンジニアでも業務アプリを形にできる時代になりました。一方、本番公開後はGitHub、Cloud Build、Cloud Run、データベース、認証、秘密情報など複数の仕組みが連動します。
「アプリは作れたけれど、本番環境をどう整理すればいいか分からない」「AIへ修正を頼みながら開発しているが、安全な運用方法に不安がある」という場合は、まず現在の開発・運用フローを整理するところから始めてみてください。
参考情報（Google Cloud公式）
- ビルドの自動化 / Cloud Build トリガー：https://docs.cloud.google.com/build/docs/automate-builds?hl=ja
- GitHub リポジトリからのビルド：https://docs.cloud.google.com/build/docs/automating-builds/github/build-repos-from-github?hl=ja
- Cloud Run へのデプロイ：https://docs.cloud.google.com/run/docs/deploying
- Cloud Run リビジョンの管理：https://docs.cloud.google.com/run/docs/managing/revisions
- Cloud Build サービスアカウント：https://docs.cloud.google.com/build/docs/cloud-build-service-account?hl=ja