BigQuery Graphが正式提供、GQL利用には上位エディションが必要

Google Cloudは2026年9月1日、BigQueryでデータ間の関係を分析するBigQuery Graphの一般提供を開始した。同日付の XcademiaのGA報道 も、GQLによる探索をBigQuery内で実行し、別のグラフデータベースへデータを移さずに関係をたどれるようになったと伝えている。

使い方の要点は、既存のBigQueryテーブルやビューをノードとエッジに割り当ててプロパティグラフを定義し、目的に応じてGQLかGRAPH_EXPANDとSQLを選ぶことだ。2026年9月1日更新の BigQuery Graph公式概要 によると、元データの複製は不要だが、GQLクエリにはEnterpriseまたはEnterprise Plusエディションの予約が必要で、オンデマンド料金ではGRAPH_EXPANDを使ってSQLから問い合わせる。

一般提供の対象と段階展開中の機能を分ける

一般提供になった中核は、BigQuery内のデータをプロパティグラフとしてモデル化し、標準GQLとSQLを組み合わせて関係を探索する機能だ。口座と取引、顧客と商品、部品と仕入れ先のような実体をノード、送金や購入、供給などの結び付きをエッジとして表せば、複数の関係をまたぐ経路や特定のパターンを検索できる。

Google Cloudの9月1日発表 は、BigQuery GraphのGAと同時に、GA済み、プレビュー中、今後数週間で展開する機能が混在していると明記している。データセットやER図からノードとエッジを提案し、元データとの対応率を検証しながらグラフを構築するエージェント機能は近日展開とされており、関連機能のすべてが正式提供されたわけではない。

今回のGAで実務上重要なのは、グラフ分析のためにデータを別基盤へ抽出する構成が必須ではなくなったことだ。BigQuery上の行レベル・列レベルのアクセス制御を利用しながら、グラフ探索と既存のリレーショナル分析を同じ環境に置けるため、データの転送、同期、重複した権限管理を増やさずに済む。

既存テーブルからプロパティグラフを定義する

作成時には、保存済みのデータを書き換えるのではなく、どのテーブルまたはビューが実体を表し、どのテーブルまたはビューが実体同士の関係を表すかを宣言する。CREATE PROPERTY GRAPHまたはCREATE OR REPLACE PROPERTY GRAPHを使い、NODE TABLESに実体、EDGE TABLESに関係を割り当てる。

1. 顧客、商品、口座など、独立して識別する実体のテーブルを選び、各ノードを一意にするKEYを定義する。
2. 購入、送金、接続などの関係を表すテーブルを選び、SOURCE KEYとDESTINATION KEYを対応するノードのキーへ関連付ける。
3. 探索条件や返却結果に必要な列をプロパティとして公開し、ラベルでノードとエッジの役割を区別する。
4. 作成したグラフに対して、経路探索ならGQL、表形式のSQL処理ならGRAPH_EXPANDを含むGoogleSQLを選ぶ。

グラフ定義は元のテーブルやビューを論理的に対応付けるため、グラフ専用の複製データセットや、その複製を更新するETLを前提としない。ただし、キーの一意性や関係の意味まで自動的に正しくなるわけではない。参照先のないキー、重複した関係、分析目的に合わないラベルがあれば、探索結果にもその設計が反映される。

GQLとGRAPH_EXPANDは目的が異なる

GQLはノードとエッジの並びをパターンとして記述し、複数ホップの経路や到達可能な対象を直接探すための問い合わせ言語だ。たとえば顧客から購入商品を経て仕入れ先までたどる処理を、ノードと関係の連続として表現できる。自己結合や再帰処理を重ねるSQLに比べ、探索したい関係をクエリ上で示しやすい。

GRAPH_EXPANDは、プロパティグラフのノードやエッジを表形式へ展開し、その結果をGoogleSQLで処理するテーブル値関数である。既存の集計処理やBI向けの出力へつなぎやすく、オンデマンド料金でも利用できるが、GQLのパターンマッチングをそのまま代替する機能ではない。

• 表形式の抽出や既存SQLとの接続が中心: オンデマンド料金を維持し、GRAPH_EXPANDの結果をGoogleSQLで絞り込み、結合、集計する。
• 固定された少数の関係を調べる: GRAPH_EXPANDと通常のSQLで要件を表現できるかを判断する。
• 可変長の経路や複数ホップのパターンを直接探索する: GQLを選び、EnterpriseまたはEnterprise Plusの予約を用意する。

したがって、SQL中心の既存環境でBigQuery Graphを導入する際の分岐点は、グラフを作るかどうかではなく、どの問い合わせ方式が必要かにある。オンデマンド環境でもプロパティグラフとGRAPH_EXPANDは使える一方、GQLを前提にするワークロードでは予約構成まで設計対象になる。

料金の境界はGQLを実行するかで決まる

GQLクエリの実行には、EnterpriseまたはEnterprise Plusエディションを使う予約が必要となる。Standardエディションの予約だけではこの条件を満たさず、オンデマンド料金もGQLの実行条件には該当しない。GQLによるグラフクエリの計算資源はスロットで測定され、BigQueryの容量ベース料金が適用される。

基礎となるテーブルのストレージ料金は通常のBigQuery料金に従い、同じテーブル上に複数のグラフモデルを定義しても、元データの保存料金がモデル数に応じて重複する仕組みではない。コピー不要という利点はストレージだけでなく、複製データの同期や整合性管理を追加せずに済む点にもあるが、クエリの計算費用や予約容量まで不要になるわけではない。

現時点で確認できる判断基準は明確だ。既存データを複製せずにグラフとして扱うこと自体は可能であり、GRAPH_EXPANDとSQLで足りるならオンデマンド運用を維持できる。GQLで経路やパターンを直接たどる必要がある場合はEnterprise系予約が費用上の入口となり、段階展開中のエージェント機能については提供時期や利用条件の追加情報を待つ必要がある。