AIを使ってアプリ開発を始めた当初、私はGitHubにコードを保存することと、Cloud Runでアプリが動くことの関係をよく理解していませんでした。

感覚としては、「GitHubへ最新のコードを入れれば、Cloud Runも勝手に最新になる」くらいの理解でした。

しかし、実際にはGitHubが直接Cloud Runを書き換えているわけではありません。その間にはCloud Buildがあります。

私が実際の業務アプリ開発を通じて理解したデプロイの流れは、次のとおりです。

この仕組みを理解してから、トラブルが起きたときの見方が大きく変わりました。

以前であればAIに「本番に反映されません。直してください」と聞いていました。今は「mainの最新SHAは何ですか」「その変更に対応するCloud Buildは成功していますか」「Cloud Runの最新Revisionはいつ作成されましたか」「そのRevisionにtrafficは向いていますか」と、問題を分解して確認できるようになっています。

この記事では、GitHubからCloud Runへコードが反映されるまでの「道のり」に絞り、非エンジニアでも分かるように解説します。

結論｜GitHubからCloud RunへはCloud Buildを通ってデプロイされる

最初に最も重要なことを押さえておきましょう。GitHubがCloud Runを直接更新するわけではありません。今回紹介する構成では、GitHubとCloud Runの間にCloud Buildが存在します。

ここを理解すると、「GitHubへpushしたのに本番が変わらない」という問題も、どこで止まっているかを順番に確認できるようになります。

まず理解したいGitHub・Cloud Build・Cloud Runの役割

GitHub、Cloud Build、Cloud Runは、それぞれまったく違う役割を持っています。初心者のうちは、この3つをまとめて「アプリを動かすもの」と考えてしまいがちです。それぞれを分けて理解してみましょう。

GitHubは「本番を動かす場所」ではなくコードを管理する場所

GitHubは、アプリのソースコードを保存し、変更履歴を残す場所です。たとえば、昨日のコードから今日、ログイン機能を修正した、PDF出力を修正した、メール機能を追加した、といった変更をcommitとして記録できます。

GitHubは単なる「ファイル置き場」ではなく、どの変更を、いつ、誰が行ったかをcommit単位で残す正式なソース履歴として考えると分かりやすくなります。

また、それぞれのcommitにはSHAと呼ばれる識別情報があります。SHAは、簡単に言えば「この時点のコードはこれです」と特定するための番号です。本番トラブルを調べる際、このSHAが非常に重要になります。

GitHubのmainに最新SHAがあることを確認できれば、少なくとも「最新コードはGitHubまでは届いている」と判断できます。逆に、開発環境では直っているのにmainが古ければ、Cloud BuildやCloud Runをいくら確認しても本番は新しくなりません。

Cloud Build Triggerはpushを検知するスイッチ

Triggerとは日本語で「引き金」という意味です。ここでは「何かが起きたら、自動処理を始める条件」くらいに理解すると分かりやすいでしょう。

たとえば、「GitHubのmainへ新しいcommitがpushされたらCloud Buildを開始する」というルールを設定できます。つまり、GitHubに変更があることを見張っているスイッチのような役割です。

重要なのは、TriggerとCloud Build本体は別物ということです。Triggerはあくまで「いつ始めるか」を決めます。実際にコードを処理するのはCloud Buildです。

Cloud Buildはコードを本番で使える形にする

Cloud Buildは、GitHubから受け取ったコードを使い、アプリを本番で動かせる形へ処理します。

初心者向けに例えるなら、GitHubにあるソースコードが「料理の材料とレシピ」だとすると、Cloud Buildは「調理工程」です。材料が冷蔵庫に入っているだけでは料理として提供できません。必要な材料を集め、決められた手順で調理し、提供できる状態にします。

Cloud Buildも同じように、ソースコードをもとにビルド処理を行います。今回のようなCloud Runへのデプロイ構成では、最終的にアプリを動かすためのコンテナイメージを作り、Cloud Runへのデプロイへつなげます。

Cloud Runは完成したコンテナを動かす場所

ここで重要なのは、Cloud RunはGitHub上のコードそのものを直接実行しているわけではないという点です。

Cloud Runは、ビルドされたコンテナをサービスとして稼働させる場所です。つまり、GitHubにあるソースコードと、Cloud Runで実際に稼働するアプリの間には、コードを実行可能な形へ変換する工程が必要なのです。

GitHubへpushしてから本番に反映されるまでの7ステップ

ここからは、実際の流れを7段階に分けて見ていきます。一度この順番を理解しておくと、トラブル時にも非常に役立ちます。

