BigQuery Graphに入門してみた！

2026年11月12日 11:36

私がBigQuery Graphに注目したワケ

新卒3年目のUです。普段はGoogle Cloud（GCP）環境でデータ分析基盤の構築やBI開発、日々のご要望に応じたデータ抽出などを担当しています。

データ基盤を運用・開発していると、たまに「ユーザーの行動遷移を辿りたい」「レコメンド用に要素同士の繋がりを見たい」といった相談をもらいます。ただ、Graph構造でデータを分析しようとすると、これまでは専用のGraphデータベースを新しく用意したり、既存のDWHからデータをエクスポート・連携するパイプラインを組んだりと、インフラ構築や運用面でのハードルが高くなりがちでした。

そんな中、BigQueryの新機能としてBigQuery Graphが公開されました！
専用のデータベースを準備することなく、普段使っているBigQueryテーブルをそのまま活用し、DWH内で完結して手軽にGraph分析ができるという点に大きな魅力を感じ、早速触ってみました。

今回は「ECサイトの購買履歴データ」を題材に、BigQuery Graphの基本と可能性についてまとめてみます。

BigQuery Graphとは

BigQuery Graphは、2026年4月にプレビューとして提供が開始された、BigQuery上でProperty Graphを扱うための機能です。BigQueryのテーブルを顧客・商品・場所のような「もの」を表すノードと、購入・フォロー・所属のような「ノード同士の関係」を表すエッジに割り当てることでグラフ構造を定義し、GQL（Graph Query Language）を使って関係性をたどる分析や可視化を行えます。

Graphのメリット
従来のテーブル形式（RDB）でもデータの紐付けは可能ですが、「Aを買った人が次にBを買い、さらに…」といった複雑な関係性を追おうとすると、SQLのJOIN（特に自己結合）が多重になりクエリが複雑化しがちです。データをGraph構造化することで、以下のような効果・メリットが得られます。

直感的なクエリ記述：関係性を `(顧客)-[購入]→(商品)` のように線で結ぶイメージでシンプルに記述できる
直感的な可視化：BigQuery Studio上でデータの繋がりがネットワーク図として一目で把握できる
高度なネットワーク分析：不正検知やレコメンド、複雑な依存関係の探索なども容易に行える

今回は「ECサイトの購買履歴データ」を作って実際の挙動を確認していきたいと思います。

今回やること

今回は、「ECサイトの購買履歴データ」を題材にして、顧客と商品をGraphとして扱ってみます。やりたいことは、「ウォーターサーバー本体を買った顧客が、その後30日以内に何を買っているか」をGraphで確認することです。
顧客と商品をノードにして、「購入した」という関係を `PURCHASED` エッジとして表現します。`orders` テーブルには `customer_id`、`product_id`、`ordered_at`、`quantity` があるので、「誰が、いつ、どの商品を、いくつ買ったか」をエッジの情報として持たせられます。以下の図のようなイメージです。

STEP1：サンプルデータを作成する

まずは、以下のようにサンプルデータを作成します。

CREATE OR REPLACE TABLE graph_demo.customers AS
SELECT 'C001' AS customer_id, '佐藤' AS customer_name UNION ALL
SELECT 'C002', '鈴木' UNION ALL
SELECT 'C003', '田中' UNION ALL
SELECT 'C004', '高橋' UNION ALLSELECT 'C005', '伊藤';

CREATE OR REPLACE TABLE graph_demo.products AS
SELECT 'P001' AS product_id, 'ウォーターサーバー本体' AS 
product_name UNION ALLSELECT 'P002', '天然水ボトル' UNION ALL
SELECT 'P003', '替えフィルター' UNION ALL
SELECT 'P004', 'コーヒー豆' UNION ALL
SELECT 'P005', 'インスタント味噌汁' UNION ALL
SELECT 'P006', 'キッチンペーパー' UNION ALL
SELECT 'P007', '卓上加湿器' UNION ALL
SELECT 'P008', '収納ボックス';

