ブログ | XIMIX

Gemini in BigQueryでのクエリ生成精度を上げるには

作成者: XIMIX 江口｜2025.08.25

はじめに

多くの企業がデータ分析基盤としてBigQueryをはじめとするクラウドデータウェアハウス（DWH）を導入しています。しかし、その活用には依然として課題が残ります。
特に、
「分析に必要なデータをすぐに見つけられない」
「SQLの学習コストが高く、一部の専門家しかデータを扱えない」
「テーブルやカラムが英語で命名されており、データの意味を正確に理解するのが難しい」
といった声は、多くの現場で共通する悩みではないでしょうか。

このような課題を解決する一手として、Google Cloudは  Gemini in BigQuery を提供しています。これは、自然言語で指示するだけで、AIが自動でSQLクエリを生成してくれる画期的な機能です。これにより、SQLに不慣れなビジネスユーザーでも、対話形式でデータ分析を進められる可能性が広がりました。

しかし、AIによるクエリ生成は万能ではありません。特に、日本語のような多義的な言語で、英語で定義されたスキーマを持つテーブルを操作する場合、AIがカラムの意味を取り違え、意図しないクエリを生成してしまうこともあります。

本記事では、その課題を解消する方法を検証しましたのでご紹介します。

Gemini in BigQuery とは

Gemini in BigQueryは、Google CloudのDWHであるBigQueryに組み込まれたAIアシスタント機能です。主な機能として、自然言語での問い合わせに対してSQLクエリを生成するSQL生成や、既存のクエリを分かりやすく解説したり、最適化の提案をしたりするSQL支援などがあります。

この機能の最大のメリットは、データアナリストやデータサイエンティストだけでなく、営業、マーケティング担当者といった、これまでSQLを専門としてこなかった職種の人々にもデータ分析の門戸を開く点にあります。分析のアイデアが浮かんでも、SQLが書けずに諦めていたようなシーンで、大きな力を発揮します。

検証：日本語descriptionはクエリ生成精度に影響するか

検証の仮説

英語でカラムが定義されたテーブルに対して、日本語で「〇〇のデータを出して」と指示しても、AIはどのカラムが「〇〇」にあたるのかを正しく判断できない場合があります。

そこで、「BigQueryのテーブルスキーマに設定できるdescription（説明）フィールドに、各カラムが何を表すデータなのかを日本語で記述すれば、AIがカラムの意味を正確に理解し、より精度の高いクエリを生成できるのではないか」という仮説を立てました。

準備したテーブル

