モバイルアプリ向けFirebase：ソロ開発者の経験談

2023年に、私は個人で初めてモバイルアプリをリリースしました - TaleMe - フルにFlutter + Firebaseの組み合わせに賭けました。2年後の結論は明白です：FirebaseはV1を驚異的な速さで出す助けになりましたが、2025年の振り返りでは問題点も見えてきました。

この文章では、ソロ開発者としての率直な経験談を共有します：Firebaseがモバイルアプリ開発で非常に得意な点、私が失望し始めた点、そして今ならどう取り組むか。

コンテキスト：なぜ2023年にFirebaseを選んだのか

フロントとバック両方を扱えるウェブ開発者として、2023年に子ども向けの物語を作るAIベースのモバイルアプリTaleMeを作りたいと思いました。開発は私一人で、モバイル経験はゼロ。V1の目標はシンプルでした：素早く、確実にリリースすること。アプリのコア機能、安全なユーザー認証システム、そしてサブスクリプション用のペイウォールが必要でした（ビジネスモデルの検証のため）。何ヶ月も車輪を再発明する時間はありません。

なぜFirebaseか？ 2023年当時、私にとっては明白な選択でした。Firebaseは必要な要素をすべて満たしていました：リアルタイムクラウドデータベース、すぐ使える認証、ファイルストレージ、サーバーサイド関数…しかも**「サーバーレス」**（デプロイや維持するサーバー不要）で、Flutterとネイティブに統合されている（公式プラグイン経由）。加えて、寛大な無料枠があり初期費用なしで始められる—MVPには理想的です。マネタイズのために、アプリ内購入は手間を避けるためにすぐに外部サービス（RevenueCat）を選びました。要するに、フロントにFlutter、バックにFirebaseを使えば、必要なパーツはすべて揃っている状態で高速にスタートできました。

Spoiler: 速度を重視したのは正解でした：ほとんどモバイル未経験の状態からでも、初版をわずか4週間でコーディングして公開（ストア審査含む）できました。V1としてのミッションは達成です！ しかし、長期的にはどうだったか？ 本題に入ります：Firebaseは私に何をもたらしたか…そしてその代償は何か？

Firebaseがモバイルアプリに対して非常にうまく機能する点

⏩ 圧倒的なTime-to-market

Firebaseの第一の利点は、開発スピードを飛躍的に上げることです。FirebaseとFlutterを組み合わせることで、驚異的な速さでアプリをブートストラップできました。Googleが大げさに言っているわけではありません："FirebaseをFlutterアプリに統合すると、より少ない時間と労力で市場に出し、ユーザーに価値を届けることができます。[…]"。実際、私はほとんど「典型的な」バックエンドをコーディングする必要がありませんでした。データベース、認証、メディアホスティング、すべてがオンデマンドでサービスとして利用可能です。2023年のソロ体制では、アイデアから動くアプリに到達する最速の手段だったのは間違いありません。もしFirebase（とFlutter）がなければ、遥かに時間がかかっていたでしょう。

🤝 Flutterとの統合とDXが最高

FirebaseはFlutterとの**優れた統合と洗練された開発者体験（DX）**でも光ります。公式のFlutterFireプラグインはほぼすべてのFirebase製品をカバーしており、ドキュメントもしっかりしていてコミュニティも活発です。プロジェクトにFirebaseを追加するのは難しくありませんでした：FlutterFire CLIを一度叩き、いくつかの設定をすれば、一連のサービスにアクセスできます。

結果として、私はアプリのビジネスロジックのコーディングに集中でき、インフラの配線に時間を取られませんでした。クライアント側がDart/Flutterエコシステムに留まることで開発がスムーズになります。

確かにバックエンド（Cloud Functions）ではTypeScriptで書く必要があり（後述します）、共有コードが書けないのは課題でしたが、Flutter側の開発者体験はとても快適でした。Firebaseはソロや小規模チームがツールと格闘せずに生産的になれるよう設計されていると感じます。

🧰 統合された便利なプロダクト群

Firebaseのもう一つの利点は、オールインワンのエコシステムであることです。Firebaseを導入することで、追加の統合作業なしにアプリにとって非常に便利な多数の補助的サービスが使えるようになります：