CREATE OR REPLACE TABLE graph_demo.orders AS
SELECT 'O001' AS order_id, 'C001' AS customer_id, 'P001' AS 
product_id, TIMESTAMP '2026-01-01 10:00:00' AS ordered_at, 1 AS 
quantity UNION ALL
SELECT 'O002', 'C001', 'P002', TIMESTAMP '2026-01-08 10:00:00', 2 UNION ALL
SELECT 'O003', 'C001', 'P004', TIMESTAMP '2026-01-18 10:00:00', 3 UNION ALL
SELECT 'O004', 'C001', 'P008', TIMESTAMP '2026-02-15 10:00:00', 1 UNION ALL
SELECT 'O005', 'C002', 'P001', TIMESTAMP '2026-01-05 10:00:00', 1 UNION ALL
SELECT 'O006', 'C002', 'P002', TIMESTAMP '2026-01-16 10:00:00', 2 UNION ALL
SELECT 'O007', 'C002', 'P002', TIMESTAMP '2026-01-28 10:00:00', 2 UNION ALL
SELECT 'O008', 'C003', 'P001', TIMESTAMP '2026-01-10 10:00:00', 1 UNION ALL
SELECT 'O009', 'C003', 'P002', TIMESTAMP '2026-01-20 10:00:00', 1 UNION ALL
SELECT 'O010', 'C003', 'P006', TIMESTAMP '2026-01-29 10:00:00', 1 UNION ALL
SELECT 'O011', 'C004', 'P001', TIMESTAMP '2026-01-12 10:00:00', 1 UNION ALL
SELECT 'O012', 'C004', 'P005', TIMESTAMP '2026-01-22 10:00:00', 4 UNION ALL
SELECT 'O013', 'C004', 'P002', TIMESTAMP '2026-02-05 10:00:00', 2 UNION ALL
SELECT 'O014', 'C005', 'P001', TIMESTAMP '2026-01-15 10:00:00', 1 UNION ALL
SELECT 'O015', 'C005', 'P002', TIMESTAMP '2026-01-25 10:00:00', 2 UNION ALL
SELECT 'O016', 'C005', 'P007', TIMESTAMP '2026-02-20 10:00:00', 1;

作成されるデータは以下の通りです。

・graph_demo.customers

$\newcommand{\arraystretch}{1.5} % \begin{array}{|l|l|} \hline \textbf{customer\_id} & \textbf{customer\_name} \\ \hline \text{C001} & \text{佐藤} \\ \hline \text{C002} & \text{鈴木} \\ \hline \text{C003} & \text{田中} \\ \hline \text{C004} & \text{高橋} \\ \hline \text{C005} & \text{伊藤} \\ \hline \end{array}$

・graph_demo.products

$\newcommand{\arraystretch}{1.5} % \begin{array}{|l|l|} \hline \textbf{product\_id} & \textbf{product\_name} \\ \hline \text{P001} & \text{ウォーターサーバー本体} \\ \hline \text{P002} & \text{天然水ボトル} \\ \hline \text{P003} & \text{替えフィルター} \\ \hline \text{P004} & \text{コーヒー豆} \\ \hline \text{P005} & \text{インスタント味噌汁} \\ \hline \text{P006} & \text{キッチンペーパー} \\ \hline \text{P007} & \text{卓上加湿器} \\ \hline \text{P008} & \text{収納ボックス} \\ \hline \end{array}$

・graph_demo.orders

