Google AI StudioのFirebase統合とは｜Firestore・認証の自動構築からCloud Runデプロイまで

Googleは2026年3月19日、Google AI StudioにFirebaseのバックエンド機能をネイティブ統合しました。これによりCloud FirestoreとFirebase Authenticationがプロンプトから自動構成され、UI設計からデータ保存・認証・本番デプロイまでをブラウザ1画面で完結できます。続く2026年5月19日のGoogle I/O 2026では、支払い方法なしのCloud RunワンクリックデプロイやGoogle Workspace連携が追加されました。同時に旧開発環境のFirebase Studioはサンセット（提供終了）が告知され、移行先の判断も必要になっています。本記事は、統合で自動化される中身、料金と無料枠、移行の手順、Google Antigravityや競合ツールとの違いを、公式ドキュメントの一次情報で整理します。

まとめ：Google AI StudioのFirebase統合の要点

• 発表と中身：2026年3月19日にFirestore・Firebase Auth（Google Sign-In）がネイティブ統合。「Enable Firebase」でプロジェクト作成・DB作成・認証有効化・コード接続まで自動実行。
• 対応と生成物：Build ModeはReact・Angular・Next.jsに対応。/src/lib/firebase.tsとfirestore.rulesを自動生成する。
• 料金：Cloud Billingなしの「共有クォータ」で開始でき、I/O 2026以降は最初の2アプリを支払い方法なしでCloud Runへデプロイ可能。上限超過や本番運用はBlazeプラン（従量課金）へ。
• 移行：Firebase Studioは2027年3月22日に完全停止。プロンプト型はAI Studio、コードファースト型はAntigravityへ移す。App Hosting公開済みアプリは停止後も稼働。
• 競合との違い：Replit・Bolt.new・Lovableに対し、バックエンド（DB＋認証）の自動統合とGoogle Cloud接続性がAI Studioの強み。

以下で、統合の実態・手順・料金・移行・競合比較を順に掘り下げます。

Firebase統合で自動化された範囲とI/O 2026での追加機能

統合前のGoogle AI StudioはGemini APIの動作確認やプロトタイプ用途が中心で、データ永続化やユーザー管理は外部で別途構築する必要がありました。今回の統合で、バックエンドの初期構築がプロンプト操作だけで完了するようになっています。

プロンプトからFirestoreと認証を自動構成する仕組み

アプリ作成時に「Firebaseをバックエンドに使った共有ToDoアプリを作って」のようにデータ保存や認証が必要な要件を記述すると、エージェントがその必要性を検出し、Firebase統合の有効化を提案します。「Enable Firebase」をクリックして利用規約に同意すると、Firebaseプロジェクトの作成、Firestoreのプロビジョニング、Authentication（Google Sign-In）の有効化、アプリのコードベースへの接続までが自動実行されます。生成されるアプリにはサインインページ、データの読み書きロジック、セキュリティルールが揃った状態になり、手動でのバックエンド設定はほぼ発生しません。公式ドキュメントは、プロンプト内でFirebaseの利用を明示すると構成がより確実になると案内しています。

2026年5月のI/O 2026で追加された無料デプロイ・Workspace連携

統合は発表後も拡張が続いています。2026年5月19日のGoogle I/O 2026では、支払い方法を登録せずにCloud Runへワンクリックデプロイできる「Google Cloud Starter Tier」が導入され、AI Studioから公開する最初の2つのFirebase対応アプリを無料で稼働できるようになりました。3つ目以降は通常のGoogle Cloudプロジェクトへの移行が必要です。あわせて、Firebase AuthenticationのSign in with Googleフローを使い、Gmail・Docs・Sheetsなどのワークスペースデータへ自然言語でアプリを接続する機能、リプレイ攻撃を防ぐFirebase App Check、KotlinベースのネイティブAndroidアプリ生成（Firebase自動統合は順次対応）も加わりました。これらはすべて2026年5月19日のI/O 2026告知（firebase.blog）で加わった現行仕様であり、3月発表時点の解説記事には載っていません。

Antigravityとの違いと使い分け

AI Studioと並ぶGoogleのフラッグシップ開発ツールが、2025年11月18日にGemini 3と同時発表されたアンチグラビティ（Google Antigravity）です。両者は役割が異なり、GSCの実クエリでも「google ai studio antigravity 統合」「違い」の検索が多く見られます。

ブラウザ完結のAI StudioとコードファーストのAntigravity

