「AIにコードを修正してもらったのに、本番画面が変わらない」

「GitHubにはpushしたはずなのに、Cloud Runで公開しているアプリが以前の状態のまま」

「AIから『修正完了しました』『正常に動作しております』と報告されたが、本当に本番まで反映されたのか分からない」

AIを使いながらアプリ開発をしていると、このような問題に遭遇することがあります。私自身、非エンジニアとしてAIと会話しながら業務アプリを作っていく中で、強く感じたことがあります。

この記事の核心
「コードの修正完了」と「本番環境の修正完了」は、まったく同じではありません。

開発環境でコードを書き換えただけでは、ユーザーがアクセスするCloud Runの本番環境は変わりません。

一般的な自動デプロイ構成では、開発したコードがGitHubへpushされ、その変更をCloud BuildのTriggerが検知し、Build処理を実行し、その結果がCloud Runへデプロイされ、新しいRevisionが作成されます。さらに、本番アクセスがその新しいRevisionへ向いている必要があります。

つまり、開発環境 → GitHub → Cloud Build → Cloud Run → 本番URLという一連の流れのどこか一つでも止まれば、「修正したのに本番へ反映されない」という状態になります。

この記事では、Cloud Runに修正が反映されないときに、非エンジニアでも原因を切り分けられるよう、確認する場所を5段階に分けて解説します。

Cloud Runに修正が反映されないときは5段階で切り分ける

Cloud Runの本番環境が変わらないとき、いきなりCloud Runの設定を触るのはおすすめしません。なぜなら、原因がCloud Runとは限らないからです。

たとえば、AIが開発環境のファイルを書き換えただけで、GitHubへのpush自体を行っていない可能性があります。逆にGitHubには正しくpushされていても、Cloud BuildのTriggerが違うブランチを監視しているかもしれません。Cloud Buildまでは正常でも、Cloud Runに新しいRevisionが作られていない可能性もあります。さらに、新Revision自体は存在しているのに、本番トラフィックが古いRevisionへ向いているケースも考えられます。

そのため、1．AI Studio・開発環境、2．GitHub、3．Cloud Build、4．Cloud Run、5．本番URLの順番で一つずつ確認します。重要なのは、勘で原因を探さないことです。各段階で「正常である証拠」を確認し、証拠が途切れた場所を探します。

5段階の確認ポイント早見表

この表の上から順番に確認するだけでも、原因特定の精度は大きく変わります。

確認1｜AI Studio・開発環境で本当に修正されているか

最初に確認するのは、Google AI Studio、ローカル開発環境、Claude Codeなど、実際にコードを編集した場所です。「AIが修正しましたと言ったから大丈夫」と考えず、実際の変更を確認します。

何を見るか

確認するのは、修正対象のファイルが変更されているか、指示した内容のコードが実際に入っているか、開発環境で対象機能が動作するか、の3点です。

たとえば「PDF出力ボタンを押した際のエラーを直してください」と依頼したのであれば、PDF生成に関係するファイルが本当に変更されているかを確認します。画面デザインの修正であれば、対象となるコンポーネントやCSSなどが変更されている必要があります。

正常の証拠

正常と判断するには、「AIが修正したと言った」ではなく、「変更されたコードが実際に存在する」ことが重要です。可能であれば開発環境でも、ログインする、フォームへ入力する、保存する、PDFを出力する、メールを送信する、といった操作を実際に行います。

ここで正常に動かなければ、GitHubやCloud Runを見る前に開発段階の問題を解決する必要があります。

AIには変更ファイルも聞く

AIに修正を依頼した場合は、「どのファイルを変更しましたか？」と確認すると原因を追いやすくなります。さらに、「どの部分を変更したのか簡潔に説明してください」と聞いておくと、次のGitHub確認と照合できます。

確認2｜GitHubに修正コードがpushされているか

開発環境で修正できていたら、次にGitHubを確認します。ここが非常に重要です。AIがローカル環境だけを書き換え、commitしていない、pushしていないという状態は十分に起こり得ます。この状態では、当然ながらCloud Buildは新しい変更を受け取れません。

