Snowflake Data HeroesPublicationへの投稿
❄️

Cortex Search と Salesforce を活用した営業支援の仕組み

Yohei Onishi
に公開
Snowflake
Salesforce
Cortex
search
tech

背景・課題

営業活動における顧客との対話ログ（ミーティングの文字起こしデータなど）の活用方法を検証中であり、セールス担当者が Salesforce などの CRM 上で効果的に利用できる形に整備することを想定している。

具体的なユースケースとして、顧客の対話ログから「プランアップグレードや追加サービスに興味がありそうな発言をしている顧客をリストにして」といった Snowflake Intelligence（SI）からの問い合わせに対応できるかを検討している。

基本方針として、CRM への連携はある程度整形した情報を送る形とし、CRM 上で完結させることを優先する。Cortex Search を補助的に活用することで、対応の自由度を高めることを目指す。

まとめと推奨事項

  • 実現可能性は高い：対話ログから「プランアップグレードや追加サービスに関心がある顧客」を特定するユースケースは、Cortex Search と Cortex LLM 関数の組み合わせで技術的に実現できる
  • 検索手法より問いの設計が重要：Cortex Search はハイブリッド検索で精度が高いが、何をクエリにするかは営業の仮説に依存する。まず営業にヒアリングして「案件になりやすい発言パターン」を言語化することが先決
  • 小さく始めて反復する：最初から完璧なロジックを目指さず、営業の仮説 → Cortex Search で候補抽出 → 営業レビュー → 結果フィードバックのサイクルを回すことで精度を高めていく
  • 推奨構成：Cortex Agent が中核となり、Cortex Search（対話ログ検索）とセマンティックビューを用いた Agent 自身による Text-to-SQL（商談データ参照）を組み合わせる。確度精査・根拠生成は Cortex LLM 関数 でオプション追加する
  • 長期的な価値：営業の暗黙知を奪うのではなく、営業活動を定性・定量の両面で可視化し、営業自身が成果を出しやすくなるよう支援することが目的である。サイクルを重ねることで「どの顧客にアプローチすべきか」の判断をデータが後押しし、営業のエンパワーメントにつながる

Cortex Search の特性と注意点

Cortex Search はドキュメント等の非構造化データを取り込み、キーワード検索とベクトル類似度検索（意味検索）を組み合わせてリランキングした結果を返すことができる。

特性 内容
ハイブリッド検索 テキストマッチング・ベクトル類似度・リランカーの3コンポーネントのスコアを重み付け合成して最終スコアを算出する
リランキング 3つのスコアを統合して最終順位を決定する。単純なマージではなく重み付き合成である点に注意
強み 表現が揺れていても意味的に近い文書を拾える
注意点 キーワードにも引っかからず、クエリと意味的にも離れているが文脈上は関連する発言は取得できない。例：「ユーザー数が増えた」「メンバー管理が大変」は上位プラン（自社サービス）で解決できる課題だが、「プランアップグレード」「ライセンス追加」という単語そのものとは意味的に離れており、クエリ設計次第では取りこぼしになる

「プランアップグレードに関心がある顧客」の特定

ゴール

対話ログデータから プランアップや追加機能への関心度が高い顧客を優先リスト化し、セールスの次のアクション（再アプローチ・提案送付）につなげること。最終的な成功指標は「リストから商談化した件数・率」であり、検索手法はそのための手段に過ぎない。

顧客は「プランアップグレードに興味があります」と直接言わないことも多いため、どの手法がゴールに近づくかは事前に断言できない。複数の手法を並行して試し、実際の成果で比較する。

検証フロー

(1) 営業の仮説ヒアリング
      ↓
(2) Cortex Search で候補抽出
      ↓
(3) LLM 分類で確度精査（任意）
      ↓
(4) 根拠の自動生成
      ↓
(5) 営業によるレビュー・妥当性確認
      ↓
(6) 営業活動の結果フィードバック → (1) へ戻る（Human in the Loop）

