AIでCRMの商談メモを自動要約する方法｜次アクションまで整理

CRM商談メモのAI要約は、短い要約文を作るだけでなく、顧客の目的、確認できた事実、未解決の懸念、次の行動を別々に記録すると実務で使いやすくなります。担当者・期限・商談段階は会話に根拠がある場合だけ候補にし、AIが補った予測を確定情報としてCRMへ保存しないでください。まず要約を下書きし、人が確認して必要な項目だけ更新する流れが基本です。

要約より先に決める出力項目

CRMへ入れる情報を先に決めます。文章を自由に短縮させてから項目を探すより、記録欄の意味を固定すると、次の担当者が根拠と未確定事項を見分けやすくなります。以下は小さく始めるための出力例です。

| フィールド | 入れるもの | 空欄にする条件 |

| 顧客の目的・課題 | 顧客が実現したいこと、困っていること | 発言から確認できない |

| 確認済みの事実 | 現在の手順、対象人数、期限など | 伝聞やAIの推測だけ |

| 決定事項 | 合意した範囲、保留事項 | 提案しただけで合意していない |

| 懸念・質問 | 顧客が示した懸念と回答状況 | 感情を推測しないと書けない |

| 次の行動 | 発言・合意に基づく作業 | 「フォローする」以上に特定できない |

| 担当・期限 | 誰がいつまでに行うか | 会話や担当者入力に根拠がない |

| 根拠 | 発言の短い引用、時刻、資料名 | 元記録をたどれない |

出力は「要約」「根拠」「未確認」「人が決める欄」に分けます。たとえば「来月までに導入したい」は顧客の希望として記録できますが、「来月契約する」「受注確度が高い」は別の判断です。希望を契約時期やforecastへ置き換えず、次に確認する条件を残します。

入力を揃えてから要約する

会議録、通話文字起こし、営業担当のメモ、関連メールが別々に保存されている場合、AIへ渡す前に対象のCRMレコードと会話の対応関係を確かめます。別顧客の記録が混ざると、流暢な文章でも役に立ちません。会議日時、参加者、会社、対象dealを照合し、重複した文字起こしや自動署名、雑談をどこまで含めるかを決めます。

入力データの選び方は精度とプライバシーの両方に影響します。CRMの全履歴を無条件に渡すのではなく、この商談の次の行動に必要な範囲を選びます。顧客の個人情報や機密情報が要約に不要なら除外し、サービス側の処理条件、権限、保存期間も組織の契約と設定で確認してください。製品の機能説明だけでは、自社のデータ利用条件まで確定しません。

処理順は、対象recordの確認、必要な会話資料の紐付け、要約の生成、根拠照合、候補fieldのレビュー、CRM保存です。生成を自動化しても、最初は下書きキューへ出し、担当者が承認してから更新します。確定更新を自動化する場合は、対象fieldと上書き条件を限定し、変更履歴を追えるようにします。

発言から次の行動へ変換する

次の行動は、会話中の発言をそのままタスク化できるものと、追加確認が必要なものに分けます。「顧客が見積書を希望した」は、見積書作成という候補にできます。ただし担当者や提出日が会話にないなら、その欄は未設定にします。「社内で検討する」は顧客側の行動ですが、誰がいつ返答するかまで合意していなければ、期限付きタスクを創作しません。

| 会話の記述 | AIが出す候補 | 人が確認すること |

| 「来週、導入条件を社内で確認します」 | 顧客側の確認待ち | 来週の具体日、連絡担当が合意済みか |

| 「対象部署の人数が分かれば見積もれる」 | 人数確認後に見積作成 | 誰が人数を調べるか、期限 |

| 「価格が予算に合うか心配」 | 価格・予算条件の確認 | 想定予算を聞いたか、値引き判断が必要か |

| 「資料を送ってください」 | 資料送付 | どの資料か、宛先、送付期限 |

| 「また連絡します」 | 具体的なActionは保留 | 誰からいつ連絡するかを再確認 |

プロンプトやworkflowには、「根拠のない値は空欄」「提案と合意を分ける」「日付を相対表現のまま残す」「不明なら確認事項を列挙する」といった規則を入れます。空欄を減らす目的で、モデルに担当者・期限・金額を補完させてはいけません。埋まった欄の数より、誤った確定情報が混入しないことを優先します。

生成結果を評価する小さなテスト

導入初日は、実際の顧客情報を使う前に匿名化した過去recordや合成データでテストします。正常な商談だけでなく、発言が曖昧な会話、複数の人が話す会議、途中で条件が変わる会話、否定・保留が多い会話を含めます。各ケースで、重要な発言が落ちたか、話者を取り違えたか、提案を合意と誤認したか、期限を作ってしまったかを採点します。

