G-gen の福井です。自然言語でデータを分析できる BigQuery Conversational Analytics について、回答精度を高める手段を徹底解説します。

はじめに
回答精度向上の考え方
- 回答精度を決めるレイヤー構造
- Google が推奨する積み上げの順序
土台となるデータとナレッジソース
- スキーマ設計とデータ整形
- ナレッジソースの絞り込み
構造化コンテキストの整備
- テーブルと列の説明
- 用語集の使用
検証済みクエリ
データエージェントへの指示
- 補完としての位置づけ
- 指示の書き方カタログ
BigQuery Graph による精度向上
- BigQuery Graph とは
- 仕組み
運用と改善
- チューニングの進め方
- 生成 SQL と推論のレビュー
実践と応用

はじめに

当記事の概要

BigQuery Conversational Analytics（以下、Conversational Analytics）は、BigQuery のテーブルに対して自然言語で質問すると、データエージェントと呼ばれる AI が SQL を自動生成して回答する機能です。専門的な SQL の知識がなくてもデータを分析できる手軽さがありますが、扱うデータやデータエージェントへ与える情報の準備しだいで、回答の精度は大きく変わります。

当記事では、Conversational Analytics の回答精度を高めるための手段を、Google が推奨する考え方をふまえて解説します。土台となるデータ設計から始め、テーブルや列のメタデータ、用語集、検証済みクエリ、データエージェントへの指示までを順に積み上げ、最後に作成からチューニング、運用までの進め方を示します。

BigQuery Conversational Analytics とは

Conversational Analytics は、BigQuery 上で自然言語によるデータ分析を行うための機能です。利用者が「先月の売上が最も多かった商品は何か」といった質問を日本語や英語で入力すると、データエージェントが質問の意図を解釈します。そのうえで対象テーブルに対する SQL を生成・実行し、表やグラフ（チャート）を交えた回答を返します。

回答とあわせて、生成された SQL や、データエージェントがどのように考えたかという推論の過程も確認できます。そのため、利用者は回答の根拠をたどり、結果が妥当かどうかを自分で判断できます。

この分析を担う中心的な存在がデータエージェントです。データエージェントは、分析対象とするテーブルやビューといったナレッジソースと、データの読み解き方を補助する情報をひとまとめにした単位です。回答精度を高める工夫の多くは、このデータエージェントに対して、より良い情報を与えることに集約されます。

Conversational Analytics の概要や料金体系といった基本事項は、以下の記事で詳しく解説しています。あわせて参照してください。

blog.g-gen.co.jp

データエージェントと回答精度

Conversational Analytics では、データエージェントを介さず、データソースに直接質問することもできます。手軽ではあるものの、Google はこの直接の対話について、データエージェントを使う場合よりも回答の精度が落ちる可能性があると説明しています。高い精度が求められる用途では、データエージェントを作成して質問することが推奨されています。

データエージェントが精度の面で有利なのは、利用者が与えた文脈を踏まえて回答できるためです。同じテーブルでも、列が何を表すのか、社内で「売上」や「優良顧客」をどう定義しているのか、よく聞かれる質問にはどんな SQL で答えるべきなのか、といった情報は、データそのものを見ただけでは分かりません。こうした文脈をデータエージェントに与えておくことで、質問の解釈や SQL の生成が安定し、回答の精度が高まります。

ただし、データエージェントを作成しても、情報を何も与えなければ回答の精度は限定的です。当記事でこれから解説する手段は、いずれも「データエージェントにどのような文脈を、どの順番で与えるか」という観点で整理できます。次の見出しでは、まずその全体像を示します。

参考 : Analyze data with conversations

回答精度向上の考え方

回答精度を決めるレイヤー構造

回答精度を高める手段は数多くありますが、ばらばらのテクニックとして覚えるよりも、土台から積み上げる階層として捉えると整理しやすくなります。次の図は、当記事で解説する手段を4つの層に整理したものです。

図の下にある層ほど、整えておくと幅広い質問で回答精度の底上げにつながります。たとえば、クリーンなデータや意味の分かりやすいスキーマ、テーブルや列の説明は、それだけで多様な質問に対する回答精度を高めます。一方、図の上にある検証済みクエリとデータエージェントへの指示は、特定の質問や業務ロジックを狙って正確に扱うための手段です。

どの手段をどの順番で整備していくのがよいかは、次の見出しで Google の推奨に沿って解説します。これらに加えて、より高度な手段として BigQuery Graph があり、当記事の後半で取り上げます。また、いずれの層も一度設定して終わりではなく、運用しながら継続的に回答精度を改善していく必要があります。