(1) 営業の仮説ヒアリング

何が「上位プランや追加機能への関心」を示す発言かは、営業の肌感覚が一番の手がかりとなる。まず営業にヒアリングして「こういう発言をする顧客が案件になりやすい」という仮説をクエリ候補として収集する。これを Cortex Search の検索クエリとして使う。

クエリ設計では提供サービス（上位プランなど）が解決できる課題の言葉を意識的に含めることが重要である。「プランを上げたい」「ライセンスを増やしたい」といった直接的な表現だけでなく、「メンバーが増えた」「セキュリティを強化したい」「アクセス制限を細かく管理したい」のような課題・ニーズ側の言葉もクエリリストに加えることで、意味的に離れた発言も拾えるように設計する。それでも取りこぼしが生じる場合は、(3) の LLM 分類を活用し、発言全体の文脈から「上位プランや追加機能で解決できる課題を抱えているか」を LLM に判断させる方法が有効である。

(2) Cortex Search で候補抽出

Cortex Search に対話ログの文字起こしデータを取り込み、(1)で集めたクエリを投入する。ハイブリッド検索（キーワード＋ベクトル類似度）によるリランキング結果から上位 N 件を候補として抽出する。

(3) LLM 分類で確度精査（任意）

(2)の上位候補を LLM（Cortex LLM 関数）に渡し、「プランアップ関心あり／なし／不明」に分類する。全件に適用するとコストが高いため、Cortex Search のスコア上位に絞って実行するのが現実的である。

(4) 根拠の自動生成

LLM に分類と同時に「なぜ関心ありと判断したか」を自然言語で説明させる。これにより営業がリストの妥当性を判断しやすくなる。

(5) 営業によるレビュー・妥当性確認

ランキング上位かつ確度が高いと判断された発言と、LLM が生成した根拠を営業に提示してレビューしてもらう。

(6) 営業活動の結果フィードバック（Human in the Loop）

(5)のリストをもとに実際にアプローチした結果を収集し、定性・定量の両面から(1)の仮説を評価する。

定性評価（営業の肌感覚）

  • このリストに上がった顧客は実際に話が盛り上がったか
  • LLM が示した根拠は営業から見て納得感があったか
  • 「このクエリはズレていた」「こういう発言も拾ってほしい」といった現場の声

定量評価

  • リスト内の商談化率・アポ獲得率
  • リストに入らなかった顧客と比べた商談化率の差（リフト）
  • Cortex Search のスコアや LLM の確度と実際の商談化の相関

両者を総合して「仮説が有効だったか」を判断し、クエリ・しきい値・分類プロンプトを改善して(1)に戻る。

このサイクルの目的は、営業の動物的な勘を「奪う」ことではない。「なんとなくこういうお客さんが案件になる」という経験知を定性・定量の両面で可視化し、営業自身が自分の判断の精度を確認しながら、より楽に・より確実に成果を出せるよう支援することにある。データが営業 of 判定を代替するのではなく、営業の判断を後押しする位置づけである。

推奨アーキテクチャ

検証フローの各ステップをシステムとして実現すると、以下の構成になる。

(1) 営業の仮説ヒアリング
    Salesforce UI / チャット
    「上位プランに関心がある顧客を探して」（自然言語クエリ）
      |
      v
(2) Cortex Agent --- 候補抽出
      |
      +-- 対話ログ（非構造化） --> Cortex Search
      |       ソース: 対話ログ文字起こしテーブル（1行 = 1発言 or 1コンタクト）
      |       ハイブリッド検索（キーワード + ベクトル類似度）でリランキング
      |       --> スコア上位 N 件を抽出
      |
      +-- 商談・顧客データ（構造化） --> セマンティックビュー参照
              SQL を自律生成・実行
              取引先 / 商談 / 活動テーブルを参照
      |
      v
