AI プロトタイプを本番環境に移行する前にすべてのスタートアップが答えておくべき 10 の質問

※この投稿は米国時間 2026 年 8 月 21 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud で AI を活用したスタートアップを立ち上げることが、これまでになく簡単になっています。

朝食時に Google AI Studio から API キーを取得し、それを Antigravity に貼り付ければ、昼食時には製品のプロトタイプができ始めているでしょう。

しかし、進歩の道のりは一直線ではありません。スタックを構築する際に、次の 3 つの課題に直面することがよくあります。

• API キーが漏洩し、48 時間で高額な請求が発生する。

• AI Studio から Gemini Enterprise Agent Platform への移行を急いで進めたが、チームに Identity and Access Management（IAM）の担当者がいないため、ロードマップが数週間停滞する。

• リリースは成功したが、プロジェクトごとのデフォルトの割り当てが原因でアプリが「HTTP 429 Too Many Requests」を返すようになり、追加料金を支払わずに容量を増やす明確な方法がない。

これらはどれも特殊なエッジケースではありません。​これらは、計画なしに急いで行動して失敗に陥ってしまうパターンであり、誰もが一度は経験したことがあるでしょう。

ここでは、スタートアップが事業を拡大する前に答えられるようにしておくべき 10 の質問を紹介します。これらの質問を、意思決定が将来を左右する 3 つのフェーズに分類しています。

1. オンボーディング（独自のプロジェクトと ID を適切に設定する）

2. スケール（費用をかけずにスループットを高める）

3. 管理（費用、キー、エージェントの暴走を防ぐ）。

これらの 10 の質問は、プロトタイプから本番環境への移行そのものを対象としています。各質問の最後には、すぐに実行できる短いスニペットが用意されています。このスニペットは、ご自身のプロジェクトにコピーして使用できます。その移行に特有ではない周辺的な意思決定（データレイヤと RAG アーキテクチャ、CI / CD、ネットワーク設計など）については、同様に重要ですが、ここでは意図的に対象外としています。

オンボーディング: 基礎を固める（ごく初期の段階）。

#1 Google AI Studio と Gemini Enterprise Agent Platform のどちらから始めればよいですか？

どちらのサーフェスも同じ Gemini ファミリーのモデルを提供しますが、解決する問題は異なります。

• Google AI Studio（Gemini Developer API を使用）は、アイデアから実際に動作するコードへと至る最短経路となります。ブラウザ IDE、API キー、豊富な無料枠が用意されており、クラウド プロジェクトを構成する必要はありません。ほとんどのアイデアはここから始めるべきであり、Google のガイダンスでもそのように推奨されています。

• Gemini Enterprise Agent Platform （旧称 Vertex AI）は、同じ Gemini モデル（サードパーティ製と OSS のモデルも含む）に加えて、企業向けの管理機能を備えています。具体的には、未加工のキーに代わる IAM とサービス アカウントによる認証、VPC Service Controls、Cloud Logging と Cloud Monitoring、予約済み容量、リージョン エンドポイント、そして最初の企業顧客によるセキュリティ審査で問われるコンプライアンス サーフェスです。

ほとんどのスタートアップにとっての正解は、両方を意図した順序で行うことです。まず AI Studio でプロトタイプを作成し、その後、実際のユーザーに提供する前に移行します。スタートアップにとって危険なのは、これらを交換可能なソリューションとして扱うことです。AI Studio のシンプルなキーモデルは企業向けの管理機能に適したものではなく、Agent Platform の IAM モデルは、認証情報が盗まれる被害から保護されていることを実感するまで、過剰なものに見えるかもしれません。

実際には、思ったより手間はかかりません。

統合された google-genai SDK は、両方を対象としています。

#2 IAM のエキスパートがいない場合に Google Cloud プロジェクトを設定するにはどうすればよいですか？

スタートアップが Agent Platform への移行を躊躇する最大の理由は、コードではなく、API キーを 1 つ用意するだけの運用から、フォルダ、サービス アカウント、組織のポリシー、ロギング、IAM バインディングを備えたクラウド プロジェクトに移行するという、運用上の大きな変化です。チームに専任のクラウド管理者がいない場合、最初のプロジェクトのセットアップに 1 週間分のエンジニアリング時間がかかることがあります。