• Crashlytics（クラッシュレポート） - 標準で含まれている。プロダクションのエラー報告を即座に受け取れ、バグ修正に不可欠でした。Sentryなどを別途繋ぐ必要がありません。
• Analytics（Google Analytics for Firebase） - ユーザー行動を理解するために。数クリックでリテンションや表示画面などのダッシュボードが得られ、プロダクトの改善に非常に役立ちました。
• Cloud Messaging（FCM） - 無料のクロスプラットフォームプッシュ通知。アプリ側の少しの設定とサーバー側のCloud Functionでユーザーに通知を送れます（例えば新機能の案内など）。
• Remote Config / A/B Testing - リモートでフィーチャーフラグを切る、あるいは機能のバリエーションをテストする機能。小規模にしか使いませんでしたが、最初から「箱から出して使える」ことは安心材料でした。
• Performance Monitoring、App Distributionなど - パフォーマンス監視やベータ配布などのツールも組み込みで提供されます。TaleMeの初期では全部は使い切りませんでしたが、必要時にすぐ有効化できるのは大きな快適さでした。

要するに、Firebaseは私にとってモバイル開発の「スイスアーミーナイフ」でした。すべてを一人でこなさねばならないソロ開発者にとって、これらのツールが手元に揃っていて相互に統合されていること（例：クラッシュとアナリティクスが同じコンソールにある、通知がFirebase Authと連携する等）は時間の節約になります。Time-to-market +1、間違いなく。

ここで問題が出始める…

当然ながら、全てが良いわけではありません。TaleMeが単なるPOCから本番運用中のプロダクトへ移行するにつれて、「全部Firebaseでやる」選択の限界と落とし穴が見えてきました。主な摩擦点は次のとおりです：

📦 POCがプロダクションに（いわゆる「全部Firebase」技術的負債）

初めはアプリをプロトタイプ風にシンプルに構築しました。ロジックは主にFirestore（NoSQL）と数本のCloud Functionsに集中していました。正直、当初はアーキテクチャを深く考えませんでした：Firebaseは多少「プラグアンドプレイ」を促します。しかし時間が経つにつれ、このアプローチが私に跳ね返ってきました。

MVPではうまく機能していたものが、機能を追加するにつれて複雑化しました。ビジネスロジック（AIを使った物語生成、コンテンツ管理など）がクライアント側のFlutterコードとサーバー側のCloud Functionsに分散してしまったのです。これが「全部Firebaseに詰め込む」症候群です：早く始められますが、気づくとFirestoreのセキュリティルール、サーバーレスのトリガー、そしてモジュール化されていないクライアントコードが混在してしまいます。

具体例を挙げると：当初、ファイルアップロード（AIで生成した画像/ビデオ）はクライアントから直接Firebase Storageへ送っていました。シンプルですが、ユーザーの検証やサーバー側でのメディア処理（文字起こし、サムネ生成…）やOpenAI APIの安全な呼び出しをしたいときには不十分でした。そのため、ファイルを受け取り処理してから保存するHTTP Cloud Function経由のアップロードを実装する必要がありました。技術的には問題なく動きます（私はその件でtutoriel à ce sujetも書きました）が、これは「フロントだけの小さなPOC」がいかにしてかなりのバックエンドを必要とするようになるかを示す例です。結果として、クライアントのDartコードと関数のTypeScriptコードを行ったり来たりすることになりました。

🔄 Cloud Functions：二つのエコシステムを維持する必要

次にFirebaseのCloud Functionsについて。サーバーを管理せずにバックエンドコードを実行できるのは素晴らしい機能ですが、Flutter開発者にとっての欠点もあります：関数はJavaScript/TypeScript（またはベータのPython）で書く必要があり、Dartで書けません。つまり、FlutterアプリとFirebaseバックエンド間でコードを共有することができず、二つのコードベースを別言語で維持しなければならないのです。ソロ開発では、このコンテキストスイッチが速度と信頼性にコストをもたらします。

私自身はJS/TSは扱えましたが、クライアント側にあるデータ構造やバリデーションのルールをサーバー側で再実装するのはフラストレーションでした。テストツールやデバッグ体験（Cloud FunctionsのログとFlutterエミュレータのデバッグは別物）も違います。

