Grok Botとは？料金・対応OS・できること・OpenClaw/Claude Coworkとの違い【2026年8月最新】

Grok Botは、SpaceXAI（旧xAI）が2026年8月11日に早期ベータ提供を開始した、クラウド上の専用コンピュータを持つAIエージェント製品です。 ブラウザやアプリを人間と同じようにUI操作し、既存の業務ツールにサインインして仕事を最後まで仕上げるという設計で、利用にはSuperGrok Heavy（約$300/月）またはCursor Ultra（$200/月）以上のプランが必要です。

2026年8月13日時点のGrok Botは、機能は先進的である一方、運用ガバナンスの部品がまだ足りていない段階にあります。理由は明確で、公式ドキュメント上で監査ログが未実装、Grok Bot固有の支出上限（spend cap）が未実装、そしてアカウント内の全Botが1台のクラウドコンピュータと全ログイン情報を共有すると明記されているためです。個人・小規模チームの隔離された低リスク業務から試し、機微データを扱う本番業務は次のアップデートを待つ、というのが現実的な判断になります。

この記事でわかること:

• Grok Botの定義と、通常のGrokチャットとの決定的な違い
• 料金の実際（対象プラン3つ・週次使用量＋従量課金の二層構造）
• 対応OS（公式ドキュメントと報道で情報が割れている点を含む）
• できること／できないこと・数値上の制約一覧
• セキュリティとガバナンス上の論点、公式推奨の安全設定
• Claude Cowork・OpenClaw・Copilot Coworkとの選び分け

業務にAIエージェントを導入するか判断したい情報システム部門・事業部門の担当者、および高額プランへの課金可否を検討している個人ユーザーに向けて、2026年8月13日時点で公式サイト・公式ドキュメント・報道から確認できた範囲に絞って整理しています。仕様は早期ベータのため短期間で変わる可能性があります。

Grok Botとは何か

Grok Botは、「自分専用のクラウドコンピュータを持ち、既存の業務ツールにサインインして仕事を最後まで仕上げるAIチームメイト」として公式に説明されている製品です。 公式ページ（x.ai/bot）では "AI teammates you can give real work to"、つまり実務そのものを渡せる同僚という位置付けで紹介されています。

出典: xAI 公式ドキュメント（docs.x.ai）

基本情報は次の通りです。

注意点として、Grok Botが内部で使っているモデル名は公式に明示されていません。 一部報道ではGrok 4.5系との推測がありますが、公式ドキュメントに記載はないため、本記事では断定しません。モデル世代の話はGrok 5とは、Grok本体のプランや機能についてはGrokとはで整理しています。

なぜxAIのエージェントがCursorのプランで売られているのか

Grok Botの料金表を見て「なぜCursorのプラン名が出てくるのか」と戸惑う人が多いはずです。理由は資本関係にあります。2026年6月、SpaceXがCursorの親会社Anysphereを600億ドル・全株式交換で買収し、両社は統合されました。 Grok Botは統合後に初めて発表されたエージェント製品であり、そのためSpaceXAI側のSuperGrok Heavyと、Cursor側のUltra／Teams Premiumの双方から利用できる形になっています。

この買収の経緯と統合後のプロダクト戦略はCursor × SpaceX 600億ドル買収で詳しく扱っています。開発者向けCLIエージェントであるGrok Buildも同じ系列の製品で、Grok Botは「非エンジニア業務も含めたオフィス作業側」を担当する位置付けです。

通常のGrokとの違い

最大の違いは「回答を返すのか、成果物を返すのか」です。 通常のGrokはテキストで答えるチャットですが、Grok Botはクラウド上の実マシンで実際にブラウザやアプリを操作し、作業を完了させます。

特に実務上のインパクトが大きいのは、API連携やMCPが用意されていないサービスでも、ログインできれば原則操作できるという点です。社内で使っている古い基幹システムやニッチなSaaSは、たいていAPIが公開されていないか有償オプション扱いです。Grok Botはそこを「人間と同じ画面操作」で埋めます。ブラウザ操作型エージェントの技術的な位置付けはClaude Computer Useとはでも解説しています。

アーキテクチャ：全Botが1台のクラウドPCを共有する

出典: xAI 公式ドキュメント Grok Bot Overview

Grok Botの仕組みを理解する上で最も重要なのは、「アカウントごとに1台の永続クラウドコンピュータが割り当てられ、その1台をアカウント内の全Botが共有する」という構造です。 ここを誤解すると、権限分離の設計を根本から間違えます。

公式ドキュメント記載の構造は次の通りです。

