MENU

個人開発を「Production Ready」へ。Firebaseで構築する本番運用の基盤(Project1-6)

記事サムネイル「個人開発を「Production Ready」へ。Firebaseで構築する本番運用の基盤(Project1-6)」。

今回はセクション3(バックエンド)の実装にFirebase機能を使って行っていきます。

セクションと呼ぶ理由については以下の記事をご覧ください。

始めに以下のFirebaseの3つのバックエンドを実装していく事を公表します。

  1. Analytics:測定ツール
  2. App Hosting:公開ツール
  3. Remote Config:運用ツール

この記事の流れ:

1.私がなぜこの3つを選択したのかの理由。→2.3つの機能の説明→3.使用するFirebase機能のコストについて→まとめの順になっています。Firebase Documentから引用し私がわかりやすく説明しているのでぜひご覧ください。

もし詳細が知りたい場合は、Documentへのリンクもあるのでそちらから情報を確かめる事もできます。


目次

私がなぜこの3つの機能を選択したのか?実装の決め手

「なぜこの3つなのか?」のリストアップ:
App Hosting:
  • 一貫性:Googleのエコシステム内で公開(デプロイ)が可能である
  • 保守性:Google Cloud によりバックアップで管理がしやすい
  • 使いやすさ:Firebase Studioでも1プッシュで公開する事ができる。
Analytics:
  • 汎用性:初心者でも導入しやすく、詳しくなれば詳細な設定もできる。
  • 使いやすさ:利用料金なしでデータを取得して分析できる。
  • 個人的問題:私自身Analyticsしかデータを取れるサービスを知らない。
Remote Config:
  • 小回り:アプリの運用で細かい操作や見た目をデプロイせずに変えられる。
  • 最適化測定:機能や背景のA/Bテストがしやすい。
  • ユーザー体験:条件を付ける事でユーザーの状況にあった提供が可能になる。

機能面での評価は以上のような利点があると感じています。

数あるFirebaseの機能の中でなぜこの3つなのか?私の理由で説明

App Hosting

これから世の中に公開していく上で必要なパッケージを持っているので説明しなくても導入せざるを得ない機能と言えます。動的アプリケーションであるためApp Hostingが対象。

Analytics

答え合わせの為に導入しようと思いました。実際に「数値」として現れないと「このアプリは市場に合っているのか?」がわからないからです。

Analyticsの良い所

無料で扱うことができ、どのように使用されているのかを知る事ができます。それによってより良いアプリの改善に繋がりユーザーの使いやすさに繋がっていくと思います。

Remote Config

私も聞いたことがなく挑戦的な導入です。以下のような説明がとても魅力的に感じ、細かいデザインや色・文字を直した後、一回一回アップデートする必要がなく、個々のユーザーが起動したときに更新されるようになるからです。

これは、時間短縮になるだけでなくバイブコーディングを行う私にはちょっとした変更点にもユーザーを待たせることなく気軽に変更できるので「良い!」と思いました。

アプリのアップデートを公開しなくても、ウェブ クライアントまたはサーバーの動作と外観を変更できます

Firebase Remote Config Document 説明引用

また、ユーザーによってA/Bテストが行えたり初回ユーザー用に使い方のチュートリアル画像の表示ができたりと使い勝手が良いのもポイントです。


AppHosting,Analytics,RemoteConfigがどういった機能なのかの説明

まず始めにここでは、Firebase Documentを読んで解釈した内容を基に記述していきます。

さらに詳しく知りたい場合は、Firebase Documentのリンクを貼っているので、そちらでご確認ください。

1.App Hosting:Firebase App Hosting

まずApp Hosting は、一言で言うと

動的ウェブアプリ(例:SNS、ショッピングサイト)のデプロイを効率化してくれるものです。

App Hostingの主なステークホルダー:【GitHub】と【GCP(Google Cloud)】です。

外部のサービスであるGitHubと深く連携しており、コードを書き換えるだけでビルドから公開までを自動的に安全に行ってくれるのが特徴です。

事前構成済み開発サポートフレームワーク:なんでも実装するだけで公開できるわけではなく、Googleが直接サポートしているフレームワークは以下の2つです。

Next.js】や【Angular】のフルスタックな開発を行えるフレームワークをサポートしています。この2つのフレームワークに関しては、公式でGoogleのサポートチームが問題報告や機能リクエストを受け付けています。

