はじめに：広告分析における Text-to-SQL の限界と「Agentic BI」への期待
生成AIの活用が進む中、データ分析の実務においても「自然言語によるクエリ（Text-to-SQL）」への期待が高まっています。しかし、実務の中でかなり役に立っているというお話はあまり聞きません。
例えば、「先月のA社のキャンペーン実績を出して」といった単純な集計は可能でも、以下のような「要因特定」や「複合的な分析」を求めると、途端に破綻してしまいます。
- 「キャンペーンAのCPAが高騰しているが、主要因はCPCの上昇か、CVRの低下か？ 媒体別・デバイス別に分解して特定して」
- 「ラストクリックベースではなく、アトリビューションを加味した広告効果を算出して」
これらの問いに答えるには、単にテーブルを集計するだけでなく、ビジネスロジックに基づいた指標の選択や、適切なドリルダウンが必要です。データベースには「結果」しかなく、「分析の文脈」が含まれていないため、従来のAIでは対応が困難でした。
そんな中、2025年に入り、AIが自律的に思考・探索を行う「Agentic BI（エージェント型BI）」が登場し、状況が変わりつつあります。
- Google Cloud: Gemini in Looker
- Databricks: Genie Research Agent
本記事では、これら最新機能を対象に、広告分析の実務に耐えうるかを検証しました。結論として、ツールを導入するだけでは不十分であり、AIに分析の作法を教え込む「セマンティックレイヤー（データの意味定義）」の設計こそが、分析自動化の成否を分ける要因であることが判明しました。
以下、両ツールの検証結果と、実務でワークさせるためのデータ基盤設計について詳述します。
1. Google Looker (Gemini): LookMLというセマンティックレイヤーの活用
まず調査したのは、Google LookerのGeminiです。
Lookerといえば LookML（独自の定義言語）ですが、GeminiもこのLookMLを徹底的に活用する設計になっていました。アプローチを一言で言うなら「ガバナンス（統制）」です。
アーキテクチャ：AIはSQLを書かない
Geminiの面白い点は、「AIがSQLをゼロから書かない」ことです。
AIはユーザーの質問を、一度Looker内部の論理的なクエリ構造に変換します。SQLの発行は、長年鍛え上げられたLookerのエンジンが行います。これにより、「AIが勝手な計算式でSQLを発行してしまう」という事故を構造的に防いでいます。
実装の勘所：AIへの「コンテキスト注入」
調査して分かったのは、LookMLの description（説明文）が、実質的な「AIへのプロンプト」になっているということです。
例えば、「利益」の定義。単に計算式を書くだけでなく、以下のように「どういう文脈で使われるか」まで書き込むと、AIの回答精度が劇的に上がりました。
view: order_items {
sql_table_name: `project.dataset.order_items` ;;
# ポイント1: フィルタのハードコード（AIのミスを物理的に防ぐ）
measure: total_gross_margin {
type: sum
sql: ${sale_price} - ${inventory_items.cost} ;;
filters: [status: "complete"] # ← キャンセル分は自動で除外される
# ポイント2: AIへの指示書となる説明文
description: "
粗利益（Gross Margin）。売上から原価を引いたもの。
ユーザーが '利益' や '儲け' と聞いた場合は、迷わずこの指標を使用すること。
※キャンセルステータスの注文は自動的に除外済み。
"
value_format_name: jpy_integer
}
# ポイント3: 分析軸の定義
dimension: region_group {
type: string
sql: CASE
WHEN ${users.country} IN ('Japan', 'China', 'Korea') THEN 'Asia-Pacific'
ELSE 'Rest of World'
END ;;
description: "地域分析用のグルーピング。アジア太平洋かそれ以外かで分類。"
}
}
検証結果:
「アジアの利益率は？」と聞くと、Geminiは定義された total_gross_margin と region_group を正確に選びました。
「決まった指標を、誰でも簡単に、間違いなく出せる」。これがLookerの強みだと感じました。
2. Databricks (Genie Research Agent): 「仮説検証」までやる自律型AI
次に調査したのはDatabricksのGenie、特に新機能の Research Agent です。
こちらはLookerとは対照的で、「もっと自由に、泥臭い分析をやらせる」アプローチでした。単にSQLを返すのではなく、「仮説を立てる → 検証する → 結論を出す」という、人間のアナリストのような動きを模倣します。
アーキテクチャ：複合AIシステム
Genieは、「Unity Catalog（メタデータ）」と「ナレッジストア（指示書）」、そしてLLMが連携して動く「複合AIシステム（Compound AI System）」です。単一のモデルではなく、複数のコンポーネントが協調して答えを導き出す点が特徴です。
実装の勘所：ナレッジストアへの「作法」の登録
Genieを賢くするには、LookMLのようなコードではなく、「分析のヒント」や「信頼できるSQL」を登録するのが効果的でした。
Genie Space設定 (General Instructions):
「分析するときは、こういう観点で見てね」という指示書を書きます。
# 分析の観点
売上減少の原因分析を行う際は、以下の順序で要因を掘り下げてください。
1. 地域別トレンド (Region)
2. カテゴリ別トレンド (Category)
3. 配送ステータス (Shipping Status)
# ビジネス定義
- 「アジア地域」とは、Regionテーブルの `name = 'ASIA'` を指します。
- 「出荷遅延」とは、`shipdate` が `commitdate` を過ぎている状態です。
Trusted Asset (SQL登録):
複雑なロジック（例：出荷遅延率）は、あらかじめSQLとして登録しておきます。これを「Trusted Asset（信頼できる資産）」としてAIに渡すことで、計算ミスを防ぎます。
-- Name: 出荷遅延率_地域別
-- Description: 地域ごとの注文総数に対する、約束日を超過して出荷された注文の割合。
SELECT
n.n_name as nation,
COUNT(CASE WHEN l.l_shipdate > l.l_commitdate THEN 1 END) * 1.0 / COUNT(*) as delay_rate
FROM lineitem l
JOIN orders o ON l.l_orderkey = o.o_orderkey
-- (以下省略)
検証結果:
Research Agentは、ユーザーの「なぜ？」という質問に対し、上記のTrusted Assetを利用して「アジア地域の遅延率」を計算し、それが原因である可能性を提示しました。これは「探索的分析の自動化」に近い体験です。
3. 比較：どっちを使えばいいの？
調査結果をまとめると、両者は「競合」というより「使い分け」の関係に近いことが分かりました。
| 特徴 | Google Looker (Gemini) | Databricks (Genie Research Agent) |
|---|---|---|
| AIの思考モデル | Deterministics (決定的)：定義されたレールの上を正確に走る。 | Probabilistic & Agentic (確率的・自律的)：仮説を立てて、探索する。 |
| セマンティックレイヤー | 必須 (LookML)：これがないとほぼ動かない。 | 推奨 (Knowledge Store)：なくても動くが、あると精度が激増する。 |
| 回答プロセス | ユーザー質問 → 定義検索 → 回答 | ユーザー質問 → 仮説立案 → 検証SQL×N回 → 結論 |
| 得意なこと | 正確性・ガバナンス：「今月のKPI報告」など、間違いが許されない場面。 | 深掘り・要因特定：「KPIがなぜ下がった？」「次どうする？」といった探索的分析。 |
4. 私たちが目指すべき「分析自動化」のアーキテクチャ
さて、ここで一つの課題にぶつかります。
「Looker用の定義と、Databricks用の定義、二重管理したくない…」
両ツールとも強力ですが、それぞれのツールに別々の定義を書き込むのは運用の悪夢です。そこで、調査の結果たどり着いたのが、「dbt Semantic Layer」をハブにするアーキテクチャです。
推奨アーキテクチャ：dbtを中心にした「意味」のハブ化
実装イメージ：dbtでの一元定義
dbtで指標を定義し、それを各ツールに供給します。こうすれば、ビジネスロジックの変更（例：売上の計上基準が変わった）があっても、dbtを修正するだけで全ツールのAIが賢くなります。
semantic_models:
- name: orders
model: ref('orders')
entities:
- name: order_key
type: primary
measures:
- name: late_shipping_count
agg: sum
# GenieのTrusted Assetと同じロジックをここで一元管理！
expr: CASE WHEN shipdate > commitdate THEN 1 ELSE 0 END
metrics:
- name: late_shipping_rate
label: "出荷遅延率"
type: ratio
type_params:
numerator: late_shipping_count
denominator: total_order_count
5. まとめ
今回の調査で、「AIにデータを渡せば勝手に分析してくれる」というのは幻想だと分かりました。
しかし、逆に言えば、「人間がデータの意味（Semantics）さえ正しく定義してあげれば、AIは驚くほど優秀なアシスタントになる」ということです。
重要なのは、AI導入を単なるツール導入として捉えるのではなく、「ボトムアップデザイン（Bottom-up design）」のアプローチで進めることです。
- データレイヤー: データソースを整備する（dbt）
- セマンティックレイヤー: データの意味を定義する（LookML / Knowledge Store）
- アプリケーションレイヤー: AIエージェントがそれを活用する
この順序を守り、泥臭い「データ定義」を積み上げた先にこそ、私たちが目指す「マーケティングプランニングや分析の自動化」という未来が待っているのだと感じています。