• 各アカウントに管理型のLinux仮想マシンが1台割り当てられる（非rootユーザーで実行）
• そのVM上にブラウザ・ファイルシステム・ターミナルが用意される
• Botごとに個別のスクリーン（画面）を持ち、並列で稼働できる
• ただしログイン情報・ブラウザセッション・ファイルは全Bot間で共有される
• 1体のBotは同時に1タスクずつ処理（Bot単位では直列、Bot間では並列）
• チーム／エンタープライズでは「メンバー1人につき専用クラウドコンピュータ1台」

つまり「Botを分ければ権限も分かれる」わけではありません。公式FAQも "do not use multiple Bots as a security boundary"（複数のBotをセキュリティ境界として使わないこと） と明記しています。リサーチ用Botが、経理用Botのログイン済みセッションに触れられる構造だと理解しておく必要があります。

なお、ユーザーは「Agent Computer」画面でBotのクリックやページ遷移をリアルタイムに観察でき、途中で操作を引き取ることもできます。複数エージェントが分担して働く仕組み全般はマルチエージェントAIとはで整理しています。

Grok Botでできること

Grok Botの機能は、大きく5つに整理できます。

出典: xAI 公式ドキュメント Tools Overview

1. クラウドコンピュータの操作（Computer Use）

ブラウザでWebサイトを開く、アプリを起動する、ファイルを保存・整形する、コマンドラインを実行する、スクリーンショットを取る、といった操作を自律的に行います。ブラウザセッションは永続化されるため、一度サインインすればタスクごとに再ログインする必要は基本的にありません。

公式は同時に「コネクタが用意されているサービスでは、そちらを優先せよ」とも案内しています（"Prefer a connector when one is available: it is often more reliable than clicking through a website."）。UI操作は万能ですが、Web画面のレイアウト変更に弱いためです。

2. 名前付きBot（役割を持たせたAIチームメイト）

Grok Botでは、職務を明確にしたBotを作ることが公式に推奨されています。公式が挙げる良い例は Talent Scout（採用ソーシング）／Expense Manager（経費処理）／Bug Reproduction（バグ再現） のように役割が具体的なもので、悪い例として General Helper（何でも屋） が名指しされています。職務が曖昧だと指針が弱くなり、蓄積した文脈を再利用しにくくなるためです。

Botはメモリを持ち、作業の好みや重要事実、業務のサマリーを保持します。ただし公式は "Memory is not a substitute for an authoritative source"（メモリは正となる情報源の代わりにはならない） とも明記しており、頻繁に変わる情報は元システムに置いたままにすべきとしています。

3. グループチャットによるBot同士の協調

複数のBotを1つのグループチャットに参加させると、Bot同士が自律的に調整し、作業を受け渡し、担当を割り当てます。1体のマネージャーBotが全体を統括し、専門Botが個別タスクを処理する構成も可能です。人間が呼び出されるのは、判断や承認が必要になったタイミングだけ、という設計になっています。

4. Skills（スキル）とRoutines（ルーチン）

Skillsは、手順・ルール・出力形式・安全境界を含む再利用可能な指示セットで、Bot間で共有できます（ただしコネクタや認証情報は別途必要）。作り方は2通りです。

1. 文章で手順を指示し、Botにスキルとして保存させる
2. Teach by demonstration（実演で教える） — ブラウザ操作を実際に見せて覚えさせる

実演学習には制約があり、記録できるのは最大10分・単一ワークフローまでです。しかも学習結果はドラフト扱いで、公式も「ルールとエラー処理を追記する必要がある」としています。RPAのような「録って終わり」ではない点は認識しておくべきです。

Routinesは自動実行の仕組みで、時刻＋タイムゾーンを指定したスケジュール実行と、SlackメッセージやGitHub通知などをきっかけにするイベントトリガー実行の2種類があります。

5. コネクタ／MCP／ファイル成果物

設定画面には「Plugins」として構造化された連携先が表示され、チャットで @ を入力してタスクに付与します。連携先としてNotion・Slack・GitHubのほか、多数のMCPサーバーが挙げられています。

生成物はカード形式で表示され、プレビュー・編集・ダウンロードが可能です。対応形式は画像、PDF、Word、Excel、CSV、JSON、ソースコード、Jupyter Notebookなど。共有ワークスペース /workspace に保存されたファイルは他のBotからも読めます（一時ディレクトリは揮発扱い）。

業務別のユースケース

公式および報道で挙がっている、SpaceX社内テストを含むユースケースを整理します。

いずれも「読み取りと下書き作成までをBotに任せ、送信・確定は人間が承認する」形が現実的です。

料金と利用条件

出典: Cursor 公式サイト

