Snowflake Data HeroesPublicationへの投稿
❄️

Snowflake Cortex Agent と Cortex Search を活用したアップセル・クロスセル支援システムの構築

Yohei Onishi
に公開
Snowflake
Cortex
search
llm
tech

前提

本記事は Cortex Search と Salesforce を活用した営業支援の仕組み を前提としている。アーキテクチャの詳細（Cortex Search の特性・推奨構成・PoC フェーズ設計・コスト見積もりなど）はそちらを参照すること。本記事では、その基本設計を アップセル・クロスセルのユースケース に適用する方法を整理する。

背景・課題

商談の音声文字起こしデータや対話ログの要約が Snowflake 上に連携されており、商談内容の構造化された要約（目的・背景・課題など）を取得できる状態にある。

一方、自社で提供する各種サービスや追加オプションは多岐にわたり、営業担当者が個々の商談ログから「現在提案中の基本機能以外に、アップグレードやオプション追加を提案できる余地があるか」を体系的に判断するのは難しい。サービスラインナップの増加に伴う知識の属人化や提案の見落としが課題となっている。

2 つの軸で整理する

この仕組みを設計するにあたり、「どう探すか」（アプローチ） と 「何を提案するか」（売り方） の 2 つの軸で整理する。

軸 1：アプローチの違い（バッチ型 vs インタラクティブ型）

バッチ型 インタラクティブ型
動き方 全商談に対して自動で候補を生成する 営業が自分の仮説・勘をもとに能動的に検索する
主な技術 Cortex LLM 関数（COMPLETE） Cortex Search（ハイブリッド検索）
強み 見落としがない・網羅的 営業の経験と組み合わせた深堀りができる
弱み 営業の仮説を反映できない クエリ設計次第で取りこぼしが生じる
典型的な使い方 「全顧客のクロスセル候補を一覧で出す」 「セキュリティ強化を検討している顧客を自分で探す」

軸 2：売り方の違い（クロスセル vs アップセル）

クロスセル アップセル
提案の内容 現在未契約の追加オプションや別製品を新たに提案する 現在の契約プランの上位エディション（プランアップ）を提案する
判定の問い 「この商談の課題を解決できる追加オプションや別製品はあるか？」 「現在のプランの制限値や機能上限に達しつつあるシグナルがあるか？」
典型的な例 標準プラン利用中 → セキュリティオプションや外部連携オプションを提案 ビジネスプラン → エンタープライズプランへの移行を提案

組み合わせ：4 パターン

2 つの軸を掛け合わせると以下の 4 パターンになる。どれか 1 つから始めて段階的に広げていくのが現実的である。

クロスセル アップセル
バッチ型 全商談に AI 関数を走らせ、追加オプションの提案候補を自動生成 全商談に AI 関数を走らせ、プランアップ候補を自動生成
インタラクティブ型 「この課題を持つ顧客」を検索し、関連オプションを手動で照合 「現在のプランに制限を感じている顧客」を検索し、移行を手動で検討

必要なデータとコンポーネント

共通で必要なもの（全パターン）

データ / コンポーネント 内容 備考
商談要約データ 商談の目的・背景・課題・顧客の発言などをテーマ別に構造化したテキスト 商談ごとに 1 レコード
SERVICE_DESCRIPTION テーブル 各サービス・追加オプションの概要・解決できる課題を記述したテキスト サービスコードをキーとする参照テーブル
Cortex LLM 関数（COMPLETE） 商談要約とサービス説明を照合し、提案候補と理由を出力する バッチ型・インタラクティブ型ともに使用

アップセルに追加で必要なもの

データ 内容 取得元
現在の契約プラン サービス名・プランランク・契約ユーザー数・契約金額 CRM / Salesforce 契約オブジェクト
プラン・オプション情報 各プランの上限・上位プランの特徴・追加オプション一覧 SERVICE_DESCRIPTION テーブルに追加整備
利用実績（任意） 実際のユーザー数推移・機能利用状況 利用ログ連携

インタラクティブ型に追加で必要なもの

コンポーネント 内容 備考
Cortex Search（商談インデックス） 商談要約をハイブリッド検索できるサービス 「この課題を持つ顧客」を探すために使う
Cortex Search（商材インデックス） SERVICE_DESCRIPTION をハイブリッド検索できるサービス 「この課題を解決できるサービス」を探すために使う（任意）

処理フロー

バッチ型のフロー（クロスセル・アップセル共通）

