Snowflake Intelligence導入で分かった活用のコツ

by wonohe

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

⾃⼰紹介株式会社ヌーラボ Reliability Engineering部プラットフォームユニット @wonohe 全社におけるデータマネジメントと、社内全体のデータ活⽤推進活動を担当。社内データ基盤刷新プロジェクトのリーダーとして、Snowﬂakeの導⼊を主導。居住地：神⼾趣味：ドラム

Slide 3

Slide 3 text

今日お話しすること

Slide 4

Slide 4 text

失敗から学んだ実践的ノウハウ 🚀 2025年11⽉からSnowﬂake Intelligenceの導⼊準備 → 半年間の学び

Slide 5

Slide 5 text

💡 3つの⼤きな学び 1. ❌「完璧主義」が最⼤の失敗だった 2. 🏗 データ構造がすべてを決める 3. 👑 ロイヤルユーザーが成功の鍵

Slide 6

Slide 6 text

⏰ Snowﬂake Intelligence 導⼊の背景

Slide 7

Slide 7 text

導⼊前のデータ分析の課題 ❌ Before：従来の課題 ● 現場の⼈が⾃分で分析できない ○ スキル⾯でデータ基盤のデータを使うのが難しい ○ メタデータの不⾜ ● データチームに分析依頼 → リソース圧迫 ● 分析速度が遅い → 意思決定が遅れる ✅ After：理想の姿 ● ⾃然⾔語で誰でも分析可能 ● 現場主導のセルフ分析 ● データチームは⾼度な分析に集中

Slide 8

Slide 8 text

Snowﬂake Intelligence 構成

Slide 9

Slide 9 text

作成したSnowﬂake Intelligence エージェント ● 売上‧契約数‧ユーザー数を扱うエージェント ○ ⽬的：主要KPIを分析するため ○ Cortex Analyst：売上、契約数、契約イベント、ユーザー数 ● 問い合わせデータを扱うエージェント ○ ⽬的：問い合わせデータを分析するため ○ Cortex Analyst：チケット情報 ● Backlog AIアシスタントの利⽤状況データ扱うエージェント ○ ⽬的：Backlog AIアシスタントの利⽤状況分析 ○ Cortex Analyst：機能利⽤状況

Slide 10

Slide 10 text

📝 学び１：完璧主義の罠

Slide 11

Slide 11 text

作成したSnowﬂake Intelligence エージェント ● 売上‧契約数‧ユーザー数を扱うエージェント ○ ⽬的：主要KPIを分析するため ○ Cortex Analyt：売上、契約数、契約イベント、ユーザー数 ● 問い合わせデータを扱うエージェント ○ ⽬的：問い合わせデータを分析するため ○ Cortex Analyt：チケット情報 ● Backlog AIアシスタントの利⽤状況データ扱うエージェント ○ ⽬的：Backlog AIアシスタントの利⽤状況分析 ○ Cortex Analyt：機能利⽤状況

Slide 12

Slide 12 text

Semantic Viewの作成 🛠 Semantic Viewの作成⾃体はそこまで難しくはない ● メタデータやリレーションをしっかりと書いていく ● 問題：どのように回答の品質を担保するか？ 💡 解決策を考えた ● 「LLMにテスト質問を作らせて検証しよう！」 ○ 実際のプロンプト ● 多様なパターンをカバーできるはず ● これが間違いの始まり…

Slide 13

Slide 13 text

100件テストの地獄体験 🔄 延々と続いた作業サイクル 1. LLMで質問を⾃動⽣成 → 「売上を教えて」「先⽉の売上は？」など 2. ⼿作業で1件ずつテスト → 結果とSQLを⽬視確認 3. 問題があったらプロンプトチューニング → またテスト実⾏ 4. 再テスト → 別の問題が発覚 → 無限ループ 😵 結果 ● プロンプトのチューニングは⼿探り ● チューニングによってデグレもおきる ● テストに時間がかかり、リリースが遅れてしまう

Slide 14

Slide 14 text

⼀⽅、お問い合わせエージェント 2⽇で開発 ⏰ テストしてる時間もなかった ⛏ お試しで出してみたらいいか、という軽い気持ち

Slide 15

Slide 15 text

衝撃の結果：⼿間かけてない⽅が成功 😂 項目売上エージェントお問い合わせエージェント開発期間 🐌 2-3ヶ月 ⚡ 2日テスト件数 💀 100件以上 ✨ 最小限ユーザー評価 😞 △ 🎉 ◎