AI Studioは完全にブラウザ上で動くプロンプト駆動型で、要件を自然言語で伝えるとエージェントがフルスタック構成を自動生成します。一方Antigravityは、複数のAIモデルを切り替えて使えるデスクトップ型のエージェント開発プラットフォームで、発表時点ではGemini 3 Proに加えClaude Sonnet系やGPT-OSSを選択できます。ローカル実行やカスタム環境構成、リポジトリのインポートを伴う本格開発にはAntigravity、プロンプトから本番アプリへ最短で到達したいならAI Studioが向きます。Antigravity 2.0では、オンボーディング時にFirebaseをワンクリックで設定できます。

フレームワークとライブラリを自動選定するエージェントの挙動

Build ModeはReact・Angular・Next.jsに対応し、設定パネルでフレームワークを選べます。外部ライブラリも要件に応じて自動導入され、アニメーション要件を検出するとFramer Motion、UIコンポーネントが必要と判断するとShadcnといった選定が行われます。ただし精度はプロンプトの具体性に依存します。「きれいにして」のような曖昧な指示では意図を取り違えやすく、「カード形式のレイアウトでホバー時にスケールアニメーションを適用して」のようにUIパターンとインタラクションまで具体化すると、狙いどおりの実装になりやすくなります。

Firestore・認証の自動構築の実態と注意点

自動構築は便利な反面、生成されるファイルとセキュリティ設定の仕組みを理解しないまま本番公開すると事故につながります。

生成されるfirebase.tsとfirestore.rulesの役割

Firebase有効化後、エージェントは主に2つのファイルを生成します。/src/lib/firebase.tsはFirebase SDKの初期化・Firestoreインスタンス取得・認証インスタンス取得を担う共通モジュールで、各コンポーネントがここを起点にFirebaseへアクセスします。firestore.rulesはデータの読み書き権限を定義するセキュリティルールで、認証必須のアプリならrequest.auth != nullを条件とした制御が設定されます。これらはイテレーションのたびに更新される可能性があるため、直接手で書き換えるより後述のプロンプト経由で修正するほうが整合性を保てます。Firebase Authenticationの認証方式やFirebase Admin SDKによるサーバー側のユーザー管理を押さえておくと、生成コードの読み解きが容易になります。

セキュリティルールをコンソールで直接編集すると上書きされる

公式ドキュメントが明確に警告しているのが、Firebaseコンソールでセキュリティルールを直接編集した場合の上書きリスクです。AI Studioのエージェントはプロジェクト内のfirestore.rulesを正としてルールを管理するため、コンソール側で手動変更しても、次にアプリを更新した際にエージェント生成のルールへ上書きされます。修正は「認証済みユーザーのみが自分のデータを読み書きできるようにルールを変更して」のようにプロンプトで指示し、ルールとアプリコードを同時に更新させるのが正攻法です。自動生成ルールは開発効率を優先して緩めになっている場合があるため、公開前に権限設定を必ず確認してください。

リアルタイム同期・オフライン対応と共有クォータの範囲

Cloud Firestoreのリアルタイムリスナーにより、あるデバイスでの変更が他デバイスへ即時反映され、オフライン時の変更もオンライン復帰後に自動同期されます。これらは追加実装なしにFirestoreの標準機能として使えます。AI Studioが作成するデータベースはCloud Billing不要の「共有クォータ」に置かれ、個人開発やプロトタイプ検証には十分ですが、多数のアクティブユーザーを抱える本番サービスでは読み取り50,000回／日などの上限に達しやすい。無料枠を維持するなら、不要なリスナーの削減やクエリ最適化でデータ使用量を抑えます。

Build ModeからCloud Runデプロイまでの手順

実際の構築は、aistudio.google.comのBuild Modeで新規アプリを作成し、要件をプロンプトで記述するところから始まります。つまずきやすいのは既存プロジェクトの扱いとデプロイ時のプロジェクト整合です。

既存プロジェクトの指定とEnable Firebaseの承認

デフォルトではEnable Firebase時に新しいFirebaseプロジェクトが自動作成されます。既存のGoogle Cloudプロジェクトを使いたい場合は、有効化カードの設定アイコンからプロジェクトを選ぶか、イテレーション中にエージェントへ「Add Firestore to this app using project PROJECT_ID」と指示します。プロジェクトIDはFirebaseコンソールのプロジェクト設定で確認できます。この初期設定はGoogleアカウントがあれば無料で開始でき、Cloud Billingの登録は必須ではありません。

プロジェクトとロケーションの固定とCloud Run不一致エラーの回避

