【Google Cloud Next Tokyo 26】BigQueryとGemini最前線 〜SQLだけで非構造化データを構造化するAgentic Data Cloud〜

はじめに

Google Cloud Next Tokyo 26のDeveloper Stageセッション「BigQueryとGemini最前線！SQLで画像データを構造化・エージェント分析」（D1-DEV-07）のセッションレポートをお届けします。

日報や写真といった非構造化データは、蓄積されていても分析に載せるまでに手間がかかります。Cloud Storageからデータを取り出して解析し、結果をテーブルに書き戻すパイプラインが必要になり、その構築と運用が負担として残ります。本セッションは、この工程をBigQueryの標準機能とGeminiだけで完結させる構成を、建設現場の業務を題材に見せる内容でした。

セッション概要

登壇者は社内でのGoogle Cloudの商談支援や技術検証を担当されているとのことで、キーワードとして掲げられていたのが「Agentic Data Cloud」でした。データを貯めるだけの基盤ではなく、AIが実質的にデータを読み解いて次のアクションの判断材料を提供する基盤、という位置づけで紹介されていました。

なお、Agentic Data CloudはGoogle Cloud Next 26で発表された枠組みで、BigQuery・Knowledge Catalog・Gemini・Lookerを1つのシステムとして扱う構想として説明されています（What’s New in the Agentic Data Cloud）。本セッションは、その考え方をBigQueryを中心に実装レベルへ落とすとどうなるか、という切り口でした。

1. 建設現場の課題とデータ基盤のパラダイムシフト

題材として選ばれていたのは建設業界です。スライドでは「建設業が直面する『2024年問題』と現場の限界」として、課題が3枚のカードで示されていました。

現場監督は日中は現場を走り回り、夜にその日の作業日報や現場写真を確認して翌日の作業計画を作り直すそうです。この膨大な非構造化データを一人で確認する作業はすでに限界に達している、という現状が示されていました。

そこで必要になるのがデータ基盤のパラダイムシフトだと整理されていました。人間がデータを目視確認して翌日の計画を組み直す時代から、AIがデータを読み解いて状況を分析し、リスクを検出して次の最適な行動を提案する時代へのシフトです。Agentic Data Cloudはそのためのデータ基盤の考え方であり、BigQueryとGeminiを掛け合わせることでAIが動ける素材を作り上げる、という立ち上がりでした。

スライドでは、従来のデータ活用が「データを蓄積する／人がデータを目視確認する／人が予定を組み直す」の3点、Agentic Data Cloudが「データを活用する／AIが自律的に分析する／AIが推論し最適解を提案する」の3点として対比されていました。

2. 「人が休んでいる間にAIが働く」タイムライン

実現像として最初に示されたのが、現場の1日のタイムラインです。コンセプトは「人が休んでいる間にAIが働く」でした。

夜間バッチで人の作業を先回りさせる、という構成そのものは珍しくありませんが、後述するとおりこの一連の処理が新しいサービスをほとんど足さずに成立している点が本セッションの主眼でした。

3. アーキテクチャの全体像

「AIエージェントを支える全体アーキテクチャ」として示されていたのは、4つのブロックを左から並べた構成でした。

ここでのポイントとして強調されていたのが、複雑なパイプラインを作り込まずにBigQueryの標準機能を中心に有効化していく点です。以降、Step 1〜3に分けて詳細が解説されました。

4. ステップ1: 非構造化データをSQLで構造化する

現場から集まるのは日報・写真・手書きメモといった非構造化データです。これをBigQuery側に取り込む際のポイントとして挙げられていたのが、Cloud Storage上の画像データに対してオブジェクトテーブルを使い、ObjectRefでSQLから直接参照するという方法でした。スライドでは「Scheduled Query × ObjectRef」「SQLから非構造化データを直接読み込み」と示されており、複雑なデータ転送パイプラインの構築が不要になると説明されていました。

そのうえで、スケジュールクエリでSQLを自動実行し、SQLの中からAI関数でGeminiを呼び出して画像を解析します。「足場の組み立て作業に不備がある」といった具体的なリスクをJSON形式で抽出し、そのままSQL内でパースして構造化データとしてテーブルへ格納します。この一連の処理がすべてSQLだけで完結する、というのがステップ1の主張でした。

以下のスライドにある格納後のテーブルでは、report_dateとcomprehensive_riskの列に、前日の足場組み立て作業で手すり先行工法が未採用であること、幅木などの部材の不備、悪天候が重なると墜落・飛来落下災害に直結する、といった評価が文章で格納されていました。画像から抽出した内容が、そのままクエリ可能な列として並ぶ形です。

