BigQueryのGeminiアシスタントで非エンジニアが自力でSQL分析できるか検証した

はじめに：SQLが書けない人がGeminiで自走できるかという問い

「BigQueryにデータは入った。でもSQLが書けないから、結局いつも誰かに頼んでいる」。中小ECや個人事業の現場でよく聞く話です。月次の売上集計、リピート率、送料の負担感——知りたいことは山ほどあるのに、最後の「SQLを書く」のひと手間で止まってしまう。

最近のBigQueryには、自然言語で質問するとSQLを提案してくれるGeminiのアシスタント機能が載っています。これを使えば、SQLが書けない人でも自力で分析できるのでしょうか。気になったので、実際に「非エンジニアの立場」を想定して検証してみました。結論から言うと、かなりのところまで自走できるが、最後の検算だけは人が担う必要がある、というのが正直なところです。

なお、機能名やUIの細かい位置づけは更新が早い領域です。具体的な操作手順は最新の公式ドキュメントに従ってください。この記事はあくまで「どこまで任せられるか」という体験の共有です。

検証のやり方

特別なことはしていません。誰でも再現できる形にしたかったので、条件をそろえました。

データ: ECを想定した架空の注文テーブル（orders）を1つ用意。order_id / customer_id / order_date / amount / prefecture / channel といった、実店舗でもありがちな列構成にしました。
プレイヤー: SQLを書けない想定で、質問はすべて日本語の話し言葉だけ。自分でSQLを直接書くのは禁止、というルールにしています。
タスク: 中小ECの担当者が実際に知りたそうなことを5つ。

与えたタスクは次の5つです。

先月の売上合計と注文件数を出して
都道府県別の売上トップ10
月ごとの売上推移（直近12か月）
同じ顧客が2回以上買っている割合（リピート率）
初回購入から2回目までの平均日数

1〜3は集計の基本、4〜5は少しひねった「分析っぽい」問い、という配分です。それぞれについて、Geminiが出したSQLをそのまま実行して、結果が妥当かどうかを別途手計算やスプレッドシートで突き合わせました。

注意：以下の「うまくいった/つまずいた」は、あくまで今回の限られたデータと質問での観察です。データの素性やテーブル設計が変われば結果も変わります。自分の環境で必ず確かめてください。

うまくいった点

率直に、想像よりずっと良かったです。

基本集計はほぼ一発

タスク1〜3のような集計は、ほぼ意図どおりのSQLが返ってきました。たとえば「先月の売上合計と注文件数」では、こんな趣旨のSQLが提案されます。

SELECT
  SUM(amount) AS total_sales,
  COUNT(DISTINCT order_id) AS order_count
FROM `project.dataset.orders`
WHERE order_date >= DATE_TRUNC(DATE_SUB(CURRENT_DATE(), INTERVAL 1 MONTH), MONTH)
  AND order_date < DATE_TRUNC(CURRENT_DATE(), MONTH);

「先月」を月初〜月末の範囲にちゃんと展開してくれて、件数も COUNT(DISTINCT order_id) と重複を避けた形になっていました。ここを自力で書こうとすると、SQL初学者は日付の境界でつまずきがちなので、これはありがたいところです。

列名のゆらぎを吸収してくれる

「都道府県」と質問しても、テーブルの prefecture 列をちゃんと拾ってくれました。日本語の言葉と英語の列名の橋渡しは、地味ですが非エンジニアには大きい。「あの列、英語でなんて名前だっけ」を気にせず質問できるのは、心理的なハードルをかなり下げます。

直してほしいところを会話で伝えられる

「金額に税込・税抜が混ざってる気がするから、amount は税込として扱って」のように、追加の前提を後出しで足しても、SQLを書き直してくれました。一回で完璧を狙わず、対話で詰めていけるのは、まさに非エンジニア向きの使い方だと感じます。

つまずいた点

一方で、任せきりにすると危ういところもはっきりありました。

リピート率の「定義」は人が決めるしかない

タスク4「リピート率」で、Geminiが出したのは「2回以上注文した顧客数 ÷ 全顧客数」でした。これは一つの正しい定義です。ですが、ECの現場では「期間内に2回以上」なのか「累計で2回以上」なのか、「キャンセルや返品を含めるか」で数字が大きく変わります。Geminiは妥当な仮定を置いてくれますが、その仮定が自社の定義と一致しているかは、質問した人にしか判断できません。

「平均日数」で件数が静かに減っていた

タスク5「初回購入から2回目までの平均日数」では、SQL自体は動きました。けれど、よく見ると2回目購入がない顧客は自然に集計から外れていました。これは間違いではないのですが、「全顧客のうち、ちゃんと2回目に進んだ人だけの平均」だと気づかずに見ると、数字の意味を取り違えます。母数が静かに減るタイプの落とし穴は、結果の数字だけ見ても気づけません。

列の意味の取り違え

channel 列を「販売チャネル（自社EC・モール等）」のつもりで用意していたのですが、ある質問では集客経路のように解釈したSQLが出てきました。列名だけからは意味が一意に決まらないので、これは仕方ありません。ただ、AIは堂々と間違えるので、結果を鵜呑みにすると静かに誤った数字が出ます。

自走の限界＝AIのSQLは検算が要る

ここが今回いちばん伝えたいところです。

Geminiが出すSQLは「もっともらしく、たいてい正しい」。でも「たいてい」は「いつも」ではありません。とくに集計では、間違っていてもエラーにならずに、それっぽい数字が出てしまうのが怖いところです。構文エラーは気づけますが、定義のズレや母数の減りは、数字だけ眺めても見抜けません。

具体的な検算の手は、難しくありません。

件数を必ず添える。平均や率を出すときは COUNT(*) も一緒に出して、「何件をもとにした数字か」を確認する。
小さく試す。まず特定の1顧客・1か月だけで結果を出し、手で数えられる規模で正しさを確かめてから全体へ広げる。
2通りで出す。可能なら別の聞き方でもう一度出して、数字が一致するかを見る。
定義を言語化して残す。「リピート＝累計2回以上・返品除く」のように、自分の定義を質問文に明記しておく。後から見ても再現できます。

この検算のひと手間を省くと、「自力でSQL分析できた」つもりが「もっともらしい誤りを量産していた」に化けます。逆に言えば、検算さえ習慣にできれば、非エンジニアでもかなり安心して使えます。

まとめ：どこまで任せ、どこを人がやるか

今回の検証で見えた線引きは、シンプルです。

AIに任せてよい：SQLの文法、日付計算、列名の橋渡し、基本的な集計の組み立て。ここは明確に速くなります。
人がやるべき：分析の「定義」を決めること、結果が妥当かの検算、列や数字の意味の最終判断。ここはまだ任せきれません。

つまり、Geminiのアシスタントは「SQLが書けない」という壁はかなり下げてくれますが、「分析が分かる」を肩代わりはしてくれない、ということです。書けないから頼んでいた人にとっては、自分で試せる範囲が一気に広がる良い道具だと感じました。一方で、出てきた数字を経営判断に使うなら、検算の習慣はセットで必要です。

このあたりの「自然言語からSQL」の仕組みそのものは別記事で整理しています。あわせて、AIエージェントを使ってBigQueryを触る話も書いていますので、合わせて読むと立体的になるはずです。

仕組みの整理：BigQueryのGeminiで自然言語からSQLを書く
別アプローチ：非エンジニアのEC事業者がClaude CodeでBigQueryを触ってみた

道具は十分に賢くなりました。あとは「どこを自分で確かめるか」を決めておくこと。これが、非エンジニアがデータと付き合ううえでの、いちばん大事な準備かもしれません。