はじめに：広告分析における 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の回答精度が劇的に上がりました。

views/order_items.view.lkml

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が賢くなります。

models/marts/semantic_models.yml

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エージェントがそれを活用する

この順序を守り、泥臭い「データ定義」を積み上げた先にこそ、私たちが目指す「マーケティングプランニングや分析の自動化」という未来が待っているのだと感じています。

参考文献