Firebase Data Connectとは｜SQL Connect改称とCloud SQL＋GraphQLの実装判断【2026年8月時点】

Firebase Data Connectは、GraphQLで書いたスキーマからCloud SQL for PostgreSQLのテーブルと型安全なクライアントSDKを生成する、Firebaseのリレーショナルデータベースサービスです。2026年に入って製品名がFirebase SQL Connectへ変わり、リアルタイム更新・オフラインキャッシュ・生SQLの記述が一般提供として加わりました。本記事では、サービス・スキーマ・コネクタという3構成の仕組み、既定がNO_ACCESSに落ちる@authの権限設計、100万操作0.9ドルという課金の数え方、Cloud Firestoreとどちらを選ぶかの判断基準までを整理します。名称・提供段階・数値は2026年8月時点の公式ドキュメントおよびFirebaseブログの記載です。

まとめ：改称後のSQL Connectを採用する条件と見送る場面

結論から示します。Data Connectの正体は、Cloud SQL for PostgreSQLの前に立つGraphQLゲートウェイとコード生成器です。データベースそのものは普通のPostgreSQLで、Firebaseが引き受けるのはスキーマからのテーブル生成、サーバーエンドポイントの用意、そして4系統への型安全SDK生成にあたります。

2026年の変化は名称だけではありません。Firebaseブログが2026年4月29日にFirebase SQL Connectへの改称を告知し、同時に@refreshによるリアルタイム更新、SDK側のオフラインキャッシュ、.gqlへの生SQL記述の3つが一般提供になりました。既存APIは変更されていないため、稼働中の実装を動かしたまま新機能だけを足せます。

採用の可否は、データの形と運用体制で切り分けられます。テーブル間の結合と外部キー制約が要件に入り、かつモバイルアプリからバックエンドを書かずに直接つなぎたいなら第一候補。逆に、リレーショナル要件が薄く階層データの同期が主用途ならドキュメント型のCloud Firestoreのほうが素直に組めますし、既にサーバーサイドのAPI層を持つ組織にとってはGraphQL層が二重になるだけの構成になります。

GraphQLスキーマからCloud SQLのテーブルと型安全SDKを生成する仕組み

まず押さえたいのは、Data Connectが「データベース製品」ではなく「データベースへの接続層」だという点です。ここを取り違えると課金構造も権限設計も読み違えます。

サービス・スキーマ・コネクタの3構成とPostgreSQLテーブル生成

構成要素は3つに整理されています。サービスがFirebaseプロジェクト上のデプロイ単位、スキーマがGraphQLで書くデータモデル、コネクタがクライアントに公開するクエリとミューテーションの集合です。スキーマに定義したGraphQLの型は、そのままCloud SQL for PostgreSQLのテーブルへ変換されます。

コネクタの粒度が設計上の勘所になります。コネクタは「誰がどのデータに何をできるか」を定める境界で、アプリ単位やユーザーロール単位で分けて持たせられる仕組みです。管理画面用と一般ユーザー用でコネクタを分けておけば、一般ユーザー向けSDKにはそもそも管理系のミューテーションが生成されず、露出面そのものが小さくなります。土台となるインスタンスの仕様やエディション選定はCloud SQLのマネージドRDBとしての仕組みに整理してあります。

型安全SDKが生成される4プラットフォームとfirebase initの手順

クライアント側の実装は、生成されたSDKを呼ぶだけの形です。対応はKotlin Android、iOS、Flutter、Webの4系統。クエリ名がそのまま関数名になり、引数と戻り値に型が付くため、フィールド名のタイプミスはビルド時に落ちます。

導入の流れはFirebase CLIに寄せられています。firebase init dataconnect でサービスとローカルのディレクトリ構成を作り、firebase init dataconnect:sdk でSDK生成の設定を追加、本番反映は firebase deploy --only dataconnect。改称後もCLIのコマンド名は dataconnect のまま据え置かれているため、既存のCIスクリプトを書き換える必要はありません。CLIの認証やプロジェクト切り替えはFirebase CLIの認証とデプロイ運用で扱いました。GraphQLの型定義からフロントエンド用のコードを起こす一般的な手法との差は、GraphQL Code Generatorのclient preset設定と並べるとつかみやすくなります。

dataconnect.yamlとconnector.yamlが分ける接続先と操作定義

設定ファイルは役割で分かれています。前者がサービス全体、後者がクライアントへ渡す操作群です。

この分割が効くのは環境を増やしたときです。接続先のインスタンスやリージョンはサービス側に閉じているため、検証環境と本番で操作定義を共有したまま接続先だけを差し替えられます。

Data ConnectからSQL Connectへ改称した経緯と2026年の追加機能

