Firebase Realtime Database（RTDB）のシステム開発は、要件整理から定着まで6段階で進みます。
最初に業務を整理し、RTDBを使う範囲を決めてから、設計・開発へ進みます。テスト、稼働、定着まで進めると、リアルタイム同期を必要な業務に活かせます。
▼全体ガイドの記事
・Firebase Realtime Databaseのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Firebase Realtime Databaseのシステム開発の全体像
RTDBの設計では、リアルタイム同期が必要なデータと、検索・集計・厳密な整合性が必要なデータを分けて考えます。RTDBのデータは1つの大きなJSONツリーに保存され、クライアントへ低遅延で同期されます。
RTDBは単純な状態共有に向いています。ただし、複雑な業務データを1つの階層に詰め込むと、読み取り範囲や権限の設計が難しくなります。
RTDBが向いている業務とシステム
更新した状態をほかの利用者へすぐ知らせる業務では、RTDBが候補になります。データが比較的単純で、読む・書き換える・変更を購読する操作が中心であれば、検証もしやすいといえます。
- 利用状況の共有：チャットやオンライン・オフラインのプレゼンス
- 現場の状態表示：店舗・倉庫の受付状況や作業員の位置情報
- 速報・共同作業：在庫速報、IoT機器の稼働状態、複数人で見る業務ボード
この構成であれば、サーバーの調達やパッチ適用の手間を減らせるため、短期間で検証を進められます。
受発注や会計のように、複数テーブルの集計、複雑な検索、厳密なトランザクションが中心の業務では、Cloud SQLや既存の基幹データベースが適する場合があります。
RTDBで現在の状態を共有し、Firestoreを文書や検索に、Cloud SQLを正規化したマスタと集計に使い分ける方法も有効です。同期する対象は、業務ごとに決めます。
開発時に組み合わせるFirebaseの構成要素
RTDBだけで完成する業務システムは少なく、認証や権限、通知などを組み合わせて構成します。
- 認証・権限：Firebase Authentication、Security Rules、App Check
- 処理・配信：Cloud Functions、Cloud Storage、Cloud Messaging、Hosting
- 運用確認：監視・ログを組み合わせ、利用状況を追跡
Authenticationで利用者を識別し、そのuidやロールをSecurity Rulesで参照することで、パスごとの読取（read）と書込（write）の権限を定めます。
Cloud Functionsは、書き込みを契機とした通知や集計、外部APIとの連携に使えます。なお、電話番号認証を使う場合は、SMSの費用が別途かかります。
Cloud Functions、Storage、Cloud Loggingも、使用量に応じて課金されます。また、Firebase公式は新規顧客にCloud Firestoreを推奨しています。
Firebase公式の説明では、RTDBは単純なデータモデルや低遅延同期に適し、規模が限定的なケースに向くとされています（出典: Firebase公式「Cloud FirestoreまたはRealtime Database」、2026年3月更新）。
選定の理由は、見積書と設計書に残しておきます。こうしておくと、後から採用理由を説明しやすくなります。
Firebase Realtime Databaseのシステム開発の進め方
開発は6段階で進みます。なかでも要件整理と設計・開発で決めた内容が、後の手戻りを大きく左右します。各段階は次の見出しから順に説明し、段階ごとに終了条件を決めておくと、画面が動いただけで本番化する事故を避けられます。
データ構造やRulesは、後から変えるとクライアントやFunctions、既存連携の修正が続きます。そのため、最初の2段階（要件整理と選定）に時間をかけます。
1. 要件整理フェーズでのリアルタイム性の定義
まず、現状と理想の業務フローを整理します。そのうえで、誰がいつどのデータを見て更新し、更新後に誰へ通知するかを書き出します。
電話や紙、Excelなどに残る例外処理も対象に含めます。ここを拾い漏らすと、現場で使えないシステムになる恐れがあります。
要件整理で仮置きする利用条件と成果物は、負荷・データ、運用・応答、成果物の3つのまとまりでそろえます。
- 負荷・データ：利用者数、ピーク同時接続、毎秒の書き込み、画面ごとの読込量、保持期間
- 運用・応答：個人情報、許容停止時間、RTO・RPO、「リアルタイム」の許容遅延
- 成果物：業務フロー、権限一覧、画面・API一覧、データ項目表、非機能要件、対象外範囲
許容遅延は、業務ごとに100ミリ秒以内か数秒以内かを分けて決めます。
どのデータがリアルタイム更新を必要とするか、検索・集計にどこまで頼るかを確認します。利用者ロールや個人情報の範囲、現場の受入担当も、この段階で押さえておきます。
発注者側が担うマスタ整備とデータクレンジングの担当も明記します。データが提供されないまま開発会社だけが責任を負うと、移行の納期と費用が膨らみがちです。
2. 選定フェーズでのRTDBの担当範囲の決定
RTDBは、Cloud Firestore、Cloud SQL、既存データベースと機能ごとに比べ、同期を担う範囲を定めます。
- RTDBが候補：低遅延同期が主目的で、単純なデータモデルと負荷が想定上限内
- 併用を検討：複数条件検索・並べ替え、厳密な集計、長期分析が中心
Firebase公式資料によると、2026年時点のスケール目安は、1データベースあたり約20万同時接続、毎秒1,000回の書き込みとされています。上限を超える場合は、複数データベースへのシャーディングが必要です（出典: Firebase公式「Realtime Database Limits」、2026年8月5日更新）。
判断では、上限ぎりぎりを前提にせず、通常時、繁忙時、障害復旧時の余裕を見込みます。
RTDBの対応ロケーション一覧には、米国、ベルギー、シンガポールが掲載されています。一方で、日本リージョンは掲載されていません。
個人情報を扱う案件で日本リージョンが必要な場合は、保管場所や越境移転を専門部署と確認します。契約や社内規程との整合も、あわせて見ます。
インスタンスは作成後にロケーションを変えられないため、事前に決めておきます（出典: Firebase公式「Realtime Databaseのロケーション」、2026年3月27日更新）。
3. 設計・開発フェーズでのデータ構造とRulesの確定
RTDBはJSONツリーでデータを保持するため、パスは画面から逆算して設計します。全社員のデータを1つの大きなノードに置かず、読む範囲に応じて部署別、案件別、ユーザー別に分けます。
同じ情報を非正規化して複数箇所に置く場合は、更新元と同期・削除の方法、整合性を担保するFunctionを記録しておきます。
listenerの範囲と取得条件を定めておくと、読みすぎや不要な通信を防げます。
- 読込設計：狭いパス、ページング、インデックス、取得件数の上限の設定
- 購読管理：不要になったlistenerの解除
- 権限設計：パスとデータ項目に合わせたSecurity Rulesの作成
広い階層を購読すると、1件の小さな変更でも大量の転送を招き、表示速度と料金に影響します。
Rulesは公開直前にまとめて書かず、データ設計と同時に作成します。Firebase公式は、Rulesをスキーマと同様に扱い、Local Emulator SuiteとCIでテストすることを推奨しています（出典: Firebase公式「Security checklist」、2026年7月確認）。
開発、ステージング、本番のFirebaseプロジェクトは分けておきます。Authenticationから監視までの各サービスも、環境ごとに管理します。
Rulesの定義とFunctionsはGitで管理します。設定やテストコードも含めて変更履歴を残し、本番のRulesは手作業で変えない運用にします。
納品物には、コードに加えてデータモデルとRulesを含めます。さらに、CI/CDや環境変数の管理方法、インフラ構成も含めます。また、運用手順と障害連絡先も、納品物として受け取ります。
4. テストフェーズでの権限・負荷・再接続の検証
権限の検証では、利用者ロールごとのreadとwriteを確かめます。そのうえで、他案件の読取やURL変更のような不正な操作と、拒否の記録も見ておきます。
- 利用者別の権限：認証前、一般利用者、管理者、退職者、削除済みユーザー
- 不正な操作：他案件の読取、URL・パス変更、必須項目や型の違反
- 拒否の監視：拒否理由と回数を記録する。拒否された通信も費用に影響し得る
負荷試験では、通常時とピーク時の接続数と書き込みを再現します。読取バイト数や切断・再接続も、あわせて試します。
オフラインからの復帰や、同じデータへの同時更新も試します。公式の制限値は、目標ではなく上限の目安として扱います。
毎秒1,000回の書き込みが必要なときは、その数まで確認したうえで、ピーク時の余裕も見ておきます。障害後に再接続が集中する場面も検証します。
受入テストでは、現場が実業務を最初から最後まで操作します。マスタの欠損や表記揺れ、重複を確認します。過去データの保持期限も見ておきます。
移行リハーサル、バックアップからの復元、障害時の切り戻しは、受入条件に含めます。合格基準は、応答時間と正確性で定めます。権限、監査記録、復旧時間についても、基準を決めておきます。
5. 稼働フェーズでの監視・課金・復旧の準備
本番の前に、接続数や保存・ダウンロード量、読書きエラーを確認できる状態にします。加えて、Rules拒否やFunctionsの失敗、応答時間も確認できるようにします。
Blazeプランでは、Budget alertsを設定します。ただし、公式の説明でも、予算アラートが利用量や請求を自動で止めるわけではないとされています。
通知が届いたあとに誰が確認し、どの機能を止め、どこへ報告するかまで決めておきます。バックアップの運用条件は、事前に定義しておきます。
- バックアップ：取得頻度、保持期間、暗号化、復元権限の定義
- 復元検証：復元テストの頻度と、別DB・Storageへの退避後の整合性の確認
たとえば、RTOが2時間なら、2時間以内に復旧できるかを実測します。RPOが24時間なら、最大24時間分のデータ損失を業務側が受け入れられるかを確認します。
数値を決めていない運用計画では、障害時に判断できません。
6. 定着フェーズでの利用状況の把握と改善
定着の段階では、利用状況を把握し、段階的に導入し、運用体制を整えながら改善を続けます。
- 利用状況：利用者数、入力完了率、エラーとRules拒否、画面別読取量、問い合わせ、手作業への逆戻りを追う
- 段階導入：1部署や1業務で試し、現場で使えることを確かめてから範囲を広げる
- 日常運用：マスタ更新、権限変更、異動・退職、データ削除を機能追加とあわせて管理する
- 運用体制：管理者による利用者の追加・停止、現場手順、問い合わせ窓口、月次費用の確認者を整える
- 保守・引き継ぎ：保守委託時も自社で必要な管理権限を保つ
Rulesや依存ライブラリの更新手順を設けたうえで、四半期または半期ごとに、権限を洗い出します。
委託契約では、Firebaseプロジェクトや請求アカウントを自社で管理できるようにします。Rulesやバックアップへのアクセス権も、自社が持ち続けられる形にします。
Firebase Realtime Databaseのシステム開発の費用相場
Firebaseの利用料と、開発会社へ支払う開発費は分けて考えます。RTDBを使えば、サーバーの初期構築や一部のインフラ運用を圧縮できます。
一方で、要件定義や画面（UI）、業務ロジックの費用は残ります。加えて、Security Rulesの作成やテスト、移行にかかる作業も残ります。教育や保守も含め、適用範囲と運用内容をもとに予算を組みます。
要件の複雑さで変わる開発費の目安
RTDB単体の請負相場を示す公的統計は確認できません。そのため、以下は業務システムの相場とRTDBの特性をもとにした初期予算の推定です。
- 検証版：認証、基本CRUD、リアルタイム表示、最低限のRulesで100万〜300万円、1〜2か月
- 小規模MVP：管理画面、通知、ログ、テスト、初期運用設計までで300万〜800万円、2〜4か月
- 業務システム：複数ロール、API・既存DB連携、監査ログ、移行、負荷試験を含み800万〜2,000万円、4〜9か月
- 大規模構成：高可用性、複数アプリ、大規模移行、複雑な連携を含む場合は2,000万〜5,000万円超、9か月〜1年半以上になる可能性があります
画面数や品質基準、外部連携が増えると、検証版の幅を超えます。いずれも確定見積ではなく、要件が固まる前の予算幅です。
Google Cloudの公開事例では、ポノスがゲーム開発で性能とコストを再検討し、App EngineとCloud SQLを組み合わせています。RTDBを使わない判断も、クエリや課金の特性に応じた役割分担の一例です（出典: Google Cloud「ポノス株式会社の導入事例」、公開事例）。
Firebaseの利用料の試算方法
利用料は、プランごとの無料枠と超過単価を基にして試算します。その際は、実際の保存量と通信量を当てはめます。
- Sparkの無料枠：RTDBの保存1GB、ダウンロード10GB/月
- Blazeの超過単価：保存5ドル/GB/月、ダウンロード1ドル/GB
- 利用例：保存5GB・通信100GB/月で約1万6,500円/月
- 利用例：保存20GB・通信500GB/月で約8万7,000円/月
Blazeでも無料枠は維持されます（出典: Firebase公式「Pricing」、2026年8月確認）。
1ドル150円で換算すると、保存は約750円/GB/月、ダウンロードは約150円/GBです。実際の請求は、為替や他製品、通信・暗号化の負荷などによって変わります。
利用例は、無料枠を差し引いた後の保存4GBと通信90GB、保存19GBと通信490GBで計算した、RTDBのみの概算です。
Functions、Storage、SMS認証の費用は含まれず、ログやネットワークも対象外です。そこで、読込ノードを狭め、短時間の接続を繰り返さず、使用量画面とBudget alertsを用意します。
Rulesによる拒否や、接続時のプロトコル・暗号化の負荷も、課金の対象になり得ます。保存だけでなく、送信トラフィックや接続・読み書きの通信も含まれます。
見積もりでは、保存GBに加えて、操作ごとの読取バイト数や1人あたりの操作回数を仮定します。さらに、同時接続時間やピーク時の再接続も仮定に入れます。
見積もりを取る際のポイント
総額を比べる前に、各社が同じ条件で見積もっているかを確認します。画面数が同じでも、ロールやデータ、Rulesの違いで工数は変わります。連携、移行、試験、保守も、工数を左右します。
RFPに利用者像とピーク負荷を記載すると、RTDB中心の案、FirestoreやSQLを併用する案、RTDBを使わない案を比べやすくなります。
見積前の利用条件と納品物の確認
見積依頼には、利用条件をそろえて記載します。未確定の項目は幅で示すと、提案会社がリスクを含めた見積の幅を出せます。
- 規模：対象環境、画面数、ロール、同時接続、書き込みレート、保存・通信量と保持期間
- 機能・運用：連携先、認証、通知、個人情報、希望リージョン、RTO・RPO
- 計画：リリース希望時期と未確定条件
納品物には、要件定義と画面仕様、データモデルとRulesを含めます。テスト仕様と結果、負荷試験、移行、バックアップと復元の手順も、納品物の対象にします。
CI/CDやソースコードが納品されるかを確認します。あわせて、Firebaseの権限、運用手順書、教育資料も確認対象に入れます。
特に、Rules、Terraform、Functionのコードがない場合は、保守会社の変更や障害調査が難しくなります。
見積書の「開発一式」に何が含まれるかは、明細で示してもらいます。
開発会社の比較軸：技術・運用・引き継ぎ
提案会社への確認は、技術、運用、引き継ぎの3軸でそろえます。
- 技術：RTDBの設計、別DBとの分担、負荷試験と合格基準、機能別の採用実績
- 運用：障害対応、課金監視、脆弱性対応、復元、追加開発単価、解約時の引き渡し
- 引き継ぎ：コードやFirebaseプロジェクト、Rules等を納品し、自社で管理できるか
初期相談に、設計や運用を担うエンジニアが参加するかを確認します。実績については、サービス名だけでなく、RTDBと別DBの機能分担も質問します。
契約では、障害時の一次対応と、Firebase・Google Cloudに障害が起きたときの連絡先を定めます。
月額保守費は、業務システムの目安として初期開発費の年10〜20％程度とされることがあります。ただし、24時間監視や休日対応、SLAによって変わり、改修時間の有無でも違いが出ます。そのため、数字だけでなく、対応時間と範囲を比べます。
発注者側では、業務責任者とデータ提供者を決めておきます。受入テスト、セキュリティ審査、現場教育の担当と、意思決定の期限も定めます。
承認の遅れやマスタの未提供、口頭での仕様変更は、開発会社だけでは吸収できません。そのため、変更管理と追加費用の扱いを、契約前に確認します。
よくある質問（FAQ）
Firebase Realtime DatabaseとFirestoreはどちらを選べばよいですか？
状態同期やプレゼンス、単純な検索が中心ならRTDBが候補です。一方で、複雑なデータモデルや複合クエリを重視する場合は、Firestoreが候補です。拡張性や高可用性が求められるときも、Firestoreを検討します。
Firebase公式は、新規顧客にFirestoreを推奨しています。なお、RTDBを選ぶ場合は、低遅延同期やプレゼンスが必要な理由と運用上の上限を、要件書に残しておきます。
Firebaseを使うと開発費は必ず安くなりますか？
Firebaseを使えば、サーバー構築や一部の運用は減らせます。ただし、要件定義や業務ロジック、Rulesの作成は残ります。試験や移行、教育、保守も必要です。
広い読取範囲や短時間の接続の多発、過剰な同期は、通信費を増やします。そのため、開発費と月額料は分けて考え、利用量の仮定と上限監視を比べます。
Security Rulesだけ設定すれば安全ですか？
安全性は、Rulesを含む複数の仕組みを組み合わせて確保します。Authenticationや、Rulesによる認可と検証、App Checkを使います。さらに、IAMやログ・アラート、依存ライブラリの更新も対象になります。
環境は開発、ステージング、本番に分け、Local Emulator SuiteでRulesを試験します。権限は定期的に確認します。個人情報を扱う場合は、リージョンと委託先の管理を、法務部門やセキュリティ部門と確認します。
開発会社には何を質問すればよいですか？
RTDBを使った機能と、FirestoreやSQLとの分担を聞きます。Rulesの試験方法や負荷試験の指標、月額料も確認します。さらに、バックアップと復元の方法や、障害時にどこまでを誰が受け持つかを質問します。
納品では、ソースコードとFirebaseプロジェクトを確認します。Rules、CI/CD、構成情報も納品対象かを確かめます。保守終了時の引き継ぎも、あわせて確認します。
実務を理解しているエンジニアと直接話せる会社であれば、技術選定の理由を確認しやすくなります。
まとめ
開発は6段階で進みます。中心は要件整理と選定で、まず同期の対象を見極め、RTDB、Firestore、Cloud SQL、既存基幹の役割を分けます。残りは設計・開発から定着までです。
JSONパスやlistener、Rulesは早めに決めておきます。さらに、接続と書き込みの上限、リージョン、利用料を定め、バックアップと復旧の方法も決めます。
着手前に確認する5つの項目
着手前に、次の5項目をそろえておきます。そうすると、開発会社が同じ前提で提案や見積を出せます。
- 同期の要件：対象業務と許容遅延
- 利用者情報：ロールと個人情報の範囲
- データ分担：RTDBと他DBの役割
- ピーク負荷：接続、書き込み、読み取りの量
- 責任分界：納品物、保守、復旧の担当
最初の一歩は業務フローとデータの洗い出し
Firebaseプロジェクトを作る前に、現場の業務、例外処理、既存データ、ピーク利用状況を整理します。
まずは小さく試し、費用や性能、Rules拒否、入力定着率を計測します。複雑な検索や厳密な集計は、別のデータストアに分けます。
▼全体ガイドの記事
・Firebase Realtime Databaseのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。