宮崎翼 
Webサービスの技術選定において、バックエンド（DBや認証）の機能比較は盛んに行われますが、フロントエンドを「どこで・どのように」公開するかというホスティング戦略は、意外と後回しにされがちです。
近年、PostgreSQLベースのBaaSである Supabase が人気ですが、Supabaseは戦略的に「Webホスティング機能を持たない」という選択をしています。対して、Google Cloudのインフラに統合された Firebase Hosting は、アプリ公開に必要なすべてをオールインワンで提供してます。
いまだに、私としては、Firebaseを使うべきか？Supabaseを使うべきか？明確でない点も多いので、こういう場合はFirebase 、こういう場合はSupabaseという点で切り替えができるように、一つ記事にしてみます。今回はFirebase。
本記事では、このアーキテクチャの違いが開発現場にどのような影響を与えるのか、具体的な事例とともに解説します。
1. FirebaseとSupabaseの構造的な違い
技術選定の際、まずこの構造的な違いを理解することが重要です。
| 特徴 | Firebase | Supabase |
|---|---|---|
| 戦略 | All-in-One Platform | Best-of-Breed (適材適所) |
| ホスティング | 標準搭載 (Hosting) | なし (Vercel/Netlify等を利用) |
| 開発体験 | 1つのCLI・コンソールで完結 | DBとホスティングで管理画面が分かれる |
Supabase + Vercel という構成は、各分野のベストなツールを使える素晴らしい組み合わせですが、インフラが分散するため管理コストは増えます。 一方、Firebaseは 「認証もDBもホスティングも、すべて1箇所で管理する」 ことによる圧倒的な開発速度とメンテナンス性の高さが最大の武器です。
2. どんなケースで違ってくるか？：会員制情報サイト（サンプル）
Firebase Hostingの統合環境が具体的にどう役立つのか、以下のプロジェクトを例に見てみましょう。
- プロジェクト名: 会員制技術記事サイト（サンプル）
- 技術スタック: React (SPA) + Firebase
- 公開ドメイン:
www.sample-tech-insight.jp
メリット①：APIサーバー不要の「リライト機能」
Webアプリ開発で最も厄介な問題の一つが、フロントエンドとバックエンドのドメイン違いによる CORS（クロスドメイン）エラー です。
Firebase Hostingでは、firebase.json に設定を書くだけで、特定のURLパス（例: /api/*）へのアクセスを、内部的にCloud Functionsへ転送（リライト）できます。
設定例 (firebase.json):
"rewrites": [
{ "source": "/api/**", "function": "apiHandler" },
{ "source": "**", "destination": "/index.html" }
]これにより、ブラウザからは「同じドメイン（www.sample-tech-insight.jp）にアクセスしている」ように見えるため、面倒なCORS設定や認証トークンの受け渡しトラブルから完全に解放されます。これはホスティングとバックエンドが統合されているFirebaseならではの強みです。
メリット②：インフラゼロで実現する「プレビュー環境」
「プルリクエストを作ったら、その変更を確認できるURLを自動発行したい」。 モダンな開発では必須の要件ですが、Firebaseなら追加契約なしで、CLIコマンド一本で実現します。
firebase hosting:channel:deploy pr-feature-loginこれにより生成される一時的なURLは本番環境と隔離されており、有効期限を設定することも可能です。Vercel等でも同様の機能はありますが、バックエンド（Functions）の変更も含めて1つのコマンドでプレビューできるのは大きな利点です。
メリット③：高度なセキュリティ要件への対応（マルチサイト）
さらに高度な活用例として、「1つのプロジェクトで複数のサイトを公開する（マルチサイト）」 機能があります。
例えば、SaaS開発において「アプリ本体（app.service.com）」と「ユーザー作成コンテンツ（user-content.com）」でドメインを分け、セキュリティ境界（サンドボックス）を作りたい場合を考えます。 Firebase Hostingなら、同じプロジェクト内で簡単にターゲットを追加し、ドメインごとに異なるデプロイ設定を管理できます。
- Site A (Main): 認証必須、APIアクセスあり
- Site B (Assets): 認証なし、静的ファイル配信のみ
このように複雑なセキュリティ要件も、Googleのインフラ上で一元管理できる点は、エンタープライズ用途でも安心材料となります。
3. 比較：Supabaseで同じことを実現するには？
Supabaseを選択した場合、これらの機能はホスティングパートナー（VercelやNetlifyなど）側の機能を使って実現します。「できない」わけではなく、「組み合わせる必要がある」という点がポイントです。
| 実現したいこと | Firebase Hosting の場合 | Supabase + Vercel の場合 |
|---|---|---|
| APIリライト | firebase.json で設定 | next.config.js や vercel.json で設定 |
| プレビュー環境 | CLIコマンド (firebase hosting:channel:deploy) | GitHub Pull Request と自動連携 (設定不要) |
| マルチサイト | 同一プロジェクト内でターゲット追加 | Vercel上で別プロジェクトとして作成しドメイン設定 |
実装のアプローチ:
- リライト機能: VercelのRewrites機能を使い、
/api/*へのリクエストをSupabase Edge FunctionsのURLへ転送するよう設定します。 - プレビュー環境: VercelはGitHubとの連携が非常に強力で、PR作成と同時に自動でプレビューURLが発行されます。この手軽さはVercelの大きな強みです。
- マルチサイト: 「本体サイト」と「アセットサイト」でリポジトリ（またはビルドコマンド）を分け、Vercel上でそれぞれ別のプロジェクトとしてデプロイすることで実現可能です。
4. まとめ：開発体験（DX）を最優先するなら
Supabaseはデータベースに全振りしているので、データ自動構築はとても便利なんですよね。シンプルに、ホスティングを必要としないネイティブアプリ開発なら、まずSupabaseで良さそう。
「アプリをWeb公開して運用する」というフェーズまで見据えると、Firebase Hostingの 「統合された開発体験」 は依然として強力です。
- インフラ管理を1つにまとめたい
- CORSなどのネットワーク設定で悩みたくない
- バックエンドも含めたプレビュー環境が欲しい
これらのニーズがある場合、Firebase Hosting（およびFirebaseエコシステム）を選択することは、チームの開発効率を考える上で武器になります。
