BrainChain
Google AI Studio × Cloud Run × Firestoreで構築する、セキュアでスケールするマルチゲーム共通基盤の裏側
PT
PT
2026-05-18
プロトタイプ開発から実用プロダクトローンチへ。本記事では、Google AI Studioを起点とし、Cloud Run、Firestore、Firebase Authenticationといった最新のサーバーレス技術を統合した、高拡張性のマルチゲーム共通基盤の構築プロセスを徹底解説します。セキュリティ設計、コスト最適化、そして将来的なマイクロサービス化を見据えたアーキテクトの視点まで、初心者からベテランエンジニアまでが学ぶべき実践的な知見が満載です。

はじめに：なぜ今、Google AI Studioから始めるのか？

「AIにコードを書かせて、動いたらラッキー！」という、いわゆるVibe Coding（バイブ・コーディング）が世界的なトレンドになっています。しかし、趣味の試作から一歩踏み出し、実際にWeb上でユーザーに遊んでもらうプロダクトにするには、インフラの壁が立ちはだかります。

実は最近、Google AI Studioに「開発したプロトタイプをそのままGoogle CloudのCloud Runへデプロイ（パブリッシュ）できる」という激熱な新機能が追加されました。これを使えば、LLMのパワーを借りながら爆速でWebアプリケーションをローンチできます。

今回は、このAI Studioを起点に、コンテナ実行環境であるCloud Run、NO-SQLデータベースのFirebase Firestore、そして認証基盤のFirebase Authenticationを組み合わせ、実用的な「マルチゲーム共通基盤」を構築するためのアーキテクチャを徹底解説します。

1. サーバーレス三銃士を繋ぐ「プロジェクトID」という名の絶対王政

Webアプリケーションを一般公開するにあたり、バックエンド（Cloud Run）とデータベース（Firestore）の連携は必須です。ここで多くのエンジニアが「セキュアな通信設定」に頭を悩ませます。

結論から言うと、Google Cloudの世界では「プロジェクトID（プロジェクト名）」さえ統一しておけば、細かいネットワーク設定はGoogleが裏側で全部いい感じにカバーしてくれます。

Google AI Studioの管理画面（青ベース）、Google Cloudコンソール（青ベース）、Firebaseコンソール（オレンジベース）と、プロダクトごとに画面の色が違っていて一見別物に見えますが、これらはすべて同じ「Google Cloudプロジェクト」という大枠の中で動いています。

同じプロジェクトIDに紐付いてさえいれば、Cloud RunからFirestoreやAuthenticationへ、わざわざ面倒なコネクタを設定したり、アクセスキーを複雑に管理したりしなくても、安全かつ高速な内部通信が担保されるのです。これがGoogleエコシステムの最大の強みです。

2. お財布に優しすぎるサーバーレス：破産を避けるための料金システムとアラート戦略

「クラウドを使うと、予期せぬアクセス集中で破産するんじゃないか……」と夜も眠れない方に朗報です。今回紹介する構成はすべて「サーバーレス」プロダクトです。

サーバーレスの何が美味しいのか？ 従来のサーバー（VPC上の仮想マシンなど）は、誰もアクセスしていなくても24時間365日、起動しているだけでお金がかかります。 一方、Cloud RunやFirestoreは**「アクセスされた瞬間だけ起動し、処理が終われば勝手に眠る」**という仕組みです。

つまり、ユーザーが0人の時は、1円もかかりません。友達や身内で十数人、あるいは100人〜200人レベルで遊ぶ程度であれば、毎月付与される無料枠（300ドル分のクレジットや、各プロダクトの月間無料枠）の中で完全に収まります。実質0円運用も夢ではありません。

それでも心配な場合は、Google Cloudの課金設定から「予算アラート」を仕込んでおきましょう。 たとえば「月額5,000円」を基準に設定しておけば、25%、50%、75%を超えた段階でシステムがメールで悲鳴（通知）を上げてくれます。手遅れになる前に、人間が介入してサービスを一時停止するなどの対策が取れるため、安心して枕を高くして眠ることができます。

3. 実践：FirestoreとAuthenticationを手動で手なずける

AI Studioは強力ですが、さすがにFirebaseの初期設定（ポチポチとクリックする作業）までは代行してくれません。ここからは、インフラエンジニアとして人間が設定すべき具体的なステップを見ていきましょう。

① Firestoreの起動とConfigの取得