(1) 商談要約を取得
      ↓
(2) Cortex LLM 関数（COMPLETE）に以下を入力
      - 商談要約テキスト（課題・ニーズ・背景）
      - SERVICE_DESCRIPTION（全サービス・オプションまたは関連上位候補）
      - ※アップセルの場合：現在の契約プラン情報も追加
      ↓
(3) LLM が提案候補と理由を出力
      クロスセル: service_code / service_name / reason
      アップセル: current_plan / recommended_plan / reason
      ↓
(4) 結果を Snowflake テーブルに格納
      ↓
(5) Salesforce または営業ダッシュボードへ連携・表示

プロンプト設計のポイント

  • 商談要約の粒度：「課題」「背景」「顧客の発言」などのテーマ別セクションをプロンプトに含めることで、LLM が顧客ニーズを正確に把握できる
  • サービス説明の渡し方：サービス・追加オプションの種類が多くトークン数が大きくなる場合は、Cortex Search で事前に関連度の高いオプション説明を絞り込み、上位候補のみを LLM に渡す設計が効率的である
  • クロスセルとアップセルの指示の分け方：両者を同時に判定させることも可能。その場合はプロンプト内で「クロスセル提案」「アップセル提案」を明示的に分けて出力させる

インタラクティブ型のフロー

(1) 営業が「こういう顧客を探したい」という仮説をクエリとして入力
      例:「セキュリティ管理の強化を検討している顧客を探して」
      ↓
(2) Cortex Search が 商談要約をハイブリッド検索
      キーワード + ベクトル類似度でリランキング
      → 上位 N 件の商談（顧客・発言・スコア）を返す
      ↓
(3) 必要に応じて SERVICE_DESCRIPTION も検索（任意）
      「この課題を解決できるサービス」を商材テーブルから抽出
      ↓
(4) Cortex LLM 関数で確度精査・理由生成（任意）
      上位候補の商談テキストとサービス説明を照合し、提案余地を判定
      ↓
(5) 営業がリストをレビューし、提案アクションに移行

クエリ設計の注意点

Cortex Search はキーワードにも意味的にも離れている発言は取りこぼす可能性がある。「課題側の言葉」と「解決策側の言葉」を両方クエリに用意することで網羅性が高まる。

直接表現（解決策側） 課題側の表現
セキュリティを強化したい、アクセス制限 メンバー管理が大変、IP制限をかけたい
外部サービス連携、APIを使いたい システム連携したい、データを自動同期したい
上位プランに移りたい 機能が足りない、ユーザーが増えた

出力サンプル

クロスセルの出力例（実際の AI 関数出力より）

[
  {
    "service_code": "SO",
    "service_name": "高度セキュリティオプション",
    "reason": "複数拠点でのメンバー急増に伴うアクセス権限管理の煩雑さと、外部漏洩リスクへの懸念を解決できる。IP制限機能と詳細な操作ログ追跡により、セキュアなリモートワーク環境を低コストで構築可能。管理者の運用負荷を最小限に抑えつつ、エンタープライズレベルの統制を実現する。"
  }
]

アップセルの出力例（イメージ）

{
  "type": "upsell",
  "current_plan": "ビジネスプラン（30名）",
  "recommended": "エンタープライズプラン",
  "reason": "商談内で「社外のパートナーとも連絡を取りたい」「セキュリティの管理をもっと細かくしたい」という発言があり、外部ユーザー招待・高度な管理機能が必要な段階にある。エンタープライズプランへの移行でこれらの課題を解決できる。"
}

営業への提示イメージ（統合カード）

[顧客カード]
会社名    : 株式会社 XX
業種      : 小売業（従業員 50 名）
担当営業  : （担当者名）
現在の契約: ビジネスプラン

[商談から検出された課題]
「今後数ヶ月で社外のパートナーを100名規模でプロジェクトに招待する予定がある」
「外部のユーザーと機密情報を安全に共有するための権限管理方法に悩んでいる」
（2026-04-20 商談 / 検索スコア: 0.91）

[クロスセル推奨商材]
商材名  : 外部ユーザー用アドバンスドセキュリティオプション（SO）
推奨理由: 大規模な社外ユーザー招待と機密情報共有というニーズに対して、
          招待用ゲストアカウントの詳細なアクセス制限と共有範囲制御が有効。
          追加の個別契約よりもコスト効率良くセキュアな運用環境を確立できる。
確度スコア: 0.85 / 1.0