3 つのステップで、この時間を大幅に短縮できます。

1. コンソールを操作する代わりに、独自の設計思想が反映されたプロジェクト テンプレートを使用する。クラウド設定のチェックリストと Google Cloud アーキテクチャ フレームワークを使用すると、本番環境レベルのフォルダ階層（prod / non-prod / dev）、一元的なロギングとモニタリングのプロジェクト、Security Command Center の有効化、ベースライン組織ポリシーが提供されるため、これらをゼロから設計する必要はありません。

2. 実際に使用する API を一度有効にする必要なときにプロジェクトごとに実行しなくても済むように、バッチ処理します。請求先のリンクの手順は省略できません。これから有効にしようとしている有料 API は、請求先アカウントが関連付けられていないプロジェクトでは有効にできないため、まずはその設定を行います。

3. Gemini にロールを選択させますが、限定的なロールをリクエストします。ロールのリファレンスを覚える必要はありません。アクセス権を付与するダイアログで [推奨ロールの表示] を使用すると、平易な言葉でタスクを説明できます（「このサービス アカウントは Gemini モデルを呼び出し、1 つの Cloud Storage バケットを読み取る必要があります」など）。すると、その理由とともに事前定義ロールが返されます。初日に知っておくべき注意点が 1 つあります。デフォルトでは、一般的なユースケースをカバーするロールが提案されます。通常は、サービスの管理者、編集者、閲覧者のロールです。これらは、必要以上に広い権限を持っています。プロンプトで「最小権限」または「最小限のアクセス」と指定すると、代わりに詳細なロールが返されます。入力する量は同じですが、認証情報が漏洩した場合の影響範囲は大幅に小さくなります。出典: Gemini のアシスト機能を使用して事前定義ロールの候補を取得する

出典: gcloud services enable リファレンス、gcloud billing projects link（GA）、GE Agent Platform 環境の設定。

単独の創業者である場合は、個人の GCP アカウントで構築しないようにしてください。適切な組織または自己所有の組織を最初に作成し、その内部ににプロジェクトを作成します。この 1 つの決定により、IAM から請求、監査まで、その他すべての作業が大幅に簡素化されます。

#3 Google Cloud を使用しています。コードの認証には、API キー、サービス アカウント、ユーザー認証情報のどれを使用すればよいですか？

この問題には安全性の階層があり、最も簡単なオプションが本番環境において適切なオプションであることは稀です。

• 未加工の API キーは、ローカルでのプロトタイピングには適しています。これは、有効期間が長く、クライアント バンドルや公開リポジトリに漏洩しやすく、それに気づくまで無制限のアクセスを許可してしまうため、本番環境では危険です。

• OAuth によるユーザー認証情報（アプリケーションのデフォルト認証情報）は、対話型ツール、CLI のほか、デベロッパーのノートパソコンで実行されるコードに最適です。

• サーバー、コンテナ、スケジュールされたジョブで実行されるものには、最小権限の IAM ロールを持つサービス アカウントが適しています。

目指すべきパターンは、コードが鍵をまったく認識しないパターンです。Google Auth ライブラリを呼び出すだけで、環境からアプリケーションのデフォルト認証情報（ADC）が読み取られます。これは、Cloud Run サービス、GKE ワークロード、または Compute Engine VM にアタッチされているサービス アカウントに対して発行された有効期間の短いトークンです。認証コードを記述しなくても、エンタープライズ グレードの認証を利用できます。

最後に、今後に備えて、そのサービス アカウントに、ワークロードが実際に必要とする最小限の IAM ロールを付与します。通常は、より広範な管理者ロールではなく、モデルを呼び出すための roles/aiplatform.user にします。30 秒ほど余分に時間がかかりますが、認証情報が漏洩したとしても、それがマスターキーになるのを防ぐことができます。

#4 AI Studio の API キーから Agent Platform の IAM モデルへの移行は、いつまで引き延ばせますか？

思っているよりも早く対応すべきです。正しいトリガーは、実害が出たときではありません。次のいずれかに該当する場合です。

