Figmaのデザインをコードに変換する開発フローを、クラウド上のプロトタイピング環境とどう接続するか検討しているインフラ担当者に向けた内容です。2025年9月29日、Google発のFirebase公式ブログでFirebase Studio（ブラウザ上で動くクラウド開発環境）とBuilder.io（デザインをコードに変換するプラットフォーム）の統合が発表されました。見た目はデザインツールの連携強化ですが、SRE（サイト信頼性エンジニアリング）やインフラ担当の立場で見ると、評価すべき論点はまったく別のところにあります。
この統合は、Figmaのプラグインで出力したデザイン情報をFirebase Studioに取り込み、Gemini（Googleの生成AIモデル）がコードを自動生成し、Firebase App Hosting（SSR対応のホスティングサービス）にワンクリックでデプロイする、という一連の流れを提供します。プロトタイプ作成が速くなる一方、「誰が」「どこで」「何を」本番環境にデプロイするのかという運用上の問いが新しく発生します。プロトタイピング用のツールを本番導入するかどうかは、便利さだけで決めるべきではありません。
どんな場面で判断が必要になるか
典型的には次のような場面で、この選定が発生します。
- デザインチームがFigmaで作った画面を、最短距離でステージング環境に反映したいとき
- 複数のフロントエンドフレームワーク（Next.js、Astro、SvelteKit、React、Angular）を使い分けているチームで、共通のプロトタイピング基盤を探しているとき
- Google Cloudをすでに採用しており、Firebase App Hostingとの親和性を評価したいとき
- AIアシスト型のスキャフォールディング（雛形自動生成）ツールの導入可否を技術選定会議にかけるとき
上記に心当たりがあれば、以下の判断軸で整理してみてください。
判断軸1: シークレット管理とIaCの整合性
Firebase Studioが生成した環境は、idx/dev.nixというNix形式の設定ファイルでワークスペースが定義されます。
これはNix（宣言的にパッケージと環境を定義するパッケージマネージャー）の設定ファイルで、コンテナのDockerfileに近い役割を持ちます。
問題は、この設定ファイルがGitリポジトリで管理されるべき一方、環境変数やAPIキーがどこに置かれるかが曖昧になりやすい点です。
公式の推奨は、シークレットをCloud Secret Manager（Google Cloudのシークレット管理サービス）に隔離することです。
すでにTerraformやPulumiでインフラをコード管理しているチームであれば、Firebase Studioが生成したリソースをそのままの状態運用で放置せず、既存のIaC（Infrastructure as Code）パイプラインに取り込めるかを確認してください。
具体的には、Firebase App Hostingの設定がTerraformのfirebase providerでどこまでコード化できるか、公式ドキュメントのリソース一覧を照合する作業が必要です。
判断軸2: デプロイ経路とCI/CDの一本化
Firebase Studioはブラウザから直接App Hostingにデプロイできる点が売りです。
しかし、これが既存のCI/CD（継続的インテグレーション・継続的デリバリー）パイプラインと並走する経路になると、デプロイ履歴が分散するリスクがあります。
たとえば、GitHub Actionsでテストとデプロイを一元管理しているチームの場合、Firebase Studioからの直接デプロイは「ブランチプレビュー用」に限定し、本番デプロイは既存のCI/CDゲートを必ず通す運用に固定する判断が妥当です。
この切り分けをしないと、誰がどの経路でデプロイしたのか障害時に追跡できなくなります。
判断軸3: オブザーバビリティの継続性
プロトタイプ段階ではログやメトリクスの監視を省略しがちですが、App Hostingにデプロイした時点でそれは「稼働しているサービス」になります。
Cloud Loggingやエラーレポートの統合が有効になっているか、デプロイ直後に確認する癖をつけてください。
具体的な確認手順としては、Firebase Consoleの該当プロジェクトでApp Hostingのバックエンド設定を開き、Cloud Runベースの実行環境にログシンクが構成されているかを見る、という流れになります。
AIが自動生成したコードは、ロギングやエラーハンドリングの実装が薄いことがあるため、生成されたコードをレビューする際はこの観点を必ず加えてください。
判断軸4: コストの予測可能性
Firebase StudioとGeminiを使った生成プロセス自体は、プロトタイピング段階では低コストで済みます。
ただし、生成されたアプリがApp Hostingで常時稼働し始めると、Cloud Runの課金体系（リクエスト数・CPU時間・メモリ）に従ったコストが発生します。
複数のプロトタイプを並行して試す運用では、不要になった環境を放置せず削除するルールを決めておくことが、コスト管理上の実務的なポイントです。
選択肢の比較
| 観点 | Firebase Studio + Builder.io | 従来のローカルDocker環境 |
|---|---|---|
| 環境構築の速度 | ブラウザのみで数分 | Docker設定とenv管理に数時間 |
| IaCとの統合 | Terraform/Pulumiへの手動移行が必要 | 最初からIaCで管理しやすい |
| デプロイ経路 | ワンクリックでApp Hostingへ直接 | 既存CI/CDパイプライン経由 |
| 対象フレームワーク | Next.js/Astro/SvelteKit/React/Angular | 任意（制約なし） |
ケース別の推奨
- Figmaでのデザインレビューからステージング確認までのサイクルを短縮したいなら、Firebase Studioをプロトタイピング専用レーンとして導入する選択が合理的です
- すでにGoogle CloudとTerraformで本番インフラを一元管理しているなら、Firebase StudioはPoC（概念実証）用途に限定し、本番コードは既存のIaCに手動で移植する運用にすべきです
- マルチクラウド構成でAWSやAzureとの併用を前提にしているなら、Firebase App Hostingへの依存を深めすぎない判断が必要です
あえて見送るべき条件
次のいずれかに当てはまる場合は、現時点での本番導入を見送り、プロトタイピング用途に限定したほうが安全です。
- 障害対応のランブック（手順書）やオンコール体制が、Firebase Studio経由のデプロイ経路に対応していない
- シークレット管理のポリシーがCloud Secret Managerへの移行を前提にできていない
- 生成されたコードのセキュリティレビュー工程を、既存のコードレビューフローに組み込める見込みが立たない
導入前に確認すること
Firebase StudioとBuilder.ioの統合は、デザインとコードの乖離（デザインドリフト）を減らす有効な手立てです。
ただし本番採用の可否は、IaCとの整合性・デプロイ経路の一本化・オブザーバビリティ・コストの4点で判断してください。
導入を検討するなら、まずはidx/dev.nixの設定ファイルをGitリポジトリにコミットできるか試し、Cloud Secret Managerとの連携を確認するところから始めてみてください。
そのうえで、既存のCI/CDパイプラインとデプロイ経路を競合させない設計を固めてから、チーム全体への展開を判断するのが現実的な進め方です。