Firebase Firestore — NoSQLドキュメントとコレクションの概要

Firebase Firestoreとは

Firebase Firestoreは、Googleが2019年にRealtime Databaseの後継としてローンチしたクラウドNoSQLデータベースです。FirestoreはGoogle Cloud SpannerとGoogle Cloud Datastoreのインフラストラクチャ上に構築されており、単一トランザクション内での強力なデータ整合性と自動マルチリージョンレプリケーションを提供します。SDKはAndroid、iOS、Web（JavaScript）、Flutter、Kotlin Multiplatform、Unityをサポートしています。

Realtime Databaseからの進化

FirestoreはGoogle I/O 2017で“Cloud Firestore”として発表されました。これは、複雑なクエリサポートの欠如、複数ノードにわたるデータスケーリングの不能、弱い整合性など、Realtime Databaseの主要な制限に対処するソリューションです。Google（2026）によると、Firestoreは1日あたり1兆以上のリクエストを処理し、新しいFirebaseプロジェクトの80%でデフォルトのデータベースとして使用されています。ただし、Realtime DatabaseはそのシンプルなJSON構造により、超低遅延シナリオ（ゲーム、共同編集）において依然として重要です。

Firestoreの無料枠

Firestoreは、Sparkプランで generous な無料枠を備えた従量課金モデルで提供されています：ストレージ1GB、月間ネットワークトラフィック10GB、1日あたり5万回の読み取りオペレーション、2万回の書き込みオペレーション、2万回の削除オペレーション。Blazeプランでは上記すべてが無料で、超過分は課金されます：読み取り10万回あたり0.06ドル、書き込み10万回あたり0.18ドル。Google（2026）によると、90%のプロジェクトが無料枠内に収まっています。

データモデル：コレクション、ドキュメント、フィールド

Firestoreのデータモデルは階層的に編成されています：ルートにはコレクションが含まれ、各コレクションにはドキュメントが含まれ、各ドキュメントにはフィールド（プリミティブ型、配列、Map）とネストされたコレクション（サブコレクション）が含まれます。コレクションのネストの深さは無制限ですが、ドキュメントは別のドキュメントを直接含むことはできません。参照（Reference型）を介してのみ可能です。

コレクションとドキュメント

コレクションは、自動生成またはユーザー定義の識別子を持つドキュメントのコンテナです。各ドキュメントは最大1 MiBのJSONライクなオブジェクトです。ドキュメントのフィールドには、文字列、数値、ブール値、配列、Map、タイムスタンプ（Timestamp）、地理ポイント（GeoPoint）、他のドキュメントへの参照（Reference）を使用できます。ドキュメントサイズはすべてのフィールド名を含めて1 MiBに制限されています。

バッチ書き込みとトランザクション

Firestoreはデータベースレベルでのアトミックトランザクションをサポートしています。トランザクションは複数のドキュメントの読み取りと書き込みが可能で、Commitはすべての変更をアトミックに適用するか、まったく適用しません。トランザクションあたり最大500オペレーション、タイムアウトは60秒です。バッチ書き込みは、読み取りフェーズのない非トランザクションのアトミック書き込みオペレーションです。トランザクションは、金融取引、座席予約、在庫管理にとって重要です。

FirestoreとRealtime Databaseの比較

FirestoreとRealtime Databaseの選択はプロジェクトの要件によって異なります。両方のデータベースはFirebaseエコシステムの一部であり、リアルタイム同期を提供し、すべてのプラットフォームで利用可能ですが、データモデル、スケーリング、価格設定において根本的に異なります。

主な違い

Realtime Databaseはデータを単一のJSONツリーに保存します。これはシンプルな構造には便利ですが、3レベルを超えるネストではスケーリングが困難になります。Firestoreは自動シャーディングを備えたコレクション-ドキュメントモデルを使用し、パフォーマンスの低下なしに数百万のドキュメントにスケーリングできます。Google（2026）によると、Firestoreは速度低下なしに単一コレクションに最大1万の同時接続をサポートし、Realtime Databaseは単一インスタンスに最大20万の接続をサポートします。

価格設定

Realtime Databaseは転送データ量（ダウンロードされたバイト数）と同時接続数に基づいて課金されます。Firestoreはオペレーション数（読み取り、書き込み、削除）に基づいて課金されます。頻繁な小規模更新があるアプリケーション（チャット、通知）の場合、Firestoreの方が一般的にコスト効率が高く、各書き込みオペレーションはデータサイズに関係なく固定価格です。大容量データの読み取りが稀なアプリケーションの場合、Realtime Databaseの方が安価な場合があります。

Googleの推奨（2026）：新しいプロジェクトのデフォルトデータベースとしてFirestoreを使用し、最小レイテンシ（50 ms未満）とフラットなデータ構造が重要なゲームやアプリケーションにはRealtime Databaseを使用してください。両方のデータベースを同じプロジェクトで同時に使用できます。

Firestoreのクエリ、インデックス、ページネーション

Firestoreクエリは、フィルタリング、並べ替え、制限を指定してコレクションまたはコレクショングループに対して実行されます。各クエリがクライアントサイドフィルタリングでJSONツリー全体をトラバースするRealtime Databaseとは異なり、Firestoreは事前に作成されたインデックスを使用してサーバー上ですべてのクエリを実行します。これにより、クエリの複雑さはコレクションサイズではなく結果サイズのみに依存することが保証されます。