• キーがノートパソコンから流出した（リポジトリにチェックインした、Slack に貼り付けた、モバイルアプリに組み込んだ）。

• チームに API を呼び出す必要がある人が複数いる。

• 1 か月あたり数百ドル以上を費やしている。

• 有料ユーザーのオンボーディングが間近に迫っている。

成長中のスタートアップが不意を突かれる可能性のある落とし穴は、単純なものです。たとえば、通常は月額 180 ドルを支払っているアカウントの Gemini API キーが公開リポジトリから漏洩し、蒸留攻撃に悪用されるケースです。この場合、所有者が最初の請求アラートを確認する前に、数万ドルの料金が累積してしまいます。Google Cloud の責任の共有モデルは明確です。お客様は、有効な認証情報を使用して発生した料金について責任を負います。

移行自体は、移行に対する不安よりもはるかに小規模なものです。google-genai では、#1 に示す 2 行の変更です。実際に時間がかかるのは、それに伴うプロジェクトのセットアップです。まさにそのために 2 が存在します。

カットオーバー日の実用的なチェックリスト:

ステップ 3 でレスポンスが出力された場合は、Agent Platform を使用しています。

スケール: 追加料金を支払うことなく容量を増やす。

#5 リリースしたのに、HTTP 429 エラーが頻発しています。これを解消するにはどうすればよいですか？

Agent Platform からの「429 Too Many Requests」はほとんどの場合、次の 2 つのいずれかを意味します。

1. プロジェクトの階層の動的共有割り当て（DSQ）の上限に達した場合。DSQ は、プロジェクトの履歴に基づいてサイズが設定される共有プールです。プラットフォーム全体での不正使用を防ぐため、新しいプロジェクトは設計上、控えめな上限から始まります。

2. 世界的に需要が急増しているときに、グローバル エンドポイントを呼び出し、共有容量をめぐって世界中のトラフィックと競合している場合。

対策としてすぐ思いつくのは、割り当て増加のチケットを送信することです。必要であればそうすることもできますが、通常は 2 つのアーキテクチャ上の変更で、より迅速かつ安価に問題を解決できます。

リージョン エンドポイントに固定する。Agent Platform でのスタートアップ トラフィックの半分以上は、デフォルトでグローバル ルーティングに設定されています。特定のリージョン（us-central1 など）に固定すると、グローバルな競合を回避でき、通常はレイテンシも改善されます（次の質問で説明しますが、1 つだけ例外があります。Priority PayGo を特に希望される場合、この機能は現在グローバル エンドポイントでのみ提供されています。それ以外の場合は、リージョンに固定します）。

適切な再試行とバックオフを追加する。429 は再試行可能なシグナルであり、致命的なエラーではありません。本番環境のクライアントには、ジッターを伴う指数バックオフが必要です。最新の google-genai SDK には、この動作が組み込まれていますが、実際に有効にした場合にのみ機能します。これは見落としがちです。古い Vertex コードで見たことがあるかもしれませんが、従来の `google.api_core.retry.if_transient_error` デコレータは使用しないでください。これは従来の例外クラス向けに設計されており、新しい `google.genai.errors.APIError` を認識しないため、429 エラーを再試行せずに無視します。代わりに、SDK の組み込みの再試行オプションを使用します。

この状況をどのように予測しますか？できれば、ユーザーから報告を受ける形ではなく。Agent Platform はサービング指標を Cloud Monitoring に公開します。また、[コンソール] > [Agent Platform] > [ダッシュボード] > [モデルのオブザーバビリティ] に、アセンブル不要の事前構築済みダッシュボードがあります。1 秒あたりのリクエスト数、トークン スループット、最初のトークンのレイテンシ、エラー率をすぐに確認できます。

実際にアラートを生成する指標は aiplatform.googleapis.com/publisher/online_serving/model_invocation_count です。error_category ラベルが付き、値は user、system、capacity のいずれかになります。capacityに関するアラートは、自分自身の間違ったリクエストから実際のスロットリングを分離します。これは、未加工の 429 エラーのカウントでは行われません。