推奨アーキテクチャ：Cortex Agent による統合

バッチ型とインタラクティブ型を Cortex Agent に統合することで、営業が自然言語で問い合わせるだけで両者の結果を組み合わせた回答を得られる構成を実現できる。

営業（Salesforce UI / チャット）
「セキュリティ強化を検討している顧客へのクロスセル候補を出して」
      |
      v
Cortex Agent（ルーティング）
      |
      +-- 商談要約 --> Cortex Search
      |       ハイブリッド検索で関連商談を抽出
      |       → 顧客 ID・商談テキスト・スコア
      |
      +-- SERVICE_DESCRIPTION --> Cortex Search
      |       課題に合うサービスを商材テーブルから抽出
      |       → サービスコード・サービス名・説明
      |
      +-- 商談・顧客データ（構造化） --> セマンティックビュー経由 SQL
              取引先 / 商談 / 活動 / 契約プランテーブルを参照
      |
      v
Cortex LLM 関数
      商談テキスト × サービス説明 → クロスセル・アップセル余地判定 + 理由生成
      |
      v
営業への提示
      会社名・商談要約・推奨商材・推奨理由をカード形式で表示
      → Salesforce に書き戻し、提案アクションへ

PoC の進め方

全体の進め方は 2 段階で構成する。

Step A — 人力オーケストレーション：自動化前に要素精度を確認する
      ↓ 精度が出たら自動パイプライン化を決断
Step B — 自動パイプライン構築：2 軸の整理にもとづく効率的な順序で組み上げる

Step A：人力オーケストレーションによる要素精度の検証

自動パイプラインを組み上げた後に「精度が出ない」と判明するのは避けるべきである。パイプラインが複雑になるほど、どの要素が精度劣化の原因かを特定することが難しくなる。そのため 自動化の前に、人間がオーケストレーター役を担って各要素を手動で実行し、精度を要素ごとに分離して確認する。

A-1：LLM 判定の単体精度を確認する

作るもの（最小限）

  • 商談要約テーブルと SERVICE_DESCRIPTION テーブルを Snowflake 上に整備
  • Cortex LLM 関数（SNOWFLAKE.CORTEX.COMPLETE）を単体で呼び出せる SQL（自動パイプラインは不要）

進め方

(1) 担当者が商談を 1 件選ぶ
      ↓
(2) 要約を手動で確認し、課題・ニーズを把握する
      ↓
(3) LLM 関数に商談要約 + SERVICE_DESCRIPTION を渡し、クロスセル候補を出力させる
      ↓
(4) 出力された推奨商材と理由を営業に見せてレビューしてもらう
      ↓
(5) 「的外れか・使えるか」を記録してプロンプトを調整し、(1) に戻る（N 件繰り返す）

確認すること

  • LLM の推奨商材は妥当か（的外れが多い場合はプロンプトを修正）
  • 理由の説明は営業が提案トークとして使えるレベルか
  • 要約の粒度・フォーマットは LLM が課題を読み取るのに十分か
  • Go 判定：営業が「半分以上は使えそう」と感じる精度が出ていること

A-2：Cortex Search の単体精度を確認する

作るもの（最小限）

  • 商談要約と SERVICE_DESCRIPTION を Cortex Search にインデックス
  • 検索クエリを手動で投入して結果を確認できる環境を構築

進め方

(1) 営業が「こういう顧客を探したい」というクエリを言語化する
      ↓
(2) 担当者が Cortex Search にクエリを手動で投入し、上位結果を確認する
      ↓
(3) 「期待する商談が上位に来ているか」を営業とともに評価する
      ↓
(4) クエリ・チャンク設計を調整して繰り返す

確認すること

  • 期待する商談が上位に返ってくるか
  • 「課題側の言葉」でクエリしても関連商談を拾えるか（例：「アクセス制限」でセキュリティ系商談が出るか）
  • Go 判定：営業が「だいたい合っている」と感じるクエリ設計が見つかること

A-3：組み合わせ精度を確認する（人間が手動で繋ぐ）

A-1・A-2 の精度がそれぞれ確認できたら、「検索 → LLM 判定」を人間が手動で繋いで、組み合わせたときに精度が維持されるかを確認する。まだ自動化はしない。

Cortex Search の上位結果（A-2）を手動で取り出す
      ↓
LLM 関数（A-1）に渡してクロスセル候補を出力させる
      ↓
営業にレビューしてもらう

Go 判定：各要素 of 単体精度が組み合わせても損なわれていないこと

