Grok Botとは？xAIのAIエージェントチームの機能や料金、使い方を解説

Grok Bot（グロック・ボット）は、xAI（現SpaceXSI）が2026年8月11日に発表した業務AIエージェント群で、ユーザーごとに1台のクラウドPCをそのユーザーの全Botで共有し、ブラウザ・ターミナル・社内アプリを横断して仕事を完結させるのが特徴です。

Xのメンション応答として知られる「@grok」とは別物で、こちらはサインインしてツールを実際に操作し、承認が必要な場面だけ戻ってくる「同僚としてのAI」の位置づけです。

2026年10月時点でCursor Premium（$30/月）以上または個人SuperGrok契約で利用可能になり、同月のアップデートではXコネクタ不要の投稿監視・Bot専用メールアドレスなどの機能追加、サポート向けIncidentWatch／IncidentSweepの社内運用事例公開など、動きが相次いでいます。

本記事では、Grok Botの定義と立ち位置、xAI製品ラインナップの中での違い、5つの差別化要素、業務領域別の委任パターン、料金プラン、実践的な使い方、Claude Cowork・ChatGPT Agent・Manusとの選び方、セキュリティと運用上の落とし穴までを、2026年10月時点の最新情報で整理します。

Grok Botとは？xAIが「同僚として渡せるAI」として設計したエージェント群

Grok Botの公式キービジュアル（出典：xAI）

Grok Bot（グロック・ボット）は、xAI（現SpaceXSI）が2026年8月11日に発表した、実際の業務を渡せる「AIチームメイト」として設計されたエージェント群です。

各ユーザーに1台のクラウドPC（Firecracker microVM）が割り当てられ、ツールにサインインしながら受信箱・アプリ・ウェブを横断して仕事を終わらせ、承認が必要なときだけユーザーに戻ってくる挙動が実装されています。1ユーザーが作る複数のBotは、この1台のクラウドPC上でブラウザ・ファイル・ログインセッションを共有し、Bot同士で作業を引き継げる構造です。

パスワードや2要素認証コードはユーザーに明示的に委ねる「Take over」設計を採る一方、ログインセッションはクラウドPC側に保持され、他のBotからも再利用できます。

この「1人1台のクラウドPC上に複数のBotが同居する」構成が、Grok Botを他のクラウド常時稼働型AIエージェントから分けるコアアーキテクチャになっています。

xAI製品ラインナップでの位置づけ

xAIが提供するGrok関連の製品群は名称が似ていて混同されやすいため、まず全体像を押さえておきます。

以下の表は、Grok Botがxやx.ai、Cursor上に展開されるGrok系サーフェスのなかでどのレイヤーを担当するかを整理したものです。

製品	役割	主な用途
@grok（Xメンション応答）	X投稿への自動返信エージェント	リプライでの事実確認・画像生成の呼び出し
Grok Chat	汎用チャットUI	対話形式での質問応答・推論・下書き作成
Grok Build	コーディング・ビルド特化面	コード生成・リポジトリ内タスクの実行
Grok Imagine	画像・動画生成	テキストから静止画／動画の生成
Grok Bot	業務エージェント群（本記事主題）	クラウドPC上でのツール横断業務の自律遂行

つまりGrok Botは、「指示を返す」寄りのChatや「ポストに答える」寄りの@grokとは分かれ、実務の多段ステップを受け持つエージェント層として独立したサーフェスになっています。

文章の下書きだけならGrok Chatで、X上の軽い質問応答なら@grokで、Cursor上のコード編集ならGrok Buildで、そしてCRM更新や受発注処理のようなツール横断業務ならGrok Botで、という棲み分けで覚えておくと混同しません。

---

Grok Botと@grok・Grok Chat・Grok Buildの違い

ここでは前セクションで整理したxAI製品群のうち、特に検索時の混同が多い@grok・Grok Chat・Grok Buildの3つに絞って、Grok Botとの差を実装・利用シーン・料金の3観点で深掘りします。

@grokとの違い

@grokとGrok Botの違いは、「公開投稿のリプライに返す」のか「サインインして実務を進める」のかという設計目的の差に集約されます。

@grokはX上のポストに「@grok」と書くと返信してくれる機能で、Grok 4.5などのGrokモデルを裏側で呼び出しています。これは広く公開情報に基づいた応答であって、閉じたビジネスツールの中で動くわけではありません。

一方のGrok Botは、デスクトップ or iOSアプリからサインインして、CRM・Gmail・Notion・Slackといった社内ツールに実際にログインしながら仕事を進めます。

xAI公式もIntroducing Grok Botで「あなたが使うツールにサインインし、仕事を終わらせる」と明記しています。

ここでのポイントは、@grokは「公開情報に対する秒速リプライ」、Grok Botは「社内ツール横断の多段ワークフロー」というレイヤーがそもそも違う、という点です。検索で両者を比較している読者は、まずこの前提を揃えておく必要があります。

