AI

BigQuery AI.GENERATEの使い方:SQLでGeminiを呼ぶ構文とトークンクォータによるコスト管理【2026年10月時点】

BigQuery AI.GENERATEの使い方:SQLでGeminiを呼ぶ構文とトークンクォータによるコスト管理【2026年10月時点】

BigQueryのAI.GENERATEは、SQLの中からGeminiを呼び出し、行ごとに要約・翻訳・情報抽出の結果を返す関数です。問い合わせ本文やレビューをテーブルに持っていれば、Pythonのバッチを書かずに1本のクエリで処理できます。2026年10月15日には、生成AI関数のトークン消費を1日単位で止める日次クォータが一般提供になりました。この記事では、権限の準備から要約・構造化抽出のSQL、東京リージョンで決まるエンドポイントの扱い、AI.COUNT_TOKENSでの見積もりとクォータの決め方までを、2026年10月16日時点の公式ドキュメントに沿って説明します。

まとめ:AI.GENERATEはSQLだけでGeminiを呼べるが本番前にトークン上限を決める

試すだけなら、2つのロールを付けてAI.GENERATE(CONCAT('指示文', 列名)).resultと書けば動きます。接続(コネクション)の作成は必須ではなく、実行したユーザー自身の認証情報で呼び出せます。

本番に入れる前に決めるべきことは2つです。1つ目は、推論する行をあらかじめテーブルに確定させてから関数を呼ぶこと。JOINやORDER BY ... LIMITを含むクエリでは、想定より多くの行がモデルに送られることがあるためです。2つ目は、日次トークンクォータをプロジェクト単位とユーザー単位で下げておくこと。既定値は入力2,000億トークンと非常に大きく、何もしなければ実質的な上限になりません。

東京リージョンのデータセットから既定の指定で呼ぶと、処理はglobalエンドポイントへ送られ、どの地域で処理されたかは指定も確認もできません。データの処理地域を契約や社内規程で縛っている案件では、この点を先に確認してください。

AI.GENERATEとAI.IF・AI.CLASSIFYの用途と戻り値の違い

BigQueryの生成AI関数の概要ページは、関数を「汎用」「マネージド」「ユーティリティ」に分けています。AI.GENERATEは汎用関数の中心で、モデル・プロンプト・パラメータをすべて利用者が決める位置づけです。

AI.GENERATEが返す3項目の役割と文字列・ファイルの入力方法

AI.GENERATEのリファレンスによると、戻り値は行ごとのSTRUCTです。resultに生成テキスト、full_responseにモデルの応答JSON全体、statusにAPIの応答状態が入り、成功した行のstatusは空文字になります。安全性フィルタに掛かった行や失敗した行ではresultがNULLです。

入力は文字列だけではありません。Cloud Storage上の画像・音声・PDF・動画をOBJ.MAKE_REFで参照し、指示文と組み合わせたSTRUCTとして渡せます。動画は1入力につき1本までで、2分を超える部分は読まれません。2026年10月16日時点のリファレンスにプレビューの表記はなく、一般提供の扱いです。

汎用関数とマネージド関数で異なるモデル選択と行ごとの失敗時の返り方

関数 戻り値 モデルの指定を省いたとき 主な用途
AI.GENERATE STRUCT(生成値・応答全体・状態) gemini-3.5-flash-lite 要約・翻訳・構造化抽出
AI.IF BOOL 処理内容に応じてBigQueryが選ぶ WHERE句やJOINでの絞り込み
AI.CLASSIFY STRING 処理内容に応じてBigQueryが選ぶ 決めたカテゴリへの振り分け
AI.SCORE FLOAT64 処理内容に応じてBigQueryが選ぶ ORDER BYでの順位付け
AI.COUNT_TOKENS STRUCT(計数値・応答全体) AI.GENERATEの既定モデル 入力トークン数の見積もり

