公開2026.08.17更新2026.09.27 Google Cloud

BigQuery Conversational Analyticsとは：データエージェントの構成とコンテキスト整備で決まる回答精度

BigQuery Conversational Analytics は、BigQuery 上のデータへ自然言語で質問し、生成された SQL の実行結果を表とグラフで返す機能です。BigQuery 側は2026年1月30日にプレビューとして発表され、開発者向けの Conversational Analytics API は2026年6月23日に BigQuery と Looker 向けで一般提供へ移りました。ただし機能を有効にしただけでは、社内の指標名も結合条件も推測した SQL が返ってきます。この記事では、データエージェントを構成する4つのコンテキスト要素、整備の着手順、IAM ロールと課金バイト上限の設計、日本語運用の制約、そして現場へ開放してよい範囲までを2026年8月17日時点の一次情報で整理しました。

まとめ：会話型分析で先に決めるコンテキスト整備の範囲と本番開放の線引き

結論から言えば、この機能の成否はモデル側ではなくコンテキスト側で決まります。テーブルとビューを選んで公開しただけのエージェントは、売上の定義が部署ごとに違う組織では必ず食い違った数字を返します。先に決めるのは3点です。第一に、対象を「定義が固まった指標を持つ数テーブル」に絞ること。第二に、頻出質問を検証済みクエリとして先に登録すること。第三に、big_query_max_billed_bytes と専用プロジェクトでコストの上限を物理的に閉じておくこと。

本番開放の線引きも先に置いてください。定義が確定した指標の照会は開放してよく、定義が揺れている領域と、その数字が社外へ出る用途は開放しません。ダッシュボードは消えません。毎日同じ切り口を見る定常モニタリングは BI に残し、会話型分析には「一度きりの深掘り」を移す、という分担が実務では収まります。以降の章では、その判断に必要な仕組み・設定・制限を順に扱います。

BigQueryの会話型分析が自然言語からSQLを組み立てる仕組みと提供面

まず押さえるのは、同じ「会話型分析」が複数の入口から提供されている点です。入口ごとに設定できる項目と制限が変わります。

BigQuery StudioのAgent Catalogから呼び出す提供面とGA時期

BigQuery 側の入口は Google Cloud コンソールの Agent Catalog タブで、ここで作成したデータエージェントとチャット形式でやり取りします。エクスプローラやクエリ結果画面からの呼び出しにも対応しました。開発者向けには geminidataanalytics.googleapis.com のエンドポイントが用意され、リリースノート上は2026年6月23日に v1 REST エンドポイントと合わせて GA へ移行、Node.js・Java・Go・Python・PHP・Ruby・.NET のSDKが揃っています。Looker と Data Studio からも同じエージェントを参照でき、AlloyDB・Cloud SQL・Spanner は2026年第3四半期時点でプレビュー扱いでした。BigQuery 自体の課金体系や制約はBigQueryとは：サーバーレスDWHの仕組み・料金・できないことと採用判断にまとめてあります。

質問からSQL生成・実行・可視化までの流れと生成SQLの開示

処理はおおむね4段階です。質問の解釈、コンテキストを踏まえた SQL の生成、BigQuery でのクエリ実行、そして結果の要約とグラフ描画。Python とグラフ描画ライブラリを扱うコードインタープリタが同梱され、集計後の加工まで一度に返します。実装者にとって効くのは、生成された SQL と判断の過程が画面上に開示される点でした。返答の数字が合わないときは、質問文ではなく生成 SQL の結合条件とフィルタを見れば原因が切り分けられます。手でクエリを書く従来の流れはBigQueryの使い方：コンソールとbqコマンドの初回操作からクエリ実行までで確認してください。

予測や異常検知に使える10種のAI関数と書き込み系が通らない制限

会話型分析からは BigQuery の AI 関数10種が呼べます。時系列予測の AI.FORECAST（基盤モデル TimesFM を使用）、異常検知の AI.DETECT_ANOMALIES、変化の要因候補を返す AI.KEY_DRIVERS、意味検索系の AI.SEARCH や AI.SIMILARITY などです。「先月の解約が増えた要因は」といった質問が、単なる集計ではなく寄与度の分解として処理されます。一方で制限も明確でした。書き込み操作・DML クエリ・リモート関数は通りません。会話履歴の共有も不可で、エージェントが触れるのは明示的に選んだナレッジソースだけです。読み取り専用の分析窓口、と割り切った設計になっています。