この仮説を検証するため、全く同じカラム構成を持ち、descriptionの有無だけが異なる2つのテーブルを準備しました。
  • descriptionなしのテーブル (`gemini_sample_no_desc.sales_data`)
      `id_field` STRING,
      `item_id_int` INTEGER,
      `value1_int` INTEGER,
      `value2_int` INTEGER,
      `value3_int` INTEGER,
      `count_int` INTEGER,
      `is_option_A` BOOL,
      `is_option_B` BOOL,
      `date1` DATE,
      `date2` DATE
  • descriptionありのテーブル (`gemini_sample_with_desc.sales_data`）
     
      `id_field` STRING OPTIONS(description="顧客を識別するID"),
      `item_id_int` INTEGER OPTIONS(description="商品ごとのアイテムID"),
      `value1_int` INTEGER OPTIONS(description="商品ごとの販売価格（税抜）"),
      `value2_int` INTEGER OPTIONS(description="配送料"),
      `value3_int` INTEGER OPTIONS(description="税額"),
      `count_int` INTEGER OPTIONS(description="販売個数"),
      `is_option_A` BOOL OPTIONS(description="配送料無料フラグ（True:無料, False:有料）"),
      `is_option_B` BOOL OPTIONS(description="特別包装フラグ（True:あり, False:なし）"),
      `date1` DATE OPTIONS(description="商品の購入日"),
      `date2` DATE OPTIONS(description="商品の配送日")
今回は商品の注文データを模したテーブルを用意しました。カラム名だけでは役割を推測しにくいよう、あえて抽象的な名称にしています。

準備したデータ

いずれのテーブルにも、以下のデータを投入しました。
'user_001', 101, 15000, 500, 1500, 1, FALSE, FALSE, '2025-08-10', '2025-08-12',
'user_001', 105, 3000, 300, 300, 1, FALSE, TRUE, '2025-08-11', '2025-08-13',
'user_002', 102, 800, 100, 80, 2, TRUE, FALSE, '2025-08-10', '2025-08-11',
'user_003', 103, 2500, 300, 250, 1, FALSE, FALSE, '2025-08-11', '2025-08-13',
'user_004', 102, 600, 100, 60, 3, TRUE, TRUE, '2025-08-11', '2025-08-12',
'user_005', 106, 32000, 1200, 3200, 1, FALSE, FALSE, '2025-08-12', '2025-08-15',
'user_006', 104, 1800, 300, 180, 1, FALSE, TRUE, '2025-08-12', '2025-08-14'

実行結果の比較

準備した2つのテーブルに対し、Gemini in BigQueryに同じ日本語プロンプトを入力し、生成されるSQLの違いを比較します。

検証プロンプト: 「ユーザーごとの支払合計額を計算して。送料がかかる場合は送料も加算して。」
  • descriptionなしのテーブル
    生成クエリ
    -- ユーザーごとの支払合計額を計算して。送料がかかる場合は送料も加算して。
    SELECT
      t0.id_field,
      SUM((t0.value1_int * t0.count_int) + t0.value3_int + t0.value2_int) AS total_payment_amount
    FROM
      `<PJ名>`.`gemini_sample_no_desc`.`sales_data` AS t0
    GROUP BY
      t0.id_field;
    「商品の金額(value1_int) × 個数(count_int)」という基本的な計算や、他の金額項目を足し合わせる点については、正しく解釈できています。
    しかし、`is_option_A`（送料無料フラグ）がTRUEの場合でも、`value2_int`（配送料）を加算してしまっています。
    これは、descriptionがないため、AIが`is_option_A`と`value2_int`の関係性を理解できなかった結果と言えるでしょう。


    user_002, user_004の注文に対して配送料が加算されています

  • descriptionありのテーブル

    -- ユーザーごとの支払合計額を計算して。送料がかかる場合は送料も加算して。
    SELECT
      t0.id_field,
      SUM( (t0.value1_int * t0.count_int) + t0.value3_int +
        CASE
          WHEN t0.is_option_A = FALSE THEN t0.value2_int
          ELSE 0
      END
        ) AS total_payment_amount
    FROM
      `<PJ名>`.`gemini_sample_with_desc`.`sales_data` AS t0
    GROUP BY
    t0.id_field;
    一方こちらは、descriptionの情報を元に「配送料無料フラグ」を正しく解釈し、フラグがFALSEの場合にのみ配送料を加算する、という意図通りのクエリを生成してくれました。
    user_002, user_004の注文に対しては配送料が加算されない結果が取得できました。

まとめ


本検証を通じて、BigQueryテーブルのdescriptionに日本語でカラムの役割やデータの意味を記述しておくことが、Gemini in BigQueryにおける日本語プロンプトの精度を向上させることが明らかになりました。

この取り組みは、以下のような多くのメリットをもたらします。

  • SQLに不慣れなユーザーの分析を強力に支援する
  • データを探す時間や、カラムの意味を問い合わせるコストを削減する
  • AIによる誤ったクエリ生成を防ぎ、分析の正確性を高める
データ基盤を管理するデータエンジニアや、データを活用するアナリストの皆様には、ぜひ管理下のテーブルに適切なdescriptionを追加していくことを強くお勧めします。この少しの手間が、組織全体のデータ活用能力を大きく引き上げるきっかけになるはずです。

Google Cloud、Google Workspace に関するご相談はXIMIXへ！

Google Cloud、Google Workspaceに関する お問い合わせはこちら

 
完全な記事を表示