HubSpot Service Hub向けGrok Bot：2026年時点でできること・できないこと

なぜ「HubSpot Service Hub向けGrok Bot」が検索されるのか

xAIが2026年8月11日にGrok Botをローンチしたとき、プロダクトページにはエージェントの能力を示す一握りのサンプルプロンプトが掲載されていました。そのうちの一つは、ヘルプデスクを直接名指ししています。「Sign in to Zendesk so I can work the support queue.」ですから、Grokをサポートデスクに向けるという発想はインターネットが考え出したものではなく、xAI自身の売り文句であり、その仕組みにZendesk固有の要素は何もありません。Grokがブラウザベースのヘルプデスクをひとつコントロールできるのであれば、Service Hubも同じように操作できます。

この質問をするチームの多くはすでに評価の真っ只中にあり、HubSpotをZendeskとの比較やFreshdeskとの比較と天秤にかけています。つまりAIレイヤーは、まさにそのショートリストにおける最新の決め手にすぎないのです。

私は本業でインテグレーションを構築しており、「これはただ動く」というタイプのエージェントに対する最初の本能は、ほころびを探しに行くことです。そして正直な結論を先に伝えます。「エージェントがデモで会話をクリック操作できる」ことと「見知らぬ顧客の請求に関する質問に無人で答えても信頼できるエージェント」であることの間には、途方もない隔たりがあります。私はここ数年、実運用のサポートキューにAIを導入する仕事をしてきましたが、自信満々に聞こえるボットが静かに誤った回答を送るのを何度も見てきました。だからこそ、私は今、たった一人の顧客に触れる前に、チームの実際の過去のチケットに対してすべてのロールアウトをリハーサルするようにしています。だから、真新しいエージェントが「私の受信箱を処理します」と言ってきたとき、最初の疑問は「クリックできるか」ではありません。「午前2時に自信満々で間違えたとき、何が起きるのか」です。

これが本稿全体を貫く視点です。Grok Botは本当に興味深い汎用ワーカーです。それをService Hubに向けたらどうなるか、何が得意で、サポート特有のどこにほころびが出るのかを見ていきましょう。

GrokをHubSpot Service Hubに接続する2つの方法

Grok と HubSpot の公式インテグレーションは存在せず、HubSpotインテグレーションディレクトリへの掲載もなく、切り替えボタンもありません。つまり「HubSpot Service Hub向けGrok Bot」は実質的に2つのセットアップのどちらかを意味し、両者はまったく異なる振る舞いをします。

ルート1:Grok Botがあなたのservice Hubの席を操作する

これはxAIのサンプルプロンプトが説明しているルートです。Grok Botは管理されたクラウドコンピューター上で動作し、ブラウザを開き、あなたがHubSpotにログインするよう指示します。それ以降は、人間の担当者と同じように共有受信箱を処理します。会話を読み、返信を下書きし、ボタンをクリックします。

魅力的な点は、エンジニアリングがまったく不要なことです。APIを配線する必要はなく、単に平易な言葉で仕事を説明すれば、GrokがUIを操作します。落とし穴は、それがBreeze Customer AgentのようにHubSpot内部の一級のAIエージェントとして参加するのではなく、外部からあなたのService Hubの席をリモート操作しているにすぎないということです。すべてのアクションは画面操作であり、確信度、エスカレーション、会話レベルのガードレールといったネイティブな概念は存在せず、あなたがボットに書いたテキスト指示があるだけです。

ルート2:Grok APIと自前のグルーコード

より制御しやすいルートは、Grok Botを完全に飛ばしてGrok 4.6モデルAPIを使うものです。HubSpotのWebhookまたはワークフローを設定し、会話が届いたときに自前のコードがモデルを呼び出し、提案された返信を受け取り、それをHubSpotのConversations APIを通じて書き戻します。

