Firebase Hostingとは｜静的とSPA配信の仕組みとApp Hostingとの選定基準【2026年8月時点】

Firebase Hosting は、ビルド済みの成果物をアップロードするだけでCDN配信とSSLまで揃うホスティングサービスです。設定の入口が firebase.json ひとつに集約されているぶん学習コストは低い一方、SPAのルーティングや動的コンテンツのキャッシュで実装時に迷いが出ます。2026年8月17日時点の公式ドキュメントを実測しながら、Hostingが何をしてくれるのか、どこから先がApp HostingやCloud Runの領分なのかを整理しました。

まとめ：静的とSPAならHosting、SSR前提ならApp Hosting

• 本領は静的サイトとSPAの配信。ファイルはCDNエッジのSSDにキャッシュされ、圧縮もGzipとBrotliから自動で選ばれます。
• SSLはゼロコンフィグで、web.app と firebaseapp.com のサブドメインが無償。カスタムドメインの証明書も自動発行。
• SPAでリロード時に404を出さないには、rewrites で全パスをindexへ内部転送する1行が要ります。
• デプロイの実体はバージョンとリリースとチャネルの3層。プレビューチャネルは既定7日・最大30日で消えます。
• 動的コンテンツはCloud FunctionsやCloud Runへの内部転送で足せますが、60秒で打ち切られて504が返る。推奨リージョンに東京は含まれません。
• 静的は自動でCDNキャッシュされる反面、動的は既定でキャッシュされません。Cache-Control の明示が要ります。
• SSRを常用するならApp Hostingへ寄せたほうが素直。タイムアウト1分対5分、動的配信リージョン3対6の差が効きます。

Firebase Hostingが配信する対象とCDNキャッシュの仕組み

Firebase Hosting が受け取るのは、ビルド後のHTML・CSS・JavaScript・画像といった静的ファイル一式です。公式ドキュメントは、アップロードした各ファイルがCDNエッジのSSDにキャッシュされると説明しており、レスポンスの圧縮もGzipとBrotliから自動で選ばれます（2026年8月17日時点）。サーバーインスタンスもOSも管理対象に入らないため、運用で触るのはビルド成果物と設定ファイルだけに絞られました。

押さえておきたいのは、Hostingが「ファイルサーバー」ではなく「CDNの前段まで含んだ配信基盤」だという点。デプロイした瞬間にエッジへ配る動作まで1つのコマンドに入っているため、CloudFrontやCloud CDNを別途組む工程が丸ごと消えます。逆に、配信経路を細かく制御したい要件では自由度が足りません。デプロイに至るまでのプロジェクト作成とSDK導入の工程はFirebaseの導入手順にまとめています。

web.appとfirebaseapp.comという2つの既定ドメイン

プロジェクトを作った時点で、web.app と firebaseapp.com の2ドメインにサブドメインが無償で割り当てられます。どちらもSSL込みで、証明書の取得や更新の作業は発生しません。検証環境や社内向けの確認用URLなら、カスタムドメインを繋がずこのまま使い切る判断も成立します。ただしいずれも第三者から到達できるURLなので、認証前提の画面を晒す使い方は避けてください。

再デプロイのたびにCDNキャッシュが全て消去される挙動の意味

静的コンテンツは既定でCDNにキャッシュされ、再デプロイすると全キャッシュが自動で消去されます。手動のインバリデーション作業は不要で、デプロイ＝反映という単純な図式が成り立ちました。ファイル名にハッシュを付けるビルド設定と組み合わせれば、古い資産が残る事故もほぼ起きません。裏を返せば毎デプロイでキャッシュヒット率が落ちるため、配信量の大きいサイトではデプロイ頻度自体が設計事項になります。

Firebase Hostingのバージョンとリリースとチャネルの関係

Hostingのデプロイは3つの概念で構成されています。バージョンはコンテンツと設定をまとめた実体、リリースは「いつ誰がどのバージョンを出したか」を記録したデプロイ履歴、チャネルはそのリリースを特定のURLで配信する箱。ライブチャネルが本番ドメインを担当し、任意個数のプレビューチャネルが一時URLを担当する構造です。

