はじめに
「SQLが書けないメンバーにもデータを見せたい」という課題は、データ活用を推進しようとすると必ず出てくる。
都度エンジニアに依頼する運用は持続しないし、全員にBigQueryを覚えてもらうのも現実的ではない。
BigQuery Conversational Analytics は、この問いに対する一つの答え候補だ。
自然言語でデータに関する質問ができる「データエージェント」を作って、チームに公開できる。
ポイントは「チャットで質問できるようにする」だけではなく、エージェントを設定・カスタマイズして公開する側になれるという点だ。
用語集や検証済みクエリを仕込んでおくことで、社内固有のビジネス用語にも答えられるエージェントを育てられる。
今回は、公開データセット bigquery-public-data.thelook_ecommerce を使ってエージェントを作り、どこまで使えるかのファーストインプレッションを確かめた。
1. 準備
必要なIAMロール
エージェントを作るには、追加するナレッジソース（テーブルやビュー）に対してクエリを実行できる権限が必要だ。
| ロール | 用途 |
|---|---|
roles/cloudaicompanion.user |
Gemini機能の利用 |
roles/bigquery.dataViewer |
テーブルの読み取り |
roles/bigquery.jobUser |
クエリジョブの実行 |
APIの有効化
次のコマンドで有効化する。
gcloud services enable cloudaicompanion.googleapis.com
2. エージェントカタログを開く
エージェントの管理画面は、BigQuery Studio のエージェントカタログタブにある。
BigQuery Studio を開くと、上部タブに「エージェントカタログ」が表示される。
ここで、自分が作ったエージェント・他のユーザーが公開したエージェント・プロジェクトのサンプルエージェントを一覧できる。
「エージェントを作成」ボタンから新しいエージェントの作成を開始する。
3. エージェントを作ってみた
エージェントは主に4つの要素で構成される。
| 要素 | 役割 |
|---|---|
| ナレッジソース | 参照させるテーブル・ビュー・UDF（最大100個） |
| メタデータ | テーブルやカラムの意味・ビジネスコンテキストの定義 |
| 用語集 | 「トップパフォーマー」=「最高売上の担当者」のような社内用語の登録 |
| 検証済みクエリ | よく使う質問に対してSQLを事前定義しておく仕組み |
ナレッジソースの追加
まず、エージェントが参照するテーブルを登録する。
今回は thelook_ecommerce から次の3テーブルを追加した。
-
orders：注文データ（注文ID、ユーザーID、ステータス、日付など） -
order_items：注文明細（商品ID、数量、売上金額など） -
products：商品マスタ（商品名、カテゴリ、価格など）
ナレッジソースは最大100個まで追加できる。
どのテーブルを含めるかはエージェントの「答えられる範囲」に直結するため、最初はスコープを絞るのが無難だ。
メタデータの設定
テーブルやカラムに説明を付与することで、エージェントがデータの意味を正確に理解できるようになる。
ナレッジソースの「カスタマイズ」からメタデータの登録が可能。
各カラムに対するDescriptionをGeminiが自動で提案してくれる。今回はこれをそのまま適用した。
なお、ページ上部に記載がある通り、ここで追加したカラムの説明は、BigQueryのカラムDescriptionには反映されない。
用語集の登録
用語集には、自然言語の質問に含まれるビジネス用語とその定義を登録する。
「売上」や「有効注文」が何を指すかはデータによって異なる。
thelook_ecommerce では order_items.status に 'Complete' / 'Cancelled' / 'Returned' などが混在しているため、ここを曖昧にしたままにすると集計が意図とズレる。
今回は次の用語を登録した。
| 用語 | 定義 |
|---|---|
| 売上 |
order_items.sale_price の合計。status = 'Complete' の行のみを対象とする |
| 有効注文 |
orders.status = 'Complete' の注文 |
| 返品 |
orders.status = 'Returned' の注文 |
| リピーター | 2回以上購入したユーザー（user_id で集計） |
| 新規顧客 | 初回購入日から30日以内のユーザー |
| AOV（平均注文額） | 有効注文の売上合計 ÷ 有効注文件数 |
| 売れ筋商品 | 過去30日間の販売数量（order_items の行数）が上位の商品 |
「売上」の定義が曖昧なまま「先月の売上は？」と聞くと、キャンセルや返品を含んだ数字が返ってくる可能性がある。
用語集に入れておくことで、この手のズレを防げる。
検証済みクエリの設定
検証済みクエリ（旧称：ゴールデンクエリ）は、よく使う質問に対してSQLを事前定義しておく仕組みだ。
エージェントが毎回SQLを生成するより、定義済みのクエリを呼び出す方が結果が安定する。
今回は次の2つを登録した。
① 月別売上サマリー
「先月の売上は？」「月ごとの推移を見せて」などの質問に対応させる。
キャンセル・返品を除いた有効注文のみを集計するロジックを埋め込む。
SELECT
DATE_TRUNC(oi.created_at, MONTH) AS month,
SUM(oi.sale_price) AS total_revenue,
COUNT(DISTINCT oi.order_id) AS order_count,
COUNT(DISTINCT oi.user_id) AS customer_count,
ROUND(
SUM(oi.sale_price) / COUNT(DISTINCT oi.order_id), 2
) AS aov
FROM
`bigquery-public-data.thelook_ecommerce.order_items` AS oi
WHERE
oi.status = 'Complete'
AND oi.created_at BETWEEN @start_date AND @end_date
GROUP BY
month
ORDER BY
month
@start_date / @end_date はクエリパラメータとして検証済みクエリに渡せる。
「今年の月別売上を見せて」と言えば、エージェントが期間を補完してくれる。
② カテゴリ別売上ランキング
「どのカテゴリが一番売れているか」という質問に対応させる。
order_items と products のJOINが必要なため、毎回生成させるより事前定義しておいた方が安定する。
SELECT
p.category,
SUM(oi.sale_price) AS total_revenue,
COUNT(DISTINCT oi.order_id) AS order_count,
ROUND(
SUM(oi.sale_price) / COUNT(DISTINCT oi.order_id), 2
) AS aov
FROM
`bigquery-public-data.thelook_ecommerce.order_items` AS oi
JOIN
`bigquery-public-data.thelook_ecommerce.products` AS p
ON oi.product_id = p.id
WHERE
oi.status = 'Complete'
GROUP BY
p.category
ORDER BY
total_revenue DESC
4. エージェントに質問してみた
エージェントへの質問は自然言語で行い、回答も自然言語のテキストで返ってくる。
SQLエディタのように「クエリ→結果」の画面にはならない。
では、裏側でどんなSQLが実行されたかはどこで見るか。
答えはBigQueryのジョブ履歴だ。
エージェントが質問に答えるたびにクエリジョブが走るため、コンソールの「ジョブ履歴」から実行済みSQLを参照できる。
確認したいのは、「検証済みクエリが呼ばれているかどうか」。
ジョブ履歴に残ったSQLが事前定義したクエリと一致していれば、エージェントが検証済みクエリを使ったと判断できる。
質問①：月別売上サマリー（検証済みクエリ①を狙う）
「今年の月別売上を教えて」と入力した。
エージェントからは自然言語の回答が返ってくる。回答の中に「検証済みクエリを利用した」旨の記述も確認できた。
実際に実行されたSQLはジョブ履歴から確認する。
確認ポイントは2つだ。
status = 'Complete' の絞り込みが入っているか、そして @start_date/@end_date を今年の範囲に補完してくれているか。
いずれも期待通りの結果となった。
質問②：カテゴリ別ランキング（検証済みクエリ②を狙う）
「カテゴリ別の売上ランキングを見せて」と入力した。
こちらも「検証済みクエリを利用した」旨の記述が確認できた。
order_items × products のJOINと status = 'Complete' の絞り込みが事前定義通りに入っていることが確認できた。
質問③：検証済みクエリ外の質問
「リピーターの割合は？」と入力した。
用語集に「リピーター＝2回以上購入したユーザー」と定義してあるが、検証済みクエリは登録していない。
エージェントが用語集の定義を参照しながらSQLをゼロから組み立てるかどうかが確認ポイントだ。
order_count >= 2の条件が含まれていることがわかる。
5. 使ってみて分かったこと
良かった点
作るだけなら非常に簡単
ナレッジソースを追加して公開するだけなら、数分で完結する。
小さいユースケースごとにエージェントを分けて作っておけば、チーム内のナレッジを段階的に蓄積できる。
「エージェントを育てる」という設計思想
チャットでデータに質問できる、というだけならData Canvasでもできる。
Conversational Analyticsの価値は、用語集・検証済みクエリ・メタデータを積み重ねることで、自社のビジネスコンテキストを理解したエージェントを作れる点にある。
グラフまでワンストップで到達できる
SQL→実行→可視化の流れが自然言語1文で完結する。
探索の初動フェーズにとくに効果が高い。
エージェントを公開・共有できる
作ったエージェントをチームに公開できる設計になっている。
「データを見たいがSQLは書けない」メンバーへのセルフサービス化の入り口になり得る。
注意点
メタデータの整備が前提になる
公開データセットのようにカラム名が英語で意味が通っていれば精度は高い。
しかし社内データに多い略語・日本語・連番のような命名では、メタデータの設定なしには精度が落ちる可能性が高い。
複雑なビジネスロジックは検証済みクエリで補う
「キャンセル・返品を除いた有効売上」のような条件は、自然言語だけで正確に伝えるのは難しい。
検証済みクエリにSQLを事前定義しておくことで精度を担保するのが現実的な運用だと感じた。
エージェントを「作る側」のコストは低くない
ナレッジソースを追加するだけなら簡単だが、用語集・検証済みクエリ・メタデータをきちんと設定しようとすると、それなりの準備が必要。
「設定ゼロで使える」というわけではない。
6. まとめ
BigQuery Conversational Analytics は、「データを自然言語で検索できるUIを作る」ではなく、「ビジネスコンテキストを知ったエージェントを育てて公開する」という設計思想の機能だった。
チャットボットというより、社内のデータに詳しい専門家を一人育てるイメージに近い。
設定に手間はかかるが、その分だけ「本当に使えるエージェント」に育てられる。