✨BigQueryから直接Geminiを呼び出してテキストを分析する（AI.GENERATE）

はじめに：大量のテキストをSQLで分析したい

中小ECを運営していると、自由記述のテキストがどんどん溜まっていきます。商品レビュー、問い合わせフォームの内容、アンケートの自由回答、SNSのコメント——どれも宝の山なのですが、量が多すぎて読み切れません。

「全部に目を通してポジティブ・ネガティブを分けたい」「要点だけ短くまとめたい」と思っても、人手では到底追いつかない。かといって、専用のツールを別途契約するのも腰が重い。

そんなときに役立つのが、BigQueryのSQLから直接Geminiを呼び出して、テーブルの中のテキストをまとめて分析するやり方です。データを別の場所に移したり、Pythonで連携スクリプトを書いたりしなくても、いつものクエリの延長で「このレビュー列を全部ポジ・ネガ分類して」といった処理ができます。

この記事では、その仕組みの概要と、感情分類・要約での使いどころ、そしてコスト面の注意点を、できるだけかみくだいて解説します。

⚠️ 注意 BigQueryのAI関数は、関数の名称や引数の構文が版によって変わります（AI.GENERATE か ML.GENERATE_TEXT か、引数の名前や形など）。この記事のSQLは「考え方を示すイメージ」として読んでください。実際に書くときは、必ず最新の公式ドキュメントで正確な関数名と構文を確認してください。

なお、課金の仕組みは Gemini in BigQueryの料金体系を完全解説 で、自然言語からSQLを書く機能そのものは Gemini in BigQueryで自然言語からSQLを書く（2026年版） で、それぞれ詳しく扱っています。あわせて読むと全体像がつかみやすいはずです。

---

仕組みの全体像：モデルへの接続

まず押さえておきたいのは、BigQueryからGeminiを呼び出すには「モデルへの接続」をひと手間用意する必要があるという点です。SQLを書けばいきなりAIが動くわけではありません。

大まかな流れは次の3ステップです。

1. 接続（コネクション）を作る — BigQueryからGoogle CloudのAIサービス（Vertex AI上のGeminiなど）を呼び出すための「通り道」を用意します。
2. リモートモデルを作る — その通り道を使って「このGeminiモデルを使います」という定義を、BigQueryのデータセット内にオブジェクトとして登録します。
3. そのモデルを関数から指定する — 実際にテキストを処理するSQLで、登録したモデルを指定して呼び出します。

リモートモデルの作成は、概念としては次のような形になります。

-- ※構文・引数はイメージです。最新の公式ドキュメントを必ず確認してください
CREATE OR REPLACE MODEL `myproject.mydataset.gemini_model`
REMOTE WITH CONNECTION `myproject.us.my_connection`
OPTIONS (
  endpoint = 'gemini-xxx'   -- 利用するモデルの指定（名称は公式ドキュメント参照）
);

💡 補足 接続を作る際には、その接続が使う「サービスアカウント」に対して、AIサービスを呼び出す権限を付与する必要があります。ここでつまずく人が多いので、権限まわりは公式の手順どおりに進めるのが安全です。一度作ってしまえば、以降は使い回せます。

一度モデルを登録しておけば、あとはそれを指す形で何度でも呼び出せます。最初のセットアップだけ少し手間ですが、ここを越えれば「SQLでAI」がぐっと身近になります。

---

テキストを処理するSQLの例

接続とモデルの準備ができたら、いよいよテーブルの中のテキストをGeminiに渡します。ここでは、ECの商品レビューを格納した reviews テーブルを想定します。

列名	内容
review_id	レビューの識別子
product_name	商品名
review_text	レビュー本文（自由記述）

有効な入力の形：テーブルを丸ごと渡す

AI関数の使いどころは、「1件ずつ手で投げる」のではなく、テーブルの行をまとめて処理できるところにあります。基本の発想は「テキスト列を含むテーブル（やサブクエリ）を入力にして、各行ごとにGeminiの結果が1列ぶら下がる」という形です。

-- ※関数名・引数はイメージです。最新の公式ドキュメントで正確な構文を確認してください
SELECT
  review_id,
  product_name,
  review_text,
  ml_generate_text_result AS ai_output   -- 出力列の名前も版によって異なります
FROM
  ML.GENERATE_TEXT(
    MODEL `myproject.mydataset.gemini_model`,
    (
      -- ここが「入力テーブル」。prompt 列を作って各行に渡すのがポイント
      SELECT
        review_id,
        product_name,
        review_text,
        CONCAT(
          '次のレビューを分析してください。\n',
          'レビュー本文: ', review_text
        ) AS prompt
      FROM `myproject.mydataset.reviews`
    ),
    STRUCT(
      0.0 AS temperature   -- 分類など「ブレてほしくない」用途では低めに
    )
  );

ポイントは、入力となるサブクエリの中で prompt 列を組み立てているところです。各行のテキストに「何をしてほしいか」の指示を結合し、その1列を行ごとにGeminiへ渡す、というのが基本の形になります。

