HubSpot Service Hub 向け Meta Muse：2026年、MetaのAIはWhatsAppヘルプデスクにどう収まるのか

要点

「HubSpot Service Hub 向け Meta Muse」は、結局のところ1つの判断に行き着きます。WhatsApp番号上の唯一のAI枠を、Meta Business Agentと、HubSpot内で動くAIのどちらに与えるかです。Muse自体は消費者向けのエージェントで、Muse Sparkは自分で組み上げて使うモデルです。

Business AgentはHubSpotのWhatsAppチャネルと番号を共有できますが、最初の応答者になり、HubSpotは待機状態に回されます。Metaは1番号につきAIエージェントを1つしか認めないため、Business AgentとHubSpot自身のカスタマーエージェントは両方で応答できません。HubSpotはMetaが挙げる引き継ぎパートナーにも入っていません。そして独自ボットを考えているなら、先にこれを知っておいてください。HubSpotのConversations APIはWhatsAppメッセージを送信できません。

コスト面では、Metaのエージェントは1会話あたり約16〜50セントで、メッセージごとに増えていきます。HubSpotのカスタマーエージェントは解決1件につき0.50ドルですが、Service Hub Professionalに含まれる3,000クレジットでは月に60件分しか賄えません。私はeeselの連携を作っていますが、今年前半に月約10,000件のチケットを扱うHubSpotチームが、過去のチケットからまだ学習できないという理由でeeselを見送りました。今は学習できます。この件が、私のシンプルな結論の理由です。WhatsAppがHubSpotヘルプデスクの一つのチャネルなら、AIはHubSpotの中にあるべきです。eeselはまさにそれを行い、過去のHubSpotチケットから学び、まずそれらで自らをテストします。

「HubSpot Service Hub 向け Meta Muse」が実際に意味するもの

私は他社の開発者向けドキュメントを読むのに週の大半を費やしていますが、その中でも2026年のMetaの命名は最も整理に手間がかかります。ここには3つのMeta製品が関わっていて、実際に顧客と話すのはそのうち1つだけです。

1. Muse。Metaが9月に発表した、消費者の用事を片付けるためのパーソナルAIエージェントです。企業の顧客に対応するためには作られていません。
2. Muse Spark 1.3。Meta Model API経由で販売されるモデルです。その上にボットを構築できます。HubSpotにとっての意味は後ほど説明します。モデルの詳細はMuse Spark 1.3の概要にあります。
3. Meta Business Agent。Metaが6月に発表した、WhatsApp、Messenger、Instagramで顧客に応答するAIです。HubSpotのサポートチームが実際に検討しているのは、この製品です。

3製品の切り分けは、私のカスタマーサポート向け Meta Museガイドにあります。この記事ではHubSpot側、つまりMetaのエージェントが加わったときにWhatsAppチャネル、ヘルプデスクのチケット、クレジットがどうなるかに絞ります。別のヘルプデスクをお使いですか？Zendesk向け Meta Museの記事と、そのFront版・Gorgias版がそれぞれ扱っています。

HubSpot Service Hub で今のWhatsAppはどう動くか

Metaのエージェントが登場する前に、HubSpotのWhatsAppチャネルがすでに何をしているかを知っておくと役立ちます。Metaの埋め込みサインアップ（設定、WhatsApp、「Connect a WhatsApp phone number」）で番号を接続し、着信先を選びます。ヘルプデスクでは、HubSpotのヘルプデスクWhatsApp記事によれば、受信メッセージごとに「a new thread and ticket in help desk」が作成され、その上にチケット担当者とスキルベースのルーティングが乗ります。

HubSpot自身のドキュメントには、以降のすべてを左右するいくつかの詳細があります。

• Professional以上の機能です。 ヘルプデスク版にはService Hub ProfessionalまたはEnterpriseが必要です。受信トレイ版は、HubSpotの受信トレイWhatsApp記事によれば、Marketing Hub ProfessionalまたはEnterpriseでも使えます。番号は受信トレイかヘルプデスクのどちらかに置かれ、両方には置けません。
• HubSpotはWhatsAppを自社で課金します。 どのアカウントにも月1,000件のテンプレートメッセージが含まれ、製品カタログでは追加ブロックが1,000件ごとに月70ドルで販売されています。HubSpotは、製品チームのお知らせによれば、2025年7月1日に会話単位からメッセージ単位に切り替えました。
• HubSpotはすでに番号にAIを載せられます。 そのカスタマーエージェントのデプロイガイドには「You can assign it to Facebook, WhatsApp, calling (BETA), live chat, form, or email channels.」とあります。つまり、すでにAIがWhatsAppのスレッドに応答している可能性は十分あります。
• コエグジステンスでスマホアプリも使い続けられます。 HubSpotのコエグジステンス設定では、同じ番号をWhatsApp BusinessアプリとHubSpotの両方で動かし、180日分の履歴をインポートできます。ヘルプデスクではインポートされた会話の1件1件が新しいチケットになるので、最初の朝は忙しくなると思ってください。
• ルールベースのWhatsAppボットはありません。 HubSpotのボットビルダーが提供するのは、ウェブチャットとMessengerのチャットフローです。WhatsAppでは、カスタマーエージェントが自動化の手段になります。