使い分けの軸は、戻り値の形と失敗の見え方です。表の生成値はresult、応答全体はfull_response、状態はstatusを表し、AI.COUNT_TOKENSの計数値もresultに入ります。マネージド関数はBOOLや文字列だけを返し、行ごとのstatusを持ちません。代わりにAI.IFのリファレンスにあるmax_error_ratioで、失敗した行の割合が上限を超えたらクエリ全体を止められます。既定値は1.0で、全行が失敗しない限り止まりません。出力の形を自分で決めたいならAI.GENERATE、「該当するか」「どの分類か」だけ欲しいならマネージド関数、と分けて考えます。

権限付与からAI.GENERATEで要約・構造化抽出を動かすまでの手順

例として、問い合わせ本文を持つmyproject.support.inquiriesテーブルを使います。

GRANT文で生成AI関数の実行ユーザーに必要な2つのロールを付与する準備

生成AI関数の権限設定ページでは、多くの場合は接続を作らず、実行ユーザーの認証情報で動かせるとしています。必要なロールはAgent Platform UserとBigQuery Job Userの2つで、プロジェクトのオーナーなら追加の作業は要りません。

GRANT `roles/aiplatform.user`, `roles/bigquery.jobUser`
ON PROJECT `myproject`
TO "group:GROUP_EMAIL";

GROUP_EMAILは対象グループのメールアドレスに置き換えます。Vertex AIは「Gemini Enterprise Agent Platform」へ改称されており、ドキュメント上のロール名も「Agent Platform User」に変わりましたが、ロールIDはroles/aiplatform.userのままです。改称の経緯はGemini Enterprise Agent Platformへの改称後の全体像で整理しています。48時間以上かかる見込みのジョブだけは、接続を作成してconnection_idに指定するよう案内されています。

問い合わせ本文をAI.GENERATEで1文に要約し失敗行をstatusで拾うSQL

推論する行を先にテーブルへ書き出し、その表に対して関数を呼ぶ2段構えにします。理由は後半の章で説明します。

-- 1. 推論対象の行を確定させる(ここで件数が決まる)
CREATE OR REPLACE TABLE `myproject.support.inquiry_target` AS
SELECT inquiry_id, body
FROM `myproject.support.inquiries`
WHERE received_at >= '2026-10-01'
  AND body IS NOT NULL
LIMIT 1000;

-- 2. 確定した表だけをGeminiに送る
CREATE OR REPLACE TABLE `myproject.support.inquiry_summary` AS
SELECT
  inquiry_id,
  AI.GENERATE(
    CONCAT('次の問い合わせを日本語で1文に要約してください: ', body)
  ).* EXCEPT (full_response)
FROM `myproject.support.inquiry_target`;

-- 3. 失敗した行を確認する
SELECT inquiry_id, status
FROM `myproject.support.inquiry_summary`
WHERE status != '';

.* EXCEPT (full_response)と書くと、resultとstatusの2列に展開されます。応答JSONの全体は容量が大きいので、調査が必要なときだけ残すのが扱いやすい形です。3の確認クエリは、後述するクォータ到達の検出にもそのまま使えます。

output_schemaで問い合わせを種別・緊急度の列に分解する構造化抽出

output_schemaを指定すると、resultの代わりに指定した列が返ります。型はSTRING・INT64・FLOAT64・BOOL・ARRAY・STRUCTが使え、OPTIONSで説明や許容値を付けられます。

SELECT
  inquiry_id,
  AI.GENERATE(
    CONCAT('次の問い合わせを分析してください: ', body),
    output_schema => '''
      category STRING OPTIONS(`enum` = ['請求', '不具合', '解約', 'その他']),
      urgency INT64 OPTIONS(description = '緊急度。1が低く5が高い'),
      product_names ARRAY<STRING>
    '''
  ).* EXCEPT (full_response)
FROM `myproject.support.inquiry_target`;

enumは予約語なので、リファレンスの例と同じくバッククォートで囲みます。本文に該当する情報が無い列はNULLになりえるため、必ず値が欲しい列にはNOT NULLを付けて「不明」などの推定値を返させます。自由記述を集計できる列に変える用途では、この書き方がAI.GENERATEの一番の使いどころです。

東京リージョンで実行するときのエンドポイントと既定モデルの扱い

モデルの選び方は、料金だけでなくデータの処理地域にも関わります。

既定のgemini-3.5-flash-liteと東京で選ばれるglobalの送り先