Grok Bot単体のサブスクリプションは存在しません。 現時点では以下3つの上位プランにバンドルされる形で提供され、追加料金なしでベータを利用できます。

※SuperGrok Heavyの$300/月は、複数の第三者価格情報が一致している値で、公式価格ページ上での直接確認は取れていません。課金前に必ず公式で確認してください。Cursorのプラン体系についてはCursorとはも参考になります。

見落としやすい「二層構造」の課金

固定費だけを見て予算を立てると、想定外の請求になる可能性があります。Grok Botの課金は次の二層です。

1. 各プランに含まれる週単位（weekly）のGrok Bot使用量
2. それを超えた分のオンデマンド追加使用（モデル・トークンコストベースの従量課金）

そして重要なのが、公式ドキュメント（teams-and-enterprises）に 「現在、Grok Bot固有の支出上限（spend cap）設定は未実装」 と明記されている点です。つまり、ルーチンが暴走したり、Botが想定外に長時間ブラウザを操作し続けたりしても、製品側で自動的に止める上限が設定できません。使用量とコストはCursorダッシュボードのusageページで製品別に確認できるため、当面は「毎日目視で確認する」運用が必要です。

なお、プランに含まれる週次使用量の具体的な数値（何時間・何タスク相当か）は公式に公表されていません。ここが読めない以上、初月は少数のBotと少数のルーチンだけで走らせ、実消費を測ってから拡大するのが安全です。

対応OS（情報が割れている点に注意）

公式ドキュメント基準では、macOS（Apple silicon／Intel）、Windows（x64／Arm64）、iPhone（iOS 18以降）の3環境です。 ただし、対応OSは情報源によって記載が食い違っているため、そのまま鵜呑みにしないでください。

Linuxについては、公式のget-startedページとFAQがいずれも「非対応」と記載している一方、日本語・英語の複数メディアが .deb パッケージの提供に言及しています。早期ベータ期間中に配信対象が変わった可能性がありますが、現時点では公式ドキュメントの記載を優先し、Linux運用を前提とした導入計画は立てないほうが安全です。 Android・iPad・チーム向け監査ログは、公式が「今後対応予定」としています。

数値上の制約一覧

早期ベータ特有の上限が複数あります。導入設計の前に把握しておくべき数値をまとめます。

特に「ルーチンの実行履歴が直近20件のみ」は運用上効いてきます。1日3回動かすルーチンなら、1週間前の実行結果はもう追えません。監査ログが未実装であることと合わせると、現時点では実行証跡を製品内で長期保全できないという前提で使う必要があります。

Grok Botができないこと・弱み

便利さの裏側で、公式が明記している「できないこと」も多い製品です。 導入判断ではこちらのほうが重要です。

Legacy Privacy Modeが使えないという制約は、日本企業の情報システム部門の審査で最大の論点になり得ます。Grok Botは「データが提供元クラウドに保存されること」が前提の製品であり、データを外部に置けない業務では選択肢に入りません。この観点の整理は生成AIセキュリティやシャドーAIの企業リスクも参考にしてください。

セキュリティとガバナンス：導入前に必ず理解すべき論点

Grok Botのリスクは「AIが間違える」ことよりも、「認証済みの状態で常時稼働している環境が1つしかない」というアーキテクチャに起因します。

出典: xAI 公式ドキュメント Security FAQ

1. 共有クラウドPCという構造的リスク

アカウント内の全Botが1台のVMとすべてのログインセッションを共有する設計は、実務上こういう意味を持ちます。

• 業務ごとにBotを分けても、権限は分離されない
• 1体のBotが不正な指示に従った場合、他のBotがサインインしたサービスにも到達し得る
• ファイルも /workspace 経由で相互に読める

対策は「Botを分ける」ではなく「そもそも危険な認証情報をこの環境にサインインさせない」という方向にしかありません。

2. プロンプトインジェクション

Webページや文書に埋め込まれた指示が、認証済みのエージェントを不正な操作へ誘導するリスクは、ブラウザ操作型エージェント共通の課題です。公開資料の範囲では、Auto Review機能が「ユーザーからの正当な指示」と「非信頼コンテンツに埋め込まれた指示」をどう区別するのかの説明は見当たりません。

参考事例として、2026年5月にX上でモールス符号に悪意ある指示を埋め込まれ、Grokが自身のウォレットから約17.5万ドル相当の送金を承認した事案が報告されています（後に回収）。「データとして翻訳すべき対象」と解釈させることで、命令としての精査を回避された形です。提供元をめぐる安全性の議論はxAI Grok 安全性訴訟でも扱っています。

3. 承認は「巻き戻し」ではない