Google が推奨する積み上げの順序

精度向上に取り組むとき、最初から思いつく情報をすべて詰め込む必要はありません。回答を確かめながら段階的にコンテキストを足していくアプローチを、Google は推奨しています。

まずは、追加のコンテキストをほとんど与えない状態でデータエージェントに質問し、回答を確認します。データエージェントはテーブルの構造などから文脈をある程度読み取れるため、これだけで十分なケースもあります。

満足な回答が得られない場合は、データの読み解き方を補う情報を足します。具体的には、テーブルや列の説明、用語集、そして想定質問と正解 SQL の例（検証済みクエリ）です。公式ドキュメントはこれらをまとめて構造化コンテキストと呼び、優先的に整備することを勧めています。前掲の図では、構造化コンテキストと検証済みクエリの2つの層がこれに該当します。

それでも改善しない場合は、最後に、必要に応じてデータエージェントへの指示（カスタム指示）を加えます。データエージェントは指示がなくてもある程度は文脈を理解できます。そのため指示は、テーブルや列のメタデータや検証済みクエリでは変えられない挙動を調整したいときに加えます。

この「まず試し、不足を見極めてから足す」進め方をとるのは、むやみに情報を増やすと、かえってデータエージェントを混乱させてしまうためです。当記事では以降、整備の土台となるものから順に各手段を解説します。

土台となるデータとナレッジソース

スキーマ設計とデータ整形

データエージェントは、テーブルの列名や型といったスキーマの情報を手がかりに SQL を組み立てます。そのため、列名そのものが意味を表していると、質問の解釈や SQL 生成の精度が上がります。たとえば order_dt という名前よりも、 order_created_date のように内容が分かる名前のほうが、データエージェントは正しく扱えます。既存のテーブルの列名を変更するのが難しい場合は、後述するテーブルや列の説明で補う方法もあります。

複雑な加工が必要なデータは、あらかじめ論理ビューや整形済みテーブルとして用意しておくのも有効です。複数テーブルの結合や前処理をビュー側に寄せておき、整形済みのテーブルやビューをナレッジソースにします。こうすると、データエージェントが結合条件や加工ロジックを推測する余地が減り、回答が安定します。生のイベントテーブルをそのまま渡すより、分析の意図に沿って整えたテーブルやビューを渡すほうが、回答精度を高めやすくなります。

関連して、以下の記事では、ライオン株式会社様が基幹システムである SAP のデータモデルを、BigQuery からの分析に供するように再設計した試みが紹介されています。

zenn.dev

ナレッジソースの絞り込み

データエージェントに接続するナレッジソースは、その用途に必要なテーブルやビューだけに絞ることが大切です。関連性の低いテーブルまで含めると、データエージェントが質問に対してどのテーブルを使うべきか迷い、見当違いのデータを参照してしまう可能性が高まります。用途を絞り込んだデータエージェントほど、質問の解釈がぶれにくくなります。

データエージェントが扱う範囲を絞ることは、Google も推奨しています。1つのデータエージェントに幅広い用途を詰め込むと、同じ言葉でも使う人によって意味や計算方法が異なるデータが混在します。その結果、質問するたびに回答がぶれやすくなります。

具体的な目安は次のとおりです。必要なデータソースが20を超える、または指標の定義が揃っていないデータをまとめて扱う場合は、用途ごとにデータエージェントを分けることが推奨されています。たとえば「売上分析用」「在庫管理用」のように分けておくと、それぞれが扱う範囲と用語の意味が明確になり、回答精度の向上につながります。

なお、ナレッジソースを必要最小限に絞る利点は、回答精度だけではありません。参照するデータが限定されるため、コストの抑制やアクセス範囲の最小化にもつながります。これらの運用面の論点は、当記事の後半であらためて取り上げます。

参考 : Conversational analytics overview - Best practices

構造化コンテキストの整備

テーブルと列の説明

データエージェントは、列名だけでなく、テーブルや列に付けられた説明文からもデータの意味を判断します。前述のとおり、分かりやすい列名は精度の向上に役立ちます。ただし、単位や取りうる値、業務独自の意味など、名前だけでは表しきれない情報もあります。こうした情報は説明文で補います。

説明文は、次の2つの方法で用意できます。

