データ基盤構築・運用の現場から 〜 Snowflake Intelligence 導入で変わった、データ活用の未来 〜

2026.05.22
The Snowflake Data Cafe @West

Transcript

1. SNOWFLAKE DATA CAFE 2026 データ基盤構築‧運⽤の現場から Snowflake Intelligence 導⼊で変わった、データ活⽤の未来 株式会社ヌーラボ Daisuke Onoe 
2. WHO I AM ⾃⼰紹介 Daisuke Onoe @wonohe 所属 株式会社ヌーラボ Reliability Engineering 部 Platform Unit 経歴 法⼈営業からキャリアをスタートし、フロントエ ンド∕バックエンドエンジニア、開発チームマ ネージャー、業務ハックエンジニアを経て、現職 ABOUT これまで、これから 全社におけるデータ基盤構築‧マネジメント と、社内全体のデータ活⽤推進活動を担当 社内データ基盤刷新プロジェクトのリーダーと して、Snowflake の導⼊を主導 Snowflake Intelligence を中⼼とした AI 活⽤ と、スケーラブルなデータ基盤の構築に取り組 んでいます 2 / 31
4. AGENDA 今⽇、お話しすること 01 10 min なぜ Snowflake だったのか データ基盤刷新の背景、4 つの決定的な強み、 移⾏プロジェクトの実際とそのインパクト 02 10 min Snowflake Intelligence 導⼊実践 現場の学び、3 つの実践ポイント、 そしてデータ⺠主化の現在地 4 / 31
5. PART 1 なぜ Snowflake だったのか データ基盤に求められる質の変化、そして Snowflake を選んだ 4 つの理由
6. ARCHITECTURE 現在のデータ基盤 6 / 31
7. BACKGROUND データ基盤の始まりは、上場準備 01 上場のための指標算出 上場のための指標を算出する ための基盤が必要で、ダッ シュボードなどでの レポーティングが主な⽤途 02 複雑なビジネスロジック 精緻な数字が求められるため、 複雑なビジネスロジックを含む 03 厳密な権限管理 重要な情報も扱うため、デー タチームのみがアクセス可能 な権限管理 IRのための指標算出とレポーティングが⼤きな⽬的だった 7 / 31
8. EVOLUTION 上場後、求められるデータ活⽤が質的に変わった PHASE 1 〜 上場まで レポーティング 売上‧契約数を「正しく⾒せる」 ダッシュボードで定型の数字を確認 ダッシュボード提供で⼗分に事⾜りる規模 → PHASE 2 上場後 〜 現在 意思決定 事業を動かすためのデータ活⽤へ より⾼度な分析‧⼤規模データ処理 ビジネス部⾨の⾃⾛への期待 数字を"⾒せる"基盤から、意思決定を"⽀える"基盤へ 8 / 31
9. THE TURNING POINT 旧データ基盤での問題 01 重く⻑いクエリの対応 意思決定に必要な分析が複雑化 し、⼤規模データを扱える基盤 が必要に。Amazon Athenaで はパフォーマンスのスケール アップが難しかった 02 IR と密結合な データ基盤 旧データ基盤 は IR データを扱 う基盤のため広く開放できず、 社内でのデータ活⽤はすべて データチームが対応しないとい けなかった 03 限定的なロール設計 社内の多様な役割に合わせた ロール設計ではなく、セルフ サービス環境を推進するため にはもっと柔軟な形にする必 要があった 質的に変わった要請に応えるため、データ基盤そのものの⾒直しが必要だった 9 / 31
10. STRENGTHS Snowflake が、⾃分たちの「形」に合った 1 SQL で全部完結 既存スキルが活きる。学習コストを最⼩化 2 ウェアハウスの柔軟性 ⾼速起動し、サイズ変更も簡単 3 透明なコスト管理 分単位課⾦で、コスト管理が明確かつ コントロールしやすい 4 強いサポートとコミュニティ 活発な事例共有とサポートで、運⽤が安⼼ 10 / 31
11. QUANTITATIVE IMPACT 数字で⾒る、Snowflake 導⼊後の変化 タイムアウト解消 30 分 → 制限なし ⼤規模クエリも 完⾛できる基盤に 移⾏プロジェクト期間 3 〜 4 ヶ⽉ dbt + Tableau も同時に刷新 セルフサービスの萌芽 数名 の⾃⾛ユーザー ビジネス職に最初の利⽤者が 誕⽣ 技術的な制約は解消し、データ⺠主化の⼟台が整った。次の⼀⼿は Snowflake Intelligence へ 11 / 31
12. WHAT'S NEXT ⼟台はできた。次は「全員が使える」段階へ 整った⼟台 拡張性のある DWH 環境 Snowflake で⼤規模データも処理可能に 整理されたデータモデル dbt でディメンショナルモデリングを刷新 BI 環境の整備 Tableau でビジネス職向けの可視化基盤を構築 残された課題 「全員が使える」までは、 まだ遠い BIツール を⼊れても、SQL を書けるのは⼀部の み。BIツールの学習コストもあり、セルフサービ ス分析は、まだ数名にとどまっていた Snowflake はゴールではなく、「次の挑戦」のためのスタート地点だった 12 / 31
13. PART 2 Snowflake Intelligence 導⼊実践 公式ドキュメントには載っていない、現場のリアルな学び
14. THE TURNING POINT Snowflake Intelligence を⾒た瞬間、即決した Snowflake Intelligenceに期待したこと ⾃然⾔語でデータと対話できる SQL のハードルが、原理的に消える ビジネス職が、⾃分で答えに辿り着ける 依頼を経由せず、その場でインサイトへ データチームが本来の仕事に戻れる 依頼対応から、設計‧改善の時間へ THE ANSWER Snowflake Intelligence 分析の担い⼿が増え、経営と現場が共通 の視座で迅速に意思決定を⾏う⼟壌を⽀ えるはず 14 / 31
15. DEPLOYMENT 最初に作った 2 つのエージェント AGENT 01 主要 KPI 分析エージェント 対象データ 売上 / 契約 / 解約 利⽤部⾨ 経営‧マーケティング‧セールス AGENT 02 問い合わせ分析エージェント 対象データ 問い合わせ データ 利⽤部⾨ カスタマーサポート 15 / 31
16. LEARNINGS 現場で学んだ、3 つの実践ポイント 01 完璧主義が最⼤の失敗だった 02 コスト管理の現実解 03 ロイヤルユーザーが成功の鍵 16 / 31
17. 完璧主義が最⼤の失敗だった 学び 1
18. LEARNING 01 完璧主義が最⼤の失敗だった 18 / 31 パターン１：主要 KPI 分析エージェント 1. エージェントの品質を担保するため、LLMで100項⽬のテスト質問を⽣成 2. ⼿作業で1件ずつテスト 3. 問題があればプロンプトチューニングして再テスト
19. LEARNING 01 完璧主義が最⼤の失敗だった 19 / 31 パターン１：主要 KPI エージェント 1. LLMで100項⽬のテスト質問を⽣成 2. ⼿作業で1件ずつテスト 3. 問題があればプロンプトチューニングして再テスト ⇒ プロンプトチューニングでハルシネーションが発⽣。   テストに時間がかかりすぎてしまい、リリースが遅延
20. LEARNING 01 完璧主義が最⼤の失敗だった 20 / 31 パターン２：問い合わせ分析エージェント 1. リリース直前に要望があり、２⽇で構築 2. 最低限のテスト 3. 70点の出来でリリース
21. LEARNING 01 完璧主義が最⼤の失敗だった 21 / 31 パターン２：問い合わせ分析エージェント 1. リリース直前に要望があり、２⽇で構築 2. 最低限のテスト 3. 70点の出来でリリース ⇒ 要望からリリースまでが早く、ユーザーに温度感⾼く   使ってもらい、ユーザーフィードバックを獲得。   フィードバックを元に改善を進め、⾼い利⽤率を実現
22. LEARNING 01 完璧主義が最⼤の失敗だった - 学び 1 たくさんテストしたからといって使われるものでもない 2 まずユーザーに使ってもらってフィードバックを得ることが⼤事 3 Semantic Viewの定量的な品質担保は難しい（※そのための機能はあります） 4 「多分動くと思うからリリースしようぜ」の精神 5 そのために、70〜80％ぐらいの品質で出すことは許容する 22 / 31
23. コスト管理のポイント 学び 2
24. LEARNING 02 コスト管理の現実解 コスト構造を理解する スレッドの内容も含まれる 会話履歴もトークンに含まれる ⾔語による差 ⽇本語は英語よりトークン数が多い 削減のための⼩さな⼯夫 やめた⽅が良いこと ‧スレッドの使い回し ‧挨拶やお礼のやりとり ‧冗⻑な質問⽂ 推奨する使い⽅ ‧英語で質問する ‧簡潔な指⽰⽂ ‧回答簡素化 （原始⼈モード） ‧スレッドの共有 社内施策 これらの Tips を 1 枚のドキュメントにまとめ、社内共有した 24 / 31 トークン課⾦ 質問‧回答の⽂字数。特に回答のトークンが⾼い
25. ロイヤルユーザーが成功の鍵 学び 3
26. LEARNING 03 ロイヤルユーザーが成功の鍵 26 / 31 問い合わせ分析エージェントが成功したもう１つの理由 1 １⼈のロイヤルユーザーの存在 Snowflake Intelligenceに強く興味を持ち、⾃発的に⾃チーム内で 勉強会や紹介を積極的に⾏ってくれた 2 ロイヤルユーザーの影響 開発者が導⼊推進するより効果的で⾃然に浸透していった。 ユーザーフィードバックも積極的にくれるので改善につながる
27. LEARNING 03 ロイヤルユーザーをどう発掘‧育成するか 発掘‧育成のプロセス STEP 01 モニタリング 質問パターンを分析 → STEP 02 特定 前向きに試している⼈を ⾒つけ出す → STEP 03 ヒアリング‧観測 困ってそうな点をヒアリン グするなどして把握 27 / 31 STEP 06 信頼貯金の積み上げ ユーザーの安⼼が、 ロイヤルティに変わる ← STEP 05 細かくお知らせ 「これ対応しました」を こまめに伝える ← STEP 04 改善 Semantic Viewやデータソース 追加、チューニングなどで困っ ている点を解消 ↓ このサイクルを、回し続ける
28. BUSINESS IMPACT Snowflake Intelligence 導⼊後 解消された課題 データチームのリソース圧迫 ビジネス部⾨の依頼が集中していた BI 学習コストの壁 Tableau に届かなかった層が存在 意思決定の遅延 数字を取りに⾏くのに時間がかかる 得られた価値 ビジネス部⾨の⾃⾛ SQL なしで、⾃分でインサイトを取りに⾏ける 意思決定の⾼速化 アクションまでのリードタイム短縮 データチームのリソース確保 本来やるべき設計‧改善に時間を使える セルフサービス利⽤者 数名 → 20 名規模 Intelligence 導⼊で、データを使う⼈の輪が広がった。 28 / 31
29. これからの取組み
30. NEXT CHALLENGE アウトカムを記録し、価値を社内に⽰し続ける ツールを⼊れて、終わりではない Snowflake Intelligence の価値を、 社内に伝え続けることが、 次のフェーズへの推進⼒になる ヌーラボでも、まだ⼗分にはできていない。 これから取り組みたいテーマ 価値を可視化する仕組み 01 アウトカムを発⾒‧収集する 活⽤事例を集めるフロー、場所の構築 02 価値を社内に提⽰する 数字と事例で具体的に価値を伝え続ける 03 理解が、さらなる活⽤につながる 活⽤が進めば、アウトカムも増えていく 「使ってもらう」だけでなく、「価値を語れる」状態を、データで作っていく 30 / 31
31. Thank you. ご清聴ありがとうございました