この3層はストレージ消費の勘所でもあります。デプロイすると直前のリリースのバージョンも保持されるため、放置すればHostingのストレージが積み上がる。公式ドキュメントはチャネルごとに保持リリース数の上限を設定でき、古いものから削除されると説明しています。無料枠の10GBに近づいたら最初に見るのはここ。

ロールバックとfirebase hosting:cloneの使い分け

切り戻しはFirebaseコンソールでライブチャネルの過去リリースを選び、ロールバックを実行する形です。実体は「同じコンテンツを配信する新しいリリースを作る」動作なので、履歴が巻き戻るわけではありません。障害対応の一次対応としては、再ビルドを待たずに数十秒で戻せる点が効きます。

一方、検証環境の内容をそのまま本番へ持ち上げたい場面では複製コマンドを使います。同一サイト内なら同じバージョンを指す新しいリリースが作られ、別サイトへ複製する場合は新しいバージョンが生成される挙動。ビルドをやり直さずに「検証で確認した現物」を本番へ載せられるため、ビルド非再現性のリスクを潰せます。

firebase deploy --only hosting
firebase hosting:channel:deploy staging --expires 7d
firebase hosting:clone my-site:staging my-site:live

SPAで必要になるrewritesとcleanUrlsの設定を読み解く

SPAをHostingに載せて最初に踏むのが、トップは表示されるのに詳細画面でリロードすると404になる現象です。原因は単純で、Hostingは要求されたパスに対応する実ファイルを探しにいくため、クライアント側ルーターしか知らないパスは存在しないファイル扱いになるから。解決策は rewrites で全パスをindexへ内部転送する設定を1つ足すことでした。

{
  "hosting": {
    "public": "dist",
    "ignore": ["firebase.json", "**/.*", "**/node_modules/**"],
    "cleanUrls": true,
    "trailingSlash": false,
    "rewrites": [
      { "source": "**", "destination": "/index.html" }
    ]
  }
}

この配列は最初に一致したルールが採用される順序依存なので、API向けの内部転送は必ず全パス一致より手前へ置きます。逆にすると全リクエストがindexへ吸い込まれてAPIが死ぬ。「APIだけHTMLが返る」症状が出たら、まずこの並び順を見てください。

firebase.jsonのhostingセクションで指定できる主なキー

cleanUrls を有効にすると拡張子なしのURLで配信され、拡張子付きはリダイレクトされます。既存サイトの移設では旧URLの形と揃うか先に確認しないと、被リンクとインデックスを持つURLが一斉に転送扱いへ変わる。trailingSlash と併せ、移設前に決めておく設定でした。

カスタムドメインの接続とSSL証明書が発行されるまでの待ち時間

カスタムドメインの接続は、所有権確認のTXTレコードを入れてから、AレコードとAAAAレコードをFirebase側へ向ける流れになります。公式ドキュメントに記載されているAレコードのIPは 199.36.158.100（2026年8月17日時点）。CAAレコードを運用しているドメインでは、letsencrypt.org と pki.goog の発行を許可しておかないと証明書が取得できません。

SSL証明書はAレコードをFirebaseへ向けてから最大24時間以内にプロビジョニングされると案内されており、実務上は数時間で終わる場合が多い印象です。ただしこの「最大24時間」を段取りに織り込まないと、切り替え当日に証明書待ちで足止めされます。リリース日の前日にDNSを触る計画は避けたほうが安全でしょう。

制約として、1つのカスタムドメインは1つのHostingサイトにしか接続できません。またapexドメインあたりのサブドメイン数には上限が設けられており、公式ドキュメントは20という数字を示しています。マルチテナントでサブドメインを大量に切る構想があるなら、この上限が設計の前提条件になります。

ダウンタイムを発生させずに既存サイトからドメインを移す段取り

