まず、Graph（グラフ）という考え方からみてみます。

Graphとは、データを「点」と「線」で表現するモデルです。

・点＝ノード（Node）

・線＝エッジ（Edge）

例えば、ECサイトデータを考えてみます。

通常のデータベースでは、

・顧客情報のテーブル

・商品情報のテーブル

・注文履歴のテーブル

のように、情報は分割されて保存されます。

もちろんSQLでこれらを結合すれば分析はできますが、データ自体はあくまで”独立した表”として存在しています。

一方でGraphでは、こうしたデータを最初からつながりを持った形で捉えます。

・「顧客Aがコーヒーを購入した」

・「コーヒーと一緒に買われやすいのはサンドウィッチ」

・「顧客Aと顧客Bは購買傾向が似ている」

といった関係そのものをデータとして扱います。

つまり、通常の表形式データが「情報を並べて保存する」のに対し、Graphは「情報同士の関係まで含めて保存する」世界といえます。

この違いによって、分析の際も「何が売れたか」だけでなく、「何と何がどうつながっているか」を辿りやすくなります。

BigQuery Graphは、BigQuery上の既存テーブルを使ってGraph構造を定義できる機能です。

重要なポイントは、専用のグラフデータベースを用意する必要がなく、BigQueryにあるテーブルをそのまま使ってグラフ分析ができるという点です。

ノードとエッジ

ノードとは、Graphの中で「主体となる情報」です。

ECサイトのデータであれば、顧客、商品、店舗といった、それぞれ単独で意味をもつものをノードとして扱います。

一方エッジとは、ノード同士を結ぶ「関係」です。

例えば、「顧客が商品を購入した」「商品と商品が一緒に買われた」といった関係をエッジとして表現します。

CustomerというノードとProductというノードをPURCHASED（購入した）というエッジで結んでいるという関係は下記のように表現されます。

Customer –>PURCHASED–> Product

Graphの定義方法

BigQuery Graphでは、既存のテーブルをもとにノードとエッジを定義します。

例えば、以下のようなテーブルがあるとします。

• customers テーブル（顧客情報）
• products テーブル（商品情報）
• orders テーブル（購入履歴：customer_id, product_id を持つ）

これらを使って、グラフを定義します。

CREATE OR REPLACE PROPERTY GRAPH dataset.ec_graph

NODE TABLES (

dataset.customers

KEY (customer_id)

LABEL Customer,



dataset.products

KEY (product_id)

LABEL Product

)

EDGE TABLES (

dataset.orders

SOURCE KEY (customer_id) REFERENCES Customer

DESTINATION KEY (product_id) REFERENCES Product

LABEL PURCHASED

);

この定義によって、

• customers → Customerノード
• products → Productノード
• orders → PURCHASEDエッジ

として扱われるようになります。

つまり、既存のテーブル構造をそのままグラフとして再解釈するイメージです。

実際の検索方法

ノードとエッジを定義すると、BigQuery GraphではGraph Query Language（GQL）を使って問い合わせができるようになります。

GQLは通常のSQLのように表を結合していくというよりも、「どのノードから出発して、どの関係を辿り、どのノードに到達したいか」を書くための言語です。

Notebook上でグラフとして可視化するための基本形は下記です。

!pip install bigquery-magics==0.12.1

%%bigquery --graph

GRAPH dataset.ec_graph

MATCH p=(c:Customer)-[:PURCHASED]->(p:Product)

RETURN TO_JSON(p) as paths

上記は、Customerノードから出発し、PURCHASEDという関係を辿って、Productノードに到達するという意味になります。

これは、「顧客が購入した商品を取得する」という関係探索を表しています。

実際に実行すると下記のような結果が表示されます（今回は小売りのデモ用のデータを利用しています）。

商品あるいは顧客のポイント部分を押下すると詳細も確認できます。

今回は単純な「顧客」と「購入商品」の関連を可視化してみましたが、もう少し複雑にして、一緒に購入されている商品も確認してみたいと思います。

可視化すると、

・アイスコーヒーと一緒に購入されているのはチキンサンドとサラダボウル

