データの消費者は「ヒト」だけじゃない ─ AI ネイティブなデータ基盤の実態
こんにちは！Scene Live bq事業本部のまっすーです。
2025年からデータサイエンティスト兼データエンジニアとして、Scene Liveに中途入社しました。bqというサービスのLLMを用いた検証・研究をおこなったり、プロダクトに関するデータ収集から利活用までの『データ基盤』を作ったりしています。
連載：Dagster 移行 3 部作
第 1 回：なぜ Airflow から Dagster に乗り換えたのか
第 2 回：Dagster 移行、500 テーブル超を止めずに引っ越した話
第３回：Dagster の“ネイティブ統合”が効いた話(dlt / dbt + リバースETL)
既刊: 【1ヶ月半で構築】bq事業のモダンデータスタック
はじめに
Dagster 移行 3 部作で、データ基盤を「育てる」話を書いてきました。
今回は連載をいったん離れて、単発の記事です。テーマは 「データの消費者には、もう人間だけじゃなく LLM もいる」という話です。
少し前まで、データ基盤の利用者は ヒト（アナリスト・エンジニア・ビジネスサイド）でした。ダッシュボードを見る、SQL を書く、Looker でグラフを眺める ─ どれも人間が起点です。
でもここ最近、うちのデータ基盤の 読み手にもう一人「LLM」が加わりました。コスト監視も、データ品質チェックも、技術トレンドの要約も、LLM が BigQuery を叩いて、判断して、Slack に投げてくる。
たとえば毎週水曜の朝、Slack を開くと「先週の BigQuery コストが先週比 +35% になってます。原因はおそらく〇〇のクエリです」 という診断つきメッセージが LLM から届く。 人間が料金ダッシュボードを開いて気づく前に、LLM の方が先に気づいて教えてくれる ─ これが想像以上に効いています。
今回はその実例を 3 つ、紹介します。
この記事の前提（用語の整理）
Dagster 移行 3 部作で出てきた用語（Dagster / dbt / dlt / BigQuery / リバース ETL / Langfuse 等）は引き続き使います。なかでも本記事の文脈で重要なのは メダリオンアーキテクチャ ─ Bronze（生データ）/ Silver（整形済）/ Gold（集計済）の 3 階層でデータを段階的に整える設計 ─ の概念で、これが LLM エージェントから見たときの“テーブルの探しやすさ”に効いてきます。
そのうえで、本記事で初めて深く登場する用語を以下に整理します。
エージェント: 本記事では「定期実行されて、データを読み、判断して通知する LLM スクリプト」 を指して使っています。チャットで人間が毎回プロンプトを叩く形ではなく、 スケジューラーで自動起動する LLM を「エージェント」 と呼んでいる、と思ってください。
cron: スケジュール起動の定番ツール。「毎週水曜の朝 8 時に起動」 のような定期実行を担う。本記事では GitHub Actions の schedule トリガが cron 相当
LLM-as-a-judge: 「LLM の出力を、別の LLM が評価する」 仕組み。人間が手で全件評価するのが大変な場合に、評価役の LLM (judge) にスコアを付けてもらう手法
評価のドリフト: LLM-as-a-judge が出すスコアの傾向が、プロンプトの古さやベースモデルのアップデート等で知らないうちにズレていく 現象
Workload Identity Federation（以下 WIF）: GitHub Actions などの外部サービスから、サービスアカウント鍵を持ち回さずに GCP リソース（BigQuery など）にアクセスする仕組み。本記事では BigQuery の認証で使用
何を「AI ネイティブ」と呼んでいるか
「AI 活用」って言葉は手垢がついていて、どうとでも解釈できてしまうので、最初に定義をハッキリさせておきます。
この記事で言う 「AI ネイティブなデータ基盤」 は、こういうものです:
LLM がデータ基盤の正規ユーザーとして扱われている
LLM が定期的に BigQuery を叩いて、判断して、人間に通知する仕組みが運用されている
人間が手動でやっていた集計・監視・分析作業の一部を、LLM が肩代わりしている
ポイントは「LLM が単なるツールじゃなく、定期実行されるエージェントとして基盤に組み込まれている」こと。チャットで人間が質問するのではなく、LLM 自身がスケジューラーやトリガーで起動して、データを見て、示唆・結論を出す。
エージェントの実装パターン
うちの場合は GitHub Actions の cron で起動するワークフローが、 LLM (Anthropic Claude) を呼び出すスクリプト を動かして、BigQueryを叩いています。
ここで重要なのが、エージェントが見にいく先は BigQuery 1 箇所 という点です。GCP 料金データも、LLM 評価スコア（後述の Langfuse 由来）も、dlt や同期ジョブ経由であらかじめ BigQuery に集約してあるので、エージェントは「BigQuery にある〇〇テーブルを SQL で読む」だけで仕事が完結します。これは Dagster 移行 3 部作で書いたデータが Bronze / Silver / Gold で綺麗に整っている効用そのものです。
BigQuery への認証はWorkload Identity Federation (WIF)経由で、サービスアカウント鍵を持ち回さずに済ませています。
具体例で見ていきます。
事例 1: GCP のコストを LLM が見張る
うちで最初に作ったのは Cost Watch Agent という、GCP の料金データを LLM が見て、異常があれば Slack に通知してくれるエージェントです。
仕組みはざっくりこうです:
毎週水曜の朝（JST 8:00）、cron で起動
BigQuery にエクスポートされている GCP 課金データの過去 30 日分を LLM が読む
「先週からコストが急増したサービスがあるか」「いつもと違う傾向があるか」を LLM が判断
異常があれば、原因の仮説と対応案つきで Slack に通知
通知内容そのものを BigQuery にも書き戻す（履歴として残し、後で「あの通知いつだっけ？」を SQL で検索できる）
Slack に来るのはこんな雰囲気のメッセージです（具体的な数字や対象は伏せた架空例ですが、構成は実物に近いです）:
💰 Cost Watch Agent (週次レポート)
過去7日でコストが特に増加したサービス:
- BigQuery: +35%（先週比）
→ 原因仮説: 大きい JOIN を含むダッシュボードクエリが頻発
→ 推奨対応: 該当クエリの partition pruning を確認
- Cloud Run: +12%（先週比）
→ 原因仮説: 新規デプロイした Service の min_instances 設定が高め
→ 推奨対応: トラフィックに対して妥当か再検証
何が嬉しいかと言うと、人間が定期的に料金ダッシュボードを眺めて「あれ、増えてない？」と気づく作業がなくなったこと。実際、人間がやると見落とすか後回しになるんです。LLM は週 1 回必ず見てくれるし、急増の閾値を超えたらちゃんと教えてくれる。
「人間がやるべきだけど、忘れがちな仕事」を LLM に任せる、典型例です。
事例 2: LLM の品質ドリフトを LLM が見張る
これは少しメタな話になります。
うちのプロダクトでは LLM が出す結果を、別の LLM で評価する LLM-as-a-judge という仕組みを使っています。LLM の出力品質が劣化していないかを、もう 1 段の LLM がスコアリングして監視する形ですね。
ところがこの LLM-as-a-judge そのものが劣化することがあります。プロンプトの古さ、ベースモデルのアップデート、データ分布の変化などで、judge が出すスコアの傾向が知らないうちにズレていく ─ これが冒頭の用語整理で書いた 「評価のドリフト」 です。
ここで登場するのが LLM Quality Agent です。仕事はこうです:
毎週水曜の朝（JST 7:30）、cron で起動
BigQuery に同期済みの Langfuse 評価データ（過去 1 週間分の LLM-as-a-judge スコア）を集計
過去のベースラインと比較して「平均が上がっていないか」「分布が偏っていないか」を LLM が判断
ドリフトを検知したら、 プロンプト修正の方向性も含めて Slack に通知
結果は BigQuery にも書き戻し、ドリフトの履歴を後追いできるようにしている
Langfuse のデータは別途 dlt で BigQuery にミラーされていて、エージェント側からは Langfuse 本体ではなく BigQuery のテーブル を見にいく形です。Langfuse → BigQuery の同期そのものについては、次の連載で詳しく書きます。
ここで面白いのが、LLM が 3 段で入れ子になっていることです。
1 段目: プロダクトの中で動いている LLM（ユーザー向けの出力を生成する）
2 段目: それを評価する LLM-as-a-judge（出力にスコアをつける）
3 段目: その judge の挙動を見張る LLM Quality Agent（スコアの傾向を監視）
「監視するもの」と「監視されるもの」が両方 LLM になっている、というだけじゃなく、 3 段とも LLM という構造です。
これも人間がやろうとすると、Langfuse のダッシュボードを毎週手で開いて、グラフをじっと眺めて、「うーん、最近スコアが上がりすぎてる気がするな」と勘で判断するしかない。勘の領域が、LLM の判断領域に変わったわけです。
事例 3: 技術トレンドを LLM が拾って共有する
最後はちょっと毛色を変えた話。Tech Trend Notification という、月曜と木曜の朝（JST 10:00）に技術トレンドを Slack に投げてくれるエージェントです。
事例 1・2 と違って、こちらは データ基盤を「読む」 のではなく、外部の世界 (ニュース検索 API や RSS) を LLM に読ませる タイプです。ただ、 集めた要約は BigQuery に書き戻して履歴を残している ので、 「LLM が定期実行で人間の代わりに作業し、結果をデータ基盤に残す」 という設計思想 は事例 1・2 と完全に同じ。応用範囲を広げる例として紹介します。
こんな感じで動きます:
月曜・木曜の朝、cron で起動
過去数日分の技術系記事・ニュース・OSS リリースを、検索 API と RSS から収集
うちの事業 / 技術スタックに関係する話題だけを LLM が抽出して要約
Slack で全社共有
同じ要約を BigQuery にも保存（後で「あの記事いつのだっけ？」を検索できる）
「技術ブログを毎日チェックして、関係ありそうなのを要約して、共有する」って、明らかに人間がやると続かない仕事です。続かないけど価値はある仕事こそ、LLM の出番です。
以下はSlackに来る通知の例です。
共通する設計パターン
3 つの事例に共通する構造を抜き出すと、こうなります:
[cron トリガ] → [LLM エージェント] → [データソース読み取り (BigQuery)] → [Slack 通知 + BQ 書き戻し]
各エージェントは小さくて、やっていることは限定的です。「人間が毎週手でやっていた小さな判断仕事」を 1 つだけ LLM に任せる、という単純な構造を、用途別にコピーしていく。
これが効くのには3つの理由があります。
LLM が読みやすい形でデータが揃っている: Dagster 移行 3 部作で書いた Dagster + dbt 基盤のおかげで、Bronze / Silver / Gold が綺麗に分かれていて、LLM が SQL を書くときにテーブル選択で迷わない
書き戻し（リバース ETL）の経験が活きている: Slack に通知するのも、BigQuery に書き戻すのも、本質的には「データ基盤からの出力」。3 部作で書いたリバース ETL の発想がそのまま使える
アウトプット先が Slack に統一されている: LLM の通知は全部 Slack に流れます。これが地味ですが効いていて、 人間は Slack だけを見ていれば LLM の出力を全部キャッチアップできる し、内容に違和感があればそのままスレッドで人間同士の議論に切り替えられる。 「LLM のアウトプットを人間がレビューする」 ループを Slack 上で完結 できる、というのは AI ネイティブ運用において思ったより重要な要素でした。新しい UI や別のダッシュボードを覚えなくていいのが大きい。
もう一つ大事なのが、通知結果そのものを BigQuery に書き戻している点です。「LLM が何をいつ言ったか」が SQL で追えるので、後から「最近、コスト警告が増えてないか？」みたいな メタ分析 もできます。エージェント自身の出力もまた、データ基盤の一部になるわけですね。
おわりに
データ基盤って「作って終わり」「ヒトが SQL で叩く前提」というイメージが強いんですが、最近やってみて思うのは、LLM が消費者として加わると基盤の価値が一段上がるということです。
ヒトが毎週手でやっていた監視作業を LLM に任せて、ヒトはその結果を見るだけになる。ヒトが本当に判断すべきところに集中できるようになる ─ あるいは事例 2 で書いた通り、 これまで「勘」 でやっていた領域を、LLM が代わりに判断してくれる ようになる。これが「AI ネイティブ」の実利だと思います。
次は予告通り、LLM 運用の中核ツールである Langfuse に関する連載を書きます。プロダクトに Langfuse を入れた話、そのログを BigQuery に流して分析基盤に載せた話。今回触れた LLM-as-a-judge のスコア も、実は Langfuse 経由で BigQuery に来ています。その裏側の話です。
次回予告
プロダクトに Langfuse を入れた話 ─ LLM 運用を “見える化” するまで
最後に
まだまだ発展途上のデータ基盤。これからも生成AI・LLMを使った改善を続けていきます！
データ基盤に興味がある方、LLMを活用した開発やデータ分析に興味がある方、ぜひお話ししましょう。
▼Scene Live 採用情報
▼bq事業のエンジニア採用