要するに、Cloud Functionsをあちこちに追加すると必要に応じては動きますが、長期的には技術的負債とバックエンドを進化させる際の複雑さを招きます。

小さなPOCは、注意しないと「小さな工場」になり得ます。

🗄️ NoSQLモデルとベンダーロックイン

Firebase = Firestore（NoSQL）であり、これが初期に与える影響を私は完全には理解していませんでした。NoSQLの柔軟性（固定スキーマなし、JSONドキュメントを保存する）はプロトタイピングには非常に魅力的です。

プロトタイプには最高です。

しかしアプリが成長するにつれ、より構造化されたデータではNoSQLの限界を感じました。例えば、コレクションをまたぐ複雑なクエリや複数フィールドでのフィルタが増えると、Firestoreはあまり得意ではありません。本物のJOINがないためにデータの複製で補ったり、クライアント側で小さなクエリを多数発行して整合性を自分で管理する必要が出てきます。

Supabaseのドキュメントが要約するように： « Firestoreのスキーマレス設計はプロトタイプを簡単にします。データ関係が複雑になると、クライアント側で結合を処理するかデータを非正規化する必要があります。 »。まさにその通りです。振り返ると、TaleMeのあるデータは伝統的なSQLデータベースの方が適していたでしょう…

また、Firebaseのベンダーロックインの問題も避けられません。始めたときはあまり考えません（「スケールしたら考えよう」）。しかし2025年になりユーザー基盤が増えると、私のすべてのデータとロジックがGoogle Firebaseに依存していることを強く実感します。別の場所（カスタムサーバーや別のBaaS）へ移行するのは大規模な工事になります。FirestoreのデータをSQLにエクスポートするのは単純ではありません（SupabaseやAWSへの移行ツールはあるにせよ）。

Firebaseエコシステムへの依存度は現実的な問題です：独自API（FirestoreやFCMなど）や特有のセキュリティルール…時間が経つほど「抜け出す」のは難しくなり、技術的妥協を受け入れざるを得ない状況になることがあります。

私は今、本気でその点を考えています（それがこの記事の背景です）。

💸 見えにくいコスト：パフォーマンスと予算の請求額

最後に、重要な点：Firebaseは永遠に無料ではないこと、そして課金体系が頭を悩ませることがある点です。最初はすべて無料枠内で収まっていました。

しかし成功（たとえ小規模でも）は使用量の増加を意味し、するとFirestoreの読み書き、Cloud Functionsの呼び出し、ストレージ、帯域などを注意深く監視する必要が出てきます。

Firebaseの従量課金は常に予測可能とは限らず、最適化を怠ると驚きの請求が来ることがあります。たとえば、悪いクエリでドキュメント読み取りが爆発的に増えたり、頻繁に呼ばれるCloud Functionが無料枠を超えたりします。ユーザー体験談は多数あります：« Firebaseの価格はアプリがスケールすると高額になり得るため、よりコスト効率の良い代替を探す開発者もいる… »。

私の場合、まだ予算を破綻させるほどではありませんが、常に「コスト最適化」を考える精神的負担は確かにあります。キャッシュ戦略の微調整、書き込みのバッチ化、使用状況ダッシュボードの監視に時間を費やし、これは機能開発に使えた時間ではありません。

パフォーマンス面でも、Firestoreの制限（全文検索がない、インデックスを正しく設定しないとクエリが失敗または遅延する）に向き合わなければなりません。Cloud Functionsのコールドスタートも一部ページで遅延を生みました。

致命的ではないものの、これらの小さな摩擦が積み重なり、2025年にはFirebaseの**実際のコスト（金銭的・認知的）**をより強く意識するようになりました。

2025年に変わったこと

ローンチから2年が経ち、私の視点は当然変わりました。2025年時点で：