クエリの種類

Firestoreは1つまたは複数のフィールドによるフィルタリング（等価、範囲、in、array-contains、array-contains-any）、昇順・降順の並べ替え、制限、ページネーションのためのカーソルをサポートしています。制限：異なるフィールドでのフィルタリングを含む複合クエリ（where price > 10 AND where category == “books”）には複合インデックスが必要です。ORクエリは禁止されています（代わりにinとarray-contains-anyを使用）。異なるフィールドでの不等号クエリは許可されていません。

data class Product(
    val name: String = "",
    val category: String = "",
    val price: Double = 0.0,
    val inStock: Boolean = false
)

suspend fun FirestoreRepository.queryProducts(): List<Product> {
    return firestore
        .collection("products")
        .whereEqualTo("category", "electronics")
        .whereGreaterThanOrEqualTo("price", 100.0)
        .whereLessThan("price", 500.0)
        .orderBy("price")
        .limit(20)
        .get()
        .await()
        .toObjects(Product::class.java)
}

自動インデックスと複合インデックス

Firestoreは単一フィールドのインデックスを自動的に作成します。単一フィールドクエリは設定なしで機能します。2つ以上のフィールドを含むクエリ（フィルタリング＋並べ替え）には複合インデックスが必要です。クエリが最初に送信されると、Firestoreはコンソールへのリンク付きのエラーを返し、ワンクリックでインデックスを作成できます。データベースあたり最大200の複合インデックス。インデックスはFirebase CLIを介してエクスポートおよびインポートできます。

AndroidへのFirestore統合

AndroidアプリへのFirestoreの接続は、Firebase BOMを介して標準的に行われます。firebase-firestore-ktx依存関係を追加した後、FirebaseFirestoreオブジェクトはgetInstance()を介して利用可能になり、追加のキーやトークンは必要ありません。Firestoreは他のサービスと同じFirebaseプロジェクトを使用します。

dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-firestore-ktx")
}

// 初期化
val db = FirebaseFirestore.getInstance()

データの読み取りと書き込み

Firestoreは2つの読み取りモードを提供します：1回限り（get）とリアルタイム（addSnapshotListener）です。1回限りの読み取りはドキュメントを1回取得し、設定や構成に便利です。リスナーは変更をサブスクライブし、ドキュメントの更新は自動的にすべての接続クライアントにリアルタイムで配信されます。set()はドキュメントを作成または上書きし、update()はドキュメント全体を上書きせずに指定されたフィールドのみを変更します。

Google（2026）によると、リアルタイムFirestoreを使用する中規模アプリケーション（10万DAU）は、月間約5〜10GBの送信トラフィックを消費します。オフラインキャッシュ（Persistence Cache）を使用すると、接続が復元されたときにSDKが変更されたドキュメントのみをロードするため、繰り返しダウンロードが60〜70%削減されます。

オフラインモード

Persistence Cacheは、インターネットアクセスなしで動作するためのFirestoreの組み込みメカニズムです。SDKは読み取られたすべてのドキュメントをデバイスに自動的にキャッシュします（Androidでは最大500 MiB）。接続が失われると、読み取りはキャッシュから続行され、書き込みはキューに入れられます。接続が復元されると、すべての未処理オペレーションがサーバーに送信され、キャッシュがサーバーと同期されます。競合制御には、snapshot-metadata.hasPendingWritesとsetOptions(ServerTimestampBehavior)を使用します。

セキュリティルールとデータ検証

Security Rulesは、各読み取りまたは書き込みオペレーションの前にGoogleのサーバーで実行されるFirestoreの宣言型アクセス制御言語です。Rulesはサーバーサイドコードを必要とせず、FirebaseコンソールまたはFirebase CLIを介して記述され、Gitを介してバージョン管理されます。各オペレーションはルールに対してチェックされ、違反があるとPERMISSION_DENIEDエラーが返されます。

ルールの構造

Firestore Security Rulesは、matchブロックとallow式で構成されています。matchはコレクションまたはドキュメントへのパスを定義し、allowは許可されるオペレーション（read、write、create、update、delete）と条件（ブール値を返すJavaScriptライクな式）を指定します。ルールは認証（request.auth）、リクエストデータ（request.resource.data）、既存データ（resource.data）、時間（request.time）、パス（request.path）をチェックできます。

rules_version = '2';

service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read: if request.auth != null;
      allow write: if request.auth.uid == userId;
    }

    match /products/{productId} {
      allow read: if true;
      allow create: if request.auth.token.role == "admin";
      allow update: if resource.data.authorId == request.auth.uid;
    }
  }
}

データ検証

Security Rulesはサーバー側での型と値の検証をサポートしています。価格が負の場合や名前が空の場合に書き込みを禁止できます。すべてのチェックは書き込み前にGoogleのサーバーで実行され、クライアント（Android、iOS、Web、Admin SDK）に関係なくデータの整合性が保証されます。Rulesは悪意のあるAdmin SDKからは保護されません。Admin SDKは設計上ルールをバイパスするためです。完全な保護には、Transaction FunctionsとFirebase Extensionsを使用してください。