注意すべき点として、Standard PayGo では「使用量が割り当ての 80% に達したら警告して」というアラートを作成できません。動的共有割り当てでは、80% を限度とする、プロジェクトごとの固定値はありません。429 エラーは、共有容量の一時的な競合を意味し、限度を超えたことを意味するものではありません。割合を上限とするアラートは、実際の上限指標が提供されるプロビジョンド スループットを使用している場合にのみ意味を持ちます。

出典: Agent Platform の指標リスト、モデルのオブザーバビリティ ダッシュボード、RetryOptions のソース、コア retry_base.py、genai errors.py、429 エラーの削減、gcloud monitoring policies create、動的共有割り当て。

Agent Platform のレート制限に関するドキュメントに沿って、プロジェクトの現在の上限が実際にどの程度であるかを把握してから、上限を超えているかどうかを判断してください。

#6 Standard PayGo、Priority PayGo、プロビジョンド スループットのうち、どの消費モデルを利用すればよいですか。

3 つの消費モデルは、ワークロードの形態も進め方もまったく異なります。適切なものを選択することで、スタートアップは AI の請求額を大幅に削減できます。まず、それぞれの定義を確認し、どのような場合に適しているか、または適していないかを見ていきましょう。

Standard PayGo（DSQ）: 共有プールからのトークン単位の課金。低価格、保証なし。Priority PayGo: トークン単位の課金、プレミアム料金のためキューをスキップ可能。プロビジョンド スループット（PT）: 予約済み容量を前払い。予測可能、使用しないと無効。

スタートアップによくある間違いは、PT を早すぎる時期に購入することです。特に、大規模なリリースの翌週、トラフィックが増加する一方のように感じられるときに、こうした間違いが起きます。PT は予約済みの容量です。使用するかどうかにかかわらず料金を支払う必要があり、ベースラインが単なる願望ではなく、真に予測可能になった場合にのみ、元が取れるようになります。

実用的な手順は次のとおりです。

1. Standard PayGo の第 1～4 週。これを使用して、実際のリクエストの形態（p50 と p99 での 1 分あたりのトークン数、リクエストのバースト、バッチ処理可能とリアルタイム処理の内訳）を測定します。

2. 初めて 429 エラーが大量に発生したときは、実際に重要なトラフィックに対して Priority PayGo を有効にします。これは構成の変更であり、注文書ではないため、調達部門の担当者は関与する必要はありません。

3. ベースラインの TPM を予測できるようになったら、PT を購入してフラット ベースラインをカバーし、ベースラインを超える分は PayGo にオーバーフローします。これが、Google が推奨する組み合わせパターンであり、まったく理にかなったものです。単なる宣伝文句ではなく、両方の利点を活かしています。

 出典: Priority PayGo のドキュメント、google-genai HttpOptions のソース、GEAP REST リファレンス。

#7 どのリクエストをライブにして、どのリクエストをバッチジョブにする必要がありますか？

スタートアップのワークロードのほとんどは、リアルタイムを装ったバッチジョブであることが実態です。ジョブをインタラクティブなパスから外すたびに、本当に高速であることが必要なトラフィック、つまりユーザーが実際にスピナーを見つめているトラフィックのために DSQ のヘッドルームが解放されます。

トラフィックを分類するのに役立つ 3 つの質問:

• ユーザーが 1 秒以内に結果を確認する必要がありますか？この場合は、ライブ推論です。

• ユーザーはスピナーを見ながら数秒間待つことができますか？この場合もライブですが、ストリーミングの候補でもあります。

• ユーザーは「準備が整い次第メールでお知らせします」または「しばらくしてからもう一度ご確認ください」というメッセージを許容できますか？この場合は、バッチ予測です。

Agent Platform でのバッチ予測は完全に独立したキューで実行され、インタラクティブな DSQ を消費しません。また、通常はオンデマンド推論の半額程度です。これは、ライブ トラフィックの高速化と費用の削減という二重のメリットをもたらす、まれな例です。

一般的な候補: 夜間のドキュメント要約、新規登録者のバックグラウンド分類、一括翻訳、エンベディングのバックフィル、テストセットに対する評価実行。これらのいずれかが現在のライブパスにあれば、通常、それらを移動することが、今週できる最も効果的な変更となります。