公式が明記している重要な注意点として、承認機能は「これから実行される提案」を制御するものであり、すでに完了した作業を取り消すものではありません。 メール送信・投稿公開・購入や資金移動といった不可逆な操作は、実行後には戻せません。エージェントによる不可逆操作の事故事例はAIエージェントによるデータ削除事故にまとめています。

4. 公式推奨の安全設定（実践手順）

公式が示すリスク軽減方針を、実際の設定手順に落とすと次のようになります。

1. 読み取り専用タスクから始める — 最初の2週間は「調べる・まとめる・下書きする」までに限定する
2. 接続するツールを絞る — 必要なコネクタだけを有効化し、決済・人事・顧客個人情報を扱うサービスにはサインインさせない
3. Auto Reviewのルールは狭く具体的に書く — 「ブラウザ内は全部許可」のような広範ルールは公式も明確に非推奨。「特定ドメインの特定操作のみ許可」に留める
4. 書き込み・送信は必ず承認ゲートの後ろに置く — メッセージ送信、コンテンツ公開、購入・資金移動は Require Approval ルールを設定する
5. シークレットをチャットに直接入力しない — パスワード・2FAコード・決済確認は、サポートされた接続の secure secret request フォームを使う（値はマスクされ、トランスクリプトから除外され、モデルにも渡されない）
6. ルーチンは有効化前に必ず手動で1回テストする — イベントトリガーは狭いマッチング条件にする
7. ローカルPC操作は「常に承認要求」のままにする — デフォルトが毎回確認になっているので、安易に「常に許可」へ変更しない
8. usageページを毎日確認する — 支出上限が未実装のため、目視が唯一のブレーキになる

エージェント全般の安全運用の考え方はAIエージェント セキュリティで体系的に整理しています。

Claude Cowork・OpenClaw・Copilot Coworkとの違い

Grok Botの立ち位置は「提供元クラウドで常時稼働し、APIがないサービスにもUI操作で入り込む、ハイエンド価格帯のエージェント」です。 競合と比べると設計思想の違いがはっきりします。

出典: Anthropic 公式サイト

選び分けの基準

• APIのないSaaSや社内Webシステムを自動化したい → Grok Bot。UI操作で入り込めるのは現時点で明確な優位点
• 手元のファイルを整理・作成させたい／データを外に出したくない → Claude Cowork。ローカル実行が前提で、非エンジニアでも扱いやすい
• コストを抑えつつ常時稼働させたい／自分で全部管理したい → OpenClaw。本体は無料だが設定を誤ったときの被害範囲が大きく、OpenClawの危険性を理解した上で使う必要がある
• Microsoft 365で業務が完結している → Copilot Cowork。統制と監査の面では最も企業向け
• クラウド常時稼働型を他社製品とも比べたい → Manusなども選択肢。全体像はAIエージェント おすすめ比較で整理しています

エージェントという製品カテゴリ自体をこれから理解する場合は、AIエージェントとはから読むと前提が揃います。

使い始めの流れ

早期ベータ時点での基本的な導入手順は次の通りです。

1. 対象プラン（SuperGrok Heavy／Cursor Ultra／Cursor Teams Premium）に加入する
2. macOSまたはWindowsのデスクトップアプリ、あるいはiOSアプリをインストールする
3. プライバシー設定を確認する（Legacy Privacy Modeのままでは起動できないため、対応設定へ切り替える）
4. 役割を明確にしたBotを1体だけ作る（例:「週次レポート作成」）
5. 必要最小限のコネクタのみ接続し、まず読み取り専用のタスクを与える
6. Agent Computer画面で実際の操作を観察し、挙動を把握する
7. 定型化できたらSkillとして保存し、テスト後にRoutineへ登録する
8. usageページで消費量を毎日確認し、想定内なら対象業務を広げる

最初から複数Botとグループチャットを組むより、1体で1業務を安定させてから増やすほうが、コストも事故も抑えられます。

こんな人・企業におすすめ

以下に当てはまるなら、早期ベータでも試す価値があります。

• APIやMCPが提供されていない業務ツールを日常的に使っている — UI操作で入り込める点は代替が効きにくい
• すでにSuperGrok HeavyまたはCursor Ultraに加入している — 追加料金なしでベータを試せる
• 夜間・休日に走らせたい定型業務がある — 端末を閉じても継続する常時稼働型が効く
• 調査・下書き作成など、失敗しても巻き戻せる業務が中心 — 承認が「巻き戻し」ではない以上、可逆な業務から始めるのが定石
• 新しいエージェント製品を検証する役割の担当者 — 統合後のSpaceXAI製品群の方向性を掴む意味は大きい