endpointを省くと、2026年10月16日時点ではgemini-3.5-flash-liteが使われます。リファレンスに載っている対応モデルはgemini-4-argonからgemini-3.1-flash-liteまでの7種類で、いずれも地域ごとのエンドポイントには対応せず、マルチリージョンのみです。

短いモデル名で指定したときの送り先は、クエリの実行場所で決まります。USの各リージョンならus、EUの各リージョン(europe-west2・europe-west6を除く)ならeu、それ以外はglobalです。東京(asia-northeast1)や大阪のデータセットはglobalに該当します。リファレンスは、globalエンドポイントでは処理される地域を制御も把握もできないため、処理地域に要件がある場合は使わないよう注記しています。個人情報や機密を含む列を送る設計では、この仕様を前提に社内の承認を取ってから進めてください。

model_paramsで思考レベルと出力上限を絞りトークンを抑える指定

Gemini 2.5以降のモデルは、回答前の「思考」にもトークン課金が発生します。要約や分類のように深い推論が要らない処理は、model_paramsで思考レベルと出力の長さを絞ります。

SELECT
  inquiry_id,
  AI.GENERATE(
    CONCAT('次の問い合わせを日本語で1文に要約してください: ', body),
    endpoint => 'gemini-3.5-flash-lite',
    model_params => JSON '''{
      "generation_config": {
        "max_output_tokens": 128,
        "thinking_config": {"thinking_level": "LOW"}
      }
    }'''
  ).result AS summary
FROM `myproject.support.inquiry_target`;

model_paramsにはgenerateContentのリクエスト本文の形で、contents以外の項目を書けます。Gemini 3.0以降ではthinking_levelがthinking_budgetに代わる指定です。出力トークンは入力より単価が高いため、上限を付けるだけでも費用の振れ幅が小さくなります。

AI.COUNT_TOKENSと日次トークンクォータで生成AIの課金上限を決める手順

2026年10月15日のGoogle Cloud公式ブログは、トークン単位のコスト管理が一般提供になったことを伝えています。測る、上限を置く、上限到達を検出する、の順に組み立てます。

AI.COUNT_TOKENSで入力トークンを事前に見積もるSQLと下限値の注意

SELECT
  COUNT(*) AS row_count,
  SUM(
    AI.COUNT_TOKENS(
      CONCAT('次の問い合わせを日本語で1文に要約してください: ', body),
      endpoint => 'gemini-3.5-flash-lite'
    ).result
  ) AS total_input_tokens
FROM `myproject.support.inquiry_target`;

AI.COUNT_TOKENSのリファレンスによると、数え方はモデルのトークナイザに従い、計算はBigQuery内で行われるためAgent Platform側の課金は発生しません。2026年10月16日時点ではプレビューの関数です。

この値は下限です。出力と思考のトークン、各関数が内部で足す指示文、画像などテキスト以外の入力は含まれません。実際の消費量は、少量で一度流したあとにクエリ結果の[ジョブ情報]タブで確認し、出力側の比率を掴んでから全件に広げます。

4種類の日次トークンクォータの既定値と変更に必要なIAMロール

トークンクォータによるコスト管理のページに載っている既定値は次のとおりです。ユーザー別の正式名は、入力が「AI input tokens per day per user」、出力が「AI output tokens per day per user」です。

クォータ名 数える対象 単位 既定値
AI input tokens per day 入力トークン プロジェクト・1日 2,000億
ユーザー別の日次入力トークン 入力トークン プロジェクト内のユーザー・1日 1,500億
AI output tokens per day 出力と思考のトークン プロジェクト・1日 200億
ユーザー別の日次出力トークン 出力と思考のトークン プロジェクト内のユーザー・1日 150億

対象はAI.GENERATE・AI.GENERATE_TABLE・AI.GENERATE_TEXT・AI.CLASSIFY・AI.IF・AI.SCORE・AI.AGGで、埋め込みのAI.EMBEDなどは含みません。使用量は全リージョンの合算で、数百万トークン単位で記録されます。リセットは太平洋時間の0時で、日本時間では夏時間の期間が16時、それ以外は17時です。キャッシュされたトークンは数えられません。