Grok Chatとの違い

Grok Chatは、ChatGPTやClaude Chatと同じく「チャットUIで質問を投げて回答を得る」タイプの汎用アシスタントです。推論や文章作成、画像の下書きなど、1つのUIの中で完結する作業に向いています。

Grok Botはチャット画面こそあるものの、裏側で持っているクラウドPCの中で、ブラウザを開いて実際にWebサイトを操作し、ターミナルからコマンドを打ち、ファイルを保存し、次のBotに引き継ぐ——というツール外に実務が出ていく設計になっています。

Grok Botの利用量カウント方式はプラン体系で分かれます。The X Subscription（Premium/Super/Ultra）ではCursor・Grok apps・Grok Botが同じ週次プールを共有し、プールを使い切ると購入済みクレジット（Additional usage credits）から追加消費される仕組みです。一方、レガシーCursorプラン（Pro/Pro+/Ultra）ではGrok Bot専用の週次枠が別立てで付与されます。契約済みプラン種別によって「既存利用量との干渉」の挙動が違う点に注意してください。

Grok Buildとの違い

Grok BuildはxAI提供のコーディング特化エージェントで、TUI（ターミナルUI）・ヘッドレス実行・Agent Client Protocol（ACP）経由で利用します。リポジトリ内のコード編集・ビルド・テスト実行を担うツールです。

これに対しGrok Botは、コード編集だけでなくCRM更新・経費処理・採用面接のスケジューリング・バグチケットのトリアージなど、業務全体の多段ステップを引き受けます。

公式に紹介されているコード系委任事例では、Grok BotのクラウドコンピュータからCursor Cloud Agent（Cursorの別の独立したクラウドエージェント）にコーディングタスクを発注する組み合わせが示されています。「業務全体はGrok Botが司令塔、コードはCursor Cloud Agentが実行役」という形です。

Grok BuildとGrok Botは別サーフェスです。Grok Bot側は使うモデルがCursor側で動的に選定されるため、特定モデル（例：Grok Code Fast 1）に固定して書き分けないほうが安全です。Grok Buildはユーザーがモデルを設定・切り替えできる設計で、両者の運用スタイルは異なります。

---

Grok Botの5つの差別化要素——公式が強調する独自ポジション

xAI公式docsのGrok Bot overviewは、Grok Botを他のAIエージェントと分かつ軸を5つに整理しています。本セクションでは、この5軸を順に見ていきます。

xAI公式docsが示す「What makes Grok Bot different」の5軸（出典：xAI Docs）

公式docsの該当セクションを見ると、5軸はEach Bot has a computer（Botはクラウド上のコンピュータで動く※同一ユーザーの全Botは1台を共有）／Setup is a message, not a workflow builder（セットアップはメッセージ1本）／Bots coordinate with each other（Bot同士が自律連携）／Bots learn workflows from demonstration（デモからワークフロー学習）／Context compounds（文脈の蓄積）の順で明記されており、以下のH3もこの順序に揃えています。

ユーザーごとに1台のクラウドPCを全Botで共有

Grok Botの最大の設計特徴は、ユーザーごとに1台のクラウドPC（Firecracker microVM・browser・filesystem・terminalつき）が割り当てられ、そのユーザーの全Botがその1台を共有する点です。あなたのラップトップを閉じても、Bot側はクラウドPCの中で処理を続けます。

これはターミナルから起動するローカル実行型のCLIや、ブラウザタブに閉じたエージェントと決定的に違う点です。

Claude Coworkもクラウド型ですが、Grok Botは「ユーザーごと1台を複数Botで共有する」モデルを明示的に採用しているため、Bot間でファイル・ブラウザセッション・アプリログインを共有して引き継ぎができます。

ユーザー間はFirecracker microVMレベルで厳格に分離されており、他ユーザーのPCには到達できません。

メッセージ1本でセットアップ

多くの業務自動化ツールが「ワークフローを事前に組み立てる」設計を採るのに対し、Grok BotはサインインするとデフォルトのBotが自動で用意され、最初のメッセージで仕事内容を伝えて記憶させる流れで、ゼロコンフィグに近い導入手順を取ります。

公式docsのGet startedに載っている最初のメッセージ例は、次のような粒度です。

Your job is product performance. Investigate product-performance questions with our observability tools. Preserve links and screenshots, separate evidence from hypotheses, and lead with the highest-impact issue. Never change production settings. Remember this for future work.
（あなたの担当はプロダクトのパフォーマンスです。パフォーマンスに関する質問は、自社のオブザーバビリティツールで調査してください。リンクとスクリーンショットは残し、根拠と仮説を分けたうえで、最も影響の大きい問題から報告してください。本番環境の設定は決して変更しないでください。今後の作業のために、この内容を覚えておいてください。）

主担当業務・やり方・禁止事項をチャットで伝え、Bot名はチャット上部をクリックしてリネームする、という流れです。

