Google CloudがプレビューのAI.AGGを紹介、数百万行を1つのSQLクエリで意味的に集約可能
公開:
BigQueryでは、発表時点でプレビュー提供中のAI.AGGを使うと、数百万行のデータに自然言語の指示を1つのSQLクエリで実行できます。AI.AGGは、BigQuery GoogleSQLに組み込まれたフルマネージドの多段階の意味的集約関数で、SQLのグループごとに1つの文字列を返す仕組みです。[1]
この記事では、AI.AGGでできることと使い方、プレビュー中の上限や費用の注意点を解説します。行単位のAI関数との使い分けも、編集部が目的別に整理しました。
プレビュー版AI.AGGで数百万行を意味的に集約
従来のリレーショナルSQLエンジンには、数百万行のテキストやマルチモーダルデータから意味のテーマを集約する標準機能がありませんでした。コンテキストウィンドウが課題となり、Geminiのような基盤モデルでも、数百万行を1つのプロンプトに渡すと厳しい切り捨てや実行の失敗が起きます。[1]
従来は、データエンジニアリングチームが外部のmap-reduceパイプラインを作り、レート制限の待機や分割した要約の結合を管理する必要がありました。プレビュー中のAI.AGGは意味的な集約を分散型のmap-reduceの問題として扱い、分割と並列実行はBigQueryエンジンが担います。
多段階バッチ処理の流れ
プレビュー中のAI.AGGのクエリを実行すると、BigQueryエンジンが処理の順序をデータベース内で自動的に組み立てます。各バッチの大きさは、選んだGeminiエンドポイントのトークン上限に収まるよう動的に決まる仕組みです。
並列推論では、自然言語のSQLプロンプトを各バッチへ並列に適用し、Vertex AIで中間要約を作ります。最後は中間出力を同じ指示でLLMへ戻す統合を繰り返し、GROUP BYのグループごとに文字列を1つ作る流れです。
マルチモーダル入力の扱い
プレビュー中のAI.AGGは、テキストとマルチモーダルの両方の入力に対応します。BigQuery Object TablesとOBJ.GET_ACCESS_URL関数を使えば、Cloud Storageに保存した数千枚の画像から視覚的な知見を集約できます。
Cloud Storageの画像の視覚的な知見をBigQuery Object TablesとOBJ.GET_ACCESS_URL関数で集約する際、移動や変換は要りません。ペタバイト規模のデータをBigQueryで意味的な知見に変えるのがAI.AGGの位置付けです。
NULL exclusivity ruleは、Google Cloudが挙げるデータエンジニアリングのヒントです。複数の列をSTRUCTで渡すと1項目のNULLで行全体が通知なく除外されるため、NULLになり得る項目はIFNULL()で包むよう勧められています。
AI.AGGの2つの活用例
プレビュー中のAI.AGGの活用例は、大量のシステムログの診断と、サポートチケットの整理です。AI.AGGの分析の力は標準SQLのGROUP BYとの組み合わせで発揮される、とGoogle Cloudは評価しています。
AI.AGGを使うと、DevOpsチームは数百万件のログをシステムのコンポーネントごとにまとめ、人が読める診断の要約を作成可能です。世界に分散したマイクロサービスのシステムログには、メモリのスラッシングや時刻のずれのように、明示的な致命的エラーを出さない劣化が隠れていることがあります。
サポートチケットの例では、AI.AGGが作るカテゴリ一覧の厳密なJSON配列を、JSON_VALUE_ARRAYで展開してAI.CLASSIFYなどへ渡す構成です。この流れによって、エンドツーエンドで自律的なラベル付けのパイプラインをSQLで組め、外部のPythonスクリプトの必要性が減ります。
AI.AGGを使ったクエリの書き方
発表時点でプレビューのAI.AGGは、BigQuery GoogleSQLに組み込まれた関数で、SQLクエリの中で使います。使い始める場所は、Google CloudコンソールとBigQueryのドキュメントです。[1]
AI.AGGの基本のクエリ例
プレビュー中のAI.AGGのクエリ例には、公開データで投稿者ごとの話題を要約する例と、エラーログからサービスごとの根本原因を探す例があります。エラーログの例は、severityが'CRITICAL'で実行時から24時間以内のログを対象に、COUNT(*)の件数とAI.AGGの要約を1つのクエリで並べる形です。
bigquery-public-data.hacker_news.fullから、上位投稿者3人ごとにコメントを要約するクエリは、以下の通りです。
WITH top_commenters AS (
SELECT
`by` AS author,
`text`
FROM `bigquery-public-data.hacker_news.full`
WHERE `type` = 'comment'
AND `by` IN ('dang', 'patio11', 'tptacek')
LIMIT 5000
)
SELECT
author,
AI.AGG(
`text`,
'These are comments written by this user on a tech forum. Tell me what topics this user talks about the most and what their general tone is. Keep it concise.'
) AS author_persona
FROM top_commenters
GROUP BY author;
公式資料からの抜粋:Semantic aggregation over millions of rows in BigQuery with AI.AGG(Macro-level topic discovery)。対象版・範囲:BigQuery AI.AGG(発表時点でプレビュー)。
上記のコードでは、発表時点でプレビューのAI.AGGを使い、LIMIT 5000で対象を最大5,000件に絞ります。AI.AGGへ話題と口調を簡潔にまとめる指示を渡し、author_personaにauthorごとの要約を返します。
プログラム向けSQL出力のプロンプト設計
Google Cloudは、高度に決定的なSQLの処理では、会話調の一般的なプロンプトがうまく働かないことが多いと指摘しています。プログラムが扱うSQL出力のプロンプト設計を厳格なエンジニアリングの領域とし、プレビュー中のAI.AGG向けに次の書き方を挙げています。
プレビュー中のAI.AGGでプログラムが扱うSQL出力を求める場合、ラベルの区切りは密なバッチでのフィールドの混同を防ぐ、というのがGoogle Cloudの見解です。同じAI.AGGでシステムログを診断する場合は、異常の前に正常な動作を説明させるとLLMが健全なログでエラーを作る傾向を抑えやすいと、Google Cloudは勧めています。
AI.AGGの利用前に確かめる条件
AI.AGGは発表時点でプレビューとして提供され、一般提供の時期や提供地域、料金の単価は今回の発表に含まれていません。プレビュー中はSQLグループごとの出力と1行の入力に上限があり、費用を抑える事前の絞り込みも求められます。[1]
プレビュー中の上限値
プレビュー中のAI.AGGでは、SQLグループごとの最終出力と、個別のペイロード行の大きさが上限の対象です。1クエリで処理する行数と出力する異なるSQLグループの数にも、安定性のためにGoogle Cloudが推奨する上限があります。
グループごとの出力が上限に収まるよう、Google Cloudはモデルに簡潔な出力を求めることを勧めています。画像の枚数の目安は、マルチモーダル配列で通知なく飛ばされるのを避けるためです。
トークン費用の抑え方
プレビュー中のBigQuery AI.AGGは再帰的にバッチを統合するため、Geminiへ送るトークンの合計は元データのトークン数より多くなります。Google Cloudは、費用を抑えるためにWHEREとLIMITによる事前の絞り込みの徹底を求めています。
BigQueryは、大規模な静的データセットを参照するワークフロー向けにGemini Context Cachingに対応済みです。Gemini Context Cachingは入力トークンの費用と実行の遅れを減らせる場合があり、実行前の見積もりにはAI.COUNT_TOKENSを使えます。
VPC-SCとバッチ処理中の一時的エラー
プレビュー中のAI.AGGは、BigQueryのガバナンスの枠組みの中で動作し、データの持ち出しを防ぐVPC Service Controls(VPC-SC)に対応する関数です。バッチ処理中に一時的なエラーが起きた場合、AI.AGGはクエリ全体を止めずに拒否された行を飛ばします。
プレビュー版AI.AGGと行単位関数の選び方
BigQueryには、AI.GENERATEやAI.CLASSIFYのような行単位のAI関数もあります。発表時点でプレビューのAI.AGGは、行単位の関数と処理の単位が違います。[1]
AI.CLASSIFYとの使い分け
プレビュー中のAI.AGGは、別々のバッチにまたがる概念の統合に深い推論が必要なため、全段階でフルウェイトのLLMを使います。AI.CLASSIFYなどの行単位の関数は、蒸留したCPUプロキシモデルを利用できる点で異なります。
複数の行から傾向や要約を1つにまとめたい場合は、プレビュー中のAI.AGGが候補です。各行に個別の処理を当てはめたい場合は、行単位の関数を先に検討するのが編集部の見立てです。
AI.AGGの本番前の確認項目
Google Cloudは、意味的なワークロードを本番へ移すには運用上の監督が必要としています。プレビュー中のBigQuery AI.AGGで本番前に確かめる項目を、編集部が以下にまとめました。
分類の無い大量のサポートチケットを整理したい場合は、プレビュー中のAI.AGGでカテゴリ一覧を作り、AI.CLASSIFYで各行に当てはめる組み合わせも検討できます。この組み合わせでは、AI.AGGの出力を厳密なJSON配列にするプロンプトの指定が前提です。
出典
- ^ Google Cloud. 「Semantic aggregation over millions of rows in BigQuery with AI.AGG」. https://cloud.google.com/blog/products/data-analytics/semantic-data-aggregation-with-bigquery-and-ai-agg, (参照 26-11-05).
※本記事は公式の一次情報を基に編集しています。内容はAIで確認していますが、誤りや最新情報との差異がある場合は、以下フォームよりご報告ください。
修正・削除・掲載などの依頼はこちら


















