Grok Botとは｜xAIの常駐型AIエージェントの仕組み・料金・競合比較・注意点

Grok Botとは、xAI(現SpaceXAI)が提供する常駐型のAIエージェントで、クラウド上に用意された作業用コンピュータの中で、人間と同じように画面を操作して仕事を完了させるサービスです。 2026年8月11日に早期ベータとして提供が始まりました。公式の定義は「実際の仕事を渡せるAIチームメイト(AI teammates you can give real work to)」で、質問に答えるチャットボットではなく、調査・入力・下書き作成といった作業そのものを任せる製品です。既成ロールには営業アウトバウンドや広告運用など営業・マーケティング職が並びます。この記事では、公式ドキュメント(docs.x.aiとCursorヘルプ)を一次情報として、仕組み・承認の設計・料金と使用量の構造・Claude CoworkやChatGPT Workとの比較・発売後10日間に報告された不具合・導入の進め方までを整理します。

Grok Botとは何か — 「答えるAI」と「作業を完了させるAI」の違い

これまでの生成AIの活用では、AIが出すのは答えや下書きまでで、それを業務システムに反映するのは人間の仕事でした。Grok Botはこの「実行」の部分を持っています。

公式ドキュメントでは「Bot=名前を持った1体の常駐エージェント、つまり1人のAIチームメイト」と定義されています。xAI社内のプロトタイプとして作られたものが社内に広まり、製品化されたという経緯が発表ブログに書かれています。基本情報を整理します。

「ベータ」という呼び方については、Cursor側のヘルプに「早期製品であることを示すための表現であり、Cursorのベータサービス規約の対象ではない」という注記があります。つまり正式な有料製品として提供されており、料金も発生します。

仕組み — クラウドPC・画面操作・スキルとルーティン

1アカウントに1台のクラウドPCを、全Botが共有する

Botが働く場所は、クラウド上に用意された管理されたLinux仮想マシンです。ブラウザ・ファイルシステム・ターミナルを備え、Botは管理者権限を持たない一般ユーザーとして動きます。ここで最も重要な仕様が、このマシンはBotごとではなく、ユーザーアカウントごとに1台だという点です。公式ドキュメントの原文は「All of your Bots use the same persistent cloud computer. They share files, browser sessions, and app logins.(すべてのBotは同じ常設クラウドコンピュータを使い、ファイル・ブラウザセッション・アプリのログインを共有する)」です。

この構造の細部を公式ドキュメントから拾うと、次の通りです。

画面操作とログインの引き継ぎ

BotはMCPやAPIによる接続も使えますが、主役は「人間と同じように画面を見て操作する」方式です。このため、APIも連携機能も用意されていない古い業務システムやベンダーの管理画面でも使えることが最大の強みになります。

ログインの流れは公式の手順がはっきりしています。Botが認証の必要なアプリにたどり着くと、人に「コンピュータを引き継いでほしい」と求めてきます。人は会話画面から「Agent Computer」を開いてクラウドPCの画面を直接操作し、パスワード・パスキー・2段階認証コード・CAPTCHAを自分で入力して、操作をBotに戻します。Cursorのヘルプには「あなた自身がサインインするので、エージェントはパスワードを見ない」とあります。ログイン済みのブラウザセッションは共有PC上に残るため、以後は他のBotも同じログイン状態を使えます。パスワードやワンタイムコードを普通のチャットに書いてはいけない、という注意も明記されています。

スキル・ルーティン・実演で教える — 3つの別概念

日本語の解説記事では混同されがちですが、公式ドキュメントでは3つは別のものです。

注意点が2つあります。ルーティンの「テスト実行」は本物の作業を行います(Webサイトを操作し、ファイルを変更し、接続したツールを呼び出す)。また長期間アプリを開かないと、Grok Botがルーティンを続けるか尋ね、返答がなければ一時停止することがあります。iPhoneアプリではルーティンの編集・履歴閲覧・テスト・削除ができず、デスクトップアプリが必要です。

複数Botの連携

新規チャットで2〜6体のBotを選ぶとグループチャットになります。Bot同士は非同期でメッセージを送り合え、受け取ったBotが起きて処理し、後で返事をします。公式の起動例はこうです。

@Researcher 出典となる資料を集め、すべての主張にリンクを付けてください。
@Writer 調査結果をローンチ用の原稿にしてください。
@Reviewer 原稿を出典と突き合わせ、公開を止めるべき問題だけを列挙してください。
何も公開しないでください。

