「Cloud Runにアプリを公開できた。次はメール送信機能を追加しよう」

そこでSMTPサーバーの情報を設定しようとすると、SMTP_HOST、SMTP_PORT、SMTP_USER、SMTP_PASS、MAIL_FROM、APP_BASE_URLなどの値が必要になります。さらに外部サービスを使えばAPIキー、ログイン機能を作ればセッション署名鍵、管理者機能を作れば管理者パスワードなども必要になります。

ここで最初につまずきやすいのが、「これらの値を全部Cloud Runの環境変数に入れておけばよいのか？」という問題です。

結論から言えば、すべてを同じように扱うべきではありません。重要なのは、「設定値」と「秘密値」を分けることです。公開されても直ちに問題にならない設定値はCloud Runの通常環境変数へ、漏れてはいけない秘密値はSecret Managerへ分離します。

SMTP_HOSTやSMTP_PORT、APP_BASE_URLなど、知られても直ちに認証突破につながらない設定値は通常の環境変数として管理できます。一方、SMTP_PASS、APIキー、セッション署名鍵、実パスワードなど、第三者に知られると不正利用につながる情報はSecret Managerで管理するのが基本です。

Google Cloudも、Cloud RunサービスがAPIキー、パスワード、証明書などの機密情報を必要とする場合、Secret Managerへ保存することを推奨しています。

今回の記事では、実際にCloud Runで業務アプリを構築した際のSecret Manager運用をもとに、設定値と秘密値の分け方 → Secret作成 → Cloud Runからの参照 → Secret更新 → バージョン確認 → 新リビジョン → 本番確認までを順番に解説します。

特に重要なのが、Secret Managerの値を更新しただけでは、稼働中のCloud Runへ意図した形で反映されたとは限らないという点です。実際の開発でも、ここが大きなつまずきになりました。

Secret Managerを「秘密を保存する場所」として覚えるだけでは不十分です。秘密値をどう更新し、Cloud Runがどのバージョンを参照し、本番へどう反映するかまで含めて運用する。これが本記事で最も伝えたいポイントです。

Cloud RunのパスワードやAPIキーはSecret Managerで管理する

ソースコードやGitHubへ秘密値を書いてはいけない

Cloud Runでアプリを動かすとき、ソースコードだけで完結するシステムはほとんどありません。メールを送信するならSMTP認証情報が必要です。外部AIや外部サービスを呼び出すならAPIキーが必要になることがあります。管理画面へのログインを実装するなら、パスワードやセッション署名鍵が必要になります。こうした情報をソースコードへ直接記述するのは避けるべきです。

たとえば、SMTP_PASS=本物のメールパスワード、API_KEY=本物のAPIキー、ADMIN_PASSWORD=本物の管理者パスワード、といった値をコードファイルへ直接書き、そのままGitHubへpushすると、秘密情報とプログラムが一体化してしまいます。

GitHubを非公開リポジトリにしていたとしても、「コードを共有すること」と「秘密情報へアクセスできること」が同じ状態になるため、運用上の管理が難しくなります。

実践手順書でも、パスワード、SMTP認証情報、セッション署名鍵、APIキーなどをGitHubやソースコードへ書かないことがSecret Managerを使う主な理由として整理されています。Secret Managerを利用することで、秘密情報をコードから分離し、IAMによるアクセス制御やバージョン管理を行えるようになります。

Secret Managerとは

Secret Managerを難しく考える必要はありません。初心者向けに言えば、「アプリが必要とする秘密の値を、プログラム本体とは別の場所に保管する仕組み」と考えると分かりやすいでしょう。

たとえばアプリ側ではSMTP_PASSという変数名だけを使います。一方、本物のSMTPパスワードはSecret Managerへ保存します。Cloud Run側で「このSMTP_PASSという環境変数には、Secret ManagerのこのSecretを渡す」という参照関係を設定します。

