【Google Cloud目線】Firebase を GCP に紐づける手順。
最初にやっておくべきこと

1. 最初のページ：Firebase コンソールで「プロジェクトを作成」

Firebase コンソールにログインすると、「始める」のところに「新しい Firebase プロジェクトを作成」が出ます。ここをクリックしてプロジェクト作成を始めます。

2. プロジェクト名の画面で、下のリンクをクリック

次に「まずプロジェクトに名前を付けましょう」とプロジェクト名を入力する画面になります。ここでいったん名前を入れずに、画面の下にある「すでに Google Cloud プロジェクトがある場合　Google Cloud プロジェクトに Firebase を追加」のリンクをクリックします。既存の GCP プロジェクトに Firebase を紐づける流れになります。

3. GCP プロジェクトを選択して、データベースを紐づける

「まず、Google Cloud プロジェクトの選択から始めましょう。」という画面になります。「Google Cloud プロジェクトを選択する」から、既存の GCP プロジェクトを選び、「続行」で進めます。操作には GCP の Editor または Owner 相当の権限が必要です。これで、その GCP プロジェクトに Firebase（Firestore などのデータベース）が紐づきます。課金・IAM もその GCP プロジェクトに統一されます。注意：一度「Firebase を追加」すると取り消せません（公式 FAQ）。プロジェクトを削除すると Firebase と GCP の両方で削除されます。

4. 紐づけ後の Firebase トップ画面

GCP プロジェクトに Firebase を追加すると、そのプロジェクト用の Firebase コンソールのトップ（プロジェクトの概要）が表示されます。課金プラン（Blaze など）や、Firestore の利用状況がここで確認できます。

5. Firestore Database 画面：複数データベースと「(default)」

左メニューの「Firestore Database」をクリックすると、Cloud Firestore の画面になります。ここに、そのプロジェクト内に作成済みのデータベース一覧が表示されます。

筆者は当初「1プロジェクトに Firestore のデータベースは1つしか作れない」と思っていましたが、1つの Firebase（GCP）プロジェクト内に複数の Firestore データベースを作成できます（複数 DB 機能は 2024 年 GA）。用途の例は、本番／テストの分離、顧客ごとのデータ分離、リージョン指定などです。

データベース名（database ID）の扱いが重要です。

• (default)： 最初に作られるデフォルトのデータベースです。クライアント／サーバーどちらの SDK でも、データベース名を指定しない場合は必ずこの (default) に接続されます。
• 複数 DB を使う場合： 2本目以降は名前を付けて作成します。GCP 上の Cloud Run や Cloud Functions、あるいは Firebase クライアントからアクセスするときは、どのデータベースを使うかを database ID で指定する必要があります。
• Cloud Run などで名前を指定しない場合： Firebase Admin SDK（Python の firebase_admin.firestore.client(database_id=None) など）やクライアント SDK で database ID を渡さないと、自動的に (default) データベースにアクセスします。そのため、複数 DB を使い分ける場合は、初期化時に database ID を明示的に指定してください。

まとめると、「データベース名を指定しなければ (default) が使われる」ので、複数 DB を用意するときは名前を付けておき、GCP やアプリからアクセスする際にその名前を指定する、と覚えておくとよいです。

6. 無料枠と複数DB：動作が変わるの？

読み書きの API や挙動は変わりません。変わるのは「どのデータベースに無料枠が適用されるか」と「課金の有無」だけです。

公式のCloud Firestore の料金によると、次のとおりです。

• 無料枠が適用されるのは「プロジェクトあたり1つのデータベースだけ」です。しかも「最初に作成した1つ」（database ID が (default) かどうかは問わない）が無料枠の対象になります。その DB を削除すると、次に作成した DB が無料枠の対象になります。
• 無料枠の内容（その1つの DB に対して）：保存 1 GiB、ドキュメント読み取り 5万回/日、書き込み 2万回/日、削除 2万回/日、送信データ 10 GiB/月。リセットは太平洋時間の深夜頃です。
• 2本目以降のデータベースを作るには、プロジェクトで課金（Blaze プラン）を有効にする必要があります。DB の作成・削除自体に追加料金はかかりませんが、2本目以降の DB への読み書き・保存は無料枠の対象外で、使用量に応じて従量課金されます。

つまり、1本目だけ無料枠が効き、2本目以降は最初から課金対象です。SDK で database ID を指定するかどうかで「どの DB に接続するか」は変わりますが、同じ Firestore の API で読み書きする点は同じです。無料枠を気にする場合は、無料枠の対象になる「最初の1つ」の DB だけを使うか、2本目以降を使うなら Blaze で課金する前提で利用量を把握しておくとよいです。

7. 作成したデータベースの管理画面：データ・ルール・インデックス

特定のデータベース（例：view-tracker）を開くと、タブで「データ」「ルール」「インデックス」などを切り替えて管理できます。

データタブ： コレクションとドキュメントがツリー表示され、この UI から直接ドキュメントの追加・編集・削除ができます。開発中の確認や少量データの手入れに便利です。

ルール（セキュリティルール）： 「誰がどのドキュメントを読める・書けるか」を制御します。match でパスを指定し、allow read, write: if 条件 で許可条件を書くホワイトリスト形式です。条件には request.auth（認証ユーザー）、resource.data（既存ドキュメントの内容）、request.resource（書き込み後の内容）などが使えます。認証済みユーザーのみ許可・「自分の uid のドキュメントだけ」といったパターンが一般的です。なお、Cloud Run や Cloud Functions などサーバー側の Admin SDK はルールをバイパスするため、その場合は GCP の IAM で権限を管理します。

インデックス： クエリのパフォーマンスと「実行できるクエリ」を左右します。単一フィールドのインデックスは自動で作成・維持されます。一方、複数フィールドを組み合わせたクエリ（例：あるフィールドで等号・別フィールドで範囲・さらに別フィールドで並び替え）には複合インデックスが必須で、コンソールの「インデックス」タブから手動で作成するか、firestore.indexes.json を Firebase CLI でデプロイして管理します。複合インデックスがないと該当クエリはエラーまたは遅延するため、本番前に用意しておく必要があります。

GCP 内の他サービスやネット経由でのアクセスと App Check： このデータベースには、GCP 内の Cloud Run や Cloud Functions からコードでアクセスしたり、Web アプリ・モバイルアプリからネット経由で連携したりする使い方があります。その際のセキュリティ対策の一つが App Check です。左メニューにも「App Check」があり、有効にすると未承認のクライアントからのリクエストを弾き、不正利用・不正課金のリスクを下げられます。設定や証明書プロバイダの詳細はここでは割愛しますが、外部公開する API やクライアントから Firestore に触れる場合は導入を検討するとよいです。

公式では「Firebase プロジェクトは Google Cloud プロジェクト」「既存の Google Cloud プロジェクトで Firebase を使う」と説明されています。既存の GCP がある場合は、上記の手順で最初から紐づけておくのがおすすめです。