方法	設定する場所	特徴
BigQuery のテーブルに設定する説明	BigQuery のテーブル・列	データエージェントに限らず、そのテーブルを使うあらゆる場面で役立つ、最も基本的な説明
カスタマイズ画面で書き加える説明	データエージェントの編集画面	データエージェント固有で、元のテーブルには影響しない。公開データセットなどでも補える

最も基本となるのは、BigQuery のテーブル自体に説明を設定しておくことです。テーブルや列への説明の追加は、Google もベストプラクティスとして挙げています。テーブル側で整えておけば、データエージェントだけでなく、ほかの分析作業でも同じ説明を使用できます。そのうえで、データエージェント固有の補足が必要な場合は、カスタマイズ画面で説明を書き加えます。列の説明は Gemini が候補を提案するため、それをたたき台に、データエージェントが迷いそうな列から整えると効率的です。

なお、BigQuery にはテーブルの分析情報（data insights）を生成する機能もあります。これは、Gemini がテーブルのメタデータを解析して概要などをまとめるものです。まとめた内容は、データエージェントが回答を作る際の参考にもなります。分析情報はテーブルの [分析情報] タブで生成・確認できます。

用語集の使用

用語集（glossary）は、利用者が使う言葉と、実際のデータとを対応づけておく仕組みです。たとえば社内で使う略語や、「優良顧客」「稼働率」といった業務独自の言い回しを登録しておくと、データエージェントが質問の意図を正しく解釈しやすくなります。

Conversational Analytics の用語集は、次の2種類に分かれます。

種類	適用範囲	管理場所
ビジネス用語集	BigQuery のリソース全体	Knowledge Catalog（Dataplex）
カスタム用語集	そのデータエージェント内のみ	データエージェントの編集画面

使い分けの考え方はシンプルです。全社で共通して使う用語（売上や粗利の定義など）は、Knowledge Catalog のビジネス用語集で一元管理します。Knowledge Catalog の用語は BigQuery リソース全体に適用されるため、組織全体で定義をそろえたいときに向いています。一方、特定のデータエージェントでしか使わない言い回しは、そのデータエージェントのカスタム用語集に登録します。

注意点として、同じ用語を Knowledge Catalog とカスタム用語集の両方に定義することは避けます。定義が二重になると、どちらが使われるかが分からず、回答が不安定になります。ビジネス用語を修正するときは、Knowledge Catalog 側で編集します。そのあとデータエージェントの編集画面に戻り、修正が反映されたことを確認します。

参考 : Create data agents - Create or review glossary terms
参考 : ビジネス用語集を管理する

検証済みクエリ

検証済みクエリの働き

検証済みクエリ（verified queries）は、想定される質問と、その質問に対する正解の SQL をセットで登録しておく仕組みです。このようなクエリは、俗にゴールデンクエリとも呼ばれます。コンテキストの優先度についても、Google は検証済みクエリ、用語集、データエージェントへの指示の順を挙げています。

検証済みクエリの働きは、利用者の質問が登録済みの質問に一致するかどうかで、2通りに分かれます。

利用者の質問	データエージェントの動き
登録した質問に一致する	登録された SQL をそのまま実行する。あらかじめ正しさを確認した SQL が使われるため、信頼できる回答が安定して得られる
登録した質問に一致しない	登録された SQL を、データの解釈やクエリの書き方の参考として使用する。似た質問に答えるための手本になる

このように、検証済みクエリは「登録した質問にはそのまま正解を返す」「それ以外の質問にも手本になる」という二段構えで、回答精度を高めます。優先度が高いのは、ほかの手段がデータの意味を説明するのに対し、検証済みクエリが質問に対する正解の SQL を直接与えるためです。複雑な集計や、間違えやすい業務ロジックを含む質問ほど、登録する効果は大きくなります。

参考 : Create data agents - Create verified queries

パラメータ化検証済みクエリ

通常の検証済みクエリは、登録した質問とほぼ同じ質問にしか一致しません。たとえば「東京倉庫のバナナの在庫数は？」を登録しても、「大阪倉庫のりんごの在庫数は？」には別のクエリが必要です。質問のバリエーションごとに登録していては、数が増えて管理が大変です。

ここで役立つのが、パラメータ化検証済みクエリです。これは、質問のなかで変化する部分をパラメータ（プレースホルダ）に置き換えた、再利用可能な SQL テンプレートです。利用者の質問から該当する値を自動で抽出し、実行時にテンプレートへ当てはめて回答します。

たとえば、商品と倉庫を変えながら在庫を尋ねる質問は、次のように1つのテンプレートにまとめられます。

