Google AI Studioで作ったWebアプリやLPのプレビューが動くと、「他の人にもURLを渡して触ってもらいたい」と思いますよね。その公開先としてよく使われるのが、Google Cloudのサーバーレス環境「Cloud Run」です。
AI Studioで作ったアプリを外部に公開するなら、Cloud Runを利用できます。 公開前に、共有リンクで足りるか、Starter Tierの対象か、通常デプロイで何に費用が生じるかを確認しましょう。相手に見せる方法と、アクセス範囲・API費用の負担は、分けて考える必要があります。
この記事は、私が以前実際にCloud Runへ公開した際の記録をベースに、2026年10月21日時点で確認した公式情報や仕様を整理して補ったものです。当時の画面例も振り返りながら、予期せぬ請求に焦らないための判断ポイントをお伝えします。
共有リンクで見せるか、Cloud Runで公開するかを決める
画面上にある「Share」と「Deploy(またはPublish)」は、どちらも人に渡せそうに見えますが、役割はまったく異なります。ボタンの名前だけで選ばず、「相手に何を見せたいか」「誰のアカウントや費用で動かすか」という目的で選びましょう。
| 比較項目 | AI Studio内の共有(Share) | Cloud Runへの公開(Publish / Deploy) |
|---|---|---|
| 主な利用場所 | AI Studioの画面内 | 一般のWebブラウザ |
| 相手に渡すもの | AI Studioのプロジェクト共有URL | 独立したWebサイトのURL(run.appなど) |
| コードの閲覧・複製 | 相手がコードを閲覧・複製(fork)可能 | アプリの操作画面。ブラウザへ配信するHTML・JavaScript等は閲覧できる |
| Gemini API利用の負担 | 共有元の利用枠に計上。有料モデルなら費用が生じ得る | 公開アプリが使うAPIキーの所属プロジェクト側 |
| 主に管理する対象 | AI Studio内の共有範囲 | Cloud Runサービス、プロジェクト、課金設定 |
公式ドキュメント(Build apps in Google AI Studio)によると、AI Studio内で共有した場合、相手はアプリのコードを閲覧したり自分の環境へ複製(fork)したりできます。共有アプリからのAPI呼び出しも共有元の利用枠に計上され、有料モデルでは費用が生じ得ます。コードを見せてよい相手か、利用量を把握できるかを確認してから共有しましょう。
一方、Cloud Runはコンテナ化したアプリをサーバー管理なしで動かせる実行環境です。公開アクセスの公式ドキュメントにある通り、URLを発行して外部から直接Webアプリとして動かせるようになります。ただし、URLを発行したからといってアクセス範囲や安全性が自動的に保証されるわけではありません。
コードを見せ合って相談したいだけなら「共有」、独立したWebサービスとして一般の人に動かしてもらいたいなら「Cloud Run公開」を検討しましょう。
公開前に、自分の公開経路と管理する場所を確認する
Starter Tierと通常デプロイの条件
AI Studioからのデプロイには、全員一律の手順ではなく複数の経路があります。公式ガイド(Deploying from Google AI Studio)では、手軽なお試し環境である「Starter Tier」と、通常の「Google Cloudデプロイ」が案内されています。
- Starter Tier:対象のアカウントであれば、Google Cloudの請求先(クレジットカードなど)を自分で設定していなくても、最大2アプリまで公開できる枠です。Google Cloud Starter Tierの仕様によると、裏側ではGoogleが管理する専用プロジェクトで動作し、リージョンや利用できるリソースが厳格に管理されています。
- 対象外になり得る条件:Google Workspaceアカウント、過去または現在の有料Google Cloud請求先アカウントの保有状況、アカウントの利用履歴などによって利用できない場合があります。自分の画面で案内される対象条件を確認してください。
Starter Tierの対象外であれば、通常のGoogle Cloudプロジェクトと請求先を連携して公開するか、管理しきれない場合は公開を見送る判断が必要です。
プロジェクト・リージョン・公開範囲を控える
通常のGoogle Cloudプロジェクトへデプロイする場合は、作業前に以下の項目を控えておきましょう。
- プロジェクトID:どのプロジェクトで動かすか(プロジェクト管理の公式ドキュメントにある通り、意図したプロジェクトを選びます)。
- 紐づく請求先アカウント:費用が発生した際にどの請求先から支払われるか。
- デプロイ先のリージョン:東京(asia-northeast1)や大阪(asia-northeast2)など、アプリを動かす地理的拠点(Cloud Runのロケーション一覧)。
- 呼び出すAPIとモデル:現在使っているモデル名と、そのAPIキーが属するプロジェクト。Cloud Runのプロジェクトと異なる場合は、API側の請求先も確認します。キーの値そのものを共有メモへ書く必要はありません。
- 公開範囲(認証):インターネット全体に開く一般公開か、認証を必要とするか。
- Cloud Runのサービス名:公開後に料金や停止対象を探せるよう、作成されたサービス名とURLも控えます。
誰でもアクセスできる一般公開にする場合、公開アクセスの公式ドキュメントでは「起動元(Invoker)のIAMチェックを無効にする」か、未認証ユーザー(allUsers)に「Cloud Run 起動元(run.invoker)」ロールを付与する手順が示されています。Webアプリ独自のログイン機能とインフラ層のアクセス権限は別物ですので、誰に開かれているかを把握しておく必要があります。

