SQLさよなら？！ Google Agent Development Kitで 「自然言語でデータ分析」エージェント作ってみた！ 🚀
>100 Views
November 24, 25
スライド概要
関連スライド
Meta XR SDK(V66-74)でQuestアプリを開発
あうぜん
1.1M
各ページのテキスト
SQLさよなら？！ Google Agent Development Kitで 「自然言語でデータ分析」エージェント作ってみた！ 株式会社電算システム 金 碩鴻（きむ そくほん） プリセールスエンジニア
本日の流れ AIエージェントとADKとは？ (The "What") デモ：Data Analytics Agent (The "How") 課題：現場で本当に使える？ (The "But...") 解決策：AIに「文脈」を教える (The "Solution")
1. The "What" - そもそも「AIエージェント」「ADK」とは？ ADK (Agent Development Kit) とは？ エコシステム (GCPでの動か し方) 目標を追求し、タスクを完了させる Google が開発したAIエージェントの Agent Engine: AIエージェントに最適 ソフトウェア システムです。 OSSフレームワーク。PythonやJava 化された実行環境。 AI エージェントとは？ AI を使用して、ユーザーの代わりに で利用可能です。 Gemini Enterprise: ADKを含む、 Googleのエージェントを呼び出すた めのプラットフォーム。
2. The "How" - 何が進化したのか？： これまで (Gemini in BigQueryなど) 自然言語 → SQLに変換し、「データ」（例: salesテーブル）に クエリを実行していました。 これは主に「データエンジニア」向けでした。
2. The "How" - 何が進化したのか？： 現在のADK GoogleのBigQueryのファーストパーティツールセットにより、 ADKで自然言語で、INFORMATION_SCHEMAを用いて、 BigQueryに対してクエリできるようになりました。
2. The "How" - 何が進化したのか？： INFORMATION_SCHEMA がなぜ重要か？ INFORMATION_SCHEMA は「データのためのデータ」です。 「どのテーブルが一番大きい？」「パーティションが切られてい ないテーブルは？」といった、 DB管理者やデータエンジニアの高度な質問にも答えられるように なります。
【DEMO】 BigQueryの"中の人"（DBA）に質問してみる 「プロジェクト内で、最もデータ量の多いデータセットを教えてください。」 「直近1ヶ月でデータ量が増えたデータセットは？」 「パーティション化されていない『巨大な』テーブルはどれか？」 （SQLだとリージョン指定やINFORMATION_SCHEMAのJOIN が面倒だけど、エージェントが全部やってくれる！）
課題提起：本当に「SQLさよなら」？ 自然言語でクエリが書けた！ ラッキー！ → 非エンジニアにとっては間違いなく朗報です！ しかし... 現場で本当に使えるでしょうか？ AIはユーザーの「意図」や「文脈」をどこまで理解できるのでしょう？
3. 課題①：スキーマ曖昧性 (Schema Ambiguity) 部署ごとの平均給与はいくらか？ 部署のテーブルって ｀current_departure｀と ｀departure_2022｀テーブル二つある。 どちらを見に行けばいい？ どのテーブルのどのカラムでクエリするのかが不明
3. 課題②：セマンティック曖昧性 (Semantic Ambiguity) 過去30日間で最も売れた商品は？ 「最も売れた」というビジネス上の定義は... 解釈A: 販売個数 (SUM(quantity)) が最多か？ 解釈B: 販売金額 (SUM(quantity * price)) が最 多か？ 解釈C: 注文件数 (COUNT(DISTINCT order_id)) が最多か？ ビジネスロジック上、複数の異なる計算方法で解釈できてしまう
3. 課題③：ドメイン曖昧性 (Domain Ambiguity) 今月の『アクティブユーザー数』を教えて スキーマに ｀active_users｀ というカラムはない。 社内定義は... 定義A: 「今月一度でもログインした人」か？ 定義B: 「今月一度でも課金した人」か？ 定義C: 「今月商品をゲットした人」か？ ユーザーは、DBに存在しない「社内用語」を使うが、 AIは理解できない。
3. 結局何が問題なのか？： AIは「コンテキスト」を知らない DBを操作するには、SQLの知識があれば良いわけではない。 ・DBに用いられている業務ドメインの知識 ・開発者の設計意図 ・プロダクトの歴史的背景 というコンテキスト（文脈）を理解してクエリする必要がある。 問い: これらの高度な「コンテキスト」を、どうやって生成AIに伝えれば良いでしょうか ？
4. スキーマ曖昧性への解決策：メタデータの強化 部署ごとの平均給与はいくらか？ ｀current_departure｀は現在の部署 ｀departure_2022｀は2022年時点での部署。 特に指定はないから、現在の部署でクエリする！ メタデータによって、マッピングがうまくいく。 ！
4. セマンティック曖昧性への解決策：聞き返す AIが「推測」するのを防ぐ 「過去30日間で最も売れた商品は？」 「確認です。『最も売れた』とは、販売個数と 販売金額のどちらで集計しますか？」 メリット: AIが「間違った答え」を自信満々に返すという最悪の事態を防げる 。 デメリット: 「毎回聞き返してくるAIは、ちょっと面倒...」
4. ドメイン曖昧性への解決策：RAG AIに「ドメイン知識の教科書」を渡す RAG:Retrieval-Augmented Generation 生成AIが回答を作成する際に、あらかじめ用意された社内文書やウェブサイトなどの信 頼できる情報源から関連情報を検索し、その内容を基に回答を生成する技術 コンセプト: ユーザーの質問に応じて、関連するコンテキスト（スキーマ定義、ビジネス ルール、過去のSQL例）を外部の知識ベース（Vector DBなど）から 動的に検索し、プロンプトに注入する 。
4. ドメイン曖昧性への解決策：RAG 1. 「今月のアクティブユーザー数は？」 6. 「 今月1000人です」 2. RAG: (知識ベースを検索) 4. 定義に沿ってSQLを生成 5. 結果を返却 3. 「今月一度でもログインした人」 という定義を発見
4. 最適解：メタデータ＋RAG ＋ 聞き返すエージェント 理想のアーキテクチャ: ・メタデータ（例：部署）でスキーマ曖昧性を解決。 ・RAGがドメイン曖昧性の質問（例：アクティブユーザー）を解決。 ・メタデータやRAGで解決できないセマンティック曖昧性（例：最も売れた商品） だけをユーザーに確認し、間違いを防ぐ。 →回答の精度とスピードを両立する
まとめ：AIエージェントは「育てる」もの ADKは「自然言語でデータ分析」エージェントを構築する 強力なフレームワークです。 しかし、「SQLが書ける」だけでは不十分。現場の 「コンテキスト（文脈）」をAIにどう伝えるかが鍵です。 メタデータ強化（基盤）に加え、RAG（教科書を与える）と 対話型エージェント（聞き返す）を組み合わせることで、 実用的なエージェントが実現します。