先に要点
- Firebase は Google が提供する BaaS(Backend as a Service)。認証・データベース・ホスティング・サーバーレス関数を、バックエンドを自前で建てずに使える。
- 主役は4つ。Authentication(認証)、Firestore(NoSQL データベース)、Hosting(静的配信)、Cloud Functions(サーバーレス関数)。リアルタイム同期とモバイル SDK の強さが看板。
- 料金プランは2つだけ。Spark(無料) と Blaze(従量課金)。無料枠は十分広いが、Cloud Functions は Blaze に上げないと使えない点が最初の関門。
- SQL を使い続けたいなら Supabase、非構造データとモバイル中心・Google エコシステムなら Firebase、という棲み分けが2026年の実務感覚。
「Firebase ってログイン機能を簡単に付けられるやつでしょ？」「サーバーを書かなくてもアプリが作れるって本当？」「無料って聞いたけど、いつ課金されるの？」── Firebase は2011年に登場し、Google に買収されてからは Google Cloud と深く統合され、2026年現在もモバイル / Web アプリのバックエンド基盤として定番の地位にあります。
ざっくり言うと、Firebase は バックエンドを自前で構築・運用せずに、認証・データベース・配信・サーバーレス処理をまとめて借りられるサービス群 です。本記事では、2026年6月時点の情報をもとに、とは / 主要機能 / 料金 / 始め方 / Supabase との違い / 採用判断 を実務目線で整理します。料金や機能は変動するため、最終的な数字は 公式の料金ページ で必ず確認してください。
Firebase とは何か
Firebase は、Google が提供する BaaS(Backend as a Service) です。Web / iOS / Android のアプリ開発で必要になる「裏側の機能」を、API とマネージドサービスとして提供します。開発者はサーバーの構築・スケーリング・OS パッチ・DB 運用といった作業から解放され、フロントエンドの実装に集中できます。
もともと Firebase は「リアルタイムにデータを同期する小さな DB」から始まりました。そのため、クライアントから直接サービスを叩く 設計と、データの変更が即座に全端末へ反映されるリアルタイム同期 が今も Firebase の核です。チャット、共同編集、ライブダッシュボードのような「画面がリアルタイムで動く」アプリと相性が良いのはこの出自によります。
Google Cloud との関係
Firebase の多くの機能は内部的に クラウド 基盤 Google Cloud(GCP)の上に乗っている。Firestore や Functions は GCP のサービスと同じ実体を別の入口から使う形。
モバイルが第一
iOS / Android の SDK が手厚く、オフライン対応やプッシュ通知まで揃う。「モバイルアプリのバックエンドを最速で立てる」用途で特に強い。
Firebase でできること(主要4機能)
Firebase は十数個のサービスの集合体ですが、実務で軸になるのは次の4つです。まずここを押さえれば「Firebase でアプリが作れる」状態になります。
| 機能 | 役割 | 主な使いどころ |
|---|---|---|
| Authentication | ユーザー認証(ログイン) | メール / パスワード、Google・Apple・GitHub などのソーシャルログイン、電話番号認証 |
| Firestore | NoSQL ドキュメントデータベース | ユーザーデータ、投稿、設定などの保存とリアルタイム同期 |
| Hosting | 静的サイト・SPA の配信 | フロントエンドの公開、独自ドメイン、自動 SSL、CDN 配信 |
| Cloud Functions | サーバーレス関数 | Webhook 処理、課金連携、データ整形、通知送信などのサーバー側ロジック |
Authentication(認証)
Authentication は、ログイン機能を数行で導入できるサービスです。メール / パスワードに加え、Google・Apple・GitHub・Facebook などの OAuth 2.0 ソーシャルログイン、電話番号(SMS)認証、匿名認証に対応します。認証が済むと JWT ベースの ID トークンが発行され、これを使って Firestore などへのアクセス権を制御します。「ログイン UI とトークン管理を自分で書かなくてよい」のが最大の価値です。
Firestore(データベース)
Firestore は Firebase の中心となる NoSQL ドキュメントデータベース です。データは「コレクション」の中に「ドキュメント」が並ぶ階層構造で保存され、リレーショナル DB のような JOIN は基本的にありません。代わりに、クライアントが購読した範囲のデータ変更がリアルタイムで全端末に流れてくる のが強みです。WebSocket を自分で扱うことなく、リアルタイム機能が手に入ります。
アクセス制御は セキュリティルール という専用言語で記述します。「ログイン中のユーザーは自分のドキュメントだけ読み書きできる」といった条件をルールファイルに書き、Firestore 側で強制します。クライアントから直接 DB を叩く構造なので、このルールが認可の要になります。
Firestore の課金単位
容量だけでなく「読み取り・書き込み・削除のオペレーション回数」で課金される。リストを1回表示しただけでドキュメント数ぶんの読み取りが発生する点に注意。
クエリの制約
JOIN や横断的な集計が苦手。リレーションを多用する設計だとデータの持ち方を「非正規化」で工夫する必要がある。ここが SQL 派のつまずきどころ。
もう一つの DB
古くからの Realtime Database も健在。シンプルな JSON ツリー構造で、超低レイテンシ用途では今も使われるが、新規は Firestore が標準。
Hosting(ホスティング)
Hosting は、静的サイトや SPA を配信するためのサービスです。CDN による高速配信、独自ドメイン、自動 SSL 証明書がすべて込みで、コマンド一発でデプロイできます。フロントエンド(React / Vue など)を Hosting で配り、データは Firestore、サーバー処理は Cloud Functions、という分担が定番構成です。
Cloud Functions(サーバーレス関数)
Cloud Functions は、サーバーを管理せずにバックエンドのコードを動かす サーバーレス 実行環境です。「Firestore に新しいドキュメントが追加されたら通知を送る」「決済 Webhook を受けて在庫を更新する」のように、イベントや HTTP リクエストをトリガーに関数を実行します。クライアントに置けない秘密鍵を使う処理や、信頼できる場所で行うべきロジックはここに置きます。注意点として、Cloud Functions は無料の Spark プランでは使えず、後述の Blaze プランへの移行が必要 です。
このほか、ファイル保存の Cloud Storage、プッシュ通知の Cloud Messaging(FCM)、アプリの利用状況を見る Analytics、クラッシュ収集の Crashlytics、機能フラグの Remote Config なども Firebase に含まれます。
Firebase の料金(Spark 無料 / Blaze 従量)
Firebase の料金プランは 2つだけ でシンプルです。無料の Spark と、従量課金の Blaze。以下は2026年6月時点で公式料金ページに記載されている代表的な数値です。料金は改定されるため、契約前に必ず 公式の料金ページ で最新を確認してください。
| 項目 | Spark(無料) | Blaze(従量課金) |
|---|---|---|
| 料金体系 | 完全無料・上限到達で停止 | 無料枠を超えた分だけ従量課金 |
| Authentication | 月間アクティブユーザー(MAU)5万まで無料 | 5万 MAU まで無料、超過分は従量 |
| Firestore 読み取り | 5万回 / 日 | 5万回 / 日まで無料、超過分は従量 |
| Firestore 書き込み | 2万回 / 日 | 2万回 / 日まで無料、超過分は従量 |
| Firestore 保存容量 | 1 GiB | 1 GiB まで無料、約 $0.18/GiB 前後 |
| Cloud Functions | 利用不可 | 月200万呼び出しまで無料、超過は $0.40/100万 |
| Hosting 保存容量 | 10 GB | 10 GB まで無料、超過は約 $0.026/GB |
| Hosting 転送量 | 360 MB / 日 | 無料枠超過分は約 $0.15/GB |
ポイントは Blaze も無料枠をそのまま内包している ことです。Blaze に切り替えても、上の無料枠ぶんは引き続き無料で、それを超えた分だけ課金されます。つまり「無料枠の範囲なら Blaze でも $0」です。にもかかわらず Blaze へ上げる最大の理由は、Cloud Functions が Spark では一切使えない 点と、外部 API への通信(アウトバウンド)が Spark では制限される点にあります。少しでもサーバー側処理を書くなら、実質 Blaze が前提になります。
無料の段差に注意
Spark は上限に達すると機能が停止する(課金されない)。本番なら Blaze + 予算アラートで「止まらないが青天井でもない」状態を作るのが定石。
読み取り課金の罠
Firestore は表示のたびに読み取りが走る。一覧を無限スクロールで何度も取得する設計だと、思った以上に読み取り回数が膨らみ請求が伸びる。
Firebase の始め方
最小構成で動かすまでの流れは次のとおりです。Web アプリを例にしています。
つまずきやすいのは セキュリティルールを後回しにすること です。開発初期に「全許可」のテストルールで始め、そのまま本番に出して情報漏えい、という事故が定番です。ルールは「最初から書く」のが鉄則。もう一つは、Cloud Functions を書こうとして「課金を有効にしてください」で止まる点で、これは Blaze 移行が必要というだけなので、予算アラートを設定したうえで切り替えれば問題ありません。
Firebase と Supabase の違い
Firebase の比較対象として必ず挙がるのが Supabase です。どちらも BaaS ですが、根本思想が逆です。Firebase は NoSQL(Firestore)前提でリアルタイムとモバイルに強い、Supabase は PostgreSQL ベースで SQL とリレーションをそのまま使える。ここが選択を分ける最大の軸です。
| 観点 | Firebase | Supabase |
|---|---|---|
| データベース | Firestore(NoSQL ドキュメント) | PostgreSQL(リレーショナル) |
| クエリ | JOIN なし・非正規化前提 | SQL・JOIN・集計が普通に書ける |
| 認可 | セキュリティルール(専用言語) | Row Level Security(SQL ベース) |
| リアルタイム | 非常に強い(出自そのもの) | 対応(Postgres の変更を購読) |
| API スタイル | 独自 SDK / トークン | 自動生成 REST / GraphQL 風 / SDK |
| オープンソース | クローズド(Google 専有) | OSS・セルフホスト可能 |
| エコシステム | Google / モバイル SDK が厚い | Postgres 資産・Vercel と好相性 |
| ロックイン | 強め(独自 DB・移行が重い) | 逃げやすい(普通の Postgres) |
判断軸はシンプルです。モバイルアプリ中心・リアルタイム同期が主役・Google エコシステム(Analytics、FCM、AdMob)を使うなら Firebase。SQL の知識を活かしたい・リレーションが多い・ベンダーロックインを避けたい・既存 Postgres 資産があるなら Supabase。「Firestore の非正規化設計に違和感がある」と感じるチームは、たいてい Supabase の方が楽に進みます。逆に「とにかくモバイルで最速に、認証もプッシュ通知も一括で」なら Firebase が圧倒的に速いです。
どんな案件で選ぶ / 避けるか
公式の機能一覧だけでは判断できない、現場での選び分けを整理します。
避けたほうがよい案件
複雑なリレーションや集計レポートが中心の業務システム、強い SQL クエリが要る分析基盤、ベンダーロックインを嫌う長期プロダクト。これらは Postgres 系(Supabase / Neon)が無難。
コスト面の判断
読み取りが多い一覧主体のアプリは Firestore の従量課金が読めなくなりやすい。トラフィックが予測しにくい大規模 read 中心なら、課金モデルを事前にシミュレーションする。
2026年の Vercel や React Server Components を軸にした Web スタックでは Supabase が選ばれる場面が増えましたが、ネイティブモバイルアプリのバックエンドとしては Firebase が依然として第一候補 です。「Web は Supabase、モバイルは Firebase」と、プロジェクト性質で使い分けるのも現実的な戦略です。
Firebase に関するよくある質問
Q. Firebase は無料で使えますか？
A. はい、Spark プランで無料で始められます。認証は月5万 MAU、Firestore は1日あたり読み取り5万回・書き込み2万回などの無料枠があります。ただし Cloud Functions は無料プランでは使えず、サーバー側処理を書くなら従量課金の Blaze へ移行が必要です。最新の無料枠は 公式の料金ページ で確認してください。
Q. Spark と Blaze の違いは何ですか？
A. Spark は完全無料で、上限に達すると機能が停止します(課金はされません)。Blaze は同じ無料枠を内包したうえで、超えた分だけ従量課金される方式です。無料枠の範囲なら Blaze でも料金は $0 です。本番運用や Cloud Functions の利用には Blaze が前提になります。
Q. Firestore と Realtime Database はどちらを使うべきですか？
A. 新規開発は基本的に Firestore を選びます。クエリ機能・スケーラビリティ・構造化のしやすさで上回るためです。Realtime Database は単純な JSON ツリーで超低レイテンシが欲しい一部用途では今も有効ですが、最初に迷ったら Firestore で問題ありません。
Q. Firebase は SQL を使えますか？
A. Firestore は NoSQL のため SQL は使えず、JOIN もありません。リレーションや集計を多用したい、SQL の資産を活かしたい場合は Supabase など PostgreSQL ベースの BaaS が向きます。
Q. 高額請求になる事故を防ぐには？
A. Blaze に切り替えたら、まず Google Cloud の予算アラートを設定します。加えて Firestore の読み取り回数を抑える設計(過剰なリアルタイム購読や無限スクロールの取得を見直す)が効きます。読み取り課金が請求の主因になりやすい点を覚えておくと安全です。
Q. Firebase はモバイルアプリ専用ですか？
A. いいえ。iOS / Android の SDK が手厚いのは事実ですが、Web 向けの SDK も充実しており、Hosting で SPA を配信できます。モバイルとの併用も含め、Web 単体でも普通に使えます。
Q. Firebase からの移行は難しいですか？
A. Firestore は独自のデータモデルとセキュリティルールに深く結びつくため、移行コストは小さくありません。将来の乗り換え余地を重視するなら、最初から Postgres 系を選ぶか、データアクセスを抽象化しておくのが現実的です。ロックイン回避を最優先するなら Supabase の方が逃げやすい構造です。
参考リンク
- Firebase: 公式サイト
- Firebase: 料金ページ(Spark / Blaze)
- Firebase Docs: 公式ドキュメント
- Cloud Firestore: ドキュメント
- Firebase Authentication: ドキュメント