Firebase Hosting
ビルド済みの静的ファイル（HTML/CSS/JS/画像など）を Google のエッジに配って高速配信するグローバルCDNであり、静的オリジンです。
- 静的サイト/SPA の高速配信：グローバル CDN、無料自動 SSL、HTTP/2/3
- シンプルなデプロイ：
firebase deploy、ゼロダウンタイム、即ロールバック - カスタムドメイン：Apex/WWW を簡単接続
- リダイレクト/ヘッダー/キャッシュ制御：
firebase.jsonで宣言的に管理 - バックエンド連携（リライト）：Cloud Functions / Cloud Run へ安全にプロキシ
- プレビュー運用：Preview Channels（PR ごと短期 URL）
Firebase App Hosting
ビルドからアプリのサーバーをマネージドで管理してくれるフルスタックのウェブアプリ用の環境を提供します。Cloud Build → Artifact Registry → Cloud Run（サーバ実行）→ Cloud Load Balancing＋Cloud CDNを自動で組んでくれる。
- Git 連携から本番まで一気通貫：リポ接続→ビルド→（必要なら）SSR 実行→CDN 配信
- サーバー実行が前提のアプリを想定：Node などのランタイムをマネージドで面倒を見る
- 画像最適化・SSR 等を“ホスティング側”で統合（対応フレームワークは順次拡大の前提）
Firebase HostingとFirebase App Hostingの使い方のまとめ
| 観点 | Firebase Hosting | Firebase App Hosting |
|---|---|---|
| 主目的 | 静的配信（CSR/SSG）中心 | SSR/サーバー実行込みの一体運用 |
| サーバーコード | 実行しない（＝静的配信のみ） | 実行する（ビルド→実行→配信まで管理） |
| 動的機能の載せ方 | Hosting →（rewrite）→ Functions / Run | App Hosting 自身が実行環境を提供 |
| 初期導入 | CLI 初期化＋firebase.json 設定 | リポ接続＋ビルド設定（GUI/宣言的） |
| 得意領域 | Jamstack、SPA、静的＋一部 API のハイブリッド | SSR 多用、画像最適化、フルスタック運用 |
Next.js の場合は
- CSR：クライアントで描画（初期 HTML は薄く、JS で描画）
- SSG：ビルド時に静的 HTML を生成して配信
- SSR：リクエストごとにサーバーで描画して返す
- ISR：公開後も静的ページを一定間隔で再生成（SSG の増分更新）
使い分け方
- CSR / SSG → Firebase Hosting 単体でOK
- Next.js の
output: "export"（next export）成果物を配信 - SPA なら
"**" → "/index.html"の rewrite を 1 本入れるだけ
- Next.js の
- SSR / ISR → 選択肢は2つ
- Firebase Hosting +（rewrite）+ Functions/Cloud Run
- 既存の GCP リソース（DB、VPC、秘密情報管理）と組み合わせやすい
- ISR/画像最適化もサーバー側で実装可能
- Firebase App Hosting
- Git 連携→ビルド→SSR 実行→配信までまとめて任せる運用
- Firebase Hosting +（rewrite）+ Functions/Cloud Run
Firebase HostingとCloud Runの接続
A) 直結
[Firebase Hosting] –rewrite–> [Cloud Run (public)]
この場合、Cloud RunでAPIを実装した場合、APIは公開になる
この、rewriteとは、Firebase Hosting の設定ファイル（firebase.json）内で使うルーティング指定のことで、Cloud RunかCloud Functionsで使用できる
B) 入口で“物理的に”締める（WAF/IAP 必須のとき）
[Firebase Hosting] → [HTTPS LB + (Cloud Armor/IAP)] → [Serverless NEG] → [Cloud Run (private)]
- LB：httpsの終点、バックエンドルーティング、SSL証明書設定等
- Armor (WAF: Web Application Firewall)：LBにポリシーをアタッチし、アクセスを制限する
- IAP (Identity-Aware Proxy)：特定のチームやユーザーのみログイン可能にする
- Serverless NEG（Network Endpoint Group）: LBとサーバーレスサービス（Cloud Run・Cloud Functions・App Engine）を接続するオブジェクト
Cloud Load Balancing（LB）
HTTP(S) Load Balancer（External HTTPS LB） は、グローバルな Google フロントエンド（GFE） 上に存在します。つまりVPC の外側にあり、世界中のユーザーから直接 HTTPS リクエストを受け取ります。
- 役割：グローバルな HTTPS 終端、証明書、L7 ルーティング、Cloud CDN 連携、ログ/メトリクスの起点。
- いつ使う：
- 複数バックエンド（Cloud Run、GKE、VM、マルチリージョン）への高度ルーティング。
- Cloud Armor（WAF）やIAPを使いたい（＝LBが前提）。
- 独自の TLS 設定、接続制御、地理ベースのルールなどを細かく運用したい。
- Firebase Hosting との関係：Hosting は“Google管理のCDN+LB相当”が内蔵。ユーザーが別途 LB を置くことは基本しない。
Cloud Armor（WAF / DDoS ルール）
- 役割：WAF ルール、IP 制限、Bot/レート制御、地理ブロック等。
- いつ使う：
- 公開 API/SSR に対して細かいセキュリティ制御をしたい。
- PCI/GDPR/社内ポリシーで WAF 必須。
- 前提：外部 HTTPS LB のバックエンドにアタッチ（Cloud Run はServerless NEG経由で LB 配下に置く）。
- Firebase Hosting との関係：Hosting 直下には付けられない。必要なら**「LB + Cloud Run」構成**に切り替える。
IAP（Identity-Aware Proxy）
- 役割：Google アカウント/SAML/OIDC 等でアプリに入る前に認証（ゼロトラスト風の境界）。
- いつ使う：
- 社内ツール/管理画面を外部公開せずに守りたい。
- OAuth/OIDC を自前実装したくないが“入口で強制ログイン”させたい。
- 前提：LB 経由 or 対応バックエンドに対して有効化。
- Firebase Hosting との関係：Hosting の静的配信に IAP は基本使わない。Cloud Run/GKE など“アプリ側入口”で使う。
NEG（Network Endpoint Group）
- 役割：LB とバックエンド（Cloud Run/GKE/VM）をつなぐハンドル。
- Serverless NEG＝Cloud Run/Functions/App Engine を LB にぶら下げるための論理オブジェクト。
- いつ使う：LB から Cloud Run へトラフィックを出したいときは必須。
- Firebase Hosting との関係：Hosting を使う限り、ユーザーが NEG を作る場面はない（裏側はGoogle管理）。
Cloud Run
- 役割：コンテナのフルマネージド実行（API/SSR/バッチ）。認証（OIDC）、最小スケール、VPC 接続、地域指定など。
- いつ使う：
- Next.js SSR/ISR、画像最適化、Webhook、バックエンド API。
- ランタイムを自由にしたい（Node 以外もOK）。
- Firebase Hosting との関係：Hosting から rewrite で Cloud Run に“同一ドメインで”プロキシ可能。LB なしでOK。