変更は[IAMと管理]の[割り当てとシステム上限]で、サービスに「BigQuery API」を選んで行います。下げる変更は承認なしで即時に反映されます。操作できるのはオーナー・編集者・Quota Administrator(roles/servicemanagement.quotaAdmin)・Service Usage Admin(roles/serviceusage.serviceUsageAdmin)のいずれかを持つユーザーです。ブログは、1人の実験がプロジェクト全体の枠を使い切らないよう、ユーザー単位から先に絞ることを勧めています。

1日100ドル以内に収める入力・出力トークン上限と比率を使った計算例

ブログの計算例は、gemini-3.1-flash-liteを使い、BigQueryのバッチ処理に付く50%割引後の単価(入力100万トークンあたり0.125ドル、出力0.75ドル)で1日100ドルに収めるものです。

費用: 0.125 × I + 0.75 × O = 100   (I・Oは百万トークン単位)
比率: I = 100 × O                  (試験実行で測った入力:出力 = 100:1)
解  : I ≒ 754(7億5,400万)、O ≒ 7.54(754万)

求めた値を、入力と出力それぞれのプロジェクト単位のクォータに設定します。既定モデルのgemini-3.5-flash-liteは、Agent Platformの料金ページで2026年10月16日時点、global・通常処理の定価が入力0.30ドル、出力2.50ドル(いずれも100万トークンあたり)です。モデルを変えたら単価を入れ替えて計算し直してください。BigQuery側のスキャン料金は別にかかり、内訳はBigQueryのオンデマンドとEditionsの料金の分岐点で確認できます。

クォータ到達時にAI.GENERATEは成功扱いでstatusに残る挙動の対処

クォータの効き方は関数によって違います。実行前に枠が尽きていれば、クエリはQuotaExceededによる拒否の対象です。実行中に尽きた場合、AI.GENERATEのような汎用関数はクエリ自体は成功し、残りの行は生成値が空のままstatusにクォータ超過のエラーが入ります。

見落としやすいのはここです。ジョブが成功表示でも、後半の行が空のまま次の工程へ流れます。定期実行に組み込むなら、要約の手順3で示したWHERE status != ''の件数を毎回数え、0件でなければ後続の処理を止めて通知する仕組みが必要です。max_error_ratioを持つAI.IFなどは、未処理の割合が上限を超えるとクエリ全体が失敗するため、こちらはジョブの失敗として検知できます。

AI.GENERATEを本番の定期処理に入れる条件と見送る場面の判断基準

小さく試すのは簡単です。判断が要るのは、件数が増えて毎日動かす段階です。

推論対象を先に別テーブルへ確定してから関数を呼ぶ行数制御の設計

リファレンスは、JOINやORDER BY ... LIMITを含む複雑なクエリでは、モデルが処理する行数が想定と異なる場合があると明記しています。LIMIT 100と書いても、並べ替えの前に全行へ関数が適用されれば、その分のトークンが消費されます。対策として示されているのが、対象を別テーブルに書き出してから推論する形です。

定期処理では、さらに「前回処理済みの行を除く」条件を対象テーブルの作成時に入れます。inquiry_idで結果テーブルと突き合わせ、未処理の行だけを毎回の対象にすれば、同じ行に何度も課金されません。statusが空でない行は対象に戻し、翌日の枠で再実行します。

AI.GENERATEを採用する場面とマネージド関数や個別実装へ切り替える場面

条件 向く手段
出力の列構成を自分で決めて集計に回したい AI.GENERATEで列構成を指定
数千行以上を決まったカテゴリに振り分けるだけ AI.CLASSIFY・AI.IFの軽量推論
応答を画面へ即時に返す、会話の履歴を持つ アプリ側からAPIを直接呼ぶ実装
地域指定必須でデータが東京などUS・EU外 採用を見送る(globalに送られるため)