STEP1｜GitHubのmainへコードをpushする

最初はGitHubです。開発環境でコードを修正しただけでは、本番デプロイは始まりません。変更内容をcommitし、mainなど自動デプロイ対象として設定されているブランチへpushします。

ここで押さえたい用語は3つです。

commit：変更を一つの単位として記録すること。

push：ローカルや開発環境のcommitをGitHubへ送ること。

SHA：commitを一意に識別する番号。

STEP2｜Cloud Build Triggerがpushを検知する

mainへpushされると、それをCloud Build Triggerが検知します。ただし、これは事前にトリガーが設定されている場合です。GitHubへコードを置くだけで、すべてのCloud Runサービスが自動更新されるわけではありません。

どのリポジトリ、どのブランチ、どのイベントを対象としてビルドを実行するか、トリガー側で決めます。

• 対象ブランチが違う
• 対象リポジトリが違う
• Triggerが無効
• Trigger設定自体が違う

STEP3｜Cloud Buildがビルドを開始する

Triggerが条件を満たすとCloud Buildが動きます。ここからが実際のビルド工程です。Cloud Buildは設定に基づき、ソースコードを取得し、必要な処理を実行します。

ここで失敗すれば、その先のCloud Runまで届きません。つまり、GitHub mainが最新であることと、Cloud Run本番が最新であることの間には、Cloud Build成功という重要な条件があります。

STEP4｜コンテナイメージが作られる

Cloud Runでアプリを動かすには、コンテナという仕組みを理解しておくと流れがつかみやすくなります。初心者であれば、コンテナ＝アプリを動かすために必要なものをまとめた実行環境、くらいの理解で十分です。

そして、コンテナイメージ＝そのコンテナを作るための完成パッケージ、と考えてください。Cloud Runは、その完成したコンテナを実行します。

STEP5｜Cloud Runへデプロイされる

ビルドが正常に完了すると、Cloud Runへ新しいアプリがデプロイされます。デプロイとは、作ったアプリを実際に動く環境へ配置することです。

「ビルド成功」と「デプロイ成功」は考え方として分けておくと便利です。コードからコンテナを作る工程まで成功していても、その後Cloud Runへ配置する段階で問題が起きる可能性があります。

STEP6｜Cloud Runで新しいRevisionが作られる

Cloud Runへ新しい内容をデプロイすると、新しいRevisionが作られます。Revisionは、Cloud Run上に保存される「その時点のアプリのバージョン」と考えると理解しやすいでしょう。

昨日のRevision、今日のRevision、修正前のRevision、修正後のRevisionというように複数残ることで、問題があった場合に以前の状態へ戻すこともできます。

STEP7｜新Revisionへtrafficが向き本番が変わる

ここが意外と重要です。新しいRevisionが作られた＝必ずそのRevisionがユーザーに表示されている、とは限りません。

trafficとは、利用者から来たアクセスを、どのRevisionへ何％送るかという設定です。新Revision：100％、旧Revision：0％であれば、すべての利用者が新バージョンを利用します。逆に、新Revision：0％、旧Revision：100％であれば、新Revisionが存在していても本番利用者には見えません。

そのため本番反映を確認するときは、新しいRevisionがあるかだけでなく、そのRevisionにtrafficが向いているかまで確認します。

初心者が混同しやすい6つの用語

ここまで出てきた重要用語を一度整理しておきましょう。

特に混同しやすいのが、Cloud Build TriggerとCloud Buildです。Triggerは「mainにpushされたら開始する」という開始条件、Cloud Buildは「実際にコードを処理してビルドする」実行処理です。

また、Revisionとtrafficもセットで理解してください。Revisionはバージョンそのもの。trafficは、そのバージョンへ利用者を送る割合です。

「mainが最新＝本番も最新」ではない

私自身、ここを理解するまでかなり混乱しました。GitHubのmainを確認して最新コードが入っていると、「なら本番も同じコードのはず」と思ってしまいます。しかし、実際にはそうとは限りません。

最重要の考え方は、「コードを直した」ことと「本番が直った」ことは別だという点です。なぜなら、mainと本番の間には複数の段階が存在するからです。

Cloud Buildが失敗しているケース

GitHub mainが最新でも、Cloud Buildが失敗していればCloud Runは古いままです。この場合、GitHubだけを何度確認しても問題は分かりません。Cloud Buildの履歴を確認し、ビルドが成功したのか、失敗したのかを見る必要があります。

別リージョンへデプロイしているケース