すると、コードの中へ実パスワードを書く必要がなくなります。Google Cloudでは、Cloud RunからSecretを環境変数として渡す方法と、ボリュームとしてマウントする方法が提供されています。本記事では、中小企業の業務アプリなどで理解しやすいよう、主に環境変数としてSecretを参照する方法を前提に解説します。

最初に覚えたい「設定値」と「秘密値」の違い

通常環境変数で管理する設定値

Secret Managerを使い始める前に、一番重要なのが分類です。何でもSecret Managerへ入れる必要はありません。逆に、秘密にすべきものを通常の設定値と同じ感覚で扱わないことも重要です。

たとえばSMTP_HOST、SMTP_PORT、APP_BASE_URL、MAIL_FROMなどは、アプリをどの環境でどのように動かすかを決める「設定」です。APP_BASE_URLなら「本番アプリのURLは何か」、SMTP_HOSTなら「どのSMTPサーバーへ接続するのか」という情報です。

もちろんシステム構成によって個別判断が必要ですが、その値単体を知られただけで認証を突破されたり、外部サービスを不正利用されたりする性質のものではないのであれば、通常環境変数として扱いやすいでしょう。

Secret Managerで管理する秘密値

一方、SMTP_PASS、API_KEY、ADMIN_PASSWORD、ADMIN_SESSION_SECRETなどは性質が異なります。SMTP_PASSが漏れればメールアカウントへの不正アクセスにつながる可能性があります。APIキーが漏れれば、第三者がそのAPIを利用して料金を発生させたり、本来許可していない処理を実行したりする可能性があります。

セッション署名鍵が漏れれば、認証処理の安全性そのものへ影響する可能性があります。つまり、「アプリを動かすための情報」だから同じなのではなく、その値が持っている危険性で分けることが大切です。

迷ったときは「漏れたら困るか」で考える

初心者が迷った場合は、まず「この値がGitHubやログ、画面、チャットへそのまま表示された場合、困るか？」と考えてください。SMTP_PORTが「587」だと知られても、それだけでメール送信できるわけではありません。しかしSMTP_PASSが漏れれば問題です。

APIの接続先URLが知られることと、本物のAPIキーが知られることも意味が違います。公開されても大きな問題にならない設定情報なのか、それとも本人確認・認証・署名・権限取得に使える秘密情報なのかを基準に判断すると分かりやすくなります。迷った場合は安全側へ倒し、Secretとして扱うことを検討してください。

SMTP設定で見るCloud Run＋Secret Managerの構成例

SMTP_HOSTやSMTP_PORTは設定値

Cloud Runアプリから自社ドメインのメールを送信する場合、SMTP_HOST、SMTP_PORT、SMTP_USER、SMTP_PASS、MAIL_FROM、APP_BASE_URLなどの設定が必要になることがあります。このとき、重要なのは「SMTP設定だから全部Secret」という考え方ではありません。一つずつ性質を見ます。

SMTP_HOSTは接続するメールサーバー、SMTP_PORTは接続ポートです。これらは通信設定として必要ですが、それだけでメールアカウントへログインできる秘密情報ではありません。そのため、通常のCloud Run環境変数として管理する設計が考えられます。

SMTP_PASSは秘密値

SMTP_PASSは全く違います。これは認証情報そのものです。そのため、SMTP_PASS=xxxxxxとソースコードへ直接書くのではなく、Secret Managerへ本物の値を保存します。Cloud Runには、環境変数名SMTP_PASSと、参照するSecretを対応させます。

アプリ側は「SMTP_PASSという名前」を参照する

この考え方は非常に重要です。コードの中ではSMTP_PASSという変数名を使います。しかし本物のパスワードそのものはコードへ書きません。つまり、コードは「何という名前の情報が必要か」を知っているだけで、「実際の値」は知らないという分離を作ります。

これによって、GitHub上のコードを確認したり、AIへコードを相談したりするときにも、本物の認証情報を見せる必要がありません。この構造を作れることがSecret Managerを利用する大きな意味です。

Secret ManagerでSecretを作成してCloud Runから参照する流れ

