Copyright Nulab Inc. All Rights Reserved. Snowflake Intelligence導⼊で 分かった活⽤のコツ 株式会社ヌーラボ （@wonohe） 

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

今日お話しすること 

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

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

⏰ Snowflake Intelligence 導⼊の背景 

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

Snowflake Intelligence 構成 

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

📝 学び１：完璧主義の罠 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

📝まとめ 

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

🙋 まだまだ分からないこといっぱい…！🔥 💡 あとでたくさん情報交換しましょう！ 🤝✨ 

Copyright Nulab Inc. All Rights Reserved. ありがとうございました🤘 

📑 Appendix 

あなたはSaaSを提供している企業の、マーケティング部⾨の意思決定者です。 データ分析部⾨に、契約状況の推移を質問したいと考えています。 ⼀般的に考えられる質問を100問考えてください。 考慮すべき属性は以下の通りです 1. プロダクトは4種類ありますが、ユーザー数を集計しているプロダクトは3種です 2. 各プロダクトに複数のプランがあります 3. 契約はスペースという単位で管理されます 4. 1スペースで複数のプロダクトを契約できますが、プランは各1種類だけです 5. 最新の単⽉の情報だけでなく、昨対（YoY、MoMなど）も知りたいです 6. 時系列で考慮するのは、年、年度、⽉、四半期です 7. 年度の開始は4⽉です 8. トライアル開始、終了、新規契約、解約、アップグレード、ダウングレードは契約イベントとして登録されます 9. 契約は有料契約と無料契約（フリープラン、トライアル）を分けて扱ってください 10. 所有しているデータの都合上、アクティブなスペースの数やユーザー数は分析対象から外してください 実際に使った質問