みなさんこんにちは！

先日開催された「Google Cloud Next Tokyo 26」の Developer Stage（7月30日）のセッション：「BigQuery と Gemini 最前線！ SQL で画像データを構造化・エージェント分析」（D1-DEV-07）というテーマで登壇いたしました。当日は、多くのエンジニア・データ活用推進者の皆様にご参加いただき、誠にありがとうございました。

セッションは、10分間の LT 形式となっているため、本記事では、当日のセッションをお聞きいただいた方への振り返りはもちろん、セッションに参加されていない初見の方にも分かりやすいよう、背景となる課題から裏側の技術仕様・SQLコードまでを解説いたします。

1. はじめに：本記事のテーマ設定

本セッションでは、建設現場のリアルな業務課題を題材とし、BigQuery と Gemini を組み合わせることで、どのように実務で活用できるのか、について、具体的にご紹介しました。

1.1 建設業が直面する「2024年問題」と現場の限界

建設業界は今、いわゆる「2024年問題」による、時間外労働の上限規制や、深刻な人手不足、ベテランの高齢化に伴う暗黙知の消失危機に直面しています。

特に現場監督の負担は非常に大きく、日中は現場巡回を行い、夕方から夜間にかけて事務所で大量の作業日報や現場写真を目視確認し、翌日の工程を組み直すという業務を行っています。増え続ける写真や手書きメモなどの「非構造化データ」を人手でチェックする運用は限界を迎えています。

1.2 データ基盤のパラダイムシフト

これまでのデータ基盤は「データを溜めて、人間が見て判断する（System of Intelligence）」ものでした。しかし、今年の Google Cloud Next でも強調された「Agentic Data Cloud」は、データ基盤自身がAIと融合し、データを読み解いて次のアクションを自律的に提案する「System of Action（行動のためのシステム）」へと進化しています。

複雑な Python スクリプトや外部 ETL パイプラインを一から構築するのではなく、エンジニアが使い慣れた BigQuery の SQL で AI エージェントの基盤を完結させられることが、Google Cloud のエコシステムを使う最大の利点です。

図1：データ基盤のパラダイムシフト

1.3 コンセプト：「人が休んでいる間に、AIが活動する」

この課題を解決するため、本セッションでは、「人間とAIの役割分担」を時間軸で整理しました。

夕方（17:00〜）：
人間が、現場写真や日報をアップロードして帰宅
AI がデータを構造化・分析しリスク抽出
深夜（02:00〜）：
人間が休息中、AI がさまざまなデータを解析・多角推論を行い、翌日の計画案を策定
翌朝（07:00〜）：
現場監督は出社後、AI の提案を確認して最終判断に集中する

図2：人が休んでいる間に AI が活動するタイムライン

2. 全体アーキテクチャ

本アーキテクチャの特長は「パイプラインレス」です。複雑なデータ転送基盤や外部サーバーは一切作らず、BigQuery の標準機能と BigQuery AI のエコシステムのみで構成しています。

図3：AIエージェントを支える全体アーキテクチャ

スマートフォン：
現場写真・日報データの送信
Cloud Storage：
非構造化データ（画像・日報データ等）の格納庫
BigQuery：
ObjectRef、Knowledge Catalog、Vector Search による画像構造化・多角推論・計画生成
タブレット端末：
データポータル（Data Studio）や Conversational Analytics による提案確認と対話

3. 実装詳細とSQLコード解説

ここからは、タイムラインに沿って実行される Step 1 〜 Step 3 の技術仕様と実際の SQL を詳しく解説します。

Step 1：非構造化データの構造化（ObjectRef × BigQuery AI）

現場写真などの非構造化データを、データを移動させずに BigQuery 内で直接処理します。

オブジェクトテーブル（ObjectRef）の定義：
Cloud Storage 上の画像データを移動・コピーすることなく、SQLから直接参照可能なオブジェクトテーブルを作成し、ObjectRef 関数で画像を参照します
BigQuery AI 関数による Gemini 呼び出し：
Scheduled Query（スケジュールされたクエリ）で深夜バッチを自動実行し、SQL内から BigQuery AI 関数（ML.GENERATE_TEXT や AI.PARSE_DOCUMENT）を呼び出して Gemini に画像を解析させます
JSON パースと構造化保存：
Gemini が画像から抽出したリスク情報（JSON 形式）を、SQL の JSON 関数（JSON_VALUE）でパースし、BigQuery の構造化テーブルへ自動保存します

図4：Step 1 非構造化データを自律的に構造化

【クエリイメージ：画像からのリスク抽出と構造化】