STEP1：Secret ManagerでSecretを作成する

まずGoogle Cloudの対象プロジェクトを確認します。複数プロジェクトを使っている場合、ここを間違えると「Secretは作ったのにCloud Runから見つからない」という混乱につながります。

Secret名は用途が分かるものにします。たとえばADMIN_SESSION_SECRET、SMTP_PASS、EXTERNAL_API_KEYのような命名です。実際の値そのものをSecret名にするのではありません。

STEP2：Secretの値を登録する

Secretを作成したら、実際の秘密値をSecret Managerへ登録します。ここで注意したいのは、Secret Managerへ登録する作業の途中でも、不要な場所へ秘密値をコピーしないことです。

問題解決のためにAIへ相談するからといって、「このパスワードをSecret Managerへ入れています」と本物の値まで貼る必要はありません。画面共有やスクリーンショットを取得するときにも、秘密値が映り込んでいないか確認しましょう。

STEP3：Cloud RunからSecretを参照する

次にCloud Runサービスを開きます。既存サービスなら、新しいリビジョンを編集・デプロイする設定画面からSecret参照を追加します。環境変数としてSecretを利用する場合は、環境変数名、Secret名、Secretのバージョンを対応させます。

たとえば「Cloud Run環境変数名：SMTP_PASS」「Secret Manager：SMTP_PASS」「参照バージョン：2」という関係です。環境変数名とSecret名は必ず同じ文字列でなければならないわけではありませんが、運用上分かりやすい命名にしておくとトラブルが減ります。

STEP4：新しいリビジョンをデプロイする

ここが非常に重要です。Cloud Runでは、サービスの構成変更によって新しいリビジョンが作成されます。実践手順書でも、環境変数、Secret参照バージョン、サービスアカウント、CPUやメモリ等の実行設定を変更したときは「新しいリビジョンの編集とデプロイ」を使う運用になっています。

設定画面を編集しただけではなく、「どのリビジョンが実際に本番トラフィックを受けているか」まで確認しましょう。

最大のつまずき｜Secretを更新したのにCloud Runへ反映されない

Secret Managerの値を変えただけで終わらせない

Secret Managerを初めて使うと、「Secret Managerで新しい値を登録したから、これでもう本番アプリも新しい値になったはず」と思ってしまいがちです。実際の業務アプリ開発でも、ここが大きな学びになりました。

たとえば管理者パスワードを変更し、Secret Managerに新しい値を登録したとします。ここまでは問題ありません。しかし、Cloud Run側がどのバージョンを参照しているかを確認しなければなりません。

Secret ManagerではSecretの中に複数のバージョンを持てます。version 1が古いパスワード、version 2が新しいパスワードという状態で、Cloud Runがversion 1を明示的に参照しているのであれば、Secret Managerにversion 2を追加しただけではCloud Runの参照先はversion 1のままです。

CloudRunがどのSecretバージョンを参照しているか確認する

Secretを変更したときは、「Secret Managerでは最新版は何番か」だけを見るのではなく、「Cloud Runは何番を読みに行く設定になっているか」を確認します。これは似ていますが、別の確認です。

Secret Managerにversion 1とversion 2があり、Cloud RunがSMTP_PASS → version 1を参照しているなら、新しい値は使われません。Cloud Run側をSMTP_PASS → version 2へ変更し、新リビジョンをデプロイします。

「設定を変えた」＝「本番が変わった」ではない

これはSecret Managerに限らず、Cloud Run全体で重要な考え方です。実践手順書では、「コードを直した」≠「本番が直った」として、GitHub反映 → Cloud Build成功 → Cloud Run新リビジョン → 100％トラフィック → 本番URLで実機確認までを1セットとして整理しています。

Secretの変更も同じです。「Secretを更新した」＝「稼働中のアプリで新しいSecretが使われている」ではありません。

新リビジョンをデプロイする

