開発・技術

個人開発SaaSを月額0円で維持する｜Vercel × Firebaseの無料枠使い倒しアーキテクチャ

「個人開発でSaaSを作りたいが、ランニングコストで赤字になるのは怖い」

これは、私たち個人開発者にとって最大の悩みです。AWSでEC2を立て、RDSを契約し、ロードバランサーを置けば、ユーザーが0人でも月額数千円〜数万円が飛んでいきます。

しかし、技術選定さえ間違えなければ、「ユーザーが増えて収益化できるまで、維持費はずっと0円」という夢のような環境を構築可能です。

今回は、私が実際に自作アプリで採用している、Vercel（フロントエンド）とFirebase（バックエンド）を組み合わせた「完全従量課金・無料枠最大化アーキテクチャ」を解説します。

なぜ「月額固定費」が個人開発者を悩ませるのか

個人開発の生存率を上げる唯一の方法は、「損益分岐点を極限まで下げること」です。

月額3,000円のサーバー代がかかる場合、月額500円のアプリなら6人の有料会員を獲得してようやくトントンです。しかし、維持費が0円なら、有料会員が1人でも現れた瞬間に黒字化します。

精神的な余裕を持つためにも、以下の構成をおすすめします。

推奨スタック（The Zero-Cost Stack）

  • フロントエンド / ホスティング: Vercel (Next.js)
  • データベース / 認証: Firebase (Firestore / Auth)
  • 開発言語: TypeScript

1. Vercel（Hobbyプラン）の無料枠を使い倒す

Next.jsの開発元であるVercelは、個人開発者にとって最強のプラットフォームです。

無料枠（Hobby）の主なスペック

  • 帯域幅: 100GB / 月
    （いわゆる「転送量」。個人開発レベルなら十分。）
  • ビルド時間: 6,000分 / 月
    （約100時間。1日3時間ビルドし続けても大丈夫な計算。）
  • Serverless Function実行回数: 100万リクエスト / 月
    （1日あたり約3.3万アクセス目安。）

※数値の根拠：Usage Limits - Vercel Docs

個人規模のSaaSで、月間100GBの転送量や1日10万リクエストを超えることは、バズらない限りまずありません。

【重要】商用利用の規約について

ここで一つ、注意点があります。VercelのHobbyプランは、原則として「非商用・個人利用」向けです。

しかし、Vercelの規約やコミュニティの議論を見ると、「趣味の範囲や、収益化前のテスト運用」であれば許容されるケースが多いです。そして、収益が安定して出始めたらProプラン（月額$20）に移行すれば良いのです。

「売上が立つまではHobbyプランで耐え、売上が立ったら経費としてProプランを払う」。これが最も健全な個人開発のステップアップです。

2. Firebase（Sparkプラン）の無料枠戦略

Googleが提供するmBaaS、Firebase。これの「Sparkプラン（無料）」も驚異的です。

Cloud Firestore（データベース）の無料枠

  • 書き込み: 20,000 件 / 日
  • 読み取り: 50,000 件 / 日
  • 削除: 20,000 件 / 日
  • 保存容量: 1 GiB

※数値の根拠：Firebase Pricing

Authentication（認証）の無料枠

  • アクティブユーザー数: 50,000 MAU（月間アクティブユーザー）

月間5万人がログインするアプリになるまで、認証基盤がタダです。これを自前で実装・保守するコストを考えれば、Firebase一択と言えます。

3. 0円運用を実現するデータ設計のコツ

この構成で唯一「課金」が発生するリスクがあるのは、Firestoreの「読み取り回数（Read）」です。ここを節約する設計がエンジニアの腕の見せ所です。

対策①：N+1問題を絶対に避ける

リレーショナルデータベース（RDB）の感覚で、usersコレクションを取得した後に、ループ処理でそれぞれのpostsを取りに行くと、一瞬で無料枠（5万回）を食いつぶします。
NoSQLであるFirestoreでは、「読み取り回数を減らすためのデータの非正規化」（データを重複させて持たせること）を恐れないでください。

対策②：React Query / SWR でキャッシュする

フロントエンド側で SWR や TanStack Query を導入し、一度取得したデータはキャッシュを利用するようにします。
ユーザーが画面を行き来するたびにFirestoreへリクエストを飛ばさないようにするだけで、Read回数は激減します。

4. 注意点：この構成が向かないケース

万能に見えるこの構成ですが、向かないケースもあります。

  • 複雑な集計処理が必要なアプリ: Firestoreは集計が苦手です。
  • 画像・動画が大量に必要なアプリ: Vercelの帯域やFirebase Storageの容量を圧迫します。
  • 常駐プロセスが必要なアプリ: WebSocketサーバーや定期実行バッチ（Cron）は、別途Cloud Functionsなどが必要になり、課金トリガーになりやすいです。

まとめ：まずは「小さく、賢く」始めよう

個人開発は、技術力だけでなく「経営力（コスト管理）」も問われます。

最初はVercel × Firebaseの無料枠でリスクゼロで立ち上げ、ユーザーからのフィードバックを得ることに集中しましょう。サーバー代を気にするのは、アプリが愛され、収益を生み出し始めてからで十分遅くありません。

まずは「維持費0円」の安心感を手に入れて、コードを書く楽しさに没頭してください。

-開発・技術