データ分析AI Agentを動かして気づいた、今の基盤に足りないもの

2026/02/25 STORES Data Lounge「AI時代のデータ基盤とデータ活用」
（https://hey.connpass.com/event/379343/）
発表時間：20分

データ分析AI Agent「Kepler」を動かして気づいた課題とその対応についてまとめました。

また、開発サポートAIの登場によって全社的にAI化が進む中でのデータ基盤開発の民主化や、AI時代にデータチームがどういう基盤（「STORES新聞」構想など）を目指していきたいかについてお話ししています。

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

Transcript

1. STORES 株式会社 AI Agentを動かして気づいた、 今の基盤に足りないもの STORES Data Lounge#1 AI時代のデータ基盤とデータ活用 2026年 2月
2. 自己紹介 小野 嵩征（おの たかゆき） WEB系の会社に新卒入社 WEBエンジニア → データエンジニア STORES株式会社 所属（2024年10月〜現在） アナリティクスエンジニア データ基盤の改善/データ活用推進を行っている 三重県在住 2
3. 複数プロダクトの成長を支える STORES のデータ基盤 3
4. 本日お話しすること 4 データ分析AI Agent Kepler のこれまで 実運用でぶつかった 基盤の壁 全社AI化の波と ボトムアップ の基盤構築 データチームが目指す STORES新聞 構想 01 02 03 04
5. 本日お話しすること 5 データ分析AI Agent Kepler のこれまで 実運用でぶつかった 基盤の壁 全社AI化の波と ボトムアップ の基盤構築 データチームが目指す STORES新聞 構想 01 02 03 04
6. Keplerとは 6 2025年9月30日から社内向けに開発した データ分析 AI Agent 簡単なデータを出せることを最初の目標と して構築 利用技術 • Google ADK • AgentEngine • Vertex AI RAG Engine • Next.js
7. Keplerでできること 7 スキーマ検索 SQL実行 SQL生成 Python実行 年×カテゴリごとの売り 上げ推移可視化し、傾 向について分析してく ださい 依頼 回答
8. テーブル検索の過程や生成したSQLもKeplerが教えてくれる 8
9. Kepler 利用ログやフィードバックを眺める 9 みんなのKeplerへの「問い」からスキーマ検索の重要性に気づく このテーブルの status カラムはどういう意 味？ 売上を集計したいけど、どのテーブルを使えば いい？ 法人番号のデータはある？ • 直接欲しいテーブルやカラムを指定 して分析する人が少ない • データが場所を検索するために Keplerを利用する人が存在 → データ分析よりもデータ探しの精度を あげることの需要が高いことが判明
10. スキーマ検索時の課題 10 • 結合のためのキーのミス • 似たテーブルの誤用 • WHERE 条件の漏れ → プロンプトで挙動制御するにも限界が... BigQuery のスキーマ情報のみだと
11. スキーマ検索の改善 11 ゴールデンクエリをRAG Engineに登録 # 1. AIが検索するためのコンテキスト（用途） name: "monthly_sales_by_category" description: "月次・カテゴリ別の売上集計クエリ。" use_cases: ["売上推移", "カテゴリ別売上", "売上合計"] # 2. 迷わせない「結合の正解」と「業務ロジック」 sql: > SELECT d.year_month, p.category_name, SUM(f.gross_sales) AS total_sales FROM `stores.mart.fct_orders` f -- 正しいディメンション（切り口）の結合 JOIN `stores.mart.dim_dates` d ON f.date_id = d.date_id JOIN `stores.mart.dim_products` p ON f.product_id = p.product_id WHERE f.status = 'completed' -- 暗黙の業務ロジック（完了分のみ） AND f.is_test = FALSE -- AIが間違えやすいテスト除外 GROUP BY 1, 2 ※架空のクエリ 1. 結合キーとテーブルの正解を示 す 2. 暗黙の業務ロジックを埋め込む 3. AIのための検索タグ → スキーマ検索時の補完に利用
12. ゴールデンクエリを登録した結果 12 ゴールデンクエリ スキーマ SQL作成/実行 1. 依頼に関連したクエリを検索 2. 依頼に関連したクエリをもとに テーブルのスキーマを検索 3. 検索した結果を元に依頼を達成す るためのSQLの生成と実行
13. 導入後効果 自分が欲しい時/知りたい時 データに関することを聞けるように • データ基盤に欲しいデータ（テーブル / カラム）があるかの調査 • 簡単なデータ抽出/集計 → とりあえず Keplerに聞いてみよう or 聞いてみた という文化が生まれた 13
14. Q. 変化はあったが、 Keplerによって データの民主化 は達成された…か？
15. データ基盤の課題が顕在化 A. 第一歩は踏み出せたが、 曖昧な問いから真の課題解決まではいけない
16. 本日お話しすること 16 データ分析AI Agent Kepler のこれまで 実運用でぶつかった 基盤の壁 全社AI化の波と ボトムアップ の基盤構築 データチームが目指す STORES新聞 構想 01 02 03 04
17. 壁① コンテキスト不足 17 テーブル定義 だけでは伝わらない「暗黙知」 テーブル定義にカラム説明を書いても、AIは「行間」が読めない • テスト除外の暗黙ルール 「売上集計ならテストデータは除外する」が テーブル定義には書かれていない • プロダクト固有の業務ロジック ステータスの意味、集計期間の慣習、特定条件の除外など「人には当たり前」の知識 • カラム説明だけでは不十分 description を書いても、AIが「どう使うべきか」の文脈は伝わらない → AIが間違えるのはAIのせいではなく、基盤が「暗黙知」を教えきれていないから
18. 壁① 解決策 18 3つの情報源で「暗黙知」をカバーする • ゴールデンクエリだけでは限界がある より深いビジネスロジックを記述しようとすると社内ドキュメントと二重定義に陥りや すい • 複数の情報源を網羅的に参照させる 1. 社内ドキュメント：ビジネスメンバーが定義した業務ロジックや用語の定義 2. ゴールデンクエリ：結合ロジック・暗黙の業務ルールの正解例 3. GitHub コード：データの発生方法・実装の背景 • データマートの要件定義を補完 複数ソースの横断参照で、テーブル定義だけでは伝わらない文脈を補う → より曖昧な指示からでもAgentがデータ分析を行える世界を目指す
19. コンテキスト不足を補うためにチーム全員でAI Agentとメタデータ拡充 19 後で紹介予定の全社のSlack botの取り組みに参画しつつ AI Agent と協力しテーブル / カラムのメタデータを埋めていく
20. 壁② 柔軟ではないデータモデリング 20 KeplerはOBT + αのテーブルを参照していたが、、 OBTの「作り方」に課題がある • 再利用可能な構造で作れていない OBT改修時の影響範囲が広がり、変更のス ピードが落ちてしまう • 全ての分析要件を1テーブルで叶えようとし てカラム数が増加 分析シナリオに対してどのカラムを使うかの 選択難易度が高い状態に → ディメンショナルモデリングの上にOBTを作るのが理想
21. 壁② 解決策 21 ディメンショナルモデリング（スタースキーマ）への再構築 • ファクトとディメンションの分離 ファクト（事実）= 売上、注文などの数値デー タ、ディメンション（切り口）= 日付、商品、 顧客などの分析軸 • AIが多角的に自律分析できる構造へ 依頼者の問いに合わせて切り口を自由に組み合 わせて JOIN できるスタースキーマが AI 向き • アナリスト巻き込みのモデリング勉強会を開催 中 データアナリストの知見を取り込み、実務に即 したモデル設計を推進 引用) アジャイルデータモデリング 組織にデータ分析を広める ためのテーブル設計ガイド
22. 壁③ データ基盤のアップデート速度 22 データチームがスピードのボトルネックに • 安全に開発できる「ガードレール」の不在 適切な権限整理ができておらず、他部署のメンバーがデータ基盤の開発に参加する　　　 ハードルが高い。 　　 • 開発環境が民主化されていない AIを使って他部署からPR（Pull Request）を出せても、手元で適切な検証が完結でき ない。 　　 ※ PMや他エンジニアの人からPRは出してもらえてる • 結果：タスクの一極集中 検証・リリース作業がデータチームに集中。 AIで分析が高速化しても「データがない」状態ですぐに足止めを食らってしまう。
23. 壁③ 解決策 23 データ基盤開発の民主化 • 開発環境のセットアップ方法を他プロダクトに揃える データチーム固有の開発体験ではなく STORES のプロダクトとしての開発体験へ • 適切な権限設計 開発に必要なロールをPrivileged Access Manager（PAM）を使って 一時的に付与する仕組みの導入
24. Privileged Access Manager（PAM） 24 • 事前定義した権限を一時的に付与・管理 （申請した期限が切れると自動で権限を剥奪） • コンソール または gcloud コマンドから申請 人やAI Agentが必要な時に権限を申請する • 申請/承認履歴を保持し、監査性を確保
25. 本日お話しすること 25 データ分析AI Agent Kepler のこれまで 実運用でぶつかった 基盤の壁 全社AI化の波と ボトムアップ の基盤構築 データチームが目指す STORES新聞 構想 01 02 03 04
26. 組織に押し寄せる「全社AI化」の波 26 STORES の開発全般をサポートする Slack bot Kuroの登場 • 強力な開発サポートAIの稼働 技術推進本部の主導により、 先週から全社Slack bot「Kuro」が稼働開始。 • ナレッジアクセス 社内のGitHubリポジトリから 社内のドキュメントまで、開発に必要な コンテキストを網羅的に閲覧可能。 • Slackで完結する「自律的な実行力」 Slackからの指示だけで、プロダクトのPR作成 　　 やブラウザの自動操作まで代行してくれる。
27. Kuroの登場によってデータ基盤が嬉しいこと 27 STORES の開発全般をサポートする Slack bot Kuroの登場 • 強力な開発サポートAIの稼働 技術推進本部の主導により、 先週から全社Slack bot「Kuro」が稼働開始。 • ナレッジアクセス 社内のGitHubリポジトリから 社内のドキュメントまで、 開発に必要なコンテキストを網羅的に閲 覧可能。 • Slackで完結する「自律的な実行力」 Slackからの指示だけで、プロダクトのPR作成 　　 やブラウザの自動操作まで代行してくれる。
28. KuroとBigQueryを接続して新たな 分析 AI Agentを模索中 28 MCP BigQuery MCP • 安全なBigQuery 操作 （コストを抑える機能付き） • Keplerで作成していたゴールデンク エリのtool 全社ナレッジ ゴールデン クエリ データ基盤
29. ダミーデータでのそれっぽい分析イメージ 29
30. 組織に押し寄せる「全社AI化」の波 30 BIの「外側」で加速するデータ分析 ビジネスメンバーのAI利用 • KuroをきっかけにBigQueryとの疎通をMCP化したことで Claude Code / Cursor 等でもBIを介さない分析が行われるようになっていく • 今後BIツールを経由しないレポーティングが爆発的に増えていく すでに一部のPMの方がレポートを作り始めている → データ利活用のハードルが下がるのはいいこと
31. Claude Code × BigQuery MCP 利用者も徐々に増加中 31 来週の月曜日にClaude Code セットアップ会開きます
32. 組織に押し寄せる「全社AI化」の波 32 AI時代、正確性とスピードの両立は難しい 事業のフェーズによってスピードと正確性の求めるバランスは変わるもの 今のフェーズは「100点満点のダッシュボード」を数日かけて作るよりも 「80点でも今すぐわかるスピード」を優先するフェーズだと思う。 AIによるカオスな独自分析をルールで縛るのではなく、 カオスを受け入れた上で基盤自体をどうすればよりよく成長させていける かを考えるのが重要。
33. 問いを資産にするボトムアップアプローチ 33 ユーザーの「問い」から 基盤を進化させる AI Agentに集まる「みんなの問い」の ログを分析。需要の高い問いを抽出し、 AIのための「ゴールデンクエリ」として 登録・データマートへ反映し続ける サイクルの確立。
34. みんなで育てるデータ基盤 34 ユーザー 全社Slack bot AI Agent 自律的に分析・判断 データ基盤 ゴールデンクエリ データマート ディメンショナルモデル メタデータ 問い 分析結果 ゴールデンクエリの登録 データ追加（PR） ユーザーも直接PRで貢献 Kepler 運用で気がついた課題を解決し、 Kuro をデータ分析の流れに組み込 むと みんながAI Agentで分析を自律的に進めながらも安全に基盤強化していく未来が作れる
35. 本日お話しすること 35 データ分析AI Agent Kepler のこれまで 実運用でぶつかった 基盤の壁 全社AI化の波と ボトムアップ の基盤構築 データチームが目指す STORES新聞 構想 01 02 03 04
36. データチームが目指す STORES 新聞 構想 36 「個人の問い」を全社の資産へ BI時代は共有されなかった個人の問いが、 AI Agentにすべて集約。 『STORES 新聞』の創刊 大量の問いから有意義な分析をAIが要約 し、新聞化。新聞化していくことで昔の新 聞を読めば組織の変化も追うことができ る。 新聞を起点とした業務の拡張 ゴールデンクエリの拡充や、基盤へのPR作 成など、「データ」から始まる業務バリ エーションを増やしていく。 売上は？ 顧客層は？ トレンド？ 在庫は？ 成果は？ AI STORES新聞 STORES新聞 STORES新聞
37. 最後に 37 AI Agentは組織のデータ力を映す鏡 AIが動かないのは、我々が教えきれていないから。 AIの進化を待つだけでは AIの真価を発揮できない 今からAIがフル活用できる基盤とエコシステムを作りに行く。 AI Agent を使わない前提であれば、現状のデータ基盤維持でもいいが、 AI Agent を組み込んだ上でデータで組織を成長させていくには とりあえず AI Agentを入れて課題を顕在化させるのが第一歩だと思う。