この製品は名前と機能の両方が動いています。日本語の解説記事の多くは2025年時点の姿を書いており、現在の前提と噛み合いません。

2024年の公開から2025年4月GA・2026年4月改称までの経緯

時系列を押さえておくと、情報の鮮度を判断しやすくなります。2024年5月のGoogle I/Oで発表、同年10月に公開プレビュー、2025年4月に一般提供という順序で段階を上げてきました。その後2026年に入って製品名がFirebase SQL Connectへ変わり、Firebaseブログの告知は2026年4月29日付です。

移行作業は不要とされています。告知では既存APIに変更が無く、稼働中の連携はそのまま動くと明記されました。実務上の影響はドキュメントのURLに出ます。公式ドキュメントは docs/sql-connect 側へ移り、旧パスの一部は404を返す状態です。社内Wikiやコードコメントに旧URLを直書きしているなら、この機会に貼り替えておいてください。

@refreshディレクティブで購読するリアルタイム更新の実装

リレーショナルDBを土台にしながら、結果の自動更新を持てるようになりました。操作ファイル側に @refresh ディレクティブを書くと、クエリの結果が変わったときにクライアントへ更新が押し出されます。一般提供の機能です。

更新のきっかけは2通りです。時間間隔で定期的に取り直す指定と、特定のミューテーション実行に紐づけて取り直す指定があり、後者はCEL式で条件を書けます。Firestoreのリスナーと違ってPostgreSQLの結合済みビューをそのまま購読できる点が実装上の差分。ただし更新のたびに操作回数を消費するため、短い間隔を全画面に敷くと後述の課金がそのまま増えます。在庫表示のように「数秒の遅れが許容できないビュー」に限って指定する使い方が現実的です。

.gqlへ生SQLを書く記法とオフラインキャッシュのmaxAge設定

GraphQLで表現しきれない処理は、生のSQLで書けます。操作ファイルの中に直接SQL文を記述する方式で、ウィンドウ関数、PostGISによる地理空間インデックス、複数行にまたがる原子的な更新といったPostgreSQL固有の機能へ手が届きます。GraphQL側の抽象で詰まったときの逃げ道が製品内に用意されている点は、この種のサービスとしては珍しい設計です。

オフラインキャッシュはSDKに組み込まれました。設定は connector.yaml に置き、maxAge で保持期間、maxSize で上限サイズ、storage で保存先の種別を指定します。クエリ単位とエンティティ単位の2粒度があり、同じ実体を参照する別々のクエリでキャッシュを共有できる構造。なおCloud Functions for Firebaseを裏に置いて外部APIを混ぜるカスタムリゾルバは2026年8月時点で実験的な位置づけとされており、本番の主要導線に据えるのは早い段階です。

既定がNO_ACCESSになる@authの5段階とApp Checkの併用

クライアントがデータベースへ直接つながる構成である以上、権限設計が実装の中心です。Firebaseの他プロダクトのセキュリティルールとは書き方が違います。

PUBLICからNO_ACCESSまでの5段階と指定漏れ時の既定挙動

クエリとミューテーションには @auth ディレクティブでアクセス水準を付けます。用意されている段階は5つです。

設計上ありがたいのが既定の向きです。コネクタ内のクエリとミューテーションは @auth を書かなければNO_ACCESSに落ち、クライアントからは呼べません。書き忘れが「全開放」ではなく「全閉塞」へ倒れる仕様のため、権限の付け漏れは公開事故ではなく動作不良として現れます。開発中に呼び出しが弾かれたら、まずディレクティブの有無を疑うのが早道です。

CEL式とwhereフィルタで書く所有者限定アクセスの権限設計

5段階だけでは「自分のデータだけ読める」を表現できません。そこで @auth にはCEL式を渡す引数と、行を絞るwhereフィルタが用意されています。サーバー側で評価されるため、クライアントの改変では回避できない構造です。

典型的な形は、認証トークンのUIDとレコードの所有者カラムを突き合わせる条件になります。ユーザーごとの注文履歴なら、USER水準に加えて所有者一致のフィルタを重ねる。管理者判定が要るならカスタムクレームをCEL式で参照する。この2段構えなら、アプリ側のコードに権限判定を書かずに済みます。見落としやすいのは、生SQLで書いた操作にも同じディレクティブが要る点です。SQLへ逃がした処理だけ権限が緩い状態を作らないよう、レビュー時は操作ファイル単位で @auth の網羅を確認してください。

App Checkの端末証明とAdmin SDKによる特権操作の切り分け

