Grok Botの評価結果、基準ごとに
私は、常時稼働のチームメイトを名乗る製品が証明すべき10個の項目を採点した。各行は2026年8月11日付のxAI公開ドキュメントと照合可能だ。実際に提供されている機能でフィルタしてほしい。
永続的なLinux VM上のブラウザ、ターミナル、ファイルシステム。xAIが明言する優先順位は、コネクタが存在すればコネクタ、存在しなければブラウザだ。
バックグラウンドのターンとスケジュール済みルーティンはクラウドコンピュータ上で実行される。アプリや画面を閉じても停止しない。
非同期のBot間メッセージに加え、2〜6体のBotによるグループチャットがあり、引き渡しは文字起こしの中で確認できる。
名前付きのBotは、毎回まっさらな環境から始めるのではなく、ターンをまたいで設定・ファイル・ブラウザのログイン状態を保持する。
「タスクを教える」機能は最大10分間のブラウザ操作を記録し、ドラフトのスキルを生成するが、判断ルールや失敗時の処理はあなたが追加する必要がある。段階的にロールアウトされているため、この機能自体がまだ表示されない場合もある。
主なメカニズムは、あなた自身が文章で書く境界線だ。Auto Reviewはモデルベースでオプトイン制であり、複数のマシン間で同期されるのではなくデスクトップごとに保存される。
SSO、MCPポリシー、席の管理はCursorのダッシュボードから引き継がれる。ローカル実行に対するチーム上限は「近日提供」とされており、Grok Botの支出上限はまだ存在しない。
サンドボックスは存在しない。ドキュメントには明確に、テストランは実際の作業を実行し、ウェブサイトを操作し、ファイルを変更し、接続済みツールを呼び出すことができると書かれている。
「Botアクションの監査ビューは近日提供予定」と、チームズページに2回明記されている。今日提供されているのはダッシュボード上の支出・利用状況と、チャットの文字起こしだけだ。
ドキュメント全体を通して、SOC 2、ISO 27001、GDPR、HIPAAのいずれの認証主張もない。保持期間もリージョンの選択肢も暗号化仕様もなく、すべてがCursorの規約に委ねられている。
10項目のうち4項目が提供済み、3項目が部分的、3項目がまだ実現していない。この比率は「早期ベータ」が意味すべき内容とおおむね一致しており、xAIの名誉のために言えば、このラベルは脚注に埋もれているのではなく製品ページ上に堂々と掲げられている。
実際に検証できたこと、できなかったこと
ここは正直に書く価値がある。ローンチ週のレビューの多くはそうなっていないからだ。
Grok Botは2026年8月11日、厳格な有料の壁の向こうでローンチした。SuperGrok Heavy、Cursor Ultra(月額200ドル)、またはCursor Premium Teams(席あたり月額120ドル)だ。無料プランはなく、公開されたトライアルもない。ドキュメントセットのすべてのページに「Last updated: August 11, 2026」というフッターがあり、コーパス全体がリビジョン履歴のないローンチ当日のスナップショットだということになる。
つまり、このレビューは3つのものに依拠している。公開されているドキュメント全体、マーケティング面、そして料金を支払った人々による最初の1週間の報告だ。そうでないもの、それは1カ月にわたる実際の利用経験であり、今週それ以外を主張する者は誰であれ、先行アクセスを持っていたか推測しているかのどちらかだ。Hacker Newsで最も詳細な実体験のレポートは、自らアーリーアクセスのテスターだと明かした人物によるもので、私は以下でその旨を明記している。
このスクリーンショットが物語る小さな事実がある。そのページ唯一のダウンロードボタンには「Download for Linux」と書かれている一方で、ドキュメントはLinuxデスクトップがローンチ時点では非対応だと述べている。対応プラットフォームはmacOS、Windows、そしてiOS 18以降のiPhoneだ。クラウドコンピュータ自体はLinuxで動作するが、あなたのデスクトップアプリはそうではない。
Grok Botが正しくできていること
クラウドコンピュータは単なる目新しさではない
ほとんどの自律型AIエージェントは、APIを呼び出すか、タスクごとに新しいサンドボックスを立ち上げて後で破棄するかのどちらかだ。Grok Botはユーザーアカウントごとに1台の永続的で管理されたLinux VMを保持し、非rootユーザーとしてBotを実行し、ブラウザ、ターミナル、そして通常のアップデートを乗り越える/workspaceファイルシステムを備える。作業はチャットのドラフトとして戻ってくるのではなく、実際のツールの中で完結する。
この違いこそが製品そのものであり、Hacker News上でのxAIエンジニア自身の説明ですら、この点について異例なほど正確だ。曰く、他の作業エージェント製品はクラウドエージェントごとに新しいVMを立ち上げては破棄するが、これは常時稼働のマシンであり、ログイン状態を維持し、Bot同士がメッセージをやり取りできるようにする。これは同社が自らの設計を説明しているものと受け止めるべきで、第三者による裏付けではない。
その実際的な効果は、AIワークフロー自動化の世界が常に苦戦してきたあらゆる場面で本物だ。20年前のサプライヤーポータル、エクスポート機能のないベンダーダッシュボード、誰も統合を構築しようとしない社内システム。これはコールセンターRPAの正当な後継であり、違うのはスクリプトが自ら書かれ、ボタンが移動しても適応する点だ。これによりGrok BotはChrome自動ブラウズと同じファミリーに位置づけられるが、決して眠らないマシンである点が異なる。
チームメイトという枠組みはおおむね機能している
Botを作成し、名前・肩書き・説明を与え、メッセージを送る。永続的なルールは説明欄に書く(「承認なしに外部へメッセージを送らない」など)。タスクの指示はメッセージに書く。スキルは再利用可能な手順定義であり、ルーティンはそれをスケジュールし、1体のBotは最大50個のルーティンを持つことができ、ルーティンごとに直近20件の実行記録が保持される。
グループチャットは2〜6体のBotを収容し、自己ルーティングさせるか、@で個別に呼びかけることができる。Bot間の引き渡しは非同期であり、会話の中で確認できる。同じことを手作業で構築していたHacker Newsの投稿者は、その差分をこうまとめている。
"I've already been doing something very similar to this with OpenClaw, where I set up multiple different Telegram bots each with different system prompts to tune their personalty & behavior. It's not trivial to do, and I never managed to get bot-to-bot communication working."
セットアップコストは本当にゼロに近い。ワークフロービルダーもなく、描くべきグラフもなく、事前のBot設定も不要だ。これは、構築すること自体が製品であるノーコードエージェントビルダーカテゴリに対する重要な優位点だ。
タスクを教える機能は予想以上に実用的だった
Botにコンピュータビューの中で一度何かをしてみせると、その録画からスキルを書き起こす。10分間という上限があり、ブラウザのみで動作し、マイク音声は取り込まない。
xAIはその成果物について立派なほど正直だ。学習したスキルはドラフトであり、たった一つの例からは明らかではない判断ルール、失敗時の処理、承認境界を自分で追加する必要がある。また段階的なロールアウトの背後に隠されているため、あなたが確認したときにこの機能自体がまだ存在しない可能性もある。だからこそ私はこれを「提供済み」ではなく「部分的」と採点した。
レビューの転換点: 1台のコンピュータ、すべてのログイン情報
これは他のすべてを再定義する発見であり、批評家からではなくxAI自身のページから直接得られたものだ。
あなたのすべてのBotは1台のクラウドコンピュータを共有している。 そのマシン上のファイル、ブラウザセッション、コマンドライン認証情報は、あなたのBot群全体で利用可能だ。各Botは独自の画面を持つが、ドキュメントはそれらの画面が別々の作業面であって別々のセキュリティ境界ではないと注意深く述べている。その指示はわずか一文だが、ドキュメントセット全体の中で最も鋭い一行だ。別々のBotをセキュリティ境界として使うな、と。
そこから2つの帰結が導かれる。第一に、Expense Manager Bot用にあるツールにログインすると、Talent Scout Botがそのセッションを引き継ぐ。第二に、Botを削除しても共有されているコンピュータ上のファイルやブラウザセッションは削除されないため、後始末は自分でウェブサイトからログアウトすることを含む6ステップの手動ルーティンとなる。
よくある批判の一つは誤りであり、正しておく価値がある。あなたは自分のパスワードをモデルに渡すわけではない。パスワード、パスキー、2FAコード、CAPTCHA、決済確認が必要な場面では、Botが一時停止して画面をあなたに渡し、あなたが入力してから制御を戻す。Hacker News上のアーリーアクセステスターはまさにこの流れを説明しており、値がマスクされ、文字起こしから除外され、モデルには決して表示されない、限定的なセキュアシークレットのプリミティブも存在する。
正確な異議はもっと繊細なもので、Hacker News上の誰かが、どのアナリストよりも見事にそれを言い当てている。
"By hijacking a real person's credentials, that person becomes the accountability sink. Very neat. Very deliberate."
まさにそういう形をしている。Botはあなたとして、あなたのセッションの中で行動し、その先のログはそれをあなたがやったことだと記録する。ヘルプデスクのデータプライバシーやSOC 2とGDPRのレビューに触れる何かにとって、これはあなたのセキュリティチームが最初に切り出す質問になるだろう。
そこでコンプライアンスのギャップの話になる。セキュリティに関連する4つのドキュメントページ全体を通して、SOC 2、ISO 27001、GDPR、HIPAA、FedRAMPのいずれの認証主張もなく、日数単位の保持期間もなく、リージョンの選択肢もなく、xAI独自の暗号化仕様もない。すべてがCursorの公開ドキュメントに委ねられている。データ保存も必須であり、Grok Botはデータ保存を要求し、レガシープライバシーモードには対応していない。文字通り「チームとエンタープライズ向け」と題されたドキュメントページにとって、これは調達チームが真っ先に見つける欠落だろう。
欠けている3つの制御
ドライランが存在しない
これは私にとって最も重要な点であり、推測ではなくxAI自身が明言している内容だ。テストランは存在し、それに付随する警告はこう書かれている。テストランは実際の作業を実行し、ウェブサイトを操作し、ファイルを変更し、接続済みツールを呼び出すことができる、と。
承認のドキュメントには、同じ問題のもう一つの静かなバージョンがある。承認は提案されたアクションを制御するものであり、すでに完了した作業を元に戻すものではない。「Stop now」を送っても何も取り消されない。つまり安全モデルは完全に予防的なものであり、その予防は事前に書いておいた境界線に依存している。
これを、スコープを絞ったエージェントが本番稼働する方法と比較してみよう。あなたはそれを数百件の実際の過去データに対して再生し、それは誰にも送信されない回答を生成し、決定する前に精度の数字を読む。それがOpenAIの評価ベストプラクティスが説明している内容であり、実際に噛みつく失敗モード、つまり明らかなたわ言ではなく流暢で説得力のある誤った回答を捕まえる標準的な方法だ。サポートにおけるAIハルシネーションが本番ではなくリハーサルで捕まる理由も同じだ。
承認はポリシーではなく文章
ドキュメントの最初の指示は、境界線をリクエストの中に一文として自分自身で書くことだ。xAIはその後、フェンスで囲むことを推奨するカテゴリを列挙するが、その動詞は「requires」ではなく「prefer」だ。メッセージの送信、公開、購入と送金、データの削除、権限の変更、本番環境への変更、法的条項への同意。このページのどこにも、製品がデフォルトでこれらを止めるとは書かれていない。
Auto Reviewはより実際の強制に近いものだが、条件付き(「Auto Reviewの強制が利用可能な場合」)であり、モデルベースであり、同期されるのではなくデスクトップごとに保存される。xAI自身の注意書きは異例なほど率直だ。これは最小権限や明示的な承認境界を置き換えるのではなく、補完するべきものである、と。LLMがLLMを判断しているのだ。r/AI_Agentsの誰かが、ドキュメントよりも見事にこの運用面のバージョンを言い当てている。
"run enough autonomous agents and the failure that costs you isn't the draft quality, it's the sent email or CRM write the agent classified as routine and never surfaced for approval. how it decides what 'needs your approval' is the entire safety surface, and that's the part nobody's actually asking about."
私は別の製品において、本番環境でまさにこの失敗を目にしたことがある。あるレストランチェーンのITマネージャーは、エージェントが誰も頼んでいないレポートをメールで送った後、こう一言返してきた。「Why did you email this report? I did not ask for that. DO not email these reports.」その時は何も損害はなかった。エージェントが共有トラッカーに追記するのではなく上書きしてしまったバージョンでは、これも実際に起きたことだが、顧客の履歴が消えてしまった。共有ドキュメントへの書き込みアクセス権を持つものは何であれ、Google DocsのAI統合に向けるのと同じ精査に値する。
監査ビューは依然として「近日提供」のまま
チームズページに未来形で2回明記されている。支出と利用状況は今日Cursorのダッシュボードに表示されるが、Botが実際に何をしたかの記録は表示されない。
チャットの文字起こしがその代替であり、確かにツールの活動、コンピュータの使用状況、作成されたファイル、承認リクエストをインラインで表示する。しかしそれはBotの会話ごとに整理されており、チーム横断で検索することはできず、ルーティンは直近20件の実行記録しか保持しない。エージェントQAのエビデンスや、擁護可能なAI解決率が必要なら、このギャップは単なる不便ではなくブロッカーになる。r/AI_Agentsのあるコメントは、この3つの論点を一行に凝縮している。
"'own computer' is the right direction, but the hard parts are identity, approvals, audit logs. without those it's not an employee, it's a browser with chaos privileges"
最初の1週間、実際のユーザーが見つけたこと
信頼性を判断できるほど長く動かしていた人はほとんどいなかったので、これは結論ではなく初期のシグナルとして扱ってほしい。
最も強力なコスト面のデータポイントは、この製品を気に入っているアーリーアクセスのテスターからのものであり、これはむしろ信頼性を高める材料だ。
"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の支出上限がまだ存在しないためだ。私はGrok Botの料金の内訳で料金体系の全体を検証しており、チームを本格導入する前に読む価値がある。1人あたり課金される席に加えて上限のないメーターというのは、AIエージェントと人間のエージェントのコスト比較にあるチケット単位の計算とは異なる形だ。
計測そのものもローンチ時点では明らかに粗かった。テストのためだけにCursor Ultraを購入したある人物は、ダッシュボードには利用状況が表示されていないのに、アプリ上では48%と表示されていたと報告している。別の人物はiOS上で壊れたGitHubログインに遭遇し、まったく入れなかった。どちらも設計上の欠陥というよりローンチ週特有のバグだが、それこそ「早期ベータ」が正しいラベルである理由だ。
最も有用な実体験のレポートはr/singularityから寄せられたもので、その適合性を公平に表現している。
"gave it a shot, seems useful for product owners that need more automation and less hands-on work. main difference is that everything is stored on their backend. presentation is clean, simple, no reasoning/thinking knobs."
両プラットフォームで最も声高だったスレッドは、品質についてのものではまったくなかった。それは下位プランのCursor顧客が締め出されていることに気づいた、というものであり、ローンチスレッドの上部の大半はこの話題だった。
では、サポートキューに向けることはできるのか
できる。そしてxAI自身のマーケティングページもそれを勧めている。サンプルプロンプトの一つは、Zendeskにログインしてサポートキューを処理するという内容だ。ただし、その次に何が起きたかに注目する価値はある。この製品が出荷する8つのBotロールのうち、サポート向けの役割は一つもない。ラインナップはSales Outbound、Talent Scout、Paid Media、Expense Manager、Product Performance、Bug Reproduction、Account Health、Chief of Staffだ。
これはxAIによる正しい判断だと私は思う。そしてこれは、買い手が何かをオンにする前に必要だと私に語る内容と一致している。Gorgias/Shopifyで月間約7,000件のチケットを扱うDTCサプリメントブランドのCXリードは、その要件を明確に述べていた。AIは決して100%の質問に答えることはないが、もしそれを試みて「すみません、わかりません」と答えるなら、7,000件のチケットを遡ってそれがうまくいったかどうか確認することはできない、と。彼らが必要としていたのは、自信のあるチケットだけを処理し、それ以外はすべて放っておくAIだった。
ログイン済みのブラウザセッションには、それを表現する手段がない。チケット単位のスコープも、信頼度のしきい値も、「返金はAIから遠ざける」というルールもない。私が話を聞いた別のサポートリードは、まさにそれを求めていた。「There are certain tickets I don't want to go through AI.」3人目は、エージェントが明示的に@でメンションされたときだけ動作し、受信するすべての顧客メッセージに対しては動作しないことを望んでいた。
これらは「ツール全体」よりも狭いスコープを求める3つの異なる方法であり、共有されたブラウザログインが持つ唯一のスコープは「ツール全体」なのだ。それこそが、エージェント型カスタマーサービス製品がヘルプデスクのUIではなく独自のAPIを中心に構築されている理由であり、チケットトリアージが独立した制御としてそもそも存在する理由でもある。どのチケットにエージェントが触れてよいかを決めることは、それに回答することとは別の仕事だ。
それでも汎用エージェントのアプローチをサポートで試したいのであれば、賢明なバージョンはドラフトのみに留めることだ。調査と準備をさせ、すべての送信を人の手の後ろに置く。それがカスタマーサービス向けAIコパイロットが設計上行っていることだ。
その上で、ブラウザセッションではカバーできない部分を追加する。実際の人間へのハンドオフの経路と、エージェントが推測するのではなく諦めるタイミングを決めるルールだ。その時点で、あなたはヘルプデスクコパイロットがもとから備えているものの大半を、手作業で再構築したことになる。
共有ログインなしで、キューのためのAIチームメイトを
もしあなたがここまで読んだのが、汎用の作業エージェントではなくサポートキューでのチームメイトの感覚を求めているからなら、それこそeeselが構築された理由となるギャップだ。eeselはZendesk、Freshdesk、Gorgias、Frontなどにログイン状態を維持するブラウザセッションとしてではなく、アプリとして接続するため、スコープはモデルが尊重してくれることを願う文章ではなく、実際の設定項目になる。
この比較で最も重要な部分はリハーサルだ。あなたはeeselを何かライブに触れさせる前に、自分自身のチケット履歴に対して再生し、それをオンにする決断をする前に、精度の数字と予測解決率を読む。信頼度に基づくルーティングが、どのチケットを処理し、どれを直接人間に回すかを決め、すべての回答は出典を引用し、すべてのアクションは照会可能なアクティビティログに記録される。セットアップはヘルプデスクのマーケットプレイス経由で数分で終わり、トレーニングデータがあなたの返金ポリシーをカバーしていることを願うのではなく、あなた自身のナレッジベースで学習させる。
また、それは他のものであるふりもしない。eeselはAPIを持たない任意のSaaSツールにログインしてあなたの代わりにクリックして回るようなことはしない。もしそれがあなたの本当の問題であるなら、Grok Botのほうが私たちよりも良い答えだ。
**eeselを試す**のは無料で、あるいは先月のチケットでシミュレーションを実行し、決断する前にその数字を見てほしい。
Grok Botレビューのスコア、あなたが誰であるかによって
| あなたは | スコア | 理由 |
|---|---|---|
| APIのないツールを自動化している | 8/10 | これこそがこの製品が存在する理由だ。ブラウザとあなたのログインは、誰も構築しない統合を待つことに勝る。 |
| ドラフト中心のナレッジワークをしている | 7/10 | 調査、資料作成、パイプラインの整理、経費仕分け。ミスの代償は読み直しであり、顧客ではない。 |
| エンジニアリングチームを運営している | 7/10 | worktreeを使い分ける手間なく、リポジトリをまたいだ非同期作業ができ、Cursorはすでにアカウント層になっている。トークンの消費量には注意すること。 |
| サポートキューを処理している | 4/10 | ドライランなし、信頼度ゲートなし、応答ごとの記録なし、そして送信は取り消せないアクションだ。 |
| 規制業界の組織向けに購入を検討している | 3/10 | 認証の主張なし、保持期間の公開なし、リージョンの選択肢なし、1人1台の共有マシン。 |
| 下位のCursorプランを使っている | 該当なし | まだ購入できない。それがローンチスレッドの大部分を占めている。 |
Grok Botは導入する価値があるか?
あなたのボトルネックが誰も統合していないツールで、作業がドラフト中心であるなら、イエスだ。 このアーキテクチャは実際の問題に対する実際の答えであり、セットアップコストはゼロに近く、私はベンダーがこれを「早期ベータ」とラベル付けして出荷するほうが、エンタープライズ対応であるかのように取り繕うよりも好ましいと思う。その軸で見れば、現在の最良のAIエージェント分野にあるもののほとんどに勝っており、その裏側にあるモデルは、静かに人々を惹きつけ続けているGrok 4.5と同じ系統だ。
仕事が顧客に何かを送信することを伴うなら、ノーだ。 モデルが悪いからではなく、エージェントをキューに安心して向けられるようにする3つの制御こそが、まさに出荷されていない3つだからだ。リハーサル、スコープ、そして記録である。そのうち2つについてはxAIがすでに近日提供予定だと語っており、それは「まだ」の正直なバージョンであり、四半期後に再確認する価値がある。
製品ではなくカテゴリを比較検討しているなら、Claude Coworkが同じトレードオフを持つ最も近い類似製品だ。Manus AIはクラウドコンピュータの形を共有しており、MaxClawも同様だ。
Lindy AIは、ブラウザセッションを求めることなく同じチームメイトの枠組みを提供している。
サポート寄りの用途であれば、代わりにAIヘルプデスクソフトウェアから検討を始めてほしい。そして、汎用エージェントを自分でつなぎ合わせたい誘惑に駆られているなら、まず自社開発か購入かの数字を計算してほしい。
よくある質問
2026年、Grok Botは導入する価値があるか?
Grok Botの料金はいくらか?
Grok Botに自分のアカウントへのアクセスを与えても安全か?
Grok Botはカスタマーサポートのチケットを処理できるか?
Grok BotとClaude Coworkの違いは何か?
Grok Botはどのプラットフォームに対応しているか?
Grok Botの代替として最良のものは何か?
Article by
Rama Adi Nugraha
Rama is a software engineer at eesel AI with two years of experience writing about B2B SaaS, AI tools, and customer support technology. Based in Bali, Indonesia, he brings a developer's perspective to product comparisons — cutting through marketing copy to what the integrations and APIs actually do.