おすすめしない人・企業

逆に、次の条件に1つでも当てはまるなら、現時点での本番導入は見送りを推奨します。

• 顧客情報・医療情報・決済情報など、機微データを扱う業務 — データが提供元クラウドに保存されることが前提で、Legacy Privacy Modeも使えない
• 監査ログの提出が求められる規制業種 — チーム向け監査ログが未実装。ルーチン履歴も直近20件のみ
• AI関連費用に厳格な上限管理が必要な組織 — Grok Bot固有の支出上限が未実装で、従量課金を製品側で止められない
• 月$200〜$300の固定費を正当化できる業務量がない個人 — 週次使用量の内訳も非公表のため、費用対効果を事前に読みにくい
• Linux中心の環境 — 公式ドキュメント上は非対応
• Android／iPadから使いたい — 初回リリース時点で非対応
• 「Botごとに権限を分ける」前提の設計をしたい組織 — 共有VMのため、その設計はそもそも成立しない

導入判断の目安

よくある質問（FAQ）

Q. 日本語で使えますか？ 日本国内から利用できますか？
公式に日本語UIの提供や国内提供可否の明記は確認できていません。Grokシリーズ自体は日本語入力に対応していますが、Grok Botの提供地域・言語対応については公式の案内を確認してください。

Q. RPAとは何が違いますか？
RPAは「記録した操作を再生する」仕組みで、画面レイアウトが変わると壊れます。Grok Botは目的を与えると自分で画面を見て判断するため、多少の変更には追従できます。一方でRPAのような決定的な再現性はなく、同じ指示でも毎回まったく同じ手順を踏むとは限りません。厳密な再現性が要件なら、RPAのほうが適しています。

Q. Botを削除するとデータはどうなりますか？
Botを削除すると、そのBotのプロフィール・会話・ルーチンが消えます。ただしファイルとサインイン状態はBot間で共有されているため、クラウドコンピュータ側には残ります。Bot削除は認証情報の削除ではない点に注意してください。

Q. 複数人のチームで使う場合、コンピュータは共有されますか？
チーム／エンタープライズでは「メンバー1人につき専用クラウドコンピュータ1台」が割り当てられます。メンバー間では分離されますが、同一メンバーのBot同士は分離されません。

Q. Botが途中で止まったときはどうなりますか？
ログイン・2要素認証・CAPTCHA・決済確認など、Botが自力で越えられない場面では、ユーザーにコンピュータの操作が引き渡されます。裏を返すと、完全に無人で完結する業務は限られます。 夜間実行のルーチンを組む場合は、認証が発生しない範囲に設計するのが現実的です。

Q. どのモデルが使われていますか？ 安いモデルに切り替えられますか？
使用モデルは公式に明示されていません。またモデルを指定してコストを抑えるルーティング設定についても、公式ドキュメントに記載は確認できていません。コスト管理は「タスク量そのものを絞る」方向で行うことになります。

Q. 早期ベータはいつ一般提供になりますか？
公式に時期の明示はありません。今後の予定として、Android対応・iPad対応・チーム向け監査ログ・エンタープライズ版（ウェイトリスト制）が挙げられています。

まとめ

2026年8月13日時点のGrok Botは、「APIがないサービスにもUI操作で入り込み、クラウド上で常時稼働する」という点で明確な独自性を持つ一方、監査ログ・支出上限・権限分離という運用の土台がまだ揃っていない製品です。

導入を検討するなら、判断の材料は料金・対応環境・セキュリティの3つに集約されます。

1. 料金 — 単体販売はなく、SuperGrok Heavy（約$300/月）／Cursor Ultra（$200/月）／Cursor Teams Premium（$120/シート/月）のいずれかが必要。加えて週次使用量を超えた分は従量課金で、製品側の支出上限は未実装
2. 対応環境 — 公式ドキュメント基準ではmacOS／Windows／iOS 18以降。Linux対応は報道と公式記載が食い違っており、Android・iPadは初回リリース時点で非対応
3. セキュリティ — 全Botが1台のクラウドPCと全ログインを共有する。公式自ら「Botをセキュリティ境界にするな」と明記しており、機微データを扱う業務には現時点では不向き

まずは可逆な業務・非機微データに限定して隔離検証し、監査ログと支出上限が実装された時点で本番導入を再評価する。これが、早期ベータ段階での最も損の少ない進め方です。エージェント製品全体の中での位置付けを確認したい場合はAIエージェントとはとAIエージェント おすすめ比較を、安全設計を詰めたい場合はAIエージェント セキュリティを続けて確認してください。