Looker Coreを使っている企業では、指標の計算ルールをAIエージェントにもそのまま参照させられるようになりました。計算ルールはデータ担当者が作ったものです。
対象はGoogle Cloud上で動くLooker Coreの利用企業です。Looker Coreを使っていない企業には、この発表は直接関係しません。
LookMLは、Lookerでデータの結合の仕方や指標の計算式を書くための言語です。今回の発表は、LookMLの定義をGoogleの「Knowledge Catalog」に自動で取り込む機能についてです。その機能（インデックス登録）が、一般提供（GA。本番で使える正式版）になりました。
Knowledge Catalogは、テーブルや文書の情報を集めて、AIエージェントが参照できるようにする仕組みです。Googleの公式ブログによると、今回の発表は日本語版です。英語版は米国時間10月27日に公開されました。
指標の計算式を、AIが推測せずに使う
AIエージェントは、データの置き場所を知っているだけでは正しい数字を出せません。売上や顧客獲得コスト（CAC。新規顧客を1人獲得するためにかかる費用）のような指標は、計算ルールで結果が変わります。
発表によると、AIが自分でSQL（データベースに問い合わせる命令文）を組むと、指標の定義がずれることがあります。たとえば、注文の状態（order_status）が「Complete」のものだけを売上に計上する、という会計ルールがあります。AIはこのルールを見落としてしまうおそれがあります。
テーブル同士の結合でも問題が起きます。請求書と明細、返金データのように1対多の関係があるとします。その結合の仕方を誤った命令文では、同じ行が重複して数えられるおそれがあります。その結果、合計金額が過大になるおそれがあると説明しています。
LookMLでは、こうした結合の条件や指標の計算式を、あらかじめ決めておけます。AIはその定義を参照するだけなので、実行のたびに計算方法を推測しなくて済みます。
今回の一般提供で、LookMLの定義はKnowledge Catalogの中で正式な層として組み込まれました。指標を見つけたエージェントは、その正確な定義を取り出せます。結合の経路や、元のテーブルまでのつながり（リネージ。データがどこから来て、どこで使われたかの流れ）も、同じ場所で取り出せます。
取り込まれるのは、LookMLのモデル、Explore（結合済みのデータを分析する入口）、ビューと指標、ダッシュボードとタイルです。同期は初期設定のままオンになっており、利用者が操作する必要はありません。本番環境のLookMLに変更を反映すると、ほぼリアルタイムでKnowledge Catalogに届きます。
Gemini Enterpriseからは、カスタムのAIエージェントを作らなくても使えます。Knowledge Catalogに接続すると、テクニカルなスキーマ、ビジネス用語集、LookMLの定義を1回の検索でまとめて探せます。
AIがデータを見るときは、利用者本人の権限が使われます。Gemini Enterpriseはエンドユーザーの認証情報で接続します。そのため、閲覧権限（例：roles/bigquery.dataViewer）を持つデータだけが検出され、照会されます。
発表では、ある質問を使って3つの方式を比べています。質問は「前会計年度の第4四半期における商品カテゴリ別の総収益と、地域ごとのプロモーションポリシーの制限」です。データベースに直接質問する方式では、1月開始の会計年度を勝手に想定するおそれがあります。未完了の注文まで数えてしまうおそれもあると説明しています。
LookMLの定義を組み合わせた方式では、計算の定義と結合の条件に沿ってSQLを組み立てるとしています。やり直しの回数も減るとしています。
サイソクは11月2日に報じています。Knowledge Catalogが定義の更新を自動で行う自己学習機能が、一部提供になったとのことです（Googleが「Knowledge Catalog」に自己学習機能 定義の更新を自動化）。
