HubSpot「Agent Hub」に見る、顧客状態を共有する設計

クレーム対応中の顧客に、別のAIエージェントが新規営業の連絡を送る。

HubSpotが2026年7月23日の発表で例示したのは、複数のAIエージェントが異なる顧客像をもとに動くことで生じる、こうした接点の衝突です。

個々のエージェントは設定された業務を実行していても、他のエージェントが同じ顧客に対して何をしているかを把握していなければ、会社全体では矛盾した対応になり得ます。

HubSpotは、この問題に対応する新機能として「Agent Hub」と「Agent Builder」を公開ベータで発表しました。

この発表から考えたいのは、管理するエージェントの数ではありません。

複数のエージェントが同じ顧客に関わるとき、どの情報を共通の事実として扱い、現在の状態をどう定義し、処理が競合したときにどちらを優先するか、という設計です。

HubSpotが挙げた「エージェントの分断」

HubSpotは2026年7月23日、営業・マーケティング・カスタマーサポートなど部門をまたいで使うAIエージェント関連の新機能「Agent Hub」と「Agent Builder」を公開ベータとして発表しました。

2026年8月確認時点で、提供対象はProfessional・Enterpriseプランの契約者とされています。

Agent Hubは、HubSpot上で利用するAIエージェントの稼働状況や成果を、一つの画面から確認・管理するための機能です。

まだ有効化されていないエージェントを確認してその場で有効化したり、需要創出・商談獲得・顧客満足・成長拡大といった目的別に、エージェントの成果を管理したりできると説明されています。

Agent Builderは、ノーコードのキャンバス上で、既存のワークフローやカスタムエージェント、起動条件（スケジュール・連絡先の更新・Webhook等）を組み合わせて新しいエージェントを作る機能です。

自然言語での設定を担うアシスタント経由で操作でき、商談履歴や連絡先情報、通話記録、購買シグナルといった共有データ基盤の上で動く設計になっている、とされています。

これらの機能が対応しようとしている課題について、HubSpotの最高製品・技術責任者（Chief Product and Technology Officer）であるDuncan Lennox氏の説明が紹介されています。

同氏によれば、難しいのは「単体のエージェントを管理すること」ではなく、「複数のエージェントを抱えた瞬間に、それぞれが顧客について別々の断片的な像を持ってしまうこと」にあるといいます。

HubSpotが挙げる典型例はこうです。

営業側の新規開拓エージェントが、ちょうど同じ週にサポート側の対応エージェントがそのアカウントの未解決クレームを処理している最中だとは知らないまま、その顧客へ営業連絡をしてしまう。

どちらのエージェントも自分の仕事は正しくこなしているのに、会社として見ると顧客に矛盾したメッセージを送っている状態です。

同社は、経営層がAIへの投資対効果を横断的に把握しづらくなる点も、この分断の副作用として挙げています。

共有データと競合回避のルールは別に設計する

HubSpotの提案は、単にエージェントを一つの画面へ並べるものではありません。

公式発表では、Agent Hubで状態と成果を把握し、Agent Builderでワークフロー、カスタムエージェント、トリガーを接続し、それらをHubSpotの共通データ基盤上で動かす構成が説明されています。

製品ページでは、信頼を築く間は各アクションを承認し、準備ができたら自律実行に切り替えられること、どのアクションを自律実行させるかを制御できることも案内されています。

したがって、HubSpotが可視化しか提供していないと捉えるのは正確ではありません。

一方、共通のCRMデータを参照できることと、複数のエージェントが競合せずに動くことも同じではありません。

例えば、サポートチケットが未解決である場合に営業連絡を止めるのか、どの重要度以上で止めるのか、チケットが閉じてから何日後に営業活動を再開するのかは、共通データが存在するだけでは決まりません。

製品は、そのルールをワークフローやトリガー、承認条件として実装するための手段を提供できます。

しかし、どの条件を採用し、例外時に誰へ引き継ぐかという業務方針は、利用企業が定義する必要があります。

今回確認した公開情報からは、HubSpotがこの種のエージェント間競合をどこまで自動的に判定・調停するのかまでは分かりません。