スレッド化は、HubSpot管理者から最もよく質問される点です。WhatsAppでヘルプデスクを使うあるユーザーはこう書いています。

「WhatsApp + Help Desk: when a customer replies after I close a conversation, it reopens the same thread. I need it to create a new conversation instead. Is there a setting for this or any workaround?」

u/ordereds, Reddit

より広い機能については私のHubSpotレビューで一通り見ており、ヘルプデスクの詳細はHubSpotカスタマーサービスソフトの記事で扱っています。

番号はかなり「粘着質」でもあります。標準接続の場合、HubSpotの受信トレイガイドは、番号が「must not be connected to another WhatsApp account, WhatsApp for Business App, or another WhatsApp integration」と述べており、先に切断する以外に文書化された移行手順はありません。どのAIが枠を得るにせよ、意図して選ぶ価値があります。

Meta Business Agent が HubSpot の番号に加わるとどうなるか

Metaのドキュメントは9月にかなり詳しくなり、ヘルプデスクチームにとってその新しい詳細は状況を大きく変えます。

最初の応答者になり、HubSpotは待機に回る

MetaのConversation Routingは、1つの番号に複数のアプリが接続されているとき、どのアプリが各メッセージに応答するかを決めます。HubSpotのWhatsAppチャネルはそのアプリの1つとして数えられます。Business Agentをオンにすると、Metaのルーティング設定ガイドによれば、「The agent becomes the sole primary for messaging entry points」となり、「Previous primary destinations move to standby so they retain context」となります。

平たく言えば、新しいWhatsAppメッセージはHubSpotのヘルプデスクではなく、まずMetaのエージェントに届きます。つまり、スレッドが戻ってくるまでチケットは作成されません。エントリーポイントごとに分けることもできます。たとえば、ダイレクトメッセージではHubSpotを主にして、Click-to-WhatsApp広告はAIに任せる形です。この設定はMeta Business Suite内でのみ行え、Metaははっきり述べています。「There is no public API for configuring Conversation Routing.」

1番号につきAIは1つなので、カスタマーエージェントとBusiness Agentは共存できない

Metaのプラットフォーム概要は適格性のルールを明記しています。番号は「Not already running another AI agent on that number」でなければならず、それは「an active authorized-agent integration blocks Meta Business Agent」だからです。

Metaは「authorized-agent integration」が何を指すか定義していません。素直に読めば、そして私が計画の前提にするのも、その番号で応答しているHubSpotのカスタマーエージェントも該当するという解釈です。つまり、これは重ねるものではなく選ぶものです。カスタマーエージェントが今WhatsAppのスレッドを処理しているなら、Metaのエージェントを加えるには、まずその番号でカスタマーエージェントを一時停止することになります。HubSpotのデプロイ画面には、一時停止したエージェントは「keeps existing chats but won't get new ones.」とあります。

引き継ぎはスレッドを通って戻り、HubSpotは名指しのパートナーではない

Business Agentが引き継ぐとき、チャットはMetaの受信トレイに移りません。同じWhatsAppスレッドに残り、番号上の別のアプリに所有権が渡るだけです。Metaのカスタマーサポートガイドは前提条件として「A staffed destination for handed-off conversations」を挙げており、単純な引き継ぎは、スレッド制御のドキュメントによれば、「escalation partner」に設定したアプリに渡されます。

HubSpotチームにとってのescalation partnerは、HubSpot自身のWhatsAppアプリになります。番号上にいるプロバイダーがHubSpotだからです。MetaがBusiness AIを発表したとき（Business Agentの以前の名称）、引き継ぎパートナーとして「Salesforce, Microsoft Dynamics 365 Contact Center, ServiceNow, Zendesk, Gorgias and Klaviyo Service」を挙げました。HubSpotはそのリストにありません。HubSpotのWhatsApp、ヘルプデスク、カスタマーエージェントの記事のどれもBusiness Agentに言及していません。Metaのルーティング文書に従えば、HubSpotがescalation partnerである限り、引き継ぎは通常のスレッドとしてHubSpotに着地するはずです（ヘルプデスクでは新しいチケットです）。ただ、このフローはこれまでどちら側も文書化していないため、信頼する前に予備の番号でテストします。