データエージェントの構成要素とコンテキスト整備で回答精度を上げる手順

データエージェントは「ナレッジソース」と「コンテキスト」の組で成り立ちます。精度の議論は、ほぼ後者の作り込み量の話に還元されます。

ナレッジソースの選び方と1エージェント100件という上限の扱い

ナレッジソースに指定できるのはテーブル、ビュー、ユーザー定義関数、Lakehouse のテーブル、そしてグラフです。1エージェントあたり最大100件まで登録できます。ただし上限まで積むのは逆効果でした。候補が増えるほど、似た名前の列を取り違える余地が広がるからです。実務では、部門と指標の単位でエージェントを分け、1つあたり数テーブルから20テーブル程度に収める構成が扱いやすくなります。グラフを使う場合の制約は別で、1エージェントにつきグラフは1つ、しかもテーブルとの併用はできません。生テーブルをそのまま渡すより、結合と粒度を固定したビューを1枚挟むほうが、生成される SQL のばらつきは小さくなります。

カスタムメタデータ・指示・検証済みクエリ・用語集の四つの役割

コンテキストとして与えられるのは次の4種類で、役割が重なりません。

カスタムメタデータ：テーブルと列の説明をエージェント側に持たせる。元テーブルの説明を書き換えずに補足できる
エージェント指示：既定のフィルタ、除外条件、集計時の粒度など、業務ルールを自然文で指定する
検証済みクエリ（旧称ゴールデンクエリ）：質問と正解 SQL の対を登録する。@product のようなパラメータ化にも対応
用語集：社内の呼び名と列の対応を定義する。BigQuery の用語集と Knowledge Catalog のビジネス用語を取り込める

API から扱う場合、これらは system_instruction に YAML 文字列として渡す形になります。構造化コンテキストと同じ内容を YAML 側にも書くと二重定義になるため、どちらで管理するかは最初に決めておいてください。

コンテキスト整備の着手順と検証済みクエリを先に置くという判断基準

着手順は、費用対効果の差がはっきり出ます。まず検証済みクエリ。現場から出る質問は上位10問ほどに集中するため、その正解 SQL を登録するだけで体感精度が変わります。次に用語集と同義語で呼び名を揃え、その後にカスタムメタデータで列の説明を埋め、最後にエージェント指示で「特記のない限り退会済み顧客は除く」といった既定ルールを固定する。逆順は非効率でした。全列の説明を丁寧に書いても、指標の定義そのものが曖昧なら誤答は残ります。判断基準はひとつです。同じ質問に対して人間が書く SQL が2通り以上あるなら、説明文ではなく検証済みクエリで正解を1つに固定してください。

日本語で質問する運用の制約と表記ゆれを吸収するコンテキスト設計

国内案件で最初に確認すべきなのが言語の扱いです。公式の記載と実際の挙動に差があり、そのまま運用設計に響きます。

公式サポート言語が英語のみという記載と日本語入力の実際の扱い

Conversational Analytics API の公式FAQには、正式にサポートする言語は英語のみと明記されています。基盤モデル自体は多言語を解しますが、非英語での動作は保証の対象外という位置づけでした。一方、BigQuery コンソール側の会話型分析については、日本語の質問がそのまま通ったという検証報告が国内の技術ブログで複数出ています。この差をどう扱うか。実務上の答えは「利用者の入力は日本語のままでよいが、コンテキストは英語で書き、日本語の呼び名は同義語として明示的に登録する」です。指示や説明文を日本語だけで用意すると、モデル側の解釈が揺れたときに切り分けができません。

同義語と用語集で部署ごとの呼び名の違いを吸収する設定の注意点

日本語運用の誤答は、多くが表記ゆれで起きます。「売上」「売上高」「受注金額」が別々の列を指す組織は珍しくありません。用語集にはこの対応を1行ずつ書き下します。あわせて、営業部の言う「新規」が初回取引を指すのか当年度の新規契約を指すのかまで定義してください。カタカナと英字の揺れも同じで、customer_id に対して「顧客ID」「カスタマーID」「会員番号」を同義語として並べます。ここを飛ばすと、質問のたびに列の推測が発生し、生成される SQL が毎回変わります。整備の実際の負荷は、テーブル数よりも指標定義の合意形成に持っていかれる、というのが導入時の現実的な見積もりです。