現在の入口は、アプリをBuild modeで開いた画面の右上にある「Publish」です。公式の公開ガイドでは、Starter Tierは「Publish → Get Started → Publish App」と案内されています。通常デプロイでは、公式の操作例(Codelabs)にプロジェクトの選択・インポートと、完了後のApp URL確認が載っています。費用と公開範囲を確認したうえで、自分に表示される経路を進めます。
上記画像は私が以前操作した当時の画面です。今回の案内は公式資料の確認に基づくもので、最新画面で再デプロイを試した記録ではありません。ボタン名や表示内容は現在の画面と見比べてくださいね。
費用はアプリの実行・準備・保存・AI利用で分ける
「アクセスが少ないから無料枠で収まるはず」と考えてしまいがちですが、Webアプリの運用にはCloud Runの実行以外にも複数のサービスが関わっています。
Cloud Runの無料枠で分かること・分からないこと
Cloud Runの料金公式ドキュメントによると、リクエスト単位(request-based)の課金方式には毎月以下の無料枠が用意されています。
- リクエスト数:月200万回
- vCPU時間:月180,000 vCPU秒
- メモリ使用量×時間:月360,000 GiB秒
- 外向きデータ転送量:月1 GiB(北米内の転送という条件付き。他地域への転送は料金条件を別に確認)
ただし、この無料枠を見る際には注意が必要です。 CPU・メモリ・リクエストの無料分はus-central1の料金を基準とし、Tier 1価格による金額割引として適用されます。同じ請求先アカウントに紐づく全プロジェクトで合算され、実際の料金はリージョンによっても異なります。また、「月間6,000PVだから0円」と断定することはできません。1回のリクエストで何秒処理がかかるか、メモリをどれだけ使うか、通信量がどれくらいかによって消費量は大きく変わるからです。
自分のサービスがrequest-basedか、起動している間に課金されるinstance-basedかも確認しましょう。アクセスがなくてもインスタンスを維持する最小インスタンス数を設定している場合には、待機中の料金も関係します。課金方式の公式説明と実際の設定を見比べると、何に対して料金が発生するかを追いやすくなります。
ビルド・イメージ保存・ログ・Gemini APIは別に確認する
公開時には、実行環境以外にも以下の費目が発生し得ます。
| サービス・費目 | 発生する内容 | 公式の料金案内 |
|---|---|---|
| Cloud Run | コンテナのリクエスト処理時間・リソース | Cloud Run pricing |
| Cloud Build | アプリのビルド時間(コンテナ作成) | Cloud Build pricing(月2,500分の無料枠は特定マシンのプロモーション条件あり) |
| Artifact Registry | ビルドされたコンテナイメージの保管 | Artifact Registry pricing(月0.5GiB相当まで無料、共有枠) |
| Cloud Logging | アクセスログやエラーログの保管 | Cloud Logging pricing(一般ログの保存はプロジェクトあたり月50GiBまで無料。種類や保持期間に別条件あり) |
| Gemini API | モデル呼び出し時のトークン量に応じた利用料 | Gemini API pricing |
| Secret Manager | (利用時)APIキーなどの機密情報の保管 | Secret Manager pricing |
データベースやログインを追加したアプリでは、そのサービスも確認対象です。FirestoreやFirebase Authenticationなどは、使っている場合だけ構成と料金を確認します。すべてのアプリに必須というわけではありません。
特に注意したいのがGemini APIの費用です。
公式ドキュメント(Build apps in Google AI Studio)によると、現在のAI StudioのWebアプリではGemini APIキーをサーバー側のsecretとして扱います。ただし、以前に作ったアプリや自分で変更したコードも同じ状態かは別途確認が必要です。手動でCloud Runを管理する場合、環境変数の公式ガイドはAPIキーなどの秘密情報にSecret Managerを推奨しています。単に環境変数へ書けば管理が完了する、という扱いは避けましょう。
公開アプリが所有者のAPIキーでGeminiを呼ぶ場合、利用はそのキーが属するプロジェクトの利用枠や請求へ計上されます。キーをサーバー側で保管していても、アプリを使う人が増えればAPI使用量は増えます。有料利用か、どのモデルを何回呼ぶかまで含めて確認しましょう。
予算通知・インスタンス数・支出上限は効く範囲が違う
想定外の支出を防ぐための対策にはいくつか種類がありますが、それぞれ「止める対象」が異なります。1つの設定だけで全体を完全に制限できるわけではありません。
| 対策機能 | 止まるもの | 止まらないもの・注意点 | 公式案内 |
|---|---|---|---|
| 予算アラート | なし(メール等で通知するのみ) | 自動では停止しない。利用費の計上と通知に遅延があり、初回通知に数時間かかる場合もある | Budgets and budget alerts |
| 最大インスタンス数の制限 | Cloud Runの最大同時起動台数 | 短時間のスケール超過があり得る。Gemini APIの累計利用回数は止まらない | Set maximum instances |
| Cloud Billingの支出上限予算(spend cap) | Cloud RunやGemini APIなど、指定した対象サービスの新しい利用 | 単一プロジェクト×単一サービスの月次設定。割引・クレジットを引く前の概算費用で判定。即時停止ではなく超過分も請求され、対象外費目は残る。翌月は自動再開 | Manage spend cap budgets |
| Gemini API側の支出上限 | 対象範囲のGemini API利用 | project単位の設定は実験的。請求先のtier上限は複数projectを合算。約10分の計上遅延や長い処理による超過があり、Cloud Run・保存費用は対象外 | Gemini API Billing |
| Gemini APIの前払い(Prepay) | 請求先のAPI残高が0になると、その請求先に紐づくAPIキーの利用が停止 | 利用できるプランかを確認。自動チャージ(auto-reload)が有効なら残高が補充される。計上遅延による超過があり、前払い残高は通常のCloud費用には使えない | Gemini API Billing |
| (参考)APIレート制限 | 1分あたりのリクエスト数やトークン数 | 短時間のスパイクを抑える速度制限であり、月間の累計金額を制限するものではない | Gemini API rate limits |
個人の検証やデモ公開であれば、予期せぬ大量アクセスでサーバー台数が跳ね上がらないよう、Cloud Runの最大インスタンス数を「1」などの小さな値に抑えておくのが一つの目安になります(ただし「1台なら絶対に安全・無料」という意味ではありません)。

