SQL不要？Google ADKでDWHと"対話"する分析エージェントを構築した勘所

Last updated at 2025-07-11Posted at 2025-07-11

はじめに

こんにちは！istyleのデータ分析システム部に所属しているやすです！
この記事ではデータ領域の職種の方向けに、データ分析業務を行うエージェントシステムの勘所をお伝えできればと思います。
※ あくまで、本番リリース前の検証段階で得られた知見です

複数のエージェントが協調して複雑なタスクを解決してくれる
基本構成は管理エージェントがいて、サブエージェントに適宜指示を出して解決を目指す
例えば、プロジェクトのように、プロジェクトマネージャーとスペシャリストがいるチームのような存在

生成AIというと、問い合わせに対して答えてくれるイメージもあると思いますが、エージェント・マルチエージェントは現実の仕事のように、他部門に仕事を依頼するように業務を遂行してくれます。

開発のモチベーション

データの専門家ではないメンバーが、データ抽出や分析をより気軽に行い、データの民主化を加速させたい
エージェント開発における知見やコストのナレッジを溜めたい
他社事例に刺激を受けて（大変参考にさせていただきました。感謝です）

2. Google ADK

Google ADKとは

エージェント開発キット（ADK）は、AIエージェントの開発と導入のための柔軟でモジュール化されたフレームワークです。GeminiとGoogleエコシステムに最適化されているADKは、モデルや導入に依存せず、他のフレームワークとの互換性も考慮して構築されています。ADKは、エージェント開発をソフトウェア開発に近い感覚で行えるように設計されており、開発者は単純なタスクから複雑なワークフローに至るまで、エージェントアーキテクチャを簡単に作成、導入、オーケストレーションできます。

要約すると、エージェント開発における特有の課題解決（セッション管理やエージェント間の連携など）や開発利便性を上げるための仕組みをGoogleがパッケージ化してくれたものです。
このパッケージを利用することで、中〜大規模なソフトウェア開発の経験がなくても、エージェント開発ができます。
私は普段データ基盤に関するインフラや分析のためのSQLしか書かず、pythonもそこまで習熟度は高くない状態ですが、サンプルも公開されているため今回の構築は容易にできました。

Google ADKサンプルシステム例

サンプルが公開されているので、基本のアーキテクチャなどはそれらを踏襲することで構築できます。
今回は、サンプルの中のデータサイエンティストエージェントを踏襲しました。

3. 作成したマルチエージェントシステム

BigQuery データ分析マルチエージェント

ユーザーのテーブルを探す要求や集計要求を理解し、適切なSQLを生成、BigQuery上で実行し結果を返却
ディメンショナルモデリングされたDWHを想定し、プロンプトを調整
※ 自社の課題とPoCを想定し、Google ADK サンプルより機能をダウングレードしています。サンプルでは、Vertex AIを利用した予測モデルの作成も可能です。

システム構成

Root Agent (管理エージェント)
├── BigQuery Schema Agent (BigQuery上のスキーマ情報取得)
└── BigQuery Runner Agent (BigQueryへSQL実行)

エージェントとツールの関係

Root Agent（管理エージェント）

役割: ユーザー意図の分析・分類と、サブエージェントへ適宜指示を出します

BigQuery Schema Agent

役割: BigQuery上のテーブル情報から、データベース構造の理解・説明を行います

BigQuery Runner Agent

役割: BigQueryへのSQL生成・実行、結果の整形

TIPS
各エージェントには挙動を定義づけるプロンプトを入力します。
例えば
管理エージェントであれば「あなたは回答の品質を一番大事にしてください」
サブエージェントには「あなたは実行の際に安全を大事にしてください」

当初は一つのエージェントではなく、なぜ複数エージェントが協調して課題解決しないといけないか理由がわからなかったですが、一つのプロンプトに例えば相反する or 複数のコンテキストが入ってしまうと、エージェントの挙動が不安定になり、同じ質問でも同一の回答ではなかったり、など不安定になります。そのためにも、管理エージェントとスペシャリストなエージェントを複数協調して、解決した方が結果として、実行の精度が高まるんだなと感じました。