n8nやZapierのような「トリガー→アクション→条件分岐」を事前に組む必要はありません。

複数Botの並列と自律協調

Grok Botは、ひとりの人間が複数のBotを同時に動かし、Bot同士をメッセージでつなげて仕事を回す運用を標準にしています。xAI公式の社内事例では、chief of staff役のBotが上位に立ち、受信箱管理・経費・採用・バグ修正・運用の各専門Botを束ねる構成が報告されています。

Botをグループチャットに入れておけば、Bot同士が自律的に仕事を割り振り、判断が必要な場面だけ人間に戻してくる設計です。

他ベンダーのエージェントも並列実行・サブエージェント連携を進めていますが、Grok Botは「ユーザー1台のクラウドPCを複数Botで共有＋グループチャット内での自律連携」を公式の標準パターンとして最初から前面に出している点が特徴です。

Teach a taskで1回見せてスキル化

Grok Botがもっとも強みを出しているのが、ブラウザ内のワークフローを1回実演すると、Botがスキルのドラフトを生成するという「Teach a task」の仕組みです。

xAI公式docsのSkills, routines, and automationsが公式手順を6ステップで整理しています。

• 1. 1対1のBot会話とcomputer viewを開く
  Teach a taskは「Botと1対1の会話＋クラウドPCのビュー」で動く。グループチャットでは起動できない
  
  

• 2. Teach a taskを選ぶ
  会話内のメニューから起動（機能は段階的に提供されているため、ボタンが見えない場合は書面指示でスキル化を依頼する）
  
  

• 3. 実演内容を言葉で宣言
  「これから何を実演するか」をBotに短く伝えてから作業に入る
  
  

• 4. ワークフローを1回だけ実行
  ブラウザ内のクリック・フォーム入力・保存先指定などを順に進める。最大10分、マイク音声は録音されない
  
  

• 5. 録画停止と生成スキルの確認
  Botが生成するスキルはドラフト扱い。失敗時の処理・判断ルール・承認境界は、ドラフトを見て手で追加する
  
  

• 6. 安全な例でテスト
  Routineに昇格させる前に、Test runで動作確認を済ませる

Zapier/Make/Power Automateで「トリガー・アクション・分岐」を書き起こしていた作業に対して、最初の実演1回＋ドラフト調整で代替できるのが差別化ポイントです。

「1回で完成」ではなく「ドラフトを土台にして手を加えて完成」という前提で設計すると、手続き型の自動化を書く専任人材がいない現場でも定着させやすくなります。

Botに文脈を蓄積させる

Grok Botは、名前付きBotごとに役割の文脈・好みの進め方・過去タスクの要約を保持します。会話は毎回リセットされず、以前の仕事の続きを拾い直せる設計です。

ただし公式FAQでも「重要な判断の場面では、記憶に頼らず最新のソースをBotに再確認させるように」と注意書きがあり、記憶は補助として扱う前提になっています。

---

Grok Botでできること——業務領域別の委任パターン

ここからは、Grok Botを実際にどんな業務に任せられるかを、xAI公式が示した社内事例と2026年10月に追加された新機能から整理します。

営業・マーケティングでの委任

営業・マーケティング向けの代表的な委任パターンは、通話記録や会議メモからCRMを更新し、次回のアプローチ文を下書きする流れです。xAI社内の運用例（Sales Bot）では、以下のような多段処理を実際に回しています。

• 録音文字起こしから要点を抽出
• CRMのオポチュニティを更新（商談ステータス・次アクション日）
• 新規コンタクトのエンリッチ（LinkedIn・企業情報の収集）
• 自分の文体に合わせたフォローアップメールの下書き
• 翌朝までに承認用ドラフトとして人間に戻す

このパターンの要点は、不可逆アクション（送付・削除・購入）の前には、ユーザーが設定した承認ルール（Auto Review）とBotへの境界指示に沿って確認カードが出せる点です。

「Allow once / Always allow / Deny」の3択で判断でき、Always allowルールを登録すれば自動進行させることも可能ですが、送信・削除・購入のような重要操作にはAsk firstルールを明示的に設定しておくのが安全です。

承認待ちの間、別のBotは他の案件を並行で進められます。

バックオフィス——経費・入社手続き・受信箱整理

経理・労務・総務のバックオフィス業務は、実行手順はある程度決まっているが、人間がPC前に貼りつく必要がある典型領域です。公式のOps Bot事例では以下のような委任が挙げられています。

• Gmailに届く請求書PDFを抽出し、会計システムへ入力
• 新入社員の受け入れ対応（公式announceの原文「seating new hires」）
• 受信箱の整理（既読処理・ラベリング・テンプレ返信）

2026年10月のアップデートで追加されたBot専用メールアドレス（ユーザーごとに1アドレスで全Botが共有）を使えば、送信元アドレス・ドメインなどを条件にメール受信ルーチンを組めます。

これまでZapierなどで作っていた「メール受信をトリガーにワークフロー実行」を、Botのメール受信だけで組めるようになりました。