既に稼働中のサイトを載せ替えるときは、簡易セットアップではなく詳細セットアップを選びます。所有権確認のTXTレコードと証明書のプロビジョニングを先に完了させ、最後にAレコードとAAAAレコードの向き先だけを切り替える順番。証明書待ちが切り替え作業の外側へ出るので、切り替え自体はDNSの伝播時間だけで済みます。簡易セットアップでいきなりAレコードを向けると証明書が出るまで警告画面を見せる恐れがあるため、本番ドメインではこの順序差がそのままダウンタイムの有無になりました。

プレビューチャネルを使って本番前の動作確認を分離する運用の作り方

プレビューチャネルは、ライブチャネルとは別の一時URLへ同じサイトを配信する仕組みです。URLは SITE_ID--CHANNEL_ID-RANDOM_HASH.web.app の形式で払い出され、期限は既定で7日、最大30日まで指定できます。期限が切れたチャネルとそのリリースは、24時間以内に削除される予定として扱われる仕様。

ここで見落とされがちなのが、プレビューURLで動くアプリも実プロジェクトのリソースを見にいくという点です。FirestoreもAuthenticationも本番と同じものを参照するため、破壊的な検証をプレビューチャネルで行うと本番データが壊れます。データを分けたいなら、チャネルではなくFirebaseプロジェクト自体を環境ごとに分ける必要がありました。

GitHub Actionsと組み合わせてPRごとにURLを配る

Firebase Hosting は、プルリクエストへのコミットに応じてプレビューURLを自動生成・更新するGitHub Actionを提供しています。レビュアーがローカルでビルドせずに実画面を触れるため、受け入れ確認のやり取りが短くなる。期限を短めに指定しておけばチャネルが際限なく増えることも避けられます。ワークフローの組み方とサービスアカウント認証の手順はFirebaseとGitHub Actionsの連携で実現する自動デプロイを参照してください。

Cloud RunとCloud Functionsを繋いだ動的配信で効く制約

Hostingは静的配信が前提ですが、rewrites の宛先にCloud FunctionsやCloud Runを指定すると、特定パスへのリクエストだけをバックエンドへ流せます。ブラウザから見れば同一オリジンなのでCORSの考慮が消え、認証クッキーの扱いも単純になる。APIを別ドメインに置く構成と比べたときの実利はここに集まります。

"rewrites": [
  {
    "source": "/api/**",
    "run": { "serviceId": "api-server", "region": "asia-east1" }
  },
  {
    "source": "/notify",
    "function": { "functionId": "notify", "region": "us-central1", "pinTag": true }
  },
  { "source": "**", "destination": "/index.html" }
]

制約として大きいのは、Hostingが60秒のリクエストタイムアウトを持つことです。バックエンドの処理が60秒を超えると、利用者にはHTTPステータス504が返ります。レポート生成やファイル変換のような長時間処理は、同期レスポンスではなくジョブ投入と結果ポーリングに分解する設計が要ります。

もう1つ、動的コンテンツの推奨リージョンとして案内されているのは us-west1・us-central1・us-east1・europe-west1・asia-east1 の5つで、東京は含まれません（2026年8月17日時点）。国内利用者向けのAPIを繋ぐなら、地理的に最も近い asia-east1 を選んでもRTTの上乗せは避けられない。レイテンシ要件が厳しい業務系では、この一点でHostingへのAPI同居を見送る判断が妥当になります。

Cloud FunctionsとCloud Runのどちらを後ろに置くか

公式の比較で決定的なのは同時実行数です。Cloud Functionsは1インスタンスあたり1リクエストを処理する前提で、Cloud Runは1インスタンスで最大1,000リクエストまで同時に受けられます。アクセスが跳ねる画面を後ろに置くなら、インスタンス数が線形に膨らむ関数側よりコンテナ側のほうが費用と起動遅延の両面で有利。

言語の自由度も分かれ目です。Cloud Runはコンテナ化できる言語なら動く一方、Cloud FunctionsはJavaScriptとTypeScript中心の構成が前提。既存のフレームワーク資産を持ち込むならCloud Runとはのコンテナ側、Webhook受けの単機能ならGoogle Cloud Functionsとはの関数側、という切り分けになります。

