AI Meets Semantic Layers:Time to Insightを数週間から1時間に短縮するデータモデリング / gcdasummit_25f

■ イベント
Data & AI Summit '25 Fall
https://cloudonair.withgoogle.com/events/data-ai-summit-25f

■ 発表者
技術本部 研究開発部
小松 尚太

■ 研究開発部 採用情報
https://media.sansan-engineering.com/randd

■ Sansan Tech Blog
https://buildersbox.corp-sansan.com/

Transcript

1. 技術本部 研究開発部 ⼩松 尚太 AI Meets Semantic Layers: Time to Insightを数週間から1時間に 短縮するデータモデリング Data & AI Summit ’25 Fall ag-ui adk [Error [SocketError]: other side closed]
2. ⼩松 尚太 Sansan株式会社 技術本部 研究開発部 研究員 - 2020年5⽉⼊社 - データ活⽤チームのリーダーとして 社内外のデータ活⽤を推進 - 前職はコートジボワールにある国際農業研究機関
3. Sansanの解約分析を例に、 分析のリードタイムを短縮するための セマンティックレイヤー構築の具体プロセス 今⽇話すこと
4. Key messages - 価値あるインサイト創出の鍵はセマンティックレイヤー ⼈間が使えないデータはAIでも使えない - セマンティックレイヤー構築には、データ利⽤者とともに データの⽣成過程について理解を深めるプロセスが必須 - データの意味の定義と共有は⼈間の仕事
5. 会社概要 4 本社 神⼭ラボ Sansan Innovation Lab 社 名 Sansan株式会社 所在地 本社 東京都渋⾕区桜丘町1-1 渋⾕サクラステージ 28F グループ 会社 Sansan Global Pte. Ltd.（シンガポール） Sansan Global Development Center, Inc.（フィリピン） Sansan Global (Thailand) Co., Ltd.（タイ） ログミー株式会社 ナインアウト株式会社 株式会社⾔語理解研究所 従業員数 2,014名（2025年8⽉31⽇時点） 2007年6⽉11⽇ 設 ⽴ ⽀店：関⻄⽀店、福岡⽀店、中部⽀店 サテライトオフィス：Sansan神⼭ラボ、Sansan Innovation Lab、 Sansan⻑岡ラボ 拠 点 寺⽥ 親弘 代表者
6. 働き⽅を変えるAXサービス ⽣産性を向上させ、企業のAI活⽤を最⼤化するデータベースとしても貢献できる 「働き⽅を変えるAXサービス」を提供します。 データクオリティマネジメント 請求 名刺 管理 営業 契約 名刺管理から、収益を最⼤化する AI契約データベースが、利益を守る 経理DXから、全社の働き⽅を変える 名刺アプリ 経理DXサービス 取引管理サービス ビジネスデータベース 各サービスの活⽤で変わる働き⽅ 情報を分析・活⽤しやすく データに基づいた判断ができる 情報の管理がしやすく すぐに共有できる 必要な情報を すぐに⾒つけられる 個⼈向け 法⼈向け
7. 解約率: SaaSにとって重要な指標 2026年5⽉期 第1四半期決算説明資料より抜粋
8. 解約の分析で成し遂げたいこと - Life Time Value最⼤化、そのためのリソース配分最適化戦略の考案 - 組織横断で 「解約率をどう定義し、どう計測し、何を⽰す指標なのか」を ⼀貫したデータ定義・ロジック・指標の確⽴
9. 課題: 解約率計算ロジックの⼿運⽤・属⼈化 KPIポータル 複数データソース からの⼿動取得 スプレッドシート に集約し統合 結合した結果をもとに 解約率を計算
10. 課題: 解約に関するAd-hoc分析のリードタイムが⻑い 前の分析の数字と乖離が ⼤きい気がするが、 計算あってる？ ⋮ このカットで⾒た場合 どうなる？
11. 追加分析依頼に基づいて分析プロセスの再実⾏ KPIポータル 複数データソース からの⼿動取得 スプレッドシート に集約し統合 結合した結果をもとに 解約率を計算
12. 積み上がるスプレッドシートのシート
13. 理想に向かうための2つの鍵 計算ロジック の統⼀ Ad-hoc分析の リードタイムの短縮 1 2
14. Ad-hoc分析の リードタイムの短縮 2 理想に向かうための2つの鍵 計算ロジック の統⼀ 1
15. 計算ロジックの統⼀: 必要なFactの整備 ユースケースを⾒出して、それをもとに必要なFactを構築する。 データエンジニア カスタマーサクセス 事業企画 解約率の計算を⾃動化し、 定期レビューで使えるような ダッシュボードを作りたい。
16. ダッシュボード構築のデザインパターン 出典: https://www.digital.go.jp/resources/dashboard-guidebook
17. ダッシュボード利⽤想定者と⽬的をすり合わせる Why ダッシュボードの⽬的は何か？ - 必要な情報を ⼀元管理し、 様々なデータソースを ⾒に⾏かなくても Churnに関する分析 （⾦額、更新解約率、 Churn Rate等）が できること - 現場からのChurn分析 依頼に対して （ある程度）条件指定 のみでデータ抽出が できること 必要とされるデータ - Churn⾒込みデータ 週次での実績値と ⽬標値の推移グループ - Churn Rate グループ別 業種別 契約年数 利⽤率 活動 プラン 必要とされる機能 - Churnとなる原因が⾒ つけられる What, so What どんな意思決定や⾏動のために、 どのような情報を知るべきか Who, When, Where 誰が、いつ、どこで⾒るのか？ How 求められる機能やデータ項⽬は 何か？ 必要な更新頻度は？ - 未達⾒込みの場合その 要因を分析できる。デ ータを⾒ながら 打開策を議論できる - 優先的に取り組むべき 要素や施策を考える ために各種情報で 絞込を⾏う - ⽬標に対する進捗度を 確認しメンバーや 上層部に報告する - メンバー、マネジャー - 週次のチーム定例で 確認 - メンバー、マネジャー - 週次のチーム定例で 確認 - 部⻑、マネジャー - ⽉次 or Q単位で 数値振り返り・ 問題点の洗い出し
18. 具体ダッシュボードのイメージ 絞り込み 営業部署 CS部署 年⽉ 更新MRRレンジ プラン Edition 契約年数 ID数レンジ 従業員レンジ 業種 Premier
19. 解約というビジネスイベントを理解する 1. 解約流⼊ ある取引先の、ある契約が、ある理由でSansanを解約しそうであるということを、 契約の担当者が、解約案件として作成する。それを解約流⼊⽇とする。 1. 解約確定 ある取引先の、ある契約が、Sansanを解約すると意思決定し、契約の担当者が、 解約として確定とする。それを解約確定⽇とする。 1. 解約阻⽌ ある取引先の、ある契約が、Sansanの契約を更新すると意思決定し、 契約の担当者が、確定とする。それを解約について失注したとみなす。 契約開始⽇/⽉ 契約終了⽇/⽉ 解約流⼊⽇/⽉ 解約確定⽇/⽉ 1. 2. 3.
20. データソースと計算ロジックからデータリネージの作成 通過レート 案件 案件推移 利⽤状況 利⽤状況 解約案件 契約 契約請求先
21. LookMLによるFactの定義
22. Factの数値をデータの利⽤者と確認する
23. 時にはデータソース側の修正も⾏う
24. FactをLookerのダッシュボードで可視化する
25. 理想に向かうための2つの鍵 計算ロジック の統⼀ Ad-hoc分析の リードタイムの短縮 1 2
26. Looker Explore機能の開発者以外への解放 - ユーザーダッシュボードの 独り歩きを防ぐ観点から、 積極的に権限解放してこなかった - Ad-hoc分析を現場メンバーが 対応できるのが望ましいと考え、 ⼀部メンバーに展開を開始
27. あまりユーザーフレンドリーでないExploreの例 多すぎるフィールド 変数名そのままのフィールド 契約と契約請求先の違いとは？
28. 分析に必要なDimensionの洗い出し 主語 サブ区分 属性 詳細 重要度 顧客 Info 従業員数 従業員規模ごとにフィルタリングしたい ★★★★★ 所在地 所在地ごとにフィルタリングしたい ★★★★★ 業種 業種ごとにフィルタリングしたい ★ 有効ID数 ID数ごとにフィルタリングしたい ★★★ 利⽤数 ★★★ ★★★ ★★★ ★★★ 契約 Info ★★★★★ ★★★★★ ★★★★★ ★★★★★ 履歴 ★★ 解約流⼊ Info ★★★★ ★★★ ★★★★ 履歴 ★★★ ★★ 活動 履歴 ★★★★★
29. Dimensionの洗い出しに基づいたExploreの再構成
30. 解約分析のデータ整備による成果 分析のリードタイムは2, 3⽇に短縮できたが、⽬標の1時間には届かず
31. AI活⽤の話は？
32. AI以前に⼈間が使いやすいExploreを作れているか？ Lookerのセマンティックレイヤーから⽣成AIでインサイトを得るには、 ⼈間にとっても使いやすいExploreになっているかが鍵ではないか？ 使いやすいExploreの例 - ⽬的別で分割されている - 余計なフィールドが⼊っていない - DescriptionやLabelが適切に振られている
33. とはいえ分析のリードタイム短縮に向けてAIも活⽤します 計算ロジック の統⼀ Ad-hoc分析の リードタイムの短縮 1 2 AIによる貢献が 期待できる部分 もここ
34. Ad-hoc分析のさらなるリードタイム短縮を狙う ここまで構築してきたセマンティックレイヤーに対してAIを活⽤し、 Ad-hoc分析をデータ利⽤者がより⾏いやすくできないか？
35. PoCアーキテクチャ BiigQuery MCP Client (Claude, Gemini CLI) Looker
36. 社内検証の進め⽅ 実⾏者がローカルにMCPサーバーを⽴てて実⾏
37. - 「0件でした。条件を変えてやり直します」を繰り返す - 結果の取得失敗に伴いデータ検索が多くなり、 トークンを多く消費する - 試⾏錯誤の末それらしい結果は出るものの、 出⼒品質がいまいち - 実際の営業メンバーにも協⼒してもらい、定性評価 データモデリングを特に⾏わずそのまま試した場合
38. なぜうまくいかないか？ - 似たようなテーブルが乱⽴していると、 誤ったテーブルを元に集計される - 取引先/契約請求先/契約/契約明細... - created_at と registered_at の違い - コンテキストがないと限界がある - 「解約」というイベントにいくつかバリエーションがあり、 LLMがそのケースごとに判断が不可能
39. AIがうまく解釈できない⼀例
40. Lookerのセマンティックレイヤーに対する検証 - 課題であったトークン消費量やツール使⽤回数は概ね削減できる - 使⽤するテーブルを限定したり、リレーションがモデル上で 定義されたことで、クエリの試⾏回数が減ったことに起因 - LookMLに定義されたMeasureをもとに Factを正しく計算できる - 「解約率」「更新解約率」についてそれぞれMeasureとして 定義されており、AIが必要なFactを正しく算出することが可能
41. 再掲: LookMLによるFactの定義
42. synonyms を通じてAIにデータの意味を教える
43. 再掲: ⼈間が使いやすいExploreを作れているか？ Lookerのセマンティックレイヤーから⽣成AIでインサイトを得るには、 ⼈間にとっても使いやすいExploreになっているかが鍵ではないか？ 使いやすいExploreの例 - ⽬的別で分割されている - 余計なフィールドが⼊っていない - DescriptionやLabelが適切に振られている
44. 解約分析から⾒えた セマンティックレイヤー構築の本質
45. - データから⽰唆を得るリードタイム Time to Insight の ボトルネックは「データの探索・加⼯・抽出」であり、 これはデータを扱うのが⼈間だろうがAIだろうが変わらない。 - これらを⽀援する分析⽤のデータマートが整備されていれば、 スプレッドシート + Geminiでも迅速な分析は可能になる。 AI時代に求められるセマンティックレイヤーの構築とは？
46. - データ⽣成過程 (システム的、⾏動的、統計的) の理解は、 AIが⽀援できる領域が拡⼤している。 - しかし、「データをどう定義し、どう解釈し、どう共有するか」 という設計は、依然として⼈間の仕事である。 AIに踊らされすぎず、⽬の前のデータに向き合おう データ⽣成と構造設計に腰を据えて向き合うことが、 データから価値あるインサイトを⽣み出す営みにおいて、 最もリターンの⼤きい投資である。