🤖Gemini in BigQueryで自然言語からSQLを生成する実践ガイド【2026年版】

はじめに

GA4のデータをBigQuery（以下BQ）に流し込んだものの、「で、ここから何を見ればいいんだっけ？」で止まっている。そんなEC担当の方は多いのではないでしょうか。

BQには売上もアクセスも全部入っています。でも、それを引き出すにはSQLという言語を書く必要があります。SQLが書けないと、せっかくの宝の山も「眺めるだけのデータベース」になってしまう。これが多くの中小ECで起きている「BQの持ち腐れ」です。

そこで頼れるのが Gemini in BigQuery です。BigQuery Studio に組み込まれたAIアシスタントで、「先月の購入者数を商品別に出して」のような日本語の指示から、SQLを下書きしてくれます。

この記事では、SQLが苦手なEC担当・経営者の方を想定して、

• Geminiで自然言語からSQLを生成する流れ
• 精度を上げる頼み方のコツ
• そして何より「AIが書いたSQLは必ず検算する」という大前提

を、実例つきで解説します。

💡 補足

この記事は2026年1月時点の一般的な機能を前提にしています。Gemini in BigQuery はアップデートが速く、UIやメニュー名、対応リージョンは変わります。具体的な有効化手順や対応範囲は、必ず最新の公式ドキュメントを確認してください。

---

有効化と前提

Gemini in BigQuery を使うには、Google Cloud のプロジェクトでいくつか準備が必要です。

項目	内容
作業画面	BigQuery Studio（Google Cloud コンソール内のBQ画面）
有効化	プロジェクトで Gemini（AIアシスト）機能を有効にする
API/サービス	関連APIの有効化が必要な場合あり
権限（IAM）	Geminiを使うためのロール付与が必要な場合あり
課金	Gemini利用や生成クエリの実行に応じた料金が発生しうる

重要なのは、これらの設定項目とロール名は頻繁に変わるという点です。「このAPIを有効化」「このロールを付与」と具体名を覚えるよりも、**「最新の公式手順に従う」**と割り切るのが安全です。

⚠️ 注意

Geminiの利用や、生成されたクエリの実行にはコストがかかる場合があります。「AIに聞くだけ」でも課金対象になりうるので、本番運用の前に料金体系を確認しておきましょう。後述の dry_run（試算）も合わせて使うと安心です。

設定まわりでつまずいた場合は、無理に自己流で進めず、わかる人に整備してもらうのが結局は早道です。非エンジニアの方がどこまで自走できるかについては、非エンジニアEC経営者がClaude Code×BigQueryで自走する記事 も参考になります。

---

基本の使い方

Gemini in BigQuery の使い方は、大きく3つです。

1. 自然言語からSQLを生成する

BigQuery Studio のクエリエディタで、やりたいことを日本語で書くと、GeminiがそれをもとにSQLを提案してくれます。

たとえばGA4のエクスポートデータ（events_* テーブル）を対象に、こんなプロンプトを試してみましょう。

プロンプト例①：直近のpurchaseイベントを集計したい

直近30日のpurchaseイベントについて、日別の購入件数と合計購入金額を出したい

生成されるSQLのイメージは次のようなものです。

SELECT
  PARSE_DATE('%Y%m%d', event_date) AS purchase_date,
  COUNT(*) AS purchase_count,
  SUM(
    (SELECT value.double_value
     FROM UNNEST(event_params)
     WHERE key = 'value')
  ) AS total_revenue
FROM
  `your_project.analytics_XXXXXX.events_*`
WHERE
  event_name = 'purchase'
  AND _TABLE_SUFFIX BETWEEN
    FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY))
    AND FORMAT_DATE('%Y%m%d', CURRENT_DATE())
GROUP BY purchase_date
ORDER BY purchase_date;

GA4特有の「event_params がネストされている」「日付がテーブルサフィックスに入っている」といった面倒な部分も、それなりに汲んでくれます。

プロンプト例②：チャネル別のセッション数

流入チャネル別にセッション数を多い順に出して

SELECT
  traffic_source.medium AS medium,
  COUNT(DISTINCT
    CONCAT(
      user_pseudo_id,
      (SELECT value.int_value
       FROM UNNEST(event_params)
       WHERE key = 'ga_session_id')
    )
  ) AS sessions
FROM
  `your_project.analytics_XXXXXX.events_*`
GROUP BY medium
ORDER BY sessions DESC;

プロンプト例③：リピート購入率

期間内に2回以上purchaseしたユーザーの割合（リピート率）を出して

WITH user_purchases AS (
  SELECT
    user_pseudo_id,
    COUNT(*) AS purchase_count
  FROM `your_project.analytics_XXXXXX.events_*`
  WHERE event_name = 'purchase'
  GROUP BY user_pseudo_id
)
SELECT
  COUNTIF(purchase_count >= 2) AS repeat_users,
  COUNT(*) AS total_buyers,
  SAFE_DIVIDE(COUNTIF(purchase_count >= 2), COUNT(*)) AS repeat_rate
FROM user_purchases;

このあたりは、ゼロから書くと地味に時間がかかるクエリです。「下書き」として出してもらえるだけで、作業時間は大きく変わります。

2. 生成されたSQLを説明してもらう

Geminiは「SQLを書く」だけでなく「書いてあるSQLを日本語で説明する」こともできます。

人から引き継いだクエリや、過去の自分が書いたクエリを開いて、「このクエリは何をしている？」と聞けば、ステップごとに解説してくれます。SQLを読む力がない段階でも、中身を把握できるのは大きな利点です。

3. エラーを対話で直す