@product の在庫数は @region 倉庫でいくつですか？

このように登録しておくと、「東京倉庫のバナナ」「大阪倉庫のりんご」のように商品や倉庫が変わっても、1つのテンプレートで対応できます。質問のたびに個別のクエリを用意する必要がなくなり、少ない登録数で幅広い質問に検証済みの回答を返せます。

パラメータ抽出の精度を高める記述

パラメータ化検証済みクエリは、テンプレートの作り方によって、パラメータがうまく抽出されないことがあります。その原因と対策は、データエージェントが行う2つの処理から整理できます。1つは、利用者の質問に対してどのテンプレートを使うかを選ぶことです。もう1つは、質問の文章から、各パラメータに当てはまる値を取り出すことです。精度を高めるためのポイントは、いずれもこの2つの処理を助けるものです。

ポイント	内容
分かりやすいパラメータ名にする	`@d1` のような名前ではなく、`@start_date` のように何を表すかが分かる名前を付ける
パラメータの説明を具体的に書く	データエージェントは説明をもとに、質問から値を読み取る。`num_enrollments` のような名前だけでなく、「5〜14歳の生徒の登録数」のように具体的に説明する
データ型をそろえる	SQL が期待するデータ型と、質問から抽出される値のデータ型が一致するようにする
手間に見合う質問に絞る	単純な質問まですべて登録せず、SQL が複雑になる質問や、計算ロジックが分かりにくい質問など、テンプレート化する価値が高いものに絞る
十分にテストする	さまざまな言い回しで質問し、パラメータが正しく抽出されるかを確認する

特に効果が大きいのが、パラメータの説明を具体的に書くことです。値を取り出す処理は、質問の言い回しに左右されます。データエージェントは、質問のどの部分がどのパラメータにあたるのかを、パラメータの説明をもとに判断するためです。説明に、名前だけでは伝わらない意味や範囲を書いておくと、データエージェントが値を取り違えにくくなり、回答の精度が安定します。

データエージェントへの指示

補完としての位置づけ

データエージェントへの指示（agent instructions、カスタム指示）は、データの解釈や回答のしかたを、自然言語のルールとしてデータエージェントに伝える仕組みです。たとえば「特に指定がなければ完了済みの注文だけを対象にする」といった内容を文章で書いておけます。

指示は自由に文章を書けるため、つい何でも詰め込みがちです。ただし、データエージェントは指示がなくてもある程度は文脈を理解できます。そのため、テーブルや列の説明や検証済みクエリなど、ほかの機能で対応できない部分に限って補うのが基本です。

指示の書きすぎは、かえって逆効果になることもあります。ルールが増えるほど、指示どうしが矛盾したり、データエージェントが解釈に迷ったりするためです。まずはこれまでに解説した手段で土台を整え、そのうえで調整しきれない挙動だけを指示で補います。この順番を意識することで、指示を最小限に保てます。

指示の書き方カタログ

指示が役立つのは、データエージェントが指定なしでは判断に迷う場面です。どの列が重要か、ある言葉がどの列を指すのか、複数のテーブルをどうつなぐのか。こうした判断を文章で明示しておくと、データエージェントの解釈が安定します。よく使われる指示の例を、防げる失敗・記述例とあわせて次の表にまとめます。

指示の例	防げる失敗	記述例
重要な列を伝える	列が多いテーブルで、分析の中心になる列を見落とす	「この表で重要な列は、顧客 ID・商品 ID・注文日です」
集計に使う列を決める	「推移」「商品別」のような曖昧な言葉を、別の列で集計してしまう	「『推移』を尋ねられたら `order_created_date` で並べる」「『商品別』なら `product_category` で集計する」
既定の絞り込みを決める	利用者が条件を言わないと、対象が広がりすぎる	「特に指定がなければ、完了した注文（`order_status = 'Complete'`）だけを対象にする」
言い換えを対応づける	社内用語がどの列・条件を指すか分からず、別の列を使う	「『売上』は `total_sale_amount` を指す」「『優良顧客』は購入回数が5回を超える顧客とする」
使わない列を指定する	紛らわしい派生列などを誤って使う	「`Transaction Date Derived`、`City Derived` は使わない」
結合方法を指定する	複数テーブルをまたぐ質問で、誤った列どうしを結合する	「売上と顧客は `order_items.user_id = users.id` で結合する」