(3)(4) Cortex LLM 関数（任意）--- 確度精査・根拠生成
    「関心あり / なし / 不明」の分類 + 判断根拠を自然言語で出力
      |
      v
(5) 営業レビュー
    Salesforce 上に結果リストと根拠を表示
    妥当性確認 --> 再アプローチ / 提案送付
      |
      v
(6) フィードバック
    商談化・失注等の結果を回収
    定性・定量で仮説を評価
    クエリ / しきい値 / プロンプトを改善
      |
      +-- 次のサイクルへ --> (1) へ戻る

Cortex Agent がルーティングの中核となる。非構造化データは Cortex Search で検索し、構造化データは Agent がセマンティックビューを参照して SQL を自律的に生成・実行する。確度精査・根拠生成は Cortex LLM 関数 でオプション追加できる。

Agent が SQL で参照するテーブル

Agent がセマンティックビュー経由でクエリする構造化データのテーブルとして、以下を想定する。

テーブル 主な列（例） 用途
取引先（Account） 会社名、業種、規模、担当営業 顧客属性によるフィルタリング
商談（Opportunity） 商談名、フェーズ、金額、クローズ日、商材 商談化履歴・確度の参照
活動（Activity / Task） 種別（ミーティング・メール等）、日時、担当者、メモ 対話履歴とのひも付け
対話ログ（カスタム） 顧客ID、コンタクト日時、話者、発言テキスト Cortex Search のソーステーブルを兼ねる。このテーブルを指定して CREATE CORTEX SEARCH SERVICE を実行することで検索サービスを構築する

データの取得元

これらのデータは CRM（Salesforceなど）が正となる。Snowflake への連携方法としては以下が選択肢になる。

  • Salesforce コネクタ for Snowflake：ネイティブ連携で CRM オブジェクトをほぼリアルタイムに Snowflake へ同期可能
  • ETL / ELT パイプライン（Fivetran・Airbyte 等）：既存のデータ基盤に合わせる場合の選択肢
  • 対話ログデータ：蓄積されているシステムから Snowflake への取り込み・連携

結果の合成と提示内容

各コンポーネントの出力

コンポーネント 出力内容
Cortex Search 発言テキスト・対話日時・顧客ID・検索スコア（上位 N 件）
Cortex LLM 関数（任意） 関心度スコア（0〜1）・分類（あり / なし / 不明）・判断根拠テキスト
Cortex Agent SQL 会社名・業種・商談フェーズ・最終コンタクト日・担当営業

合成ロジック

3つの出力を顧客IDでひも付けて1レコードに統合し、以下の優先順位でランキングする。

  1. LLM の関心度スコアが高く、かつ Cortex Search スコアが高い顧客を上位に置く
  2. 同一顧客で「関心あり」発言が複数回検出されている場合はさらに優先
  3. 商談フェーズが未開始・停滞中の顧客を優先（すでに商談中の顧客は除外してもよい）

営業担当者への提示イメージ

[顧客カード]
会社名    : 株式会社 XX
業種      : 製造業（従業員 300 名）
担当営業  : 山田 太郎
商談状況  : 商談なし（最終コンタクト: 2026-03-15）

[検出された発言]
「今後は利用メンバーが急増する予定で、セキュリティ管理をもっと細かく制限したくて...」
（2026-03-15 商談 / 検索スコア: 0.87）

[LLM の判断]
確度スコア: 0.82 / 1.0（関心あり）
根拠: 組織規模の拡大に伴うセキュリティ管理機能の強化ニーズが確認でき、
      上位のエンタープライズプランのユースケースに合致する可能性が高い。

提示する項目・フォーマットは Phase 1 の営業レビューを通じて調整する。「根拠が長すぎる」「スコアは不要」など現場の声を反映して絞り込む。

PoC の進め方

Phase 1 — データ基盤と検索の最小構成（作るもの・確認すること）

