HubSpot で商談議事録をリードプロパティーに落とす — AI 要約は「読める」が「効かない」

HubSpot Japan の「AI を活用した営業活動の効率化」4 日連続シリーズ、その 2 日目のテーマが商談議事録とプロパティー更新だった。1 日目のカスタムシグナルについてはHubSpot のカスタムシグナル — 「買いのサイン」を自然言語で書くと AI が Web を見張ってくれるに書いた。

メール本文は 1 日目より薄い。「商談内容をもとに要点整理や CRM 項目の更新を効率化できると、入力工数を抑えながら、必要な情報を残しやすくなります」——これだけである。機能名も、どのアクションを使うのかも書いていない。

ただし添付されていた実機スクリーンショットのほうが、本文よりはるかに情報量が多かった。デモポータルのコンタクトレコードに AIによるコンタクト調査 という専用タブがあり、そこに 3 種類の AI 生成プロパティーが並んでいた。この 3 種類の作り分けが、この機能の実務上の要点そのものだった。

この記事では、営業メールが省略した部分——組み込みの AI 要約でなぜ足りないのか、議事録をプロパティーに落とす経路が実は 3 つあること、そしてクレジットが尽きたときに起きる厄介な挙動——を埋めていく。

営業メールが挙げていた課題

• 商談後の議事録作成に毎回時間がかかる
• CRM の更新が後回しになり、入力漏れが出る
• 引き継ぎや振り返りのための情報が揃いにくい

この 3 つは同じ問題ではない。1 番目は文章を書く手間、3 番目は読む手間で、どちらも「要約」で解決する。だが 2 番目の「CRM の更新」は質が違う。CRM が更新されていないと困るのは、人が読めないからではなく、セグメントの絞り込みやワークフローの分岐が空振りするからだ。

この違いを踏まえずに「AI で議事録を要約する」だけをやると、次の落とし穴に落ちる。

落とし穴: 組み込みの AI 通話要約は「読める」が「効かない」

HubSpot には最初から通話の AI 要約がある。**コミュニケーションインテリジェンス（CI）**の一部で、Sales Hub または Service Hub の Professional 以上が必要になる。

要約は決まったセクションに分かれて生成される。

営業担当が振り返るには十分な粒度で、Auto / Support Rep / Sales Rep のテンプレートも選べる（サポート担当向けはケース解決に、営業担当向けは商談インサイトに寄った要約になる）。ただしこの Breeze コールサマリーを使うには、アカウントで Breeze アシスタントと通話レコーディングの両方を有効化しておく必要がある。文字起こし自体は自動言語検出で行われ、日本語も自動文字起こしの対応言語に含まれている。

問題はここから先だ。この要約には次の性質がある。

1. 編集不可のフィールドである。人が直すことを想定していない
2. コール（アクティビティー）オブジェクト側に付く。リードであるコンタクトや取引のプロパティーではない
3. 自由記述テキストである。「クレームの気配があるか」を条件にしたくても、部分一致で拾うしかない

つまり、人が開いて読む分には効くが、「クレームの気配がある顧客だけ抽出して担当マネージャーに通知する」といった自動化の入力にはならない。営業メールが言っていた「CRM の更新が後回しになる」問題は、組み込みの要約では解けていない。

解くには、議事録をリード側の構造化されたプロパティーに書き込む必要がある。その配管がこうなる。

議事録をプロパティーに落とす 3 つの経路

この変換を担うのが データエージェント（データ管理 > データエージェント）である。データエージェントは 3 つの構成要素を持つ。

• スマートプロパティー — プロパティー自体に AI プロンプトを埋め込む
• スマートアクション — ワークフローに組み込む AI アクション
• スマート列 — データポータルのデータセットに AI 列を足す

議事録からリードプロパティーを更新する用途では、次の 3 経路が候補になる。

議事録を読ませたいなら、鍵になるのは太字にしたデータソースだ。

スマートプロパティーの「アクティビティーと文字起こし」 は対象が広い。記録されたコール、E メール、ミーティングの文字起こし、そしてレコードに関連付けられたメモからデータを取る。さらに「アクティビティータイプ」で対象を絞り込める。手入力の議事録メモも対象になるので、通話録音を運用に載せていないチームでも使える。