これにより本当の意味での制御が得られます。モデルにどのコンテキストを見せるか、何を許可するか、どこで人間が介入するかを自分で決められます。ゼロから構築したくない場合、HubSpotはチャットボット連携ガイドにネイティブな経路を文書化していますが、それはGrokではなくBreezeに戻ってしまいます。自前構築ルートの代償は、今や小さな社内プロダクトを保守することになる点です。誰かがリトリーバルを構築し、プロンプトを書き、エラーを処理し、エスカレーションロジックを担当し、HubSpotのAPIレート制限の中でそれを動かし続けなければなりません。始める前に知っておく価値があるのは、HubSpot自身のMCPやコネクタの経路は会話を読み取り専用のままにしているため、このルートは実際に返信を送信するために生のConversations APIに頼ることになり、一括書き込みは一度に10件のレコードに制限されるということです。これは典型的な「作るか買うか」の分岐点であり、ほとんどのサポートチームでは「作る」側が静かに恒久的な副業プロジェクトへと変わっていきます。

どちらの道を選んでも、外部の頭脳をService Hubにボルトで取り付けることになります。会話を要約するスクリプトであればそれで構いません。しかし、それが顧客と話す存在になると、話は別の基準になります。

Grok Botが本当に得意なこと

批判する前に、公平でありたいと思います。Grok Botはある種の仕事にとって本物の前進だからです。

それぞれのボットは自身のルーチン、コンテキスト、ドメインを持ち、ボット同士が仕事を引き継ぎ合うことができます。1か月間これを使い続けていたあるHacker Newsのコメント投稿者は、その魅力をうまく言い表しています。

"Biggest advantage is each one owns its own routines, context, and domain, and they can communicate between each other... each one has their own computer, which means async work feels like it actually works. I haven't had to juggle worktrees for the last month."

jjcm, Hacker News

オープンエンドで自律的なプロジェクト、サプライヤーのソーシング、リサーチの実行、複数システムをまたいだ経費の追跡といった用途では、この常時稼働でコンピューターを操作するモデルは正真正銘強力です。xAIが標準で提供する8つの役割(Sales Outbound、Talent Scout、Paid Media、Expense Manager、Product Performance、Bug Reproduction、Account Health、Chief of Staff)は、その本質がどこにあるかを物語っています。すなわち、幅広く自律的な、個人貢献者向けのナレッジワークです。

これはまた、サポート用途にとっての最初の警告サインでもあります。それら8つの役割のうち、サポートエージェントは一つもありません。「サポートキューを処理する」ことを例として提案するこのツールが、サポート向けのボットをひとつも提供していないというこの不一致は、テンプレートが欠けているという以上に根深いものです。HubSpotのチャットボットやネイティブのBreezeエージェントは、少なくとも顧客に応答しているという前提から出発します。一方Grok Botは、自分があなた自身であり、一人で作業しているという前提から出発するのです。

Service Hubの受信箱にとって危険が高まる部分

サポートには、オープンエンドなナレッジワークにはない要件があります。顧客の個人情報に触れること、無人のまま大量に稼働すること、そして間違った回答は再実行できるものではなく、顧客に見える形のインシデントになることです。これはまさに、Service Hub AIが価値に見合うかという問いが、生の能力ではなく常にガバナンスの話に戻ってくる理由でもあります。Grok Botの設計に関する3つの点がこれと衝突します。

1台の共有コンピューター、1つの使い回されるログイン

これが大きな問題です。あるユーザーのすべてのボットは単一のクラウドコンピューターを共有します。ボットはあなたのHubSpotパスワードを保持することは決してなく、代わりに画面をあなたに渡し、あなたが認証情報を入力すると、そのセッションはその共有コンピューター上に持続し、他のあらゆるボットがそれを再利用できます。xAI自身のドキュメントは2回、こう述べています。「Do not use separate Bots as a security boundary.」ボットを削除しても、そのファイルとログインは残ります。

個人的な生産性向上のセットアップであれば、これは肩をすくめる程度の話です。しかし、CRM全体と顧客との会話をまるごと保持しているHubSpotアカウントにとっては、あなたが本来望むはずの境界線、すなわち「このボットはサポートしか見られず、あちらのボットはそれに触れられない」というものが、製品によって強制される仕組みではないことを意味します。それはまた、あなたがHubSpot内部で慎重に設定した細かなユーザー権限にも逆行します。あるコメント投稿者は、この説明責任の問題を鋭く言い表しました。

"By hijacking a real person's credentials, that person becomes the accountability sink. Very neat. Very deliberate."

ares623, Hacker News