さらに詳しく知りたい方に:App Hosting のフレームワークとツール  |  Firebase App Hosting

App Hostingの流れ:以下の画像を見るとわかりやすいと思います。

Firebase App Hostingの公開までの流れを説明した画像。
Firebase App Hostingの流れを説明した画像。

Firebase Hosting機能との違い

もう一つ似たような機能に【Hosting】というFirebase機能があります。

それは、静的webアプリ(例:会社のホームページ、掲示板に貼られたポスター)に最適化されており、無料でストレージ(許容量:10GB)とデータ転送(許容量:毎月10GB)を使って公開していきます。またGoogle が運営するグローバル CDN(コンテンツ・デリバリー・ネットワーク)も自動で利用できます。

機能の選び方のススメ

「まずはシンプルなWebサイトを公開したい」なら Firebase Hosting

「Next.jsなどで本格的な動的アプリを作りたい」なら App Hosting

と作って発信したいコンテンツによって使い分ける事ができます。


2. Analytics(アナリティクス):Google Analytics for Firebase

Google Analyticsの特徴:無料で使える分析ソリューションです。

Analytics は Firebase 機能と統合されていて、Firebaseを通して定義できる最大 500 種類ものイベントに対応しており無制限のレポート作成機能を備えているのが特徴です。自身で管理するFirebaseのプロジェクトコンソールから確認する事ができます。

この機能を使うことでできる事:

レポートを見る事でユーザーの行動を把握でき、マーケティングやパフォーマンスの改善に繋がる、データに基づいた行動をとる事ができます。

他にも「どんなデータを取りたいのか」を柔軟にカスタマイズして取得する事もできるので、初期データだけでなく欲しいデータを設定する事もできます。


3.Remote Config:Firebase Remote Config

Remote Configを一言で言うと

アプリのアップデートを公開しなくても、ウェブ クライアントまたはサーバーの動作と外観を変更する事ができます。

例えば、アップデートを行った後、ユーザーにアプリのアップデートのダウンロードを依頼する必要がなくなります。

Remote Configがどのように動いているのか?:

作成したパラメータ値のフェッチ(データを取得する)やパラメータ値をキャッシュに保存できるクライアントライブラリが含まれています。

パラメータ値はキーとバリューの関係であり、プロジェクトのコード内でキー(例:my_key_color)を予め設定しておく事で、このキーに対応したバリューを変更できるといった形で対応しています。

ちょっとしたポイント:

フェッチする感覚も設定でき(default:12H)、開発中であればすぐにフェッチできるように短くするのがおススメです。

ご利用の際の制限情報:

1.Firebase プロジェクト内には、最大 3,000 個のパラメータ、最大 2,000 個の条件を設定できます。

2.バージョン管理(変更履歴)も最大300件、又は90日間まで自動管理でき、それを超えると古いものは削除され自然に整理されます。なので安心して設定変更できる仕組みにもなっています。これは、「1つ前の正常だったバージョンに戻す(ロールバック)」の操作ができるのであります。

利用の際の注意点:

  • ユーザー承認が必要なアップデートは作成しないように。信頼できないアプリと判断される恐れがあります。
  • 機密データでの使用は、ユーザーがアクセスできてしまいます。
  • ターゲット プラットフォームの要件を回避しようとしないでください。(後だしじゃんけんや規制の回避に使わないで)
「フェッチ (Fetch)」とは?

「フェッチ」=「親(Firebase)に『新しい指示ある?』と聞きに行くこと」


3つの機能のコストについて

App Hosting・Analytics・Remote Configのコスト面について把握できるような情報をお伝えしていきます。

(現在2026/01/31時点の情報)※コストがかかるものは必ず一度Documentを確認する事をおススメします。

Firebase プライシング表(spark:無料プラン/blaze:従量課金)

公式サイトやDocumentを確認の上で開発に実装していく事をおススメします。

Firebaseでは、基本的にそれぞれに強力な無料枠があるため、個人開発レベルなら実装しやすいと感じています。

私が今回実装する機能のコスト面:(2026/01/31時点)

無料でサービスが提供されています。

無料でサービスが提供されています。

この機能の中で一番入り組んでいるのがApp Hostingです。ここが変動要素になってきます

App Hostingは、単一の料金プランではなく、裏側で動いている Google Cloud の各サービスの合算 で決まります。

