2026年秋のFall Spotlightで、商談獲得の領域に、3つのエージェントが紹介されました。案件創出エージェント、取引進行、収益管理エージェントです。HubSpotはこの3つを「商談に勝つことは営業担当が会話に入る前から始まっていて、売上が回収されるまで終わらない」という考え方で、ひとつの流れとして位置づけています。
営業現場へのAI導入の検討で、最後まで残る論点は「取引レコードの更新をエージェントに任せてよいか」という問いです。営業責任者にとって、予測の数字は自分の手で管理できる数少ない対象です。自分が見ていないあいだにエージェントが金額やフェーズを書き換える。ここで問われているのは精度ではなく、数字の管理権限を誰が持つかです。導入のご相談でも、この一点で足が止まることが少なくありません。今回の発表は、その問いに承認率という物差しで答えています。
本記事では、商談獲得の3つのエージェントと、導入の前に決めておくことを解説します。プラットフォーム基盤のコンテキストホーム・Agent Hub・Breezeアシスタント、エージェントを自作するエージェント作成ツールと HubSpot Work、需要創出の各エージェントは、それぞれ別の記事で扱います。
商談獲得の3つのエージェントが、接触から入金までを一続きにする
3つのエージェントは、パイプラインの段階ごとに役割が分かれています。
| 段階 |
エージェント |
担うこと |
| 見込み客を集める |
案件創出エージェント |
シグナルを検知し、アカウントの優先順位をつけ、接触の文面を相手に合わせる |
| 商談を決める |
取引進行 |
次に取るべき行動を示し、返信の下書きと見積を作り、CRMのプロパティを更新する |
| 売上を回収する |
収益管理エージェント |
未回収の請求書を監視し、支払いのリマインドを送り、質問に答える |
これまでは、リストを作る作業、商談を動かす作業、入金を確認する作業が、それぞれ別の担当者と別のツールに分かれていることが多くありました。3つが同じCRMの上で動くため、前の段階で分かったことが次の段階でも参照されます。
CRMの顧客情報を、次のエージェントが引き継ぐ
接触の段階で相手が反応した論点は、商談に入ってからの提案でも使えます。商談の途中で出た支払い条件の相談は、請求の段階で督促の可否を判断する材料になります。担当者が口頭やメモで引き継いでいた内容が、レコードに残った情報として次の段階へ渡ります。
この引き継ぎは、レコードに情報が残っていることが前提です。接触の履歴を営業支援ツールに、請求を会計システムに、それぞれ分けて置いている場合、3つのエージェントは同じ材料を見られません。どこまでをCRMに集めるかを、先に決める必要があります。
提供段階と対象プラン
| エージェント |
提供段階 |
対象 |
| 取引進行 |
公開ベータ |
Sales Hub または Service Hub の Professional 以上。有料シートが必要 |
| 収益管理エージェント |
公開ベータ |
すべての有料プラン |
今回の更新は、すでに提供されている案件創出エージェントに加わるものです。自社で使える範囲は、ポータルの表示で確認してください。
株式会社100の見立て:3つを同時に入れる必要はありません。導入のご相談で最初にお伺いするのは、自社のパイプラインでどのステージから先へ進まなくなっているかです。デモと提案のあいだで止まっているなら、狙うのはそのステージで、取引進行から入るのが順当です。リストを作る工数が足りていない場合は案件創出エージェント、支払い遅延が資金繰りに響いている場合は収益管理エージェントが先になります。どこから入るかは、3つを並べて比べるより、止まっている1か所を名指しできるかどうかで決まります。
案件創出エージェント|エージェントの推奨を待たずに、担当者がコンタクトを調達する
案件創出エージェントは、営業担当がその場でコンタクトを調達し、そのまま接触を始められるようになりました。
これまでは、エージェントが推奨するアカウントが出てくるのを待つ必要がありました。今回の更新で、担当者が接続済みの外部データ提供元から直接コンタクトを調達できます。リストに入っていない企業に気づいたとき、作業を止めて、リストを作る担当に差し戻す手間がなくなります。
今回加わった5つの機能
| 機能 |
何が変わるか |
| On Demand Sourcing |
接続済みの外部データ提供元から、担当者が直接コンタクトを調達する |
| Email Memory |
担当者が下書きを直した内容とフィードバックから学習し、以降の下書きの手直しが減る |
| Brand Voice per Play |
Play 単位で、ブランドの言葉づかいに合わせて設定する |
| Company Fit and Intent Scoring |
関心度に加えて、企業の適合度もスコアで示す |
| Rep-Level Performance Reporting |
刷新されたパフォーマンスタブで、担当者ごとにエージェントの推奨をどう扱っているかが見える |
Email Memory は、担当者の手直しを学習の材料にする仕組みです。文面を毎回書き換えている状態が続いているなら、その書き換え自体が、次の下書きを良くする材料になります。使い始めに手直しを丁寧に行うほど、あとの負担が軽くなります。
Company Fit and Intent Scoring は、これまで関心度を見ていたスコアリングに、企業の適合度が加わったものです。適合度が高くても関心を示していない企業と、関心が出ていても自社の提供内容と合わない企業は、取るべき対応が違います。この2つを分けて見られるかどうかで、接触の優先順位が変わります。
Rep-Level Performance Reporting で見えるのは、成果の数字だけではありません。担当者がエージェントの推奨をどう扱っているかが分かります。推奨をそのまま使っている担当者と、毎回書き換えている担当者と、そもそも開いていない担当者では、次に打つ手が違います。
株式会社100の見立て:運用に差が出るのは、On Demand Sourcing と Company Fit and Intent Scoring の組み合わせです。これまでリスト作成に充てていた工数が、そのまま接触の量に振り替わります。ただし適合度スコアの前提になるのは、コンテキストホームに入っている理想的なお客さま像(ICP)です。ここが空欄のままだと、スコアは業種と従業員規模だけで決まってしまいます。案件創出エージェントを試す前に、コンテキストホームの顧客タブに自社の判断基準を書いておくことをおすすめします。
取引進行|会話と会話のあいだで、取引計画を最新に保つ
取引進行は、メールと会話の内容から次に取るべき行動を示し、取引計画を会話のあいだも最新の状態に保ちます。
Smart Deal Progression の機能強化です
すでに Smart Deal Progression をお使いの場合、これは単なる名称変更ではなく、機能の強化です。中核の能力は変わりません。変わったのは動く範囲で、これまでのように会議後にCRMを更新するだけでなく、メール・通話・会議をまたいで動きます。
これまでの設定や、社内で共有している手順は、そのまま使えます。名称が変わるため、社内の資料だけは先に直しておくと混乱を避けられます。
取引進行が実行すること
- 次に取るべき最善の行動を示す
- 返信メールの下書きを作る
- 見積を作成する
- CRMのプロパティを更新する
- 営業手法との対応づけを維持する
- 会話と会話のあいだも、取引計画を最新に保つ
営業担当は、取引レコードの画面と受信トレイの中で、そのまま実行できるガイダンスを受け取ります。HubSpotはこの設計の理由を「商談の勢いは、会話と会話のあいだの空白で失われる」と説明しています。商談が止まるのは、多くの場合、打ち合わせが終わってからの数日です。
どのデータを参照するか
| 種類 |
中身 |
| CRMのレコード |
取引、コンタクト、企業の各レコードと、その履歴 |
| やりとりの記録 |
過去のメール、メモ、取引の活動、コンタクト履歴 |
| 会議の文字起こし |
HubSpot Notetaker、Zoom、Teams、Meet |
参照先に会議の文字起こしが入っている点が、これまでとの大きな違いです。打ち合わせで出た条件や懸念が、営業担当の入力を待たずに取引計画に反映されます。
気づく場所も変わります。これまでは、CRMを開いて取引レコードを確認する必要がありました。取引進行は受信トレイの中でもガイダンスを示すため、メールに返信する流れの中で次の行動が分かります。CRMを開く回数が減るほど、入力の抜けも減ります。
株式会社100の見立て:この機能の前提は、会議の文字起こしがCRMにつながっていることです。録画を各自の端末に保存していたり、会議ツールの中だけに残していたりすると、参照できる材料は過去のメールだけになります。取引進行を試す前に、社内で使っている会議ツールの文字起こしが、取引レコードに紐づいて保存されているかを確認してください。ここが整っていないと、示される次の行動は一般的な内容にとどまります。
実際に使っている営業手法を読み取って、プロパティに対応づける
取引進行は取引プロパティを一通り確認し、そのポータルで実際に使われている営業手法を特定します。そのうえで、手法の主要な要素をどのCRMプロパティに対応づけるかの案を、自動で提示します。
営業手法を導入していても、CRM上では自由記述のメモに残るだけで、プロパティとして構造化されていないことがよくあります。その状態では、手法にそって商談が進んでいるかを集計できません。対応づけの案が示されるため、この整備に着手しやすくなります。
クレジットの消費
中核機能と既定プロパティの更新は、有料シートに含まれており、クレジットを消費しません。カスタムプロパティと営業手法のプロパティを更新する場合はデータエージェントを経由するため、更新した分のクレジットを消費します。
株式会社100の見立て:ここは見積の前提が変わる箇所です。取引の状態を自社で定義したカスタムプロパティで管理している場合、更新のたびにクレジットを消費します。既定プロパティで足りる項目と、カスタムプロパティで持つ必要がある項目を先に分けておくと、消費量の見通しが立つようになります。実際の消費量は、承認制で運用している最初の数週間の記録から見積もるのが確実です。
任せる範囲は、承認率を測りながら広げる
冒頭の問いに戻ります。取引レコードの更新をエージェントに任せてよいかは、最初にすべてを決める必要はありません。HubSpotは、次の3段階で広げる形を示しています。
- すべての操作を承認制から始める。エージェントは提案までを行い、担当者が承認するまで反映されません
- 承認率を測る。提案のうち、担当者がそのまま承認した割合を記録します
- 承認率で信頼を得た操作にだけ、自動で実行する範囲を広げる
あわせて、最初のエージェントを動かす前に支出の上限を設定します。この2つで、意図しない操作と想定外の消費を、どちらも防げます。
承認率は、操作の種類ごとに分けて取ります
承認率を全体で1つの数字にまとめると、判断の材料になりません。返信メールの下書きは9割承認されているのに、取引ステージの変更は半分しか承認されていない、という状態は実際に起きます。この場合に自動化を広げてよいのは、返信の下書きだけです。操作の種類ごとに分けて記録してください。
却下した理由も一緒に残しておくと、あとの改善に使えます。提案の内容が間違っていたのか、内容は正しいが社内の手順に合わなかったのかで、次に直す場所が変わります。前者はエージェントに渡している情報の問題で、後者は運用ルールの問題です。
承認率は、社内で説明するための材料になります
承認率の推移は、今回のリリースで最も分かりやすい成熟度の指標です。「エージェントが提案した100件のうち、92件は担当者がそのまま承認した」という記録があれば、任せる範囲を広げる判断に、根拠を持たせられます。承認率が低い操作には、任せる前に直すべき点が残っています。
株式会社100の見立て:どの操作を自動で実行させるかは、設計として決めることです。おすすめしている進め方は、営業責任者に「この操作のうち、誰も確認しない状態でエージェントに任せて構わないものはどれですか」と1つずつ尋ねることです。ためらいが出た操作を、そのまま承認制に残します。この会話を先に済ませておくと、運用開始後に「勝手に動いた」という話になりません。取引ステージの変更と、予測に関わるプロパティは、承認制に残す判断をされるお客さまが多いです。
基盤編で扱った Growth Context の考え方と、この承認率はつながっています。AIの回答の質は、渡している情報の質で決まります。承認率が上がらないとき、まず見直すのはエージェントの設定よりも、コンテキストホームに入っている自社の情報です。
収益管理エージェント|入金の回収までを商談の範囲に入れる
収益管理エージェントは、未回収の請求書を監視し、支払いのリマインドを送って、入金までの日数を短くする、売掛金管理のための機能です。
商談は、見積書に承諾をいただいた時点では終わりません。売上が回収されて終わります。督促は必要な業務ですが、担当者が手作業で追いかけているうちは、件数が増えるほど抜けが出ます。収益管理エージェントは、未回収の請求書を監視し、相手に合わせた支払いのリマインドを送り、お客さまからの質問に答え、会話の展開に合わせて対応を変えます。
督促を止める判断ができます
支払いが遅れている理由は一様ではありません。単純な支払い漏れのほかに、サポート上の問題を抱えている、契約内容が変わっている、請求内容に相違がある、といった状況があります。収益管理エージェントは Growth Context を参照して、この違いを区別します。区別できると、督促を止めて、適切な担当者に引き継げます。
督促を自動化するときに心配されるのは、お客さまとの関係が悪くなることです。この区別の仕組みは、その懸念に対する答えになります。
例外を誰が判断するかを、先に決めておきます
区別の仕組みがあっても、督促を止めるべき状況のすべてがCRMに残っているとは限りません。営業担当が口頭で聞いた事情や、経営層の間で進んでいる契約の話は、レコードに入っていないことがあります。こうした事情を督促の対象から外せるように、社内で伝える道筋を決めておく必要があります。
運用の設計として決めるのは、督促を止める権限を誰が持つか、そしてその判断をどこに記録するかの2点です。特定の取引先を対象から外す操作を営業担当ができるのか、経理部門の承認を挟むのかで、運用の負荷が変わります。
課金が発生する時点を、先に社内で共有してください
収益管理エージェントの課金は、入金が回収された時点ではなく、督促を開始した時点で発生します。請求書1件について督促を始めると、その時点でクレジットを消費します。回収できたかどうかは課金に影響しません。
回収を助ける機能であるため、成果報酬型だと受け取られやすくなっています。経理部門と情報システム部門に、この点を先に共有しておくことをおすすめします。
いまの請求データをそのまま使います
QuickBooks から HubSpot へ請求データを同期している場合、収益管理エージェントは同期済みの請求データを使って動きます。請求の仕組みを作り替える必要はありません。
株式会社100の見立て:収益管理エージェントを検討する前に、売上債権回転日数を測っておいてください。この数字がないと、導入後に短くなったかどうかを説明できません。もう1点、名前の似た Revenue Hub は、Commerce Hub が改称されたものです。収益管理エージェントとは別のものなので、社内で検討する際は取り違えないようにしてください。
まとめ|いまから着手できる3つのこと
HubSpotが今回示した変更点
- 商談獲得を、案件創出エージェント・取引進行・収益管理エージェントの3つで、接触から入金まで一続きの領域として扱う
- 案件創出エージェントに、その場でのコンタクト調達、手直しからの学習、Play ごとの言葉づかい、企業の適合度のスコア、担当者ごとに推奨の扱い方が分かるレポートが加わった
- 取引進行は Smart Deal Progression の機能強化で、メール・通話・会議をまたいで動き、会議の文字起こしも参照する
- 任せる範囲は、すべて承認制から始めて承認率を測り、信頼を得た操作にだけ広げる
- 収益管理エージェントの課金は、督促を開始した時点で発生する
株式会社100の見立て|いまから着手できる3つの作業
次の3つは、当社が導入支援の現場から申し上げる優先順位です。1つ目と2つ目は、HubSpotも診断の工程として挙げています。
- 止まっているステージを1つ名指しする。受注率、営業サイクルの長さ、ステージ間の転換率を出して、どこから先へ進まなくなっているかを特定します。ファネル全体を対象にすると、効果が測れなくなります
- 着手前の数値を記録する。受注率、営業サイクルの長さ、ステージ間の転換率、営業担当1人あたり週あたりの打ち合わせ設定件数、売上債権回転日数、そしてエージェントごとの承認率です。承認率は最初の1週間から記録してください。後から遡って取れない数字です
- 会議の文字起こしと請求データの接続状況を確認する。取引進行と 収益管理エージェントは、どちらも既存データの上で動きます。つながっていない状態で試しても、出てくる内容は一般的なものにとどまります
プラットフォーム基盤、エージェント作成ツールと HubSpot Work、需要創出の各エージェントについては、別の記事で解説しています。あわせてご覧ください。
営業のAIで最初に決まるのは、どのエージェントを入れるかよりも、どこまでを担当者の確認に残すかです。自社ではどの操作を承認制に残すかを、一度整理してみてはいかがでしょうか。私たちも、お客さまの運用設計を支援できる体制づくりに取り組んでまいります。