さらに分かりにくいのがリージョン違いです。実際の開発では、古いCloud Build Triggerが残っていたことにより、mainへpushするたびに意図していない別リージョンのCloud Runサービスが再作成される問題を経験しました。

つまり、「Cloud Runへデプロイされた」だけでは不十分です。どのプロジェクトの、どのサービスの、どのリージョンへデプロイされたかまで確認する必要があります。

古いRevisionへtrafficが向いているケース

Cloud Buildも成功し、Cloud Runにも新Revisionがある。それなのに本番が古い。その場合はtrafficも確認します。新Revisionが作成されていても、旧Revisionがユーザー向けに使われている状態は仕組み上あり得ます。

本番反映を確認するときはGitHub→Cloud Build→Cloud Runの順に見る

トラブルが起きたとき、私は現在、GitHub → Cloud Build → Cloud Run → 本番URLの順番で確認しています。下流から手当たり次第に確認するより、上流から追う方が整理しやすいからです。

① GitHubでmainの最新SHAを確認する

最初に見るのはGitHubです。ここで「そもそもGitHubへ変更が入っていない」と分かれば、Cloud BuildやCloud Runを調査する必要はありません。

• mainに意図した変更があるか
• 最新commitはいつか
• SHAは何か
• 変更したファイルが含まれているか

② Cloud Buildでビルド結果を確認する

次にCloud Buildを確認します。GitHubまでは成功していても、ここで止まっている可能性があります。

• push後にビルドが開始されたか
• 成功したか
• 失敗したか
• 実行時刻は合っているか
• 想定しているトリガーから起動したか

③ Cloud Runで最新Revisionを確認する

Cloud Buildが成功していたら、Cloud Runへ進みます。たとえばGitHubへ18時にpushしたのに、Cloud Runの最新Revision作成時刻が昨日のままなら、反映経路の途中で止まっている可能性があります。

• サービス名
• リージョン
• 最新Revision
• Revision作成時刻
• デプロイ時刻

④ trafficが最新Revisionへ向いているか確認する

最新版が存在していることと、その最新版が利用されていることは別です。Revisionだけでなくtrafficも確認します。

• 最新Revisionに100％向いているか
• 意図せず分割されていないか

⑤ 最後は本番URLを実際に操作する

技術的な「デプロイ成功」と、利用者視点の「修正完了」は分けて考えます。最後は人間が本番URLを操作して確認します。

• 管理者ログイン
• データ保存
• PDF生成
• CSV出力
• メール送信

仕組みが分かるとAIへの質問の仕方が変わる

今回、私が最も大きな学びだと感じたのは、GitHubやCloud Runの操作方法そのものではありません。問題を分解できるようになったことです。

AI開発を始めたころは、問題が起きると「本番に反映されません。直してください」とAIへ伝えていました。しかし、この質問では問題の範囲が広すぎます。

• 開発環境
• GitHub
• Trigger
• Cloud Build
• Cloud Run
• traffic

「mainの最新SHAは何ですか」と聞く

まずGitHubを固定します。「mainの最新SHAは何ですか」と確認すれば、どのコードを基準として話しているのかが明確になります。「最新コード」という曖昧な表現ではなく、「このcommit」と指定できるようになります。

「その変更のCloud Buildは成功していますか」と聞く

次にCloud Buildです。GitHubの変更が確定したら、「このpush後のCloud Buildは成功していますか」と確認します。これで、GitHubまでは成功、Cloud Buildで失敗、という切り分けができます。

「Cloud Runの最新Revisionはいつ作成されましたか」と聞く

Cloud Buildが成功しているのであれば、次はCloud Runです。「最新Revisionはいつ作成されましたか」と確認します。さらに、「そのRevisionにtrafficは何％向いていますか」と確認すれば、本番への公開状況も判断できます。

AIを使える人はすべての技術を暗記している人ではない

私は、AIを使えるようになるとは、すべてのプログラミング技術を覚えることでも、Google Cloudのすべての設定画面を暗記することでもないと考えています。

重要なのは、問題を小さく分解して、どこを確認すればよいか分かることです。AIに詳しくなるというより、AIと一緒に問題を切り分けられるようになることが、非エンジニアのAI開発では非常に重要だと感じています。

GitHubからCloud Runへの自動デプロイで注意したいこと

Triggerを増やしすぎない

Cloud Build Triggerが複数あると、一つのpushで複数のビルドやデプロイが動く可能性があります。実際の開発でも、古いリージョン向けトリガーが残っていたことで、削除したCloud Runサービスが再び作成される問題が起きました。

