LookML が Knowledge Catalog に自動で入る - AI エージェントが指標の定義を参照できるようになった（GA）

はじめに

Google Cloud 上の Looker で、LookML の定義が Knowledge Catalog に自動で取り込まれる機能が一般提供（GA）になりました。

一言でいえば、AI エージェントが「指標の計算式や結合の関係」を、Looker で定義したものとして参照できるようになる機能です。エージェントが SQL を毎回推測して書く必要がなくなる、というのが狙いです。

本記事では、公式ブログの内容を整理し、使うための条件と設定の流れをまとめます。なお、本記事は公式発表をもとにした整理で、実際の環境で試した結果ではありません。

1. 何が発表されたのか

一言で

Google Cloud 上でマネージド提供される Looker（Looker (Google Cloud core)。以下、Looker Core）の LookML が Knowledge Catalog に自動でインデックスされるようになりました。

Knowledge Catalog は、Google Cloud のメタデータ管理・データガバナンスのサービスです（旧称 Dataplex）。テーブルのスキーマ、データの流れ（リネージ）、ビジネス用語集などを横断して管理します。

LookML は、Looker で指標や結合の関係を定義するための言語です。ここでは、BI で使う指標の定義を書いたファイルと考えてください。

この機能の対象

対象は Looker Core のみです。公式ドキュメントでは、Looker は次の 3 種類のインスタンスに分けて説明されています。

種類	内容
Looker（オリジナル）	Looker がホストする従来型
セルフホスト型 Looker（オリジナル）	利用者が自前のインフラで運用する型
Looker Core	Google が Google Cloud 上でホストする、マネージド型

Looker Core は、Google Cloud コンソールからインスタンスを作成・管理する形態です。セルフホストやマルチクラウドでは使えません。Knowledge Catalog との連携は、この Looker Core 固有の機能として整理されています。

使えるかどうかは、まず自分の Looker がどの種類かを確認してから、という順番になります。確認方法は、後の節で触れます。

2. なぜ必要なのか

具体例：指標の定義がぶれる

公式ブログは、AI エージェントがデータウェアハウスへ直接 SQL を書く場合の問題を 2 つ挙げています。

1 つ目は指標定義のドリフト（毎回の推測による定義のずれ）です。たとえば「純売上高」を、注文ステータスが完了（order_status = 'Complete'）のものだけで集計する、というルールがあるとします。エージェントがこのルールを知らないと、未完了の注文も含めて集計してしまいます。

2 つ目はファンアウト（結合による行の重複）です。請求書、明細、返金のテーブルを安易に結合すると、1 対多の関係で行が重複します。その結果、売上などの合計が実際より大きくなります。

どちらも、エージェントが「テーブルは見えているが、その業務での意味は知らない」ために起きます。

2 種類の文脈

公式ブログは、エージェントには次の 2 種類の文脈が必要だと整理しています。

• 広い組織の文脈：テーブルスキーマ、リネージ、ガバナンス、ビジネス定義
• 決定論的なビジネスセマンティクス：指標を定義する SQL 式、結合パス、フィルタ規則（決定論的とは、同じ質問に対していつも同じ定義が使われる、という意味です）

前者は Knowledge Catalog が、後者は LookML が担います。今回の機能は、この 2 つを同じ場所で参照できるようにするものです。

3. 何がインデックスされるのか

LookML の例

何が取り込まれるのかを見る前に、LookML がどんな見た目かを確認します。以下は、機能の説明用に私が作った例で、公式ブログのコードではありません。

