皆さんの会社では、「会議室を予約したのに誰も使っていない（空予約）」や「急な打ち合わせで空き部屋を探すのにPCを開くのが面倒」といった悩みはありませんか？

本プロジェクトではこうした課題を解決し、会議室の利用効率を最大化するプロジェクトを進めています。今回は、バックエンドのデータベース選定において、なぜ王道のRDBMS（Cloud SQL）ではなく Firestore (Firebase) を選定することになったのか。その決定的な理由を、実際のアーキテクチャ図を交えてお伝えします！

1. プロジェクトの概要とアーキテクチャ

本プロジェクトは、社内の会議室利用における「負」を解消するため、全10部屋の会議室にiPadを設置し、Googleカレンダーと連携する予約システムを構築するものです。

システム構成図

上図が全体のアーキテクチャです。iPadでの操作（予約・チェックイン・退室）は Cloud Run 上のAPIを経由して処理され、データは Firestore に格納されます。

※構成図はわかりやすくするため一部省略している箇所があります。

Googleカレンダーとの同期の仕組み

ここで重要になるのが「Googleカレンダーとの連携」です。構成図にある通り、Cloud Run がハブになっています。

  • iPad → GCal：API経由で即時書き込み。
  • GCal → iPad：Cloud Schedulerが定期的にGCalの変更をチェックし、Firestoreを更新します。

ポイントは、「バックエンドで更新検知のラグがあっても、iPad側はFirestoreの更新を待つだけでいい」という点です。iPadアプリ側で複雑なポーリングロジックを書く必要がなく、Firestoreが更新された瞬間に画面が切り替わる仕組みを構築しています。

達成したいUXと課題

  • 会議室利用状況の無駄を省く：予定より早く終わった場合に、iPadから「退室」操作を行うことで即座に予約を解放。
  • 予約操作の迅速化：iPadから文字入力なしで即時予約・入室。
  • NoOps（運用負荷ゼロ）：インフラ管理コストを極限まで下げる。
  • 利用状況の分析：どの事業部の人がどれだけ会議室を活用しているのか・空予約が多いのはどの事業部の誰かなどを利用データから分析できるようにする。
  • 空予約の解消：予約しているけど活用していない会議室がある状況の解消

例：定例で毎週会議室を予約していたが、リモートで会議を実施するようになり会議室を使わなくなったが予約されている

2. 比較：なぜ Cloud SQLではなくFirestoreなのか？

最初はよく採用されている Cloud SQLも検討しました。しかし、今回の「リアルタイムUX」と「小規模スタート」という要件に対して、RDBMSには3つの「壁」がありました。

① 課題：SQLは「変更検知」が苦手（ポーリングによるラグ）

RDBMS自体は高速ですが、データの変更をクライアント（iPad）に即座に通知する標準的な仕組みがありません。 iPad側で常に最新の状態を表示しようとすると、短い間隔でサーバーに問い合わせる「ポーリング」が必要になります。これは通信量やサーバー負荷の増大を招き、それでも数秒〜数十秒のタイムラグ（UXの低下）が避けられません。

②開発コスト： リアルタイム機能の実装コストが高い

「誰かが予約した瞬間に、目の前のiPadを『使用中』に変える」を実現するために、RDBMSの場合は別途 WebSocket サーバーなどを構築する必要があります。これでは開発工数が増えるだけでなく、運用の手間も増えてしまいます。

③ 稼働コスト：10部屋には「オーバースペック」なコスト

ここが重要なポイントです。Cloud SQLはインスタンスを起動し続ける必要があるため、利用者がいない夜間や休日でもコストが発生し続けます。 今回の対象は「会議室10部屋」のみ。この規模感で、月額数千円〜数万円のインスタンス費用を払い続けるのは、コストパフォーマンスの観点で最適とは言えませんでした。

3. Firestore 選定の決め手となった「4つの要素」

上記の課題をクリアし、Firebase (Firestore) を採用するに至った4つの理由を解説します。

項目 PostgreSQL (Cloud SQL) Firestore 判定
リアルタイム反映 × 苦手（ポーリングが必要） ◎ 得意（Real-time listeners） Firestore
整合性・排他制御 ◎ 得意（強固なトランザクション） ○ 可能（ACIDトランザクションあり） Draw
コスト・規模感 △ 注意（常時課金・小規模には割高） ◎ 最高（従量課金・小規模ならほぼ無料） Firestore
運用負荷 △ 注意（インスタンス管理が必要） ◎ 最高（完全サーバーレス） Firestore

要素1：リアルタイムリスナー (Real-time listeners)

Firestore Client SDK に標準搭載されている機能です。サーバーサイドの実装なしで、データの変更を検知し、瞬時にiPad画面へ反映できます。 「SQLにおけるポーリングのラグ」問題を解決し、ユーザーが予約ボタンを押した瞬間に、他のすべての端末に最新情報が行き渡るUXを実現しました。

要素2：セキュリティルール

Firestoreには強力なセキュリティルールがあり、サーバーを介さずにクライアントからアクセスする場合でも、安全なデータ保護が可能です。

例えば「自社のドメインのアカウントかつ認証済みユーザーのみ読み込み可能」といった細かい権限設定を、アプリケーションコードではなくデータベース側で強制的に適用できます。 これにより、クライアント側から直接データベースへ参照する構成でも、堅牢なセキュリティ対策を実現しています。

要素3：従量課金制

これが「10部屋」のプロジェクトに最適でした。Firestoreは「読み書きした分だけ」の課金です。 会議室の予約データ量はたかが知れており、利用のない夜間・休日はコストがゼロになります。Cloud SQLのインスタンス維持費と比較すると、圧倒的なコスト削減になりました。

要素4：Stream Firestore to BigQuery

Firestoreの弱点である「複雑な検索・集計」を補う拡張機能です。 冒頭で達成したい課題として挙げた「空予約の状況分析」や「事業部ごとの利用率分析」は、この連携によってBigQuery側で行います。

これにより、Firestoreはアプリの動作（UX）だけに専念でき、複雑な集計処理によるパフォーマンス低下を防ぐことができます。「アプリはFirestoreでサクサク動き、分析はBigQueryでガッツリやる」。この住み分けを、コードを一行も書かずに実現しています。

まとめ

今回の技術選定では、以下のポイントでFirestoreが勝者となりました。

  • UX要件：リアルタイムリスナーによる「即時反映」
  • 規模感：10部屋という小規模スタートに適した「従量課金」
  • 運用：NoOpsを実現する「サーバーレス構成」

「DBといえばとりあえずSQL」ではなく、プロジェクトの規模や実現したい体験（UX）に合わせて技術を選ぶことが、成功への近道だと実感しています。