「データエージェント：調査」のコールの文字起こし は範囲がはっきり狭い。関連付けられた直近 5 件のコールのみである。長期の取引で「初回商談で言っていたこと」を拾いたい場合、この経路では届かない。

作った値をどこで受けるか

ワークフロー系の 2 アクションは、出力を返すだけでプロパティーには書かない。書き込みは別アクションで行う。

• ［レコードを編集］アクション — 編集するプロパティーを選び、値のフィールドで「アクションデータ」セクションから当該アクションの 応答 を選ぶ
• 分岐 — 1 件のプロパティーまたはアクション出力 を選び、同じく「アクションデータ」から 応答 を選ぶ。プロパティーに残さず分岐だけしたい場合はこれで足りる
• 自動 E メールのカスタムトークン — Marketing Hub Enterprise が必要。1 アカウント最大 1,000 件のトークンを作れる

スマートプロパティーのほうは書き込み先が自分自身なので、この手間はない。代わりに ［スマートフィルプロパティー］ での一括入力や、スケジュール／レコード作成時の自動入力を設定する。

実機スクリーンショットから読み取れる設計

ここが本題である。営業メールの添付スクリーンショットには、AI 生成プロパティーが 3 種類に作り分けられていた。この分類が実務の勘所だと思う。

① 要約系 — 人が読むための項目

問い合わせメモ要約(AI) のような、複数行テキストの項目。引き継ぎと商談前の事前準備の時間を削るのが目的で、値の書式は問わない。

② 判定系 — 出力の書式を固定する

クレーム検知(AI) がこれだった。値の中身が示唆的で、こういう形をしていた。

【クレーム兆候】
判定｜🟡 ややあり
要点｜現行プリンターの遅さと紙詰まりへの課題感が報告
時期｜2026年1月の通話で最近の苦情増加に言及
対応｜プリンター更新提案と見積もり準備で合意済み
温度｜穏やかで前向きな相談トーンで強い怒りなし
反復｜不具合は継続傾向だが具体的反復事例は不明
上申｜サポート部門への対応依頼メモありも公式上申不明

ポイントは 3 つある。

行ラベルを決め打ちしている。 判定 / 要点 / 時期 / 対応 / 温度 / 反復 / 上申 という 7 行が固定なので、レコードを開いた人が毎回同じ位置を見れば済む。AI に自由に書かせると段落構成が毎回変わり、目が滑る。

先頭に判定を置き、絵文字を付けている。 🟡 ややあり が 1 行目にある。一覧ビューで列を並べたとき、先頭の数文字だけで温度感が分かる。

「不明」を書かせている。 反復｜不具合は継続傾向だが具体的反復事例は不明 のように、根拠が足りないところを明示している。これがないと、AI が空白を埋めるために推測を書き、それが CRM の既成事実になる。

この形にするなら、プロンプト側で書式を指定する。公式ドキュメントも、後続アクションに合わせて応答を制限することを推奨しており、「必ず『メーカー』または『輸入業者』のいずれかの値を含む、一語の回答で応答してください。」という例を挙げている。判定系ならこうなる。

以下の商談メモと通話内容から、クレームの兆候を評価してください。

出力は必ず次の 8 行だけで構成してください。前置きや結論の補足は書かないこと。
【クレーム兆候】
判定｜(🔴 高い / 🟡 ややあり / 🟢 なし のいずれか 1 つ)
要点｜(1 文)
時期｜(1 文)
対応｜(1 文)
温度｜(1 文)
反復｜(1 文)
上申｜(1 文)

各行について、根拠となる記述が資料内に無い場合は推測せず「不明」と書いてください。

③ 分類系 — ここだけが自動化の条件として効く

分類 部署カテゴリ(AI) がこれで、スクリーンショットでは 次世代総務企画部一課 という自由入力の部署名に対して 総務・庶務系 という値が入っていた。表記揺れの正規化である。

そして重要なのは、スマートプロパティーで選べるフィールドタイプに列挙型が含まれることだ。

• 単行テキスト
• 複数行テキスト
• 数値
• 1 つのチェックボックス
• 複数のチェックボックス
• ラジオボタン選択
• ドロップダウン選択