最低限の評価項目は、①顧客の目的が元発言と一致する、②決定と未決定が区別される、③次Actionの根拠をたどれる、④担当・期限の不明欄が不明のまま残る、⑤個人情報が不要に複製されない、です。正答率だけでなく、重大fieldの誤更新をゼロにできるかを別の停止条件にします。少数のケースで見逃しがあれば、自動保存を始めず、対象field・入力範囲・review画面を見直します。

HubSpotの公式案内では、workflowでrecordを要約する機能、conversation transcriptの同期、dealの次の行動に関する提案がそれぞれ説明されています。機能の利用条件や必要な権限、credit、beta・seat条件は同じではありません。利用できる機能を一括して「CRMが次Actionまで自動確定する」と捉えず、契約プランと管理画面で個別に確認してください。提案機能は担当者が採用・編集・拒否できる前提で扱います。

失敗したときの切り分け

要約が使いにくい場合、プロンプトだけを何度も調整する前に、入力、分類、出力、CRM書き込みのどこで誤りが起きたかを特定します。違うdealの会話が紐付いているなら入力選定の問題です。発言は正しいのに「希望」が「決定」へ変わるなら、分類ルールと出力schemaを見直します。要約は正しいのに担当・期限が埋まるなら、補完禁止のルールとfield mappingを確認します。

保存後に誤りを見つけた場合に備え、更新元、実行時刻、承認者、変更前後を追跡できるようにします。CRMの重要propertyを直接上書きするworkflowは、対象を絞ったrollback手順と例外キューなしに広げないでください。会話の記録を更新した人が後から確認できない設計なら、自動化より手動レビューを選びます。

次の商談に引き継ぐ

よい要約は会話の短縮版ではなく、次の担当者が「何が分かっていて、何を確かめ、誰が動くか」を短時間で把握できる記録です。冒頭に結論だけ置き、その後に根拠と未確認点を残すと、読み手は全文の文字起こしへ戻る必要がある場面を判断できます。要約から次回の確認事項へつなぎ、商談の進捗やforecastは営業担当が別途判断します。

始めるときは、重要fieldを一つに絞り、数件のrecordで下書き運用を行います。根拠を参照できる割合、重大な誤分類、担当者の修正量、更新にかかった時間を確認し、導入前より次Actionが明確になったかを評価します。要約の長さが短くなっただけなら、Reader Jobが改善したとは言えません。

AIものさしの判断

CRM要約の自動化で先に整えるのは、短縮率ではなく「source付きの事実」「提案と決定の区別」「人が承認するfield」です。会話にない担当や期限は空欄でよく、未確定が見えること自体が安全な出力です。まずは要約を下書きにし、誤更新を検知できる評価と履歴を確認してから、自動保存の範囲を決めます。

30秒で読むための表示順

CRMの要約欄には、最初に「顧客が求めていること」「今回決まったこと」「次に確認すること」を置きます。根拠や全文へのリンクはその下に置き、短時間で読む人と詳細を確認する人の両方が使えるようにします。次の担当者が一覧画面で見る項目が限られる場合は、長い要約をそのまま一つのpropertyへ入れず、CRMの欄を分けるか、recordへのリンクを添えます。

| 表示順 | 一覧に出す内容 | 省略してはいけない条件 |

| 最初 | 状態・要点 | 「合意」と「提案」を区別する

| 次 | 次Actionと担当 | 未定なら未定と表示する

| 詳細 | 根拠・未確認事項 | 元発言へ戻れるリンクを保つ

文章量を減らすために条件を落としていないかを確認します。たとえば「導入を希望」だけでは、対象部署、開始時期、決裁者、未解決条件が見えない場合があります。全項目を埋める必要はありませんが、商談を次へ進めるために不足している情報を「次に確認すること」として示します。

自動化の段階を分ける

導入は、①要約案だけ生成、②分類済みfieldを担当者へ提示、③承認後にfield更新、④限定されたfieldを自動更新、のように段階を分けます。最初から③や④へ進む必要はありません。少数の担当者と対象dealで下書き品質を見て、修正の種類を記録し、誤更新リスクが低いfieldから範囲を広げます。forecast、金額、deal stageのように評価や経営判断に使う項目は、人による判断を維持するのが安全です。

各段階の移行条件も数値だけでなく失敗の重さで定めます。誤った会社・担当者の紐付けが1件でも起きた場合は自動保存を止める、期限や金額の創作が一定件数を超えたら入力とschemaを再設計する、といった停止条件が考えられます。モデル更新後や文字起こし方式変更後も、同じ評価ケースを再実行します。

導入後に見直す条件

導入後は、文字起こし精度、CRMの項目設計、商談の進め方が変わったときに評価ケースを更新します。利用者から修正が多い欄は、モデルの品質だけでなく欄の意味や入力元が曖昧でないかも確認します。改善の判断は、要約が短くなったかではなく、担当者が根拠を見つけ、次の確認を選べる状態になったかで行います。