公式ドキュメントを確認すると、オブジェクトテーブルはCloud Storageのディレクトリの内容を表示する読み取り専用テーブルで、ObjectRef型のref列を自動的に持ちます。ObjectRef値はCloud Storage URIをOBJ.MAKE_REF関数に渡す形でも作成できると記載されています（Analyze multimodal data in BigQuery）。

セッションで「AI関数」と呼ばれていたものは、AI.GENERATE系の関数に相当します。特にAI.GENERATE_TABLEはレスポンスのスキーマを指定できるため、JSON形式でリスクを抽出してテーブルに格納する用途と対応が取れます（The AI.GENERATE_TABLE function）。

処理の形としては、オブジェクトテーブルのref列をプロンプトと一緒にAI.GENERATE_TABLEへ渡し、出力スキーマを指定して結果をそのままテーブルに書き出す流れになります。効いているのは「Cloud Storage上の画像を取り込まずに参照できる」「モデル呼び出しと結果の構造化がクエリの中で閉じる」という2点です。ここが成立するため、抽出処理をアプリケーション層に持つ必要がなくなります。

5. ステップ2: Knowledge Catalogとベクトル検索で計画を立てる

ステップ2では、ステップ1で抽出した日報やリスクデータに、外部データ（天気・交通情報）、工程表・施工計画、過去事例（事故・遅延）を掛け合わせて当日の行動計画案を作成します。これを実現しているものとしてスライドに掲げられていたのが「Knowledge Catalog × Vector Search」でした。散在するデータの意味づけ・自動整理を行い、過去事例をセマンティック検索により照合する、という位置づけです。

過去事例のデータはBigQueryに格納されたタイミングでBigQueryの機能によって自動的にベクトル化されます。あわせて、カタログが散在するデータへタグやメタデータを自動的に付与し、ビジネス上の意味を整理することで、AIがコンテキストを理解できる状態を作り上げると説明されていました。

そしてSQLの中からベクトル検索の関数を呼び出し、現在の状況に類似した過去事例を引き当てます。スライドでは「Geminiが点と点をつなぎ、最適な行動計画を推論」として、「強風」×「足場不備」×「過去事例」⇒明日の高所作業は中止、という掛け合わせの例が示されていました。引き当てた過去事例をコンテキストとしてSQLで補強してGeminiへ渡すことでこの推論が成立し、一連の処理はすべてSQLに還元できるという整理です。出力側には、8:00に屋内作業への変更、10:00に資材搬入時間調整、13:00に安全確認会議といった当日の行動計画案が時刻付きで並んでいました。

Knowledge Catalogは、構造化・非構造化データからセマンティクスを自動抽出してコンテキストグラフを構築し、AIエージェントを企業内の事実に基づかせるものだと説明されています（Knowledge Catalog overview）。

「格納されたタイミングで自動的にベクトル化される」という説明は、自律型エンベディング生成が該当します。ソース列にデータを追加・変更するとBigQueryが自動でエンベディング列を生成・更新し、VECTOR_SEARCHやAI.SEARCHから埋め込み設定を意識せずに使える、という機能です。公式ドキュメントではプレビューと記載されているため、本番前提で組む場合はこの点が制約になります（Autonomous embedding generation）。
ベクトルデータベースを別に立てず、RAGに相当する参照をSQLの中に埋め込める点が、この構成でパイプラインが減っている理由の1つになっています。

6. ステップ3: AIエージェントとの対話と意思決定

翌朝、現場監督のタブレットにはエージェントから次の一手が表示されています。裏側では夜間に格納された計画案をもとにGeminiが動いており、「安全確保のため高所作業を中止し、屋内配線へ作業をシフトします」といった提案を自然言語で提示します。

この自然言語による対話インターフェースを実現するものとしてスライドに挙げられていたのが、Conversational Analytics APIでした。エージェントがプロアクティブに次の一手を提示し、現場監督は内容を確認して最終判断を下す（Human-in-the-Loop）、という整理です。

対話例では、「午後は強風のため高所作業を中止し、屋内配線へ作業シフトします。よろしいですか。」という提案の下に工程のガントチャートが表示され、そこに「2 hours of delay recovered」という注記と【承認】【修正】のボタンが並んでいました。提案を丸のみさせず、承認と修正の2択を残している画面設計になっていた点は、この構成の思想が出ているところだと感じました。