「最後の1行」が承認境界です。Bot間のグループ内での引き継ぎは現時点ではテキストのみで、画像を見せたい場合はBot同士のダイレクトメッセージで直接送る必要があると公式が注記しています。

承認の仕組み — 人がどこで止めるか

Grok Botの設計思想は「仕事を最後までやり、承認が必要なときだけ戻ってくる」です。そのため、どこで止まるかを人が設計することが導入の中心になります。

公式ドキュメントが「承認を要求すべき操作」として挙げているのは次の7種類です。

境界は依頼文に書きます。公式の例文は「キャンペーンデータを突き合わせ、推奨する予算変更の案を作ってください。キャンペーンを変更したり代理店に連絡したりしないでください。現在値・提案値・想定される影響を示したうえで承認を求めてください」という形です。最初の依頼を書くときの型として、公式は「成果(Outcome)/情報源(Sources)/制約(Constraints)/納品物(Deliverable)/確認ポイント(Review point)」の5要素を挙げています。

承認のUIはデスクトップで「1回だけ許可(Allow once)」「拒否(Deny)」、そして「常に許可(Always allow)」で同種の操作を恒久的に許可するルールを保存できます。設定の「Auto-review」で「承認必須(Require Approval)」と「常に許可(Always Allow)」のルールを管理し、両方に当てはまる場合は承認必須が勝ちます。ただしこの自動審査はモデルによる判定で、公式自身が「最小権限の代替にはならない」と注記しています。ルールはそのデスクトップ端末に保存されてクラウドPCに同期されるだけなので、別のPCからは引き継がれません。

押さえておくべき原則が2つあります。承認は「提案された操作」を止めるものであり、完了してしまった作業を巻き戻す機能ではないこと。そして、作業を即時に止める「Stop now」も、すでに実行された操作を取り消すわけではないことです。作業の途中に人の確認を挟むヒューマンインザループの設計は、どこまでを承認必須にするかを自社で決めて初めて機能します。通知は、Botごとの設定で「完了したとき・入力が必要なとき」にOS通知やモバイル通知を受け取れます(モバイルのプッシュ通知は段階的に有効化中)。

何に使うのか — 既成ロールは営業・マーケ・バックオフィス

ドキュメントには8種類の既成ロールが、製品サイトには9カテゴリ54種類のロール案が掲載されています。まず8種類です。

営業アウトバウンドの公式スタートプロンプトは「このCRMビューにある25社を調査し、理想顧客像(ICP)と直近の購買意向で採点してください。レビュー用のリストを返し、誰にも送信・登録しないでください」というものです。xAI社内の実例として紹介されているのは、営業Botが夜間にターゲット企業を調査し、コンタクト先に優先順位を付け、営業担当者の文体でメールとLinkedIn投稿の下書きを作っておく、という使い方です。人が朝出社すると下書きができている、という運用で、営業・マーケティングの実行工程をエージェントに移すAgentic GTMの考え方をそのまま製品にした形といえます。

54種類のロール案は、カスタマーサクセス(チケットの一次仕分け、アカウントマネージャー)、営業(商談準備、CRM運用、更新デスク、パイプライン分析)、マーケティング(競合調査、LinkedInキャンペーン、SEO/AEO監査、ニュースレター執筆)、オペレーション・財務(契約デスク、請求書調整、セキュリティ質問票の記入、APIのないベンダーポータルの操作)、人事(日程調整、採用スクリーニング、オンボーディング)、一般(受信箱管理、日次ブリーフィング、ステータスレポート作成)などに分かれます。共通しているのは「監視して、下書きを作り、送信は人の承認の後ろに置く」という設計で、たとえば受信箱管理ロールの説明文は「すべての送信はあなたの承認の後ろに留まる」です。通話記録からのCRM更新のような記録系の定型作業、顧客の利用状況の監視も向いています。

適性の目安はこうなります。向いているのは、APIが用意されていない社内ポータルやベンダー管理画面の操作、そして夜間の調査・下書きづくりのような、人のレビューを前提とした内部作業です。逆に、顧客に直接触れる作業(問い合わせ対応の自動返信など)は、後述する監査・テスト機能の不足からまだ勧められていません。公式文書と初週の利用者報告をもとにしたeesel AIの評価(実機テストなしと明記)でも、「APIのないツールの自動化」は10点中8点、「下書き型の知識労働」は7点、「サポート対応」は4点、「規制業種」は3点と、同じ方向の採点になっています。