認証は「誰か」を確かめる仕組みで、「正規のアプリからの呼び出しか」は別問題です。ここを埋めるのがApp Checkによる端末証明で、Data Connectのエンドポイントにも適用できます。正規ユーザーが改造クライアントやスクリプトから大量に呼ぶ経路を塞ぐ層と考えてください。プロバイダの選び方や監視モードから強制へ切り替える段取りはFirebase App Checkのプロバイダ選定と強制移行の解説にまとめています。

サーバー側からの操作は経路自体を分けます。バッチ処理や管理業務のようにNO_ACCESS水準の操作を実行したい場合は、特権環境からAdmin SDKで呼ぶ形。クライアント向けコネクタに管理用のミューテーションを混ぜてCEL式で守る書き方より、コネクタごと分離してAdmin SDK経由に寄せるほうが事故が起きにくくなります。ローカルでのルール検証はFirebase Local Emulator Suiteによる再現環境で回せます。

100万操作0.9ドルで積み上がる課金構造とCloud SQL側の実費

費用は2階建てで発生します。Data Connect層の操作課金と、その下で動くCloud SQLインスタンスの実費。見積もりで漏れるのは後者です。

250,000操作の無料枠と100万操作0.9ドルという数え方

Blazeプランでは毎月250,000操作までが無料で、超過分は100万操作あたり0.9ドル。2026年5月1日から適用された単価です。ここで効いてくるのが「操作」の定義になります。

1操作は、複数テーブルにまたがる結合クエリでも、複数行をまとめて更新するミューテーションでも1回として数えられます。読み取った行数では数えません。この数え方は、正規化したテーブルを結合して一覧を引く用途で有利に働きます。読み取り回数で課金されるCloud Firestoreなら複数回の読み取りが積み上がる場面でも、こちらは1操作で済むためです。1件ずつ引く実装をループで回すと操作回数がそのまま伸びるので、まとめて取る設計に寄せる価値が費用面にも出ます。

Sparkの90日無償枠とBlazeの3か月トライアルの適用条件

無償で試せる枠が2系統あります。条件が細かいため、検証計画を立てる前に確認しておく箇所です。

Spark側はインスタンスが1つに限られ、設定変更もできません。Blaze側の3か月トライアルはdb-f1-micro相当（1 vCPU、ストレージ10GB、メモリ約629MB）で、請求アカウントあたり5回まで使えます。落とし穴は解除条件です。インスタンスの構成を1か所でも変更した時点で無償枠を抜けて課金が始まるため、「トライアル中にメモリだけ上げて負荷試験」という進め方は成立しません。性能検証まで見込むなら、最初から課金前提で構成を組んでください。

月9.37ドルから始まるCloud SQL実費と請求が跳ねる条件

トライアル終了後に効いてくるのがインスタンス代です。Cloud SQLの基本料金は月9.37ドルからで、リージョンと構成によって上下します。操作課金が0.9ドル毎100万というスケールなので、小〜中規模のアプリでは請求の大半がインスタンス側に寄る構造です。

費用が跳ねる条件は3つに絞れます。第一に高可用性構成で、レプリカを持てばインスタンス代がおおむね倍。第二にストレージの自動拡張で、削除してもプロビジョニング済み容量は縮まりません。第三に@refreshの短い間隔で、画面数×同時接続数×毎分の更新回数がそのまま操作数に乗ります。Firestoreや関数と併用するプロジェクト全体の単価合算と予算アラートの設定は、Firebaseの料金と無料枠・Blaze超過単価の実額にまとめました。

Cloud Firestoreとの使い分けとData Connectを見送る判断条件

ここは中立に並べず判断を言い切ります。Data Connectは「Firebaseの新しいDB」ではなく、リレーショナル要件を持つアプリに向けた接続層です。用途が合わなければ構成が1段増えるだけになります。

リレーショナル要件から引く選定基準とFirestoreに残す領域

選定の分岐は、データに結合と制約が要るかどうかで引けます。受注と明細、社員と部署、予約と設備のように、実体どうしの関係を外部キーで守りたいならPostgreSQLが素直です。集計クエリやウィンドウ関数を要する管理画面も同じ側に来ます。

一方で、Firestoreに残したほうがよい領域も明確です。プレゼンス表示やチャットのように階層データを高頻度で同期する処理、そしてスキーマが定まらないうちに作り始めるプロトタイプ。両方を同一プロジェクトで併用できるため、業務データをData Connect、リアルタイム性が要る周辺機能をFirestoreへ寄せる分担が現実的な着地になります。判断が付かないなら、テーブル設計図を1枚書いて外部キーの矢印が3本以上引かれるかを目安にしてください。

Hasura・AWS AppSyncと比べたときの採用条件と見送るべき場面