Conversational Analytics APIはgeminidataanalytics.googleapis.com経由でアクセスするAPIで、自然言語での問い合わせをクエリに変換するデータエージェントを構築できるものです。公式ドキュメントではBigQueryとLookerについて一般提供（GA）と記載されています（Build data agents and chat with your data）。

7. 生成SQLでエンジニアの役割が変わる

最後のパートは、裏側の処理をどう実装するかという話でした。こうした複雑な処理をエンジニアが1からコードで書き起こす必要はなく、Gemini in BigQueryのSQL生成を使えば実現したい処理を自然言語で伝えるだけでAI側が複雑なクエリを自動生成してくれる、と説明されていました。スライドの見出しは「SQL開発をローコード、ローコストで実現」で、「複雑なSQLはAIが作成支援」「人間は、レビューと実行設定に集中」と添えられていました。画面例では「現場写真から抽出したリスク、天気予報、過去事例などをベクトル検索し、改善計画を提案するクエリ」というプロンプトから、日報・天気予報・AI提案・過去事例をJOINするSQLが生成されていました。

そのうえで示されたのが、エンジニアの役割のシフトです。

• AIに要件を正しく伝えること
• 生成されたSQLをレビューすること
• スケジュール実行を設計すること

なお、自然言語からのSQL生成やBigQuery data canvasを含むGemini in BigQueryの機能は一般提供されていると公式ブログに記載されています（Gemini in BigQuery features are now GA）。

現場への価値として挙げられていたのは、AIが夜間作業を巻き取ることによる実働時間の削減、ベテランの暗黙知をベクトル検索で誰でも活用できる形に変える属人化の低減、連鎖的なリスク検出による安全性の向上の3点でした。

最後に、この仕組みは人間の仕事を奪うものではないという線引きが示されました。AIがデータを読み解いて選択肢を提示し、人間が責任を持って最終判断を下します。「悩む時間」を「決断する時間」へ、というメッセージとともに、BigQueryとGeminiで現場の意思決定を加速するという締めでした。

印象に残ったポイント

「作らなくてよくなったもの」で構成の軽さが分かる

このアーキテクチャの説得力は、足した機能ではなく消えた実装物のほうに表れていると感じました。セッションの説明をたどると、従来なら用意していたものがいくつも要らなくなっています。

• Cloud Storageから画像を取り出してAIへ渡す転送パイプライン
• 抽出結果をJSONからパースしてテーブルへ書き戻すアプリケーション層
• 過去事例を検索するためのベクトルデータベース
• エンベディング生成と更新のためのバッチ
• 夜間処理を並べるためのオーケストレーション（スケジュールクエリで代替）

新しいサービスをほとんど足さずに夜間の自動処理まで到達している点が、今回の説明で一番効いていた部分でした。

レビューの対象がSQLの中身から外側へ移っている

エンジニアの役割が「複雑なクエリを書く人」から「要件をAIに正しく伝え、生成SQLをレビューし、実行スケジュールを設計する人」へ移る、という整理が本セッションの主張の1つでした。役割が移せる理由が技術側にあるのがポイントで、ObjectRefでETLが消え、ベクトル検索がSQLに入ってベクトルデータベースが消え、スケジュールクエリでオーケストレーションが消えます。作り込む対象が消えた結果として、書く仕事が減っているという因果です。
そうなると「レビューする」の中身も変わります。クエリが正しく動くかはAIが担保する領域になり、残るのはSQLに書かれていない部分です。業務要件とデータ特性を知っている人間しか判断できない領域で、実装の正しさの検証から運用設計の妥当性の判断へ、見るものが移ることになりそうです。

責任分界の線引きが明示されていた

推論はAIが担い、最終的な安全責任と決断は人間が持つ、という線引きが明示されていたのは、安全に関わるユースケースを扱ううえで誠実な整理だと感じました。Human-in-the-Loopを機能ではなく責任の所在として説明していた点が印象的でした。

さいごに

非構造化データの構造化から計画策定、対話による意思決定までを、BigQueryの標準機能とGeminiだけで通す構成を、具体例に沿って追える内容でした。一方でクエリが自動生成されるほど、SQLに書かれていない部分を誰が見るのかという論点は残ると感じました。
また、処理を夜間にまとめる構成であればレイテンシの制約は緩くなりますが、画像1枚ごとの課金やレート制限といったコスト面は気になったため、実際のデータ量での試算が必要になりそうです。同じような構成を検討している方の参考になれば幸いです。