Firebase Studioを本番前に使うなら：App Prototyping・Gemini・Hostingを分ける基準

このテーマをもう少し広げて見るなら、Codex Sitesを社内ツールに使う前に：Business/Enterprise preview・RBAC・secretsの確認ポイント と AIコーディングツール料金改定の見方：個人・小規模チーム・法人で変わる導入判断 も合わせて確認してください。Firebase Studioで作った社内向けツールを公開する前に、RBACやsecretsの確認軸を比較できる

3行まとめ

Prototype

App Prototyping agentで作る。

Project

Firebase projectを確認する。

Gemini

API keyとrulesを分ける。

Hosting

App HostingとHostingを選ぶ。

Firebase StudioはGoogle Cloud資源に近いので、作成されるprojectを必ず確認します。

• Firebase Studioは、App Prototyping agent、Gemini in Firebase、Firebase project、preview、publishが近いAI開発環境です。
• 本番前に使うなら、AIで作る流れと、Firebase project自動作成、Gemini API key、.aiexclude、App Hosting、Firebase Hosting、billingを分けて確認します。
• Publishは生成完了ではなく、Firebase/Google Cloud資源、IAM、billing、hosting選択を伴う公開判断です。previewと人間reviewを先に置きます。

本文の事実確認には、Firebase公式docsのApp Prototyping agent、Gemini in Firebase、Firebase project、Preview、Publish、Google/Firebase integrationsを使っています。Xで見かけるFirebase Studio、Gemini、App Hosting、Genkitへの投稿は需要シグナルとして扱い、本文の根拠にはしていません。

この記事でわかること

Auto create

projectとAPI keyの作成。

Rules

Geminiの指示を管理。

.aiexclude

読ませないfileを決める。

Publish

billingと権限を確認。

生成されたappだけでなく、裏で作られるFirebase/GCP資源を見ます。

• Firebase Studioを本番前に使う時に最初に分ける運用境界
• App Prototyping agentとGemini in Firebaseの役割の違い
• Firebase projectやGemini API keyが自動作成される場面
• AI rules fileと.aiexcludeでGeminiのcontextを管理する方法
• App HostingとFirebase Hostingをどう分けるか
• Publish前にbilling、IAM、preview、logを確認する理由

Firebase Studioは、browserで動く開発環境として、AI appのprototype、Firebase servicesとの統合、preview、publishまで近いところを扱えます。Firebaseに慣れているチームにとっては、AI app builderをFirebase運用へつなげやすい場所です。

ただし、近いからこそ注意が必要です。AIがappを作る流れと、Firebase project、Google Cloud billing、Gemini API key、hosting、IAM roleは別の責任です。

前提知識

項目	内容	見方
App Prototyping		Next.js appをAIで生成。
Gemini in Firebase		chat、CLI、inline支援。
Firebase project		backend serviceのcontainer。
App Hosting		dynamic framework app向け。

Firebase StudioはAI app builderとFirebase運用の接点として理解します。

Firebase Studio docsでは、App Prototyping agentが自然言語、画像、drawing toolsなどのmultimodal promptsから、AI-forwardなweb appをrapid prototypeできると説明されています。現在はNext.js appsをsupportし、他platformやframeworkは今後予定とされています。

Gemini in Firebase docsでは、workspace-awareなchatやCLI、inline actions、code completionを使えると説明されています。Geminiはreview and approvalのもとでfile更新、terminal command実行、command output解釈、次stepの判断もできます。

この記事の扱う範囲

項目	役割
App Prototyping agent	promptからapp blueprint、code、previewを作る
Gemini in Firebase	workspace-awareなAI coding支援
Firebase project	backend servicesのcontainer
Gemini API key	appやGemini機能で使うkey
AI rules file	Geminiへのcustom instruction
.aiexclude	Geminiへ読ませないfileやdirectory
App Hosting	dynamic framework app向けpublish先
Firebase Hosting	static contentやSPA向けpublish先