$\newcommand{\arraystretch}{1.5} % \begin{array}{|l|l|l|l|r|} \hline \textbf{order\_id} & \textbf{customer\_id} & \textbf{product\_id} & \textbf{ordered\_at} & \textbf{quantity} \\ \hline \text{O001} & \text{C001} & \text{P001} & \text{2026-01-01 10:00:00} & 1 \\ \hline \text{O002} & \text{C001} & \text{P002} & \text{2026-01-08 10:00:00} & 2 \\ \hline \text{O003} & \text{C001} & \text{P004} & \text{2026-01-18 10:00:00} & 3 \\ \hline \text{O004} & \text{C001} & \text{P008} & \text{2026-02-15 10:00:00} & 1 \\ \hline \text{O005} & \text{C002} & \text{P001} & \text{2026-01-05 10:00:00} & 1 \\ \hline \text{O006} & \text{C002} & \text{P002} & \text{2026-01-16 10:00:00} & 2 \\ \hline \text{O007} & \text{C002} & \text{P002} & \text{2026-01-28 10:00:00} & 2 \\ \hline \text{O008} & \text{C003} & \text{P001} & \text{2026-01-10 10:00:00} & 1 \\ \hline \text{O009} & \text{C003} & \text{P002} & \text{2026-01-20 10:00:00} & 1 \\ \hline \text{O010} & \text{C003} & \text{P006} & \text{2026-01-29 10:00:00} & 1 \\ \hline \text{O011} & \text{C004} & \text{P001} & \text{2026-01-12 10:00:00} & 1 \\ \hline \text{O012} & \text{C004} & \text{P005} & \text{2026-01-22 10:00:00} & 4 \\ \hline \text{O013} & \text{C004} & \text{P002} & \text{2026-02-05 10:00:00} & 2 \\ \hline \text{O014} & \text{C005} & \text{P001} & \text{2026-01-15 10:00:00} & 1 \\ \hline \text{O015} & \text{C005} & \text{P002} & \text{2026-01-25 10:00:00} & 2 \\ \hline \text{O016} & \text{C005} & \text{P007} & \text{2026-02-20 10:00:00} & 1 \\ \hline \end{array}$

STEP2：Graphを作成する

早速ですが、Graphを定義してみます。GQLクエリの全体像は以下のようになります。

CREATE OR REPLACE PROPERTY GRAPH graph_demo.EcommerceGraph
  NODE TABLES (
    graph_demo.customers AS Customers
      KEY (customer_id)
      LABEL Customer
      PROPERTIES (customer_id, customer_name),

    graph_demo.products AS Products
      KEY (product_id)
      LABEL Product
      PROPERTIES (product_id, product_name)
  )
  EDGE TABLES (
    graph_demo.orders AS Purchases
      KEY (order_id)
      SOURCE KEY (customer_id) REFERENCES Customers (customer_id)
      DESTINATION KEY (product_id) REFERENCES Products
 (product_id)
      LABEL PURCHASED
      PROPERTIES (order_id, ordered_at, quantity)
  );

それでは解説していきます。

`NODE TABLES` の解説

`NODE TABLES` では、どのテーブルをノードとして扱うかを定義します。

graph_demo.customers AS Customers
  KEY (customer_id)
  LABEL Customer
  PROPERTIES (customer_id, customer_name)

これは、`customers` テーブルを `Customer` ノードとして扱う、という意味です。`KEY` はノードを一意に識別する列で、`PROPERTIES` にはGraphクエリ内で参照したい列を指定します。
`LABEL Customer` と書くことでラベルを付与できます。それにより、例えば「Customersノードを探索して変数 c に割り当てる」といった指定を`(c:Customer)` のように記述できるようになります。

`EDGE TABLES` の解説

一方、`EDGE TABLES` ではノード同士の関係を定義します。

graph_demo.orders AS Purchases
  KEY (order_id)
  SOURCE KEY (customer_id) REFERENCES Customers (customer_id)
  DESTINATION KEY (product_id) REFERENCES Products (product_id)
  LABEL PURCHASED  PROPERTIES (order_id, ordered_at, quantity)

ここでは、`orders` テーブルの1行を `Customer → Product` のエッジとして定義しています。始点を`SOURCE KEY` で、終点を`DESTINATION KEY` で指定することで、顧客から商品に向かう `PURCHASED `エッジが形成されます。
この定義により、購買履歴を表形式のデータから「顧客と商品を結ぶグラフ構造」として参照できるようになります。

STEP3: Graphの構造を可視化する

Graphが作成できたら、まず構造を確認してみます。

GRAPH graph_demo.EcommerceGraph
MATCH p = (:Customer)-[:PURCHASED]->(:Product)
RETURN
  TO_JSON(p) AS path;