データ構造

ディメンショナルモデリング

Dimension Tables: 商品、記事、会員、ブランド、クーポン etc. （計5テーブル）
Fact Tables: 購入、レビュー、いいね etc. （計3テーブル）
※検証用テーブルで10~100レコード
※BigQuery上にテーブルと各カラムの説明文が入っており、エージェントはそれらの情報を参考にしてタスクを実行していきます。

Google ADKのUI上による実行画面

Google ADKの便利なところは対話するUIが用意されているので、エージェントの挙動さえ定義すればすぐに試すことが可能な部分と、エージェント間のやり取りやコストに関わるプロンプトのトークンサイズが画面から確認可能な点です。

下記画像は、実際にエージェントと対話して「商品に関連するテーブルはどんなものがあるか」や「商品の売り上げを集計してください」と指示と結果のスクショです。
1枚目の画像では、「商品に関連するテーブルはどんなものがあるか」に対して、商品テーブルのみ回答してしまいましたので、「それだけではないです。ちゃんと探してください」と追加の指示を出しました。その後の正確な回答が返却されました。回答の不足は5回に1回くらい起きるので、改善余地のあるポイントですし、ここがエージェント開発の肝だと感じました。

実際に生成されたSQLは以下の通りで、結合や集計に問題はなさそうです。

SELECT
  t2.product_name,
  SUM(t1.quantity) AS total_quantity_sold,
  SUM(t1.total_amount) AS total_sales_amount
FROM
  `sample.sample.fact_purchase` AS t1
INNER JOIN
  `sample.sample.dim_product` AS t2
ON
  t1.product_id = t2.product_id
GROUP BY
  t2.product_name
ORDER BY
  total_sales_amount DESC
LIMIT
  80

4. 知見

エージェント開発で重要と感じたポイント

1. 一貫性 > 精度

過去: 回答の精度自体が満足いくものではなく、精度のチューニングが優先度が高い
現在: 生成AIの進化により精度は向上済みであり、LLM提供側での解決可能な問題に
今後: 回答の同一性、会社のコンテキストをいかに反映させるかが、開発においては重要

2. コンテキスト設計の重要性

注意すべきアプローチ
・とにかく学習・情報を渡せばよい ➡︎ ハルネーションの頻度高 & コスト増に

正しいアプローチ
・業務プロセスやスペシャリストのミッションなどを整理し、エージェントのコンテキストに反映

より詳細に知りたい方は以下のサイトを見てもらうといいかも

コストについて

1. 実際のトークン費用

検証におけるデータ分析セッションの実績と試算

1セッション平均のトークン量: 5000トークン（スキーマ調べて、データ抽出するまで）
1セッションあたりのトークン費用: 2円〜80円（モデルによって変動）
これらの情報をもとに例えば、ユーザー数 × 週の利用数 × 1セッション当たりの単価 などでコスト試算をしてみます。
ただし、1セッション平均のトークン量は扱うデータ量やプロンプトのやり取り回数に応じて、変動するため試算時は幅をもって計算することをお勧めします。

2. コストの削減ポイント

今回、コストにおけるチューニングは何も行っていませんが、一般的にはコンテキストサイズの最小化やエージェントに応じたモデル選択により、コストを最適化することができます。

まとめ

Google ADKを用いて、データ分析エージェントを構築しましたが、容易に構築することができました。データ基盤がGoogle Cloudであれば、連携も非常に簡単です。
今回は検証テーブルなので、テーブル数やカラム数が少ないですが、DWHが整備されていれば数が増加しても問題ないのではないかと思います。今後は本番実装に向け、その辺りを検証していきたいと思います。
また今後、このデータ分析エージェントに営業提案エージェントや在庫発注エージェントなどを作成し組み合わせていき、様々な業務を効率化・高度化できるのではないかと思います。

最後まで読んでいただき、ありがとうございました！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up