Step B：自動パイプラインの構築順序

Step A で精度が確認できたら自動化に進む。4 つのパターン（2 軸 × 2 軸）を一度に組み上げる必要はない。作り手の効率から見た推奨順序は以下のとおりである。

※ どのパターンを優先するかのビジネス優先度は営業の判断に委ねる。ここでは「前のステップの成果を最大限に流用できる順序」という観点で整理している。

① バッチ型 × クロスセル
      ↓ データ追加なし・パイプライン構造を流用
② インタラクティブ型 × クロスセル
      ↓ Cortex Search インデックスは②で完成済み・契約データを追加
③ バッチ型 × アップセル
      ↓ バッチ構造は①で完成済み・Cortex Search は②で完成済み
④ インタラクティブ型 × アップセル

① バッチ型 × クロスセル（最初に作る）

理由：必要なデータが最も少ない（商談要約 + SERVICE_DESCRIPTION のみ）。LLM 判定パイプラインの基礎を確立する。Step A のプロンプト・SQL がそのまま流用できる。

作るもの

  • 商談要約 → LLM 関数 → クロスセル候補（service_code・service_name・reason）を出力する自動パイプラインを実装
  • 結果を Snowflake テーブルに格納し、Salesforce または営業ダッシュボードへ連携

確認すること

  • Step A の手動検証結果と自動化後の出力を比較し、精度が劣化していないか

② インタラクティブ型 × クロスセル（次に作る）

理由：①で整備済みの商談要約・SERVICE_DESCRIPTION データをそのまま流用できる。新たに必要なのは Cortex Search のインデックス構築のみ（データ追加なし）。Step A の A-2 で検証済みのクエリ設計を実装に落とし込む。

作るもの

  • Cortex Search サービスを構築（商談要約 + SERVICE_DESCRIPTION をインデックス）
  • Cortex Agent に Cortex Search を接続し、自然言語クエリ → 検索結果＋LLM 判定が返る構成を実現

確認すること

  • Step A の手動検索結果と自動化後の検索結果を比較し、精度が維持されているか

③ バッチ型 × アップセル（その次）

理由：①のバッチパイプライン構造を流用できる。変更点はプロンプトの修正と、Salesforce 契約データの追加連携のみ。新たなデータ統合作業（Salesforce 連携）が発生するが、パイプライン自体は①の延長として実装できる。

作るもの

  • Salesforce の契約プラン情報を Snowflake に連携
  • SERVICE_DESCRIPTION テーブルにプラン・オプション情報を追加整備
  • ①のプロンプトにアップセル判定指示を追加し、current_plan・recommended_plan・reason を出力

確認すること

  • 契約データの精度（Snowflake 上の契約情報が実態と合っているか）
  • アップセルの推奨根拠が営業にとって納得感があるか

④ インタラクティブ型 × アップセル（最後）

理由：②の Cortex Search インデックスと③の契約データがすでに揃っている。組み合わせるだけで実現できる。単独では最も依存するコンポーネントが多いため、最後に位置づける。

作るもの

  • ②の Cortex Search に契約データ・プラン情報の検索を追加（または別インデックスとして構築）
  • Cortex Agent のプロンプトにアップセル判定ロジックを統合

確認すること

  • クロスセル・アップセルの両提案が 1 つの自然言語クエリから返せているか
  • Salesforce 上で 4 パターンすべての提案が営業の日常業務に組み込まれているか
  • 最終 Go 判定：提案リストを活用した商談化率が活用しない場合より有意に高いこと

まとめと推奨事項

  • まずバッチ型・クロスセルから始める：最も必要なデータが少なく、精度検証がしやすい。商談要約と SERVICE_DESCRIPTION が整えば始められる
  • アップセルは契約データが鍵：Salesforce の契約プラン情報と SERVICE_DESCRIPTION のプラン情報を整備することで対応可能。バッチ型クロスセルの精度が出てから追加するのが現実的
  • Cortex Search は営業の勘を拡張する：バッチ型で網羅しつつ、営業が自分の仮説でリストを作れる検索を組み合わせることで、見落としを防ぎながら能動的な活用も実現できる
  • 要素精度を先に確認してから統合する：LLM 判定・検索それぞれを手動で検証してから自動化・Agent 統合に進むことで、全体を組んだ後に精度が出ないリスクを避けられる

参考

Snowflake Data Heroes
Snowflake Data HeroesPublication

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

Discussion