Google Cloud · Field note

Looker Conversational Analytics の仕組みと設計判断 ── LookML セマンティックレイヤーが会話品質を決める理由

Looker Conversational Analytics が自然言語クエリを deterministic SQL に変換する仕組み、RBAC・行レベルセキュリティの継承構造、Known Limitations と LookML 整備度の関係、競合との構造的差分、トークン料金を整理します。

Google Cloud Looker BigQuery 生成AI 中級
Published
Read
15 min
Author
tgeas
目次
  1. Conversational Analytics の位置付け ── Gemini in Looker の一機能として
  2. 自然言語が SQL になるまで ── LookML フィールド照合と deterministic コンパイル
  3. 権限とセキュリティが継承される仕組み ── RBAC・行レベル制御・監査
  4. 「枠の外は答えられない」── Known Limitations と LookML 整備度の関係
  5. 他社アプローチとの構造的な違い ── LookML の code-as-infrastructure とマルチツール共有
  6. トークン料金と無料枠 ── 2026 年 10 月以降の超過料金試算
  7. まとめ ── LookML の整備が会話品質の上限を決める
  8. 参考文献

本記事では、Looker の Conversational Analytics ── 自然言語で Explore に質問できる機能 ── の仕組みと、実務で扱う際の判断材料を整理します。機能の位置付けと他の Gemini in Looker 機能との関係、自然言語クエリがどのような経路で SQL に変換されるか、権限設計とガバナンス統制の構造、Known Limitations とトークン料金、他社アプローチとの構造的な差分を順に扱います。仕組みと制約の両面を把握することで、自組織の LookML 整備状況を踏まえた導入計画の判断材料にしてください。

Conversational Analytics の位置付け ── Gemini in Looker の一機能として

Gemini in Looker は、Looker 上で動作する複数の生成 AI 機能の総称です。その中で Conversational Analytics は、Explore インターフェイス上で自然言語による問い合わせができる機能として位置付けられています。

2025 年 11 月 14 日に Looker (original) および Looker Google Cloud core の Explore ベース版が GA になりました。同名の Looker Studio 版は別製品であり、Preview 段階・LookML 非依存という異なる構成をとります。本記事のスコープは Explore ベース版です。

Gemini in Looker には Conversational Analytics 以外にも、複数の Explore にまたがる Cross-domain analysis (GA)、ダッシュボードに対話機能を追加する Dashboard Agents (Preview、Google Cloud Next ‘26 発表)、コードやクエリを生成・説明する各種 Assist 機能などが含まれます。Conversational Analytics はその中でも「Explore を起点にした対話型分析」の入口に位置します。

利用要件として、Looker (original) は v25.2 以上のホスト型、Looker (Google Cloud core) は Google Cloud コンソールから Gemini in Looker を有効化する手順が必要です。

自然言語が SQL になるまで ── LookML フィールド照合と deterministic コンパイル

Conversational Analytics の内部処理は、一般的な「LLM が SQL を直接生成する」アーキテクチャとは異なります。ここが仕組みを理解する上で最も重要な点です。

処理の流れを整理すると、次のようになります。

  1. ユーザーの自然言語入力を受け取る
  2. LookML のフィールドメタデータ (name / label / description / type / dimension_group) を照合し、該当フィールドを特定する
  3. Looker の Explore クエリとして構築する
  4. Looker の SQL コンパイラが deterministic な SQL を生成する

最終的な SQL は、LookML で定義された構造から deterministic に生成されます。LLM が直接 SQL を書くのではなく、LLM はフィールド照合と Explore クエリの構築を担い、SQL への変換は Looker の既存エンジンが行います。

この構造は、agentic フレームワーク・LookML・RAG (動的ナレッジグラフ)・ファインチューニング済みモデル (SQL・Python 生成用) を組み合わせて実装されています。

フィールドの description パラメータは、照合精度に直結する情報源です。

dimension: gross_revenue {
  type: number
  sql: ${TABLE}.gross_revenue ;;
  label: "粗利益"
  description: "返品控除前の売上高。税込み金額を含む。割引後の純売上とは異なる。"
}

description が空のフィールドや、ラベルが汎用的すぎるフィールドは、自然言語照合の精度が下がります。「粗利益」と「純売上」の違いをモデルが判別するには、description に業務文脈を明示することが判断材料になります。

回答の根拠を確認できる「How was this calculated?」機能も用意されており、使用したフィールド名・計算式・フィルタ・ソート順を平文で表示します。生成 AI の出力を受け入れる前に根拠を確認できる設計です。

