Grok Botの正体
Grok BotはxAIのAIチームメイトアプリで、2026年8月11日に発表された。自社ページでは「Early beta」と表示されている。各ボットは永続的で名前を持つ労働者であり、専用のクラウドコンピューターを与えられ、あなたがすでに使っているアプリにログインし、通常のインターフェースを通じてそれらを操作する。これはサポート製品ではなく汎用の労働エージェントであり、実際にログインしたブラウザを操作する他の自律型AIエージェントと同じカテゴリーに属する。
設計上の目標はカバレッジだ。Grok Botは「クリーンなAPIやMCPを持たないプラットフォームを含む」アプリやウェブサイト全般で動作するように作られており、それを実現する方法は人間のように振る舞うことにある。画面を乗っ取り、クリックし、フォームに入力する。この単一のメカニズムこそがカバレッジを買っており、この記事のあらゆる注意点の源でもある。
ログインフローは理解しておく価値がある。それが製品の核心だからだ。ボットがあなたのパスワードを保持することは決してない。ボットは画面をあなたに渡し、あなたがパスワード、パスキー、2FAコード、CAPTCHAを自分で入力し、それから制御を返す。そこから先は、xAIのドキュメントによれば、"ブラウザセッションは共有のGrok Botコンピューター上に残り続けるため、適切な場合には他のBotが同じログイン済みセッションを使用できる。"あるプレリリースのテスターはHacker Newsで率直にこう述べている。
"It'll ask you to take over its computer to log in […] After you do you just tell the bot you're done logging in and it'll keep driving. And yea, it's a separate VM for each bot."
ローンチ時には8つの名前付きボットの役割が用意された。Sales Outbound、Talent Scout、Paid Media、Expense Manager、Product Performance、Bug Reproduction、Account Health、Chief of Staffだ。マーケティングのプロンプトではサポートキューが例に挙げられているにもかかわらず、そのどれもがサポート職ではない点は注目に値する。この食い違いが、製品の関心が実際にどこにあるかを物語っている。
Grok Botはサポートキューを処理できるか
できる。しかもセットアップは速い。デスクトップアプリ（macOSまたはWindows。モバイルアプリはiOS 18以降が必要）をインストールし、ボットを立ち上げ、ヘルプデスクへのログインを依頼する。すると引き継ぎフローが起動し、あなた自身がZendeskやFreshdeskにログインすると、ボットが操作を始める。そこから先は、キューのトリアージ、返信の下書き、ナレッジベースでの検索などを依頼できる。
「Teach a task」という機能もある（xAIは保存されたバージョンをRoutinesと呼ぶ）。ボットが見ている前で一度作業をこなすと、その手順を保存して後で繰り返してくれる。反復的なチケット自動化にはそれなりに合っている。ただし制約は現実的で、ワークフローをこれに頼って構築する前に知っておく価値がある。ティーチングはブラウザでのみ機能し、10分の上限があり、出力は明示的に「下書き」であり、1ボットあたり50個のRoutinesしか持てず、Routineごとに保持される実行記録は20件のみだ。
つまり「できるか」の欄にはチェックが入る。この記事がここから先も続く理由は、「動かせるか」と「本番キューを任せるべきか」は別の問いだからであり、後者でサポートチームが痛い目に遭う。
本番キューでこの形が崩れるところ
デモでは見えないことがある。サポートキューは、意欲的な労働者に渡すToDoリストではない。実際の問題を抱えた実際の人々の流れであり、そこにAIを乗せる規律のすべては、AIにさせてはいけないことをめぐるものだ。4つの制御機構がその役割を担うが、共有ブラウザセッションをログイン済みの人間として操作するボットには、そのどれを置く場所もない。
ドライランがない。 xAIのドキュメントは明確だ。"A test run performs real work. It can navigate websites, change files, and call connected tools." ボットが直近の1,000件のチケットに回答し、どう答えていたかを見せてくれるモードは存在しない。それがあれば、たった一人の顧客にも影響が及ぶ前に精度の数字を確認できるはずだ。この数字こそが安全なロールアウトの核心だ。私たちがシミュレーションしたあるEコマースの受信箱では、ドライランはトリアージで93%の精度、下書きで7%の事実誤りという結果を返しており、誰かが送信ボタンを押す前に両方の数字を把握していた。「ログインして作業を始める」からは、そのどちらも得られない。
確信度によるスコープ設定がない。 Grok Botはキューに就くと1つのモードしか持たない。キューを処理するだけだ。しかしほとんどのチームはそれを望んでいない。GorgiasとShopifyを使い、月間約7,000件のチケットを抱えるDTCサプリメントブランドのCXリードは、この要件を誰よりも明確に言い表している。
"The AI will never be able to answer 100% of the questions, but if it tries and just answers 'sorry I don't know this,' I cannot go and check all my 7,000 tickets to see if the AI actually made a good answer, then the point is a little bit gone. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
これはインテント確信度しきい値を求める声であり、購入者が最も頻繁に求めるものだ。ログイン済みのブラウザセッションは「確信のあるチケットだけに触れる」ということを表現できない。ただ入力するだけだ。
チケットタイプの除外がない。 関連はしているが別の話として、AIを完全に近づけたくないカテゴリーは常に存在する（一定額を超える返金、法務案件、怒っているVIP案件など）。サポートチームはこれをAIチケット分類とルーティングルールによって実現している。ヘルプデスクのUIを操作するだけの汎用労働エージェントには、「このクラスのチケットは扱わない」という概念がない。
返信ごとの監査がない。 これはxAI自身の言葉でギャップとして文書化されている。"An audit view of Bot actions is coming." 未来形だ。今日の時点では確認できる返信ごとの記録はなく、これは二重の意味で重要になる。AI解決率を測定できないし、何か問題が起きたときにボットが実際に顧客へ何を伝えたのかを再現できない。そして、Grok Botの承認はプロダクトが強制するアクションリストではなくユーザーが書いた自由記述のテキストであるため、あなたが書くガードレールですら助言にすぎず、強制停止ではない。ドキュメントが指摘するとおりだ。"an approval controls the proposed action. It does not reverse work already completed."
これらはGrok Botが悪いという話ではない。この特定の仕事には形が合わないという話だ。UIを操作するその設計が光るのは、クリーンなAPIが一切ないツールに対するワークフロー自動化であり、コールセンターRPAの正統な後継だ。ライブのサポートキューは、そういうものではない。
サポートチームが最初に問うべきセキュリティの疑問
コストより先に、精度より先に、多くの記事が見落としている問いがある。共有のAI労働者にヘルプデスクへのログイン済みセッションを与えることは、実際には何を露出するのか。
設計から見ていこう。xAIのドキュメントによれば、"All of your Bots share one cloud computer… Files, browser sessions, and command line credentials on that computer are available across your Bot roster,"とあり、その後に2回にわたって、"not use separate Bots as a security boundary."という指示が続く。つまり、あなたのサポートボットが作成したZendeskのセッションには、営業ボットや広告運用ボット、そのアカウント上の他のあらゆるものからアクセスできてしまう。
誤解されがちだが実際の問題ではない点を1つ整理しておく価値がある。批判者は、すべてのログイン情報をイーロンのサーバーにアップロードすることになると言う。そうではない。パスワードは引き継ぎの際に自分自身で入力する。正確な問題点はもっと微妙で、率直に言えばもっと鋭い。ボットがログイン済みのセッション内で行動するため、ログ上ではその行動があなたに帰属する。あるHacker Newsのコメント投稿者は、この設計を短い言葉で言い当てた。
"By hijacking a real person's credentials, that person becomes the accountability sink. Very neat. Very deliberate."
ここにサポート特有のデータを重ねてみよう。チケットには日常的にカード番号やパスワード、その他のPIIが含まれる。したがって、ヘルプデスクへの永続的でログイン済みのセッションは単なる生産性ツールではなく、恒常的な認証情報・データの露出面となる。そしてGrok Botはコンプライアンス認証をひとつも謳っていない。SOC 2もISO 27001もGDPRもHIPAAもPCIもFedRAMPもなく、保持期間の明記も、データレジデンシーの明記もなく、保持に関する扱いはCursorの利用規約に委ねられている。セキュリティレビューを経験したことのある人にとって、これは強制停止に値する。ローンチ当日、あるコメント投稿者はこう総括した。
"Pricing: 120/200 USD per month, per employee. This is an interesting idea although I'm not sure how many companies are comfortable with giving SpaceXAI access to all your files and data. Outside of America this is, most likely, not going to fly."
キューにどんなAIを導入するか評価しているなら、データプライバシーと制御、そしてSOC 2やGDPRを満たしているかどうかは、最後ではなく最初に片付けるべき問いだ。
Grok Botの費用
Grok Botは2つのセルフサーブプランに加えてバンドルを提供しており、いずれもxAIではなくCursorにちなんで名付けられている。全体像は以下のとおりだ。
| プラン | 価格 | 備考 |
|---|---|---|
| Cursor Ultra | 月額200ドル | ソロプラン |
| Cursor Premium Teams | 1シートあたり月額120ドル | 一元請求、共有スキルマーケットプレイス、使用状況分析、SAML/OIDC SSO |
| SuperGrok Heavy | 追加料金なしで含まれる | Heavyサブスクリプションにバンドル |
| 無料プラン | なし | 公表された試用期間なし |
いくつか目を引く点がある。チームプランはソロプランよりシート単価が安く、これは珍しい。そして公表されている唯一のクォータは数字のない「Extended limits on AI tokens」であり、ドキュメントにはその上限は週単位で、超過分はモデルとトークンコストに応じて課金されるとある。この最後の部分は見た目以上に重要だ。常時稼働するエージェントは大量のトークンを消費するからだ。製品を気に入っている先のプレリリーステスターは、再びこう語る。
"Biggest downsides are token expenditure. I've used more tokens this month than not this month. That's not a typo - I've used less tokens in the last 5 years prior to this month than I have this month. Always on perpetual agents use a LOT of tokens."
サポートチームにとってより本質的なのは、自分が何に対して支払っているのかだ。Grok Botはシート単位で課金され、それはひとりの労働者へのアクセス料金だ。その労働者が今月1件のチケットを解決しても、1,000件を解決しても、コストは変わらない。
サポート自動化は通常これとは逆の方法で価格設定されており、チケット単位や解決単位で課金されるため、請求額は実施された作業に連動する。AIエージェントと人間のエージェントのコストを比較検討しているなら、この単位の違いこそが比較の本質であり、契約前に実際の数字を当てはめてみる価値がある。
Grok Botを自社のサポートキューに導入すべきか
私からの評決ではなく、実際に私がたどるであろう判断の道筋をここに示す。自分に最も近い行を選んでほしい。
代わりに使うべきもの：サポート専用のチームメイト
Grok Botを検討した理由が「自社のサポートキューにAIを導入したい」だったのなら、その仕事をこなすツールは、ブラウザセッションを渡す汎用労働者ではなく、キューのために作られたものだ。それがeeselが埋めるギャップだ。
eeselはAIチームメイトのプラットフォームであり、ここで適しているチームメイトはAIヘルプデスクエージェントだ。違いは接続の仕方から始まる。ログイン済みのブラウザを乗っ取るのではなく、アプリとしてヘルプデスクに接続する。これこそが、欠けていた4つの制御機能をそもそも表現可能にしているものだ。
- 本番稼働前のシミュレーション。 eeselは自社の過去のチケットに対して実行し、どのように対応していたかを報告するので、顧客が何かを目にする前に精度の数字を得られる。これがGrok Botにはないドライランであり、AIエージェントの評価の背後にあるのと同じ規律だ。
- 確信度に基づくルーティング。 確信のあるチケットに回答し、そうでないものは静かに人間へ残し、確信がない場合は人へのきれいなハンドオフを行う。
- スコープ設定と引用。 チケットタイプを除外でき、すべての回答は学習データからの即興ではなく、引用付きでナレッジベースに根ざしている。
- 本物の記録。 すべての応答が記録され、確認可能なので、解決率を測定し改善することが実際にできる。
そして、Grok BotにAPIもCLIもMCPもないという理由でここにたどり着いた人たちへ。eeselは逆の方向に進んでいる。カスタマーサポートエージェントAPIとCLIを公開しているので、スクリプトやコーディングエージェントが、キューを処理するのと同じチームメイトを操作できる。まず全体の選択肢を比較したいなら、AIカスタマーサービスソフトウェアとAIヘルプデスクソフトウェアのまとめが良い出発点になる。
サポートキューでeeselを試す
Zendesk、Freshdesk、あるいはGorgiasのキューでAIに実際に働いてほしいなら、eeselはすでに使っているヘルプデスクを通じて接続し、初日からヘルプセンターを把握している新入社員のように機能する。本番で一件でも回答する前に、直近数千件のチケットでシミュレーションでき、確信の持てる範囲だけに限定でき、すべての返信を確認できる。使用量ベースの課金なので、シート数ではなく解決したチケットに対して支払い、試用は無料だ。
要するに、Grok Botは賢い汎用労働者であり、カスタマーサポートはまさに「あなたとしてログインし、実際の作業をこなす」ことが強みではなくリスクになってしまう仕事だ。キューにはキューのために作られたものを使おう。
よくある質問
Grok Botは実際にカスタマーサポートのキューを処理できますか？
サポートチームにとってGrok Botの費用はいくらですか？
Grok Botに自社ヘルプデスクへのアクセスを与えるのは安全ですか？
カスタマーサポートにおけるGrok Botの最良の代替案は何ですか？
Grok Botにはサポート自動化のためのAPIやCLIがありますか？
Article by
Alicia Kirana Utomo
Kira is a writer at eesel AI with a Computer Science background and over a year of hands-on experience evaluating AI-powered customer service tools. She focuses on breaking down how helpdesk platforms and AI agents actually work so that support teams can make better buying decisions.