ドロップダウン選択やラジオボタン選択にしておくと、そのままセグメントの絞り込み条件やワークフローの分岐条件に使える。 ①の要約系と②の判定系は自由記述なので、条件に使うには部分一致に頼ることになる。「議事録から CRM を更新する」の実利は、ほぼこの分類系プロパティーに集まっている。

ワークフロー側の「データエージェント：カスタムプロンプト」でも、［アクション出力］で出力タイプに［列挙］を選べば同じことができる。値のリストを定義して、AI の応答をその選択肢に縛る。

AI 由来の項目は専用タブに隔離する

スクリーンショットで AIによるコンタクト調査 という専用タブが切られていたのも、意図的な設計だと思う。人が入力した値と AI が推定した値を同じ画面に混ぜない。

レコードの中央パネルはタブを追加でき（レコードをカスタマイズ）、最大 5 つまで設定できる。全製品・全プランで使える機能なので、ここは追加コストなしで真似できる。

なお、スマートプロパティーの値には根拠を辿る導線がある。一覧ビューのスマートプロパティー列で行にマウスを乗せて AI ボタン → 詳細をすべて表示 → ソース タブで、参照されたソース資料が出る。判定系プロパティーの検証はここで行う。

実装で踏みやすい落とし穴

カスタムプロンプトは「プロンプトに書いたものしか見ない」

ここは公式ドキュメントがかなり強い言い方で警告している部分だ。「データエージェント：カスタムプロンプト」アクションは、プロンプトに追加したデータ以外のコンテキストを一切持たない。

例えば、プロンプトに追加しない限り、登録されたレコードの他のプロパティー、タイムラインのアクティビティー、最近送受信した E メールの内容などは利用されません。

さらに LLM はインターネットに接続されていない。「レコードを見て判断してくれる」と思って短いプロンプトを書くと、何も見ずに答える。必要なプロパティーはデータ変数・パーソナライズトークンとして明示的に差し込む必要があり、しかもプロンプトは 3,000 文字までなので、長い議事録を全文流し込むのは現実的でない。

議事録本文を読ませたいなら、素直に「データエージェント：調査」のコールの文字起こしか、スマートプロパティーのアクティビティーと文字起こしを使うほうがいい。カスタムプロンプトは、既にプロパティーに入っている値を材料に判定・整形させる用途に向いている。

クレジットが尽きると null が入る

これが一番厄介な挙動だと思う。

アカウントに十分なクレジットがない場合、[データエージェント:カスタムプロンプト]アクションは失敗し、出力として null 値が入力されます。

null は「クレームの兆候なし」と区別がつかない。分岐で 応答 = 🟢 なし 以外を通す作りにしていると、クレジット切れの月だけ全件がアラート側に流れるか、逆に全件が素通りする。null／未設定の分岐を必ず用意して、そこはアラートか手動確認に回す設計にしておきたい。

値が入らなくてもクレジットを消費する

スマートプロパティーも同じ方向の注意がある。

スマートプロパティーを実行すると、プロパティーの値が入力されていなくても HubSpot クレジットが消費されます。

空振りが課金対象になるので、自動入力の設定でセグメントを絞るのが効く。スケジュール自動入力は対象セグメント・頻度（日次／週次／月次）・曜日／日付・時刻を指定できるので、「議事録が付くのは商談があった相手だけ」という前提でセグメントを切っておく。全コンタクトを日次で回すのは、コスト的にも精度的にも意味がない。

その他の制約

• スマートプロパティーには検証ルール（一意の値を必須にするなど）とセンシティブデータを適用できない
• LinkedIn を参照するプロンプトは除外され、値を返さないことがある
• スマートプロパティーの「プロパティーデータ」ソースは参照できるプロパティーが 1 つだけ。ファイルプロパティーを選ぶと最初にアップロードされた PDF が使われる
• 権限は、作成に プロパティー設定の編集（またはスーパー管理者）、実行に データエンリッチメントアクセス権（またはスーパー管理者）。ワークフロー側は ワークフロー 権限
• AI 設定で 生成 AI ツールや機能へのアクセス権をユーザーに付与 と CRM データ をオンにする必要がある。アクティビティーと文字起こしを使うなら 顧客との会話データ と ファイルデータ も必要