Cache-Controlと__sessionクッキーで詰まりやすい場所

キャッシュの既定値が静的と動的で非対称な点は、実装時に必ず引っかかります。静的ファイルは何もしなくてもCDNに載る一方、Cloud FunctionsやCloud Runから返る動的コンテンツは既定でキャッシュされず、公式ドキュメントはHostingが private を設定すると説明しています。

エッジに載せたい応答には、バックエンド側でヘッダーを明示します。public がブラウザとCDNの双方にキャッシュを許可し、max-age がブラウザの保持秒数、s-maxage が共有キャッシュの保持秒数を指定する役割。共有キャッシュでは s-maxage が max-age を上書きするため、ブラウザには短く、CDNには長く持たせる指定が書けます。

res.set("Cache-Control", "public, max-age=300, s-maxage=600");

キャッシュのキーになるのは、ホスト名・パス・クエリ文字列、そして Vary ヘッダーで指定したリクエストヘッダーです。トラッキング用のクエリパラメータが付いたURLはそれぞれ別エントリとして扱われるので、パラメータの種類が多いサイトではヒット率が落ちます。存在しないURLへの404応答は10分間キャッシュされる点も、デプロイ直後の確認で混乱を招きがちな挙動でした。

そして最も見落とされるのがクッキーの制限です。動的コンテンツへ渡るクッキーは __session のみで、それ以外はバックエンドに届きません。既存のセッション実装をそのまま持ち込むと、ログイン状態が一切引き継がれない現象に遭遇します。公式ドキュメントも、利用者の認可状態でコンテンツを出し分ける場合に限って使うよう促しており、セッションを積むほどキャッシュ効率が落ちるトレードオフを織り込んだ設計が求められます。

App HostingとAmplify Hostingとの違いから選定を決める基準

2026年8月時点の公式比較ページは、SSR機能を持つモダンWebアプリのホスティングにはApp Hostingが適し、Firebase Hostingは静的サイトやSPAに向くと整理しています。Firebase CLIのフレームワーク実験でHostingへSSRアプリを載せている構成については、App Hostingへの移行を推奨する記述も入りました。判断材料を数値で並べると差がはっきりします。

費用面の性格も別物です。Hostingは無料枠にストレージ10GBと1日360MBの転送があり、超過後の転送は0.15ドル毎GB。App HostingはBlaze専用で、2025年8月1日以降の帯域として非キャッシュ分が月10GiBまで無償、その先は0.20ドル毎GiBという体系になっています（2026年8月17日時点）。プロジェクト全体の請求がどう積み上がるかはFirebaseの料金で実額を整理しているので、見積り段階ではそちらを併読してください。

AWS Amplify Hostingと比べたときの判断の分かれ目

他クラウドで同じ役割を担うのがAWS Amplify Hostingです。両者とも「リポジトリを繋いでWebアプリを配信する」箱として似ていますが、決め手になるのは配信対象ではなくバックエンドの所在。認証もデータベースもFirebase側に置くならHosting、既にVPCとRDSがAWSにあるならAmplify側という単純な引力が働きます。

これを無視して配信層だけ別クラウドに置くと、トークン検証やデータ取得がクラウドをまたぐ往復になり、運用の窓口も二重化します。AWS側の詳細はAWS Amplify Hostingとはを参照してください。

受託開発でFirebase Hostingを採用する条件と見送る場面

採用してよいのは、配信物が静的またはSPAで完結し、バックエンドがFirebaseのプロダクト群に寄っており、国内利用者向けの同期APIをHosting経由で流す必要がない案件です。この3条件が揃うとき、インフラ構築工数はほぼゼロに落ち、SSLとCDNの運用も消えます。小規模なコーポレートサイト、社内向け管理画面、キャンペーン用の単発サイトあたりが典型でしょう。