固定バージョン参照を1 → 2へ変更した場合は、新リビジョンをデプロイします。その後、最新リビジョンになっているか、正常に起動しているか、本番トラフィックがそのリビジョンへ向いているかを確認します。

最後は本番URLで1回テストする

デプロイできたからといって安心せず、実機テストを行います。SMTP_PASSを変更したならメール送信、管理者パスワードなら管理者ログイン、APIキーなら対象APIを利用する機能、というように変更したSecretが実際に使われる機能を確認します。

実践手順書では、本番でのテストを「1回だけ」行うこともポイントとして整理されています。認証失敗を繰り返すと、サービスによってはレート制限やロックなど別の問題を引き起こす可能性があります。Secret変更 → 参照先確認 → デプロイ → 本番テストをセットにしましょう。

Secretは削除せず「新しいバージョン」を追加する

version 1を上書きするのではなくversion 2を作る

パスワードを変更するとき、古いSecretを削除して新しいSecretを作り直すより、同じSecretへ新しいバージョンを追加する方が管理しやすくなります。たとえばSMTP_PASSのversion 1を使用中なら、変更時にversion 2を追加します。これなら、どのタイミングでSecretが更新されたかを追いやすくなります。

旧バージョンをすぐ削除しない

新しいパスワードへ切り替えた直後、問題が発生したとします。このとき旧バージョンが残っていれば、原因確認や切り戻しの余地があります。実践手順書でも、旧バージョンはすぐ消さず、ロールバックの余地を残す運用になっています。

安定後に旧バージョン無効化を検討する

古い認証情報を永遠に有効な状態で残してよいわけではありません。新しいSecretで正常稼働することを確認し、影響範囲を確認したうえで、古いバージョンの無効化などを検討します。大切なのは、「更新した瞬間に旧版を削除する」のではなく、「切替確認後に整理する」という順番です。

latestと固定バージョンはどちらを使う？

固定バージョンのメリット

Secret ManagerとCloud Runを連携するとき、よく迷うのが「latestを指定すればよいのか、それともversion 2のように番号を固定すべきか」という問題です。

SMTP_PASS → version 2と指定すれば、「このCloud Runリビジョンはversion 2を使っている」という関係が明確です。トラブルが起きたときも、どのリビジョンか、どのSecretバージョンかを対応させやすくなります。

Cloud RunでSecretを環境変数として利用する本番運用では、再現性を重視するなら特定バージョンへ固定する考え方が分かりやすいでしょう。

固定バージョンの注意点

固定するということは、Secretを更新したときにCloud Runの参照先も変更する必要があるということです。version 3を作ったのに、Cloud Runがversion 2を参照し続けていれば、新しい値には切り替わりません。これが実際につまずきやすいポイントでもあります。

latestのメリット

latestを使うと、参照するSecretを「最新バージョン」として扱えます。実践手順書では、緊急復旧が速い点をメリットとして整理しています。ただし、いつ値が変わったのかを運用側で管理する必要があります。

本番では固定バージョンを基本に考える

非エンジニアがCloud Runの本番サービスを管理する場合は、通常運用では固定バージョンを基本にすると管理しやすいでしょう。新しいSecretバージョンを作る → Cloud Runで参照バージョンを変更する → 新リビジョンをデプロイする → 本番動作確認する → 安定後に旧バージョンを整理する、という変更手順を決めておきます。

一方で、Secretローテーション方式やボリュームマウントなど、システムの構成によって最適解は変わります。本番設計時はGoogle Cloud公式ドキュメントの最新情報も確認してください。

Secret Managerだけでは足りない｜Cloud Runの権限も確認する

Cloud Runの実行サービスアカウントを確認する

Secret Managerへ値を保存しただけでは、Cloud Runが自由にその値を読めるわけではありません。ここで関係してくるのがIAMとサービスアカウントです。Cloud RunサービスはサービスアカウントというGoogle Cloud上のIDを使って他のGoogle Cloudサービスへアクセスします。