なお「画面を操作して定型作業を自動化する」という説明はRPAと重なりますが、仕組みが違います。RPAは記録した操作手順の再生なのでレイアウト変更に弱いのに対し、Grok Botは視覚モデルで画面を理解して操作するため変化に比較的追従しやすいとされています。ただし画面操作依存の脆さが完全に消えるわけではなく、公式も「サイト・コネクタ・データの形式が変わるとルーティンが壊れることがあるので再テストを」と明記しています。RPA側の費用対効果の考え方はRPAのROI計算で解説しています。

料金 — 席料+週次の使用枠+従量課金

料金体系は「単純な月額」ではありません。プランに含まれる席料のほかに、使用量の枠と従量課金が乗る三層構造です。

使用量の仕組みは次の通りです。

• 計測単位はメッセージ数ではなく「エージェントのステップ数とトークン数」。1つの依頼でも、Botが何手も操作すれば多く消費する
• 週ごとにリセットされる使用枠が付く。ただし枠の具体的な量は非公開
• 枠を使い切ると、アカウントの従量課金(on-demand)が有効ならモデルとトークンの原価ベースで続行できる
• Grok Bot専用の支出上限はまだない(アカウント全体の従量課金の上限設定は効く)
• モデルは選べない。安いモデルに切り替えて節約する、という手が使えない
• macOSとiOSは同じ使用枠を共有する
• 無料トライアルは日数ではなく使用量クレジット制で、7日の期限も併存。長時間のタスク1つで使い切ることがあり、補充されない

初期利用者からは「今月だけで過去5年分より多くのトークンを使った」(Hacker Newsの1か月利用者)という報告があり、常駐して何手も操作するエージェントは従来のチャット利用とは消費の桁が違うことがうかがえます。他社の同種製品では、Devinが「1ACU(約15分の稼働)=2〜2.25ドル」、MicrosoftのCopilot Studioの画面操作エージェントが「1ステップ=5クレジット(約0.04ドル)」のように単価と枠を公表しているのに対し、Grok Botは週間枠の量も超過単価も非公開です。AI利用料の管理の考え方はAIコストの管理で解説しています。

SuperGrok Heavy連携の落とし穴も押さえておくべきです。Heavyに加入していてGrokアカウントを連携すると0ドルのCursor Ultraが作られますが、このときStripe課金のCursor ProやPro+を契約していると、そのプランは解約されて置き換わり、後でHeavyをやめても元のプランは自動では戻りません。Apple課金のPro/Pro+やチームアカウントは連携の対象外です。連携ボタンはログイン前のペイウォール画面にしか表示されないため、すでにログイン済みならアプリの完全再起動が必要になります。

なぜCursorのプランなのか — 2026年の企業再編

xAIの製品なのに契約がCursorのプランに紐づいているのは、2026年の一連の再編の結果です。

Grok BotはCursorのインフラの上で動いており、アプリの配布・ログイン・課金はすべてCursorアカウント経由です(Grok Bot専用のログインは存在しない)。iPhoneアプリの販売元もxAIではなくAnysphere社になっています。発売が買収成立の3日前だったこともあり、認証情報の扱い・データ保持・学習への利用可否といった規約はGrok Bot独自のものではなく「Cursorの規約と設定に従う」と書かれています。早期ベータのため、プラン構成・価格は今後変わる可能性があります。

競合比較 — Claude Cowork・ChatGPT Work・Copilot Coworkとの違い

2026年に入り、各社が「常駐して作業を完了させるエージェント」を相次いで出しています。違いは「どこで動くか」と「どうやってツールにつなぐか」の2軸で整理できます。

比較の軸で見ると、Grok Botの位置づけは次のようになります。「クラウドに常駐する」点はClaude Coworkのリモートセッション、Copilot Cowork、Devinなども同じですが、「全Botが1台を共有する」と公式に明記しているのはGrok Botだけです。ログイン情報については、他社がコネクタのOAuth(Cowork・ChatGPT Work・Copilot)か本人のブラウザのセッション(Coworkローカル版)を使うのに対し、Grok Botは「Botが本人としてサインインし、セッションを全Botで共有する」方式で、これがAPIのないツールに入れる強みと、後述するセキュリティ上の注意点の両方の源泉です。承認については、OpenAI・Google・Microsoftが「重大な操作の前に確認する」ことを製品仕様として明文化しているのに対し、Grok Botは「常に許可」で恒久的に許可でき、自動審査はモデル判定という設計です。料金は、Grok Botだけが「席料+枠の量が非公開の従量」という構造です。