Slide 16

Slide 16 text

学び 1. たくさんテストしたからといって使われるものでもない 2. Semantic Viewの定量的な品質担保は難しい → フィードバックもらいながらチューニングしたほうが早い 3. まずユーザーに使ってもらってフィードバックを得ることが⼤事 💬 4. そのために、70〜80％ぐらいの品質で出すことは許容する ⚙✨ 5. 「多分動くと思うからリリースしようぜ」の精神

Slide 17

Slide 17 text

📊 学び2：エージェントと Semantic Viewのコツ

Slide 18

Slide 18 text

成功するエージェント‧Semantic Viewの基本 1⃣ Snowﬂake公式から出ているベストプラクティスに沿って作る 2⃣ Semantic Viewはユースケース∕業務∕指標ごとに、粒度を揃えて作る 3⃣ エージェントはユースケース∕職種ごとに作る 4⃣ Semantic Viewにテーブルは詰め込みすぎない → ヌーラボでは⼀番多いものでも9テーブル → カラムは50〜100列程度にする（ベストプラクティス）

Slide 19

Slide 19 text

エージェント設計のミス ❌ 売上エージェント（失敗） ● Semantic Viewは指標単位で分かれている ○ 売上‧契約数‧契約イベント‧ユーザー数 → エージェントが経営層向けなのか現場オペレーション向けなのかあいまい ✅ お問い合わせエージェント（成功） ● Semantic Viewは「お問い合わせデータ分析」のユースケースで作成 →「カスタマサポートの現場オペレーション向け」で明確

Slide 20

Slide 20 text

セマンティックビュー作成の実践的コツ 🚫 よくある間違い ● 同義語の設定しすぎ → 全項⽬に設定すると精度が落ちる ● 警告の放置 → 警告が残っていると設定内容を参照しない場合がある ✅ 正しいアプローチ 1. 最⼩限の設定でSemantic Viewを作成 2. 警告は必ず全て解消しておく 3. ユーザーテストで問題が出た項⽬のみ同義語追加 4. Veriﬁed Queryはかなり効くので、副作⽤に注意しながら使う

Slide 21

Slide 21 text

🚀 学び3：ロイヤルユーザーが成功の鍵

Slide 22

Slide 22 text

ある⽇のできごと 1. ある⽇、カスタマーサポートの⼈から「SnowﬂakeでZendeskのデータを分析したい」という要望 2. Snowﬂake Intelligenceを爆速で開発し、ベータ版ですよーと⾔いながら提供（２⽇） 3. 実際に触って「めちゃくちゃいい！もっと使いこなしたい！」 → ✨⾃発的に勉強会や紹介をしてくれた✨

Slide 23

Slide 23 text

⼝コミ展開の威⼒ 📈 ロイヤルユーザーの威⼒はすごい ● 1⼈のロイヤルユーザー → 部署内に利⽤が拡⼤ ● ⼝コミ効果 → マニュアルより信頼度が⾼く、社内の評判も⾼まる ● ⾃然な浸透 → 開発側が導⼊推進するより効果的 🎯 ロイヤルユーザーの特徴 1. 価値を理解してくれる⼈ 2. 周りに影響⼒がある⼈ 3. 前向きに試す⼈ → フィードバックをたくさんくれる

Slide 24

Slide 24 text

どうやってロイヤルユーザーを育てるか 🔍 １．発掘興味を⽰してくれた⼈や、モニタリングで利⽤者を特定する。質問が１往復ではなく、複数回やってる⼈など。 🤝 ２．関係構築モニタリング内容をもとにフォローアップをしたり、要望があれば優先的に対応して、共有も細かくしていく。 →とにかく、悪い体験にならないように細かくアップデートするのも⼤事 → 成功パターン：💕技術より⼈間関係が重要🤝

Slide 25

Slide 25 text

📝まとめ

Slide 26

Slide 26 text

📝 まとめ 1⃣ 完璧主義は失敗の元 80%の完成度で早期リリース → ユーザーフィードバックで改善 2⃣ データ構造がすべて Semantic Viewとエージェント → ユースケースなど考えて分割する 3⃣ ロイヤルユーザーが鍵⼈間関係を⼤切に → ⼝コミ展開で⾃然な浸透