エンジニアリング——バグ再現から修正の受け渡しまで

エンジニアリング用途では、バグレポートを受け取って再現環境でチケットを起票し、修正担当のBotにハンドオフする流れが整理されています。公式のEngineering Bot事例の多段処理は以下です。

• 製品UI上でバグを再現し、ステップとスクリーンショットを保存
• JIRA/Linearにチケットを起票し、再現手順と期待動作を記載
• デバッグ担当Botにハンドオフし、グループチャットで修正状況を共有
• Cursor Cloud Agentに修正を発注（Grok Botの司令塔役＋Cursor Cloud Agentのコード実行役の組み合わせ）

この流れを一度Teach a task経由で確立すれば、以後はCursor上の開発チーム全体が同じ経路でバグ修正を回せます。

Grok Bot側で使われるモデルはCursor側で動的に選定されるため、「Botがどのモデルで動くか」を記事側で固定せずに運用できます（Cursor Cloud Agent側は委任元の設定に従います）。

サポート向けIncidentWatch・IncidentSweep（社内運用事例）

2026年10月20日にxAI公式が公開した社内運用事例として、IncidentWatchとIncidentSweepという2つのサポート向けBotの使い方が紹介されています（新機能リリースではなく、Grok Botを使ったサポートチームの運用パターン）。

• IncidentWatch: チケットの急増や問い合わせトピックの変化を自動検知し、潜在インシデントとしてフラグ付け
  
  
• IncidentSweep: 関連する問い合わせバックログを集約し、対象チケットと返信文を人が承認してから返信・クローズする運用

この運用事例が示すのは、サポートリーダーがチケット増加に気付くタイミングと、現場が実際にバックログを捌くタイミングのギャップを、Grok Botの承認ワークフローで埋められる点です。

インシデント対応SLAが明文化されているSaaS企業や、問い合わせ量にムラがあるEC・金融系で参考になるパターンです。

X投稿の監視と定期レポート

2026年10月のアップデート（公式changelog v0.70.2）で、Xコネクタを事前に設定しなくてもX上の公開投稿を検索・監視できるようになりました。例えば以下のような委任が可能です。

• 自社ブランド・競合ブランドのメンションを常時監視し、日次でメール要約
• 業界イベントのハッシュタグに言及が集中した時だけアラートを出す
• 特定アカウントの新規投稿を要約してSlackに流し込む

この機能は、@grokのような単発リプライとは逆方向の設計です。

@grokは「ポストに答える」もの、こちらは「ポストを監視して定期レポートを吐く」もので、情シス・マーケティング・PR部門の定常業務にそのまま載せられます。

---

Grok Botの料金プランと利用枠

Grok Botは単体販売されておらず、既存のCursorプランもしくはSuperGrokプランにバンドルされる形で提供されます。

本セクションでは2026年10月時点の料金体系と、週次リセットの利用枠設計を整理します。

Cursorプラン別の対応状況

Cursor公式pricingによれば、個人向けプランでのGrok Bot対応状況は以下のとおりです。

プラン	月額	Grok Bot	位置づけ
Free	$0	✗	入門用（限定機能）
Plus	$8	✗	Grokモデルのみ提供される入門有料プラン
Premium	$30	✓（最安）	Grok Bot・Cloud Agent・コードレビュー等が解放
Super	$100	✓	Plus比15倍の使用量枠（Premium比だと約3.75倍）
Ultra	$200	✓	最大枠・最新機能先行アクセス
Teams	$30+/user	✓	SSO・席ごと利用枠・管理機能
Enterprise	要相談	✓	監査ログ・SCIM・ネットワーク制御

個人で最も安く始められるのはCursor Premium（$30/月）です。

2026年8月11日のGrok Bot公開当初はSuperGrok Heavy・Cursor Ultra・Cursor Teams Premium限定でしたが、同年8月25日の公式changelogでCursor Pro・SuperGrokの対象プランへ提供が広がり、10月のThe X Subscription統合でPremiumプランとしてさらに広く提供されるようになりました。

SuperGrok側からの利用

Cursorプランを契約せず、SuperGrok側からGrok Botを使う経路もあります。

• SuperGrok（月$30）
• SuperGrok Plus（月$100）
• SuperGrok Heavy（月$300）

いずれのSuperGrokプランでもGrok Botがバンドルされており、Cursor側でSettings → Usage & Billing → Get Access with Grok からSuperGrokアカウントをリンクすれば利用枠を接続できます。

既にSuperGrokを個人契約していてGrok 4.5などのGrokモデルを使っているユーザーなら、追加課金なしでGrok Botが有効化できます。

利用枠は週次リセット・プラン種別で算定方式が異なる

Grok Botの利用枠は週次リセットですが、プラン種別で算定方式が分かれます。

• The X Subscription（Premium/Super/Ultra）
  Cursor・Grok apps・Grok Botが同じ週次プールを共有。プールを使い切った後は購入済みクレジット（Additional usage credits）から追加消費
  
  