応答モードは 2 種類あります。Fast Mode は単純な質問への高速応答を目的とし、Thinking Mode は複雑な分析向けにマルチステップ推論を行います。Thinking Mode は 2026 年 3 月のリリースで利用可能になっています。トークン消費量は Fast Mode より増えるため、後述のコスト試算では利用比率も判断材料に含まれます。

権限とセキュリティが継承される仕組み ── RBAC・行レベル制御・監査

Conversational Analytics のアクセス制御は、既存の Looker 権限構造をそのまま継承します。新たなアクセス制御レイヤーを追加する必要はありません。

RBAC 面では、Looker の access_data 権限に加えて gemini_in_looker・chat_with_agent・chat_with_explore といった専用権限が必要です。v25.18 以降では save_agents も追加されています。デフォルトロールとして Conversational Analytics Agent Manager / User / Admin の 3 種が用意されています。

行レベルセキュリティも継承されます。LookML の access_filter や access_grant、ユーザー属性 (user attribute) による制御は、Conversational Analytics を経由した問い合わせにも有効です。チャット経由で取得できるデータの範囲は、通常の Explore と同一です。

監査については、System Activity Explores の History Explore で API クライアント名 "Conversational Analytics" を条件にフィルタすることで、Conversational Analytics 経由の利用状況を追跡できます。

データ保護に関しては、顧客データ・プロンプト・出力は Google の生成 AI モデル学習に使用されません。データ at rest は Looker インスタンス内に留まる一方、リクエスト処理時のデータの取り扱い (リージョン境界の扱いなど) は Gemini in Looker の公式ドキュメントを参照する必要があります。FedRAMP High / Medium には現時点で対応していない点も確認しておくと安心です。

「枠の外は答えられない」── Known Limitations と LookML 整備度の関係

Conversational Analytics が回答できる範囲は、LookML で定義済みのフィールドの範囲に限定されます。これは制約であると同時に、設計上の必然でもあります。

LookML 未定義のフィールドは参照できず、カスタムフィールド (再利用・新規生成ともに) は非対応です。parameter や filter として定義した filter-only フィールドも対象外です。

数値面の制限を整理すると、次のとおりです。

  • Looker データソース: 1 質問あたり最大 5,000 行
  • 出力上限: 8,192 トークン (超過時は MAX_TOKENS エラー)
  • QPS: 全体 10、チャット 1
  • 可視化タイプ: Area / Bar / Geoshape / Heatmap / Line / Pie / Scatter の 7 種

Cross-domain analysis を使えばエージェント 1 つに最大 5 Explore を接続できますが、1 つの質問で参照する Explore は 1 つに限られます。ピボット (pivots パラメータ) は非対応で、データは long (flattened) 形式で返されます。

統計分析や予測は標準機能の対象外で、Code Interpreter (Preview、v25.18 以上が必要) を使うことで対応できます。VPC Service Controls など高度なネットワーク隔離構成と組み合わせる場合は、Conversational Analytics API の Known Limitations と Looker (Google Cloud core) のネットワーク要件をあわせて確認する必要があります。

Looker の公式内部テストでは「セマンティックレイヤー使用時に自然言語クエリのデータエラーが最大 3 分の 2 削減された」と報告されています [Looker 公式の内部テスト数値、外部検証なし]。この数字はフィールド定義の整備度に依存するため、LookML の品質が回答精度の上限を決めるという関係が成立します。

フィールドの description が空白のまま運用している Explore では、照合が曖昧になりやすいです。Conversational Analytics の導入前に、主要 Explore のフィールド定義を整備することが実務上の判断材料になります。

explore: orders {
  label: "受注データ"
  description: "受注ヘッダーと明細を結合した分析用 Explore。返品済み注文を含む。"

  join: order_items {
    type: left_outer
    sql_on: ${orders.id} = ${order_items.order_id} ;;
    relationship: one_to_many
  }
}

Explore 自体の description も照合精度に影響します。「このデータで何が答えられるか」を記述することが、Conversational Analytics が適切な Explore を選択するための文脈情報になります。

他社アプローチとの構造的な違い ── LookML の code-as-infrastructure とマルチツール共有

「何が AI のコンテキストになるか」という観点で、他の BI ツールのアプローチと比較します。機能の優劣ではなく、設計思想の構造的な差分を整理します。

