Firebase Realtime Databaseの発注は、要件整理、契約と委託範囲の決定、見積比較の順に進めます。この順で進めると、適切な設計と運用につながります。
発注形態、RFPと契約、費用と委託先選定の3点について、決め方を順に説明します。
▼全体ガイドの記事
・Firebase Realtime Databaseのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Firebase Realtime Databaseのシステム発注前に知っておく全体像
Firebase Realtime Database（RTDB）は、JSONツリーの形でデータを保持するクラウド型NoSQLデータベースです。
アプリやブラウザへリアルタイムに同期できる点が特徴です。
発注範囲は、データベースより広く考えます。
認証、権限、画面は、利用者の操作に直接かかわる部分です。
通知や外部連携も、発注範囲に入ります。
テスト、監視、保守は、リリース後の運用まで含めて見ます。
RTDBが向いている業務システム
RTDBが合うのは、利用者の状態や最新情報をすぐ共有したいシステムです。
- 現場の状態共有：受付状況、作業員の位置、設備の稼働状況
- 利用者への速報：チャット、プレゼンス、在庫や予約枠の表示
認証済みユーザーのuidやロールを使って、Firebase Security Rulesを設計できます。
書き込みをきっかけにCloud Functionsで通知や集計を実行する構成も組めます。
複雑な検索や大量の集計、厳格なリレーション整合性が中心の案件では、RTDBだけに集約しない判断が必要です。
Firestoreはクエリ性・拡張性・高可用性に優れます。一方、RTDBは単純なデータモデルや検索に適し、低遅延同期や限定的な規模とも相性がよいです（出典：Firebase公式「Cloud FirestoreまたはRealtime Databaseの選択」、2026年8月確認）。なお、Firebase公式は2026年8月時点で、新規顧客にCloud Firestoreを推奨しています。
RTDBだけに集約しない構成
業務に応じてデータベースを分担すると、RTDBだけに集約せずに済みます。
- 状態同期・速報値：RTDBで配信
- 検索しやすい業務データ：Firestoreへ分ける
- 厳格なトランザクション・SQL集計：Cloud SQLに置く
- 分析データ：BigQueryに置く
- 基幹マスタ：既存データベースに残す
RTDBとFirestoreは同じプロジェクトで併用でき、全データを一方へ集める必要もありません。
発注前にこうして切り分けておくと、検索画面の追加費用や将来の移行困難を抑えられます。
発注者は、委託先にRTDBの採用理由、別のデータベースに置く領域、将来の移行条件を説明してもらいます。
採用可否の判定条件
採用判断では、性能、データ、保管地域の条件を確認します。
- 性能：更新許容時間、同時接続数、毎秒の書き込み数
- データ：保存期間、検索・集計・監査ログの要否
- 保管地域：個人情報を保管できる地域
RTDBは、単一データベースで同時接続おおむね20万、書き込み毎秒1,000が目安です。この目安を超える場合は、複数データベースへのシャーディングが必要になります（出典：Firebase公式「Realtime Databaseの制限」、2026年8月確認）。
「リアルタイムだからFirebase」と決める前に、重要な業務処理と補助的な状態同期を分けて考えます。
提案は、価格に加えて設計の妥当性でも比べます。
発注形態の選び方：内製、部分外注、一括委託
発注形態は、要件の確定度と内製化方針から決めます。納期や運用体制も判断材料に入り、技術者の有無は、その一部です。
検証で不確実性を減らしてから本開発へ進むと、RTDBのデータ構造や従量課金のリスクを確かめられます。
社内主導で専門工程だけを外注する方法
社内にプロダクトオーナーやフロントエンド担当がいる場合は、社内と専門会社で作業を分けられます。
- 社内：業務要件と画面仕様の整理、画面開発
- 専門会社：RTDBのデータモデル、Rules、負荷試験、CI/CD、Cloud Functions
- 共同：受入テスト
社内に知識が残るため、引き継ぎの場面でも役立ちます。
責任分界が曖昧だと、障害時の原因究明が難しくなります。
そこで、リポジトリやFirebaseプロジェクトの管理者を文書に残します。秘密情報やデプロイ権限の管理者も、書き出しておきます。
要件定義から保守まで一括で委託する方法
社内に業務システムの経験者が少ない場合は、企画整理から保守まで一社に委託できます。
- 委託範囲：企画整理、要件定義、設計、開発、テスト、リリース、保守
- 計画対象：データ移行、現場教育
- 発注者の管理：Firebaseプロジェクトの所有、成果物の受領
- 納品物：ソースコード、Rules、インフラ設定、テスト仕様、運用手順
窓口をひとつにまとめられる一方で、一括委託でも安心とは限りません。要件定義の成果物や変更管理が弱いと、追加費用や納期延長が起きやすくなります。
契約終了後に別の会社へ移行できる状態を整えておくと、外注への依存を防げます。
PoCからMVP、本番へ段階的に発注する方法
要望が固まっていない場合は、PoC（概念実証）から始めて、段階的に発注します。
- 認証、主要画面、基本CRUD、同期、最小限のRulesを検証する
- データ構造の拡張性、想定読み取り量での動作、業務継続性を確かめる
- 検証結果を本番版のRFPに反映する
この順に進めると、不要な機能を先に作るリスクを下げられます。ただし、安く作ることだけを目的にしたPoCは、本番での作り直しにつながる場合があります。
PoCの段階でも、認証方式やパス設計、権限は、本番を見据えて決めておきます。ログやデータ削除の方針も、同じ考え方で決めます。そのうえで、使い捨てる範囲と引き継ぐ範囲も委託先と合意します。
RFPと要件整理で決めるべき項目
RFPには、「Firebaseで作りたい」という技術要望に加えて、目的、利用者、データを書きます。
性能や保守条件まで示すと、同じ条件で提案と見積を得られます。
RTDBでは、データモデルと読み取り範囲が費用・性能・安全性に直結します。そのため、発注時に明確にしておきます。
業務フローによる業務要件の整理
画面を作る前に、業務フローと利用者の役割を整理しておきます。
- 業務の流れ：誰がいつ入力し、誰が確認するか
- 通知条件：次の担当者へ知らせる状態
- 例外処理：差し戻し、キャンセル、権限変更、通信断からの復帰
- 利用者権限：読めるパス、書けるパス、承認できる操作
現場の暗黙知やExcelでの補正を要件に残したままだと、完成後に使えないと評価される場合があります。
成功指標は、受付処理時間の短縮や二重入力の削減など、業務上の成果で示します。
非機能要件の数値指定
非機能要件は、「快適に動く」のような表現では見積もれないため、数値で指定します。
- 負荷：同時接続数、ピーク時の書き込み数
- 性能・容量：画面更新時間、データ容量、保持期間
- 復旧：バックアップ頻度、RTO、RPO
数値は仮置きでもかまわないので、平常時500、ピーク時2,000の同時接続や、画面更新3秒以内などを示します。
月間ダウンロード量なら、最大100GBといった条件で示します。
RTDBの料金は、保存量だけでなく、ダウンロード量や接続維持、暗号化の通信オーバーヘッドにも左右されます。
Sparkプランでは、保存1GBと月10GBのダウンロードが無料です。
Blazeプランの超過分は、保存5ドル/GB、ダウンロード1ドル/GBです（出典：Firebase公式料金表、2026年8月確認）。
このため、予算の上限を決めるだけでなく、利用量を監視する前提で要件を定義しておきます。
RFPに含めるデータ移行・セキュリティ・運用
移行、セキュリティ、運用の担当範囲を、RFPに明記します。
- データ移行：対象件数、項目、重複・欠損、リハーサル、切り戻し
- セキュリティ：Authentication、Rules、App Check、管理者権限
- 運用：監査ログ、秘密情報、脆弱性対応、バックアップと復元テスト
発注者側で行う抽出・クレンジング作業もWBSに入れ、準備担当と期限を決めておきます。特に、移行を委託先に任せきりにすると、品質と納期が遅れやすくなります。
Firebase公式は、Rulesをデータ構造と同時に作り、Local Emulator SuiteでテストしてCIに組み込むよう案内しています（出典：Firebase公式「セキュリティチェックリスト」、2026年8月確認）。
RTDBのリージョンは作成後に変更できず、公式の選択肢には米国中部、欧州西部、アジア南東部などがあります。
日本リージョンが必要な場合は、法務・セキュリティ担当と委託先に事前に確認します。そのうえで、保管地域、委託先のアクセス地域、事故時の報告期限をRFPに含めます。
RFPに記載する納品物と評価基準
納品物と評価基準は、発注後の引き継ぎまで見据えて定めます。
- 設計・実装：要件定義、画面仕様、データモデル、Rules、認証設計
- 品質・運用：テスト結果、負荷試験、CI/CD、構成情報、復旧手順
- 引き継ぎ：操作マニュアル、教育資料、構成管理コードと実行手順
Terraformなどの構成管理コードも、所有権の対象に含めます。
提案は、価格、RTDB実績、代替案の3点で評価します。さらに、Rules・App Checkの扱いや負荷試験、工数の根拠も見ます。
担当者との面談、保守、内製化支援も評価の対象にします。また、同じRFPを各社に渡し、前提と除外項目を揃えます。
契約形態の選び方：請負と準委任
契約は、要件と成果物をどこまで確定できるかで選びます。完成条件を定義できる工程は請負が、探索や専門家の稼働確保には準委任が合いやすいです。
要件定義は準委任、開発は請負、リリース後は保守契約に分ける方法もあります。
請負契約が合うケース
請負契約は、委託先が成果物を完成させ、発注者が検収する形です。
- 適する工程：完成条件を仕様化できる開発
- 成果物：画面、認証、データモデル、Rules、テスト、マニュアル
- 管理面：予算と納期を管理しやすい
仕様変更には追加見積や契約変更が必要です。また、検収では、権限の越境やオフライン復帰時のデータ破損がないことを確認します。
非機能の条件には、想定同時接続数での応答やバックアップからの復元を含めます。さらに、検収後の瑕疵対応期間、障害の重大度、無償修正の範囲も契約書に記載します。
準委任契約が合うケース
準委任契約は、合意した業務を専門家が進め、稼働時間や役割に応じて精算します。
- 要件整理：業務フローを整理しながらデータモデルを試す
- 調査・開発：既存システム調査、社内チームとの共同開発
- 継続改善：運用改善や不確実性を含むPoC
技術的に不確実なPoCでは、検証の成果を段階的に確認しやすくなります。ただし、時間を使えば成果が自動的に出る契約ではありません。
月次報告と稼働上限は、契約の段階で決めておきます。報告には、成果物、残課題、次月計画を含めます。担当者のスキルや会議体も、あわせて取り決めます。
発注者側にも意思決定者を置き、要件の優先順位を停滞させない運営が必要です。
工程ごとの契約分けと責任分界
工程ごとに契約形態と責任範囲を分けると、役割の境目をはっきりさせられます。
- 要件定義・技術検証：準委任
- MVP開発：合意した範囲を請負
- リリース後：準委任で保守・改善
工程ごとに成果物と判断基準を分けられるため、リスクを一方に押し付けずに済みます。
契約では、FirebaseやGoogle Cloudの利用料の扱いと、予算超過を検知する担当を決めておきます。
障害の一次対応、データ消失・漏えい時の報告や復旧、費用負担も明確にします。加えて、第三者サービスの仕様変更への対応も決めておきます。
Firebase利用料は、発注金額とは別の運用費です。そのため、責任範囲を見積書と契約書に残しておきます。
Firebase Realtime Databaseのシステム開発費用相場
Firebaseでサーバー調達や一部のインフラ実装を減らせても、工数がなくなるわけではありません。要件、画面、権限の工数は残ります。
テストや移行にも工数がかかります。教育や保守も含めて、考える必要があります。
日本向けのRTDB単体について、請負の統計は確認できません。そのため、ここに示す金額は、一般的な業務システムの工数とFirebaseの特性から算出した初期予算です。正式な金額は要件と委託先の体制で変わります。
開発規模ごとの費用レンジ
開発規模ごとの初期費用と期間は、次のレンジが目安です。
- プロトタイプ：基本機能と最低限のRulesを検証。100万〜300万円、1〜2か月程度
- 小規模MVP：画面、通知、ログ、テスト、初期運用を含む。300万〜800万円、2〜4か月程度
- 業務システム：連携、移行、監査ログ、負荷試験を含む。800万〜2,000万円、4〜9か月程度
- 大規模構成：高可用性や複数アプリなどを含む。2,000万〜5,000万円超、9か月〜1年半以上の場合あり
プロトタイプでは、認証と基本CRUDを検証します。リアルタイム表示や最低限のRulesも対象です。
小規模MVPは、スマートフォンまたはWebアプリに、管理画面などを加えたものです。
業務システムは、複数ロールや外部API、既存DB・基幹連携などを含みます。
大規模構成では、複雑な業務連携や大規模移行が費用・期間を押し上げる可能性があります。
見積では、要件定義、UI設計、アプリを分けて示してもらいます。データモデル、Rules、Functionsも区別します。外部連携も、別に示してもらいます。
一方で、一式でまとめた見積では、削られた工程や追加になる作業が見えません。テストや移行、教育は、工程ごとに確認します。プロジェクト管理と保守も、別の行に書いてもらいます。
Firebase利用料と月額費用の考え方
Firebase利用料は開発費とは別に、保存量とダウンロード量を中心に試算します。
- 5GB保存・月100GBダウンロード：RTDB部分は約16,500円/月
- 20GB保存・月500GBダウンロード：同じ仮定で約87,000円/月
1ドル150円の仮定では、前者の内訳は保存4GB分約3,000円、ダウンロード90GB分約13,500円です。
為替や実利用量で変動するため、固定費とは断定できません。他サービスや通信オーバーヘッドの影響も受けます。
- 読み取り範囲：広いパスを避け、必要な範囲に絞る
- 取得設計：インデックスやページングを使う
- 利用量管理：ダッシュボード、アラート、停止手順を保守契約に含める
短時間に頻繁な接続が続くと、SSLやプロトコルのオーバーヘッドが増えることがあります。また、Rulesで拒否された通信も課金対象になり得ます。Budget alertsは、支出を止める上限ではありません。
保守・運用費の見積粒度
保守には、障害監視、利用量確認、脆弱性対応を含めるかを決めます。OS・SDK更新、Rules変更、バックアップ確認も、含めるかを確認します。問い合わせや軽微な改善についても、対象に入れるかを確かめます。
一般論として、保守費は初期開発費の年10〜20％が目安とされることがあります。
- 監視・対応：障害監視、利用量確認、問い合わせ
- 保全：脆弱性対応、OS・SDK更新、Rules変更、バックアップ確認
- 改善：軽微な改善
24時間監視や障害対応を含むかで、金額は変わります。データ復旧や追加開発を含むかも確かめます。割合だけで判断せず、含まれる内容を比べます。
月額のGoogle Cloud利用料を委託先が立て替えるか、発注者が直接契約するかも確認します。
発注者のアカウントで請求と所有権を管理し、委託先には必要な権限だけを付与します。その形が、運用の継続にもつながります。
委託先選定と見積比較で確認するポイント
委託先は、Firebase対応の表記よりも、RTDBの設計や運用の経験で選びます。
担当実績は、データモデル、Security Rules、App Checkについて確かめます。さらに、負荷試験や移行、運用監視の担当実績も確認します。
公開実績があっても、担当範囲が分からない場合があります。そのため、機能や規模、役割を尋ねます。
運用期間も聞いておきます。可能であれば、担当エンジニアから説明を受けます。
技術提案で確認する質問
技術提案では、RTDBの採用理由や運用設計を具体的に質問します。
- データ設計：Firestore・Cloud SQLとの境界、JSONパス、listener
- 性能・費用：読み取り量と従量課金、接続数・書き込み数の試験方法
- アクセス制御：ロール別read/write、validate、管理者操作、匿名認証
- テスト：App Check、Emulatorの試験ケース、CIへの組み込み
具体的な図や試験方法で答えられる会社は、システム全体を見ている可能性があります。
Firebase公式は、Rulesをスキーマの一部として開発と同時に作り、Local Emulator Suiteで試験するよう案内しています。
見積書の比較観点：前提と除外項目
見積を比べるときは、各社が同じ範囲を見積もっているかを確かめます。
- 開発範囲：画面、ロール、外部連携、移行件数、テスト端末
- 検証・納品：負荷試験、納品物
- 契約条件：打ち合わせ回数、保守期間、前提と除外項目
各社には、含むものと含まないものを分けて記載してもらいます。前提条件や、追加になる条件も書いてもらいます。
極端に安い提案では、要件定義やセキュリティが省かれていないかを確認します。移行や受入支援も、省かれていないかを確かめます。
ドキュメントや負荷試験の有無も見ます。一方、高い提案では、不要なサーバーや複雑な機能を避けているか、Firestoreや既存システムとの分担で下げられる工程がないかを確認します。
引き継ぎと運用体制を含む選定条件
納品後の運用担当と引き継ぎ対象も、選定条件に含めます。
- 運用担当：コンソール確認、利用量異常の検知、Rules変更の承認
- 内製化支援：レビュー、操作説明、障害訓練、コードリーディング
- 移管物：ソース、Firebase設定、Rules、Functions、CI/CD、復旧手順
発注者側には、構成と運用を理解している人を最低一人置きます。そのうえで、環境変数の管理やバックアップ、利用サービス一覧も引き継ぎます。外部アカウントの名義も、引き継ぐ対象です。
別の委託先でも運用できる状態を検収条件にすると、長期の発注リスクを減らせます。
よくある質問
Firebase Realtime Databaseの発注でよくある疑問を取り上げます。料金や技術の選び方は案件ごとに変わるため、判断の基準を示します。
Firebase Realtime Databaseのシステム開発は安くできますか？
Firebaseはサーバー基盤の一部を省力化しますが、業務機能などの開発費は残ります。
- プロトタイプ：100万〜300万円
- 小規模MVP：300万〜800万円
- 業務システム：800万〜2,000万円程度
比べるときは、業務要件、画面、認証の費用を含むかを確かめます。権限やテストの費用も含むかを見ます。移行や保守の費用も、対象に入っているかを確かめます。
価格だけでなく、セキュリティや運用で後から必要になる分まで含まれているかも比べます。
FirestoreではなくRealtime Databaseを選んでも問題ありませんか？
低遅延の状態同期やプレゼンスが中心なら、RTDBが有力です。単純なデータモデルや限定的な規模も、RTDBに向く条件です。
複雑な検索や階層データが中心なら、FirestoreやCloud SQLも比べます。高可用性や自動スケールが必要な場合も、比べる対象になります。
RTDBとの併用も含めて判断し、採用条件と採用しない条件を委託先に示してもらいます。
Firebaseに詳しい外注先はどのように探せばよいですか？
Firebase対応の表記だけでなく、実務経験と担当範囲を確認します。
- 技術実績：RTDB設計、Rules、App Check、負荷試験
- 運用実績：データ移行、利用量監視、保守
- 提案比較：工数、除外項目、納品物、所有権、障害時の責任
複数社へ同じRFPを渡し、担当エンジニアとも面談します。価格差の理由を説明できる会社を選ぶと、発注後の追加費用を抑えられます。
日本のデータ保管要件がある場合に注意することは何ですか？
RTDBは作成時にリージョンを選び、後から変更できません。
- 保管先：公式一覧に日本リージョンがないことを踏まえ、保管地域と越境移転を確認
- 委託先：アクセス地域と契約上の安全管理措置を確認
法務やセキュリティの担当と相談し、要件を満たせない場合は、別のデータベースや構成も検討します。
まとめ
発注前に、リアルタイム同期が必要な業務と、Firestore・Cloud SQL・基幹へ分ける業務を洗い出します。
要件の確定度と内製化方針に合わせて、部分外注、一括委託、PoCからの段階発注のいずれかを選びます。
発注前のRFPと責任分界の準備
RFPには、業務フロー、ロール、データ構造を記載します。加えて、同時接続数、書き込み数、保持期間も示します。
RTO・RPO、リージョン、Rules、App Checkも指定します。さらに、移行、テスト、監視、納品物の条件も、RFPに盛り込みます。
契約では、請負と準委任の範囲を明確にします。利用料、障害対応、所有権は、契約書で定めます。保守と引き継ぎ条件も、同じ契約で定めます。
見積の金額・技術・運用を同じ条件で比較
見積は、金額の前提と範囲を揃えたうえで、技術と運用の面も比べます。
- 費用：プロトタイプ100万〜300万円、小規模MVP300万〜800万円
- 業務システム：800万〜2,000万円程度
- 総コスト：Firebase利用料、監視、セキュリティ、移行、保守も確認
根拠となる工数と範囲を確認し、発注者側にアカウントと構成情報を残せる委託先を選びます。
▼全体ガイドの記事
・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を創業。