このクエリを実行した直後は、デフォルトで「強制レイアウト」が選択されており、ノードが放射状に広がるため顧客と商品の区分けや関係性の流れが少し把握しづらく感じます。
そこで、顧客ノードと商品ノードが上下の層（階層）にきれいに整理され、データの繋がりが直感的に見やすくなるよう、プルダウンから「順次レイアウト」を選択します。

すると、以下のように表示されます。

顧客が青色の丸、注文がグレーの線、注文した商品が赤色の丸で表現されていることが分かります。

では、中身を確認したときのクエリの解説をします。
`GRAPH` で対象のGraphを指定し、`MATCH` で探したいパターンを書きます。

(:Customer)-[:PURCHASED]->(:Product)

これは、「CustomerノードからProductノードへ向かうPURCHASEDエッジ」を表しています。かなり直感的な書き方だと思います。
また、`p = (...)` と書くことで、この経路全体を `p` というパスとして扱えます。最後に `TO_JSON(p)` を返すと、BigQuery Studio上でGraphとして可視化できます。ただのクエリ結果ではなく、顧客と商品が線でつながった形で見られるため、非常にイメージがつかみやすいです。

STEP4: 顧客の購買傾向をGraphで可視化する

次に、「商品ID`P001`を買った顧客が、その後30日以内に`P001`以外で何を買っているか」を集計してみます。`P001` はウォーターサーバー本体です。

GRAPH graph_demo.EcommerceGraph

MATCH  (target:Product {product_id: "P001"})
    <-[e1:PURCHASED]-(c:Customer),
  p = ((c)
    -[e2:PURCHASED]->(next_product:Product))

WHERE
  next_product.product_id <> target.product_id
  AND e2.ordered_at > e1.ordered_at
  AND e2.ordered_at <= TIMESTAMP_ADD(e1.ordered_at, INTERVAL 30 DAY)

RETURN
  TO_JSON(p) AS path;

このクエリの面白いところは、MATCH句において同じ顧客 `c` を使って2つの購入関係を表現しているところです。

(target:Product {product_id: "P001"})
  <-[e1:PURCHASED]-(c:Customer)

ここでは、`P001` を買った顧客を探しています。`e1` はP001を買ったときの購入エッジです。
次に、P001を購入した顧客`c`がその次に購入した商品を探します

p = ((c)-[e2:PURCHASED]->(next_product:Product))

ここでは、顧客 c による P001 購入後に買った商品を next_product として指定しています。
p = (...) で後続購入のパスのみを変数化することで、TO_JSON(p) による可視化対象を絞り込んでいます。
条件判定用と可視化用の関係性を分離できるため、不要なパスでGraph表示が複雑化するのを防げます。
購入後30日以内という条件は、エッジのプロパティである `ordered_at` を使って書けます。

e2.ordered_at > e1.ordered_at
AND e2.ordered_at <= TIMESTAMP_ADD(e1.ordered_at, INTERVAL 30 DAY)

これで、「P001を買った後、30日以内に発生した別商品の購入」に絞れます。
このクエリを実行すると以下のようになります。

このGraphを見ると、P001(ウォーターサーバー)購入後の商品がP002(天然水ボトル)に集まっていることが分かりますね。

標準SQLとの比較と所感

標準SQLでも同じ分析はできます。ただ、同じ顧客の購入履歴を比較するには、注文テーブルを自己結合する必要があります。一方、BigQuery Graphでは、同じ `Customer` ノードから出ている2本の `PURCHASED` エッジを `MATCH` するだけで表現できます。

(c:Customer)-[e1:PURCHASED]->(...)
(c)-[e2:PURCHASED]->(...)

この「同じノードを起点に、複数の関係をたどる」書き方が、Graphらしいところだと感じました。
実際に書いてみると、SQLでJOINを組み立てるというより、「顧客から商品へ線をたどる」という感覚に近いです。この感覚は、普通のテーブル集計とは少し違っていて面白いです。

ここで、通常のテーブル集計とBigQuery Graphでのアプローチの違いを表に整理すると、以下のようになります。