GitHubのcommitとは何か

GitHub初心者の場合、まずcommitを「保存時点」と考えると分かりやすいでしょう。GitHub公式ドキュメントでは、commitは1つまたは複数ファイルの変更を記録するもので、それぞれのcommitにはSHAまたはhashと呼ばれる一意のIDが割り当てられます。SHAによって、どの変更・いつの変更なのかを識別できます。

SHAのイメージ
a8f32c7… のような文字列です。全文を覚える必要はありません。実務では短縮SHAで識別することもあります。

GitHubで見るべき3つの証拠

1．コミットSHA
最も重要です。SHAが分かれば、「どの時点のコードについて話しているのか」を揃えられます。AIへ「今回の修正をpushしたコミットSHAを教えてください」と聞いてもよいでしょう。

2．コミットメッセージ
「PDF生成エラーを修正」「メール送信処理を修正」「管理画面の表示不具合を修正」など、commitが今回の変更を表す内容かを確認します。

3．変更ファイル一覧
さらに重要なのが変更ファイルです。たとえばPDF出力を修正したと言っているのに、変更ファイルがREADMEだけなら違和感があります。commitに含まれる変更ファイルと差分を見れば、AIが実際に何を変更したかを確認できます。

「AIがローカルだけ直していた」を見つける方法

AIが「修正が完了しました。PDF出力も正常になりました」と報告していても、GitHubの最新commitが昨日のままなら、Cloud Runの問題ではありません。そもそも修正版がGitHubまで届いていない可能性があります。

切り分け
開発環境：新しい ／ GitHub：古い → commit・pushの段階を確認します。

この場合は、「修正した内容をcommitしてmainへpushしてください。完了後、SHAと変更ファイル一覧を報告してください」と依頼します。

「pushしましたか？」だけでは確認が弱い

AIへ単純に「GitHubへpushしましたか？」と聞くだけでは十分ではありません。対象branch、commit SHA、commit message、変更ファイル一覧まで答えてもらい、実際のGitHub画面と照合できる状態にします。

確認3｜Cloud BuildがGitHubのpushを検知しているか

GitHubまで正しい場合、次はCloud Buildです。ここで理解しておきたいのは、GitHubがCloud Runを直接更新しているわけではないという点です。

Google Cloudの一般的な自動ビルド構成では、Cloud Build Triggerがリポジトリイベントを監視します。たとえばmainブランチへ新しいcommitがpushされたら、そのイベントを受け取ってBuildを開始します。

デプロイの流れ
GitHubへpush → Cloud Build Triggerが検知 → Cloud BuildがBuildを実行 → コンテナイメージを作成 → Cloud Runへデプロイ → 新しいRevision

Cloud Buildでは「履歴」と「トリガー」を分けて考える

Cloud Build初心者が混乱しやすいポイントが、History（履歴）とTrigger（トリガー）の違いです。似たようなCloud Buildの画面にありますが、役割はまったく違います。

Historyは「すでに実行されたBuildの結果を見る場所」です。履歴では、いつBuildされたか、成功したか、失敗したか、どのソースからBuildされたか、Buildログに何が出ているかを確認します。一方でTriggerは「何が起きたらBuildを開始するかというルール」です。たとえば「GitHubの○○リポジトリのmainブランチへpushされたらBuildする」という設定です。

特に重要なのは、過去の履歴・ログと、自動実行ルールそのものを混同しないことです。自動デプロイを止めたい場合はTrigger側を確認する必要があります。

Cloud Buildの履歴で何を見るか

1．GitHubのpush後に新しいBuildがあるか
まず日時を見ます。GitHubへ21時10分にpushしたのに、Cloud Buildの最新履歴が20時30分なら、Triggerが動いていない可能性があります。

2．Buildが成功しているか
失敗している場合は、Cloud Runを見る前にBuildログを確認します。コンテナBuild失敗、依存関係のエラー、権限エラー、デプロイコマンド失敗、Artifact Registry関連エラーなどが考えられます。