💡 補足 いきなり全件に流すのではなく、まずは LIMIT 10 などで少数の行だけ試すのが鉄則です。プロンプトの書き方で結果の質も費用も変わるので、小さく試して納得してから全件に広げましょう。

---

活用例①：感情分類（ポジ・ネガ判定）

レビューや問い合わせを「ポジティブ／ネガティブ／どちらでもない」に仕分けたい、というのは最も需要の多い使い方です。プロンプトで出力の形を縛ってあげると、後段で集計しやすくなります。

-- ※構文はイメージ。正確な関数名・引数は公式ドキュメントを確認してください
SELECT
  product_name,
  ai_output
FROM
  ML.GENERATE_TEXT(
    MODEL `myproject.mydataset.gemini_model`,
    (
      SELECT
        product_name,
        CONCAT(
          '次のレビューの感情を判定してください。',
          'positive / negative / neutral のいずれか一語だけで答えてください。\n',
          'レビュー: ', review_text
        ) AS prompt
      FROM `myproject.mydataset.reviews`
    ),
    STRUCT(0.0 AS temperature)
  );

コツは、「positive / negative / neutral の一語だけで答えて」と出力の形式を厳しく指定することです。こうしておけば、結果をそのまま GROUP BY で集計して「商品ごとのネガティブ率」を出す、といった分析につなげられます。

💡 補足 AIの出力は、指示しても余計な前置きが混ざることがあります。後段で LOWER() や文字列の含み判定を使って表記ゆれを吸収するか、出力をJSON形式で返させて構造化する方法を検討すると、集計が安定します。

---

活用例②：要約

長い問い合わせ文やレビューを「ひとことで要約」させるのも実用的です。サポート担当が全文を読まなくても、要点を一覧でつかめるようになります。

-- ※構文はイメージ。正確な関数名・引数は公式ドキュメントを確認してください
SELECT
  review_id,
  ai_output AS summary
FROM
  ML.GENERATE_TEXT(
    MODEL `myproject.mydataset.gemini_model`,
    (
      SELECT
        review_id,
        CONCAT(
          '次のレビューを、要点を40字以内の日本語1文で要約してください。\n',
          'レビュー: ', review_text
        ) AS prompt
      FROM `myproject.mydataset.reviews`
      WHERE LENGTH(review_text) > 100   -- 長文だけを対象に絞る
    ),
    STRUCT(0.2 AS temperature)
  );

要約のように「多少の言い回しの自由度があってよい」用途では、temperature を少し上げても構いません。一方、分類のように「決まった答えに寄せたい」用途では低めにする、と使い分けるのがおすすめです。

このほか、レビューから「言及されている要望キーワードの抽出」「不満点のカテゴリ分け」など、応用の幅は広いです。やりたいことをプロンプトの日本語で書き換えるだけで、同じ枠組みのまま対応できます。

---

コストと注意点

便利な反面、従量課金が積み上がりやすい機能なので、ここはしっかり押さえておきましょう。

トークン量に比例して費用がかかる

AI関数は、処理したトークン量（入力＋出力の文字量に相当）に応じて課金されます。100件なら小さくても、10万件のレビューを一括で要約させると、件数に比例して費用が膨らみます。

具体的な単価は変動するため、ここでは金額を示しません。料金はあくまで目安として、必ずGoogle Cloudの公式の最新料金ページで確認してください。課金の発生ポイントは Gemini in BigQueryの料金体系を完全解説 でも整理しています。

「うっかり全件」を防ぐ

一番怖いのは、テスト中に LIMIT を外したまま巨大テーブルに流してしまう事故です。次の習慣で防げます。

• まず LIMIT 10 などで少数を試し、結果と費用感を確認する
• WHERE で対象を絞る（期間・商品・文字数など）
• 一度処理した結果はテーブルに保存し、同じテキストを何度もAIに投げ直さない

⚠️ 注意 AIに投げるテキストには、個人情報（氏名・住所・電話番号・メールアドレスなど）が含まれていないか必ず確認してください。問い合わせ文やレビューにはこうした情報が混じりがちです。社内のデータ取り扱いルールや、利用するサービスの規約を踏まえて、扱ってよい範囲で使うようにしましょう。

結果は鵜呑みにしない

AIの分類や要約は便利ですが、必ず間違いが混じります。特に感情分類は、皮肉や微妙なニュアンスを取り違えることがあります。重要な判断に使う前には、いくつかサンプルを人の目で検算する——この最後のひと手間は省かないのが安全です。

---

まとめ

BigQueryから直接Geminiを呼び出せば、レビューや問い合わせといった大量の自由記述テキストを、いつものSQLの延長で感情分類・要約できるようになります。データを移さず、別ツールも増やさずに済むのは大きな利点です。

一方で、関数名や構文は更新が早く、費用も件数に比例して積み上がります。「構文は公式ドキュメントで確認」「小さく試してから全件」「個人情報に注意」「結果は検算する」——この4点を守れば、中小ECでも安全に活用できるはずです。まずは手元の数十件で、小さく試してみてください。