• レガシーCursorプラン（Pro/Pro+/Ultra）
  Grok Bot専用の週次枠が別立てで付与される（公式announceの「Grok Bot comes with its own usage, separate from your Grok and Cursor plans」はこのプラン群向けの原則）
  
  
• SuperGrok / X Premium+ リンク
  利用グラント（Cursorプランとは別）として付与。Cursorプランと重ねても加算ではなく、週次枠が大きい方が採用される

どのプランでも週次リセットは共通で、1週間ごとに利用枠がリフレッシュされます。

業務エージェントを走らせっぱなしにする想定なら、The X SubscriptionではSuper/Ultra、レガシーならPro+/Ultra、SuperGrok側ならPlus/Heavyなど、週次枠の厚いプランを選ぶのが安全です。

Enterpriseでのガバナンス機能

Enterprise契約では、管理者がCursorダッシュボードの Grok Bot ページからオン/オフを有効化し、全メンバーまたは特定グループに対して提供範囲を制御します（Teamsプランでは既定で有効）。

Enterpriseでしか使えないガバナンス機能は以下のとおりで、本記事後半のセキュリティセクションで詳述します。

• Network Controls（送信先ホワイトリスト）
• Team Secrets・Team Setup（独自のネットワーキング・証明書）
• Enforce Auto-review（組織横断の自動レビュー強制）
• Action Recording（90日間のBot行動記録）
• SCIM / 監査ログのSIEMエクスポート
• OpenTelemetry Export

日本法人が本番導入でSCIM・Network Controls・Action Recording等の統制機能を使うには、Enterpriseプランの契約と、管理者ダッシュボードでの有効化手順を事前に確認しておく必要があります。

---

Grok Botの使い方

ここからは、Grok Botを実際にセットアップし、最初のRoutineまで到達する手順を整理します。

xAI公式docsのGet startedの流れをベースに、導入時に詰まりやすいポイントを添えて解説します。

対応OSとサインインまでの流れ

Grok Botのデスクトップアプリは、2026年10月時点で以下のOSに対応しています。

• macOS（Apple silicon / Intel）
• Windows（x64 / Arm64）
• Linux（x64 / Arm64・.deb / .rpm / AppImage）
• iOS / iPadOS
• Android

2026年8月のGrok Bot公開当初は「Linux非対応」と記載された記事も多く残っていますが、公式docsでは安定リリースごとにLinuxビルドが配布されている状態です。社内の開発チームが主にUbuntu/Fedoraで動いている現場でも、同じ経路で導入できます。

サインインはCursorアカウントが前提です。組織でSAML SSOを使っている場合、既存のCursor SSO設定（Okta・Microsoft Entra・Google Workspace・OneLoginに対応）がそのまま適用されます。

SSOを強制している組織では、パスワードログインは自動的に無効化されます。

最初のBotと「仕事を伝えるメッセージ」

サインインが完了すると、Grok Botは最初のBot（名前「Grok Bot」）を自動作成してチャットを開きます。

ユーザーはそのチャットの最初のメッセージで、Botに主担当業務とやり方を伝えて記憶させる流れです（Botのリネームはチャット上部のBot名クリックから、2体目以降は New → Create new Bot で追加）。

最初のメッセージは、Botの振る舞いを決める「人格と権限の境界」になります。

公式のGet startedガイドが示すメッセージ例を参考に、次の要素を含めると初動のミスが減ります。

• 使うツールの指定（「我々のobservabilityツールを使う」等）
• 作業の進め方（「エビデンスと仮説を分けて書く」「影響度の高い論点から並べる」等）
• 禁止事項（「本番設定を変更しない」「外部に送信する前に必ず承認を取る」等）
• 記憶の指示（「Remember this for future work.」のように、以後のタスクで引き継いでほしい旨を明記）

禁止事項を明示しておくと、後述のApproval（承認カード）とAuto Reviewの判定が安定します。最初のメッセージに書いた境界が、Botの最初の防衛線になります。

Teach a taskでワークフローを教える

Botを作成したら、最初のタスクを渡します。公式手順に沿うと、Teach a taskはBotとの1対1会話＋クラウドPCのビューを開いた状態で起動します。

• 1対1のBot会話を開き、「Teach a task」を選ぶ
• これから実演する内容を1〜2文で宣言してから、ブラウザ上の操作を1回だけ通す
• 録画を停止すると、Botがスキルのドラフトを生成する
• ドラフトに失敗時の処理・判断ルール・承認境界を手で加えてから、安全な例でTest runを走らせる
• Test runが通ったら、Routineに昇格させて定期実行できる

Zapier/Makeで「どのトリガーで何をどう呼ぶか」を手書きで組んでいた作業と比べると、最初の実演1回＋ドラフト調整で済むため、手続き型の自動化を書く専任人材がいない現場でも立ち上げやすくなります。