また、予算アラートは「通知が来たら自分で気づいて止めに行くための仕組み」として、無理のない金額(例:500円など)で設定しておきましょう。
通常デプロイでは、Google Cloudコンソールの「Billing(お支払い)→ Budgets & alerts(予算とアラート)」で対象プロジェクト・サービス・通知先を確認します。API側はAI StudioのBillingで前払い/後払いと自動チャージ、Spendで上限設定を確認するのが入口です。Cloud RunとAPIが別プロジェクトなら、それぞれを確かめてください。

公開後の確認と、使い終わったときの止め方
公開URL・認証・費目を確認する
公開が完了したら、一般公開なのか、認証した人向けなのかという意図どおりのアクセス範囲になっているかを確認します。あわせてGoogle CloudコンソールやGemini APIの管理画面で、利用状況と費目を確認しましょう。
なお、クラウドの請求情報や利用統計の反映にはタイムラグがあります。「まだURLを誰にも配っていないから」「ブラウザのタブを閉じたから」と安心せず、管理画面で実際のステータスを確かめることが重要です。
非公開化・手動0・削除で残るものを比べる
アプリの利用が終わったら、再開する予定があるか、サービスを片づけるかで止め方を選びましょう。公開を止める操作と、保存されたデータやイメージを削除する操作では、残るものが異なります。
| 停止・削除方法 | 止まるもの | 残るもの・注意点 | 公式案内 |
|---|---|---|---|
| AI StudioでUnpublish | Webアプリとしての公開状態 | 全関連資産の消去までは確認できないため、Cloud側にも残るリソースがないか確認する | 公式操作例 |
| 匿名公開を止めて認証を要求 | 設定に応じた未認証アクセス | Invoker IAM checkが無効なら、allUsers権限を外すだけでは止まらない。チェックの有効化と権限を確認する。サービスや保存資産は残る | Allowing public access |
| 手動でインスタンス数を0にする | 後続のリクエスト受付 | 手動スケーリングの「Number of instances」を0にする。自動スケーリングの最大数0とは別。処理中の要求や、タグURLのみで稼働するリビジョンには例外あり | Manual scaling |
| Cloud Runサービスを削除 | 対象サービスと全リビジョン | 取り消し不可。Artifact Registryのイメージなどは別に残る。同名・同リージョンで再作成すれば同じURLになる場合がある | Manage Cloud Run services |
| プロジェクトの課金を無効化 | 通常のGoogle Cloud有料サービス等 | 他のサービスへの影響や一部データの消失がある。FirebaseやGemini APIは無料プラン/無料枠へ移る場合があり、すべての利用を止める操作ではない。既発生費用の支払いは残る | Modify project billing |
| プロジェクトを削除 | 対象プロジェクトの利用 | 他サービス・データも対象。回復期間中でも早期に失われるデータがあり、当期の請求が続く場合への注意も記載されている | Delete projects |
再開しない単体のデモを終了するなら、Cloud Runサービスの削除が候補になります。その後は、コンテナイメージの保存先(Artifact Registry)や、別に使っていたAPI・データベースも確認してください。ほかのアプリと共有するプロジェクト全体の削除は、残したいサービスやデータがないかを確かめてから判断しましょう。
補足:独自ドメインとデータの学習利用について
- 独自ドメイン:Cloud Runでは標準の
xxxx.run.appドメインが割り当てられます。カスタムドメインの公式案内では、直接マッピングは限定提供のPreview機能で、本番用途には推奨されていません。ほかの方式には別の構成・費用が関わります。検証ならまず標準URLで足りるかを考えましょう。AI Studioが案内するai.studioのサブドメインは、自分が所有する独自ドメインとは別です。 - データの学習利用:Google Cloudサービス固有の規約と、呼び出し先のGemini API追加利用規約を分けて確認します。API規約のUnpaid Servicesでは入力や応答が製品改善の利用対象です。Paid Servicesでは製品改善に使わない一方、不正利用対策等のための限定的な保持があります。AI Studioは画面の利用料が無料でも、アクティブな請求先付きCloudプロジェクトへのアクセスやWorkspace enterpriseなどの条件でPaid扱いになります。Gemini APIは呼び出すプロジェクトの課金状態が基準です。アプリの置き場所だけで判断せず、使うサービスとアカウント条件を確認しましょう。
公開する前の確認チェックリスト
最後に、AI Studioからアプリを公開する前に確認しておきたいチェックリストをまとめました。
- 共有か外部公開か:AI Studio内の「Share」で足りないか? 独立したWebサイトとして不特定多数に動かしてもらう必要があるか?
- 公開経路の確認:請求先設定が不要なStarter Tierが使える対象か、それとも通常のGoogle Cloudデプロイか?
- 管理する場所:通常デプロイならプロジェクトと請求先を把握しているか? Starter TierならGoogleが管理する範囲と利用できる機能を確認したか?
- 認証とAPI費用の負担:誰でもアクセスできる状態か? 他人がWebアプリを経由して利用したGemini API費用を支払う準備があるか?
- 費用の範囲:通常デプロイなら実行・ビルド・保存・ログ・Gemini APIの各費目を把握しているか? Starter Tierなら基盤の無料利用範囲と、APIの利用条件を分けて確認したか?
- 支出対策と片づけ方法:通常デプロイなら最大インスタンス数・予算・利用できる上限機能を確認したか? 自分の経路で公開を終えるとき、何が残るかを理解しているか?
「請求先や費用の仕組みがよく分からない」「他人に使われたときのAPI費用を把握できない」という段階なら、まずは他人へ共有せず、自分だけで内容を確認しておく方法もあります。共有リンクを渡す場合も、有料モデルの利用やコードを見せる範囲は確かめてくださいね。
準備が整ったら、公式のDeploying from Google AI Studio ガイドを確認しながら、一歩ずつ進めてみてくださいね。