Secret ManagerからSecretを取得する場合も、「このCloud Runサービスのサービスアカウントが、このSecretへアクセスしてよい」という権限が必要です。

必要な権限だけを与える

権限エラーが出ると、「とりあえず管理者権限を付ければ動くだろう」と考えたくなるかもしれません。しかし、本番環境では必要以上に強い権限を付けないことが重要です。どのサービスアカウントがSecret Manager、Firestore、その他のGoogle Cloud APIのどこへアクセスする必要があるのかを整理しましょう。

AIにCloud Runのエラーを相談するときも秘密値は貼らない

「SMTP_PASSというSecretを参照している」で十分

AIと会話しながらアプリを作っていると、Cloud RunやSecret Managerでエラーが起きたときにChatGPTやClaudeなどへ相談したくなる場面があります。そのとき、本物のSMTPパスワードやAPIキーを貼る必要はありません。

たとえば、「Cloud RunでSMTP_PASSという環境変数を設定し、Secret ManagerのSMTP_PASSというSecretを参照しています。Secret Managerにはversion 1とversion 2があり、Cloud Runは現在version 1を参照しています。新しいパスワードはversion 2へ登録しましたが、ログインできません」と伝えれば、参照バージョンの切り分けができます。

AIへ相談するときに伝えるべき情報

Cloud Run＋Secret Managerの問題なら、Cloud Runの環境変数名、Secret名、Secretの参照方式、参照しているバージョン、新しいバージョンを作成したか、新リビジョンをデプロイしたか、どの機能でエラーが出ているか、エラーメッセージ、本番リビジョンへトラフィックが向いているか、などを整理すると相談しやすくなります。

AIへ伝えなくてよい情報

実パスワード、本物のAPIキー、アクセストークン全文、秘密鍵、セッション署名鍵、パスワード再設定用トークン全文、Cookieなどの認証情報は原則として貼らないようにします。

本記事で扱っているのは、開発システム内部の認証情報を、デバッグやAI相談の過程でも露出させないという設計・運用の話です。「値」ではなく「構造」を伝える。これを習慣にしましょう。

Cloud Run＋Secret Managerで起きやすい失敗

失敗1：GitHubへ秘密値を書いてしまう

最初はアプリを動かすことに集中しているため、実パスワードを直接コードへ書いてしまうことがあります。開発途中の一時対応だったとしても、そのままGitHubへpushされる可能性があります。秘密値はコードへ埋め込まず、Secret Managerへ分離します。

失敗2：すべてを通常環境変数として考える

Cloud Runに「環境変数」という設定欄があるため、「パスワードも環境変数へ入れればよい」と考えてしまいがちです。重要なのは、通常の値を直接設定する環境変数と、Secret ManagerのSecretを環境変数として参照する方式を区別することです。

失敗3：Secretの新バージョンを作って満足する

Secret Managerでversion 2を作ったから新しい値になった、とは限りません。Cloud Runがversion 1を参照しているなら、その参照設定も確認する必要があります。

失敗4：Cloud Runが古いバージョンを参照している

Secret Manager画面だけ見ていると「最新はversion 2」という事実しか目に入りません。しかし重要なのはCloud Runが何を参照しているかです。Secret側とCloud Run側の両方を確認しましょう。

失敗5：新リビジョンをデプロイしていない

Cloud Runの設定を編集しても、新しい設定を反映したリビジョンが本番で稼働していなければ意味がありません。最新リビジョン、正常起動、トラフィック、作成時刻などを確認し、本番URLで実機確認します。

失敗6：旧Secretをすぐ削除する

新しいSecretへ変更した瞬間に旧版を削除すると、トラブル発生時の復旧余地を減らします。まず新しいバージョンを作り、Cloud Runを切り替え、本番確認を行います。その後、影響範囲を確認してから旧版を整理します。

失敗7：ログへSecretを出してしまう