したがって本稿では、Agent Hubに機能がないと評価するのではなく、共通データ基盤の上に、どのような業務ルールを設定する必要があるかを考えます。

混ざりやすい四つの層を分ける

複数エージェントの運用を設計するとき、次の四つは似て見えますが、決めている内容が異なります。

可視化は、どのエージェントが稼働し、何を実行し、どのような結果を出したかを見ることです。

共通コンテキストは、各エージェントが同じ顧客記録、商談履歴、通話記録、購買シグナルなどを参照することです。

オーケストレーションは、複数のエージェントが同時に動こうとしたとき、どちらを優先し、どちらを停止・保留するかを決めることです。

権限と承認は、各エージェントが何を閲覧・更新・送信できるか、どの操作に人の承認を求めるかを決めることです。

一言でまとめると、可視化は「何が動いているか」、共通コンテキストは「何を見ているか」、オーケストレーションは「次に誰が動くか」、権限は「何をしてよいか」を決めます。

この四つを一つの言葉で語ると、実際には手つかずの層が残ったまま「対応済み」と扱われやすくなります。

単体のエージェントが必要な精度で動いていても、複数のエージェント間で顧客状態と優先順位が共有されていなければ、顧客接点全体では矛盾が起こり得ます。

「同じ顧客像」は三段階に分けて確かめる

顧客像を共有する、という表現はよく使われますが、実務では少なくとも三つの段階に分かれます。

第一に、同じ顧客を指しているかです。

同一人物・同一企業が、複数の連絡先や別レコードとして登録されていないか、という問題です。

第二に、現在の状態を同じように認識しているかです。

未解決の問い合わせがある、契約更新を検討中である、解約意向がある、営業担当者との商談が進行中である——こうした状態を、どのデータと条件で判定するかが揃っている必要があります。

第三に、その状態で許される行動が一致しているかです。

「未解決チケットがある場合は営業連絡を止める」といった、状態に応じた行動ルールが共有されているかどうかです。

ここで決めるべきなのは、顧客の今の状態を誰が正とするか、という漠然とした問いではありません。

顧客の現在状態を、どのレコードと条件から判定し、誰がその定義と更新に責任を持つかです。

どのデータを正本とするかと、誰が更新責任を持つかは、分けて決める必要があります。

共有することと、全部見せることは違う

ここでいう「共有」は、すべてのエージェントに顧客データを全面開放することではありません。

矛盾した行動を防ぐために必要な状態だけを共有し、詳細な会話内容や個人情報は、業務上必要なエージェントに限定する設計も考えられます。

例えば営業エージェントが知る必要があるのは、「重要度の高い未解決チケットが存在するため、営業連絡を保留する」という状態だけかもしれません。

サポート担当者と顧客の会話全文や、問題の細部まで営業エージェントに渡す必要があるとは限りません。

共通コンテキストと最小権限は、対立する考え方ではありません。

何を共通状態として共有し、どの詳細情報へのアクセスを制限するかを、目的ごとに分けて設計する必要があります。

実務でどこを決めるか（一例）

エージェントが複数になる前提で、あらかじめ決めておくと後の矛盾を減らせる論点を整理します。

以下は自社に置き換えて使うための叩き台であり、正解の設定を示すものではありません。

実際にどこまで細かく決めるか、どこに線を引くかは、業務の性質や規制、リスク許容度に応じて各社が判断することです。

設計する対象	確認する問い	主な実装先の例
顧客・企業の識別	同じ人物や企業が複数レコードに分かれていないか。どのレコードを正本とするか	CRMのデータモデル、重複統合ルール
顧客状態の定義	「対応中」「解約検討中」「商談中」を、どの項目と条件で判定するか	CRMプロパティ、チケット・商談ステータス
状態の更新と失効	誰が状態を更新し、いつ解除するか。古い状態が残り続けないか	更新ワークフロー、期限、再確認条件
処理の優先順位	営業、サポート、マーケティングのアクションが競合したとき、どれを優先するか	トリガー条件、抑止ルール、ワークフロー
権限と承認	各エージェントが何を読めるか、更新できるか。どの操作に承認が必要か	ツール権限、CRM権限、承認設定
例外と引き継ぎ	自動判定できない場合に誰へ渡し、誰が顧客へ説明するか	エスカレーション、担当者割当
記録と検証	どの状態を根拠に、どのエージェントが何を実行したか追跡できるか	実行履歴、監査ログ、評価指標