explore: order_items {
  always_filter: {
    filters: [orders.created_date: "last 90 days"]
  }

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

view: orders {
  measure: net_revenue {
    type: sum
    sql: ${TABLE}.amount ;;
    filters: [status: "Complete"]
  }
}

この例には、次の 3 つが書かれています。

• relationship: many_to_one：結合のカーディナリティ（行の対応関係）。ファンアウトを防ぐ手がかりになる
• always_filter：常に適用するフィルタ
• net_revenue：完了した注文だけを合計する指標の定義

エージェントが推測していた部分が、LookML では明示された定義として書かれています。

取り込まれる対象

公式ブログでは、解決済みの LookML モデル、Explore、ビュー、リネージ、ダッシュボードが対象とされています。

対象	主な内容
モデル	説明、データベース接続、include の階層、データテスト
Explore	結合（sql_on、relationship など）、必須フィルタ（always_filter、access_filter）、スターター クエリ
ビューとフィールド	コンパイル済みの SQL 式、主キー、タイムフレーム、フィールドの類義語、派生テーブルの変換ロジック、パーティションとクラスタリングのキー
ダッシュボード、Look、タイル	フィルタ、グラフの種類、所有者、利用統計、BigQuery のテーブルからタイルまでのリネージ

先ほどの例でいえば、結合の relationship や always_filter が、そのまま Explore の情報として取り込まれる形です。

4. どう動くのか

同期

• 本番環境の LookML に push した変更は、ニアリアルタイムで Knowledge Catalog に反映されます。
• 新規のインスタンスでは、デフォルトで有効です。利用者側の操作は要りません。

利用経路

経路	内容
Gemini Enterprise	Knowledge Catalog を有効にすると、スキーマ、用語集、LookML のロジックを 1 ステップで検索できる
自作のエージェント	LookupContext API で、同じ情報をまとめて取得できる

推奨される 2 段階の流れ

公式ブログが推奨するエージェントの動きは、次の 2 段階です。

1. 文脈とガバナンスの確認：Knowledge Catalog で、対象のモデルが認定済みか、列ごとのタグはどうなっているかを確認し、質問を LookML のフィールドに対応づける
2. 決定論的な実行：エージェントが SQL を即興で書くのではなく、LookML の定義に基づいて SQL を作る

回答には、メジャーとフィルタが設定済みの「Looker Explore で開く」リンクが付きます。利用者は、行レベルの明細まで 1 クリックで掘り下げられます。

3 つの構成の比較

公式ブログは、次の質問を例に 3 つの構成を比較しています。

前会計年度の第 4 四半期における商品カテゴリ別の総収益と、適用される地域ごとのプロモーション ポリシーの制限を教えて。

構成	内容	公式ブログの評価
1	DWH に直接 SQL を書く	ガバナンスが効かず、結果がぶれる
2	Knowledge Catalog の文脈だけを使う	ガバナンスは効くが、計算が不一致になりうる
3	Knowledge Catalog と LookML を併用	定義が揃い、SQL の再試行が減る

5. 使うための条件と設定

公式ブログに書かれている条件

• Looker Core を使っていること
• プロジェクトで Cloud Dataplex API と Data Lineage API を有効化していること
• 利用者に、次の閲覧ロールを付与していること
  • roles/dataplex.viewer
  • roles/looker.schemaViewer
  • roles/datalineage.viewer
• Gemini Enterprise から使う場合は、BigQuery などのデータストアを連携クエリモードで接続していること

設定の流れ

1. Looker Core で、メタデータのインデックスが有効になっていることを確認する（新規インスタンスはデフォルトで有効）
2. 上記の API を有効化し、閲覧ロールを付与する
3. Gemini Enterprise の管理画面で、[構成]、[アシスタント] の順に開き、[Knowledge Catalog を有効にする] をオンにして [保存して公開] を押す

利用者は、自分が IAM 権限を持つデータだけを検索・クエリできます。

自分の Looker が Core かを確認する

Looker Core は、Google Cloud コンソールからインスタンスを作成・管理する形態です。そのため、Google Cloud コンソールの Looker のインスタンス一覧に載っているかが、確実な確認方法です。

インスタンスの URL の形だけで判別する方法は、私が確認した公式ドキュメントには見つかりませんでした。URL は参考程度にとどめ、コンソールで確認するのが安全です。

料金

公式ブログによると、Looker のテクニカルメタデータの保存に、追加料金は発生しません。BigQuery のクエリ料金や Gemini Enterprise の利用料金については、記載がありません。

6. まとめ

何が起きたのか

Looker Core の LookML が Knowledge Catalog に自動でインデックスされるようになりました。モデル、Explore、ビュー、リネージ、ダッシュボードが対象です。

何を解決するのか

AI エージェントが SQL を推測して書くことで起きる、指標定義のずれと、結合による行の重複を減らします。

どう使うのか

Looker Core で API の有効化とロールの付与を行い、Gemini Enterprise で Knowledge Catalog を有効にします。自作のエージェントなら LookupContext API を使います。

前提

対象は Looker Core のみです。まず、自分の Looker がどの種類かを確認する必要があります。

7. ポイント

Looker（オリジナル）では使えないのか

公式ブログの対象は Looker Core です。オリジナル版の扱いについては、公式ブログに記載がありません。オリジナル版の利用者は、使えるかを公式ドキュメントで確認する必要があります。

既存のインスタンスでも自動で有効になるのか

新規インスタンスではデフォルトで有効、と書かれています。既存のインスタンスの扱いは、公式ブログに記載がありません。

Looker の会話型分析とは何が違うのか

公式ブログは、2 つを使い分ける考え方を示しています。

• Looker の会話型分析：BI の中で、あらかじめ用意した特定の Explore に対して質問する専用のアシスタント
• Knowledge Catalog と Looker の組み合わせ（Gemini Enterprise 経由）：BigQuery などの複数のデータソースや文書を横断して質問する。多数のモデルから、必要な定義を動的に探す

LookML は書いてあるだけで効くのか

ここからは、公式ブログの記載ではなく、私の解釈です。

取り込まれるのは LookML に書かれている内容です。結合の relationship や、必須フィルタ、類義語、説明文が書かれていないと、取り込まれる情報も少なくなります。機能を入れるだけで精度が上がるのではなく、LookML をどれだけ丁寧に書いてあるかが効くのだと考えています。

本番への push が AI の参照先にも反映される

これも私の解釈です。本番の LookML に push した変更がニアリアルタイムで反映されるため、定義の変更が AI の回答に直結します。LookML のレビューやテストの重みが、これまでより増すと思います。

8. 感想

公式ブログを読んでまず良いと感じたのは、「指標の定義を 1 か所に置いて、人と AI が同じ定義を使う」という考え方です。AI に SQL を毎回書かせると、同じ質問でも答えがぶれます。定義を LookML に集めておけば、BI のダッシュボードで見る数字と、AI が答える数字を、同じ定義にそろえやすくなると感じました。

もう 1 つ感じたのは、LookML の説明文や結合の書き方が、AI の精度を左右する資産になる点です。これまで BI の使いやすさのために整えていたものが、AI の時代には別の意味を持ちます。

一方で、公式ブログだけでは、効果が自分たちのデータでどれだけ出るのかは分かりません。まずは小さい範囲で試して、LookML の整備の度合いと、回答の質の関係を見てみたいと思います。

参考

• LookML メタデータのインデックス登録が Knowledge Catalog で GA に（Google Cloud Blog）
• Looker（Google Cloud コア）の概要
• Knowledge Catalog で Looker（Google Cloud コア）のメタデータを管理する
• Gemini Enterprise で Knowledge Catalog に接続する
• Knowledge Catalog