• スキルアップ： 2023年とは別人のように成長しました。Flutter/Firebaseで手を動かしTaleMeを進化させる中で、モバイルやモバイルアプリのアーキテクチャについて多く学びました。技術的な自信と専門性が増しました。
• AIが共助者に： 開発の風景も変わりました。AIコパイロットの台頭でソロ開発者が楽になっています。Expressのバックエンドコードを生成したり、移行スクリプトを書いたり、SQLクエリを作るといった作業をAIが手伝ってくれるため、2023年にフルスクラッチで書くのが重かったものが2025年にはずっと楽になっています。
• 新たな優先事項：テスト可能性、移植性、堅牢性： 振り返ると、アーキテクチャ面を重視するようになりました。例えばテスト可能性—2023年はCloud Functionsのテストをあまりやっていませんでした（Firestoreのモックが難しい）。今はユニット/統合テストを書きやすいバックエンドが欲しいと思います。同様に移植性や堅牢性も重視します：ロックインの限界を経験したので、よりオープンな選択（標準的なSQLデータベース、他クラウドへのデプロイなど）に価値を見出しています。要するに、初速を少し犠牲にしても長期的に保守可能な基盤を作りたいと考えるようになりました。開発のジレンマは変わらず：最初に時間を節約する選択は後で時間を失わせることがある。

まとめると、私の見方は変わりました：Firebaseは今でも素晴らしいツールですが、今はそれを一要素として賢く使い、全てを魔法のように任せるのではなく構築を意識した上で使うべきだと考えています。

では、2025年にソロのモバイル開発者がバックエンドスタックを選ぶとしたら、私の推奨は？

私の現在の推奨（2025年のソロ開発者向け）

今日からモバイルアプリを始める独立開発者にアドバイスするとしたら、バックエンドのスタックはこう考えます：

Option 1 : Firebase + 専用バックエンド（良いとこ取り）

これが新しい少し野心的なプロジェクトで私が採るであろうアーキテクチャです。アイデアは：Firebaseは得意な部分に使い、残りは自前のバックエンドに委ねること。実践的には、Firebase Auth（統合が容易で堅牢）、Cloud Messaging（プッシュ）やCrashlytics/Analytics等は残し、高度なビジネスロジックや機密処理（OpenAI等の外部API呼び出し、複雑な計算、データ管理）は分離した小さなAPI（REST/GraphQL）で扱います。

Node/Expressでも、NestJSでも、PythonのFastAPIでも良い—重要なのは、Cloud Functionsの制約から解放されてロジックをきれいに書けることです。

このバックエンドは必要に応じてSQL等のデータベースを使います。FirebaseとこのバックエンドはHTTPSなどで通信します。フルFirebaseより少し手間はかかりますが、Firebaseを無理矢理ねじ曲げる必要がなくなります。

汎用的な部分はFirebaseで素早く出しつつ、コアの制御は自分のバックエンドで行う。2025年のソロ開発ならツールやAIの助けもあり、数日でAPIのプロトタイプを作ることも十分可能です。

Option 2 : Supabase（やSQLベースのBaaS）でより開かれたバックエンド

2025年のもう一つの有力な選択肢は、SQLベースのBaaSに移ることです。代表はSupabaseで、Auth、Storage、Functions、リアルタイム等Firebaseに近い体験を提供しますが、ベースはPostgreSQLでオープンソースです。Supabase は要するに「同様のサービス群（認証、ストレージ、リアルタイム、関数）を備えつつ、SQLの予測可能性とセルフホスティングの自由を提供する」ものです。

つまり関係スキーマ、強力なクエリ、トランザクション（ACID）などが必要な場合、Supabaseは魅力的です。セルフホストも可能でロックインが緩い。BaaSの簡便さを保ちながらFirebaseのいくつかの制約を回避できます。もちろんSQLの扱いに慣れる必要がありますし、エコシステムはFirebaseより若いですが、構造化されたデータが多いなら学ぶ価値は大きいです。

他にもAppwrite、PocketBase、Parse、あるいはAWS Amplify等の選択肢がありますが、SupabaseはFirebaseの代替として2025年に最も注目に値するものの一つです。TaleMeをゼロからやり直すなら、ロックイン回避と最初からリレーショナルDBを使うためにSupabaseを真剣に検討するでしょう。

Option 3 : Firebaseに留まるがきちんと分離して使う

それでもFirebaseの恩恵を最大限に享受したい場合（Flutterとの統合は素晴らしいし、小さなアプリならFirebaseだけで十分機能することも多い）、将来を見越してきちんと分離する方針を取るべきです。つまり、ビジネスロジックをFirebaseに直接埋め込まず、抽象化しておく。