同じ週にSlackが発表したSlack Code(AIコーディングエージェントをチームの承認下に置く機能)も含め、2026年夏の各社の動きは「AIに実務を渡し、人は確認と承認に回る」という一つの方向に揃っています。

セキュリティ — 「Botは安全境界ではない」の意味

公式ドキュメントは承認のページとFAQの2箇所で「Do not use separate Bots as a security boundary.(Botを分けることを安全境界として使わないでください)」と書いています。具体的に何が起きるかを整理します。

• 共有の中身: ブラウザのログイン状態、/workspace のファイル、コマンドラインの認証情報が全Botで共有される。Bot AがログインしたサービスにBot Bがアクセスすると、再認証なしでログイン済みの状態になる(発売後、利用者からBot別のブラウザプロファイルと「どのBotがどのセッションを使ったか」のログを求める要望が公式フォーラムに出ている)
• 削除しても残る: Botを削除しても、共有PC上のファイルとブラウザセッションは残る。完全にアクセスを断つ公式手順は6段階で、①関連ルーティンの停止・削除 ②共有PC上のWebサイトからのログアウト ③コネクタのアンインストールと提供元サービスでの認可取り消し ④/workspace 内の機密ファイル削除 ⑤Botの非表示・削除 ⑥必要ならCursorアカウントの削除
• 認証情報の渡し方: パスワード・パスキー・2段階認証・CAPTCHA・決済確認は人がクラウドPCを直接操作して入力する。対応する接続では「セキュアシークレット要求」という専用の入力欄があり、値はマスクされ、会話記録から除外され、モデルには見えない。通常のチャットにパスワードを書かない
• 名義の問題: Botの操作は、各サービス側のログには「ログインした人間」の操作として記録される。後から「AIの操作か人の操作か」を区別しにくい
• 学習への利用: 学習利用のオプトアウトは「Cursorアカウントのプライバシー設定に従う」。Grok Botはクラウドへのデータ保存が必須で、Cursorの旧プライバシーモード(Legacy Privacy Mode)では使えない
• 管理機能の現状: SSOはCursorの設定がそのまま適用される。組織管理者はメンバーのクラウドPCを点検・削除できる。一方で、Botの操作を一覧する監査ビューは「提供予定」、Grok Bot専用の支出上限も「まだない」、クラウドPCはMDM(端末管理)に登録されず、Okta FastPassのような端末認証は使えない。SOC 2やISO 27001などの認証について、Grok Botのページに記載はなく、参照先のCursorのセキュリティページに「SOC 2 Type IIの報告書を要求に応じて提供」とあるのみ

なぜこの構造に注意が要るのかは、Simon Willison氏が2025年6月に整理した「致命的な三要素(lethal trifecta)」で説明できます。AIエージェントが①私的なデータにアクセスでき、②信頼できない外部コンテンツ(Webページ・メール・チケットの本文など)を読み、③外部に情報を送信できる、という3条件が揃うと、外部コンテンツに仕込まれた指示(プロンプトインジェクション)でデータを持ち出される経路ができる、という枠組みです。Grok Botは設計上この3条件をすべて満たします。これはGrok Botに限らず「人としてログインして画面を操作する」タイプのエージェントに共通する構造で、だからこそ「どのアカウントを渡すか」「どの操作に承認を必須にするか」を先に決める必要があります。

参考として、同じxAIの開発者向けCLI「Grok Build」では2026年7月に、Gitリポジトリ全体(履歴や設定ファイルを含む)が外部ストレージに送信されていたことが研究者の指摘で判明し、翌日にサーバー側で停止された経緯があります。Grok Botとは別製品ですが、認証情報や機密ファイルをエージェントの作業環境に置く際の線引きを、ベンダー任せにしない理由にはなります。ルールづくりの枠組みは生成AI利用ガイドラインの作り方を参照してください。

発売後10日間に報告された不具合と初期レビュー

早期ベータの実態を知るうえで、公式フォーラムに記録された不具合と、実際に使った人の報告は参考になります。

実際に使った人の報告としては、次のようなものがあります。

• ゲーム開発者が自作の画像生成ツールをBotに操作させ、74点のゲーム用素材を約2時間で生成・透過処理・組み込みまで完了させた例。同時に「最初は少し遅い」「メール購読の解約を一部取りこぼした」という失敗も報告
• AI起業家が数週間テストし「一般の人が初めてエージェントを使うきっかけになり得る」と評価する一方、モデルが選べず自動選択の精度が悪かった(後に改善されたと聞いた)と指摘
• 約8時間で12体のBot(参謀役・顧客調査・旅行計画など)を構築したニュースレター著者が、複数エージェントの連携を「消費者向けアプリで初めて実感できた」と肯定的に評価
• Hacker Newsでは、海外の仕入先選定と価格交渉に成功した1か月利用者が「今月だけで過去5年分より多くのトークンを使った」と報告。データをxAIに預けることへの抵抗感やプロンプトインジェクションへの懸念も並行して議論された