2026年6月1日時点で公開されているFirebase公式docsを確認しています。導入時には、利用中のFirebase Studio、Firebase project、Gemini API key、billing account、IAM role、App Hosting backend、Firebase Hosting siteを改めて確認してください。

注意点

Firebase docsでは、Gemini outputを検証すること、productionで未テストの生成codeを使わないこと、PIIやuser dataをchatへ入力しないことが注意されています。この記事でも、AI生成をそのまま本番投入しない前提で整理します。

まず6つの境界に分ける

項目	内容	見方
Prompt		依頼と完了条件。
Project		Firebase project。
AI		Gemini API keyとrules。
Ignore		.aiexclude。
Preview		Nixと操作確認。
Publish		hostingとbilling。

境界を分けると、試作から公開までの責任を説明しやすくなります。

Firebase Studioを本番前に使うなら、最初に6つの境界を分けます。

境界	確認すること
Prompt	app idea、完了条件、制約
Project	Firebase project、owner、services
AI	Gemini API key、rules、chat設定
Ignore	.aiexclude、secret、user data
Preview	web preview、Nix設定、operation
Publish	hosting、billing、IAM、rollback

この6つを分けると、「Firebase Studioで作った」から一歩進んで、「どのFirebase projectに何を作り、どのhostingへ公開するか」を説明できます。

Firebaseに近い強み

Firebase Studioは、Firebase Authentication、Cloud Firestore、Cloud Storage、App Hosting、Hostingなどへ近い場所で作業できます。Firebase Local Emulator Suiteをworkspace内で使えることもdocsで説明されています。

Firebaseに近い注意点

Firebase projectは、authentication、data storage、hosting、analyticsなどのbackend servicesをまとめるcontainerです。AI app builderで試作しているつもりでも、projectやAPI keyが作られることがあります。

判断基準

迷ったら、「これはworkspace内の試作か、Firebase projectに作られた資源か」を分けて見ます。後者なら、Firebase consoleとGoogle Cloud IAMで確認します。

App Prototyping agentは試作入口として扱う

Blueprint

app ideaを構造化。

Code

Next.js appを生成。

Preview

web previewで確認。

Iterate

promptで修正する。

App Prototyping agentは試作を速くする入口であり、公開判断そのものではありません。

App Prototyping agent docsでは、natural languageとoptional imageからapp ideaを伝えると、agentがapp blueprint、code、web previewを生成すると説明されています。AIを使うappでは、Gemini Developer APIやGenkit flowsを使う構成も示されています。

App Prototyping agentは、試作入口として見るのがよいです。

agentに向く依頼

依頼	理由
small prototype	形にしてpreviewしやすい
AI-forward app	Gemini APIやGenkitと相性がよい
UI flow	blueprintから操作を見られる
demo app	Firebase servicesの組み合わせを試せる

agentに任せすぎない部分

auth、database rules、billing、IAM、production data、custom domain、monitoringは人間が確認します。AIが作ったappが動いても、Firebase運用として安全とは限りません。

blueprintをreviewする

codeが生成される前に、app blueprintや目的を確認します。scopeが広すぎる場合は、prototypeを小さくします。

完了条件を書く

promptには、主要user flow、使うFirebase service、使わないservice、previewで確認する操作を書きます。曖昧なまま進めると、projectやserviceが増えやすくなります。

Firebase project自動作成を見落とさない

項目	内容	見方
Gemini key		auto-generate時に作成。
Backend		必要service追加時。
Publish		未作成なら作成。
Console		project名と権限を見る。

自動作成されたprojectは、あとから必ずFirebase consoleで確認します。

Firebase Studio docsでは、App Prototyping agentが必要に応じてFirebase projectをprovisionできると説明されています。Gemini API keyをauto-generateする場合、workspace名に合うprefixのFirebase projectとGemini API keyを作ることも説明されています。