デバッグのために秘密値そのものをログ出力する処理を入れたままにするのも避けましょう。Secret Managerへ保存していても、その値をアプリ側でログ出力すれば秘密管理の意味が薄れます。値そのものではなく、SMTP_PASSが設定されているか、といった存在確認に留めるなど、安全なデバッグ方法を考えます。

Cloud Run＋Secret Manager運用チェックリスト

Secret Managerを使う目的は「秘密を置く」だけではない

「コード管理」と「秘密情報管理」を別物にする

Secret Managerを導入する目的は、秘密情報を一か所へ置くことではなく、秘密情報のライフサイクルをコードから切り離すことです。パスワードはいつか変更します。APIキーはローテーションする可能性があります。退職や担当変更、サービス移行などで認証情報を交換することもあります。

秘密値がコードへ直接入っていると、認証情報を変更するたびにコードまで変更する状態になります。一方、アプリ側はSMTP_PASSという変数を読み、Cloud Run側でその変数がSecret Managerの特定バージョンを参照する構造にしておけば、秘密情報とアプリロジックを分けて考えられます。

AIを使ってアプリ開発を行う時代には、この分離はさらに重要です。コードはGitHubで管理する、Claude Codeで修正する、ChatGPTへ相談する、他の開発者にレビューしてもらう、といった形で比較的多くの場所を移動します。しかしSecretは同じように移動させるべきではありません。コードを共有しても、実パスワードや実APIキーまで共有しない構造にしておけば、安全性だけでなく開発もしやすくなります。

非エンジニアこそ「どこへ置くか」を覚える

AIと会話しながらアプリを作れるようになったことで、以前ならエンジニアへ任せていたシステムを、中小企業の経営者やWeb担当者が自分で構築するケースも増えていくでしょう。そこで必要になるのが、プログラム文法そのものよりも、「このデータはどこへ保存するのか」「この認証情報は誰が読めるのか」「変更した設定はどう本番へ反映されるのか」という設計上の判断です。Secret Managerは、その中でも非常に重要な基礎知識の一つです。

Cloud RunとSecret Managerを安全に運用する5段階

1．設定値と秘密値を分ける

まず一覧化します。設定値としてSMTP_HOST、SMTP_PORT、APP_BASE_URL、MAIL_FROM、秘密値としてSMTP_PASS、API_KEY、ADMIN_PASSWORD、ADMIN_SESSION_SECRETのように分類します。

2．秘密値をSecret Managerへ入れる

本物のパスワードやAPIキーをGitHubやソースコードへ書きません。Secret ManagerへSecretとして登録します。

3．Cloud RunからSecretを参照する

Cloud Run側で、環境変数名、Secret名、参照バージョンを設定します。本番ではどのバージョンを使っているか追える状態にしておきます。

4．Secret更新時は新リビジョンまで確認する

Secretの新バージョンを作っただけで終わりません。固定バージョンを使うならCloud Runの参照バージョンを変更し、新リビジョンをデプロイします。新バージョン追加 → Cloud Run参照確認 → デプロイ → 本番テストという順番で運用します。

5．本番URLで実際に確認する

最後に、ログイン、メール送信、API接続など対象機能をテストします。Cloud Runでは、設定したことと、本番でその設定が実際に使われていることを分けて確認する習慣が重要です。

よくある質問

Cloud Runの環境変数へパスワードを直接入力してはいけませんか？

Cloud Runでは通常環境変数も利用できますが、パスワードやAPIキーなどの機密情報については、Secret Managerへ保存してCloud Runから参照する方法を検討してください。SMTP_HOSTやAPP_BASE_URLなどの設定値と、SMTP_PASSやAPIキーなどの秘密値を分けて管理すると、コードや設定の共有時に秘密情報が露出するリスクを抑えやすくなります。

SMTP_HOSTもSecret Managerへ入れる必要がありますか？

必ずしも必要ではありません。SMTP_HOSTやSMTP_PORTのように認証情報そのものではない設定値は通常環境変数として管理できます。一方、SMTP_PASSのように第三者へ知られると認証に悪用される情報はSecret Managerで管理します。迷う場合は「この値が漏れた場合に認証突破や不正利用につながるか」を判断基準にしてください。

