HubSpotで問い合わせ対応をAI化するときは、利用者が自分で読むナレッジベースと、資料を基に回答するCustomer Agentを分けて準備します。ナレッジベース機能はありますが、契約・席・権限の条件があります。また、記事を用意したことだけで、Customer Agentの参照元や人への引き継ぎまで設定済みにはなりません。
この記事は公式ヘルプに基づく設定・確認手順です。実アカウントでの作成、同期、回答、引き継ぎは検証していません。質問と資料の例は架空です。料金総額や個別契約の適用可否は扱いません。
目次
ナレッジベースとCustomer Agentの条件を別に確認する
公式のナレッジベース記事作成案内は、Service Hub ProfessionalまたはEnterprise、割り当て済みのService Hub席、Service Access内のKnowledge base articles権限を条件としています。移行済みナレッジベース向けの手順であり、未移行の旧版には別案内があります。
作成の入口は Service > Knowledge Base > Create article です。記事の本文に加え、Settingsで分類や閲覧範囲を決めます。Public、アクセスグループへの登録、SSOによる閲覧という選択肢を、使うドメインや設定条件と合わせて確認します。HubSpot：ナレッジベース記事の作成（新しいタブで開く）
一方、Customer Agentの作成・編集にはCustomer agent editor権限と割り当て済みの席が必要です。対象Hub等のProfessional・Enterprise条件、チャネルへ展開する際のHubSpot Creditsも別に確認します。「ナレッジベースを持てるからAgentも無条件に使える」「AgentがあるからService Hubの全機能が含まれる」とは判断しません。
公式は、Customer AgentのプレビューとテストはCreditsを消費しないと説明しています。ただし、公開チャネルでの利用や個別の契約費用まで無料という意味ではありません。作成したAgentは編集や一時停止はできますが削除できないという注意もあるため、既存Agentの有無と作成する対象を確認します。HubSpot：Customer Agentの設定（新しいタブで開く）
回答に使ってよい資料だけを選ぶ
対象は、公開してよい操作案内など、答えが明確なものから始めます。社内担当者向けの補足や顧客別条件を、同じ資料の末尾へ混ぜないようにします。
特に重要なのは、元記事の非公開設定とAgentの回答範囲の違いです。公式は、追加したソースは公開・非公開のどちらも回答作成に使われ、非公開ソースは引用されなくても内容が回答へ現れ得ると注意しています。引用リンクが出ないことは、内容が使われていない証拠ではありません。HubSpot：Customer Agentのナレッジソース管理（新しいタブで開く）
次は資料選定の架空例です。
表は横にスクロールできます
| 資料 | 内容 | Agentへの追加判断 |
|---|---|---|
| 公開済みのログイン手順 | 利用者共通の操作案内 | 最新版と対象製品を確認して候補にする |
| 社内の例外対応メモ | 個別判断や担当者向け情報 | 非公開だから安全と考えて追加しない |
| 顧客別の契約一覧 | 個別条件や顧客情報 | 汎用回答用の資料へ混ぜない |
| 旧版の操作ガイド | 廃止された画面の案内 | 現行案内との競合を整理する |
この表は社内の情報管理判断を代行するものではありません。Agentから外部へ伝えてよい情報かを、資料の所有者が確認します。公開案内と内部メモを一つのファイルにしているなら、必要な内容を分けるところから始めてください。
Train > Knowledgeでソースを指定する
Customer Agentの Train > Knowledge > Add content を開きます。既存のHubSpot記事を使う場合は From HubSpot で対象を選び、保存する手順です。記事がアカウント内にあるだけで、今回のAgentへ選択済みとは扱いません。
外部サイトなら Import from public URLs を使います。関連URLの取り込みを有効にする場合、ドメイン全体、指定パス配下、指定サブドメインという範囲の違いと、パスの包含・除外を確認します。サポートページだけ欲しいのに、採用情報や古いキャンペーンまで対象にしないよう、一覧を見直します。
更新について、公式は同期済みのナレッジベース記事の変更は自動再同期、他ソースは週次の自動再同期と説明しています。必要なら対象一覧の Refresh で再同期します。使わせない資料は Remove as source の対象です。引用表示を無効にする操作は、ソースを外す操作とは区別してください。
更新担当者が残すメモは「資料名／Agentへ選択した対象／公開してよい範囲／元資料の更新／同期確認／回答確認」です。更新直後の正しさや反映時間を、一覧に載っていることだけで保証しません。
人へ渡す条件と、渡し方を別に設定する
Train > Human handoff では、引き継ぐ条件と処理を確認します。公式の既定の例は、答えられない、人と話したいと利用者が求める、Agentが一時停止されている場合です。必要に応じて独自のHandoff guidelinesを追加します。
さらに Edit handoff process で、すぐ人へ渡すLive handoff、後で担当者が対応するAsync handoff、Agentが継続するDon't handoffを区別します。「人へ渡す条件を書いた」だけで、即時に担当者へ接続されるとは考えません。
ルーティング編集には追加の権限条件があり、割当先の対象者にも席の条件があります。担当者が選べないときは、名前を別欄へ書くだけで補わず、管理者が適用条件を確認します。HubSpot：Human handoffの設定（新しいタブで開く）
受付状態にも注意します。公式は、割り当てでユーザーの空き状況を参照し、チャットウィジェットの空き状況は参照しないと説明しています。また Team only を選ぶとユーザーの空き状況を考慮せず、受付可能な人がいなくてもhandoffが実行されるという注意があります。利用者への「今すぐ対応できます」という文言を、チームを選べたことだけから確約しないでください。
Testで根拠と引き継ぎを読み分ける
設定後は本番チャネルへつなぐ前に Test [agent name] を開き、EmailまたはLive Chatの対象を確認します。質問への答えだけでなく、拡大表示の Testing Insights で応答理由、起動したトリガー、引用したソースを調べる手順が案内されています。
確認に使う質問と期待条件を、先に人が決めます。次は試験計画の架空例で、実際の合否は記録していません。
表は横にスクロールできます
| 質問 | 先に決める期待条件 | 確認するもの |
|---|---|---|
| ログイン手順を教えて | 現行製品の案内に沿う | 回答と参照ソース |
| 古い手順の画面が見つからない | 旧手順を現行として繰り返さない | 対象製品・更新版の区別 |
| 担当者と話したい | 定めたhandoff方針へ進む | トリガーと引き継ぎ先 |
| 自分だけの特別条件を教えて | 汎用資料から個別条件を推測しない | 回答境界と引き継ぎ |
テストのために実顧客の秘密情報や顧客別ファイルを新たに追加しません。まず許可された合成データで確認し、回答の問題が資料、選択範囲、更新、引き継ぎ方針のどこにあるかを記録します。
テスト画面で良い文が返ったことと、実チャネルで正しい担当へ届くことは別です。担当者側で受け取れる会話情報、受付不可時の案内、対応開始後の責任分担も、公開判断の前に確認します。
運用を広げる前に、残る未確認を整理する
確認結果は、正答件数だけにまとめず、資料の範囲、同期、回答の根拠、引き継ぎ、利用条件で分けます。たとえば回答内容は正しくても、非公開の内部メモを参照していたなら、そのまま対象を広げる理由にはできません。
修正後は同じ質問を確認し、古い案内や意図しない情報が残っていないかを見直します。公開チャネルへの展開、利用量やCredits、設定変更を誰が判断するかも決めます。AIの応答が整うことと、サポート業務として継続できることを分けて進めてください。
確認した公式情報
資料確認日：2026年10月21日。利用条件、席、権限、同期やhandoffの動作は、現在の契約と利用画面に照らして確認してください。