作るもの

  • 対話ログの文字起こしデータを Snowflake テーブルに取り込む（サンプル数十件で可）
  • チャンク設計を決定（1発言1行 or 1ミーティング1行）し、Cortex Search サービスを作成

検証すること

  • 営業からヒアリングした仮説クエリを Cortex Search のクエリ API に投入し、上位結果を営業に見せる
  • 「このリストは使えそうか」を定性評価してもらい、クエリとチャンク設計を調整する
  • Go 判定：営業が「だいたい合っている」と感じる結果が得られること

Phase 2 — LLM 分類・根拠生成の追加（作るもの・確認すること）

作るもの

  • Phase 1 の上位候補を Cortex LLM 関数 に渡し、「関心あり / なし / 不明」の分類と根拠テキストを生成するパイプラインを構築

検証すること

  • LLM が出した根拠を営業に提示し、「なぜこの顧客が候補に上がったか」の説明として納得感があるかを確認
  • Phase 1 の結果と比較して、精度・有用性が向上しているかを評価
  • Go 判定：根拠付きリストが営業の判断を実際に助けていること

Phase 3 — Cortex Agent 統合（作るもの・確認すること）

作るもの

  • Cortex Agent に Cortex Search とセマンティックビューを接続し、自然言語で問い合わせると文字起こし検索と商談データの SQL 生成・実行が自律的に動く構成を構築

検証すること

  • 「プランアップグレードに興味がありそうな顧客をリストにして」のような自然言語クエリに対して期待通りの回答が返るかを確認
  • CRM の商談データと文字起こし検索の結果が適切に組み合わさっているかを評価
  • Go 判定：営業が自然言語で問い合わせて実用的な結果が得られること

Phase 4 — CRM 組み込みと本運用準備（作るもの・確認すること）

作るもの

  • Cortex Agent の回答を CRM 上で閲覧・アクションできる UI/UX を整備（API 直呼び出し or 各種コパイロット連携）
  • フィードバックデータ（商談化・失注等）の回収フローを整備

検証すること

  • 実際の営業活動でリストを使ってもらい、商談化率・アポ率を計測
  • 定性・定量フィードバックをもとにクエリ・プロンプトを改善し、サイクルが回ることを確認
  • Go 判定：リストを使った顧客の商談化率が使わない場合より有意に高いこと

コスト見積もり

価格は Snowflake クレジット単価・契約形態・リージョンによって異なる。以下は参考値であり、正確な料金は Snowflake 公式料金ページ で確認すること。

コストの種類

固定コスト（常時発生）

項目 概要
Cortex Search サービス稼働費 インデックス済みデータ量（GB）に基づいて課金される（GB / 月単位）。クエリがない時間帯はサスペンドすることで稼働コストを削減できる。サスペンド中もストレージコストは発生する点に注意
Snowflake ストレージ 対話ログテーブル・Search インデックス・CRM 連携テーブルの保存容量。データ量が増えるにつれて増加

変動コスト（利用量に応じて発生）

項目 課金単位 備考
Cortex Search EMBED_TEXT トークン数 クエリ実行時および取り込み時のテキスト埋め込みに課金
Cortex Search Warehouse クレジット インデックス更新（データ取り込み・再インデックス）時に消費
Cortex LLM 関数 入出力トークン数 分類・根拠生成に使用。モデルによって単価が異なる（軽量モデルほど安い）
Cortex Agent 入出力トークン数 + ツール呼び出し SQL生成・Search呼び出し・回答生成のすべてが対象
Snowflake ウェアハウス クレジット / 秒 Agent の SQL 実行時のコンピュート。XS サイズで最小化可能

シナリオ別 月額概算

以下の前提でシナリオを設定する。

  • ミーティング文字起こし: 1件 = 約 2,000 トークン（発言単位チャンク: 1チャンク ≈ 100 トークン）
  • LLM モデル: 軽量モデル（例: Snowflake Arctic / Llama 3 系）を想定
  • Cortex Search の稼働コストはインデックスデータ量（GB / 月）に基づく

