BigQuery Managed AI Functions ── SQL から Gemini を呼ぶ設計の転換点

本記事では、2026-04-13 に GA となった BigQuery Managed AI Functions について解説します。

従来の ML.GENERATE_TEXT との設計上の違い、3 関数の呼び出し形式と SQL への組み込み方、料金モデルの構造、実務上の制約を順に整理します。

Managed AI Functions の設計上の位置付けを把握することで、既存のデータ処理クエリに Gemini を組み込める範囲の判断材料としましょう。

Managed AI Functions の位置付け ── ML.GENERATE_TEXT と何が違うのか

本記事が扱うのは AI.IF / AI.SCORE / AI.CLASSIFY の 3 関数のみです。BigQuery には生成 AI 関連の関数が複数存在しますが、「マネージド (Managed)」と呼ばれるグループと「汎用 (general-purpose)」と呼ばれるグループは、公式ドキュメントで明確に区別されています。

このうちマネージドグループが本記事の対象です。

汎用グループの代表が ML.GENERATE_TEXT です。この関数を使うには、事前に CREATE MODEL 文でリモートモデルを登録し、Vertex AI への接続設定 (REMOTE WITH CONNECTION) を明示する必要があります。

-- ML.GENERATE_TEXT を使う場合 (汎用): CREATE MODEL が前提
CREATE OR REPLACE MODEL `my_project.my_dataset.gemini_model`
  REMOTE WITH CONNECTION `asia-northeast1.my_connection`
  OPTIONS (endpoint = 'gemini-2.0-flash');

SELECT ml_generate_text_result
FROM
  ML.GENERATE_TEXT(
    MODEL `my_project.my_dataset.gemini_model`,
    (SELECT CONCAT('要約してください: ', body) AS prompt FROM `my_dataset.articles`),
    STRUCT(0.2 AS temperature, 1024 AS max_output_tokens)
  );

この構造では、モデル登録・接続設定・プロンプト組み立て・出力 STRUCT のパース、これらすべてを実行者が管理します。出力型は STRUCT であり、後続の SQL で値を取り出すには JSON_EXTRACT や STRUCT フィールド参照が必要です。

Managed AI Functions はこの前工程を BigQuery 側に委ねる設計です。CREATE MODEL は不要で、connection_id も省略可能 (後述の例外あり)。モデルの選択と最適化は BigQuery が動的に処理します。

-- AI.IF を使う場合 (マネージド): CREATE MODEL 不要
SELECT review_id, review_text
FROM `my_dataset.reviews`
WHERE AI.IF((
  'この口コミはサービスに対して肯定的な評価をしていますか？',
  review_text
));

出力型も ML.GENERATE_TEXT とは異なります。AI.IF は BOOL、AI.SCORE は FLOAT64、AI.CLASSIFY は STRING を返すため、WHERE / ORDER BY / GROUP BY に直接書けます。

BigQuery 側に何を委ねるかという設計選択が、SQL でデータを扱う人間の業務範囲を変えます。汎用関数はプロンプトと出力構造を完全に制御できる反面、モデル管理の負担を伴います。Managed AI Functions はその負担を手放す代わりに、SQL の節に Gemini の判断結果をスカラー値として直接組み込めるようになります。

3 関数の呼び出し形式と SQL への組み込み方

AI.IF ── 条件フィルタとしての自然言語判定

AI.IF は BOOL を返す関数で、WHERE 句や JOIN ON 句に配置します。呼び出し形式は以下のとおりです。

AI.IF((prompt_prefix, column [, column ...]) [, connection_id => ...] [, endpoint => ...] [, max_error_ratio => ...])

prompt_prefix には判定基準を自然言語で記述し、column にはモデルが評価対象とする列を渡します。

-- 例: 否定的な口コミのみを抽出する
SELECT review_id, review_text
FROM `my_dataset.reviews`
WHERE AI.IF((
  'この口コミはサービスや商品に対して否定的な内容を含んでいますか？',
  review_text
));

AI.SCORE ── 順序付けのための相対スコア

AI.SCORE は FLOAT64 を返します。ORDER BY 句と組み合わせることで、自然言語の基準に基づいて行を相対的に順序付けできます。

AI.SCORE((prompt_prefix, column [, column ...]) [, connection_id => ...] [, endpoint => ...] [, max_error_ratio => ...])

重要な点は、この値が絶対的な評価点ではなく相対的な順序付けのための値であることです。スコアの数値そのものを閾値フィルタに使うことは、公式ドキュメントが想定していない使い方です。

