Firebase Hosting

解決する課題

サーバーを用意せずに、静的サイトやフロントエンドを世界中へ高速・安全に配信できます。

• Web サイトや SPA をサーバー管理なしで公開したい
• HTTPS（TLS 証明書）を自動で用意し、独自ドメインも簡単に割り当てたい
• 世界中のユーザーへ CDN で低遅延配信したい
• デプロイを CLI 一発で行い、レビュー用の一時 URL も手軽に共有したい
• 静的配信に加え、一部の処理だけ動的なバックエンドへ橋渡ししたい

主要概念と用語

• サイト / プロジェクト: Firebase Hosting は Firebase（および Google Cloud）プロジェクトに属する。1 プロジェクトに複数の Hosting サイトを持てる（マルチサイト）
• デプロイ / リリース: ローカルの公開ディレクトリ（例 public）をアップロードし、新しいバージョンとして公開する操作。過去バージョンは保持されロールバックできる
• プレビューチャネル: 本番とは別の一時 URL に配信する仕組み。レビューや PR 確認に使い、有効期限付きで自動失効する。本番反映は同じ内容を**ライブチャネルへ昇格（clone）**する
• カスタムドメイン: 独自ドメインを接続すると、Google が証明書を自動でプロビジョニング・更新する
• リライト（rewrites）: 特定パスへのリクエストを Cloud Run / Cloud Functions や SPA の index.html に内部転送する設定
• リダイレクト（redirects）/ ヘッダ（headers）: パスごとに HTTP リダイレクトやキャッシュ制御ヘッダを宣言的に定義する
• firebase.json: 公開ディレクトリ・リライト・リダイレクト・ヘッダなどの配信設定をまとめる構成ファイル
• CDN キャッシュ: 静的アセットをエッジでキャッシュして配信。Cache-Control ヘッダで挙動を制御する

仕様・制限・クォータ

• 静的コンテンツの配信が基本。動的処理はリライト経由で Cloud Run / Cloud Functions に委譲する
• 配信は HTTP/2・HTTPS が標準で、HTTP は HTTPS へリダイレクトされる
• 証明書は自動管理で、独自ドメイン接続後に発行・更新される（手動でのアップロード運用は不要）
• プレビューチャネルには有効期限があり、期限切れで自動的にアクセス不可になる
• 1 デプロイあたりのファイル数・サイズや、サイト数・チャネル数には**上限（クォータ）**があり、無料枠の転送量・ストレージを超えると従量課金（Blaze プラン）になる
• 既定の配信ドメイン（web.app / firebaseapp.com）が自動で割り当てられ、独自ドメインを追加で接続できる

内部の仕組み

デプロイすると、公開ディレクトリの各ファイルは内容ハッシュ単位でアップロードされ、変更のないファイルは再送されずに差分だけが転送されます。確定したバージョンは新しいリリースとしてアトミックに切り替わり、エッジの CDN へ配布されます。ユーザーのリクエストは最寄りのエッジに到達し、キャッシュ可能な静的アセットはエッジから直接返されます。リライト対象のパスだけが、設定された Cloud Run / Cloud Functions のオリジンへ転送されます。

• 各リリースは独立したバージョンとして保持されるため、問題があれば過去バージョンへ即時ロールバックできる
• キャッシュ挙動は各レスポンスの Cache-Control に従う。ハッシュ付きファイル名（app.[hash].js）と長い max-age を組み合わせると、更新は新 URL の取得で確実に反映できる

設計パターン / ベストプラクティス

• ハッシュ付きファイル名 + 長期キャッシュでアセットを配信し、index.html は短命キャッシュにして更新を即反映（cache busting）
• SPA は全パスを index.html へリライトし、API などの一部パスだけ Cloud Run / Cloud Functions へリライトして、フロントとバックを 1 ドメインに統合
• レビューはプレビューチャネルで共有し、確認後にライブへ昇格。CI/CD（GitHub Actions など）でプレビュー URL を自動コメントする運用が定番
• セキュリティ関連ヘッダ（Strict-Transport-Security など）を headers で宣言的に付与
• 不要になった古いバージョンや期限切れチャネルを整理し、ストレージとデプロイ履歴を肥大化させない

運用・監視

• Firebase コンソールでリリース履歴・現在のバージョン・チャネルを確認し、問題時はワンクリックでロールバック
• カスタムドメインの証明書状態・DNS 設定はコンソールで確認できる。ドメイン接続直後は反映に時間がかかる場合がある
• アクセス傾向は Firebase / Google Analytics 連携や、バックエンド側（Cloud Run / Cloud Functions）の Cloud Logging / Cloud Monitoring で把握
• リライト先のレイテンシやエラーはバックエンド側のメトリクスで監視し、静的配信とは切り分けて見る

コスト

Firebase Hosting は主に**保存しているコンテンツ量（ストレージ）と配信した転送量（egress）**で課金されます。無料枠（Spark）に一定のストレージ・転送が含まれ、超過分は従量課金（Blaze）になります。証明書や CDN のキャッシュ自体に追加費用はかかりません。

動的処理をリライトで Cloud Run / Cloud Functions に委譲した分は、Hosting ではなくそれぞれのサービス側の料金になる点に注意します。

セキュリティ

• HTTPS が標準で、独自ドメインの証明書は自動発行・自動更新。手動更新の失念事故が起きにくい
• headers 設定で HSTS やコンテンツ系セキュリティヘッダを宣言的に付与できる
• バックエンドへ橋渡しする処理は Cloud Run / Cloud Functions 側で認証・認可を実装し、Hosting を「公開フロント」、機密処理を「保護されたバックエンド」と分離する
• 配信は静的アセットが中心のため、機密データを公開ディレクトリに置かない（ビルド成果物に秘密情報を埋め込まない）

関連サービス・比較

静的フロントエンドを Firebase Hosting で配信し、動的 API を Cloud Run にリライトで委譲する構成が王道です。両者の役割を比較します。

ハンズオン / CLI例

# 1) Firebase CLI を導入してログイン
npm install -g firebase-tools
firebase login

# 2) プロジェクト直下で Hosting を初期化（公開ディレクトリや SPA 設定を選ぶ）
firebase init hosting

# 3) ローカルでエミュレート確認
firebase emulators:start --only hosting

# 4) 本番（ライブチャネル）へデプロイ
firebase deploy --only hosting

# 5) レビュー用のプレビューチャネルへデプロイ（期限付きの一時 URL を発行）
firebase hosting:channel:deploy preview-pr-123

# 6) 確認後、プレビュー内容を本番へ昇格
firebase hosting:clone SOURCE_SITE:preview-pr-123 TARGET_SITE:live