具体的には、Flutterアプリ内でリポジトリ層を設けてFirebase呼び出しを隔離し、UIに直接.doc().get()を散りばめない、Cloud Functionsはモジュール化して1万行の巨大関数を避ける、Emulator Suiteでユニットテストを整備してセキュリティルールと関数を検証する、などです。

目的は将来的な移行を「可能にする（あるいは少なくとも痛みを軽くする）」ことです。データアクセス層が分離されていれば、FirestoreからPostgresへの移行はその層の変更だけで済む可能性があります。同様に、ビジネスロジックがカプセル化されていれば別バックエンドへ再実装するのも楽です。要するに、_「Firebaseに留まる＝閉じ込められる」ではない_ということを意識して設計するのが重要です。2025年の経験から言うと、初期に少し設計をしておくだけで将来の自由度は大きく変わります。

TaleMeを作り直すなら私が変えること（もしやり直せるなら）

具体的に言うと、2023年の自分にアドバイスするとしたら、TaleMeについてFirebaseに関して以下を残す／変えるでしょう：

迷わず残すもの：

• Firebase Authentication - 時間の節約効果が大きく、非常に信頼できる。登録、ログイン（メール、Google、Apple…）、パスワード回復などを自前で作るのは時間とセキュリティリスクの無駄です。Firebase Authは完璧に仕事をしてくれるので、2025年でも迷わず使います。
• Crashlytics & Analytics - 本番で不可欠。無料で統合されており、クラッシュ検出（Crashlytics）や利用状況把握（Analytics）に大いに役立ちました。どのバックエンドを選ぶにせよ必須のツールです。
• Flutter + Firebase（クライアント統合） - FlutterFire SDKはよくメンテされており、少ないコードでFirebaseを活用できます。リアルタイムが必要な場合やシンプルなデータ保存にはFirestoreは便利です。Firebase Cloud MessagingもFlutterFire経由で使い続けます。

変える／避けること：

• 構造化データをすべてFirestoreに置かないこと： やり直すなら、関係性のあるデータ（ユーザー、物語、章など）については最初からSQLを導入します。場合によってはFirestoreを一部のリアルタイム用途に残し、残りをPostgresにするか、Supabaseに移行するでしょう。目的は長期的にクエリや構造の制約に悩まされないことです。
• ビジネスロジックをCloud Functionsに詰め込み過ぎないこと： AIによる物語生成のような複雑な処理は、別の軽量バックエンド（NodeやDeno等）で作ってHTTP経由で呼ぶ方が良いです。独立デプロイ、ユニットテスト、管理の観点で有利ですし、NodeJSとDartを同じプロジェクトで混在させる煩雑さも避けられます。
• V1からアーキテクチャを多少意識すること： 2023年は「YOLO、出してから考える」をやってしまいました。もし2025年に戻れるなら、初期の数日でアーキテクチャ方針（明確なモジュール化、フロントとバックの責務分離、テスト戦略、セキュリティとバリデーション設計）を決めます。長時間はかけずに、しかし将来の柔軟性を担保する程度の設計は必要です。問題はFirebase自体ではなく、設計なく使い倒すことでした。

結論

振り返れば、Firebaseは「問題」ではなかった：むしろTaleMeを迅速に開始しコンセプトを検証する上で理想的な選択でした。

その利点（開発速度、統合されたサービス、自動スケーリング）は、ソロ開発者がV1目標を達成するのに大いに寄与しました。

ただし学んだことは、アーキテクチャを決めないこと自体が選択であり、多くの場合誤りにつながるということです。Firebaseの快適さに身を任せすぎた結果、技術的負債や後で調整が必要な制約を抱えました。もう少し俯瞰して設計していれば避けられたものもあります。

良いニュースは、2025年にはバックエンド構築の選択肢がこれまで以上に豊富になっていることです：Firebaseと自前バックエンドの混在、Supabaseのような代替、AIの支援によるコーディング効率化など。重要なのはアプリの持続可能性を意識すること：Firebaseは素晴らしい加速装置ですが、適切にブレーキをかけ、周囲に堅牢な基盤を築くことが必要です。

Et vous, quelle est votre expérience avec Firebase (ou ses alternatives) ? Avez-vous aussi connu le syndrome du MVP "100% Firebase" qu'on doit refactorer ensuite, ou au contraire tout s'est bien passé ? Partagez vos retours en commentaire, ça m'intéresse !