ボットはログイン済みの人間のセッションを通じて動作するため、HubSpot内でボットが取るすべてのアクションは、そのログインを行った人物に帰属します。それはサポートリーダーとしては気まずい立場であり、特にタイムラインが重要になるCRMのような記録システムの内部ではなおさらです。

ドライランが存在しない

サポートAIを展開する際に最も重要なただ一つの習慣は、実際に稼働させる前に自分自身の履歴に対してテストすることです。Grok Botはそれを提供していません。そのドキュメントは明確にこう述べています。「A test run performs real work. It can navigate websites, change files, and call connected tools.」つまり、サンドボックスも読み取り専用のリハーサルもなく、「先月の会話にどう返信していたか見せて」ということもできません。それが初めてあなたの受信箱を処理するとき、それはあなたの本物の受信箱を処理しているのです。

承認機能は多少役に立ちますが、それはユーザーが書いた自由記述のテキストであり、製品側が強制する許可されたアクションのリストではありません。そして何かを承認することは、それを取り消せることと同じではありません。「An approval controls the proposed action. It does not reverse work already completed.」ボットがすでに返信を送信済みであれば、承認フローはそれを呼び戻すことができません。それは、誤送信が下書きではなく顧客へのメールになってしまうチャネルにとって、相性の悪い仕組みです。

監査証跡とコンプライアンスページの両方がほぼ空白

サポートにおいては、単独作業よりも重要になる2つのギャップがあります。まず可観測性について。xAIのドキュメントはボットの操作を監査するビューを未来形で「coming」と説明しています。つまり今日の時点では、あるシフトの会話全体を通じてエージェントが正確に何をしたのかを再構成するのは難しく、これはHubSpot自身のレポート機能に頼って何が起きたかを把握しようとする場合には問題になります。

次にコンプライアンスについて。Grok BotはSOC 2、ISO 27001、GDPR、HIPAAのいずれの準拠も謳っておらず、データ保持期間やデータ所在地の条件も公開しておらず、Cursorの利用規約に委ねています。あなたのサポートデータに何か規制対象のものが含まれているなら、それは注釈ではなく、完全な停止条件です。これはGrokというモデルへの批判ではなく、サポートチームが必要とするガバナンス層をまだ構築していないベータ版エージェントだということです。HubSpot自身のBreezeエージェントは、そのクレジット計測の癖はあるにせよ、少なくともHubSpotのコンプライアンスの枠内で動作しています。

誰もスクリーンショットに撮らないコストの実像

値札の部分は簡単です。x.ai/botによれば、Cursor Ultraで月200ドル、Cursor Premium Teamsで席あたり月120ドル、あるいはSuperGrok Heavyに含まれています。人々を驚かせるのは、その下にあるメーターの部分です。

Grok Botは席料金に加えて週単位のAIトークン割り当てを課金し、超過分は「billed from model and token cost」とされ、xAIのドキュメントははっきりとこう述べています。「There is no Grok Bot-specific spend cap yet.」コスト管理にとってさらに悪いことに、「Grok Bot has no model picker, for members or admins」なので、日常的な会話業務をより安価なモデルに振り分けることもできません。サポート受信箱を処理する常時稼働のエージェントはトークン消費の激しいワークロードであり、それを気に入っていた同じHNユーザーが、まさにこの点を指摘しています。

"I've used more tokens this month than not this month. That's not a typo... Always on perpetual agents use a LOT of tokens."

jjcm, Hacker News

API側のルートでは計算式は異なりますが、単純ではありません。grok-4.6は100万トークンあたり入力2.00ドル/出力6.00ドルで動作し、さらにWebおよびX検索の呼び出しごとの料金(1,000回あたり5ドル)とファイル検索(1,000回あたり10ドル)が加わります。

そして、HubSpotのネイティブAIを並行して稼働させ続けるなら、そのメーターも積み重なります。Breeze Customer Agentは解決1件につき50 HubSpotクレジット(約0.50ドル)を課金し、Professionalに含まれる3,000クレジットは月あたり約60件の解決にしかならず、1日あたりおよそ2件に相当し、しかも他のあらゆるBreezeのアクションと共有されます。クレジットを使い切ると、エージェントは次のリセットまで、すべてのチャネルにわたって新しい会話を静かに受け付けなくなります。

