こんにちは！
KDDIアイレットの取り組みとして、6月22日〜7月3日の期間で開催中の「Google Cloud Next '26 / Google I/O やってみた系ブログリレー」、本日は10日目の投稿です。
今回触ってみたのは、Google Cloud Next '26 で紹介された BigQuery の会話型分析（Conversational Analytics） です。ひとことで言うと、データに自然言語（日本語など）で質問すると、裏で Gemini が SQL を生成し、BigQuery がそれを実行して、集計やグラフで答えてくれる新機能です。
日本語などで質問するだけで分析できる、と聞くと手軽そうですが、実際に何度か試してみると、同じ質問でも生成される SQL が変わることがあり、思ったより奥がありました。料金まわりで気をつけた点も含めて、触ってみた記録を書きました。
前回までの記事はこちらです。
- Managed Agents API の仕組みと使い方：自律型エージェント構築を試してみた
- 【音声生成】Gemini 3.1 Flash TTS は「この先生きのこるには」を正しく読めるのか検証してみた
- NoSQLでJOINする日が来た：Firestore Pipelines API（コレクション間JOIN）を実機で試してみた【Next '26】
使ったもの
- BigQuery（コンソール / BigQuery Studio）※ブラウザだけで完結します
- 公開データセット
bigquery-public-data.noaa_gsod（NOAA が世界中の観測所から収集した気象観測データ。長期間ぶんが入っています）
お題は「東京の月ごとの平均気温」にしました。公開データなので自分でデータを用意する必要もありません。年は、最初は最新の2025年で試したのですが、この時点では年の途中まで（8月分まで）しかデータが無かったので、通年そろっている2024年を使うことにしました。
会話型分析はプレビュー機能です（2026年7月時点）。挙動は今後変わる可能性があります。
料金の注意点
触り始める前に気になったのが料金です。ここは会話型分析ならではの注意点があるので、先に書いておきます。
BigQuery の料金は、基本的にクエリでスキャンしたデータ量で決まります。普段エディタで SQL を書くときは、実行前にスキャン量の見積もりが表示されるので、それを見てから実行できます。
一方、会話型分析の直接会話では、実行前にスキャン量の見積もりを確認する操作が見当たりませんでした。日本語で質問すると、生成された SQL がそのまま実行されます。そのため、対象範囲を意識せずに質問すると、想定より広い範囲をスキャンしてしまい、その分だけ課金額が増えてしまう可能性があります。
対策としては、次の2つが効きます。
-
対象のテーブルを絞る。全期間ではなく
gsod2024（1年分）だけをナレッジソースに指定すれば、スキャン範囲がその年に限定されます - エージェントを作って上限を決める。エージェントを作成すると「最大バイト数（Maximum bytes billed）」を指定でき（10MB 以上）、クエリ実行前の試行実行（Trial Run）で見積もりが上限を超える場合は、実行せずエラーとしてブロックしてくれます
なお、BigQuery には無料枠（月 1TiB）もありますが、大きなテーブルを何度も分析すると消費することがあります。今回のように 1年分の公開データで試すぶんには、費用が大きく膨らむことはありませんでした。
権限でつまずいた
「コンソールをポチポチするだけでしょ」と思っていたら、最初につまずいたのは権限でした。会話を開こうとすると、こんなエラーが出ることがあります。
この機能を使用するには、次の権限が必要です:
cloudaicompanion.topics.create
会話型分析は裏で Gemini（Gemini for Google Cloud）が動くので、BigQuery の権限だけだと足りません。自分の環境では関連 API を有効化したところ利用できるようになりましたが、環境によっては IAM ロールの追加などが必要になる場合もあります。
エラーメッセージに出た権限を足していけば大丈夫です。
共有プロジェクトだと権限を勝手に足しにくいので、検証用に自分のプロジェクトを用意しておくと楽だと思います。
日本語で質問して分析してみる
準備ができたら、あとは日本語で聞くだけです。会話を開いて、ナレッジソースに気温テーブル（gsod2024）を指定して、こう聞きます。
東京の2024年の月ごとの平均気温を教えて
しばらく待つと、ちゃんと返ってきました。
返ってきたのは、月別の平均気温の表と、季節変化の折れ線グラフ、それに気温の傾向をまとめた文章でした。夏に高く冬に低い、見慣れた季節のカーブが出ています。
面白いのは、これがそれらしい文章を返しているだけではなく、実際に SQL が生成されて実データに集計をかけていることです。回答からは、生成された SQL を確認できます。
SELECT
mo AS month,
ROUND(AVG(temp), 1) AS avg_temp_f,
ROUND(AVG((temp - 32) * 5 / 9), 1) AS avg_temp_c
FROM `bigquery-public-data.noaa_gsod.gsod2024`
WHERE stn = '476620'
AND temp != 9999.9
GROUP BY month
ORDER BY month
この SQL は、単に集計するだけでなく、気温を華氏から摂氏へ変換する処理まで自動で含めています。実はこの気象データ、気温はアメリカ式の単位（華氏）で入っているのですが、放っておくと「東京の8月が85度」みたいな数字になるところを、ちゃんと日本でおなじみの摂氏に直してくれているわけです。
「東京」という指定に対して、最終的に stn = '476620' を使った SQL を生成しているのも含め、日本語で聞いただけでこのあたりまで考慮してくれるのは便利です。
……が、何度か聞いているうちに、「あれ？」と思うことが出てきました。
同じ質問でも生成されるSQLは毎回同じではなかった
同じ質問を何回か投げてみたところ、東京の取り方が毎回同じではありませんでした。
あるときは、さっきのように WHERE stn = '476620'（TOKYO の1観測所）で集計していました。ところが別のときは、こうなりました。
WHERE stn IN ('476950', '476620', '476710', '476870')
今度は東京を名乗る観測所4つをまとめて対象にしていました。 同じ質問なのに、生成される SQL が毎回同じとは限らなかったのです。今回表示された思考プロセスでは「"東京"は広く解釈できるので、関連する観測所をまとめて平均するのが妥当だろう」といった判断が記録されていました。前のときは「主要な代表観測所の 476620 が最適」と記録されていたので、判断の記録そのものが変わっていたことになります。
実は、この気象データには「東京」を名乗る観測所が4つあります。自分で stations テーブルを引いてみると、こうでした。
| usaf | name | lat | lon |
|---|---|---|---|
| 476620 | TOKYO | 35.683 | 139.767 |
| 476710 | TOKYO INTL | 35.552 | 139.780 |
| 476870 | TOKYO HELIPORT | 35.633 | 139.850 |
| 476950 | TOKYO/KASHIWA | 35.867 | 139.967 |
476620 の「TOKYO」は緯度経度からして都心（大手町あたり）ですが、他には空港（TOKYO INTL）やヘリポート、名前に KASHIWA（柏）とついた郊外寄りのものまで混じっています。
1観測所だけを使うか、4観測所を平均するかで、結果の数字も変わりました。8月の平均は、1点だと28.9℃、4点平均だと29.8℃ と、対象の観測所が違うぶん 1℃ ほど差が出ています。
どちらが正しいというより、「東京」という曖昧な指定では、対象となる観測所の選ばれ方が変わることがありました。日本語で「東京の気温」と聞くだけだと、対象になる観測所が毎回同じとは限らず、答えの数字も少し変わる。ここは触ってみるまで気づきませんでした。
グラフは毎回出るのか
今回は「グラフを出して」と頼まなくても、毎回グラフが付いてきました。今回表示された思考プロセスでは「時系列データなのでグラフを表示する」といった判断が記録されていて、「明示的にグラフと言われたか」「行数は十分か」「時系列トレンドか」といった条件を確認したうえで表示している様子でした。
裏を返すと、条件次第では出さないこともありそうです（例えばデータが1〜2行しかない、単純な数値比較、など）。確実にグラフが欲しいなら「グラフも出して」と明示するのが無難だと思います。ちなみに、あるときは折れ線、あるときは棒グラフと、グラフの種類も揺れていました。
観測所を指定したら安定した
ここまでで「曖昧に聞くとブレる」ことが分かってきました。では逆に、きちんと指示すれば安定するのか。これが一番知りたかったところです。
観測所を明示して、こう聞いてみました。
観測所476620（TOKYO）における、2024年の月ごとの平均気温を教えて
これを何度か投げたところ、今度は毎回 WHERE stn = '476620' で固定され、結果もぴったり同じになりました。さっきは「東京」の範囲が揺れていたのに、観測所を1つに絞って指示した瞬間、ブレなくなったわけです。
この結果を見て、ちゃんと指定してあげることが大切だとよく分かりました。「東京の気温」のようにふわっと聞くと解釈がブレますが、「観測所476620で」と対象をはっきり指定すれば、毎回同じ答えになる。曖昧さを残さず、こちらの意図を具体的に説明して頼むことが、この機能をうまく使うコツなのだと思います。
高速モードと思考モード
会話型分析には応答モードの切り替えがあります。高速モードと思考モードで挙動が変わるのか、同じ質問で見比べてみました（各2回ずつなので、あくまで参考程度です）。
試行回数は少ないため断定はできませんが、今回試した範囲では、思考モードのほうが、より段階的に候補を調べている様子が思考プロセスから確認できました。stations テーブルを実際に引いて東京の観測所の候補を確認してから選ぶ、といった手順が記録されています。
とはいえ、前の章で見た「東京を1観測所にするか4観測所の平均にするか」というブレは、思考モードでも起きました。なので「思考モードにすれば必ず安定する」とまでは言えなさそうです。試した回数が少ないので、あくまで今回の範囲での印象、くらいに受け取ってください。
まとめ
- 日本語で質問すると、SQL が自動生成・実行され、実データを集計してくれる。 「東京」という指定に対応する観測所コードを使った SQL を生成し、単位を摂氏に直し、グラフまで描く。ここは素直に便利
- 料金は、直接会話だと自分で見積もりを確認できないぶん要注意。 対象テーブルを絞る・エージェントで上限を決める、で守る
- 曖昧に聞くとブレる。 「東京」の範囲が毎回変わって、答えも 1℃ くらいズレることがある
- 絞って指示すれば安定する。 観測所476620を指定すると、毎回同じ結果になった
日本語で質問するだけで、SQL の生成から実行、グラフ化まで行ってくれるのは、とても便利でした。一方で、「東京」のような曖昧な指定では、生成される SQL が毎回同じとは限らないことも分かりました。会話型分析を使うときは、対象を具体的に指定したうえで、生成された SQL もあわせて確認することが、正確な分析につながると感じました。
今回は公開データセットで試しましたが、自社データを分析する場合も同様に、対象を具体的に指定して、生成された SQL を確認することが大切になりそうです。
プレビュー機能なので、これからどう変わっていくかも楽しみです。ここまで読んでいただき、ありがとうございました。