3．今回のcommitからBuildされているか
GitHub側で確認したSHAと、Cloud Build側で扱われたソースを照合します。ここが一致すれば、GitHub → Cloud Buildまではつながっていると判断しやすくなります。

Cloud BuildのTriggerでは何を見るか

まず、接続しているGitHubリポジトリです。そもそも別のリポジトリを監視していないか確認します。似た名前のリポジトリを複数作っている場合は特に注意が必要です。

次に対象ブランチです。mainにpushしたのに、Triggerがmasterやdevelopを監視していたら動きません。あわせて、branchへのpushなのかPull Requestなのかといったイベント種別も確認します。

さらにBuild設定も重要です。どのcloudbuild.yamlなどを使っているかを確認します。間違った設定ファイルを使用していると、Build自体は成功していても別のサービスをデプロイしている可能性があります。

古いTriggerが残っていると削除したサービスが復活することもある

AI開発を試行錯誤していると、サービスを作り直す、リージョンを変更する、別名のサービスを作る、古いCloud Runサービスを削除するといったことがあります。このとき注意したいのが古いTriggerです。

以前のBuild設定が「mainへpushされたら、旧リージョンのsample-appへデプロイする」内容のまま残っていれば、後から同じ処理が再実行され、意図していないサービスが再作成される可能性があります。

考え方
「Cloud Runが勝手に復活した」ではなく、「残っていた自動デプロイ設定が再び作成した」と考えると切り分けしやすくなります。

不要になったデプロイ経路は、TriggerだけでなくBuild設定やデプロイ先まで含めて棚卸しすることが重要です。

確認4｜Cloud Runに新しいRevisionが作成されているか

Cloud Buildまで成功していたら、次はCloud Runです。ここで重要になる言葉がRevision（リビジョン）です。非エンジニア向けに簡単に言えば、「その時点で実行されるアプリのバージョン」と考えると分かりやすいでしょう。

Cloud RunではサービスへデプロイするとRevisionが作成されます。Revisionは作成後に書き換えるものではなく、変更がある場合は新しいRevisionが作成されます。コンテナイメージだけでなく、環境変数などの設定変更でも新Revisionが作成されます。

Revisionのイメージ
app-00001 → app-00002 → app-00003 のように世代が増えるイメージです。実際の名前はサービス設定によって異なります。

最新Revisionが作られているかを見る

GitHubへpushし、Cloud Buildが成功した時刻より後に新しいRevisionが作成されているか確認してください。GitHub pushが20時40分、Cloud Build成功が20時43分なのに、最新Revisionが昨日のままなら、Cloud Build → Cloud Runのどこかで処理が止まっている可能性があります。

新しいRevisionがあるだけでは安心できない

Cloud Runでは複数Revisionの間でトラフィックを分けることができます。たとえば旧Revision 90％、新Revision 10％という運用も可能です。あるいは旧Revision 100％、新Revision 0％という状態も作れます。

重要
「最新Revisionが存在する」＝「一般ユーザーが最新Revisionを見ている」とは限りません。

本番トラフィックが最新Revisionへ向いているか確認する

完全に新しいバージョンへ切り替えたい運用なら、最新Revisionへ100％のTrafficが向いているか確認します。意図的な段階公開をしている場合は100％である必要はありません。確認するのは、最新Revision名、作成日時、Traffic割合、古いRevisionへTrafficが残っていないか、の4点です。

環境変数を変えただけでも新Revisionが必要

Cloud Runでは環境変数もRevisionの構成の一部です。APIのURL、メール送信先、アプリの動作モード、外部サービスに関係する設定値などを変更した場合も、新しい設定を持つRevisionが作成されることを確認します。

Secretやサービスアカウントも確認する

コードは正しいのにAPI接続だけ動かない場合は、Secret参照、Secretのバージョン、サービスアカウント、IAM権限なども切り分け対象になります。単純に「コードが悪い」と決めつけないことが重要です。

GitHubのSHAとCloud Runをつなげて管理すると強い

