Firebase Spark プラン 2026｜介護記録アプリ移行を本気で比較

通所リハで働きながら、AIで職場の業務改善アプリを自作してます

前回の11本目で「DB が全消失した話」を書いて、最後に「Firebase に傾いてる」って記事を書きました！

今日はその続編で、Firebase Spark プランを本気で調べたメモです

結論として、

その調査メモが、今日の記事になりますね

Firebase Spark プランとは｜2026 年の無料枠を公式から拾う

まず Firebase の Spark プランから

ざっくり言うと、Firebase の無料プランです

Google 公式の表現を借りるなら、こう書いてあります

“No payment method needed”

つまりクレジットカードの登録すらいらない

これが Spark プランの最大の安心ポイントやと思ってます

主要サービスの無料枠を、Firebase 公式の Pricing ページから拾ってみました

サービス	Spark プランの無料枠
Cloud Firestore	1 GB ストレージ／50,000 reads/日／20,000 writes/日／20,000 deletes/日
Realtime Database	100 同時接続／1 GB ストレージ／10 GB ダウンロード/月
Authentication	50,000 MAU
Hosting	10 GB ストレージ／360 MB/日 転送
Cloud Storage	利用不可（Blaze プランへ移行が必要）

※ 2026年5月時点で公式ページから確認した数値です

※ 数値は変更される可能性があるので、最新は必ず公式で確認してください

ここからは、介護記録アプリで実際に使う3本柱について、もう少し具体的に見ていきます

Cloud Firestore：1 GiB / 50K reads / 20K writes

データ置き場のメインになるのが Firestoreになります

簡単にいうと、介護記録アプリで、利用者や入所さんの名前や誕生日といった内容を保存する場所ですね！

Spark プランの無料枠は

• ストレージ：1 GiB
• 読み取り：50,000 件/日
• 書き込み：20,000 件/日
• 削除：20,000 件/日

結論だけ先に言うと、プロト規模なら全然余裕やった

Realtime Database：100 同時接続 / 10 GB ダウンロード

リアルタイム同期に強いほうの DB

ちなみに、でDBというのは、データベースの略ですね！

無料枠は

• 同時接続：100
• ストレージ：1 GB
• ダウンロード：10 GB/月

介護記録アプリは「同時に何十人も書き込む」用途じゃないから、100 同時接続でも余裕です

Authentication：50,000 MAU

ログイン機能の無料枠は 月間アクティブユーザー50,000人

これは個人開発だとほぼ気にしなくていい数字やと思います

職場のスタッフ数で50,000人は、たぶん日本中の事業所でも数えるほど

Hosting：10 GB ストレージ / 360 MB/日 転送

画面の HTML/CSS/JS を置く場所

画面がどんな表示になるかとかの、データを置く場所ですね

• ストレージ：10 GB
• 転送：360 MB/日

JavaScript のシンプルなアプリなら、10 GB あれば余裕

転送量も、職員10人〜20人が毎日使う規模なら届かない数字

個人開発・小規模業務改善のレベルなら、Spark プランは本当に手厚い

これが Google の「まずは触ってみて」っていう設計思想やと思う

Spark と Blaze の違い｜「クレカ無し」が最大の壁

次に、上のプラン Blaze との違い

Blaze プランは従量課金プラン

「無料枠＋超過分は使った分だけ払う」っていう仕組みです

項目	Spark	Blaze
クレカ登録	不要	必須
無料枠	あり	あり（同じ）
超過時の挙動	上限到達でサービス停止	従量課金で継続
Cloud Storage	利用不可	利用可

ポイントは2つ

1つ目：無料枠は Spark も Blaze も同じ

Blaze にしたから無料枠が増える、ってことはない

2つ目：超過時の挙動が違う

Spark は上限に達するとサービスが止まります

Blaze は超えた分だけ課金されて、サービスは止まらない

Cloud Storage が Spark で使えなくなった話

ちょっと注意点がひとつ

Firebase の Cloud Storage（画像・ファイル置き場）が、Spark プランでは利用不可になってます

調べた範囲では、2024年10月末の仕様変更で、新規の Spark プロジェクトでは Cloud Storage の新規バケット作成ができなくなった、と理解してます

「写真をアプリに保存したい」っていう用途は、Spark プランでは無理

そこは Blaze プランに上げる必要があります

将来、どうしても必要になったら、 Blaze 移行を考えますね

それまでは Spark で困らない、っていう判断です

Spark プラン無料枠で介護記録アプリは何日もつ？｜紙の上で見積もり

ここからが本題

「Spark プランの無料枠で、うちの介護記録アプリは何日もつのか」を概算してみます

注意：まだ Firestore で実装してないので、あくまで紙の上の見積もりです

8本目の介護記録アプリ自作記事で書いた6機能を引き継いで計算します

機能	1日あたりの書き込み回数（概算）
座席表	35人 × 1回 ＝ 35
入浴表	35人 × 1回 ＝ 35
送迎表	35人 × 2回（行き・帰り）＝ 70
おやつ	35人 × 1回 ＝ 35
食事	35人 × 2回（昼・おやつ）＝ 70
バイタル	35人 × 3回（血圧・脈拍・体温）＝ 90
合計	約 335件/日

※ あくまで概算です

※ 実装してから実測する必要あり

読み取り側は、画面を開くたびに発生する

書き込みより多くなる想定

ただ、Firestore はキャッシュが効くので、

