Firebase・Supabaseプロジェクト移管の罠
「バックエンドは全部Firebaseです。プロジェクトのオーナー権限を移せば引き継ぎ完了ですよね」── BaaS（Backend as a Service）で構築された事業のM&Aで、こう語られることは多い。しかし実際にプロジェクトを引き継ごうとすると、課金アカウントの紐付け、サービスアカウントの権限、クライアントアプリに埋め込まれた設定値、認証ユーザーの移行、Cloud Functionsのシークレット ── これらが次々と「オーナー権限の移管だけでは引き継げない」項目として立ち現れる。
FirebaseやSupabaseは、認証・データベース・ストレージ・サーバーレス関数・プッシュ通知を一括で提供するため、事業の裏側がまるごとこの一つのプロジェクトに集約されていることが多い。集約されているということは、移管が失敗したときの影響範囲も事業全体に及ぶということだ。そして、その移管にはプラットフォーム固有の罠が複数潜んでいる。
本稿では、FirebaseとSupabaseのプロジェクト移管における課金・権限・Functionの引き継ぎの盲点、クライアント埋め込み設定と認証ユーザー移行の難所、両プラットフォームのロックイン度合いの違い、そして移管リスクをバリュエーションにどう織り込むかを、現場目線で整理する。
1. BaaS移管が「オーナー権限の移管」で終わらない理由
1-1. プロジェクトは複数の所有レイヤーにまたがる
Firebaseプロジェクトは、その実体としてGoogle Cloudプロジェクトの上に乗っている。プロジェクトの所有権、課金アカウントの紐付け、IAMによる権限管理、サービスアカウント ── これらは別々のレイヤーで管理されており、「Firebaseコンソールのオーナーを変える」だけでは、課金や下層のGCPリソースの所有が移るわけではない。
Supabaseも同様に、組織（Organization）とプロジェクトという階層があり、課金は組織に紐づく。プロジェクトを別組織に移す、あるいは組織のオーナーシップを移すという操作が必要で、単純なメンバー招待では事業の所有は移らない。BaaSの移管は、表層のコンソール権限の下にある課金とインフラの所有レイヤーまで含めて、初めて完了する。
1-2. 事業全体が一つのプロジェクトに集約されるリスク
BaaSの利便性は、バックエンドを一つのプロジェクトに集約できることだ。しかしこれは、移管時には「単一障害点」になる。認証・DB・ストレージ・関数・通知のすべてが一つのプロジェクトに乗っているため、移管プロセスのどこかでつまずけば、事業の複数の機能が同時に止まる。
さらに、開発環境・ステージング・本番が同一プロジェクトに同居していたり、複数の事業が一つのプロジェクトを共有していたりすると、移管対象の切り分け自体が困難になる。DDでは、移管対象の事業がプロジェクト単位でクリーンに分離されているかを最初に確認する。
2. 課金とサービスアカウントという下層の盲点
2-1. 課金アカウントの紐付け替え
Firebaseの従量課金（Blazeプラン）は、GCPの課金アカウントに紐づく。プロジェクトを引き継ぐには、課金アカウントを買い手側のものに紐付け替える必要がある。この紐付け替えのタイミングを誤ると、旧オーナーの課金アカウントに請求が続く、あるいは課金アカウントが切れて従量課金機能が停止する、といった事態が起きる。
Supabaseでも、課金は組織に紐づくため、プロジェクト移管に伴って課金の引き継ぎを設計する必要がある。課金の連続性は、決済アカウント（#36 Stripe）と同様、移管タイミングの設計を誤ると機能停止か二重課金を招く論点だ。無料枠で運用している事業でも、移管後にスケールすれば従量課金が発生するため、課金主体の整理は必須になる。
2-2. サービスアカウントとIAM権限のゾンビ化
Firebase/GCPでは、サーバー間連携やCI/CD、外部サービスとの接続にサービスアカウント（とその鍵）が使われる。これらのサービスアカウント鍵が、旧オーナーの管理下で複数発行されたまま残存していると、移管後も旧体制が下層リソースにアクセスできる状態が続く。
これは本連載で繰り返し扱ってきた「ゾンビ権限」のBaaS版だ。DDでは、IAMの権限割り当て一覧とサービスアカウントの棚卸しを行い、不要なもの・出所不明なものを無効化する。サービスアカウント鍵は、Wikiやコードに平文で埋め込まれていることも多く、機密棚卸し（#45）と連動して確認する必要がある。
3. クライアント埋め込み設定と認証ユーザーの移行
3-1. アプリに焼き込まれた設定値とOAuthクライアントID
Firebaseのクライアント設定（APIキー、プロジェクトID、FCM送信者ID等）は、モバイルアプリやWebアプリのコードに埋め込まれている。プロジェクトを別のものに移す（新規プロジェクトを作って移行する）場合、これらの設定値が変わるため、アプリ側の更新と再リリースが必要になる。モバイルアプリの場合、ユーザーがアップデートするまで旧設定で動き続ける。
特にGoogle/Appleサインイン等のソーシャル認証は、OAuthクライアントIDがプロジェクトに紐づくため、プロジェクトを変えると認証連携の再設定が必要だ。FCM送信者IDが変わればプッシュ通知が届かなくなる。「プロジェクトを作り直して移行する」アプローチは、クライアント側の連鎖的な再設定とアプリ再リリースを伴う。だからこそ、新規作成ではなくプロジェクトそのものの所有権移管が望ましい。
3-2. 認証ユーザーの移行という難所
仮にプロジェクトを作り直す場合、最も難しいのが認証ユーザーの移行だ。Firebase Authはユーザーのパスワードハッシュをエクスポート/インポートできるが、ハッシュ方式とパラメータを正確に引き継がないと、移行後にユーザーがログインできなくなる。ソーシャルログインのユーザーは、OAuth設定の再構築が必要だ。
Supabaseの場合、認証情報はPostgresのテーブルに格納されており、DBダンプで移行しやすい反面、auth周りのスキーマとRLS（Row Level Security）ポリシーを正確に引き継ぐ必要がある。ユーザー認証の移行は、一人でもログインできなくなれば直ちに顧客影響が出る、最も神経を使う領域だ。
4. Cloud Functions・Edge Functionsとセキュリティルール
4-1. 関数のコード・環境設定・トリガーの引き継ぎ
Cloud Functions（Firebase）やEdge Functions（Supabase）には、事業ロジックの一部が乗っている。これらの引き継ぎには、関数のソースコードだけでなく、環境変数・シークレット、デプロイ設定、トリガー（DBの変更トリガー、スケジュール、HTTP）の構成を正確に移す必要がある。シークレットが旧プロジェクトのSecret Managerにしかなければ、移行先で再設定が必要だ。
関数がスケジュールトリガーで動いている場合、本連載のCron回（#42）と同じく、移管時に起動を忘れると定期処理が静かに止まる。関数の一覧、トリガー、依存シークレットを台帳化し、移行後に各関数が正しく起動・実行されることを検証する必要がある。
4-2. セキュリティルール・RLSポリシーの移行
FirestoreやStorageのセキュリティルール、SupabaseのRLSポリシーは、データへのアクセス制御を担う重要な設定だ。これらが正しく移行されないと、データが過剰に公開される（セキュリティ事故）か、逆に正当なアクセスが拒否される（機能停止）。どちらも深刻だ。
セキュリティルールはコードとして管理されていることが多いが、コンソールで直接編集された差分がある場合は注意が必要だ。移行前後でルールの差分を検証し、アクセス制御の挙動が変わっていないことを確認する。データの公開範囲が変わる事故は、移管直後に最も起きやすいセキュリティインシデントの一つだ。
5. ロックイン度の違いとバリュエーション
5-1. Firebaseの専有性とSupabaseのポータビリティ
FirebaseとSupabaseは、ロックインの度合いが異なる。Firestoreは独自のNoSQLデータモデルで、他のDBへの移行は再設計を伴う。Firebase固有のサービス（Remote Config、A/Bテスト、Dynamic Links後継機能等）に依存していれば、脱出はさらに難しい。Firebaseは利便性が高い分、専有性も高い。
一方Supabaseは、中核がPostgreSQLであり、標準的なDBダンプで移行でき、プラットフォーム自体もオープンソースでセルフホスト可能だ。これは「最悪でも自前で動かせる」という脱出経路を意味し、ロックインリスクを大きく下げる。同じBaaSでも、ポータビリティの差はバリュエーションの差として評価に反映される。
5-2. 移管可能性とチェックリスト
バリュエーションでは、①プロジェクトのクリーンな分離、②課金主体の移管可能性、③サービスアカウント/IAMの健全性、④クライアント設定変更の要否とアプリ再リリースの負担、⑤認証ユーザー移行の難易度、⑥関数とセキュリティルールの引き継ぎ可能性、⑦プラットフォームのロックイン度（Firebase vs Supabase）、を評価する。
買い手はこれらを技術DDで確認し、移管工数と脱出困難性を価格に反映する。売り手は、プロジェクトを事業単位でクリーンに分離し、サービスアカウントを棚卸しし、設定とルールをコード管理し、課金主体を整理して、移管の容易さを実証する。「オーナー権限を移すだけで引き継げる状態」に近づけておくことが、BaaS事業のバリュエーションを守る。
結論：集約された便利さは、移管時に集約されたリスクになる
FirebaseやSupabaseは、バックエンドを一つのプロジェクトに集約することで、少人数でも高度なサービスを運営可能にする。しかしその集約は、移管時には事業全体に及ぶリスクへと反転する。課金の下層、サービスアカウントの権限、クライアントに焼き込まれた設定、認証ユーザー、関数とセキュリティルール ── これらは「オーナー権限の移管」という一行の裏に隠れ、一つでも取りこぼせば事業の一部が止まる。
BaaSプロジェクトの移管は、表層のコンソール権限から下層の課金・IAM・サービスアカウントまで、所有のすべてのレイヤーを引き継ぐ作業だ。売り手にとってはプロジェクトの分離とポータビリティが事業価値を守り、買い手にとっては移管工数とロックイン度が買収リスクの実像を映す。技術的DDの本質は、「便利に集約された」事業基盤を、確実に引き継げる単位に分解して検証することにある。BaaSは、その集約と移管可能性のトレードオフが最も鮮明に現れる領域だ。