知っておく価値のある引き継ぎの詳細をいくつか挙げます。

• コンテキストは2,000文字のメモで運ばれます。 引き継ぎイベントには自由記述のmetadataフィールドがあり、Metaは「to carry the ticket or order reference」に使うことを勧めています。チームが受け取るのは、チャットのAI要約か、ライブの待機コピーのどちらかで、両方同時にはありません。
• トリガーは制御できません。 プラットフォームでは、信頼度が低いとき、整合性の問題があるとき、顧客が人間を求めたときに引き継ぎが発動し、Metaの機能ページによれば「You do not configure the triggers」です。一方、HubSpot自身のカスタマーエージェントには、Pending、Awaiting Human Assignment、Handed offを追跡するチケットステータス付きの引き継ぎワークフローがあります。
• Metaは午前2時の引き継ぎについて警告しています。 自社ガイドにはこうあります。「An agent that hands off at 02:00 into an unstaffed queue produces a worse outcome than one that says when the team is next available and raises a ticket.」

プラットフォームへの早期アクセスを得たあるBSPコンサルタントは、コントロールをこう要約しました。

「The harness is very basic. You only get 4 controls - knowledge, personality, audience, handoff. Fine for a simple FAQ or catalog bot. But if you want real step-by-step logic, you hit the wall fast.」

u/Kira_SENPAI_1, Reddit

どのスタックでも良い引き継ぎとはどんなものかは、私のAIエージェントの引き継ぎガイドで扱っています。

HubSpotのプライベートアプリトークンはMetaのコネクタ認証に合うが、MCPサーバーは合わない

Business Agentは、自分で定義するHTTP APIやリモートMCPサーバーであるコネクタを通じてアクションを実行します。Metaのサポートガイドにはcreate_support_ticketツールの手順まで載っています。GorgiasとFreshdeskの記事ではここでつまずきました。それらのAPIはBasic認証を求め、Metaのコネクタリファレンスは「only OAUTH2_CLIENT_CREDENTIALS, API_KEY, and NONE are supported」としているからです。

HubSpotはここでは相性のよい側にいます。HubSpotのアプリアクセストークンは静的なBearerトークンで、MetaのAPI_KEYタイプならヘッダー名を指定し、Bearer プレフィックスを設定できます。したがって理屈の上では、Metaのエージェントは引き継ぎが行われる前に、HubSpotチケットの作成、連絡先の検索、プロパティの更新ができます。インストール済みアプリ向けのHubSpotのOAuthは認可コードで動き、そのクライアント認証情報グラントはアプリ設定の管理にしか使えないため、プライベートトークンが道として残ります。

比較のために言えば、HubSpot自身のカスタマーエージェントは、すでにアカウント内にあるため、コネクタの配管なしでこうしたアクションを利用できます。

HubSpotのリモートMCPサーバーは事情が異なります。PKCE付きのOAuthを必要とし、Metaのクライアント認証情報フローと合いません。しかも会話を読めても送れません。このサーバーにできることとできないことは、HubSpot向けClaudeの記事でさらに掘り下げています。

自作する場合の注意が2つあります。プライベートアプリ向けのHubSpotのレート制限は、FreeとStarterで10秒あたり100リクエスト、ProfessionalとEnterpriseで190で、1日の上限はアカウント内のすべてのアプリで共有されます。そしてMeta自身がサイレント失敗のリスクを指摘しています。「A failed ticket is invisible: the agent has already said a colleague will be in touch, the shopper waits, and nobody finds out until they message again angrier.」

料金：WhatsApp上のMeta Business AgentとHubSpotのカスタマーエージェント

2つのAIは課金単位が異なり、どちらも、すでに支払っているHubSpotのシートとWhatsApp枠の上に上乗せされます。

会話あたりで見ると、Metaが公表しているどの例でも、Metaのエージェントのほうが1回のHubSpot解決より安く収まります。ただ、調子の悪い日にはHubSpotのモデルのほうが公平です。引き継ぎで終わった会話は無料なのに対し、Metaは役に立ったかどうかにかかわらず全メッセージを課金するからです。初期のユーザーはメッセージ単位課金の点にすぐ気づきました。

「My concern is that the per-message cost is insanely high at approximately 5 cents per message.」

u/Aromatic-Surround167, Reddit

HubSpotのエージェントは、うまく設定されればよく使われるので、まさにそのために枠が重要になります。高ボリュームの国際サポートチームを率いるサポートディレクターはこう書きました。