※以下はアーキテクチャ理解のためのサンプルクエリです。ご自身の環境のプロジェクト名・データセット名・モデル構成等に合わせて調整してください。

-- 1. GCS上の画像を参照するオブジェクトテーブル（事前定義イメージ）
-- CREATE EXTERNAL TABLE `my_project.my_dataset.site_images_object_table`
-- WITH OPTION (object_metadata_type='SIMPLE', uris=['gs://my-bucket/site_photos/*']);

-- 2. 画像からリスクを抽出し、構造化テーブルへ格納するクエリ
INSERT INTO `my_project.my_dataset.daily_risk_report` (
  report_date,
  site_name,
  image_uri,
  risk_detail,
  risk_level
)
WITH raw_ai_output AS (
  SELECT
    uri AS image_uri,
    -- BigQuery AI関数によりGeminiを呼び出し
    ML.GENERATE_TEXT(
      MODEL `my_project.my_dataset.gemini_pro_model`,
      (
        SELECT
          'この現場写真から安全上の不備（足場の不備、保護具の未着用など）を抽出し、' ||
          '{"risk_detail": "リスクの具体的な説明", "risk_level": "High/Medium/Low"} のJSON形式で出力してください。'
          AS prompt, ObjectRef(uri) AS image_ref
        FROM `my_project.my_dataset.site_images_object_table`
        WHERE DATE(created_time) = CURRENT_DATE()
      )
    ) AS result
  FROM `my_project.my_dataset.site_images_object_table`
  WHERE DATE(created_time) = CURRENT_DATE()
)
SELECT
  CURRENT_DATE() AS report_date,
  'A工事現場' AS site_name,
  image_uri,
  JSON_VALUE(result, '$.risk_detail') AS risk_detail,
  JSON_VALUE(result, '$.risk_level') AS risk_level
FROM raw_ai_output;

Step 2：多角的な推論（Knowledge Catalog × Vector Search）

Step 1 で構造化した「当日の現場リスク」に、天気予報（外部データ）、工程表（構造化データ）、および過去の事故・遅延事例（非構造化データ）を掛け合わせて多角的に推論します。

自律型エンベディング生成（Autonomous embedding generation）：
過去の事故・遅延報告書などの事例データは、BigQuery に格納されたタイミングで自動的にベクトル化（インデックス同期）されています
セマンティクス整理（Knowledge Catalog）：
散在するデータに対してメタデータやビジネス定義を自動付与・整理し、AI がコンテキストを深くまで理解できる状態を作ります
VECTOR_SEARCH と SQL JOIN の組み合わせ：
SQL 内で VECTOR_SEARCH 関数を呼んで現在のリスクに類似する過去事例を引き当て、そこに明日の天気データや工程表を SQL で結合（JOIN）して Gemini へ渡し、翌日の最適な行動計画案を推論させます

図5：Step 2 データを掛け合わせた多角的な推論

【クエリイメージ：類似事例検索と多角統合推論】

※以下はアーキテクチャ理解のためのサンプルクエリです。環境に合わせてテーブル名や列名を置き換えて調整してください。

-- 当日のリスクデータと過去類似事例、天気、工程を結合してGeminiで総合推論するクエリ
WITH current_risk AS (
  SELECT report_date, site_name, risk_detail
  FROM `my_project.my_dataset.daily_risk_report`
  WHERE report_date = CURRENT_DATE()
),
-- VECTOR_SEARCH による類似過去事例の引き当て
similar_past_accidents AS (
  SELECT
    query.report_date,
    base.accident_description AS past_accident_case
  FROM VECTOR_SEARCH(
    TABLE `my_project.my_dataset.past_accidents_indexed`,
    'text_embedding',
    (
      SELECT report_date, ML.GENERATE_EMBEDDING(MODEL `my_project.my_dataset.embedding_model`, risk_detail) AS query_embedding
      FROM current_risk
    ),
    top_k => 1
  )
),
-- 異種データの統合（JOIN）
integrated_context AS (
  SELECT
    r.report_date,
    r.site_name,
    r.risk_detail,
    w.weather_condition,
    w.wind_speed,
    a.past_accident_case
  FROM current_risk r
  JOIN `my_project.my_dataset.weather_forecast` w ON r.report_date = w.forecast_date
  JOIN similar_past_accidents a ON r.report_date = a.report_date
)
-- Gemini による最適な行動計画案の推論と保存
INSERT INTO `my_project.my_dataset.ai_proposals` (report_date, site_name, ai_plan)
SELECT
  report_date,
  site_name,
  ML.GENERATE_TEXT(
    MODEL `my_project.my_dataset.gemini_pro_model`,
    CONCAT(
      'あなたは建設現場の優秀な安全管理者です。以下の条件を総合的に分析し、
       明日の現場での最適な行動計画案（作業の中止、屋内作業への切り替え等）を具現化してください。\n\n',
      '【本日の現場リスク】: ', risk_detail, '\n',
      '【明日の天気予報】: ', weather_condition, '（風速: ', CAST(wind_speed AS STRING), 'm/s）\n',
      '【類似の過去事故例】: ', past_accident_case, '\n'
    )
  ) AS ai_plan