また、Publish時にもFirebase projectが未作成ならprovisionされることがあります。

自動作成される場面

場面	見ること
Gemini API key auto-generate	Firebase projectとkeyが作られる
backend services追加	Firebase serviceが有効になる
Publish	未作成ならprojectが作られる
App Hosting setup	billingやproject権限を見る

Firebase consoleで確認する

workspace上で見えているだけでなく、Firebase consoleでproject名、owner、enabled services、billing、IAM、API keyを確認します。

project名を読めるようにする

auto-generated project名は、あとから見て用途が分かりにくいことがあります。teamではproject naming、labels、owner、billing accountを整理します。

使わないprojectを放置しない

prototypeで作ったprojectが残ると、billing、security、API key管理が散らかります。不要なら停止、削除、owner確認をします。

Gemini API keyとAI rulesを分ける

API key

自動作成か持ち込みか。

Chat

workspace-aware支援。

Rules

AI rules fileで指示。

Approval

変更適用はreviewする。

Geminiの能力設定と、appが使うGemini API keyを混同しないようにします。

Gemini in Firebase docsでは、Gemini in Firebaseをworkspace-awareなAI assistanceとして使えると説明されています。settingsでは、code completion、codebase indexing、AI rules file、.aiexclude、bring your own key、code change apply設定などを調整できます。

ここで混同しやすいのが、appが使うGemini API keyと、Gemini in Firebaseの振る舞いです。

分けるもの

項目	役割
Gemini API key	appがGemini APIを呼ぶためのkey
Gemini chat	workspace-awareな開発支援
AI rules file	Geminiへのproject rule
code apply settings	AI変更をどう適用するか
codebase indexing	どの情報を使って支援するか

AI rules fileに書くもの

項目	例
architecture	directoryごとの責務
Firebase services	Authentication、Firestore、Hostingなど
commands	build、test、emulator
security	API key、PII、rules
review	publish前に説明すること

approvalを残す

Gemini in Firebaseは、review and approvalのもとでfile更新やterminal command実行ができます。最初は自動適用ではなく、変更内容とcommandを人間が見ます。

keyをpromptへ貼らない

Gemini API keyやservice account keyをchatへ貼りません。Firebase/Google Cloud側のsecret管理を使います。

.aiexcludeで読ませない情報を決める

Secrets

keysやcredentialを外す。

User data

PIIや顧客dataを外す。

Generated

生成物や巨大fileを外す。

Logs

private logを外す。

.aiexcludeは安全性とcontext品質の両方に効きます。

Gemini in Firebase docsでは、.aiexclude filesでGeminiからfileを除外できると説明されています。これはAI app builderの安全性に効きます。

.aiexcludeに入れる候補

対象	理由
credentials	service account keyやAPI keyを除外
user data	PIIやreal user dataを除外
logs	private logやerror dumpを除外
generated files	noiseや巨大fileを除外
build output	contextを圧迫する

PIIをchatへ入れない

Firebase docsでは、PIIやuser dataをchatへ入力しないよう注意されています。.aiexcludeは補助であり、chatへ貼らない運用も必要です。

rulesとexcludeをセットで見る

AI rules fileは「守ること」を書き、.aiexcludeは「読ませないもの」を決めます。両方をセットで管理します。

review観点

AIが変更したfileにsecretやuser dataが混ざっていないか、.aiexclude対象が変更されていないかを見ます。

PreviewはNix設定と実操作で確認する

項目	内容	見方
dev.nix		preview環境を定義。
Web preview		主要flowを操作。
Android		対象ならpreview。
Logs		buildとruntimeを見る。

previewは表示確認だけでなく、環境設定と主要操作を確認します。

Firebase Studio Preview docsでは、templatesやApp Prototyping agentで生成したappではpreviewが設定済みの場合が多く、必要なら.idx/dev.nixでpreview environmentを設定できると説明されています。

previewは、画面が表示されるかを見るだけではありません。