-- 例: お問い合わせをクレームらしさの高い順に並べる
SELECT inquiry_id, inquiry_text,
       AI.SCORE((
         'この問い合わせはクレームまたは強い不満を含んでいますか？',
         inquiry_text
       )) AS urgency_score
FROM `my_dataset.inquiries`
ORDER BY urgency_score DESC
LIMIT 100;

AI.SCORE には後述する optimization_mode が対応していないことも、使い分けの際に押さえておく制約です。

AI.CLASSIFY ── ラベル付けと集計への組み込み

AI.CLASSIFY は、指定したラベル候補の中から最も適切なものを STRING として返します。SELECT 句や GROUP BY 句に配置できるため、分類ラベルを集計キーとして直接使えます。

AI.CLASSIFY(
  (prompt_prefix, column [, column ...]),
  categories => ['label1', 'label2', ...] [, connection_id => ...] [, endpoint => ...] [, max_error_ratio => ...]
)

categories に候補ラベルを配列で渡す点が AI.IF / AI.SCORE と異なります。返した分類ラベルを集計キーとして直接 GROUP BY に使う場合のクエリ例を示します。

-- 例: サポートチケットをカテゴリ別に集計する
SELECT
  AI.CLASSIFY(
    ('このサポートチケットの問題カテゴリを分類してください。', ticket_text),
    categories => ['請求・料金', '技術的な不具合', '使い方の質問', 'その他']
  ) AS category,
  COUNT(*) AS ticket_count
FROM `my_dataset.support_tickets`
GROUP BY category
ORDER BY ticket_count DESC;

endpoint 引数によるモデル固定

3 関数はいずれも options として endpoint を指定できます。省略した場合、BigQuery が gemini-2.5-* 系の中からモデルを動的に選択します。特定のモデルに固定したい場合は明示します。

-- 例: Gemini 2.5 Flash-Lite に固定する
WHERE AI.IF((
  '商品レビューは星 4 以上に相当する高評価ですか？',
  review_text
), endpoint => 'gemini-2.5-flash-lite')

optimization_mode (Preview) ── コスト削減のローカルフィルタ

AI.IF と AI.CLASSIFY には、Preview 段階の optimization_mode パラメータが存在します。MINIMIZE_COST を指定すると、ローカルの蒸留モデルが前段でフィルタリングを行い、Gemini への呼び出しを削減します。

公式ドキュメントによれば、約 3,000 行以上のデータセットで効果が出やすいとされています。AI.SCORE にはこのオプションは対応していません。

なお optimization_mode => 'MINIMIZE_COST' を有効化するには、テーブル側に埋め込みベクトルを保持する必要があり、AI.IF / AI.CLASSIFY には別途 embeddings 引数を渡します。embeddings を渡さない場合は標準の LLM 推論で全行を処理する動作にフォールバックします。

動的モデル選択が見積もりを難しくする理由 ── 二層課金の構造

Managed AI Functions の料金は二層構造です。BigQuery 側の課金 (スキャン量またはスロット) に加えて、Vertex AI 側の Gemini トークン課金が発生します。

BigQuery 側の課金はオンデマンドとスロット予約 (Editions) のどちらでも変わらず、関数が参照した列データのスキャン量に基づきます。スロット予約 (BigQuery Editions) を利用している場合、関数呼び出しのスキャン分は予約済みスロットの稼働時間に含まれ、追加のスキャン課金は発生しません。Vertex AI 側のトークン料金は予約とは別建てで計上されます。

Vertex AI 側は入力トークン・出力トークン単位の課金です。公式ページに記載されている料金は USD 一律で、リージョン別の単価差は設けられていません (1 USD = 150 円換算・確認日 2026-05-04)。

出典: Agent Platform の料金 (旧 Vertex AI 生成 AI 料金) ── 確認日 2026-05-04

endpoint を省略して動的選択を使う場合、適用されるモデルがクエリ実行ごとに変わる可能性があります。トークン単価が一意に確定しないため、コストの見積もりが難しくなります。料金を予測可能にしたい場合は endpoint を明示してモデルを固定するのが現実的な選択肢です。

概算の試算例

AI.IF で 100 万行のレビューデータを処理する場合を想定します。1 行あたりのプロンプトが約 100 トークン、出力が約 5 トークンとすると、入力トークン総数は約 1 億トークン (100 万行 × 100 トークン)、出力トークン総数は約 500 万トークンです。

Gemini 2.5 Flash で計算すると以下になります。

• 入力: 100 百万トークン × $0.30 / 100 万トークン = $30
• 出力: 5 百万トークン × $2.50 / 100 万トークン = $12.50
• 合計: 約 $42.50 (約 6,375 円)