$\newcommand{\arraystretch}{1.5} % \begin{array}{|l|l|l|} \hline \textbf{比較項目} & \textbf{標準SQL（従来のテーブル形式）} & \textbf{BigQuery Graph} \\ \hline \text{データの捉え方} & \text{行と列で構成される「表」} & \ \text{ノード（点）とエッジ（線）の「ネットワーク」}\\ \hline \text{関係性の表現} & \begin{gathered}\ \text{複数回のJOINや自己結合の組み合わせ}\end{gathered} & \text{MATCH 句による直感的なパターン記述} \\ \hline \begin{gathered} \text{クエリ記述の思考プロセス}\ &\end{gathered} &\text{} \begin{gathered}\ \text{関係性を1つの「表」上で表現するため、} \cr \text{テーブル同士の結合条件を組み立てる}\end{gathered} & \begin{gathered}\ \text{起点ノードから線を辿って関係性を追いかける}\end{gathered} \\ \hline \text{結果の可視化} & \text{集計数値やグリッド表} & \text{BigQuery Studio上のネットワーク図} \\ \hline \text{得意な分析} & \text{売上の合計・平均などの数値集計} & \text{購買順序の追跡、レコメンド、経路探索} \\ \hline \end{array}$

このように、クエリを書く際の思考プロセスや直感的な可視化のしやすさに大きな違いがあることが分かります。

BigQuery Graphの魅力

BigQuery Graphは、単なる既存の売上集計やSQLクエリを置き換えるものではなく、データ同士の「関係性（繋がり）」そのものをそのまま分析し、BigQuery Studio上で直感的に可視化できる点に最大の魅力があります。

特に、以下のような「複雑なリレーションの探索」が求められるビジネスシーンにおいて、非常に強力な威力を発揮すると実感しました。

マーケティング・EC分析（レコメンドの高度化）：
「Aを買った人が次にBを買い、さらにCに至る」といった一連の購買ストーリーや併売構造を視覚的に見つけ出すことで、数字の表だけでは見落としがちな「ハブになっている隠れた人気商品」を発見し、効果的なクロスセル施策へ直結させることができます。

不正検知・リスク管理：
「別名義のアカウント同士が同一のクレジットカードやIPアドレスを共有している」といった、多層に絡み合った不自然なユーザー関係（スパムやマネーロンダリングなど）を一発で検知・可視化できます。

サプライチェーン・依存関係の探索：
システム間のマイクロサービス構成や物流ネットワークなど、「どこがボトルネックや単一障害点（SPOF）になっているか」を構造的に特定できます。

ビジネス意思決定における「可視化」のインパクト
BI開発やデータ抽出業務を行う中で、「集計表や数値を提示するだけでは、複雑な関係性や課題の緊急性がビジネスサイド（非エンジニア）に伝わりにくい」と感じることが多々あります。BigQuery Graphによってデータの繋がりがネットワーク図として一目で把握できるようになると、「分析者とビジネス側の認識のギャップ」が一瞬で埋まります。「なぜこの施策が必要なのか」「どこに構造的なリスクが潜んでいるのか」が直感的に共有できるため、会議での議論の空中戦を防ぎ、意思決定のスピードと確信度を劇的に高めるインパクトが期待できます。

これまでは専用のグラフ分析基盤や複雑なETLパイプラインが必要だった高度な分析が、普段使いのBigQuery環境だけで今すぐ手軽に始められるのは、データ基盤運用やデータ抽出を担う身としても大きな強みです。

今後も「表形式の集計」にとどまらず、データ同士の繋がりから新しいインサイトを引き出す強力な武器として、積極的に実務で活用していきたいと思います！

（書き手：U）

このように、現場において新しい技術に触れ、実践できるのが当社D4cプレミアムで働く大きなメリットです。
新しい技術や考え方を、いち早く身につけたい方はぜひ求人サイトもご覧ください！
D4cプレミアム：採用サイト

この記事が参加している募集

#
企業のnote
with note pro
40,684件