管理: 費用、鍵、エージェントを管理する。

#8 請求額が 3 倍になっても丁寧なメールが届くだけでなく、実際に費用を削減できる利用額上限を設定するにはどうすればよいですか？

正直なところ、最近まで予算は通知するだけで、ブレーキペダルは自分で作る必要がありました。7 月にこの状況が変わりました。メカニズムは 3 つあり、これらはレイヤとして考えることができます。

1. 利用額上限の予算（プレビュー）。Cloud Billing の予算で、メール通知だけでなく、強制的な適用が可能になりました。プロジェクトに利用額上限を設定すると、使用料金が予算の 100% を超えた時点で、Google はサービスを一時停止します。サービスを再開するには、手動で一時停止を解除する必要があります。Gemini API、Cloud Run、Cloud Run Functions とともに、Agent Platform が対象リストに明示的に記載されています。アラートは 50% と 80% で引き続き発生するため、予告もなく一時停止になるわけではありません。

利用する前に知っておくべき 3 つのこと:

• 各上限は、1 つのプロジェクトと 1 つの対象サービスに適用されます。アカウント全体の保護ではありません。Agent Platform と Cloud Run の両方に上限を設定する場合は、2 つの上限を設定することになります。

• 適用は即時ではなく、推定費用に基づきます。上限を超えた分は通常どおり請求されるため、実際の予算上限よりも低い数値を設定してください。上限の解除は手動で行われ、サービスの再開には最長で 1 時間かかることがあります。また、プロビジョンド スループットの使用も一時停止されるため、容量を前払いしている場合は、上限に達するとその容量も使えなくなります。

• 公開時点ではプレビュー版であり、対象サービスのリストは今後増えていくことが記載されています。設計する前に、現在のリストを確認してください。

2. 課金を無効にする Pub/Sub トリガーによる予算設定。利用額上限では対応できない、広範な影響範囲（複数のサービスの一括設定、プロジェクト全体、まだ対象になっていないサービスなど）が必要な場合は、依然として適切なツールです。予算がしきい値に達すると、Pub/Sub が Cloud Functions の関数を起動して請求先アカウントを切り離し、数分以内にすべての課金対象アクティビティを停止します。ネイティブの上限よりも大雑把で危険です。リソースが回復不能になる可能性があるため、最初にではなく、2 番目に試みてください。詳細なチュートリアル: 予算通知に自動的に応答する。

出典: 利用額上限の予算を管理する、プログラムによる通知を設定する、gcloud billing budgets create リファレンス、Cloud Billing の予算のコンセプト、通知で課金を無効にするチュートリアル、プログラムによる通知のペイロード スキーマ。

デフォルト設定が予期しない問題を引き起こす可能性があるため、事前に対応すべきことが 2 つあります。

1. 予算の範囲を制限する: --filter-projects を使用しない場合、予算は請求先アカウント全体に適用されます。いずれかのプロジェクトで急増が発生すると、すべてのキルスイッチがトリガーされます。

2. ローカルにデプロイする: 予算通知では、影響を受けるプロジェクトが指定されていません。キルスイッチが目的のプロジェクトにのみ影響するように、保護するプロジェクト（my-startup-prod など）と同じプロジェクトに Cloud Functions の関数をデプロイします。

次に、そのトピックに小さな Cloud Functions の関数を接続し、100% のしきい値に達したときに projects.updateBillingInfo を呼び出して請求先アカウントのリンクを解除します。これが、回路ブレーカーの役割を果たします。

割り当てのオーバーライドによる機械的な上限。上記のキルスイッチを設定しなくても、プラットフォームのデフォルトを下回る、モデルごと、リージョンごとの割り当てを明示的に設定することで、費用が累積するレートに上限を設けることができます。アプリの本来の用途において gemini-2.5-pro に対する 1 分あたりのリクエスト数が 500 を超えることがない場合は、Cloud Quotas コンソールで上限を 500 に設定します。割り当てによってサービスが拒否されるため、キーが漏洩してもリソースが消費されることはありません。

#9 シークレットはどこに保存すべきですか？（.env ファイルではありません）