共通するのは、「APIのないツールをまたいで仕事を完了させる」という中核の価値は早期から実証されている一方で、認証の安定性・モバイルアプリの品質・費用の予見可能性はまだベータ水準、という評価です。

導入の進め方 — 最初の2週間の設計

以上を踏まえると、試す価値はあるが「何を渡すか」を先に決めるべき製品です。実務での進め方を手順にします。

1. 対象業務を3条件で選ぶ。 ①失敗しても取り消せる(下書き・調査・一覧作成) ②APIや連携機能がなく人が画面操作している ③成果物を人がレビューする工程が既にある。最初の候補は「夜間の見込み客調査→優先順位つきリストと文面の下書き」「ベンダーポータルからの請求情報の転記」「週次レポートの材料集め」あたりです
2. 渡すアカウントを決める。 全Botがログインを共有する前提で、「このクラウドPCにログインしてよいサービス」を列挙します。本番の管理者権限、決済権限、顧客データの一括エクスポート権限を持つアカウントは最初の2週間は渡さない、と決めておくのが安全です。可能なら業務用の専用アカウントを用意します
3. 依頼文に承認境界を書く。 公式の5要素(成果・情報源・制約・納品物・確認ポイント)で書き、「送信・登録・削除・購入はしない。レビュー用のリストを返す」を毎回入れます。「常に許可」は最初は使いません
4. ルーティン化は手動で3回成功してから。 テスト実行も本番で動くため、手動で結果を確認できた作業だけをスケジュール化します。時間帯(タイムゾーン設定)と、情報源が見つからなかったときの挙動を指定します
5. 費用を週次で確認する。 使用枠は週ごとにリセットされ、Grok Bot専用の上限がないため、設定画面の週間使用量と従量課金の有無を週1回は見ます。初月は「席料の2倍まで」のような社内上限を決めておくと稟議が通しやすくなります
6. 撤退手順を先に書く。 Botを消しても残るものがある前提で、前述の6段階(ルーティン停止→ログアウト→認可取り消し→ファイル削除→Bot削除→アカウント削除)を手順書にしておきます

依頼文の型は、たとえば次のようになります。

成果: 展示会の名刺リスト80件を調査し、自社の理想顧客像に合う順に並べる
情報源: 添付のCSV、各社の公式サイト、プレスリリース
制約: メール・LinkedInでの連絡は一切しない。CRMへの登録もしない
納品物: 会社名・優先度(高/中/低)・根拠1行・下書き文面のスプレッドシート
確認ポイント: 完成したら私に知らせる。途中で判断に迷ったら止まって聞く

この「生成と確認を分け、人の承認を関所にする」設計は、AIに作業を任せるときの一般原則でもあります。仕組みとしての考え方は自己修正ループで解説しています。

よくある誤解

1. 「自分のPCをAIが操作する」→ 違います。 Botはクラウド上の作業用PCで作業します。人のPCは占有されず、人が寝ている間も作業が進むのはこのためです。手元のPCでの実行は別機能で、既定は「毎回確認」です。
2. 「Botごとに独立した環境で安全に分かれている」→ 分かれていません。 画面は別でも、ログイン・ファイル・認証情報は1台のPC上で共有されます。営業Botと経理Botを分けても、アクセスできる範囲は同じです。
3. 「月200ドルの定額で使い放題」→ 定額ではありません。 週次の使用枠を超えると従量課金になり、枠の量は非公開、Grok Bot専用の上限もまだありません。
4. 「放っておけば全部やってくれる」→ 現時点では下書き・調査・記録系が主戦場です。 顧客に直接届く操作を任せるには、テスト環境や監査ログなどの統制機能がまだ足りません。
5. 「チャットボットの延長」→ 製品の性格が違います。 質問への回答ではなく作業の完遂が目的で、設計の中心は「どこで人が止めるか」にあります。

Grok Botは「AIチームメイト」という完成形を最も具体的に見せた製品である一方、統制まわりは発展途上の早期ベータです。試すこと自体は難しくありませんが、ログイン情報を渡すことになるため、どの業務のどのアカウントまで渡してよいかを先に決めてから始めてください。