権限とコストの制御：三つのIAMロール分離と課金バイト上限の設計

会話型分析は、権限設計を誤ると「誰でも全社データへ自然言語で聞ける状態」を作ります。ロールと課金の両面で先に閉じてください。

作成・所有・利用で分けるdataAgent系ロールの割り当て方

用意されているロールは3つに分かれています。エージェントを作るのが roles/geminidataanalytics.dataAgentCreator（プロジェクトに付与）、編集と削除ができるのが roles/geminidataanalytics.dataAgentOwner（エージェントまたはプロジェクトに付与）、使うだけなら roles/geminidataanalytics.dataAgentUser です。現場の利用者に配るのは3つ目だけに限定してください。作成権限を配ってしまうと、コンテキスト未整備のエージェントが各所に増え、同じ質問に別々の数字が返る状態を招きます。なお、エージェントが読めるデータの範囲は BigQuery 側の権限にも従うため、行レベル・列レベルのアクセス制御はそのまま効きます。AI クライアント側から接続する場合の権限分離はBigQuery MCPサーバーの接続手順と6ツールの権限分離で整理しました。

big_query_max_billed_bytesで1クエリの上限を決める設定

自然言語での質問は、書き手がスキャン量を意識しません。「全期間の推移を見せて」の一言でパーティションを無視した全走査が走ります。防ぎ方は2段構えです。エージェントのデータソース設定にある big_query_max_billed_bytes で1クエリの課金バイト数に上限を置き、公式ドキュメントの例では 104857600 バイト（100 MiB）が示されています。加えてプロジェクトとユーザー単位の標準的な割り当てを併用します。注意点として、この上限が効くのはオンデマンド課金のプロジェクトのみで、スロット予約を使うプロジェクトには適用されません。オンデマンドと Editions の分岐はBigQueryの料金：オンデマンドとEditionsの分岐点で確認してください。

エージェント単位で費用を追えない前提のプロジェクト分離の設計

コスト管理でつまずくのはここでした。BigQuery のラベルを使ったエージェント単位のコスト追跡はサポートされておらず、エージェント単位の割り当て設定も用意されていません。つまり「営業部のエージェントが今月いくら使ったか」を標準機能だけで切り出せないということです。公式ドキュメントが案内する回避策は単純で、エージェントを専用プロジェクトへ隔離し、プロジェクト単位の割り当てと予算アラートを当てる方式です。請求を部門按分する必要がある案件では、この構成をエージェント設計より先に決めておかないと、後からプロジェクトを分け直す手戻りが発生します。

BIツールとの住み分けと現場へ開放してよい範囲を決める判断基準

ここは言い切ります。会話型分析はダッシュボードの置き換えではありません。役割が違う2つの窓口として設計してください。

ダッシュボードが残る作業と会話型分析へ移してよい作業の切り分け

判断軸は「その質問を何回するか」です。毎朝同じ数字を同じ切り口で見る作業は、定義が固定され、レンダリングも速く、監査もしやすいダッシュボードに残します。会話型分析が効くのは、ダッシュボードを見た後に生まれる一度きりの深掘りです。

観点	BIダッシュボード	会話型分析
向く質問	毎回同じ定常モニタリング	その場限りの深掘り
定義の固定	作成時に固定される	コンテキスト整備に依存
結果の再現性	同じ数字が返る	質問文で揺れる余地あり
準備コスト	画面ごとの実装が必要	指標定義の整備が必要

Google のスタックで組む場合、定常モニタリングの受け皿はLooker Studioとは｜無料BIツールの機能・料金・BigQuery連携と企業導入の判断で扱った構成が現実的で、会話型分析はその隣に置く探索用の窓口という位置づけになります。両方を同じ指標定義に乗せられるかが設計の分かれ目でした。

先に開放してよいのは定義が固まった指標だけという線引きの理由