FROM integrated_context;

Step 3：AI エージェントとの対話型意思決定

深夜バッチで生成された翌日の行動計画案は、翌朝、現場監督のタブレット上にプロアクティブに提示されます。この対話インターフェースを実現するのが Conversational Analytics です。

図6：Step 3 AI エージェントとの対話型意思決定

柔軟な展開アプローチ

検証フェーズ（データポータル / Data Studio 等）：
PoC（動作検証）段階では、BigQuery の出力テーブルや Conversational Analytics エージェントを Data Studio に接続することで、「リスク＆提案ダッシュボード＋対話機能」をノーコードで迅速に構築・検証できます
本運用フェーズ（Gemini Enterprise 等）：
本運用では、このエージェントを Gemini Enterprise 等へパブリッシュします。エンタープライズレベルの権限管理・セキュリティのもとで、社内共通の対話基盤としてスムーズに全社展開できます

対話型意思決定がもたらす価値

カスタム UI 開発が不要：
独自のチャットアプリを一から構築・保守することなく、管理された安心な対話 UI（Data Studio や Gemini Enterprise 等）をそのまま活用可能
自然言語でのシミュレーション：
現場監督は「なぜ午後の作業を中止するのか？」「代替の人員シフト案を出して」とチャットで問いかけることで、根拠の確認やシミュレーションが可能
Human-in-the-Loop の実現：
AI が提示した「次の一手」を人間が確認・納得した上で最終承認を下す、安全な意思決定プロセスを構築

4. 開発体験：Gemini in BigQuery によるローコード開発

上述のような画像参照・AI 関数・ベクトル検索・JOIN・AI 推論を組み合わせた複雑なパイプラインですが、エンジニアがイチからコードやパイプラインを書く必要はありません。

Gemini in BigQuery の SQL 生成機能を活用し、実現したい処理（例：「現場写真から抽出したリスク、天気予報、過去事例などをベクトル検索し、改善計画を提案するクエリ」）を自然言語で指示することで、AI が高度な SQL クエリのベースを自動生成してくれます。

開発プロセスの劇的な変化

従来のデータ開発では、Python や Dataflow を使った複雑な ETL パイプラインの作成・運用が不可欠でした。本アーキテクチャでは、「SQL ＋ Scheduled Query による自動実行」で全自動のエージェント基盤が完結します。

エンジニアの役割は「パイプラインを構築する作業者」から、「AI に適切な要件を伝える設計者」、「生成された SQL をレビュー・調整するアーキテクト」へとシフトします。これにより、構築期間と開発コストの圧倒的な短縮・圧縮を実現しています。

5. まとめ

今回のアーキテクチャがもたらす現場への価値は以下の3点に集約されます。

実働時間の削減：
夜間の日報・写真目視確認と計画策定を AI が自動化し、実働時間を削減
属人化の低減：
ベテランの経験・暗黙知をベクトル検索可能にし、組織のナレッジとして標準化
安全性の向上：
リスク・天候・過去事例の多角的な推論により、見逃しが許されない現場の安全を守る

Agentic Data Cloud が拓くデータ基盤の未来

本アーキテクチャの本質は、AI で業務を効率化した点にとどまりません。データ基盤そのものが、従来の「データを溜めて人間が分析する（System of Intelligence）」から、AIエージェントが自律的にデータを読み解き次のアクションを提案する「System of Action（行動のためのシステム）」へと進化した点にあります。

AI は判断の材料と選択肢をスピーディーに提示する役割に徹し、責任を持った最終判断は人間が行う（Human-in-the-Loop）。「悩む時間」を AI に任せ、人間はプロフェッショナルとして「決断する時間」に集中する。——これこそが、BigQuery と Gemini が実現する次世代のデータ活用の姿です。

本記事が、データ基盤のモダン化や生成 AI の実業務適用に取り組む皆様の参考になれば幸いです。

関連リソース

Introducing the Google Cloud Knowledge Catalog

Unveiling new BigQuery capabilities for the agentic era

※Next Tokyo 26 公式アンバサダーとして参加・執筆しています。
#GoogleCloudNext #NextTokyoアンバサダー