サポート部門の自動化には、他部門にはない固有のリスクがあります。営業のアウトリーチで文面がいまひとつでも失われるのは機会損失ですが、サポートで誤った回答をすれば既存顧客の信頼を直接損ないます。「たらい回しにされた」という体験は、契約更新の判断にまで影響します。

本記事では、HubSpotのAgent Hubをカスタマーサポート業務に適用する際の、一次対応と有人対応の切り分け設計を具体的に示します。

サポート業務のどこを自動化すべきか？

問い合わせを4象限で分類する

自動化の適否は「定型度」と「感情負荷」の2軸で判断できます。

着手すべきは①です。ここで自動解決率と顧客満足度の両方が担保できることを確認してから、③へ段階的に広げます。②と④は、当面有人のまま残す判断が妥当です。

「自動解決率」を目標にしてはいけない理由

自動解決率を単独のKPIに据えると、有人へのハンドオフを絞る方向にインセンティブが働きます。その結果、AIが答えられない質問に無理に答え続け、顧客が「話が通じない」と感じる状態を招きます。

設計すべき指標は、自動解決率と顧客満足度、そしてハンドオフ後の解決時間の3点セットです。適切に有人へ渡された会話が短時間で解決していれば、切り分けは機能しています。

顧客対応エージェントは何を根拠に回答するのか？

顧客対応エージェントは自社が提供した承認済みコンテンツのみを根拠に回答し、出典を明示します。取り込める形式にはPDF、会議のトランスクリプト、企業ドキュメントが含まれます。

ナレッジソースの指定方法

以下の2系統が指定できるとされています。

• 既存のHubSpotコンテンツ：ナレッジベース記事など
• 公開URL：最大5,000件を自動クロール。スコープは全ページ／特定パス／単一サブドメインから選択でき、含める・除外するパスをフィルタリング可能

ナレッジソース管理で最も多い失敗

実務で頻発するのは、廃止済みコンテンツの混入です。旧価格表、サポート終了した製品バージョンのマニュアル、統合前の会社名を使ったページ。これらがクロール対象に入っていると、エージェントは正確にその古い情報を引用します。

対策は2段階です。第一に、クロール前にサイトマップを棚卸しし、除外パスを明示的に指定する。第二に、ナレッジソースの棚卸しを四半期ごとの定例作業としてカレンダーに入れる。エージェントは作った瞬間から劣化を始めるため、更新責任者を1人決めておく必要があります。

一次対応と有人対応の切り分けはどう設計するか？

エージェント自身の判断機能と、明示的な条件定義

公式プロダクトページには、「会話が人の対応を必要とするタイミングをエージェント自身が認識し、自動で転送する」機能が記載されています。しかしこれに任せきりにするのは危険です。自社にとって致命的な会話は、明示的な条件として定義すべきです。

無条件で有人に回すべき5条件

最後の2条件は、CRMを基盤に持つHubSpotの構造的な強みです。顧客対応エージェントはCRMデータへのアクセスと更新を許可できるため、「契約金額が一定以上の顧客は自動対応せず有人へ」という運用が実装可能です。

ハンドオフ時にコンテキストを引き継ぐ

切り分け設計で最も見落とされるのが、引き継ぎの品質です。顧客が「たらい回しにされた」と感じる最大の原因は、有人担当者が会話の経緯を把握しておらず、同じ説明を求めることです。

ハンドオフの際には、①顧客が何を尋ねたか ②エージェントが何を回答したか ③どの情報源を引用したか ④なぜ転送されたか の4点が有人担当者に見える状態を作る必要があります。設定段階のテスト環境では、右側パネルで応答理由・トリガー・引用ソースを検証できるため、この情報が引き継ぎ画面で確認できるかを事前に確認してください。

エージェントに何を実行させるか？

回答するだけのエージェントは「FAQの読み上げ」に留まります。公式ナレッジベースでは、設定項目として「アクション（パスワードリセット等）」が挙げられています。実際に問題を解決できるかどうかは、このアクション設計で決まります。

アクション権限の段階的な開放

1. 第1段階：読み取りと回答のみ——CRMデータの参照と、ナレッジソースに基づく回答生成に限定
2. 第2段階：低リスクな操作を追加——パスワードリセット、資料送付、ミーティング設定など、誤操作の影響が小さいもの
3. 第3段階：CRM更新を許可——チケットのステータス変更、プロパティ更新。出力の妥当性が検証できてから

いきなり第3段階から始めると、誤った判断がCRMに書き込まれ、その誤りが他のエージェントやレポートに波及します。HubSpotのMCPサーバーのドキュメントでも、LLMは誤った出力を生成し得るため、アカウントを変更する権限の利用時には常に確認が必要である旨が明記されています。

導入前に何を確認すべきか？

「解決」の定義とコスト試算

公式プロダクトページでは、解決を「エージェントが対応し、72時間以内に有人対応へ転送されなかった場合、またはリードとして適格化された場合」と定義しています。つまり有人へ渡された会話には課金されません。

月間1,000件の問い合わせがあり、想定自動解決率が60%であれば、600件×50クレジット＝30,000クレジット（約300ドル相当）が目安になります。詳細レートはHubSpot製品・サービスカタログで確認してください。

公開されている成果はどうなっているか？

以下はHubSpotが公開している顧客事例の数値です（出典：公式プロダクトページ、2026年8月12日取得時点）。

Nutribeesの事例が示すのは、サポート自動化が単なるコスト削減策ではないという点です。顧客対応エージェントにはリードの適格化とミーティング設定の機能もあるため、サポート接点が収益機会に転換し得ます。