DBの前にGraphQL層を置く発想自体は珍しくありません。GraphQL APIをマネージドで提供するAWS AppSyncや、既存DBからAPIを自動生成するOSSにも同じ狙いがあります。Data Connectの差分は、クライアントSDKの生成とFirebase Authentication・App Checkとの結合がひとつながりになっている点に集約されます。

採用してよいのは次の条件が揃う場合です。モバイルまたはWebのアプリが主戦場で、Firebase Authenticationを使っているか使う予定がある。データにリレーショナル要件がある。そしてバックエンドAPIの専任を置かない小〜中規模のチーム。認証・権限・SDK・DBの4点が1つの設定体系に収まる効果が、そのまま実装工数へ効きます。

逆に、見送るべき場面を挙げます。既に自社でREST APIやBFF層を運用しているなら、GraphQL層が二重になり権限の実装箇所が分散します。サーバー間連携が主でモバイルクライアントを持たないシステムも対象外で、Cloud SQLへ直接つなぐほうが構成が短い。他クラウドへの移行可能性を残したい案件も、コネクタ定義とSDK生成がFirebaseに依存するため慎重に判断してください。Cloud SQLを含むGoogle Cloud上のバックエンド構成を外部と詰めたい場合は、Google Cloudを含むインフラ構築と受託開発から相談できます。

よくある質問

Data Connectの採用を検討する実装者から挙がりやすい質問をまとめます。

Firebase Data ConnectとFirebase SQL Connectは別物ですか？

同じ製品です。2026年4月29日付のFirebaseブログで、Firebase Data ConnectがFirebase SQL Connectへ名称変更されたことが告知されました。既存のAPIは変更されておらず、稼働中の実装はそのまま動きます。CLIのコマンドも firebase deploy --only dataconnect のように旧名称の識別子が残っているため、設定ファイルの書き換えも不要です。実務上の影響は公式ドキュメントのURLが移った点で、旧パスをブックマークやコード内コメントに残している場合は貼り替えが要ります。

Data Connectを使うとCloud SQLの料金は別途かかりますか？

かかります。費用は2階建てで、Data Connect側の操作課金に加えて、その下で動くCloud SQLインスタンスの料金が発生します。インスタンスは月9.37ドルからで、リージョンと構成で変わる仕組み。小規模なアプリでは請求の大半がインスタンス側に寄るため、操作単価だけで見積もると実額から外れます。Blazeプランには3か月のCloud SQL無償トライアルがありますが、構成を変更した時点で課金が始まる点に注意してください。

Firestoreから移行する価値があるのはどんなケースですか？

結合と集計に苦しんでいる場合です。Firestoreで非正規化を重ねた結果、更新時に複数コレクションへ書き戻す処理が増えている、あるいは管理画面の集計をクライアント側やCloud Functionsで組み立てている、という兆候が出ているならリレーショナル側が向きます。逆に、リアルタイム同期とオフライン動作が価値の中心にある機能は移す理由が薄い構成。全面移行ではなく、業務データだけを寄せる部分移行から検討するほうが投資対効果を測りやすくなります。

ローカル環境でData Connectの動作を確認できますか？

ローカル環境での確認が可能です。エミュレータが同梱されており、PostgreSQLを含めた構成をローカルで再現して、スキーマ変更・操作の実行・SDK生成まで課金なしで確認できます。VS Code拡張からエミュレータを起動する導線も用意済みです。初期データは seed_data.gql に書いておけば投入でき、チーム内で同じ状態を共有した状態から検証を始められます。他プロダクトと合わせたローカル再現の全体構成は、Firebase Local Emulator Suiteの記事で扱っています。

GraphQLで書けない複雑な処理はどう実装しますか？

操作ファイルに生のSQLを直接記述できます。ウィンドウ関数を使った順位付け、PostGISによる地理空間インデックスを前提とした近傍検索、複数行をまとめて更新する原子的な処理などが対象で、この記法は一般提供済みです。外部APIとの連携が要る場合はCloud Functions for Firebaseを裏に置くカスタムリゾルバという選択肢もありますが、2026年8月時点では実験的な位置づけのため、提供段階を確認したうえで判断してください。

関連記事

• Cloud SQLとは？GCPのマネージドRDBの仕組み・エディションと採用判断：土台になるインスタンスの仕様と選定です。
• Hasuraとは？DBから即GraphQL APIを生成するOSSとDDNの最新像：既存DBへGraphQL層を被せる代替手段との比較材料です。
• Firebase Local Emulator Suiteとは｜ローカル再現の構成とCI組み込み：スキーマと権限をローカルで検証する手順です。
• Firebaseの導入手順｜プロジェクト作成からSDK導入と初回デプロイまで：SDK導入までの前段の流れです。
• Firebaseの料金｜無料枠とBlaze超過単価の実額：プロジェクト横断で単価を合算する際の参照先です。