利用する事でコストの対象となるサービスが以下の6つのサービスです。

App Hostingの費用について

コンピューティング(Webサイトを動かすエンジン)

  • Cloud Run (サーバー本体):Next.js の SSR(動的処理)を行う場所。
    • 無料枠: 月間 200万リクエスト180,000 vCPU秒 まで無料。
    • 目安: 1日あたり約1万回画面が見られても無料です。
  • Cloud Build (ビルド工場):GitHub に Push した時に、アプリを組み立てる機能。
    • 無料枠: 1日 120分 まで無料。
    • 目安: 1回のビルドが3分だとしても、1日40回デプロイできます。

ストレージとネットワーク(倉庫と配送)

  • Artifact Registry (コンテナ置き場):ビルドされたアプリ(Dockerイメージ)の保管場所。
    • 無料枠: 月間 0.5 GB までストレージ無料。
    • 注意点: デプロイを数百回繰り返すと容量が増えるため、古いバージョンを自動削除する設定(ライフサイクルポリシー)を入れると安心です。
  • データ通信量:ユーザーへのデータ転送量。
    • 静的ファイル(cached): CDN経由。高速かつ安価(Firebase Hostingの枠組み)。
    • 動的生成 (Uncached): Cloud Run から直接送るデータ。月間 10 GB まで無料(北米リージョン等の場合。条件により異なる)。
  • Cloud Logging:ログ保存管理。
    • Logging ストレージ50 GB / プロジェクト / 月
    • ロギングの保持30 日間無料
  • Secret Manager:環境変数(APIキー)管理。
    • アクティブなシークレット バージョン6 バージョン / 月

Firebase Documentでは【サンプル請求書】にて実際に利用した場合のシナリオが用意されています。これを見る事で費用感を掴めると思います。

サンプル請求書※前提条件も加味していますのでご確認ください。


他の実装している機能:Firestore Database & Authentication

Firestore:Standardエディションでは、 1日 5万人 がデータを読み、2万人が書き込み・削除が発生したら、ようやく課金が始まるレベル。

Firestore無料割り当ての詳細

Firebase Docより。Firebase Firestore Databaseの無料枠の利用量の表の画像。
Firebase Docより。Firebase Firestore Databaseの無料枠の利用量の表の画像。

Authentication:月に5万人以上のアクティブユーザーがログインする事で、その超過分に料金が発生するものです。ある月にログインしたアカウントは、その月のアクティブ ユーザーと見なされます。

※電話 / SMS 送信は別途料金発生アリ

Authentication(Identity Platform)の料金詳細について


最後に

為替やリージョン、Googleのポリシー変更により変動する可能性があるため、必ず Google Cloud 料金計算ツール予算アラートを設定しましょう。

予算アラートについてはセクション5(セキュリティ・クォータの設定)で記事にしようと思います。


まとめと次回

今回は、セクション3(バックエンド実装編)の実装するバックエンドの説明を主に記事にしてきました。

紹介したFirebase機能
  • App Hosting
  • Analytics
  • Remote Config

記事の流れ:

  • なぜこの3つを選択したのか?
  • そのバックエンドの特徴の説明をFirebase Docを基に作成。
  • それぞれのコストについて説明。
  • まとめ

次回は、この3つのバックエンドの実装を行っていきます。

ここまで読んでいただきありがとうございました。

筆者感想

こうしてまとめているとFirebaseについて詳しくなっている感覚があります。書き込んでいく事で何を知りたいのかを考える学習のきっかけにもなっています。実践だけでなく記事に残すことでメモのような役割として今後も活用できるかなと感じます。

Doc確認の重要性:今後の私のポリシーとして

「AIはコードを書いてくれるが、仕様までは保証しない。だから最後は人間がDocで検閲(Review)する」というのを念頭に置いてプロジェクトを進めていきたいと思います。

今回参考にしたサイトリンクのまとめ

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

始めまして。このブログを運営するTomoyaです。
未経験個人開発者。AI×個人開発(Vibe Cording)で学習して参入してくれる人が増えて広がっていくと良いなと思って始めました。

実際に作成→デプロイ(公開)→運営を行ってそれについての問題や疑問を記録していきます。
また行っていく上で内容(セキュリティ・制限など)にもこだわっていきたいなと思っています。

コメント

コメントする

目次