見送るのは次の場面。第一に、レイテンシ要件が厳しい国内業務システムのAPIを同一オリジンに同居させたい場合、動的コンテンツの推奨リージョンに東京がないため要件を満たせません。第二に、60秒を超える同期処理を返す設計を変えられない場合。第三に、WAFやIP制限、詳細なアクセスログといった配信層のガバナンス要件が契約に含まれる場合は、CloudFrontやCloud CDNを自前で組む構成のほうが説明責任を果たしやすくなります。

採用してよい条件と見送ったほうがよい場面の具体的な切り分け方

迷ったときは「SSRを常用するか」を先に問うのが早道です。常用するならHostingに実験的機能を積むのではなくApp Hostingへ寄せる。App Hostingへのデプロイを従来Firebase Studioから流していた案件なら、Firebase Studioの提供終了と引き上げ手順を先に確認してください。SSRが不要でSPAとAPIの分離で足りるなら、Hostingを配信層に置き、APIはCloud Runへ独立させて別ドメインで運用したほうが、リージョン制約もタイムアウト制約も回避できます。

クラウド側の構成そのものを含めて詰める段階に入ったら、要件と既存資産を突き合わせて設計するのが確実です。インフラ構築（AWS・Google Cloud・Azure）では、こうしたホスティング層とバックエンドの配置を含めた構成設計から運用まで対応しています。

よくある質問

Firebase Hostingは無料のまま本番運用できますか？

静的サイトやSPAで転送量が小さければSparkプランのまま運用できます。無料枠はストレージ10GBと1日360MBの転送（2026年8月17日時点）。ただしSparkは無料枠を超えた月の残り期間に該当プロダクトが停止するため、外部公開サイトならBlazeへ上げるほうが安全でしょう。Blazeでも無料枠は同じで超過分だけが従量課金。

SPAでリロードすると404になるのはなぜですか？

Hostingが要求されたパスに対応する実ファイルを探すためです。クライアント側ルーターだけが知っているパスは実ファイルがなく、存在しないURL扱いになります。firebase.json の rewrites に全パス一致のルールを追加し、宛先をindexへ向けると解消。API向けの内部転送を併用するなら、その全パス一致ルールは配列の最後に置いてください。

カスタムドメインのSSL証明書はどれくらいで発行されますか？

AレコードをFirebase Hostingへ向けてから最大24時間以内にプロビジョニングされる、というのが公式の案内です（2026年8月17日時点）。実際は数時間で終わる場合が多いものの、切り替え当日にこの待ち時間を含めると計画が崩れます。稼働中サイトの移設なら詳細セットアップを選び、証明書の準備を済ませてからDNSを切り替えてください。

東京リージョンで動的コンテンツを配信できますか？

Hosting経由の動的コンテンツで公式が推奨リージョンに挙げるのは、us-west1・us-central1・us-east1・europe-west1・asia-east1 の5つで、東京は入っていません（2026年8月17日時点）。国内向けにレイテンシを詰めるなら、APIを内部転送に載せず東京リージョンのCloud Runへ独立配置し、別ドメインで公開する構成が現実的です。

App Hostingへ移行すべきなのはどんなときですか？

SSRを常用する構成に移った時点が目安です。公式比較では、SSRの自動デプロイがHosting側で実験的扱いなのに対しApp Hostingは正式対応、リクエストタイムアウトは1分対5分、動的配信リージョンは3対6、GitHub統合も組み込みという差が示されています。静的とSPAのままなら移行は不要。

関連記事

• Firebaseの料金：無料枠の実数とBlaze超過単価の積み上がりをプロダクト横断で整理。
• FirebaseとGitHub Actionsの連携で実現する自動デプロイ：デプロイをCIから回すワークフローと認証の手順。
• AWS Amplify Hostingとは：AWS側で同じ役割を担うサービスの料金と特徴。
• Cloud Runとは：内部転送先に置くコンテナ基盤の仕組みと課金単位。
• SupabaseとFirebaseの違いを徹底比較：どちらのBaaSを採るかの比較軸。