職員10人が1日10回ずつ画面を開いても、reads は数千件レベルで収まりそう

50,000 reads/日 にも、まだ余裕がある見立て

ストレージ 1 GB はどうか

バイタル1件のデータサイズを仮に500バイト（数値＋日付＋ID）とすると

• 1日：300件 × 500B ＝ 150 KB
• 1ヶ月：約 4.5 MB
• 1年：約 54 MB

1 GiB の枠なら、18年分くらい入る計算

Firestore vs Realtime Database｜介護アプリならどっち？

Firebase には DB が2種類あって、ここで悩んでます

公式の使い分け基準を読むと、ざっくりこういう棲み分け

• Cloud Firestore：複雑なクエリ・スケール重視・新規プロジェクト推奨
• Realtime Database：単純な構造・低レイテンシ・書き込み頻度が高い用途

クエリっていうのが、パソコンにお願いする文章になります

スケールっていうのは、規模感のことかな

レイテンシっていうのは、反応のまでの待ち時間みたいなニュアンスですね

理由はこんな感じ

• Google 公式が「新規は Firestore 推奨」って打ち出してる
• 利用者ごと・日付ごとに絞り込むクエリが書きやすい
• スケールが必要になっても、設計を引きずって移行で困りにくい
• 個人開発の参考事例が多くて、詰まった時に検索しやすい

Realtime Database のほうが速いって話も聞きますが、介護記録アプリはミリ秒単位の即応性が要る用途じゃない

「データを残す」「あとで見返す」が主目的やから

Firestore のほうが性に合ってそう、っていう現時点の見立てですね

Supabase Free との比較感｜11本目の補強

11本目では「Firebase に傾いてる」とだけ書きましたが、Supabase もちゃんと候補に残してます

Supabase Free プランの主要な数字は、こんな感じ（Supabase 公式の Pricing から）

項目	Supabase Free
データベース	500 MB
MAU	50,000
同時接続	200
ストレージ（ファイル）	1 GB
プロジェクト数	2つまで
通信量	5 GB egress
一時停止	1週間の非アクティブで自動停止

Firebase Spark との対比をざっくり並べると

項目	Firebase Spark	Supabase Free
DB ストレージ	1 GiB（Firestore）	500 MB
MAU	50,000	50,000
同時接続	100（Realtime DB）	200
自動停止	なし	あり（1週間非アクティブ）
クレカ登録	不要	不要
個人開発の事例	めっちゃ多い	増えてきてる

11本目で書いた「Firebase に傾いてる理由3つ」を、もう一度ここで確認

1. Google アカウントとの相性が良い（Sheets 時代から Google で組んでた）
2. ネット切れに強い（オフライン同期の設計が手厚い）
3. 個人開発の参考事例が多い（詰まった時に検索しやすい）

これに今回の見立てを足すと

4. 無料枠が介護記録アプリ規模に十分
5. Cloud Storage 縛りも、スキャン機能想定なしで影響軽微

PostgreSQL ベースで SQL 慣れてる人なら、Supabase のほうが早い場面も多い

要は用途次第になりますね

検討中段階で見えてきた3つの注意点

選定中の段階で、現時点で見えてきた注意点を3つメモしておきます

① Cloud Storage は Spark で新規不可

写真・動画・大きいファイルを扱う設計をしてるなら、Spark プランは選択肢から外れる

Blaze プラン（クレカ登録あり）に上げる必要があります

うちのケースは写真機能想定なしなので、ここは影響軽微

② Spark の Cloud Functions は外部通信に制約がある

Spark プランの Cloud Functions（バックエンド処理）は、Google 以外の外部 API への通信に制約があると理解してます

「外部の決済 API を叩く」「外部の天気 API を叩く」みたいな用途は、Spark プランでは厳しい

うちの介護記録アプリで外部 API を叩く要件は、いまのところ無し

ここも影響軽微の見立て

③ クレカ無し縛り（Spark）／ プロジェクト一時停止（Supabase）

無料プランには、それぞれ独自の落とし穴がある

• Spark：クレカ登録できない＝そもそも超過しても課金されない（裏返せばサービス停止）
• Supabase Free：1週間の非アクティブで自動停止

業務アプリで本番運用するなら、どっちも頭の片隅には置いておきたいポイント

まとめ｜検討中の現在地

長くなったけど、要点はこれ

• Spark プランの無料枠は、個人開発のプロトには十分
• 介護記録アプリ規模なら Firestore × Authentication × Hosting で当面 0 円見込み
• Cloud Storage は Spark で利用不可だけど、写真機能想定なしなら影響軽微
• Firestore vs Realtime Database は、いま Firestore に傾いてる
• Supabase Free も候補は残してるけど、用途的に Firebase が合いそう
• ただし まだ Firestore で動かしてはない＝選定中段階

「決めた」ではなく「いま Firestore に傾いてる」段階の記事です

進捗は X で「Firebase 試してみる」シリーズとして更新していきます

実装に入って想定外のハマりが出たら、それもブログに残します

業務改善で自作してる人の参考になれば嬉しいです

業務改善シリーズの過去記事も置いとくね：

• 介護記録アプリを自作した話｜現役職員がAIで現場の不満を解決 ← 8本目（自作のスタート地点）
• 自作アプリのDBが全消失した話｜Google SheetsからFirebaseへ移行検討中 ← 11本目（今回の前日譚）

今日はそんなところ！ノシ