これらの指示に共通するのは、データエージェントが推測に頼らざるを得ない部分を、あらかじめ言葉で埋めておくという考え方です。推測の余地が減るほど、同じ質問に対する回答は安定します。逆に言えば、指示で埋めるべきなのは「人なら前提として知っているが、データだけからは読み取れない」情報です。

なお、言い換えの対応づけは、カスタム用語集でも設定できます。同じ内容を用語集と指示の両方に書くと管理が重複するため、どちらか一方にまとめておくと整理しやすくなります。

参考 : Create data agents - Create agent instructions

BigQuery Graph による精度向上

BigQuery Graph とは

これまで解説した精度向上の手段は、いずれもテーブルやビューを対象とするものでした。これらに加えて、より高度な手段として、BigQuery Graph をデータソースに使う方法があります。BigQuery Graph は、2026年7月現在、プレビュー段階の機能です。

BigQuery Graph は、データをノード（点）とエッジ（線）の関係としてモデル化する仕組みです。たとえば、顧客・注文・商品・倉庫といった対象をノードとして、その間のつながりをエッジとして表現します。このように関係を表したデータを、当記事ではグラフと呼びます。Conversational Analytics でグラフをデータソースにすると、データエージェントは生のテーブルではなく、ノード間の関係をたどりながら回答を組み立てます。

参考 : BigQuery Graph の概要
参考 : Conversational analytics overview - Graph support

仕組み

グラフが精度の面で有利なのは、複数の関係を順にたどる質問に適しているためです。たとえば「ある配送センターで遅延が起きたとき、どの顧客の注文に影響するか」という質問を考えます。テーブルで答えるには、配送センター・倉庫・注文・顧客を順に結合する必要があり、結合が増えるほど誤りも起きやすくなります。グラフでは、配送センターから注文、顧客へと関係を直接たどって答えを導けます。質問に応じて、データエージェントは GQL または SQL を構築して回答します。たどった経路は図として表示されます。

グラフでも、これまでの手段と同じ考え方で精度を高められます。グラフのラベルやプロパティに説明や同義語を定義しておくと、データエージェントが質問を解釈しやすくなります。

データソースに使えるグラフは、1つのデータエージェントまたは会話につき1つまでです。また、テーブルとグラフを同時にデータソースにすることはできません。

運用と改善

チューニングの進め方

データエージェントは、一度作ったら終わりではなく、回答を確かめながら調整していくものです。

データエージェントの編集画面には、公開する前に回答を試験できるプレビュー用の入力欄があります。ここに質問を入力すると、その時点の設定で回答が返ります。試すときは、1つの理想的な質問だけでなく、利用者が実際に使いそうな複数の言い回しで確認します。データエージェントは質問の言い回しによって解釈が変わるためです。期待した回答にならなければ、次の見出しで述べる方法で、生成された SQL を確認します。そのうえで原因に応じて、テーブルや列の説明、検証済みクエリ、指示といった設定を見直します。こうしたやり取りを繰り返し、回答の精度を整えてから公開します。

調整の途中では、データエージェントを下書き（ドラフト）として保存できます。ドラフトはあとから編集を再開できるため、設定を作り込む間はドラフトのままにし、回答が安定したら公開する、という進め方ができます。

生成 SQL と推論のレビュー

回答精度を保つには、データエージェントが返した答えを鵜呑みにせず、どう導いたかを確かめることが大切です。特に運用を始めた直後は、生成された SQL や考え方を定期的に点検し、誤った解釈がないかを確認します。

Conversational Analytics の画面上では、データエージェントが答えにたどり着くまでの思考のステップをたどったり、実際に生成された SQL とその実行結果を確認したりできます。生成された SQL は、クエリエディタで開いて中身を確かめることもできます。

これらを確認して、意図と異なる列が使われていたり、想定と違う条件で絞り込まれていたりするのを見つけたら、設定を直す手がかりが得られます。たとえば、ある列が繰り返し誤って使われるなら指示で使わないよう伝える、特定の質問でうまく答えられないなら検証済みクエリを足す、といった改善につなげられます。点検と改善を繰り返すことで、回答精度は時間とともに安定していきます。

実践と応用

当記事で紹介する BigQuery Conversational Analytics を使うケースに限らず、AI によるデータ解釈の精度を上げるには、土台となるテーブルやビューのスキーマ設計をクリーンにすることが重要です。以下の記事では、ライオン株式会社様が基幹システムである SAP のデータモデルを、BigQuery からの分析に供するように再設計した試みが紹介されています。