Teach a taskは段階提供（gradual rollout）のため、画面にボタンが出ない場合は書面指示でスキルを作成する運用に切り替えます。

RoutineとAutomationで定期実行化

スキルが安定したら、時刻・イベント・webhookを使ってRoutine化します。例として挙げられる構成は次のとおりです。

• 毎朝8時に、昨日のCRM更新サマリをSlackに投げる
• Bot専用メールアドレスに請求書PDFが届いたら、会計システムへの入力ルーチンを起動する
• 特定リポジトリのPRが作成されたら、関連チケットの状態を更新する

Routineは、Botの詳細パネルから一覧表示・停止・再開ができます。

Teach-a-Taskで作ったスキルをRoutineに紐付ける形になるため、「仕事を教える工程」と「自動化を組む工程」が分かれていた従来ツールと比べて、設計の心理的ハードルが低くなっています。

---

他のAIエージェントとの比較と選び方

2026年のAIエージェント業界は、Claude Cowork・ChatGPT Agent・Manus・Grok Botが「クラウド常時稼働×デスクトップ代行」の路線で正面衝突しています。本セクションでは、Grok Botを選ぶかどうかの判断軸をケース別に整理します。

主要エージェントの比較マトリクス

以下の表で、代表的な4製品の設計思想と向き不向きを整理しました。

製品	開発元	常時稼働の形	強み	向く組織
Grok Bot	xAI（SpaceXSI）	ユーザーごと1クラウドPCを全Bot共有	Teach a task・Cursor連携・X監視	既にCursor/SuperGrokを契約しているチーム
Claude Cowork	Anthropic	セッションごとに独立した一時サンドボックス	裏側モデルのデスクトップ操作精度（Claude Fable 5[1m]はOSWorld-Verified 85.96%）・MCP連携	文書・コード作業を厳密に進めたい開発チーム
ChatGPT Agent / ChatGPT Work	OpenAI	クラウド実行＋ブラウザ・shell・ファイル操作・サブエージェント	現行Workはツール横断の自律実行に対応・Deep Research連携	ChatGPT Business/Enterpriseユーザー
Manus	Manus	ハイブリッド（クラウド+ローカル）	並列サブエージェント・成果物の生成品質	リサーチ・レポート生成を重視するチーム

この表から読み取れるのは、どれも「クラウド型AIエージェント」ではあるが、強みの軸がそれぞれ違うという点です。

GrokはTeach a taskとCursor既存契約との統合、Claudeは裏側モデルのOS操作精度、OpenAIはChatGPT Business/Enterpriseとの一体運用（Workによるブラウザ・shell・ファイル横断）、Manusはリサーチ成果物の生成品質に重みを置いています。

ケース別の選び方——AI総研の支援現場での判断軸

AI総研の支援現場で問われることの多い「どのエージェントを第一候補にするか」という問いに、ケース別の推奨を示します。

• 既にCursorでチーム開発している組織
  Grok Botが第一候補。Cursor Premium ($30/月) を既に払っている場合、Grok Botは追加料金なしで解放されるため、まずTeach-a-Taskで小タスクから委任を始めるのが最短ルート
  
  

• 文書作業・コードを厳密に進めたいチーム
  Claude Coworkが優位。裏側のClaude Fable 5[1m]はOSWorld-Verifiedで85.96%というデスクトップ操作精度を記録しており（Cowork製品全体の精度を直接示す数値ではないが、採用モデルの基礎能力として参考になる）、ミスの許されない書類業務や精緻なコード修正での安定度の目安になる
  
  

• ChatGPT BusinessやEnterpriseを既に契約している組織
  ChatGPT Agentから入るのが摩擦が少ない。既存のGPTs・ChatGPTのSSO設定・購買契約が流用できるため、情シス側の導入ハードルが低い
  
  

• リサーチレポートや構造化成果物を量産したいチーム
  Manusが向く。並列サブエージェント構成で、調査レポート・構造化成果物の生成品質に強みがある
  
  

• 全部まだ検討段階の組織
  Grok Botの無料トライアル（7日間の期限＋利用クレジット制。クレジットを消費すると期限内でも終了）でTeach a taskの体験値を取る→その上で他エージェントとの差分を見るのが現実的。クレジットが短時間で尽きないよう、タスクは小さく絞って試す

ここで注意したいのは、「どれが絶対的に最強か」ではなく、自社の既存ツール契約・既存ワークフローとの相性で決める方が総コストが低くなる、という点です。

Cursor既存ユーザーがわざわざ別エージェントに乗り換えるのはROIが悪く、同様にChatGPT Businessユーザーが新規にSuperGrokを契約するのも二重投資になります。

Cursor Teams・Businessでの位置づけ

複数人のチームで使う場合は、個人プランではなくCursor TeamsまたはSuperGrok Businessへの移行を検討します。