previewで見る項目

項目	確認すること
.idx/dev.nix	preview環境が正しいか
web preview	user flowを操作する
logs	buildやruntime error
emulator	Firebase servicesを本番前に試す
Android preview	対象なら動作を見る

Local Emulator Suiteも見る

Firebase Studio docsでは、Firebase Local Emulator Suiteを直接使って、Authentication、Cloud Functions、Cloud Firestore、Cloud Storage、App Hosting、Hostingなどをpublish前にtestできると説明されています。

previewで終わらせない

previewで動いても、本番のIAM、billing、domain、API key、security rulesは別です。previewは公開前の1段階として扱います。

操作logを残す

主要flowを実際に触り、何を確認したかを残します。AIが「動きます」と言っただけでは十分ではありません。

App HostingとFirebase Hostingを分ける

項目	内容	見方
App Hosting		Next.js/Angularなどdynamic app。
Firebase Hosting		staticやSPA。
Billing		App HostingはBlaze確認。
GitHub		App Hostingは連携も見る。

名前が似ていますが、App HostingとFirebase Hostingは用途が違います。

Publish docsでは、Firebase Studioが複数のpublishing optionを提供すると説明されています。Firebase App Hostingはdynamic Next.js and Angular applications向けで、Firebase Authentication、Cloud Firestore、Firebase AI Logicなどと統合しやすい選択肢です。Firebase Hostingはstatic web contentやSPA向けです。

名前が似ていますが、用途が違います。

App Hostingに向く場合

場面	理由
Next.js app	framework supportがある
dynamic app	server-side behaviorがある
Firebase products統合	auth、Firestore、AI Logicなど
GitHub integration	app hosting flowへ寄せやすい

Firebase Hostingに向く場合

場面	理由
static site	HTML/CSS/JS/image中心
SPA	client-side app
simple preview	billingなしで始めやすい場合がある
CDN	global deliveryとSSL

billingの違い

Publish docsでは、App Hosting setupではCloud Billing account linkingが案内され、projectがBlaze planへupgradeされることが説明されています。一方、Firebase HostingのsetupにはCloud billing accountがrequiredではないと説明されています。

hosting選択をprompt任せにしない

AIに「publishして」と頼む前に、app構成に合うhostingを人間が選びます。Next.jsだから必ずApp Hosting、staticだから必ずHosting、という単純な話ではなく、runtime、data、auth、costを見ます。

Publish前にbillingと権限を確認する

Billing

Blaze planへの影響。

IAM

必要roleとowner。

Services

有効化されたAPI。

Rollback

戻し方とlogを見る。

Publishは生成完了ではなく、課金と権限を伴う公開判断です。

Publish docsでは、App Hostingをset upする時、Firebase project作成やCloud Billing account linkingが案内されると説明されています。また、App Hosting service accountへ必要roleを付与する説明もあります。

Publishは、AI作業の終点ではなく、課金と権限を伴う公開判断です。

publish前に見る項目

項目	確認すること
Firebase project	正しいprojectか
Billing	Blaze planやCloud Billing account
IAM	owner、service account、roles
APIs	有効化されたservice
Secrets	API keyやservice account key
Logs	build、deploy、runtime

publish失敗時の扱い

Publish docsでは、Firebase Hostingでpublishが失敗した場合、promptを再実行してretryできるtipもあります。ただし、やみくもにretryするより、log、permission、billing、projectを見ます。

公開後の確認

公開URL、auth、database rules、Gemini API usage、logs、billing alertを確認します。

billing alertを設定する

AI appはGemini APIやFirebase servicesを使うことがあります。prototypeでも課金が発生する可能性があるため、billing alertやbudgetを設定します。

導入初週の進め方

1. 1日目

   小さなNext.js prototype。

2. 2日目

   Firebase projectを確認。

3. 3日目

   Gemini rulesと.aiexclude。

4. 5日目

   previewとemulator確認。