開放範囲は指標の成熟度で切ってください。売上や受注件数のように定義が確定し、経理や営業管理の数字と突き合わせ済みの領域は、検証済みクエリを登録したうえで開放してよい範囲です。逆に、部署ごとに集計ロジックが違う指標、たとえば「稼働率」「歩留まり」の類は開放しません。もっともらしい数字が返り、しかもそれが誤りだと気づかれないまま会議資料へ載ります。社外へ出す数字、監査対象の数字、契約金額に紐づく数字も同様に対象外とし、人が書いた SQL とレビューを通す経路に固定してください。生成 SQL が画面に出る仕様は便利ですが、それを読める人がいなければ検算の役には立ちません。

導入を見送るべき体制と受託開発側で先に固める設計項目の整理と順序

見送るべき体制ははっきりしています。指標定義が文書化されておらず、同じ数字を複数部署が別ロジックで出している状態。データ基盤がスプレッドシートからの手動投入に依存し、更新日が揃っていない状態。この2つのいずれかに当てはまるなら、エージェントを作る前に定義とパイプラインの整備を先に回すべきです。会話型分析は、整っていないデータの上では誤答の生産性を上げるだけの道具になります。受託開発として入る場合に先に固める順序は、指標定義の棚卸し、ビューによる粒度と結合の固定、検証済みクエリの登録、権限とプロジェクト分離、その後にエージェント公開。この順序を崩すと必ず作り直しになります。指標定義の整備からダッシュボードと会話型分析の併走までを含む設計は、BIツール導入支援で相談を受け付けています。

BigQueryの会話型分析の精度・料金・権限でよくある質問と回答

導入検討と設計の場面で実際に出た質問を、一次情報の記載に沿って整理しました。

BigQuery Conversational Analyticsの利用に追加料金はかかりますか？

公式ドキュメントは、エージェントの作成時と会話時に実行されるクエリについて BigQuery のコンピューティング料金が課金される、と記載しています。エージェント機能そのものの価格体系は Data Cloud Agent Pricing 側にまとまっており、無償枠や試用の扱いは時点で変わるため、請求設計の前に必ず自社の課金モデルで確認してください。実務上の注意は、質問1回あたりのスキャン量が読めない点にあります。big_query_max_billed_bytes の設定を先に入れておくのが安全です。

日本語で質問しても正しく答えてくれますか？

Conversational Analytics API の公式FAQでは、正式にサポートする言語は英語のみと明記されています。BigQuery コンソール側では日本語の質問が通ったという検証報告が国内で複数出ていますが、保証された挙動ではありません。日本語で運用する前提なら、コンテキストは英語で記述し、日本語の指標名や列の呼び名は同義語として用語集に登録する構成にしてください。表記ゆれを吸収する設計を入れておけば、質問文が日本語でも参照先の列が揺れにくくなります。

回答が間違っていたとき、どこから直せばよいですか？

まず生成された SQL を開いて、結合条件・フィルタ・集計単位のどこで意図とずれたかを特定します。列の取り違えなら用語集と同義語、除外条件の抜けならエージェント指示、そもそも組み立て方が違うなら検証済みクエリの登録、という順で対応先が決まります。同じ質問が繰り返し誤答するなら、説明文を足すより検証済みクエリで正解を1本固定するほうが確実でした。パラメータ化した検証済みクエリを使えば、対象商材や地域が変わる質問群も1本でまかなえます。

1つのエージェントにテーブルをいくつまで登録できますか？

ナレッジソースの上限は1エージェントあたり100件です。ただし上限いっぱいまで登録すると、似た名前の列や重複した粒度のテーブルが増え、誤答の余地が広がります。部門や指標のまとまりごとにエージェントを分け、1つあたり数テーブルから20テーブル程度に抑える構成を推奨します。グラフをナレッジソースにする場合は制約が別で、1エージェントにつき1つ、テーブルとの併用は不可です。

既存のダッシュボードは会話型分析に置き換えられますか？

定常モニタリングの置き換えには向きません。毎回同じ切り口で同じ数字を見る用途は、定義が固定され再現性のあるダッシュボードのほうが確実です。会話型分析を入れる価値が出るのは、ダッシュボードでは用意していない切り口を、その場で1回だけ確認したい場面でした。両者を同じ指標定義の上に乗せられるかどうかが、併用がうまくいくかの分かれ目になります。