本番運用では、「どのリポジトリの、どのブランチを、どのTriggerが監視し、どこへデプロイするのか」を整理しておきましょう。

本番環境と検証環境を混同しない

検証用と本番用のサービスを持つ場合は、サービス名、リージョン、Triggerを明確に分けた方が安全です。「どちらにデプロイしたのか分からない」状態になると、原因調査が急に難しくなります。

秘密情報をGitHubへ入れない

APIキー、SMTPパスワード、秘密鍵などの情報は、GitHubへそのまま保存するべきではありません。コードと秘密情報は分けて管理しましょう。

デプロイ成功だけで本番確認を終えない

Cloud Buildが成功し、Cloud Runにも新Revisionがあり、trafficも100％。ここまで確認できても、最後に実機確認を行います。特にログイン、保存、メール、PDF、外部サービス連携などは、実際に操作して初めて分かる問題があります。

GitHub・Cloud Build・Cloud Runの関係を一枚で整理

GitHub：保存する場所。最新のソースコードと変更履歴を管理します。

Cloud Build Trigger：変更を見つける仕組み。GitHubへのpushを検知します。

Cloud Build：作る仕組み。コードから実行可能なアプリをビルドします。

Cloud Run：動かす場所。ビルドされたコンテナをRevisionとして稼働させます。

traffic：どの版を利用者へ見せるか決める仕組み。

本番URL：利用者が実際に触る場所。

この流れが理解できれば、「GitHubへpushしたのになぜ本番が変わらないのか」という疑問も、漠然としたトラブルではなくなります。

よくある質問

GitHubへpushすれば必ずCloud Runへ反映されますか？

いいえ。GitHubへpushしただけで、自動的にすべてのCloud Runサービスへ反映されるわけではありません。Cloud Build Triggerなど、リポジトリ更新をきっかけにビルド・デプロイを行う設定が必要です。

GitHubがCloud Runを直接更新しているのですか？

本記事で紹介している構成では、直接ではありません。GitHubへのpushをCloud Build Triggerが検知し、Cloud Buildがビルドとデプロイを行い、Cloud Runへ新しいRevisionが作られます。

Cloud Build TriggerとCloud Buildは何が違いますか？

Cloud Build Triggerは「いつCloud Buildを開始するか」を決めるルールです。Cloud Buildは「実際にコードをビルドする処理」です。

Cloud RunのRevisionとは何ですか？

Revisionは、Cloud Runサービスの特定時点のバージョンです。新しい設定やコードをデプロイすると、新しいRevisionが作成されます。

新しいRevisionに問題があったら元へ戻せますか？

はい。Cloud Runではtrafficを以前のRevisionへ移すことでロールバックできます。ただし、本番環境で変更する際は、対象サービスやRevisionを十分確認したうえで操作してください。

まとめ｜デプロイ経路を理解すれば本番トラブルを分解できる

GitHubからCloud Runへの自動デプロイは、GitHubからCloud Runへコードが瞬間移動しているわけではありません。

本記事で紹介した構成では、GitHub mainへpush → Cloud Build Trigger → Cloud Build → コンテナイメージ → Cloud Run → 新Revision → traffic → 本番URL、という順番で進みます。

そして、最も大切なのは、mainが最新だからといって、本番も最新とは限らないということです。

1. GitHubのmainとSHAを確認する
2. Cloud Buildが成功したか確認する
3. Cloud Runに新Revisionがあるか確認する
4. 最新Revisionへのtrafficを確認する
5. 本番URLで実際に動作確認する

この考え方を身につけると、AIへの質問も変わります。「本番に反映されません」ではなく、「mainの最新SHAは何ですか」「その変更のCloud Buildは成功していますか」「Cloud Runの最新Revisionはいつ作成されましたか」と聞けるようになります。

AIを使った開発で必要なのは、すべての技術を暗記することではありません。問題を分解し、どこまで正常で、どこから異常なのかを確認できること。これが、AIと一緒にアプリ開発を進めるうえで非常に大切な力だと、実際の開発を通じて感じています。

参考資料

• ベストプランナー合同会社「GitHub 実践手順書」2026年8月実践整理版
• ベストプランナー合同会社「Cloud Run と Cloud Build トリガーの関係」2026年8月実践整理版
• ベストプランナー合同会社「Cloud Run 実践手順書」2026年8月実践整理版
• ベストプランナー合同会社「AI・クラウドシステム構築 実践ハンドブック」2026年8月実践整理版
• Google Cloud 公式ドキュメント（Cloud Build / Cloud Run）