Gemini 2.5 Flash-Lite であれば入力 $10 + 出力 $2 = 約 $12 (約 1,800 円) になります。モデル選択と optimization_mode の組み合わせで、同じ処理でもコストに大きな差が出ます。

なお東京リージョン (asia-northeast1) では、2026-05-04 時点で gemini-2.5-flash / gemini-2.5-flash-lite / gemini-2.0-flash などの Gemini モデルがサポートされており、マネージド AI 関数を東京リージョンの BigQuery データセットからそのまま呼び出せます。

出典: Vertex AI 生成 AI のロケーション

Cloud Billing での追跡

コストの内訳を追跡するには、Cloud Billing エクスポートで bigquery_job_id_prefix ラベルを使います。BigQuery 側と Vertex AI 側の請求が別々に集計されるため、ラベルを起点に両側を突き合わせる運用が必要です。

本番投入前に確認する制約 ── ジョブ時間・エラー行・リージョン

48 時間超のジョブは connection_id が必要

Managed AI Functions は通常 connection_id を省略できますが、例外があります。48 時間を超えるジョブを実行する場合は connection_id の明示が必要です。大量データを一括処理する設計では、ジョブ時間の見積もりを事前に行い、必要に応じて接続設定を準備してください。

エラー行は NULL を返す

処理中にエラーが発生した行は例外をスローするのではなく、NULL を返します。デフォルトの max_error_ratio は 1.0 (100%) で、エラー行がどれだけあってもジョブ自体は完了します。

本番クエリではこの挙動が想定外のデータ欠損を引き起こす可能性があります。許容できるエラー率を max_error_ratio で明示的に設定することを推奨します。

-- 例: エラー率 5% 超でジョブを失敗させる
WHERE AI.IF((
  '...プロンプト...',
  review_text
), max_error_ratio => 0.05)

global エンドポイントを指定するとデータ処理リージョンが不確定になる

endpoint に gemini-2.5-flash のようなグローバル形式を指定した場合、データが実際にどのリージョンで処理されるかは確定しません。データの所在地を特定リージョンに限定する必要がある場合は、リージョン修飾子を含むエンドポイント指定か、リージョン固定の接続設定を使ってください。

クォータ

公式ドキュメントに記載されているクォータは以下の通りです。

• 1 ジョブあたりの行数上限: 10,000,000 行
• 同時実行ジョブ数: 5 ジョブ

大規模なバッチ処理では、テーブルを分割して複数クエリで実行する設計が必要になります。

出典: BigQuery クォータと上限

まとめ ── SQL の節に Gemini が書ける、という設計の意味

BigQuery Managed AI Functions は、モデル選択とプロンプト最適化を BigQuery 側に委ねることで、リモートモデルのセットアップなしに Gemini をスカラー出力として SQL に組み込める設計です。この委譲の設計が、SQL でデータを操作できる人間が ML エンジニアの前工程を待たずに Gemini を本番クエリに組み込める状況を作ります。

3 関数の役割はそれぞれ異なります。

• AI.IF: 自然言語の条件で行を絞り込む。WHERE / JOIN ON 句に配置
• AI.SCORE: 相対的な順序付け。ORDER BY 句でスコアの高低に並べる
• AI.CLASSIFY: ラベル候補の中から分類。GROUP BY と組み合わせた集計が得意

ML.GENERATE_TEXT (汎用) との使い分けは、出力の構造と制御の必要性で判断できます。プロンプト設計や出力フォーマットを細かく制御したい場合、あるいは生成テキストをそのまま使いたい場合は ML.GENERATE_TEXT を選びます。

スカラー値 (BOOL / FLOAT64 / STRING) として SQL 節に直接組み込みたい場合は Managed AI Functions が適しています。

optimization_mode は現時点で Preview 段階です。本番環境での挙動の安定性と正式 GA のタイミングを確認した上で採用判断をしてください。

参考文献

• BigQuery 生成 AI の概要
• AI.IF リファレンス
• AI.SCORE リファレンス
• AI.CLASSIFY リファレンス
• セマンティック分析チュートリアル
• BigQuery リリースノート
• Agent Platform の料金 (旧 Vertex AI 生成 AI 料金) ── 確認日 2026-05-04
• BigQuery クォータと上限
• AI 関数の権限

Author

tgeas

大阪の SIer 勤務。Google Cloud Partner Top Engineer 2026 / 2025 JAPAN All AWS Certification Engineers。インフラ・ネットワークからデータ活用と生成 AI 活用支援まで幅広く対応。

profile