これらの項目には、製品設定だけで実装できる部分もあれば、社内の業務ルール、役割分担、データ管理方針と組み合わせる必要がある部分もあります。

どちらに属する項目なのかを分けないまま進めると、製品側の設定だけで完了したつもりになり、業務ルールの側が空白のまま残ることがあります。

導入の落とし穴——可視化とオーケストレーションを混同しない

一つの画面で全エージェントが見えるようになると、分断の問題そのものが解決したように感じやすくなります。

ここは注意が必要です。

可視化は状況を把握するための前提であって、どちらのエージェントを先に動かし、どちらを止めるかという判断そのものではありません。

両者を混同すると、エージェントの稼働状況は見えるようになっても、顧客への矛盾した接触が残る可能性があります。

もう一つの落とし穴は、「エージェントを増やすこと」自体を進捗の指標にしてしまうことです。

共通の状態定義や競合回避のルールがないまま、部門ごとにエージェントを追加すると、顧客接点の矛盾が増える可能性があります。

増やす前に、顧客状態をどう共有し、優先順位をどう決めるかを先に置いておく方が、結果的に手戻りが少なくなるというのが私たちの考えです。

なお本稿は、複数のAIエージェントが同じ顧客状態を参照し、矛盾なく動くための設計論点を扱うものです。

Agent Hub・Agent Builderの具体的な料金体系や、管理画面の個々の操作手順は対象としていません。

まとめ

HubSpotは、複数のAIエージェントが分散し、それぞれ異なる顧客像で動く問題を、Agent HubとAgent Builderが対応する課題として明確に挙げました。

単体エージェントの性能を高めることと、複数のエージェントが同じ顧客状態を参照し、矛盾なく動くことは、別の設計課題です。

Agent Hubは稼働状況や成果を一元的に確認する場所を提供し、Agent Builderは共通のHubSpotデータを使って、エージェント、ワークフロー、トリガー、アクションを接続する仕組みを提供します。

ただし、共通のデータ基盤があるだけで、営業とサポートのどちらを優先するかが自動的に決まるわけではありません。

顧客の現在状態をどのデータから判定するか、その状態を誰が更新し、いつ解除するか、処理が競合したときにどちらを止めるかを、業務ルールとして定義し、製品上の条件へ反映する必要があります。

また、状態を共有することと、すべての顧客データをすべてのエージェントに開放することも同じではありません。

複数のAIエージェントを導入する際には、少なくとも次の四点を分けて確認することが重要です。

• 何が動いているかを把握できるか
• 各エージェントがどの顧客情報と状態を参照するか
• 処理が競合したとき、どちらを優先するか
• 各エージェントに何を読み書き・実行させるか

エージェントの数を増やす計画と同時に、この状態共有と競合回避のルールを設計しておくことが、顧客接点の矛盾を減らす土台になります。

情報確認について

本記事は、HubSpot公式コーポレートニュース「Meet Agent Hub and Agent Builder: One place to build and manage AI agents with shared context」（2026年7月23日）を主要な参照元として、2026年8月確認時点の情報をもとに作成しています。

Agent HubとAgent Builderは、HubSpotの公式発表ではProfessional・Enterprise契約者向けの公開ベータとして案内されています。

アクションごとの承認や、どのアクションを自律実行させるかの制御については、HubSpotの製品ページも参照しています。

Agent HubはProfessional・Enterpriseプランに含まれますが、Agent Builderで作るカスタムエージェントの実行にはHubSpot Creditsが使用されるとされています。

HubSpotが挙げる「エージェントの分断」は同社による製品課題の整理です。

本稿における可視化・共通コンテキスト・オーケストレーション・権限の区分、および顧客状態の共有ルールに関する考察はMIFによるものです。

公開ベータの提供範囲、機能、利用条件、クレジット消費量は変更される可能性があります。

導入時にはHubSpotの公式情報で最新の条件をご確認ください。