Firebase

Firebase とは

Firebase (ファイアベース) は、Google が提供するアプリ開発のためのプラットフォームだ。認証・データベース・ストレージ・ホスティングといった、アプリに必要な裏側 (バックエンド) の機能を、サーバーを自分で構築・運用せずに利用できる。こうした形態は BaaS (Backend as a Service) と呼ばれ、クラウド側が用意した既製の機能を組み合わせて裏側を成立させる。サーバーの構築と運用が不要になる分、個人開発やスタートアップの素早い立ち上げで重宝される。

主な機能

機能	役割
Authentication	ログイン・認証を手軽に実装
Firestore	データをドキュメントとコレクションで保存するデータベース
Realtime Database	データベース全体を 1 本の JSON として保持する初期からのデータベース
Cloud Storage	画像・ファイルの保存
Hosting	Web サイトの公開

これらを組み合わせることで、サーバー側のコードをほとんど書かずにアプリを成立させられる。

Firebase は機能の入れ替えがある基盤でもある。2026 年 8 月時点では上記はいずれも現行の機能だが、たとえば短縮 URL を発行する Dynamic Links は 2025 年 8 月 25 日に停止し、それまでに作られたリンクも動かなくなった。使う予定の機能が現行かどうかは、着手前に公式ドキュメントで確認しておく方が安全だ。

2 つのデータベースの違い

データベースが 2 つあるのは、後から設計の異なる Firestore が加わったためだ。公式ドキュメントは 2026 年 8 月時点で、新しく始めるなら Firestore を勧めている。両者の違いは、データの持ち方と課金の軸に出る。

Firestore はデータをドキュメント単位で持ち、ドキュメントの下にさらにコレクションを置いて階層を作れる。複雑なデータでも構造のまま整理しやすい。課金は主に操作の回数、つまり読み取り・書き込み・削除の件数で決まり、通信量と保存量はそれより低い単価で加算される。読み取りの件数は「クエリを満たすために読んだドキュメントと索引エントリ」で数えるため、一覧画面で 100 件表示すれば読み取り 100 件分になる。件数を絞る、必要な分だけ読む、といった設計が費用に直結する。

Realtime Database はデータベース全体が 1 本の大きな JSON ツリーで、単純なデータほど扱いやすい代わりに、階層が複雑になると整理が難しくなる。課金は操作回数ではなく通信量と保存量だけで決まり、単価は Firestore より高い。大きなノードを丸ごと購読すると、変更のたびに転送量として跳ね返る。

リアルタイム性の仕組みはどちらも共通で、クライアントの SDK が変更の通知を受け取って手元のデータを更新する形をとる。オフライン時はローカルに保持し、接続が戻った時点で反映される。

何が嬉しいか

通常、アプリを作るには、サーバーの用意・データベースの設定・認証の実装など、裏側の構築に多くの手間がかかる。Firebase はこれらを肩代わりするため、開発者はアプリの本質的な機能に集中できる。データが即座に同期するリアルタイム性も、チャットや共同編集のようなアプリと相性がよい。

採用時の注意点

手軽さの裏で、いくつか留意点がある。まず、従量課金の軸がサービスごとに違い、Firestore は操作回数、Realtime Database は転送量が主な課金対象になる。どの画面で何回の読み取りが起きるかを意識せずに実装すると、利用者が増えた分だけ費用が積み上がる。単価は改定され得るので、金額の見積もりは公式の料金ページで都度確認する。次に、Firebase はクライアントから直接データベースにアクセスする構成になりやすく、アクセス制御 (セキュリティルール) の設定を誤ると情報漏洩につながる。公式ドキュメントも、クライアントに直接アクセスを許す前提であるためセキュリティルールがデータを守る要になると位置付け、開発中に緩めたルールを本番へ持ち込まないよう注意している。公開したアプリは告知前でも外部から到達できる。さらに、特定サービスへの依存が強まるため、大規模化や他基盤への移行時にコストがかかる。小さく速く始める用途に強い一方、これらの特性を理解して使うことが大切だ。

採用の目安は、サーバー側に置きたい処理がどれだけあるかだ。認証と保存が中心で、画面から直接読み書きして完結するならこの基盤の取り分が大きい。集計や外部システム連携のようにサーバー側で走らせたい処理が増えるほど、その部分を Cloud Functions などへ切り出す設計になり、手軽さは薄れていく。あわせて、データの持ち方をサービス固有の形に寄せすぎず、API 越しに差し替えられる余地を残せるかどうかが、後の移行コストを左右する。