本番トラブルで困るのは、「いま本番でどのコードが動いているのか分からない」という状態です。そこで、GitHubのcommit SHAをデプロイ識別に利用すると、GitHub、Build、デプロイイメージの時点を追いやすくなります。非エンジニアでも「本番はどのSHAですか？」と確認しやすくなります。

確認5｜最後は本番URLを人間が実操作する

ここまで全部正常でも、最後の確認が残っています。それが実際の本番URLでの操作です。Cloud Buildが成功し、Cloud Runへ新Revisionがデプロイされても、実際の業務機能が正しく動くとは限りません。

画面が開いただけでは正常とは言えない

たとえば診断アプリなら、トップページが表示されたからといって完成ではありません。ログインできるか、フォームを入力できるか、データを保存できるか、保存したデータを再表示できるか、診断処理が正常か、PDFが生成できるか、メール送信できるか、管理画面へ反映されるか、までを確認します。

修正した機能の周辺も確認する

もう一つ重要なのが回帰確認です。回帰確認とは、「Aを直した結果、以前動いていたBやCが壊れていないかを見ること」です。メール送信処理を変更した結果、PDF添付が外れた、顧客データ保存が動かなくなった、管理画面へ表示されなくなったといったことも起こり得ます。

そのため本番確認では、修正対象＋周辺機能を見ることが重要です。

Cloud Runに反映されないときによくある4つの事故

Cloud Runのローカル保存に依存しない

Cloud Runのコンテナには書き込み可能なファイルシステムがありますが、インスタンスは使い捨てを前提としており、インスタンスが停止するとローカルファイルは永続化されません。永続ファイルが必要な場合はCloud Storageやデータベースなど外部の保存先を利用します。

顧客データ、生成PDF、アップロードファイル、診断結果、業務上必要な記録など、消えてはいけない情報をCloud Runのローカル保存だけに依存しないよう注意してください。

AIの「修正完了しました」を鵜呑みにしないための質問リスト

AIとの開発で非常に重要なのが、報告ではなく証拠を出してもらうことです。

AIへの追加指示
実施していない項目は、実施済みのように書かず「未実施」と明記してください。

「修正完了」の定義をAIへ最初に渡しておく

毎回質問するより、さらに効果的なのが、最初から完了条件を定義しておくことです。

本番修正完了の定義テンプレート
1．対象コードの修正が完了している／2．GitHubのmainへ反映済み／3．commit SHAを確認済み／4．Cloud Buildが対象SHAで成功／5．Cloud Runに新Revisionが作成済み／6．最新Revisionへ本番Trafficが向いている／7．本番URLで修正対象を実操作／8．周辺機能を回帰確認

「この8項目すべて完了した場合のみ『本番修正完了』と報告してください」と定義します。これだけでもAIとの認識ズレを減らしやすくなります。

AIの完了報告フォーマットも決める

特にSHA、Build、Revision、本番操作の4つが揃っているかを見るだけでも、報告の信頼性は上がります。

「正常に動作しています」という言葉より実ログを見る

AIとの開発で注意したいのは、「問題ありません」「正常です」という自然言語だけで判断しないことです。AIから「デプロイも正常に完了しました」と報告された場合でも、何を根拠にそう判断したのかを確認します。Cloud Buildの実ログを確認したか、Revisionの作成を実際に確認したか、本番URLへアクセスしたか、という3点です。

AIがコードを解析した結果として「正常だと思われます」と回答しているだけなのか、実際の環境を確認しているのかでは、意味がまったく違います。

原因が分からないときは「証拠が途切れた場所」へ戻る

ここまで説明した内容を使うと、トラブル対応がかなりシンプルになります。

証拠の連鎖
SHA → Build → Revision → Traffic → 本番操作。どこで証拠が途切れたかを探します。

Cloud Runトラブルで一番避けたいのは「とりあえず再デプロイ」

うまく動かないと、「とりあえずもう一回デプロイしてみよう」となりがちです。もちろん再デプロイで解決するケースもあります。しかし原因を特定しないまま何度も変更すると、Revisionが増える、どのコードが正しいか分からなくなる、Triggerが複数残る、リージョン違いのサービスが増える、環境変数が違う、どのBuildが本番なのか分からない、といった状態になりかねません。