Secret Managerの値を変更すればCloud Runへすぐ反映されますか？

参照方法によって考え方が異なります。固定バージョンを環境変数として参照している場合、新しいSecretバージョンを追加してもCloud Runの参照先が旧バージョンのままなら、新しい値へ切り替わりません。新しいバージョンを作成した後は、Cloud Runの参照バージョンを確認し、必要に応じて変更して新リビジョンをデプロイし、本番で確認してください。

latestと固定バージョンはどちらがおすすめですか？

本番環境で再現性を重視する場合は、固定バージョンを基本にすると、どのCloud RunリビジョンがどのSecretを使っているか追いやすくなります。一方、latestには運用上の利便性もあります。システム構成やSecretローテーション方式によって適切な方法は変わるため、本番設計時は最新のGoogle Cloud公式ドキュメントも確認してください。

ChatGPTやClaudeへ相談するとき、本物のAPIキーを貼る必要がありますか？

必要ありません。「API_KEYという環境変数が、Secret ManagerのAPI_KEYというSecretを参照している」「現在version 2を参照している」といった構造を伝えれば、原因切り分けに必要な情報を共有できます。実パスワード、APIキー、アクセストークン、秘密鍵などは貼らないようにしましょう。

まとめ｜秘密値を分離するだけでなく「更新後の反映」まで運用にする

Cloud RunでパスワードやAPIキーを管理するとき、最初に覚えるべきことは「設定値」と「秘密値は違う」ということです。SMTP_HOST、SMTP_PORT、APP_BASE_URLなどはアプリを動かすための設定値です。一方、SMTP_PASS、APIキー、管理者パスワード、セッション署名鍵などは第三者に知られてはいけない秘密値です。これらはSecret Managerへ分離して管理します。

そして、Secret Managerを使ううえで特に重要なのが、Secretを更新しただけで作業を終わらせないことです。固定バージョンで運用しているなら、新しいSecretバージョンを追加 → Cloud Runの参照バージョンを確認 → 新リビジョンをデプロイ → 本番トラフィック確認 → 本番URLで動作確認までを1セットとして考えます。

Cloud Runのコード変更でも、「GitHubへpushした＝本番が変わった」ではありません。Secret Managerも同じです。「Secretを変更した＝稼働中のアプリが新しいSecretを使っている」ではありません。本番環境では、どのコード、どのリビジョン、どの設定、どのSecretバージョンが実際に動いているのかを確認できる状態を作ることが重要です。

また、ChatGPTやClaudeなどAIへトラブルを相談するときも、本物のパスワードやAPIキーを貼る必要はありません。「SMTP_PASSという環境変数が、Secret ManagerのSMTP_PASSというSecretのversion 2を参照している」という構造を伝えれば、原因切り分けには十分なケースが多くあります。AIでアプリを作りやすくなった今だからこそ、作る技術だけでなく、秘密情報・データ・権限・本番環境を安全に運用する知識も一緒に身につけていきましょう。

AIを使えば、非エンジニアでも業務アプリを形にしやすくなりました。一方、本番環境では、データをどこへ保存するか、パスワードやAPIキーをどう管理するか、GitHubへ何を置いてよいか、Cloud Runへどう反映するか、どのサービスアカウントへどの権限を与えるか、といった設計も必要です。

「アプリは作れたけれど、本番運用の構成が正しいか不安」「AIを使って自社業務をシステム化したいが、Cloud RunやFirestore、Secret Managerの役割分担が分からない」という場合は、現在の業務とシステム構成を一度整理してみることをおすすめします。相談時には、本物のパスワードやAPIキーをお送りいただく必要はありません。

参考：Google Cloud公式ドキュメント（Secret Manager / Cloud Run）および自社の実践手順書をもとに構成しています。Google Cloudの画面名称や仕様は変更される可能性があるため、実装時は最新の公式情報をご確認ください。