・アイスコーヒーを購入する人は、カフェラテも購入している人が多い

・カフェラテと一緒に購入されているのは、ハムサンド

など関係性がより分かりやすいですね！

SQLを利用して、Graphで辿った結果を表として取得することも可能です。

SELECT *

FROM GRAPH_TABLE (

  dataset.ec_graph

  MATCH (c:Customer)-[p:PURCHASED]->(pr:Product)

  COLUMNS (

    c.customer_id AS customer_id,

    pr.product_id AS product_id,

    pr.product_name AS product_name,

  )

)

ここで気になるのが、「JOINを使えば、通常のSQLでも同じことができるのでは？」という点です。

結論として、可能です。

ただし、関係を深く辿ろうとするほど、SQLはかなり複雑になっていきます。

①対象顧客→②類似顧客→③類似顧客が購入した商品→④その商品と一緒に購入される商品を辿る場合、SQLでは複数回のJOINや中間テーブルが必要になります。

一方Graphでは、事前にGraph構造を定義してくことで、下記のように関係探索を直感的に記述できます。

MATCH (c:Customer)-[:SIMILAR_TO]->(sc:Customer)

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

-[:BOUGHT_WITH]->(rec:Product)

上記のようにGraphでは「どの関係を順番に辿るか」をそのまま書くことができます。

この「読みやすさ」と「意図の明確さ」が通常のSQLとの大きな違いかと思います。

対比として同じ処理をSQLで実装すると、テーブル設計やカラム構成にもよりますが、少なくとも複数回のJOINが必要になり、場合によっては中間テーブルも必要になります。

SELECT

  c.customer_id              AS customer_id,

  sc.customer_id             AS similar_customer_id,

  p.product_name             AS product_name,

  rec.product_name           AS rec_product_name

FROM customers c



-- 類似顧客

JOIN customer_similarity sim

  ON c.customer_id = sim.customer_id



JOIN customers sc

  ON sim.similar_customer_id = sc.customer_id



-- 類似顧客の購入商品

JOIN purchases pur

  ON sc.customer_id = pur.customer_id



JOIN products p

  ON pur.product_id = p.product_id



-- 併買商品

JOIN bought_with bw

  ON p.product_id = bw.product_id



JOIN products rec

  ON bw.rec_product_id = rec.product_id



WHERE c.customer_id = 1;

デモデータを利用して実際にグラフの結果を表形式で結果を取得してみました。

検索対象をcustomer_id=1の人で検索すると、類似顧客としてcustomer_id=3が見つかり、その顧客が購入した商品は「アイスティー」でした。さらに、アイスティーと一緒に購入される商品として「ショートケーキ」や「シュークリーム」といった関連商品まで辿ることができます。

BigQuery Graphが力を発揮するのは、「つながりを見る分析」です。

代表的には下記のような用途があります。

・顧客レコメンド

・Customer360分析

・不正取引検知

・サプライチェーン分析

・ネットワーク障害分析

共通点は、単一テーブルを集計して終わりではなく、複数のテーブルのつながりを追う必要がある分析という点です。

AIエージェントが業務判断を行う場面では、

• 情報を探す
• 関連情報を辿る
• 複数の材料を組み合わせる

というプロセスが必要になります。

例えば営業支援エージェントであれば、

• 類似顧客は何を導入しているか
• その顧客群でよく組み合わされる製品は何か

といった関係を辿ることで、提案内容を動的に生成できます。

BigQuery Graphは、この「探索経路」をデータとして扱いやすくする仕組みです。

BigQuery Graphは、BigQuery上の既存データを活用しながら、関係探索を可能にする機能です。

通常のSQLでも同様の分析は実現できますが、Graphを使うことで

・関係を辿るロジックを直感的に書ける

・クエリの意図が読みやすい

・AIエージェントの探索と相性が良い

といったメリットがあります。

今後、AIに業務判断を任せる場面が増えるほど、「データ同士のつながり」をどう扱うかが重要に重要になっていくはずです。

BigQuery Graphはそういった場面で非常に注目したい機能だと感じました。