Grok Botとeesel AIはどちらも「チームメイト」という言葉を使いますが、想定している仕事が違います。Grok BotはxAIの汎用の労働エージェントです。クラウド上のコンピューターが割り当てられ、ログイン済みの人間としてアプリにサインインし、人がするようにクリックして回ります。この設計のおかげで、きれいなAPIを持たないツールにも届きますが、まさにその理由で、私は稼働中のサポートキューには置きません。過去のチケットでの予行演習がなく、「自信のあるチケットだけ触って」と指定する方法がなく、返信ごとに何をしたかの記録もありません。
eesel AIは意図的にその逆の形をしています。ヘルプデスク担当のチームメイトは、Zendesk、Freshdesk、Gorgias、Help Scoutそれぞれの連携を通じて接続し、過去の履歴で学習し、顧客に一度も返信する前に数千件の過去チケットでシミュレーションできます。チケット単位で範囲を決め、確信度でルーティングし、すべての返信を監査できます。
ひとことで言えば、アプリをまたぐ雑多なコンピューター作業をエージェントに任せたいなら、Grok Botは一見の価値があります。サポートキューを安全に任せたいなら、それは別のツールで、この記事が本当に扱うのはそちらです。
始める前にお断りしておくと、私はeeselで働いており、ここ数年、稼働中のサポートキューにAIエージェントを置いてきました。印象に残っているのはデモではありません。ナレッジベースが空で返ってきたせいで、自信ありげなボットが実在の顧客のチケットに答えをでっち上げる光景です。私たちはそれを出荷し、見つけ、いまはそれを前提に設計しています。これがこの比較に持ち込む視点です。
このスクリーンショットが議論のすべてです。エージェントが行ったあらゆる操作が、チケット単位に絞られ、承認済み、保留中、解決済みのタグが付いています。この点を覚えておいてください。ブラウザを操作する汎用エージェントには提供できないものだからです。
Grok Botとは実際に何か
Grok Botは、xAIの常時稼働のエージェント型チームメイトアプリで、2026年8月11日に発表され、自社ページではいまも「Early beta」と表示されています。各Botは永続的で名前のある作業者です。専用のクラウドコンピューター（管理されたLinux VM）が割り当てられ、あなたが使うアプリやウェブサイトにサインインし、インターフェース経由で操作します。最大の売りはカバー範囲です。人間のようにログインして動くため、APIを呼ぶのではなく、"platforms with no clean API or MCP" でも作業できるとしています。
これは本物の能力で、新しいものです。ローンチ時に8つの名前付きの役割が用意されています。Sales Outbound、Talent Scout、Paid Media、Expense Manager、Product Performance、Bug Reproduction、Account Health、Chief of Staffです。Bot同士でメッセージを送り合い、2〜6体のグループチャットを作り、@で呼ばれなくても自分でルーティングします。バックグラウンドで静かに仕事をこなす自律型AIエージェントを望んでいたなら、これはより野心的な試みのひとつで、Claude CoworkやManus AIと同じ系統です。
ただ、ここに手がかりがあります。製品ページ自身の例示プロンプトは "Sign in to Zendesk so I can work the support queue." なのに、8つの役割のどれもサポート担当ではありません。xAIは、実際にはサポート製品を出していないサポート用途を見せているのです。このギャップが、この比較記事を書く理由のすべてです。
eesel AIとは実際に何か
eeselはAIチームメイトのプラットフォームです。特定の仕事向けにすぐ働けるチームメイトを雇い、すでに使っているアプリにつなぐと、数分で働き始めます。現在のラインナップは2人で、AIヘルプデスクのチームメイトとAIブログライターです。この記事で重要なのはヘルプデスク担当のほうです。
Grok Botとの違いは見た目ではなく、アーキテクチャです。eeselは人間としてヘルプデスクにサインインしてクリックして回ることはしません。ヘルプデスク自身の連携インターフェースを通じてアプリとして接続し、だからこそサポート固有のあらゆる制御を表現できます。過去のチケット、ヘルプセンター、ドキュメントで学習し、Zendesk、Freshdesk、Gorgias内のキューに参加し、注文を調べ、チケットにタグを付け、返信を下書きまたは送信します。そして、稼働中の会話に一度も触れる前に、チケット履歴に対するシミュレーションとして実行できます。
Grok Botがログインとタスクリストを渡す汎用の作業者だとすれば、eeselは、すでに製品を知っていて、あなたのルールの中で働く新しいヘルプデスク担当者に近い存在です。
核心の違い：ブラウザを操作するか、アプリとして接続するか
その後のすべては、エージェントがヘルプデスクにどう到達するかという1つの設計判断から生まれます。
Grok BotのBotたちは、ユーザーアカウントごとに1台のクラウドコンピューターを共有します。Botが認証情報を直接保持することはなく、一見安心に聞こえます。画面を渡され、あなたがパスワードやパスキー、2FAを入力し、Botが進めます。しかしそのセッションは共有コンピューター上に残り、アカウント内のほかのBotも再利用できます。xAIのドキュメントは平易な言葉で2回述べています。"Do not use separate Bots as a security boundary." Botを削除しても、そのファイルとサインインは残ります。
生産性ツールとしてなら、このトレードオフは問題ありません。サポートキューには不向きな形です。ログイン済みのブラウザセッションには、実際のキューに必要な制約を置く場所がないからです。「自信のあるチケットだけ対応して」とは言えません。「請求トラブルはAIから完全に遠ざけて」とも言えません。何をなぜ判断したかの返信単位の記録も得られません。これらはあれば嬉しい機能ではなく、私が話したすべてのサポートリーダーが本番稼働の前に最初に尋ねることです。ある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. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
GorgiasとShopifyを使い、月に約7,000件のチケットを扱うDTCサプリメントブランドのCXリーダー
人間としてヘルプデスクにログインするエージェントのモードはただ1つで、キューを処理することです。この購入者の依頼のすべては、キューの大半を処理しないことでした。エージェントが範囲を絞ったアプリとして接続するなら表現できる制約ですが、あなたのログインが入っただけのブラウザセッションでは、根本的に表現できません。
Grok Botが本当に優れている点
公平に言えば、画面を操作する設計は間違いではなく、現実の問題への本物の答えです。多くの業務ツールには使えるAPIがありません。RPAベンダーは長年そのギャップを埋めて商売をしてきましたが、画面を見て正しいボタンをクリックできるモデルは、壊れやすい画面スクレイピングのスクリプトよりはるかに良い橋渡しです。社内の業務、単発のリサーチ、半ダースのアプリにまたがるワークフロー自動化、かつては午後を丸ごと使っていた長時間のお使いなどには、専用コンピューターを持つ常時稼働のBotは確かに魅力的です。コールセンターRPAの正統な子孫で、運転手がはるかに賢くなっています。
1か月使ったあるHNのコメント投稿者は、魅力と落とし穴の両方を捉えていました。
"Additionally though each one has their own computer, which means async work feels like it actually works... Biggest downsides are token expenditure. I've used more tokens this month than not this month. That's not a typo."
これがトレードオフの要点です。本物の非同期の能力と、本物のトークンコスト。仕事が広く、探索的で、たまの回り道を許容できるなら、そのトレードは見合うかもしれません。サポートキューはそのどれでもありません。
eeselがより適している点：サポートキュー
本番のキューには具体的な要件のリストがあり、ほとんどのチームにとって譲れないものです。それらは、範囲を絞ったアプリにできてブラウザセッションにできないことと、ほぼ1対1で対応します。
本番前の予行演習。 eeselは過去のチケットに対してシミュレーションでき、顧客が関わる前に議論できる数字が得られます。あるECの受信トレイでは、この予行演習の結果、トリアージの精度は93%、下書きの事実誤り率は7%と判明し、どちらもスイッチを入れる前に把握できました。Grok Botのドキュメントは、ここにそんなものはないと明言しています。"A test run performs real work. It can navigate websites, change files, and call connected tools." 予行演習がないので、最初の本当のテストは本当の顧客に対して行われます。
確信があるときだけ回答。 eeselは意図の確信度しきい値でルーティングし、それ以外には手を触れません。上のCXリーダーが、これなしには稼働しないと言った唯一の制御です。
特定のチケット種別をスキップ。 チケット分類により、カテゴリごとAIから遠ざけられます。ログイン済みのセッションは受信トレイ全体を見てしまいます。
出典を示し、きれいに引き継ぐ。 回答には出典が付き、エスカレーションは行き止まりではなく人への引き継ぎに回ります。なぜこれが重要か、私たちは痛い目を見て学びました。自律フローが名前のある人間のエージェントになりすまし、自分自身のエスカレーションメールを自動でクローズし、本物の人間が誰も目にしなかった例を見たことがあります。返信ごとの記録ときれいなエスカレーションは、そうした失敗が静かにではなく見える形で起きるようにするために存在します。
すべての返信の記録。 これが解決率と監査の土台で、「AIが対応した」と「AIが何をしたかはこのとおり」の違いを生みます。
Grok Botは、この欠落を隠していない点では評価できます。承認モデルには、ドキュメントに警告が明記されています。"An approval controls the proposed action. It does not reverse work already completed." では監査の土台は？ "An audit view of Bot actions is coming." 未来形です。私たち自身のガードレールを設計していたとき、チームのAmoghはこう言いました。"If hard-fail it's silent-failure class (worst class for trust)." レビューできる前に動けるサポートツールで、監査ビューがまだロードマップ上にあるなら、まさにそのクラスに入ります。
料金：シートかクレジットか
2つの製品は、価格の付け方が違うだけでなく、違うものに値段を付けています。
Grok Botが売るのはシートです。2つのセルフサービスプランは、xAIではなくCursorの名前を冠しています。月額$200のCursor Ultraと、1シートあたり月額$120のCursor Premium Teamsです（チームプランのほうが個人プランより1シートあたり安いのは奇妙です）。無料枠も公開された試用もなく、上限に関する記述は数字のない "Extended limits on AI tokens" だけで、超過分はモデルとトークンのコストで請求されます。シートは作業者へのアクセス権です。
eeselが売るのは完了した仕事です。料金ページのとおり、件数に合わせた固定の月額で、月額$299から500クレジット、1クレジットは長さに関係なくチケットまたはチャット1件（返信ごとではありません）で、プラットフォーム料金もシートごとの料金もありません。100クレジットが無料で、クレジットカードも不要です。チケットは、すでにあなたが普段考えている単位です。
| Grok Bot | eesel AI | |
|---|---|---|
| モデル | シート単位 | 固定の月間クレジット（チケットまたはチャット1件につき1） |
| 入口価格 | 個人は月$200、チームは1シート$120 | 月$299から（500クレジット） |
| 無料枠 | 公開なし | 100クレジット無料、カード不要 |
| 超過 | トークンコストが上乗せ | 任意、追加1クレジットあたり$0.80、上限はご自身で設定 |
| 支払う対象 | 作業者へのアクセス | 実際に完了した仕事 |
定価以上にこれが重要な理由は、予測しやすさです。eeselのクレジットは、1件のチケット内でのボットの内部的な反復、追跡、リトライに追加料金を課さないため、月末の数字はモデルのおしゃべりではなく仕事量に連動します。Grok Botの "you'll use a LOT of tokens" という実態（私の言葉ではなくHNユーザーの言葉です）は逆です。エージェントがどれだけ考えるかでコストが増え、それはまさに予測できない変数です。AIの単位価格が人間のエージェントとどう比較されるかの詳しい内訳は、コスト計算を別記事で解説しました。
セキュリティと共有セッションの問題
Grok Botをサポート用途で検討している方に、最も強く注意を促したい部分です。
サポートチケットには、カード番号、パスワード、個人情報など機微なデータが詰まっています。厳しいセキュリティレビューを一緒に乗り越えたある購入者は、個人情報を含むチケットデータが自社の環境内に留まるのかと率直に尋ねました。規制の厳しい業界では、それが当たり前の質問であり、特殊なケースではありません。
Grok Botのドキュメントはコンプライアンス認証がゼロだと明言しています。SOC 2なし、ISOなし、GDPRなし、HIPAAなし、保持期間やデータ所在地の記載もなく、Cursorの規約に委ねています。これに、ほかのBotが再利用できる永続的でログイン済みのブラウザセッションが加わると、共有マシン上に認証情報と個人情報の露出面ができあがります。公開ウェブサイトを閲覧する生産性ツールとは、まったく異なるリスクプロファイルです。
eeselのセキュリティ体制は、その正反対の利用者向けに作られています。顧客データがモデルの学習に使われることはなく、各ワークスペースは完全に分離され、オプションの個人情報伏せ字処理は、カード番号、メールアドレス、電話番号などを取り込み時に、コンテンツが処理される前に取り除くため、生データがデータベースや検索インデックスに届くことはありません。GDPRとCCPAに準拠し、SOC 2 Type II認証を取得しており、HIPAAはアドオンで利用できます（ご相談ください）。サポートのデータプライバシーがチェックリストにあるなら、比較が実際に行われるのはそのレベルであり、どちらかに決める前にSOC 2とGDPRについて読んでおく価値があります。
開発者向け：API、MCP、CLI
サポートエージェントをターミナルやスクリプトから動かしたいチームなら、このセクションが当てはまります。ここで2つの製品は完全に分かれます。
Grok Botには、文書化されたAPI、SDK、Webhook、CLIがありません。MCPは資料の中でちょうど1回だけ登場し（"connectors/MCP where available"）、詳しい説明はありません。ツールにプログラムから到達することが存在意義の製品なのに、皮肉なことに自分自身がプログラムから到達できません。Grok Botを自社のシステムに組み込みたいなら、現時点の答えは「きれいにはできない」です。
eeselは逆を行きます。eesel CLIは、同じチームメイトをターミナルに持ち込みます。意図的に別製品ではなく、CLIで設定したものはダッシュボードにも表示され、その逆も同様です。どちらでも同じエージェントだからです。ダッシュボードを開かずに、エージェントとチャットし、ヘルプデスクを接続し、ナレッジをアップロードし、自動化を組み、保留中のアクションを承認できます。すべてのコマンドがJSONを出力するため、Claude Code、Cursor、Codexのようなコーディングエージェントが、ワークスペース全体のセットアップを代行できます。アカウントなしで始めることもできます。npx @eesel/cli initで$5分の利用枠付きの匿名ワークスペースが作られ、あとからeesel loginで自分のものにできます。これは、Grok Botが示唆しながらも公開していない、エージェント型でスクリプト化されたワークフロー向けの、本物のプログラマブルな接点です。さまざまなアシスタントの接続方法を比べているなら、Claudeをヘルプデスクにつなぐガイドも同じ領域を扱っています。
では、どちらを選ぶべきか
正直な線引きはこうです。
Grok Botを選ぶのは、APIを持たないものも含め多くのアプリにまたがる社内業務向けの汎用エージェントが欲しく、トークン使用量に応じて増えるコストと事後レビューのモデルを許容できる場合です。興味深い製品で、適した業務ワークフローには役立ちます。ただし、サポート製品ではなく、自社のロードマップ（監査ビューは "coming"）がそれを自覚していることを示しています。
eesel AIを選ぶのは、仕事がサポートキューである場合です。予行演習、確信度しきい値、チケット単位の範囲設定、返信ごとの監査、個人情報の伏せ字処理、予測できる固定の月額料金が必要でしょう。これは、ヘルプデスクのログインを持たされた汎用の作業者ではなく、専用設計のカスタマーサービス向けAIエージェントです。まだ比較中なら、AIヘルプデスクソフトウェアのまとめと、より広いカスタマーサービスの代替ツールの一覧で、ほかの選択肢が見渡せます。
カテゴリの混同は無理もありません。どちらの製品も「チームメイト」と言うからです。しかし、ブラウザセッションとタスクリストを渡す必要があるチームメイトと、すでにヘルプデスクの中で暮らし、製品を知り、指示した範囲でのみ動くチームメイトとでは、担う仕事が違います。
eeselを試す
Grok Botの「Zendeskにサインインしてキューを処理する」デモが目に留まったなら、eeselはそれを本番向けに作ったものです。Zendesk、Freshdesk、Gorgias、Help Scoutなど1000以上のツールに数分で接続し、過去のチケットとヘルプセンターで学習し、顧客に一度も返信する前に履歴に対して全体をシミュレーションできます。範囲設定、確信度の制御、監査証跡は、最後まであなたの手元に残ります。
100クレジットでクレジットカード不要の無料スタートもできますし、eesel CLIで同じチームメイトをターミナルから動かすこともできます。最初の回答に実際の顧客を賭けることなく、AIにキューを実際に任せるための、私が知る最も安全な方法です。