クエリを実行してエラーが出たとき、エラー内容をGeminiに渡して「直して」と頼めます。

たとえば「value カラムが見つからない」「型が合わない」といったよくあるエラーは、対話を数往復するうちに直ることが多いです。「エラー文を読んでも意味がわからない」という壁を、Geminiが下げてくれます。

---

精度を上げるコツ

Geminiは賢いですが、こちらの出し方しだいで精度は大きく変わります。ポイントは3つです。

コツ1：テーブルとカラムの文脈を与える

「売上を出して」だけだと、Geminiはどのテーブルの何を売上とみなすか分かりません。

• ❌「売上を出して」
• ⭕「analytics_XXXXXX.events_* の purchase イベントの event_params の value を売上として、日別で出して」

対象テーブル名・カラム名・「何を指標とみなすか」を明示するだけで、的中率が上がります。

コツ2：スキーマ（列の構成）を示す

GA4のようにネストが深いテーブルでは、列の構成（スキーマ）をある程度伝えると精度が安定します。「event_params は key と value のネスト構造」と一言添えるだけでも変わります。可能なら、対象テーブルをエディタで開いた状態で頼むと、文脈を拾ってくれやすくなります。

コツ3：一発で全部頼まず、段階的に頼む

複雑な集計を一度のプロンプトで完璧に出させるのは難しいものです。

1. まず「purchaseイベントを日別にカウント」だけ出す
2. 次に「これに売上金額の合計を足して」
3. さらに「チャネル別に分けて」

というように、小さく頼んで積み上げるほうが、結果として速く・正確になります。

💡 補足

AIへの頼み方そのもの（指標の言語化、段階的な依頼）は、Geminiでも Claude でも共通のコツです。3大AIのデータ分析での得意・不得意を整理したChatGPT・Claude・Geminiのデータ分析力を比較した記事 も、ツール選びの参考になります。

---

注意：AIが書いたSQLは必ず検算する

ここが、この記事でいちばん伝えたいところです。

⚠️ 注意

Geminiが生成したSQLは、**「それらしく動くが、意図とは微妙に違う」**ことがあります。エラーなく実行できて、数字も出てくる。でもその数字が正しいとは限りません。SQLは「間違っていても止まらず、間違った数字を返す」のが怖いところです。生成されたSQLは必ず人間が検算してから経営判断に使ってください。

特にGA4のデータでは、次のようなズレが起きがちです。

よくあるズレ	内容
セッションの数え方	user_pseudo_id と ga_session_id の組み合わせ漏れで二重カウント
重複イベント	同一purchaseが複数回記録されているのに DISTINCT していない
期間のズレ	タイムゾーン（UTC/JST）の考慮漏れで1日ぶんずれる
NULLや欠損	チャネル名が空のレコードを無視/集計してしまう

検算の最低ラインとして、次の3つはやっておきたいところです。

1. 小さい期間で答え合わせ：1日だけに絞って、管理画面など別ソースの数字と突き合わせる
2. 件数を見る：COUNT(*) で、想定とかけ離れた件数になっていないか確認する
3. コストを試算する（dry_run）：本番実行の前に、スキャン量を見積もる

dry_run は、クエリを実際に走らせずに「このクエリは何GBスキャンするか」を確認する機能です。BQはスキャン量で課金されるため、巨大なテーブルにうっかり全期間クエリを投げて高額請求、という事故を防げます。コマンドラインなら次のように確認できます。

bq query --use_legacy_sql=false --dry_run \
'SELECT COUNT(*) FROM `your_project.analytics_XXXXXX.events_*`'

「AIが書いてくれたから安心」ではなく、「AIが下書き、人間が検算」。この役割分担が、データを使った意思決定の土台になります。

---

他のアプローチとの住み分け

自然言語からSQLや分析にたどり着く方法は、Gemini in BigQuery だけではありません。ざっくり住み分けると次のようになります。

アプローチ	向いている場面
Gemini in BigQuery	BQの画面の中で完結したい。単発のSQL下書き・説明・エラー修正
Claude Code / MCP × BigQuery	チャットで「聞くだけ」で分析させたい。複数クエリをまたぐ調査や仕組み化
自分でSQLを書く	定型レポートを正確に固める。検算済みのクエリを資産として残す

Gemini は「BQの画面で、その場でちょっと助けてほしい」ときに強いです。一方、**「日本語でチャットするだけで分析を回す仕組み」**を作りたいなら、MCP（Model Context Protocol）でBigQueryとClaude Codeをつなぐアプローチが向いています。

このあたりは、聞くだけで分析できる社内ツールをMCP×BigQuery×Claude Codeで作った記事 で具体的に紹介しています。「単発で助かる」のがGemini、「仕組みとして自走させる」のがMCP、というイメージで使い分けるとよいでしょう。

---

まとめ

Gemini in BigQuery を使うと、SQLが苦手なEC担当でも次のことができます。

• 日本語の指示からSQLを下書きできる（purchase集計・チャネル別・リピート率など）
• 既存SQLを日本語で説明してもらえる
• エラーを対話で修正できる
• テーブル名・カラム名・スキーマを明示し、段階的に頼むと精度が上がる

ただし、忘れてはいけない大前提があります。

• AIが書いたSQLは必ず検算する（動く ≠ 正しい）
• 本番実行の前に dry_run でコストを試算する

「SQLが書けないからBQに手が出せない」という壁は、Geminiでだいぶ低くなりました。まずは小さなプロンプトから試して、出てきた数字を別ソースと突き合わせてみてください。その一歩が、眠っているデータを動かす最初の一歩になります。