ワンクリックデプロイの『その先』— AI Studio から Cloud Run に出した Gemini アプリを本番に引き上げる点検手順

点検 2: その URL、誰でも叩ける状態になっていないか

ワンクリックデプロイの目的は「すぐ試せる URL を出すこと」なので、サービスは未認証アクセスを許可した状態で公開されているはずです。試作の共有ならそれでよくても、Gemini API の呼び出しはリクエストのたびに費用が発生します。つまり 未認証の公開 URL は、他人があなたの財布でトークンを消費できる窓口 でもあります。

利用者が自分と数人のうちは、Cloud Run の IAM 認証に切り替えるのが最短です。

# 未認証アクセスを閉じる
gcloud run services update my-genai-app \
  --region=asia-northeast1 \
  --no-allow-unauthenticated
 
# 叩いてよい人にだけ起動権限を付与する
gcloud run services add-iam-policy-binding my-genai-app \
  --region=asia-northeast1 \
  --member="user:teammate@example.com" \
  --role="roles/run.invoker"

呼び出す側は ID トークンをヘッダーに付けます。curl での動作確認はこの形です。

curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" \
  https://my-genai-app-xxxxxxxx-an.a.run.app/api/generate

不特定多数に公開するアプリなら IAM では守れないので、アプリ側の認証（Firebase Authentication など）とレート制限を実装してから開けることになります。ここは用途によって答えが変わる部分ですが、「認証なしで公開したまま気づいたら数週間経っていた」が一番避けたい状態です。まず閉じてから、開け方を考える順番が安全です。

点検 3: 費用の天井を先に決める

Gemini アプリの費用は「Cloud Run の実行費」と「Gemini API のトークン費」の二階建てです。ここでの落とし穴は、Cloud Run 側の上限だけ絞って安心してしまうことです。放置したときに伸びるのは後者のトークン費なので、両方に天井を付けてはじめて事故を回避できます。

Cloud Run 側は、スケール上限と同時実行数を明示します。プロトタイプ相当の負荷なら、私は最初にかなり保守的な値を入れておき、必要になってから上げる運用にしています。

gcloud run services update my-genai-app \
  --region=asia-northeast1 \
  --max-instances=2 \
  --concurrency=20

Gemini API 側は、プロジェクト単位で月額の上限を設定できる Project Spend Caps を入れておくと、キー漏洩や想定外のループのような事故でも被害額が確定します。上限に達すると止まるという性質そのものが保険になります。アプリ側でのソフト上限との二段構えについては、Project Spend Caps とアプリ側ソフト上限で、無人パイプラインの費用事故を二重に止めるで詳しく書きました。

もうひとつ、コールドスタートは費用と体験のトレードオフとして把握しておくと判断が楽です。私の手元の Node 系コンテナでは、アイドル状態からの初回応答に 2〜4 秒程度かかります。これが気になる場合は --min-instances=1 で常駐させられますが、当然アイドル分の課金が発生します。試作を昇格させた直後の段階では、私は min-instances を入れず「最初の 1 リクエストは遅くてよい」と割り切ることが多いです。

点検 4: 生成されたコードの所有権を取り戻す

ワンクリックデプロイの状態は「AI Studio 上の成果物がクラウドに写っている」状態であって、自分のリポジトリと CI が起点になっていません。このままだと、次の変更をどこでやるのか、誰がいつデプロイしたのかが曖昧なままサービスが生き続けます。

やることは単純で、コードをエクスポートして自分のリポジトリに入れ、以後のデプロイをソース起点に切り替えるだけです。

# リポジトリ化したソースからのデプロイに載せ替える
gcloud run deploy my-genai-app \
  --region=asia-northeast1 \
  --source=. \
  --no-allow-unauthenticated

同名サービスに対して gcloud run deploy を実行すれば新しいリビジョンとして載るので、URL や設定は引き継がれます。以後は GitHub Actions なりで main ブランチからこのコマンドを叩く形にすれば、ワンクリックデプロイは「最初の一回の足場」だった、という位置づけに整理できます。

ここで一度だけ、生成されたコードを読む時間を取ることをおすすめします。全部を理解する必要はありませんが、Gemini をどのモデル名で呼んでいるか と リトライやタイムアウトの有無 の 2 点だけは確認する価値があります。プレビュー版のモデル名が直書きされていれば、いずれ廃止で止まります。基盤側の変更で自動処理が静かに止まる問題への備えは、静かに止まる自動処理を防ぐ — Gemini 基盤変更に備える事前検証ゲートの設計にまとめています。

点検 5: 観測 — 「動いているか」を数字で言えるようにする

最後は観測です。Cloud Run は標準出力の JSON を構造化ログとして拾ってくれるので、Gemini 呼び出しの結果とトークン量を 1 行で吐くだけでも、運用の解像度が大きく変わります。

import json, time
 
def log_generation(model: str, resp, started: float) -> None:
    """Gemini 呼び出しごとに 1 行の構造化ログを出す。
    Cloud Logging 側で jsonPayload として検索・集計できる。"""
    usage = resp.usage_metadata
    print(json.dumps({
        "severity": "INFO",
        "message": "gemini_generation",
        "model": model,
        "input_tokens": usage.prompt_token_count,
        "output_tokens": usage.candidates_token_count,
        "latency_ms": int((time.time() - started) * 1000),
    }))

期待する出力はこのような 1 行です。

{"severity": "INFO", "message": "gemini_generation", "model": "gemini-flash-latest", "input_tokens": 412, "output_tokens": 380, "latency_ms": 2150}

このログがあると、「今月のトークン消費が先月比でどう動いたか」「レイテンシが悪化したのはいつからか」に数字で答えられます。個人開発では専任の監視役がいないぶん、ログベースの指標とアラートポリシーを先に仕込んでおくのが、結局いちばん安上がりだと感じています。私自身の運用では「5 分間のエラー率が 5% を超えたら通知」「p95 レイテンシが 10 秒を超えたら通知」の 2 本だけを入れ、予算アラートは月 3,000 円の 50% と 90% で通知するように設定しています。

点検リストのまとめと、引き継ぐか書き直すかの基準

ここまでの点検を、初期状態との対比で一覧にしておきます。

なお、この引き上げ作業を進める中で「これは引き継がず書き直したほうが早い」と判断する場合もあります。私はこの判断を 2 つの基準で行っていて、リクエストの境界（入力の検証と出力の整形）が読み取れないコード と、特定のプレビュー機能に依存していて代替が見えないコード は書き直します。逆に、多少冗長でも境界が読めるコードなら、上の手順で運用に引き上げてから少しずつ直すほうが、結果的に速く安定します。フルスクラッチで Cloud Run 上の Gemini API サーバーを設計する場合の構成は、Gemini 3.1 Pro × Cloud Run：サーバーレスAI APIの本番構築が参考になるはずです。

最初の 30 分でやる順番としては、次の 3 つをおすすめします。

1. gcloud run services describe で環境変数とアクセス設定を自分の目で確認する
2. API キーを Secret Manager 参照に差し替える（コードの変更は不要です）
3. 公開が必要になるまで --no-allow-unauthenticated で受け口を閉じる

ここまで進めば、残りの点検は落ち着いて取り組めます。同じようにプロトタイプの公開判断で迷っている方の、出発点になれば嬉しいです。