📈

Jagu'e'r Looker User Meetup - なぜ今「セマンティックレイヤー」が熱いのか?生成AI時代のデータ活用の鍵

に公開

1. はじめに

株式会社 MBK デジタルの古畑です。
2025年9月26日(金)、Google渋谷ストリームオフィスにて、Google Cloudユーザー会「Jagu'e'r」主催の Looker User Meetup Part 4(データ利活用分科会 #29) が開催されました。

今回のテーマは、事前アンケートで最も人気の高かった 「セマンティックレイヤー」
初のランチ会として開催され、オフライン・オンライン共に多くの参加者が集まりました。
本記事では、Google様、アイレット様から語られた、生成AI時代におけるセマンティックレイヤーの重要性と、そのリアルな活用事例を詳細にレポートします。

2. イベント内容

オープニング

イベントは主催者からの挨拶で幕を開け、アジェンダが紹介されました。
Google様、アイレット様のセッション後に質疑応答が設けられ、オフライン参加者はGoogle Cafeでのランチ懇親会も予定されているなど、活発な交流が期待される雰囲気でスタートしました。

① Google様『セマンティックレイヤーと生成AI 〜データ分析の未来〜』

トップバッターは、Googleの山本様。
今、世界的に注目度が急上昇している「セマンティックレイヤー」がなぜ重要なのか、そして生成AIとの関係性やLookerの未来について、デモを交えながら解説してくださいました。

セマンティックレイヤーとは?

山本様は、セマンティックレイヤーの本質を ビジネスの言葉とデータの言葉の通訳者であると説明しました。
Looker における LookML がこれにあたります。

  • 役割:
    ユーザーが使う「売上」のようなビジネス用語を、データベースが理解できる SQL に自動で変換する。
  • 機能:
    • 指標の定義を一元管理し、誰が計算しても数字がブレないようにする。
    • 常に正しいルールでテーブルを JOIN する。
    • 計算効率の良い SQL を生成し、BigQuery などのコストを最適化する。
    • ユーザーに応じた行・列レベルの権限管理を行う。

これにより、ユーザーは裏側の複雑なデータ構造を意識せず、安心してデータ分析に集中できると強調しました。

なぜ今、世界的に注目されているのか?

その理由は、生成AIとの相性が抜群だからです。
セマンティックレイヤーがあるおかげで、「各店舗の月間売上データをください」といった自然言語での曖昧な質問に対し、生成AIがビジネス用語を正しく解釈し、正確なデータを返すことが可能になります。
山本様はこれを 鬼に金棒と表現し、その重要性を訴えました。

Lookerの新機能「会話型分析」と未来のロードマップ

このセマンティックレイヤーと生成AIを組み合わせた機能が、現在プレビュー中の 会話型分析 / Conversational Analysisです。

  • 概要:
    Lookerの画面上でチャット形式でデータに関する質問をすると、AIがLookMLの定義を解釈して可視化まで行ってくれる機能。
  • デモ:
    「人気の商品ランキングを作って」といった曖昧な質問に対し、AIが「人気」を「合計売上」と解釈して適切なグラフを生成。分析のハードルを劇的に下げる可能性を示しました。
  • ロードマップ:
    • コードインタープリター:
      「返品が多い理由は?」といった複雑な問いに、AIが複数分析を試してレポートを生成。
    • ダッシュボードへの統合:
      既存ダッシュボード上でAIと対話し、集計軸の変更や深掘りが可能に。
    • セマンティックモデルの自動生成:
      ER図などからLookMLの下書きを自動生成。

2年前は間違いだらけだった生成AIの進化スピードに触れ、これらの機能が当たり前になる未来はそう遠くないと締めくくりました。

② アイレット株式会社様『現場の課題から生まれたセマンティックレイヤー構築・運用術』

続いて登壇されたのは、アイレット株式会社の山田様。
現場での泥臭い課題と向き合いながら、いかにしてセマンティックレイヤーを構築し、運用してきたか。そのリアルな道のりを共有してくださいました。

Looker導入前の課題:指標のブレ

山田様のチームでは、元々OSSのBIツールRedashを運用していましたが、各々が直接SQLを書くため、同じ「対応率」という指標でも人によって集計結果が違うという問題が頻発していたそうです。
そこでLookerを導入し、LookMLで指標の定義を統一。これにより、ようやく データに基づいた健全な議論ができるようになったと語ります。

Looker導入後の新たな課題と解決策

しかし、Lookerを導入して全てが解決したわけではありませんでした。

  • 課題1: ライセンスの壁

    • 全員にライセンスを付与できず、データを見られる人が限られてしまう。
    • 対策:
      Looker APIとGoogle Apps Scriptを使い、レポートをSlackに定時配信する仕組みを自作。ライセンスがないメンバーにも情報を届けられるように。
  • 課題2: ダッシュボード作成の壁

    • SQLが書けないビジネスユーザーは、自分でダッシュボードを作れない。
    • 対策:
      Looker Studioを連携。
      Lookerで定義された信頼できる指標を、ユーザーがGUIで自由に組み合わせてレポートを作成できる環境を構築。

会話型分析を試して見えた「もう一歩先」

山田様も「会話型分析」を早速試したところ、シンプルな集計は成功したものの、対応率対応成功率のような、社内独自の微妙なニュアンスを持つ指標の解釈をAIが間違えるという課題に直面しました。
この経験から、山田様は生成AIを使いこなすための重要な提言をします。

  • 提言:
    • 生成AIには、セマンティックレイヤーに加えて アナリティクススペックが必要ではないか。
  • アナリティクススペックとは:
    • 山田様が提唱する AIへのデータ分析仕様書
    • 「AMS対応率の計算式はA÷Bです」「棒グラフで表示してください」といった、分析の文脈や計算式、アウトプット形式をプロンプトとしてAIに与えるという考え方。

AI任せにするのではなく、人間が文脈を適切に与えることでAIの精度を格段に上げられるという、今後のAI活用における重要な視点でした。

質疑応答ハイライト

Q. 会話型分析でBigQueryのコストが急増する懸念はないか?抑制する工夫は?

今回はAmazon Athenaの話になるが、基本的なガードレールが重要。分析エージェントに対し、「検索時は必ずパーティションを指定する」「何件以上は表示しない」といった指示を与えることでコストをコントロールしている。

Q. 「対応率」のような単語の解釈違いは、LookML(セマンティックレイヤー)側で吸収できないのか?

LookMLで対応率というメジャーを事前に定義すれば解決は可能。しかし、社内には「平均対応率」「平均成功率」など類似の指標が大量にあり、全てをLookMLで定義するのは現実的ではない。そのバランスをどう取るかが今後の課題。

まとめ

今回のLooker User Meetupでは、2社のセッションを通じて、セマンティックレイヤーが単なるBIの便利機能ではなく、生成AI時代のデータ活用において、人間とAIの共通言語となる極めて重要な基盤であることが浮き彫りになりました。

Lookerを、ビジネスの共通言語を定義し、信頼できるデータ活用の土台を築くツールとして捉え直すこと。
そして、生成AIに対しては、その土台の上で人間が「アナリティクススペック」のような適切な文脈を与え、二人三脚で分析を進めていくこと。
この2点が、今後のデータ活用の成否を分ける大きなポイントであると強く感じました。

また、セッション後のランチ会では、他のLookerユーザーやGoogle社員の方々と直接お話しする機会もあり、貴重な情報交換の場となりました。
登壇者の皆様、そして主催のJagu'e'r運営の皆様、素晴らしいセッションをありがとうございました!

GitHubで編集を提案
株式会社 MBK デジタル

Discussion