本番に載せる前に必ずプレビューを回す

両経路にドライランの導線がある。ワークフローのアクションには ［アクションをテスト］ があり、対象レコードを選ぶと成否と生成される応答が確認できる。スマートプロパティーの作成パネルにも レコードのプレビュー と 結果をプレビュー がある。

プロンプトの試行錯誤はここで済ませる。クレジットを消費しながら本番レコードに書き込んで気付く、という順序にすると、汚れたデータを後から掃除する仕事が発生する。

料金プランとクレジット

必要なプランは経路によって違う。ここは見積もりの分かれ目になる。

そして全体に HubSpot クレジットが乗る。クレジットは月次でリセットされ、未使用分は繰り越されない。使い切ると従量課金の機能は次のリセット日まで停止するか、容量パックを買うことになる（購入後は auto-upgrades か pay-as-you-go overages を選ぶ）。複数の Hub を契約している場合、付与数は最上位プランのものが適用される。

具体的な付与数（Starter 500 / Professional 3,000 / Enterprise 5,000）やスマートプロパティー 1 レコードあたりの消費数（10 クレジット）といった数字はサードパーティの解説記事でよく見かけるが、HubSpot 公式のナレッジベースはこれらを明記せず、「クレジットレートは機能の進化に伴い変わる可能性がある」として製品・サービスカタログを参照させている。単価と付与数はカタログと自ポータルのクレジット管理画面が正なので、対象レコード数 × 頻度で見積もる前に必ず確認したほうがいい。

なお使用状況は データ管理 > データエージェント > 管理 タブで確認できる。入力数・正常な実行・エラー数の測定指標が出るので、クレジットを溶かしている割に値が入っていないプロパティーはここで特定して止める。

Professional で何が開くかについてはHubSpot Professional にアップグレードするメリットを 6 Hub 別に整理にまとめてある。

まとめ

営業メールの「要点整理や CRM 項目の更新を効率化」という一文は、実は 2 つの別の仕事をひとまとめにしていた。分けて考えるとこうなる。

要点整理は組み込みの AI 通話要約でほぼ済む。Sales Hub / Service Hub Professional 以上なら追加の設計なしで動くし、日本語の文字起こしにも対応している。

CRM 項目の更新は自分で配管を組む必要がある。組み込みの要約はコール側の編集不可な自由記述で、リードの絞り込みや分岐には効かない。データエージェント（スマートプロパティー、またはワークフローのカスタムプロンプト／調査）で、議事録を列挙型プロパティーに落として初めて自動化の入力になる。

そして実機スクリーンショットが教えてくれた設計の要点は 4 つだった。

1. AI プロパティーを要約系・判定系・分類系に作り分ける
2. 判定系は出力の行ラベルを固定し、根拠がなければ「不明」と書かせる
3. 分類系はドロップダウン／ラジオボタンにする。ここだけが自動化の条件として効く
4. AI 由来の項目は専用タブに隔離して、人の入力と混ぜない

技術者として押さえておきたい落とし穴は 3 つ。カスタムプロンプトはプロンプトに書いたものしか見ない（3,000 文字上限、インターネット非接続）。「調査」の文字起こしは直近 5 件のコールのみ。そしてクレジットが尽きると出力に null が入り、「該当なし」と区別できない——だから null 側の分岐を必ず作る。

営業とマーケの境界でこういうデータ配管を組む役割についてはGTMエンジニア — AI時代に生まれた「1人で3チーム分」の新職種でも触れている。「AI で議事録を要約する」で止めるか、「議事録を CRM の判断材料に変える」まで行くかの差は、この配管を引く人がいるかどうかで決まる。

参考リンク

• Breeze を使ったワークフローのデータ管理 — HubSpot ナレッジベース
• スマートプロパティーを使用してレコードを自動的に入力 — HubSpot ナレッジベース
• データエージェントを設定して使用する — HubSpot ナレッジベース
• 通話のレコーディングと文字起こしを確認する — HubSpot ナレッジベース
• Understand HubSpot Credits and billing — HubSpot Knowledge Base
• 製品・サービスカタログ — HubSpot Legal Center