完成したアプリはShareメニューのPublishからCloud Runへデプロイします。ここでの重要な制約は、最初に統合した機能で選んだプロジェクトとロケーションが、以降のFirebase・Google Cloudサービスすべてに自動適用される点です。ロケーションは一度決めると変更できません。デプロイ先に別プロジェクトを選ぶと不整合エラーになるため、Firebaseバックエンド・Firestore・Cloud Runのデプロイ先を同一プロジェクトに揃えるのが回避策です。すでにずれてしまった場合は、エージェントへ「Switch to Firebase project PROJECT_ID」と指示してプロジェクトを合わせてから再度Publishします。デプロイ前に3者が同一プロジェクト内にあるかを確認する習慣をつけると、この種のエラーを未然に防げます。

無料枠・共有クォータと従量課金の境界

開発段階では気にならなかったコストが本番運用で急増するのはよくある失敗です。無料枠の境界と課金トリガーを事前に把握しておくことが、想定外課金を避ける前提になります。

共有クォータの具体的な上限

共有クォータは、公式ドキュメントで日次・月次の上限が明示されています。少人数のテスト利用であれば、これらに到達することはほとんどありません。

クォータのリセットは太平洋時間の深夜前後に行われます。Cloud Billing未設定なら上限超過時はサービスが制限されるため予期せぬ課金は発生しませんが、その分サービス停止のリスクは残ります。

Blazeプランへ自動アップグレードされる3つのトリガー

従量課金のBlazeプランへの移行は予告なく起きるのではなく、特定の操作をトリガーとして実行されます。

• Firebase App Hostingへデプロイした場合：無料枠を超える使用量に課金が発生する状態になる。
• Cloud Billingアカウントをプロジェクトにリンクした場合：Gemini APIの有料ティアにも切り替わり、利用枠が拡大する一方で使用量課金の対象になる。
• 共有クォータからフルスケーリングへ手動移行した場合：対象データベースが従量課金に切り替わる。

プロトタイプ段階ではCloud Billingをリンクせず、共有クォータの範囲で開発を進めるのがコスト管理の基本です。予算アラートは通知機能でありサービスを自動停止しないため、リスナー数やAPI呼び出し回数の定期確認、テスト環境と本番環境のプロジェクト分離といった運用チェックを併用します。

フルスケーリングへ移すcurl手順とStarter Tierの無料枠

アプリがトラクションを得て共有クォータがボトルネックになったら、Blazeプランへアップグレードしたうえで、対象データベースを共有クォータグループから手動で移します。この操作はコンソール画面からは実行できず、APIへPATCHリクエストを送ります。移行は不可逆で共有クォータには戻せないため、タイミングは慎重に判断してください。

curl -X PATCH \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  "https://firestore.googleapis.com/v1/projects/PROJECT_ID/databases/DATABASE_ID?updateMask=free_tier_limited" \
  -d '{"free_tier_limited": true}'

実行後はFirebaseコンソールで「Upgrade database」→「Upgrade to pay-as-you-go」もクリックします。なお前述のとおり、I/O 2026で導入されたGoogle Cloud Starter Tierを使えば、最初の2つのFirebase対応アプリは支払い方法なしでCloud Runへ公開できるため、小規模な検証段階では課金設定そのものを後回しにできます。

Firebase Studioサンセットと移行先の選び方

2026年3月19日、GoogleはFirebase Studioの段階的なサンセットを正式発表しました。2025年4月に公開された統合開発環境が、1年足らずで終了に向かうことになります。背景には、Google AI StudioとAntigravityという2つのフラッグシップへの機能集約という戦略があります。

3段階のマイルストーンと公開済みアプリの継続稼働

サンセットは約1年の移行期間を設けた3段階で進みます。第1段階は2026年3月19日の告知と移行ツールの提供開始、第2段階は2026年6月22日の新規ワークスペース作成・新規サインアップの停止、第3段階が2027年3月22日の完全停止で、この日に残存データが永久削除されます。重要なのは、影響を受けるのはFirebase Studioの開発環境だけで、Cloud Firestore・Authentication・App Hostingなどのコアサービスは継続する点です。App Hostingにデプロイ済みのアプリはサンセット後も稼働し続けます。ただしサンセット後はFirebase Studioからの再デプロイができないため、コード修正の必要があるアプリは移行先環境を事前に用意しておくべきです。Firebase Studio側から見た提供条件と引き上げ経路は、Firebase Studioとは｜2027年3月終了までの移行判断と引き上げ手順で整理しています。

AI StudioとAntigravityどちらへ移すか、エクスポート手順