• Cursor Teams（$30+/user/月）: 席ごとの週次利用枠（メンバー間でプール共有せず、席単位で算定）・SSO・利用状況分析・集中請求
• Grok Business Plan: SuperGrokシートからサインインして使う法人向け経路

個人プランでチームが混在して使う運用は、監査ログと利用量の切り分けが曖昧になりがちです。10名を超えるチームで本格運用に入る前に、プランを法人向けに統一しておくと、ガバナンス機能を最低限担保できます。

---

Grok Botのセキュリティと運用上の落とし穴

Grok Botを業務に組み込む前に、必ず押さえておくべきセキュリティ論点があります。

本セクションでは、xAI公式のGrok Bot securityドキュメントに基づき、Self-serve TeamsとEnterpriseで扱える機能の差、そして国内導入時の実務的な落とし穴を整理します。

全Botが1クラウドPCを共有する設計上の制約

Grok Botで最も重要な設計上の論点は、ひとりのユーザーが所有する全Botが、同じクラウドPCを共有する点です。公式docsも「The computer belongs to your account, not to an individual Bot」と明記しています。

• 1つのBotがダウンロードしたファイルは、別のBotも参照できる
• あるBotがログインしたウェブセッションは、別のBotも引き継げる
• 1Password等の資格情報を1つのBotで入れると、他のBotもその資格でサイトに入れる

これは「Bot間のハンドオフをスムーズにする」設計上の意図ですが、部署をまたいだ業務を同じアカウントの別Botに割り当てる場合、権限が意図せず広がるリスクがあります。

実務的な対策は、業務ドメインごとにユーザーアカウントを分けること（販売・経理・エンジニアリングでユーザー自体を別にする）です。ユーザー間は厳格に分離されるため、アカウントを分ければBot越しのセッション共有は発生しません。

Botは独自の資格情報を持たない——「代理執行」の性格

公式docsの重要な原則が、Botは独自の識別子・資格情報を持たず、サインインしているユーザーの代理として動く点です。

• Botがツールにアクセスする権限は、原則としてBot所有者の権限が上限（ただしTeam-managedコネクタはチームまたはサービスアカウント資格情報を使う例外あり）
• すべてのアクションは、所有者の名前で記録される
• 署名ユーザーの外側に、監査・ローテーションすべき独立のマシンアイデンティティは存在しない

この設計は、IDガバナンスの監査対象をユーザーに統一できる点でメリットがあります。一方で、Bot経由の操作をユーザー自身の操作と分けて追跡したい場合、Audit Logs（管理・セキュリティイベント）とは別系統であるAction Recording（Botアクションの記録・Enterprise限定・90日保持）を有効化し、OpenTelemetry Export経由でSIEMに送信します。送信イベントには「cursor.surface=grok_bot」タグが付与されるため、SIEM側で分別可能です。

ApprovalsとAuto Reviewの役割

Grok Botには、不可逆アクション（送信・購入・削除）の前に承認を要求するApprovals機能と、より踏み込んだレビューを行うAuto Reviewが実装されています。

• Approvals
  チャット上に「この操作を実行しますか？」の確認カードが表示される。「Allow once / Always allow / Deny」の3択
  
  
• Auto Review
  独立したレビューモデルが、shellコマンド・プラグイン呼び出し・コンピュータ使用・ルーチン変更・サブエージェント起動などを事前評価し、通過・要承認・ブロックを判定

Auto Reviewの重要な注意点は、モデル判断なので100%の判定精度は保証されないことです。

公式docsも「explicit boundaries and least privilege（明示的な境界と最小権限）」を補完として位置づけており、Approvalsを過信してはいけない前提になっています。

• Enterprise限定: Enforce Auto-review（組織横断の強制）とTeam Auto-review rules（全メンバーに適用されるルール）
  
  
• Self-serve Teams・個人: 自分のパーソナルルールのみ編集可能

国内のPoC段階ではSelf-serve Teamsプランで試せますが、本番導入ではEnforce Auto-reviewなしに全社展開するリスクを評価しておく必要があります。

Local executionの扱い

Grok Botは、クラウドPCでの作業に加えて、ユーザーのローカルPC上でもコマンド実行できる設定を持ちます。これは便利な反面、設定を誤ると最も影響範囲が広い機能です。

• デフォルト: Ask every time（毎回確認）
• 緩和: Always allow（指定条件で自動実行）
• 封鎖: Never allow（ローカル実行を完全禁止）

公式docsが明示的に推奨しているのはNever allowで、特定のBotにローカル操作をさせる具体的な理由がない限り、ローカル実行は切っておくべきと説明されています。

管理者はチーム全体に対してExecution on Local Computerの上限を設定できますが、個人設定がより厳格な場合は個人側が優先されます。

データ所在・SCIM・監査ログの制約

国内の情シス審査で引っかかりやすい論点を、公式docsの記述から抽出しておきます。