Firebaseコンソールで対象のプロジェクトを開き、「Firestoreデータベース」を作成します。リージョン（東京など）を選択し、テストモードで開始します。 次に、Firebaseに「Webアプリ」を追加します。すると、以下のようなJavaScriptのconfigオブジェクト（キー情報など）が発行されます。

const firebaseConfig = {
  apiKey: "AIzaSy...",
  authDomain: "your-app.firebaseapp.com",
  projectId: "your-project-id",
  storageBucket: "your-app.appspot.com",
  messagingSenderId: "...",
  appId: "..."
};

このConfig情報をGoogle AI Studio側のプロンプト、あるいは生成されたコードにペーストすることで、AIが作ったプログラムが正常にデータベースと通信できるようになります。

② Authentication（認証）のワンクリック有効化

ユーザーごとにデータを保存（メタルの残高やスコアの記録）したい場合、ユーザーの識別（認証）が必要です。 Firebase Authenticationの画面で「ログイン方法」を選び、「メール/パスワード」や「Googleログイン」を有効化します。これだけで、数万行規模のセキュアなログイン認証基盤があなたのアプリに実装されます。ログインしたユーザーには一意の「ユーザーID（UID）」が割り振られます。

** ※ つい最近のGoogle Cloud Next'26 Lasでは、Google AI Studio上、Cloud RunとFirebase連携などの噂がありましたが、より深くスマートな強化機能のリリースを期待しています。 **

4. アーキテクトの視点：1つのCloud Runにまとめるか、分けるべきか？

プロダクトがスケールしてくると、「すべてのゲームを1つのCloud Run（Webサイト）に詰め込むべきか、ゲームごとにCloud Runを分けるべきか」という問いに直面します。

Google CloudのProfessional Cloud Architectとしての見解を述べると、長期的には「ゲームごとにCloud Runを分ける（マイクロサービス化する）」のが圧倒的に正解です。

なぜ分けるべきなのか？（メリット・デメリットの分析）

  1. 影響の分離（爆発半径の極小化） スロットゲームのコードを少し修正してデプロイした際、万が一バグが混入しても、ポーカーゲーム側は1ミリも影響を受けずに稼働し続けられます。
  2. コストの最適化 「ポーカーだけが異様に人気で、スロットは過疎っている」という場合、ポーカーのコンテナだけが自動でスケール（増殖）し、スロットは眠ったままにできるため、無駄な課金が発生しません。
  3. カナリアリリースの容易さ 特定のゲームだけ「新バージョンを5%のユーザーにだけ先行公開して様子を見る」といった高度な運用（トラフィック分割）が、Cloud Runの標準機能で簡単に実現できます。

「クローズドドメイン（Same-Originポリシー）」の罠

ただし、Cloud Runを分割すると、それぞれに異なるURL（デフォルトの xxx.run.app）が割り当てられます。 ブラウザには「Same-Origin（同一起源）ポリシー」という強力なセキュリティ規制があるため、異なるドメイン間でのデータのやり取りやセッションの共有には、CORSの設定などが必要になり、開発の難易度が上がります。

これを綺麗に解決するのが、Google Cloudコンソールから設定できる「ドメインマッピング」です。 お名前.comなどで取得した独自ドメイン（例：mygame.com）をベースに、以下のようにサブドメインをそれぞれのCloud Runにマッピングします。

  • mygame.com（メインのゲーム選択・ログイン画面用Cloud Run）
  • poker.mygame.com（ポーカー用Cloud Run）
  • slot.mygame.com（スロット用Cloud Run）

このように同じドメイン傘下に隠蔽（マッピング）してあげることで、ブラウザの制約を回避しつつ、裏側では完全に独立した堅牢なシステムを維持することができます。この設計は、後からやろうとすると骨が折れるため、最初の段階でロードマップに組み込んでおくのがスマートです。

おわりに：Vibe Coding時代の歩き方

Google AI Studioの登場により、インフラのコードやバックエンドのロジックはLLMがある程度自動で組み立ててくれる時代になりました。しかし、今回解説したような「認証情報の渡し方」「プロジェクトIDによるセキュアな設計」「ドメインとブラウザのセキュリティ制限」といったコアなアーキテクチャ設計は、依然として人間のエンジニアの「知恵」が必要です。

適切な設計思想（土台）さえしっかりと作っておけば、AIという最強の作業パートナーを率いて、1人で何十個ものサービスを爆速で運営・管理することが可能になります。

まずは1つのクラウドプロジェクト、1つの共通データベースから、あなたのゲーム帝国を築いてみませんか？