そこで先に、現在のGitHub SHAは何か、最新Buildは何か、最新Revisionは何か、本番Trafficはどこかを記録します。そのうえで次の操作を行う方が安全です。

経営者・発注担当者もSHAを知っておくと管理しやすい

「SHAなんてエンジニアだけが知っていればよい」と思うかもしれません。しかしAI開発では、非エンジニアの経営者や発注担当者こそ、「本番はどのSHAですか？」と聞けるようになると便利です。

コードの内容そのものを読めなくても、「今回依頼した修正のcommitはどれか」を識別できるからです。これは工事で例えるなら、「どの設計図の版で施工したのか」を確認するようなものです。

よくある質問

GitHubにpushできていればCloud Runにも自動で反映されますか？

必ずしも反映されません。GitHubへのpush後にCloud Build Triggerが正しく動作し、Buildが成功し、Cloud Runへのデプロイまで実行される構成になっている必要があります。GitHubのSHA確認後はCloud Build Historyを確認してください。

Cloud Buildが成功していれば本番も正常ですか？

いいえ。Cloud Build成功はBuild処理が成功したことを示しますが、本番機能の動作確認とは別です。さらに、新しいCloud Run Revisionが作成されているか、そのRevisionへTrafficが向いているかも確認する必要があります。最終的には本番URLで実際の業務操作を確認してください。

新しいRevisionがあるのに画面が変わらないのはなぜですか？

Trafficが古いRevisionへ向いている可能性があります。Cloud Runでは複数RevisionへTrafficを分割できます。新Revisionの存在だけでなく、本番Trafficの配分も確認してください。

Cloud Buildの履歴を消せば自動デプロイも止まりますか？

履歴・ログとTriggerは役割が異なります。Build Historyは過去の実行結果を確認する場所で、Triggerは今後のBuildを開始する設定です。自動実行を止める場合は対象Trigger側を確認してください。

Cloud Runの中へファイルを保存しても大丈夫ですか？

一時ファイルとして利用する設計と、永続保存は分けて考える必要があります。Cloud Runのローカルファイルシステムはインスタンス終了時に永続化されません。顧客情報や業務データなど、消失してはいけない情報は外部の永続保存先を利用してください。

まとめ｜最後は人間が本番URLを操作して初めて完成

AIを使ったアプリ開発では、AIから「修正完了しました」「正常に動作しています」と言われることがあります。しかし、それをそのまま「本番環境まで修正された」という意味で受け取ってはいけません。

覚えておきたいこと
コード修正完了＝本番修正完了ではありません。

Cloud Runに修正が反映されない場合は、1．AI Studio・開発環境 → 2．GitHub → 3．Cloud Build → 4．Cloud Run → 5．本番URLの順番で確認します。

GitHubではcommit SHAと変更ファイルを確認します。Cloud BuildではHistoryとTriggerを分けて確認します。Cloud Runでは新Revisionが作られたかを確認し、そのRevisionへ本番Trafficが向いているかを確認します。

そして最後は、ログイン、データ入力、保存、PDF出力、メール送信、管理画面、その他の周辺機能を人間が本番URLで実際に操作します。そこまで終わって、初めて「本番修正完了」です。

AIによってアプリ開発のハードルは大きく下がりました。しかし、本番環境で正しく動いていることを確認する責任までAIへ丸投げするのではなく、「何をもって完成とするか」を人間側が定義することが、これからのAI開発ではますます重要になります。

参考情報

技術仕様に関する記述は、Google CloudおよびGitHubの公式ドキュメントを参照しています。サービス仕様は変更される可能性があるため、実際の運用時は最新の公式情報をご確認ください。

Google Cloud：Cloud Runへのデプロイ
Google Cloud：Revisionの管理
Google Cloud：Revision間のTraffic管理
Google Cloud：Cloud Buildによる自動Build
GitHub Docs：About commits