Tableau Pulse / Agent との比較では、指標定義の管理方法が異なります。 Tableau はビジュアル設定中心の指標定義を採用しており、AI はその設定情報をコンテキストとして使用します。Looker の LookML は code-as-infrastructure として管理され、Git ワークフローでバージョン管理・コードレビューを適用できます。

Power BI Copilot との比較では、セマンティックモデルの共有範囲が異なります。 Power BI は DAX セマンティックモデルと Microsoft Copilot エコシステムとの統合を主眼としています。LookML は Looker–Power BI Connector (Looker v23.10 以降で GA) を介して Power BI Desktop の DirectQuery モードから Looker Explore のデータを参照でき、Connected Sheets や Looker Studio とあわせて複数のツールでセマンティックレイヤーを共有する設計が可能です。

LLM を直接 BigQuery に接続するアプローチとの比較では、テーブルスキーマがコンテキストになるかフィールド定義がコンテキストになるかが異なります。 スキーマ直接接続では、フィールドの曖昧さ・結合の誤り・指標の不統一が起きやすいです。LookML は「このフィールドが何を意味するか」「どのテーブルをどう結合するか」を事前に確定しているため、SQL の determinism を保てます。

この構造的な差分は、「LookML 未定義のフィールドは答えられない」という Conversational Analytics の制約と表裏の関係にあります。「枠の外は答えられない」という制約は、ハルシネーション抑制とガバナンス統制の構造的な根拠でもあります。

トークン料金と無料枠 ── 2026 年 10 月以降の超過料金試算

Looker 本体は年間契約のみで公開価格はなく、営業経由での見積もりが必要です。Conversational Analytics のトークン料金は各エディションに無料枠が付属しており、2026 年 9 月 30 日まではプロモーション期間として無制限アクセス (フェアユース内) が適用されます。

2026 年 10 月 1 日からの超過料金は次のとおりです (1 USD = 160 円換算、確認日: 2026-05-04)。

区分無料枠 / 月超過料金
閲覧者ユーザー入力 100 万 / 出力 2 万トークン—
標準ユーザー入力 200 万 / 出力 4 万トークン—
デベロッパーユーザー入力 400 万 / 出力 8 万トークン—
入力データトークン (超過分)—$3.00 / 100 万トークン (約 480 円)
出力データトークン (超過分)—$20.00 / 100 万トークン (約 3,200 円)

入力と出力の単価差が 6 倍以上ある点は、利用パターンによっては出力側で費用が集中する可能性があります。出力上限の 8,192 トークンという制約と合わせて、大量ユーザーが長い会話を繰り返すシナリオでのコスト試算を事前に行うことを推奨します。

まとめ ── LookML の整備が会話品質の上限を決める

Conversational Analytics の実力は、LookML セマンティックレイヤーの整備度に規定されます。フィールドの description が充実しているか、Explore のラベルが業務文脈を反映しているか、指標定義が一元管理されているか ── これらが AI の照合精度に直結します。

「枠の外は答えられない」という制約は、LookML で定義した範囲外の回答を生成しないという設計選択から来ています。これがハルシネーションを抑制し、既存の RBAC・行レベルセキュリティをそのまま継承できるガバナンス統制の根拠になっています。

導入を判断する際の実務的な視点として、次の 3 点が判断材料になります。

  • 主要 Explore のフィールド description が埋まっているか ── 「自然言語が SQL になるまで」で示したフィールド照合の起点。空白なら整備を先行させる
  • 答えてほしい質問の種類が Known Limitations の範囲内に収まるか ── 「枠の外は答えられない」で整理した行数 5,000・可視化 7 種・ピボット非対応・予測非対応 (Code Interpreter は Preview) の各制約と業務要件を突き合わせる
  • 2026 年 10 月以降のトークン超過料金を考慮したコスト試算が成立するか ── 出力単価が入力の 6 倍超で上限 8,192 トークン。利用人数とエージェント数を仮置きしてプロモーション期間中に実測する

LookML の整備が既に進んでいる環境では、Conversational Analytics は追加コストを抑えながら導入できる可能性が高いです。逆に LookML が未整備の状態で導入しても、AI が参照できる文脈が少なく期待した精度は得られません。会話品質の上限は LookML の品質が決め、それを超えることはない ── この構造を踏まえて導入計画を立てることが、会話品質を最大化する最初の一歩です。

参考文献

Author
tgeas

大阪の SIer 勤務。Google Cloud Partner Top Engineer 2026 / 2025 JAPAN All AWS Certification Engineers。インフラ・ネットワークからデータ活用と生成 AI 活用支援まで幅広く対応。