論点	2026年10月時点の状態
クラウドPCの稼働場所	US拠点のみ（Firecracker microVM）。EU/APACのクラウドPC稼働は未提供（要相談）
SCIM 2.0	Enterprise限定（Self-serve Teamsでは利用不可）
Audit Logs（管理イベント）	Enterprise限定・SIEM送信可
Action Recording（Botアクション記録）	Enterprise限定・既定オフ・90日保持・OpenTelemetry Export経由でSIEMへ
Network Controls	Enterprise限定（Self-serve Teamsは全許可固定）
オンプレ・自社VPC導入	未対応（Cursor hosted cloudのみ）

情シス審査が厳しい業種（金融・医療・公共）では、SCIM・Network Controls・Action RecordingがEnterprise限定である以上、Enterpriseプラン契約と管理者ダッシュボードでの有効化を本番運用の前提に組み込むのが妥当です。社内ガバナンスのうち5つ以上をEnterprise機能に依存するなら、個人・Self-serve Teamsプランでの本番運用は推奨しづらい状況です。

プロンプトインジェクション・会話内の秘密情報

Grok Botはツールにサインインして動くため、ブラウザで開いたページの中に悪意ある指示が埋め込まれていた場合、Botがそれに従ってしまうリスク（プロンプトインジェクション）があります。

この領域はAIエージェントのセキュリティで扱う一般論と地続きです。

• 不審なサイトやページをBotに読ませない運用規律を敷く
• 認証コード・パスワード・ワンタイムコードはチャット本文に書かず、Secure Form（マスクされた入力欄）で入れる
• Memory writeの監査は限定的なので、Botの「記憶」に残したくない秘密情報は入れない

実装側の対策（セーフガードモデル・承認カード）だけに頼らず、ユーザー側の運用規律とBotの境界指示（最初のメッセージでチャット経由で伝えた禁止事項）を併用するのが現時点のベストプラクティスです。

---

Grok Botで固めた業務の手順を、自社テナントの本番運用に移す

Cursor Premium以上を契約していれば、Grok BotのTeach a taskで手順を教え、小さな業務から任せてみる段階は追加料金なしで試せます。ただ、クラウドPCは米国でのみ稼働し、Botの行動記録やSCIMはEnterprise限定のため、顧客データや基幹システムに触れる業務を本番で任せるなら、データの置き場所と記録の残し方を自社で決めておくことが前提になります。

Grok Botで確かめた手順を、データも記録も社内に置いたまま組み直す先になるのが、自社のAzureテナント内に構築するAI Agent Hubです。社員はTeamsからAgentを呼び出し、Agentはすべて1つの管理画面にまとまります。

• 顧客データをテナントの外に出さない
  Agentが扱う顧客データと実行の記録は自社のテナント内にとどまるため、データの所在を問う情シスの審査には、米国のクラウドではなく自社の環境として説明できます。
  
  
• 使える社員を部署ごとに区切る
  Agentごとにアクセス権限を設定できるため、営業のAgentは営業部、経理のAgentは経理部というように、業務の範囲に合わせて使える社員を決めておけます。
  
  
• Agentに任せた処理を記録からたどる
  どのAgentで誰が何を処理したかは不変の実行ログに残り、監査で問われたときに、Agentに任せた処理を1件ずつたどれます。

AI総合研究所の専任チームが、Grok Botで試した業務のどれを自社テナントに移すかを、扱うデータの機密度から一緒に決めていきます。

---

まとめ

本記事では、Grok Botについて、xAI製品ラインナップでの位置づけ・5つの差別化要素・業務領域別の委任パターン・料金プラン・使い方・Claude Cowork/ChatGPT Agent/Manusとの選び方・セキュリティ運用までを、2026年10月時点の最新情報で解説しました。

2026年10月時点で押さえておくべきポイントは次の3つです。

• Grok Botは「クラウドPCを持った同僚としてのAI」で、@grok（Xメンション応答）やGrok Chatとは明確に別の製品ライン。全Botが1台のクラウドPCを共有するという独特の設計を持つ
• 料金はCursor Premium（$30/月）以上または個人SuperGrok契約でバンドルされ、週次リセットで動く。The X Subscriptionでは共有プール、レガシーCursorでは別枠と、プラン種別で算定方式が異なる。Teach a taskでの一度見せる＝ルーチン化（ドラフト保存→手直しで確定）が最大の差別化要素
• SCIM・Network Controls・Action RecordingはEnterprise限定で、Self-serve Teamsプランは本番ガバナンスを張りきれない。国内本番導入は管理者ダッシュボードでEnterpriseを有効化し、小規模検証から段階的に始めるのが現実的

既にCursor Premium以上を使っている開発チームなら、Teach a taskで小タスクから委任を試す動きはそのまま始められます。一方、業務コード・顧客データを扱う本番運用までを視野に入れるなら、クラウドPCが米国で稼働する点・Enterprise限定機能の制約を踏まえ、自社テナント内で動く業務エージェント基盤と組み合わせる設計を並行で検討するのが、2026年後半の実践的な取り回しになります。