移行先は開発スタイルで選びます。ブラウザベースのプロトタイピングを好み、App Prototypingエージェントを使ってきた開発者はGoogle AI Studioが適します。デスクトップでのコードファースト開発や、テンプレート・リポジトリからの構築を行ってきた開発者はAntigravityが向きます。エクスポートはワークスペース上部の「Move now」ボタンから移行先を選び、ローカル保存する場合は「Zip and Download」を選択します（表示されない場合はコマンドパレットで「Firebase Studio: Zip & Download」を実行）。なおAI Studioへの直接移行パイプラインはまだ発展途上で、変換時にエージェントがつまずくこともあるため、GitリポジトリへのプッシュやZipバックアップを暫定の保全策として併用しておくと安全です。

Replit・Bolt.new・Lovableとの比較とAI Studioを選ぶ基準

AI駆動のアプリ開発ツールは2026年に競争が激化しており、Replit Agent、Bolt.new、Lovableなどの有力な選択肢があります。プロジェクトの要件次第で最適解は変わります。

バックエンド統合度で比較した各ツールの位置づけ

実用性を最も左右するのがバックエンド機能の統合度です。Google AI StudioはFirestoreとFirebase Authenticationをネイティブ統合し、プロンプト操作だけでDB構築から認証まで完結する点が突出しています。

バックエンド統合度ではAI Studioが優位ですが、フロントエンドのUI品質やデザイン面ではLovableやBolt.newが勝る場面もあります。DB・認証・リアルタイム同期を要件に含むプロジェクトほど、AI Studioの自動統合が効きます。

AI Studioを選ぶべき条件と避けるべき条件

採用の判断は割り切ってよい部分があります。データ永続化・認証・リアルタイム同期が必要で、かつプロトタイプから本番まで一気通貫で進めたいなら、途中でツールを乗り換えずCloud Runへ公開できるAI Studioが最短です。すでにFirebaseやGoogle Cloudを業務基盤にしているチームなら、既存資産をそのまま活かせます。逆に、AWSやAzureを主要インフラとするチームには、Google Cloudへのロックインがそのままデメリットになるため避けたほうが無難です。また、エージェント駆動開発の品質はプロンプトの具体性に強く依存します。「ToDoアプリを作って」といった曖昧な指示は意図と乖離した成果物を生みやすく、同期対象や競合処理、切断時の状態管理を明示しないマルチプレイヤー実装は不具合の温床になります。要件を具体化するプロンプト設計を前提にできないチームでは、期待値を下げて評価すべきです。

よくある質問

Firebase Studioはいつ終了しますか。データは消えますか。

2027年3月22日に完全停止し、残存データは永久削除されます。新規ワークスペースの作成は2026年6月22日に停止済みです。ただしCloud Firestore・Authentication・App Hostingなどのコアサービスは影響を受けず、App Hostingに公開済みのアプリは停止後も稼働します。期限前にプロジェクトの移行またはバックアップを済ませてください。

Google AI StudioとAntigravityはどちらを使えばよいですか。

ブラウザ完結でプロンプトから素早くフルスタックアプリを作りたいならGoogle AI Studio、デスクトップでコードファーストに本格開発したいならAntigravityが向きます。AI Studioで試作し、必要に応じてAntigravityへ移す使い分けも可能です。

Firebase統合は無料で使えますか。

Cloud Billingなしの共有クォータで開始でき、I/O 2026以降は最初の2つのFirebase対応アプリを支払い方法なしでCloud Runへデプロイできます。共有クォータは1日あたり読み取り50,000回・書き込み40,000回などの上限があり、超えるとBlazeプラン（従量課金）が必要です。従量課金の単価はFirebase料金ページを参照してください。

Google AI Studioでアプリを作るにはどうすればよいですか。

aistudio.google.comのBuild Modeで新規アプリを作成し、要件をプロンプトで記述します。データ保存や認証が必要なら「Firebaseをバックエンドに使う」と明示すると、エージェントがEnable Firebaseを提案し、承認後にFirestoreと認証を自動構成します。完成後はShareのPublishからCloud Runへデプロイします。

Firebase StudioとGoogle AI Studioの違いは何ですか。

Firebase StudioはCode OSS系のIDE型環境で、AI Studioのバックエンド統合はプロンプト駆動型です。開発の起点がコードエディタかチャットかが最大の違いで、AI Studioはエージェントの自律性とバックエンド自動構築の手軽さで差別化されています。Firebase Studioは終了予定のため、新規はAI StudioまたはAntigravityを選びます。

関連記事

• アンチグラビティ（Google Antigravity）とは？料金・使い方・2.0の最新情報まで解説【2026年最新】
• Firebase Authenticationとは？基本機能と認証方式の概要
• Firebase Admin SDKとは？導入・初期化からユーザー管理まで使い方を解説
• Gemini 3とは？Google最新AIモデルの特徴・ラインアップ・料金と3.1への進化