AIが活躍できるデータ基盤を目指して

2025/9/30 AI時代の意思決定を支える 各社のデータ基盤Lunch Talk

STORES 株式会社
データ本部 データ基盤グループ
小野 嵩征（ono.takayuki）/ アナリティクスエンジニア

登壇前日に社内にリリースしたデータ分析Agentについて
AIが活躍しやすいデータ基盤にするために取り組んでいることについてお話ししました。

1. STORES 株式会社 小野 嵩征 AI時代の意思決定を支える 各社のデータ基盤Lunch Talk 2025年 9月 AIが活躍できるデータ基盤を目指して
2. 自己紹介 小野 嵩征（おの たかゆき） WEB系の会社に新卒入社（2020年4月） WEBエンジニア → データエンジニア STORES株式会社 所属（2024年10月〜現在） アナリティクスエンジニア データ基盤の改善/データ活用推進を行なっている DATA Saber 中部コネクトで、コミュニティ活動中 2
3. 本日お話しすること 3 1. 開発中の社内向けデータ分析 Agentのお話し 2. AI（データ分析 Agent Kepler）が活躍できる基盤にするための取り組み
4. 目次 4 会社概要 STORES のデータ基盤 AI Agent Keplerについて AIが活躍するためにやっていること さいごに 01 02 03 04 05
5. 目次 5 会社概要 STORES のデータ基盤 AI Agent Keplerについて AIが活躍するためにやっていること さいごに 01 02 03 04 05
6. 会社概要 6 会社名 STORES 株式会社 設立 2012年3月23日 代表取締役社長 佐藤裕介 資本金 1億円 所在地 〒150-0011 東京都渋谷区東3丁目16番3号　エフ・ ニッセイ恵比寿ビル4階 事業内容 インターネットビジネスの企画・開発・ 運営
7. サービス紹介 7 お店のデジタルを まるっとサポート。 個人や中小事業の方々に向けて、 お店のデジタル化をまるっと 実現できる価値を提供しています。
8. サービス紹介 8 他　合計10個のサービスを提供
9. 目次 9 会社概要 STORESのデータ基盤 AI Agent Keplerについて AIが活躍するためにやっていること さいごに 01 02 03 04 05
10. STORESのデータ基盤 10
11. STORESのデータ基盤 11
12. STORESのデータ基盤 12 データ分析 AI Agent Keplerくん
13. 目次 13 会社概要 STORES のデータ基盤 AI Agent Keplerについて AIが活躍するためにやっていること さいごに 01 02 03 04 05
14. AI Agent Keplerについて 14 データチームが社内に提供する データ分析Agent （9/29リリース） データから軌道を発見し、 ビジネスに繋げることを期待してKeplerと命名 データ基盤利用者のデータ活用をサポートする仲間
15. Keplerでできること 15 スキーマ検索 SQL実行 SQL生成 Python実行 年×カテゴリごとの売り 上げ推移可視化し、傾 向について分析してく ださい 依頼 回答
16. Keplerでできること 16
17. システム構成 17 利用技術 Next.js Google Agent Developer Kit Cloud Run Cloud SQL Cloud Storage BigQuery MCP Toolbox for Databases
18. なぜ作ったのか 18 データ基盤利用者の最初の壁をなくし、ビジネスを早く進めるため
19. データ活用のサイクル 19 課題 データ収集 集計/分析 企画立案 行動 振り返り サイクルを早く回せれるほどビジネスも早く進みやすい
20. データ活用のサイクル 20 課題 データ収集 集計/分析 企画立案 行動 振り返り 最初の壁
21. データ活用を回すための最初の壁 21 データ基盤からデータを取り出し、課題解決を行うためにはハードルが存在 1. SQL/BIの知識が必要 2. 複数サービスのドメイン知識が必要 3. データがどこにあるかわからない 4. データ抽出後にデータを有効に使う方法がわからない
22. データ活用を回すための最初の壁 22 データ基盤からデータを取り出し、課題解決を行うためにはハードルが存在 1. SQL/BIの知識が必要 2. 複数サービスのドメイン知識が必要 3. データがどこにあるかわからない 4. データ抽出後にデータを有効に使う方法がわからない → データチームに依頼する or サポートを受ければ解決するが、 　タイミングによっては依頼からリードタイムが発生することがある。 　人のリソースは有限。
23. Keplerの登場により 23 1. SQL/BIの知識が必要 2. 複数サービスのドメイン知識が必要 3. データがどこにあるかわからない 4. データ抽出後にデータを有効に使う方法がわからない
24. Keplerの登場により 24 1. SQL/BIの知識が必要 → KeplerがSQLを生成/実行 2. 複数サービスのドメイン知識が必要 3. データがどこにあるかわからない 4. データ抽出後にデータを有効に使う方法がわからない
25. Keplerの登場により 25 1. SQL/BIの知識が必要 → KeplerがSQLを生成/実行 2. 複数サービスのドメイン知識が必要 → Keplerが社内ドキュメントを検索（展望） 3. データがどこにあるかわからない 4. データ抽出後にデータを有効に使う方法がわからない
26. Keplerの登場により 26 1. SQL/BIの知識が必要 → KeplerがSQLを生成/実行 2. 複数サービスのドメイン知識が必要 → Keplerが社内ドキュメントを検索（展望） 3. データがどこにあるかわからない → Keplerがスキーマ/カタログを検索 4. データ抽出後にデータを有効に使う方法がわからない
27. Keplerの登場により 27 1. SQL/BIの知識が必要 → KeplerがSQLを生成/実行 2. 複数サービスのドメイン知識が必要 → Keplerが社内ドキュメントを検索（展望） 3. データがどこにあるかわからない → Keplerがスキーマ/カタログを検索 4. データ抽出後にデータを有効に使う方法がわからない → Keplerがデータ分析をサポート
28. Keplerと協力して最初の壁を壊してデータ活用を進める 28 データ活用 最初の壁
29. 目次 29 会社概要 STORES のデータ基盤 AI Agent Keplerについて AIが活躍するためにやっていること さいごに 01 02 03 04 05
30. AIが活躍するためにやっていること 30 1. よく使うテーブルをまとめたワイドテーブルの作成 2. スキーマ情報の集約 3. dbt docsの内容をNotionに連携 4. Keplerへのフィードバックをもとに基盤とKeplerの改善
31. AIが活躍するためにやっていること 31 1. よく使うテーブルをまとめたワイドテーブルの作成 2. スキーマ情報の集約 3. dbt docsの内容をNotionに連携 4. Keplerへのフィードバックをもとに基盤とKeplerの改善
32. Keplerがスキーマ検索時に困ること 32 ネットショップのxx分析して テーブルA テーブルA´ テーブルA´´ 依頼 回答 似たテーブル、 似たカラムが多い → 試行錯誤が多くなる → 意図しない結果になる
33. ワイドテーブルの作成 33 STORES サービス STORES サービス STORES サービス サービスに特化した ワイドテーブル STORES サービス STORES サービス STORES サービス サービスをクロスして 見たい時の要件をあつめた ワイドテーブル AIにとっても 人にとっても便利
34. AIが活躍するためにやっていること 34 1. よく使うテーブルをまとめたワイドテーブルの作成 2. スキーマ情報の集約 3. dbt docsの内容をNotionに連携 4. Keplerへのフィードバックをもとに基盤とKeplerの改善
35. 各サービスの最新のスキーマを1つのリポジトリに集約 35 schema変更でトリガー schema 集約リポジトリ RDB DDLに 変換&コミット 各サービス リポジトリ GitHub Actions CREATE TABLE … schema.sql
36. 各サービスの最新のスキーマを1つのリポジトリに集約 集約リポジトリ スキーマ変更通知 開発時に参照 スキーマ検索時に 開発リポジトリの テーブル/カラムコメント を見にいく
37. AIが活躍するためにやっていること 37 1. よく使うテーブルをまとめたワイドテーブルの作成 2. スキーマ情報の集約 3. dbt docsの内容をNotionに連携 4. Keplerへのフィードバックをもとに基盤とKeplerの改善
38. dbt docsについて 38 dbt モデルファイル 特に制御しなければ全モデルがdbt docsに出る 加工レイヤーも反映
39. dbt docsに求める情報の粒度の違い（開発者） Exposures が見たい 特定のsourceに依存したモデルを確 認したい 見たい情報が多い
40. dbt docsに求める情報の粒度の違い（データ基盤利用者） 情報量が多い モデル名表記なので分かりにくい etc . 関心のある情報のみが出るのがベスト
41. スキーマ検索 利用体験向上のため dbt docsに出すモデルの量を減らしたりして 基盤利用者用のdbt dcosを提供すれば緩和されるかもしれないが
42. スキーマ検索 利用体験向上のため dbt docsに出すモデルの量を減らしたりして 基盤利用者用のdbt dcosを提供すれば緩和されるかもしれないが → 情報量減らした上で検索体験を高めたい。 全社的に利用頻度の高いツールNotionへ移行
43. dbt docsの内容をNotionに連携
44. 利用者用のカタログをNotionにしてみて Notion AI によって検索体験が上がった
45. 利用者用のカタログをNotionにしてみて dbt の ymlを変更しなくてもデータカタログの情報を増やせるように
46. 利用者用のカタログをNotionにしてみて Keplerがスキーマ検索時にNotionのデータも複合的に見れるように（展望） ネットショップ の 売上について教えて 社内用語/テーブルの利用優先度 スキーマ検索 データが発生するロジックを検索 依頼 回答
47. AIが活躍するためにやっていること 47 1. よく使うテーブルをまとめたワイドテーブルの作成 2. スキーマ情報の集約 3. dbt docsの内容をNotionに連携 4. Keplerへのフィードバックをもとに基盤とKeplerの改善
48. フィードバックの収集 48 Keplerの回答に対してのフィードバックを収集
49. Keplerの改善 49 • UI 改善 ◦ SQLをコピーできるボタンをつけて欲しい ◦ 文字サイズを大きくして欲しい ◦ チャットの送信をSlackと同じ形式にして欲しい（Enter改行） • Agent 改善 ◦ xxx のデータも追加して欲しい ◦ Agentのレスポンスを早くして欲しい ◦ システムプロンプトの改善
50. データ基盤の改善 50 KeplerのセッションDBの活用（展望） Google Agent Developer Kitを利用するとCloud SQLに ユーザーとAgentのやり取りログが保存される。 保存されたやり取りログとフィードバックを使って基盤の改善に活かす
51. データ基盤の改善 51 BigQuery ジョブ実行履歴+セッションDBを使って基盤の継続的な改善 ジョブ実行 履歴 利用ログ 需要の高い テーブル 問い合わせを 抽出 データ基盤への データ追加/データマート改善
52. 目次 52 会社概要 STORES のデータ基盤 AI Agent Keplerについて AIが活躍するためにやっていること さいごに 01 02 03 04 05
53. さいごに 53 • AI が活躍する基盤を目指すのであれば、まずはAIに働いてもらうのが大事 • AI が活躍することは暗黙知を表出化する行為 ≒ 人も便利になる • AI が活躍することがわかれば、全社的にメタデータを集めるとかデータマー トを整備すると言ったことがやりやすくなる
54. まずはAIに働いてもらう - Google Agent Developer Kit 54 Google Agent Developer Kitを使う場合は 1. BigQueryのプロジェクトと検証用のデータセットを一つ作成 2. adk-sample にアクセス 3. python/agents/data-science のREADMEを参考にセットアップ 4. README通りにデプロイ 5. Cloud Runで動くデータ分析Agentの完成
55. 55 ありがとうございました！
57. #2C85DE #F79A40 #EB75AA #EE5253 #10AC84 #6833D4 #0AB0DE #F5CC00 Text A Text Text Text Text Text Text Text Text Text A Text Text Text Text Text Text Text Text