5. 7日目

   hostingとbillingを整理。

初週は公開より、Firebase projectと権限の見える化を優先します。

Firebase Studioは、最初の1週間で「作れるか」より「Firebase projectと公開責任を見える化できるか」を確認します。

日	やること	目的
1日目	小さなNext.js prototypeを作る	App Prototyping agentの流れを見る
2日目	Firebase projectとGemini API keyを確認	自動作成資源を把握する
3日目	AI rules fileと.aiexcludeを整える	AI contextを管理する
4日目	previewとLocal Emulator Suiteを試す	本番前の動作確認を作る
5日目	App HostingとHostingを比較する	publish先を選ぶ
6日目	billing、IAM、APIを棚卸しする	公開前の責任を確認する
7日目	publish checklistを作る	本番化条件を決める

初週の評価軸

評価軸	見ること
project理解	どのFirebase projectか説明できるか
AI context	rulesと.aiexcludeがあるか
preview	主要flowを操作したか
hosting	App HostingとHostingの違いを理解したか
billing	課金とIAMを確認したか

広げる条件

次の条件を満たしたら、本番に近いtaskへ広げます。

• Firebase projectのownerとbillingが明確
• Gemini API keyとAI chat設定を分けている
• .aiexcludeでsecretやuser dataを外している
• Local Emulator Suiteまたはpreviewで主要flowを確認している
• App HostingとFirebase Hostingの選択理由がある
• publish前のIAM、API、logs、billing alertを確認している

FAQ

Auto project?

consoleで確認する。

App Hosting?

dynamic app向け。

Hosting?

static/SPA向け。

PII?

chatへ入れない。

迷ったら、AI作業とFirebase資源作成を分けて確認します。

App Prototyping agentとGemini in Firebaseは同じですか？

同じではありません。App Prototyping agentはapp blueprint、code、previewを作る試作入口です。Gemini in Firebaseはworkspace-awareなchat、CLI、inline actions、code completionなどの開発支援です。

Firebase projectはいつ作られますか？

docsでは、Gemini API keyをauto-generateする時、backend servicesを作る時、Publish時などにFirebase Studioがprojectをprovisionする場面が説明されています。Firebase consoleで確認します。

App HostingとFirebase Hostingはどう分けますか？

App Hostingはdynamic Next.js/Angular app向けです。Firebase Hostingはstatic contentやSPA向けです。billing、runtime、Firebase productsとの統合、app構成で選びます。

.aiexcludeは必須ですか？

必須ではありませんが、チーム導入では強くおすすめです。secret、PII、user data、logs、generated filesをGeminiのcontextから外します。

Geminiにproduction user dataを貼ってよいですか？

Firebase docsでは、PIIやuser dataをchatへ入力しないよう注意されています。production user dataは貼りません。必要なら匿名化、sample data、emulatorを使います。

Publish前にbillingを見る必要がありますか？

必要です。App Hosting setupではCloud Billing account linkingやBlaze planへのupgradeが関係します。Gemini APIやFirebase servicesのusageも確認します。

---

次に読むなら

参照した主な情報源

• https://firebase.google.com/docs/studio
• https://firebase.google.com/docs/studio/get-started-ai
• https://firebase.google.com/docs/studio/set-up-gemini
• https://firebase.google.com/docs/studio/firebase-projects
• https://firebase.google.com/docs/studio/preview-apps
• https://firebase.google.com/docs/studio/deploy-app
• https://firebase.google.com/docs/studio/google-integrations

次に読むなら

更新履歴

1. 2026年6月1日

   Firebase公式docsのStudio、App Prototyping、Gemini、Preview、Publishを確認して初版を作成しました。

導入時には利用中のFirebase Studio、project、billing、Gemini設定を確認してください。

• 2026年6月1日: Firebase公式docsのStudio、App Prototyping agent、Gemini in Firebase、Preview、Publish、project連携を確認し、初版を作成しました。