LLM/Agent評価：トップ営業の発言を「正解」にする 〜暗黙的正解による評価を営業資産に変える〜

Transcript

1. トップ営業の発言を「正解」にする 〜暗黙的正解による評価を営業資産に変える〜 CyberAgent / AI Shift 二宮大空 LLM/Agent評価勉強会 (2026年7月)
2. 所属 CyberAgent / AI Shift AIエージェント事業部プロダクトチーム 開発 • Chatbot / Voicebot内の検索システムの開発 • RAGシステムの開発 • 営業向けSaaSの開発 関心 • Google Cloud (Google Cloud All Certification Holder) • Agentの評価 二宮 大空 にのみや　ひろたか Hirotaka (@takkuhiro)
3. 今日の要点 技術の問い 正解が定義できないドメインでは、 組織内の実データから 暗黙的な正解 (Implicit Ground Truth) を作る という選択肢がある。 事業の問い 評価パイプラインの副産物 が、 そのまま事業資産になり得る。 提案・設計段階の部分も含め、フィードバックがあればぜひ教えてください！
4. プロダクトについて 01
5. AIドリブンな、営業組織へ。 商談データを営業資産に変え、 営業成果を最大化する。
6. 商談を中心とした営業活動支援 BEFORE 商談前 DURING 商談中 AFTER 商談後 クライアントの調査 トークスクリプトの作成 商談の録画 AIでのフォローと自動聞き取り 議事録作成 録画の閲覧と分析
7. 商談中AI機能 フォロー機能 ”今すべき質問”を表示する 自動聞き取り機能 要点をAIが自動でメモする Zoom, Teamsのサイドパネルにアプリを表示 ※デモ用のデータです
8. 商談中AI機能 フォロー機能 ”今すべき質問”を表示する 自動聞き取り機能 要点をAIが自動でメモする Zoom, Teamsのサイドパネルにアプリを表示 ※デモ用のデータです
9. フォロー機能 営業担当者が“今すべき質問”を、SPIN話法をベースにLLMで生成する Situation 状況質問 顧客の状況を正確に理解するための質問 ex. 業務で何か困っていることはありますか？ Problem 問題質問 顧客が気付いていない問題や不満を明らかにする ための質問 ex.業務の効率が上がらない原因は何だとお考えで すか？ Implication 示唆質問 顧客に不完全な状況や不足している点を強く認識さ せるための質問 ex.この問題を放置すると、他の部門にも悪影響が 出る可能性はありませんか？ NeedPayoff 解決質問 顧客が問題を解決した際に得られる利益や価値を 認識してもらうための質問 ex.この問題が解決された場合、顧客満足度はどの ように変わりますか？ あなたはミーティング中の営業担当者をサポートするアシスタントです。 SPIN話法を用いたフォローアップ質問を提案します。 # SPIN話法 … # 出力ルール … {ミーティングのメタデータ} {リアルタイム文字起こし} {過去生成したフォロー質問} フォロー質問の具体例 プロンプト SPIN話法
10. アーキテクチャ Meeting Provider Zoom Google Meet Microsoft Teams External Services Recording Service （外部SaaS） Google Cloud 2. Recorder参加 1. ミーティングの登録 Backend 3. 文字起こし (厳密には録画サービスから取得) Firestore 4. 保存 PubSub Functions 5. 定期実行 6. フォロー質問を生成
11. 評価の壁 02
12. フォロー機能が正しく機能しているか評価したい。 だが「フォロー質問の良さ」をどう定義すべきか悩ましい。 そもそも商談における良い発言とは？
13. 素朴な案 「SPIN話法の記述との意味的近さ」を測るのはどうか？ →結局採用しなかった • SPIN話法は営業におけるノウハウの1つにすぎない • 今後の拡張性を保つために、SPIN話法に限定したくない • 会社ごとに良い営業の定義は違うはずで、個別に定義するのは大変
14. 根本課題 商談の「良い発言」は変数が多すぎてルールを網羅できない • 企業／部署／商材／既存・新規／顧客状況…によって定義が異なる → 「何を言うべきか」を固定の評価軸に落とせない • しかもプライバシー観点から他社の商談データは見れない → 一般的な「正解データセット」も作れない
15. 暗黙的な正解の定義 03
16. 発想：トップ営業の実発言を「正解」とみなす 「何が良い発言か」は定義できなくても、 「誰が良い営業か」は営業成績DBで定義できる • 売上高 • 成約率 • 目標達成率 • 新規開拓数 … 1位：田中さん（5000万円） 2位：佐藤さん（4500万円） 3位：内藤さん（4000万円） 4位：橋本さん（3000万円） 5位：丸井さん（1000万円） “トップ営業”と定義 （※架空の例です）
17. 提案する評価方法 ① マッチング：フォロー質問との類似発言をLLMで抽出する 00:10:20 [状況質問] 業務で何か困っていることはありますか？ 00:20:43 [状況質問] 社内での生成AIの普及率はどのくらいですか？ 00:30:02 [問題質問] 業務の効率が上がらない原因は何だとお考えですか？ … LLMで生成したフォロー質問 00:23:49 [田中] 先週話してた疑問点につい て議論させてください。 00:24:05 [佐藤] そうですね。 00:24:28 [田中] では生成AIは社内でどこま で浸透していますか？ × ② 採点：DB上の営業成績を参照してトップ営業を選定し、 トップ営業が参加する商談での質問一致率を集計する （RAGASのContext Recallと考え方が近いかもしれない） 商談の文字起こし →上記のマッチングログをBigQueryに保存しておく
18. マッチングログのスキーマ meeting_id STRING ID followup_question_id STRING ID followup_question_content STRING フォロー質問 showed_at TIMESTAMP フォロー質問が生成された時間 is_matched BOOLEAN 発言されたか matched_utterance STRING (NULLABLE) 最も類似している発言 speaker STRING (NULLABLE) 発言者 spoke_at TIMESTAMP (NULLABLE) 発言した時間 is_used_addon BOOLEAN (NULLABLE) 発言者がアプリを利用していたか utterance_offset_seconds INTEGER (NULLABLE) 提案から発言までの時間差 rationale STRING LLMで生成した判断根拠 evaluated_at TIMESTAMP 評価を実行した時間 フォロー質問と類似発言のペアをBigQueryに保存する is_matched = true && speaker in $トップ営業 でフィルタリング →効果の高いフォロー発言を収集
19. この設計におけるLLMの役割 採点者ではなく 測定器 （類似発言の抽出にのみ利用） • Reference-based Evaluationの変種。Referenceがトップ営業の実発言 • 「良さ」の根拠 ＝ 営業成績DBであり、LLMの判断ではない 強い前提：トップ営業がいない商談は採点できない • ミーティングに対する網羅性も、生成されたフォロー質問1件1件に対する網羅性もない。個々の 質問の合否判定器ではない。あくまで「トップ営業を"基準器"として、フォロー機能（生成シス テム全体）の質をサンプリング的に評価する」ことに限定した仕組み • 割り切り：網羅性を捨てる代わりに、正解が定義できないドメインで信頼できるシグナルを得る
20. 発展設計 • トップ営業の範囲の調整：現状フォロー機能による恩恵が最も高いのは非 トップ営業のサポート目的での利用。社内の営業全体の人数によっても、 トップ営業の範囲は調整が必要。 • トップ営業 vs 非トップ営業の比較：一致率の差分を見る。トップ営業だけ で一致率が高いなら「トップ営業らしい質問」を生成できている • アプリ利用の区別：アプリ利用者（is_used_addon = true） の発言は「表 示された質問を読み上げただけ」の可能性 → 除外 or 別集計し、自発的発言 のみをimplicit ground truthとして扱う • 時間差の考慮：提示前の発言（utterance_offset_seconds < 0）は純粋な自 発発言。提示直後の発言は追従の可能性があり切り分けたい
21. 限界と改善案 【限界】 • 質問一致率という非常に疎な情報しか得られない • 生成されるフォロー質問は、LLM・Promptに依存しており分布が偏る 【改善案】 • その環境における営業の良さをルーブリックにする変換器を構築する • トップ営業の発言と他営業の発言を比較し、トップ営業独自の発言を 望ましい表現として抽出する
22. 営業ドメインの類似事例：Gong • Gong：トップ営業の行動を基準器にする先行プロダクト • 数十億規模の商談インタラクションを分析し、「トップ営業は独自に何をや るか」をベンチマーク化。 • example-based smart trackers：実際の通話から採った例文（最低5文）で AIトラッカーを訓練し、キーワードでなく概念単位で発言を検出（つまり、 実発言を基準にする実装は既に製品化されている）
23. 評価を営業資産に 04
24. 評価器を作ること自体が価値を生む 今回のマッチングログは 「トップ営業が・どんな場面で・何を言うか」のデータベース • これは営業の本質的ノウハウ であり、営業資産である • 具体的な活用例 ◦ アプリケーションレイヤ：評価器が高評価をつけた発言を採用 ◦ モデルレイヤ：評価器から作ったデータでモデルを強化（GAN, PPO, …） • 新しい手法やモデルはどんどん出てくるので、自社のドメインにおける評価の 枠組みを作ることは費用対効果が大きい
25. プロンプト改善に留まらない活用 営業組織内での 対話戦略の構築 に活かせる （最初は共感し後半で論理的証拠を出そう） （A社に近い製品デモを先に見せた上で、我々の商品を提案しよう） （ニーズがズレてそうなので、別のプロダクトを提案しよう） トップ営業 マッチングログは時刻・順序を持つため、発言単位に留まらず「どの局面で・ど の順序で質問するか」という系列パターン（＝対話戦略）の分析に拡張できる
26. 展望①：LLM-as-a-Judgeの構築 蓄積されたマッチングログ ＝「この組織における正解発言コーパス」なので、 以下の方法でLLM-as-a-Judgeとして利用できる • Reference集：正解発言をfew-shotのreferenceとしてJudgeに与える • ルーブリック：正解発言群から「この組織における良い質問の条件」を言語 化してJudgeに与える 特にルーブリックとして言語化できれば、組織内での営業戦略を考える良いきっ かけにできる
27. 展望②：Judge結果からLLMの学習データを生成 トップ営業 （良い発言） （トップ営業と離れた発言） フォロー生成 • 蓄積されたマッチングログから選好ペアを構築でき、選好学習（DPO等）や蒸留（On-Policy Self-Distillation等）の学習データとして活用できる可能性がある（特にプライバシー観点から Local LLMの必要性が高まる場合がある。また、外部テナントにデータが漏洩することはなく、テ ナント内で完結する構想。詳細は補足参照。） • AIのフィードバックで学習するRLAIF, Constitutional AIの系譜。ただし選好ラベルの源泉はLLM の好みではなく 営業成績DB＋実発言 であり、「測定器」の設計思想と一貫している 【DPOの場合】 • Input: 時刻tまでの文字起こし • Positive: トップ営業の発言 • Negative: トップ営業とは離れたフォロー生成内容
28. 展望②の注意点：AI評価を学習に使うことのリスク • 誤りの増幅：判定器のバイアスや誤りは、評価だけならスコアの誤差で済む が、報酬信号にすると増幅される（cf. A Survey on Agent-as-a-Judge） • Preference Leakage：学習対象のLLMと評価に用いるLLMが同系統だと、 評価が甘くなる • The Curse of Recursion：生成データを用いた自己学習ループを積み重ね るとモデル崩壊が起きる。今回の場合フォロー機能で表示した質問を営業が 読み上げ、それが将来の「正解」として蓄積されると自分の出力で学習する 循環になってしまう。（そのために is_used_addon でフィルタする）
29. 展望③：Agentの評価へ フォロー機能の高度化（より高度な営業戦略・DB参照・API Call）に伴い、 評価もより高度になっていく可能性がある Figure 1 from Zhuge et al., "Agent-as-a-Judge: Evaluate Agents with Agents" (arXiv:2410.10934), CC BY 4.0 【ユースケースと評価方法の議論】 • 将来的にAgentのサポートが複雑化する例 ◦ 商談中の会話を元に営業戦略を作成→上司にレポート を提示→承認→即営業 ◦ Trajectoryに対するRulebased評価が第一候補 • Agent-as-a-Judgeという選択肢 ◦ AgentRewardBench：「判定器が実行後に環境とや り取りできる前提は、環境状態を保存・共有できない と成立しない」 (cf. Section 4.1) ◦ この観点だとSalesAgentは自社プロダクトで環境を 保存できる立場にあるので、Agent-as-a-Judgeが向 いているケースではある ◦ ただし、分析が困難になることはあまりやりたくない
30. 最後に 05
31. 残る課題点 【SalesAgentの観点】 • 類似発言が複数件存在する場合の考慮（意図的な可能性もある） • その人が発言するから効果があるのかも（キャラクターとの一貫性） • 発言単位（文レベル）の評価であり、話の流れや質問の順序という営業の本質はまだ捉えられてい ない→ログに時刻・順序があるので、系列レベルの分析や対話戦略への拡張が次の課題 【LLM as a Judgeの観点】 • LLMによる抽出を完全に信頼しておりメタ評価が必要（ex.人手との一貫性） • 1件ずつの評価は非常に高コスト • データから高品質な評価基準・ルーブリックを得るまでの時間が見通せない
32. まとめ 技術の問い 正解が定義できないドメインでは、 組織内の実データから 暗黙的な正解 (Implicit Ground Truth) を作る という選択肢がある。 事業の問い 評価パイプラインの副産物 が、 そのまま事業資産になり得る。 提案・設計段階の部分も含め、フィードバックがあればぜひ教えてください！
33. 補足 00
34. フレーズレベルの評価から対話戦略へ 営業の説得力は単発のフレーズではなく、話の流れ（質問の順序・組み立て）に宿る。現状のフォロー 機能はユーザーの認知負荷軽減の観点から意図的にフレーズ単位に設計しているが、今後営業戦略に基 づいたエージェントを想定すべきであり、現時点ですでにその設計が必要となる。 • ログ設計の工夫：マッチングログは showed_at / spoke_at / utterance_offset_seconds を持つ ため、既存データのまま「トップ営業が どの局面で・どの順序で 質問するか」という系列レベル の分析に拡張できる（データの取り直しは不要） 対話を「戦略ラベルの系列」として扱う研究領域 • Persuasion for Good（ACL 2019）: 説得対話1,017件に10種の説得戦略をアノテーションし、 どの戦略が効くかを分析 • ESConv（ACL 2021）: 感情支援対話を支援戦略ラベル付きで構築 • SPIN話法の4分類（状況→問題→示唆→解決）を系列として見る発想は、これらの枠組みと同型 • 評価側の発展: 対話全体を通した高次の社会的認知を測る Sentient Agent as a Judge（ACL 2025）など、発言単位でなく対話レベルで評価する研究も登場している
35. マルチテナントにおけるデータ分離の設計 • SalesAgentはマルチテナント設計だが、データの保存・利用は完全にテナント単位で分離 ◦ 評価パイプラインも同様に、文字起こし・フォロー質問・マッチングログ・一致率スコアは すべてテナント内で完結する ◦ テナントを跨いだデータ利用は一切行わない ◦ 他テナントのトップ営業の発言をreferenceにすることはない ◦ テナント横断での学習・集計・ルーブリック蒸留も行わない • 蓄積される営業資産（正解発言コーパス・対話戦略）はその組織固有の資産であり、外部に共有さ れることはない • つまり、この環境では「正解となるデータを開発者が直接分析する必要がない手法」でないと適用 できない。本アプローチはLLMによる自動マッチングで正解発言を扱うため、この条件を満たす
36. FAQ • トップ営業本人には意味がないのでは？ ◦ 直接の恩恵が大きいのは非トップ営業のサポート（発展設計のスライド参照）。ただしトッ プ営業の範囲を広げれば知識の網羅性が上がる ◦ 展望①のルーブリック言語化は、トップ営業がふんわり持っている暗黙知を言語化する営み でもある。言語化されれば本人にとっても「再現可能なスキル」になり、属人性の解消は組 織とトップ営業双方の利益となる • トップ営業が参加する商談数が少ないと統計的に不安定では？ ◦ その通り。特に会社ごと（場合によっては部署ごと）の集計になるので、統計上不安定にな る場合もある。信頼区間と合わせて提示することもできるが、根本解決策は今後考える • 類似判定LLM自体のメタ評価は？ ◦ 『残る課題点』のスライドの通り、今後の課題。