Phase 1 — PoC（サンプル数十件、手動クエリ）

項目 想定量 月額概算
Cortex Search 稼働（GB / 月） 数十件 ≈ 数 MB ほぼ 0
Cortex Search トークン（EMBED_TEXT） 取り込み時のみ: 50 件 × 100 トークン = 5K トークン ほぼ 0
LLM 分類・根拠生成 50 件 × 2,000 トークン = 100K トークン 数百円〜
Cortex Agent 数十回の手動検証 数百円〜
合計 〜数百〜数千円 / 月

Phase 2 — 小規模運用（数千件、営業 10 名が週次利用）

項目 想定量 月額概算
Cortex Search 稼働（GB / 月） 5,000 件 ≈ 500 MB 数百円〜
Cortex Search トークン（EMBED_TEXT） クエリ: 200 回 × 100 トークン = 20K トークン 数百円〜
LLM 分類・根拠生成 上位 500 件 × 2,000 トークン = 1M トークン 数千円〜
Cortex Agent 200 回のインタラクション 数千円〜
合計 〜1〜3 万円 / 月

Phase 3 — 本番運用（数万件、営業全員が日次利用）

項目 想定量 月額概算
Cortex Search 稼働（GB / 月） 50,000 件 ≈ 5 GB 数千円〜
Cortex Search トークン（EMBED_TEXT） クエリ: 5,000 回 × 100 トークン = 500K トークン 数千円〜
LLM 分類・根拠生成 上位 5,000 件 × 2,000 トークン = 10M トークン 数万円〜
Cortex Agent 5,000 回のインタラクション 数万円〜
合計 〜5〜15 万円 / 月

コスト最適化の方針

  • LLM は段階的に適用：全件に LLM 分類を走らせず、Cortex Search スコア上位のみに絞ることで大幅削減できる
  • 軽量モデルを優先：根拠生成には高性能モデルは不要。Llama 3 系などの軽量モデルで十分な場合が多い
  • Search サービスは営業時間のみ稼働：夜間・休日は停止してコストを抑える
  • チャンク粒度の最適化：チャンクが細かすぎると件数が増えてクエリコストが上がるため、適切な粒度に調整する

未解決の論点

  • 文字起こしデータのチャンク設計：コンタクト1件を会話単位で1チャンクにするか、発言ごとに分割するかで検索精度が大きく変わる
  • 個人情報・機密情報の取り扱いポリシーとのすり合わせ
  • 検索結果をどのフィールドに、どのタイミングで CRM（Salesforce等）に書き戻すか
  • Cortex Agent の応答を CRM UI に組み込む際の技術的手段（API 直呼び出し vs 各種コパイロット機能連携等）
  • クエリの管理・バージョン管理：ヒアリングで集めた仮説クエリをどこで管理し、改善履歴をどう残すか
  • フィードバックデータの取得方法：CRM の商談ステータス変化を自動で拾うか、営業が手動で報告するか
  • 対象データの範囲：全対話ログを取り込むか、直近 N ヶ月・特定商材に絞るか

参考リンク

Snowflake 公式ドキュメント

機能 URL
Cortex Search — 概要 https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-search/cortex-search-overview
Cortex Search — サービス作成・管理 https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-search/cortex-search-overview
Cortex Search — クエリ API https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-search/query-cortex-search-service
Cortex Agents — 概要 https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-agents
Cortex LLM 関数 https://docs.snowflake.com/en/user-guide/snowflake-cortex/llm-functions
Snowflake Cortex AI — 機能一覧 https://docs.snowflake.com/en/user-guide/snowflake-cortex/overview
Snowflake Data Heroes
Snowflake Data HeroesPublication

Snowflake データクラウドのユーザ会 SnowVillage のメンバーで運営しています。 Publication参加方法はこちらをご参照ください。 zenn.dev/dataheroes/articles/db5da0959b4bdd

Discussion