ただしこれらは各社の運用条件下での結果です。問い合わせの定型度、ナレッジベースの充実度、製品の複雑さによって自動解決率は大きく変動します。

テストと段階展開はどう進めるか？

想定質問リストで検証する

公式ドキュメントによれば、テスト環境ではクレジットを消費せずに動作確認ができ、右側パネルで応答理由・トリガー・引用ソースを検証できます。

実務では、過去3ヶ月のチケットから頻出質問を30〜50件抽出し、1件ずつテストして以下を確認します。

• 回答内容が事実として正しいか
• 引用している情報源が最新のものか
• 有人に回すべき質問が適切に転送されるか
• トーンが自社のサポート文面と整合しているか

段階展開の順序

1. 限定チャネルから：まずライブチャットのみ、あるいはメールのみで開始
2. 限定時間帯から：営業時間外のみ稼働させ、翌営業日に有人がレビュー
3. 限定カテゴリから：特定製品・特定質問カテゴリに絞る
4. 全面展開：上記で品質が確認できてから

営業時間外からの開始は、リスクが最も小さい入口です。従来は翌営業日まで放置されていた問い合わせが対象になるため、品質が完璧でなくても顧客体験は改善方向に働きます。

メリットとデメリットを公正に評価すると？

よくある質問（FAQ）

カスタマーサポートでAgent Hubを使うと何ができますか？

顧客対応エージェントが、メール・ライブチャットなどのチャネルを通じて一次対応を担います。自社の承認済みコンテンツのみを根拠に回答し出典を明示、人の対応が必要な会話は有人へ転送します。あわせてリードの適格化とミーティング設定も可能です。

一次対応と有人対応の境界はどう決めればよいですか？

「定型度」と「感情負荷」の2軸で問い合わせを分類し、定型度が高く感情負荷が低いものから自動化します。加えて解約・返金・クレーム・重要顧客・根拠のない質問は、無条件で有人へ回す条件として明示的に定義してください。

自動解決率はどのくらいを目指すべきですか？

自動解決率を単独の目標にすることは推奨しません。無理に答え続けて顧客体験を損なう方向にインセンティブが働くためです。自動解決率・顧客満足度・ハンドオフ後の解決時間の3点セットで評価してください。公開事例では70〜91%が報告されていますが、これは各社の条件下の結果です。

誤った回答をしてしまうリスクはどう抑えますか？

ナレッジソースから廃止済みコンテンツを除外すること、テスト環境で想定質問30〜50件の引用ソースを1件ずつ検証すること、根拠のない質問には推測させず有人へ回す方針をガイドラインに明記すること。この3点が基本です。

料金体系を教えてください。

解決済み会話1件あたり50クレジット（約0.50ドル、1クレジット＝約0.01ドル）の成果報酬型です。「解決」はエージェントが対応して72時間以内に有人へ転送されなかった場合、またはリードとして適格化された場合を指し、すぐ有人に渡された会話には課金されません。

既存のチャットボットは廃止する必要がありますか？

いいえ。ルールベースのチャットボットは対応チャネルとして併存できます。定型的な分岐で完結する導線はルールベースのまま残し、自由記述の質問を顧客対応エージェントに回すハイブリッド構成が現実的です。

サポート担当者の人員はどうなりますか？

公開事例ではサポート人員の削減が報告されている一方、担当者が高難度案件に集中できるようになったという文脈でも語られています。重要なのは、残る業務の難度が上がるため、担当者のスキル要件と評価基準を見直す必要がある点です。人員計画は自社の問い合わせ構成を分析してから判断すべきです。

ハンドオフされた際、顧客に同じ説明をさせないためには？

有人担当者に、顧客の質問内容・エージェントの回答・引用した情報源・転送理由の4点が引き継がれる状態を作ってください。テスト環境の右側パネルでは応答理由・トリガー・引用ソースを確認できるため、これらが実際の引き継ぎ画面で見えるかを事前に検証してください。

日本語での運用は問題ありませんか？

HubSpotは日本語版の公式ナレッジベースを提供しており、日本語環境での設定が想定されています。ただし回答品質は自社のナレッジソースの言語構成に依存します。日本語コンテンツが薄い状態では日本語の回答品質も上がらないため、まず日本語ナレッジベースの整備状況を確認してください。

まとめ：自動化の質は、有人に戻す設計で決まる

カスタマーサポートの自動化は、AIがどれだけ答えられるかではなく、答えるべきでない会話をどれだけ正確に人へ戻せるかで評価されます。承認済みコンテンツのみを根拠にする設計、出典の明示、72時間ルールに基づく成果課金——HubSpotの設計はいずれも「答えられない時に無理をしない」方向を向いています。

その設計思想を活かせるかどうかは、自社がハンドオフ条件をどれだけ具体的に定義できるかにかかっています。

株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして、400社以上のCRM導入を支援してきました。過去チケットの分類から切り分け設計、稼働後のチューニングまで伴走します。

あわせて読みたい関連記事

• 顧客対応エージェント（Customer Agent）の設定方法と活用シーン
• Agent Hub導入で失敗する組織の共通点｜CRMデータ品質と運用ルール設計
• Agent Builderの使い方｜自然言語でカスタムAIエージェントを作る手順

本記事はHubSpot公式サイト・公式ナレッジベース（日本語版・英語版）の公開情報（2026年8月12日取得時点）に基づいて作成しています。掲載した成果数値はHubSpotが公開する各社事例であり、自社での再現を保証するものではありません。仕様・エディション要件・クレジットレートは変更される可能性があります。