簡潔に言うと、Secret Manager です。環境変数、.env ファイル、リポジトリのいずれにも保存しないでください。IAM を介して、読み取りアクセス権を、そのアクセス権を必要とするサービス アカウントにのみ付与します。

次に、2 つのちょっとした習慣を紹介します。これらは、いざ必要になったときにその価値がわかります。

• 定期的なローテーションと、疑いがあるときのローテーション。Secret Manager のバージョンは安価です。既存のバージョンを書き換えずに、ロール フォワードしてください。

• シークレットが漏洩したときの検出。Secret Manager の通知と Google Cloud のSensitive Data Protectionにより、攻撃者に先んじて、リポジトリにチェックインされたキーやログストリームに貼り付けられたキーを捕捉できます。

ユーザーに代わって動作する AI アプリケーション（ユーザーに代わって Gmail を呼び出す、ドライブのフォルダを読み取る、ユーザーの認証情報を使用してサードパーティの SaaS にアクセスするなど）には、有効期間の長いトークンを保存しないでください。有効期間の短いアクセス トークンと更新フローとともに OAuth 2.0 を使用します。これにより、ユーザーが突然退職した場合や、不正使用されたアカウントが取り消された場合、エージェントは同時にアクセス権を失います。

#10 新しい AI エージェントが、決してすべきではないことをしないようにするにはどうすればよいでしょうか？

ツールの呼び出し、ウェブの閲覧、コードの実行が可能なエージェントには、他のあらゆる本番環境サービスと同様の、あるいはそれ以上に「多層防御」の考え方が求められます。なぜなら、そうしたエージェントは、ユーザーにとってもモデルにとっても事前に完全には予測できないような判断を下すからです。

4 つのレイヤがあり、実際のユーザーがいる場合は、どれも省略できません。

1. エージェント自体の ID。エージェントに独自のサービス アカウントを付与し、本当に必要なリソースとツールのみにスコープを限定します。これは、他のワークロードと同じ最小権限の原則です。Agent Engine はファースト クラスのエージェント ID をサポートしているため、監査ログですべてのアクションを特定のエージェント インスタンスに関連付けることができます。

2. サンドボックス化されたコード実行。エージェントが生成されたコードを実行する場合（データ分析や「この Python を実行して」のフローにおける一般的なパターン）、アプリケーション プロセスで実行しないでください。隔離されたサンドボックスを使用することで、不適切な組み合わせが本番環境データに影響を与えないようにします。

3. プロンプトと回答のフィルタリング。Model Armor は、モデル呼び出しの手前に配置され、プロンプト インジェクション、ジェイルブレイク、機密データの引き出し、ブランドにそぐわない出力をスクリーニングします。これらはすべて、実際のユーザーが使い始めれば、実質的に避けられないものとなります。

4. 行動のモニタリング。脅威検出機能を備えた Security Command Center は、エージェントの動作における異常にフラグを立てます。たとえば、サービス アカウントがこれまで使用したことのない API を突然呼び出す、エージェントが未知の外部ホストにアクセスする、特権操作が予期せず急増する、といったことです。これは、ほぼリアルタイムで行われます。

エージェントが実際のユーザーに代わって行動したり、実際のお金を扱ったりするようになると、これらはどれも省略できなくなります。

いわば宿題として

1. リポジトリ、ノートブック、本番環境ランタイムで、未加工の API キーを監査します。そこにあるべきでないキーをローテーションします。

2. 同期レスポンスを必要としないワークロードは、Batch API に移行します。

3. モデルのオブザーバビリティ ダッシュボードを有効にして、容量エラーに関するアラートを 1 つ設定し、次の 429 エラーが顧客より前に自分に届くようにします。

4. プロジェクトの利用額上限を設定し、50% と 80% のアラートに注意します。使用量が予算の 100% を超えると、手動で解除するまで、Google はサービスを一時停止します。

今週この 4 つの事項を実施すれば、AI 機能をリリースしているほとんどのスタートアップよりも先を行くことができます。

次回取り上げてほしいシナリオはありますか？Google Cloud for Startups までお問い合わせください。

- Google Cloud AI、テクニカル ソリューション、Sergio Villani