完全な数字は私たちのHubSpot AIコストの内訳と、より広範なBreeze機能と制限ガイド、そしてその下にあるHubSpotの料金プランにあります。Freeは0ドル、Starterは席あたり7ドル、Professionalは席あたり90ドル(加えて必須の1,500ドルのオンボーディング費用)、Enterpriseは席あたり150ドルです。

代替案:実際にHubSpot Service Hubのために作られたAIエージェント

Grokの2つのルートに共通しているのはこれです。どちらもサポートに必要な安全レイヤーの責任をあなたに負わせ、どちらも事前にリハーサルする方法を与えてくれません。もしあなたが評価の途中にあるなら、目的特化型のService Hub AI代替策とも並べて検討する価値があります。それこそが、eeselが埋めるために存在するまさにそのギャップです。

eeselはAIチームメイトプラットフォームであり、HubSpot向けにはAIヘルプデスクチームメイトを雇うことになります。外部からあなたの画面を操作する代わりに、それはOAuth経由で本物のAIエージェントとしてあなたのService Hubアカウントに参加し、そのうえであなたのチームがすでに信頼している素材、すなわちあなたのナレッジベース記事、保存済みスニペット、過去のチケットで学習します。チケットを読み、返信を下書きして送信し、チケットのプロパティを更新し、ライブのCRM連絡先データを使ってレコードをパイプラインに沿って動かします。これらすべてが、借り物の人間のログインではなく、HubSpot自身の権限モデルの内側で行われます。

それは、あなたがすでに使っている同じHubSpotインテグレーションの周りにではなく、隣に位置します。サポートにとって最も重要な違いは、Grok Botが持っていないものです。あなたは、実際の顧客に返信する前に、あなたの実際の過去の会話数百件に対してエージェントをシミュレーションできます。それは過去のチケットを再生し、AIの回答をあなたのチームが実際に送った内容と照らして採点し、ギャップと提案される指示変更をあなたに返します。それが「信頼する前にテストする」という習慣であり、あなた任せにされるのではなく、製品に組み込まれています。

さらに、実運用の受信箱が必要とするコントロールも手に入ります。まずタグ付けとルーティングだけを行う純粋なトリアージモードで開始し、信頼できるようになったら公開返信をオンにできます。そしてGrok Botが「coming」としてリストしている監査証跡は、ここでは今日すでに存在します。すべての実行は、その背後にある理由とともに記録されます。

コスト面では、結果にかかわらず処理チケットあたり定額0.40ドルが課金され、席料金はなく、任意の固定月間支出上限を設定できるため、監視すべき青天井のトークンメーターも、月の途中で静かにゼロになってカスタマーエージェントを止めてしまうクレジット残高もありません。セキュリティ面では、eeselは取り込み時点で個人情報を編集(レダクト)し、あなたのデータでモデルを学習することは一切なく、リクエストに応じてEUデータ所在地を伴うGDPR準拠であり、SOC 2 Type IIを取得準備中で、Enterpriseプランでは BAA付きのHIPAAも提供します。

そして、もしあなたがGrok Botに惹かれた理由がそもそもターミナルとエージェントのワークフローにあったのなら、eeselもそこであなたを迎えます。それは本物のCLIとMCPサーバーを提供しており、Claude Code、Codex、CursorのようなコーディングエージェントがHubSpot連携を接続し、エージェントの指示を編集し、実行を一覧表示・承認し、アクティビティログを読むことができます。これらすべてがダッシュボードを開くことなく可能です。無人のブラウザにあなたのCRMを渡すことなく、プログラム可能でエージェント駆動の感覚を得られます。

HubSpot Service Hub向けにeeselを試す

もしあなたが、AIエージェントにあなたのHubSpot Service Hubの受信箱を処理させたいと思ってここに来たのなら、それはまさにeeselが存在する理由であり、数分でService Hubに接続できます。それは、あなたのナレッジベースと過去のチケットをすでに知っている新入社員のように機能し、最初にすることは、あなたの直近数百件の会話をどう処理していたかを見せることです。だからあなたは、ただスイッチを入れてうまくいくことを願うだけということには決してなりません。チケットあたり定額0.40ドル、席あたりの費用なし、クレジットカード不要で無料で試せます。