はじめに
個人開発のWebアプリを無償で公開・運用したい。でもバックエンドが必要。しかもユーザーの位置情報を扱うからセキュリティも手を抜けない。
この記事では、お金をかけずにWebアプリを公開・運用するために、インフラとセキュリティをどう設計したかをまとめます。同じように個人開発で公開を考えている方の参考になれば。
実際に公開しているアプリはリアルタイム位置共有Webアプリ「あえるまっぷ」です。
GitHub Pagesだけでは足りなかった
フロントだけならGitHub Pagesが最強です。pushすれば公開完了、無料、楽。
ただ、リアルタイムにデータを同期するアプリだとバックエンド（DB・認証）が必要で、GitHub Pagesだけでは成立しません。そこでフロントはGitHub Pages、バックエンドはFirebaseという構成にしました。
Firebaseを選んだ理由はシンプルで、認証・DB・リアルタイム同期が無料枠でワンストップで揃うから。特にFirestoreのonSnapshot()によるリアルタイム同期は、WebSocketを自前実装しなくていいのが大きかったです。
最終的な構成はこうなりました。
無料枠に収めるための工夫
Firebaseは従量課金のBlazeプランを使っていますが、無料枠の範囲内で収まるように設計しています。意識したのは「いかにFirestoreへのアクセス回数を減らすか」です。
-
Cloud Functionsを最小限に：無料枠の回数制限が厳しいので、リアルタイム通信にはFunctionsを使わずFirestoreのonSnapshot()で直接同期
-
不要データを自動削除：古いデータを定期的に消すことで、ストレージもアクセスも肥大化しない
「機能を足す」より「アクセスを減らす」方向の設計が、無料枠で運用し続けるコツだと感じています。
位置情報を扱うならセキュリティは妥協できない
無償の個人開発でも、位置情報はセンシティブなデータです。ここは手を抜けません。
設計の基本方針は「Firestoreセキュリティルールだけでアクセス制御を完結させる」こと。具体的には、本人以外のデータは書き込めない、参加者以外にはデータが見えない、それ以外は全拒否、というルールです。
もう一つ重要なのが「残さない」設計。位置情報は目的が終われば保持する理由がないので、退出時に即削除、放置されても最大6時間以内に自動削除されるようにしました。データが存在しなければ漏洩しようがない、というのが一番確実なセキュリティです。
サーバーなしで定期削除をどう実現するか
「データを自動削除する」と決めたものの、定期実行（cron）にはサーバーが要ります。無償運用なのにサーバーを立てたら本末転倒。
Cloud Functionsのスケジュール実行（Cloud Scheduler連携）も選択肢にはありますが、従量課金なのでできれば避けたい。
ここで活躍したのがGitHub Actionsです。パブリックリポジトリなら無料で、cronスケジュール実行ができます。
on:
schedule:
- cron: '0 */3 * * *' # 3時間おきに実行
Firebase Admin SDKでFirestoreに接続し、期限切れデータを一括削除。サービスアカウントの鍵はGitHub Secretsに格納するだけ。サーバーを持たずに定期処理を無償で実現できました。
まとめ
個人開発を無償で公開・運用するうえで大事だったのは、「何を足すか」より「何を減らすか」を考えることでした。アクセス回数を減らせば無料枠に収まるし、データを残さなければセキュリティリスクも減る。定期処理もGitHub Actionsで十分回せます。