表の列構成の指定にはoutput_schemaを使います。分類だけが目的なら、AI.IFとAI.CLASSIFYのoptimized modeが候補になります。データの一部だけをGeminiにラベル付けさせ、その結果で軽量なモデルをクエリ実行中に学習し、残りの行を推論する仕組みです。入力に約3,000行以上と埋め込み列が必要で、2026年10月16日時点ではプレビューとして提供されています。考え方は知識蒸留の仕組みと判断基準と同じです。

逆に、ユーザー操作に応じて数秒で答える用途はAI.GENERATEに向きません。クエリジョブとして動くため、問い合わせ画面の応答のような処理はアプリケーションからAPIを呼ぶ構成にします。BigQueryに溜めたデータへ生成AIの処理を組み込み、取り込みから結果テーブル、監視までを一続きの基盤として設計する場合は、データ分析基盤構築・MLOps構築支援で対応範囲を確認できます。

BigQueryのAI.GENERATEと生成AI関数のコストについてよくある質問

2026年10月16日時点の公式ドキュメントをもとに答えます。

AI.GENERATEとML.GENERATE_TEXTの違いは何ですか?

AI.GENERATEはSELECT句の中で列のように使うスカラー関数で、リモートモデルを作らずにエンドポイント名を指定するだけで呼べます。AI.GENERATE_TEXT(別名ML.GENERATE_TEXT)はテーブルを返す関数で、事前に作ったリモートモデルの参照が必要です。Anthropic ClaudeやLlamaなどGemini以外のモデルを使いたい場合は後者を選びます。どちらも日次トークンクォータの対象です。

AI.GENERATEの料金はどこに請求されますか?

モデルの呼び出しはAgent Platform(旧Vertex AI)のGeminiの料金として、入力・出力・思考のトークン数に応じて請求されます。これとは別にかかるのが、クエリが読み込んだデータ量またはスロットに応じたBigQueryの料金です。公式ブログの例では、BigQueryからの呼び出しはバッチ処理として50%割引後の単価で計算されています。AI.COUNT_TOKENS自体にはAgent Platform側の課金はありません。

トークンクォータを下げたら実行中のクエリはどうなりますか?

クォータの引き下げは承認なしで即時に反映されます。実行中のクエリが途中で上限に達した場合、AI.GENERATEは新しいモデル呼び出しを止め、残りの行のstatusにクォータ超過のエラーを入れて終わるため、クエリ自体の扱いは成功です。その日のうちは、生成AI関数を使うクエリがQuotaExceededで失敗し続けます。再開できるのは太平洋時間の0時のリセット後です。

AI.GENERATEで画像やPDFを読み取れますか?

読み取れます。Cloud Storage上のファイルをOBJ.MAKE_REFで参照するか、オブジェクトテーブルのref列を使い、('この請求書の合計金額を抜き出して: ', ref)のように指示文とSTRUCTで組み合わせます。対応する形式はGemini APIのmimeTypeに準じ、動画は1入力1本・先頭2分までです。VPC Service Controlsの境界内では署名付きURLを使う参照が拒否されるため、OBJ.MAKE_REF(uri)の1引数の形で渡します。

接続(コネクション)を作る必要はありますか?

多くの場合は不要です。connection_idを省くと、クエリを実行したユーザーの認証情報で呼び出されます。そのユーザーにroles/aiplatform.userとroles/bigquery.jobUserが付いていることが実行の条件です。48時間以上かかる見込みのジョブでは、Cloud リソース接続を作成し、接続のサービスアカウントにroles/aiplatform.userを付けてconnection_idに指定します。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.16 テックブログ バーガーキング不正アクセスで約1,118万件の情報漏洩|対象確認・案内メールの真偽と運営側のログ点検
  2. 2026.10.15 テックブログ 銀のさら不正アクセス:最大650万件の対象確認と窓口、パスワード変更の手順
  3. 2026.10.16 テックブログ ソースネクスト不正アクセスで最大2,252万件流出|ログインできない理由・パスワード再設定と会員APIの点検
  4. 2026.10.15 テックブログ リゾートトラスト不正アクセス:会員2.6万件・カハラ横浜3.6万件の対象確認と窓口
  5. 2025.12.02 テックブログ クーパン問題とは?3,755万人流出と過去最大6,246億ウォンの課徴金

RELATED POSTS 関連記事

目次