「I am absolutely evangelical about customer agent. I direct a high volume international support team and overall, we love it. Our customer agent successfully resolved 47% of our inbound tickets last month and 97% of our inbound chats.」

u/Large_Customer_548, Reddit

同じコメントは、エージェントが自動応答と延々やり取りを続ける「robot wars」にも触れており、エージェントがスパムを振り分ける前に返信してしまい、その分を彼らのボリュームでは支払うことになる、とも指摘しています。

驚かれやすいHubSpotの数字は、料金ではなく枠のほうです。Service Hubの料金にはProfessionalで3,000クレジットが含まれ、これは月60件のカスタマーエージェント解決、つまり1日およそ2件で、そのクレジットはアカウント内の他のAI機能すべてと共有されます。使い切ると、HubSpotによれば、追加購入しない限り、リセットまで全チャネルで新しい会話の受け付けが止まります。HubSpotのクレジットガイドは繰り越しできないことを確認しています。その計算は、私のHubSpot Creditsの解説で扱っています。

10月1日はHubSpot側の未解決の問い

ほとんどのHubSpotチームが実際に感じる変化は、AIの価格ではありません。2026年10月1日から、Metaは電話番号ごと月1,000件の無料枠を超えたサービスメッセージをメッセージ単位で課金します。ここでのサービスメッセージとは、人または第三者AIによる自由形式の返信のことで、Metaの料金ページによれば、各メッセージは「either as a Meta Business Agent message or as a service message, never both」として課金されます。

HubSpotはこの請求の真ん中にいます。WhatsAppを自社で計測し、テンプレートメッセージを1,000件の枠に数えているからです。10月1日以降、自由形式の返信を吸収するのか、転嫁するのか、計測するのかは、HubSpotのWhatsApp、ヘルプデスク、カタログのどのページにもまだ書かれていません。チームがHubSpotから多くのWhatsApp返信を送っているなら、今週、アカウントマネージャーに尋ねる価値があります。料金の全履歴は私のWhatsApp API料金の解説に、Metaが第三者ボットに何をしたかはMetaのポリシー変更の記事にあります。

Muse Spark で自前のHubSpotボットを作る

3つ目の道は、Business Agentを飛ばしてモデル上に直接構築するものです。私の本業に最も近い道で、HubSpotについては計画全体を組み替える事実が1つあります。

モデル側では、Muse Spark 1.3は標準ティアで100万トークンあたり入力1.25ドル、出力4.25ドルで（Meta Model APIドキュメント）、ツール呼び出しと構造化出力が使えます。安価なコントリビューターティアはサポート業務では選べません。Metaの利用規約に「You must not submit sensitive, confidential, or personal information to the Discounted Services.」とあるからです。そしてサポートチケットは、名前、メールアドレス、注文番号だらけです。モデルの強みは、私のMuse Spark 1.3レビューで扱っています。

HubSpot側には、ここに落とし穴があります。HubSpotのConversations APIガイドには「sending WhatsApp messages via a connected WhatsApp business account is not supported using the conversations API.」とあります。つまりカスタムボットはHubSpotのWhatsAppスレッドを読めますが、返信はできません。回避策はHubSpotのカスタムチャネルAPIで、ServiceまたはSales Hub Professionalと、開発者プラットフォームのアプリが必要です。自分のサービスが独自のWhatsApp接続を持ち、汎用のカスタムチャネルとしてメッセージをHubSpotに押し込むので、24時間ウィンドウ、テンプレート、Metaの課金はすべて自分で運用することになります。

それ以外もすべて自分の担当です。

1. ナレッジ。 ヘルプセンター記事、スニペット、過去のチケットを同期し続けること。
2. チケットのループ。 スレッドを読み、返信や社内コメントを下書きし、チケットのプロパティを設定すること。HubSpotには送信専用のスコープがないため、各API呼び出しのMESSAGEとCOMMENTのフィールドが、下書きと顧客に見える返信を分ける唯一の線です。
3. Webhook。 HubSpotのconversation.newMessageはIDのみを送り、Webhookガイドによれば5秒のタイムアウトで再試行します。モデル呼び出しとは相性が悪いため、すばやく受領を返し、処理は非同期で行います。
4. エスカレーション。 自前の信頼度しきい値とルーティングルール。
5. テスト。 何かが顧客に届く前に、実際のチケットを再生すること。

この道を検討するすべてのチームへの私の助言は、構築だけでなく保守も数えることです。全項目のリストは私の自作か購入かガイドにあります。別のモデルで同じことをするなら、HubSpot向けChatGPTを参照してください。HubSpot向けGrokの記事ではxAI版を扱っています。

HubSpotチームにとってMetaのエージェントが止まる場所

どれも隠されてはおらず、すべてMeta自身のドキュメントにありますが、CRMを土台にしたヘルプデスクで働くチームには、より重くのしかかります。

• Metaのアプリの中でしか応答しません。 HubSpotヘルプデスクはメール、ライブチャット、フォーム、多くの場合は通話も扱います。Business Agentはそのどれもカバーしないため、2つのAIと2組のルールを運用することになります。ウェブサイト側は、私のHubSpotチャットボットの記事で扱っています。
• チケット履歴はナレッジソースになりません。 Metaのサポートガイドは「export the top drivers from your helpdesk for the last quarter」してFAQエントリーを手で書くよう指示しています。何年分もの解決済みHubSpotチケットに眠る最良の回答には手が届きません。HubSpot自身のエージェントは、自分で追加するコンテンツソース、たとえばナレッジベース、ウェブサイトのURL、ファイルから回答しますが、過去のチケットはそのリストにもありません。
• 配線しない限りCRMは見えません。 HubSpotのカスタマーエージェントは、話している相手の連絡先をすでに知っています。Metaのエージェントが知っているのは、自分で作ったコネクタが取ってくる内容だけです。
• 規制業界は除外されます。 Metaのプラットフォーム概要によれば、金融や医療、また政府、アルコール、ギャンブルの企業は利用できません。
• 精度には依然として根拠づけが必要です。 Metaのヘルプセンターは「Some AI messages may be inaccurate or inappropriate」と警告しており、初期のテスターは「the same product come back at two different prices in two replies」を目にしています（Reddit）。

チケット履歴の話は、eeselのほぼすべての営業通話で出ます。eeselの創業者の一人である同僚のAmoghは、そのうちの1件のあとではっきりとこう言いました。

「Also - past ticket training strikes again. Classic. People really, really, really want to train on past tickets.」

Business Agentでは、その履歴をFAQとして手で書き戻すことになります。多くのHubSpotチームにとって、この一点が決め手になります。

あなたのHubSpotチームに合う構成

顧客がどこから連絡してくるか、チームがどう働いているかに基づいて、私ならこう選びます。

私が話すほとんどのHubSpotチームにとって、2行目が現実の答えです。顧客はWhatsAppで書き、メールでフォローアップし、後でCSAT調査に答えます。チームにはそのすべてが、HubSpotとMetaに分かれるのではなく、1つのHubSpotチケットと1つの連絡先レコードにまとまっている必要があります。だからこそ、Metaの問いよりもHubSpot内のAI選びのほうが重要なのです。

r/SaaSのあるコメント投稿者は、Metaが基本的な自動化を無料で配るとき、価値がどこに移るかについて同じことを述べました。

「When Meta ships the basic automation for free, SaaS value has to move up the workflow. The durable layer is cross-channel context, approval and exception handling, reporting tied to campaigns, and knowing when automation should stop and a human should take over.」

u/ayecl, Reddit

HubSpot内で選択肢を比較するなら、私のService Hub向けAI比較とBreezeカスタマーエージェントの代替のリストが次に読むのに適しています。ツールをまたぐWhatsAppについては、WhatsAppサポート向けベストAIを参照してください。

HubSpotのWhatsAppでeeselを試す

eeselは、新入社員のようにHubSpotに参加するAIヘルプデスクのチームメイトで、別ウィジェットも2つ目の受信トレイも必要ありません。HubSpotチケットを読み、返信を下書きして送り、社内メモを追加し、チケットのプロパティを更新し、パイプラインを通してチケットを動かします。その際、ライブのCRM連絡先データを使います。過去のHubSpotチケットに加え、ナレッジベース記事とスニペットからも学び、WhatsAppにも直接接続します。顧客にたった1件返信する前に、過去のチケットに対するシミュレーションを実行するので、どれを正しく処理できるかが見え、そのうえで触れてよいチケットの種類を選べます。

料金は月額固定のクレジットプランで、チケットまたはチャット1件は、返信が何回になっても1クレジットです。ボリュームに合ったプランサイズを選べます。セットアップをスクリプト化したいなら、eesel CLIを使って、あなた、またはClaude Codeのようなコーディングエージェントが、ターミナルからHubSpotの接続、ナレッジの追加、アクションの承認を行えます。すべてのコマンドがJSON出力に対応しています。

100クレジット付きでカード不要のeeselを無料で試し、10月1日の料金変更が始まる前に、HubSpotのWhatsAppチケットをどう処理するか確かめてください。