.png)
AIへ質問するのではなく、メールやCRMへログインさせ、仕事が終わるまで任せられるとしたら、働き方はどう変わるのでしょうか。
2026年8月11日に発表された早期ベータ版「Grok Bot」は、クラウド上のコンピューターを使い、実際の業務ツールで仕事を進めるAIエージェントです。
回答を受け取った人間が転記する従来のチャットAIとは違い、調査、入力、更新、引き継ぎまでを一つの仕事として扱います。
SpaceXAIは「常時稼働するAIチームメイト」と表現していますが、現在使える人は限られ、業務アカウントを接続するには権限管理も欠かせません。
「AI社員」という呼び方は機能をつかむには便利でも、法的な責任を負う従業員や、人間を完全に代替する存在を意味するものではありません。
本記事では、2026年8月12日に確認したSpaceXAIの公式発表と公式ドキュメントを基に、機能、料金、日本での利用条件、端末対応、セキュリティまで整理します。
Grok Botは、ユーザーごとに割り当てられたクラウドコンピューター上で、ブラウザ、ファイル、コマンドライン、コネクターを扱うコンピューター利用型AIエージェントです。
仕事を依頼すると、必要なサービスを開き、情報を読み、複数の画面を行き来し、指定された成果物や更新結果を返します。
APIやMCPに正式対応していないWebサービスでも、ブラウザ画面を人間のように操作できる点が特徴です。
ただし、サイト側が自動操作を拒否している場合や、CAPTCHA、再ログイン、支払い確認が表示された場合は、人間の操作が必要になります。
以下は記事内で使う共通CSSです。Webflowでは最初のHTML埋め込みに一度だけ配置してください。
「24時間働く」とは、ユーザーのパソコンを閉じてもクラウド側の処理が続くという意味です。
ログインセッションの期限切れ、承認待ち、Web画面の変更、外部サービスの障害などで停止する可能性はあり、無停止や完遂を保証する仕様ではありません。
通常のGrokは、質問への回答、調査、文章や画像の生成が中心です。
Grok Botは、回答を材料として返すのではなく、その後に人が行っていた「サービスを開く」「情報を入力する」「ファイルを保存する」「次の担当へ渡す」といった操作まで受け持ちます。
Grok Botは「Grok 4.5の別名」でも、新しい基盤モデル名でもありません。業務を実行する製品・アプリの名称です。
公式のチーム向け文書によると、Grok Botには利用者向けのモデル選択画面がなく、処理に使うモデルは製品側で管理されます。
Grok Botの基本的な流れは、次の8段階です。
たとえば「今月の広告実績を集計して改善案を作る」と依頼した場合、広告管理画面と分析ツールを開き、予算表と照合し、変更案をまとめるところまで進められます。
一方、広告予算の変更や代理店への連絡は承認前で止める、という境界も同じ依頼の中で指定できます。
Grok Botは人間のパソコンを遠隔操作するだけの製品ではありません。
通常の仕事はクラウドコンピューター上で行い、利用者のMacやWindows PCへアクセスする機能は別権限です。
ローカルコマンドは初期設定で毎回確認となっており、必要のない場合は無効にできます。
Grok Botが向いているのは、質問一つで終わる作業より、複数の情報源と操作をまたぐ反復業務です。
SpaceXAIの公式ユースケースと発表事例を基に、具体的な使い方を見ていきます。
CRMに登録された候補企業を読み、企業サイトや利用を許可された情報源を調べ、理想顧客像との一致度を評価し、担当者ごとのメールやLinkedInメッセージ案を作る流れです。
信頼できる運用になるまでは送信やシーケンス登録をさせず、レビュー用一覧で止めます。
通話後には、会話メモをCRMへ記録し、次のアクションとフォローアップ文案を作る使い方も公式発表で紹介されています。
調査、記録、下書きを一つの仕事として渡せるため、担当者は判断と顧客対応へ集中できます。
広告プラットフォーム、分析画面、予算シートから実績を集め、目標CPAや予算進捗と比較し、配分変更案を作る用途です。
レポート作成までは自動化しやすい一方、広告費の変更や外部公開は人間の承認対象に残すのが安全です。
競合サイトの更新や新製品発表を定期的に確認し、根拠リンク付きの変化だけをまとめる情報収集にも使えます。
ただし、Webサイト側の利用規約や自動取得の制限を無視できるわけではありません。
公式発表では、Gmailへ届いた請求書の処理や入社予定者の座席準備が社内事例として示されています。
実際の流れは、メールや取引先ポータルから請求書を探し、必要な項目を読み取り、保存先へ整理し、不足情報を一覧化して確認待ちにする、といった複数工程です。
振込や購入まで自動で進める設計にはせず、照合と仕訳候補の作成までをBotへ任せ、金額・取引先・支払日を人間が確認してから実行する方が現実的です。
募集要件に合う候補者を探し、すでにATSへ登録済みの人物を除外し、合致する根拠と連絡文案を準備できます。
採用担当者は候補者の選定と連絡可否を判断し、Botには情報収集と準備を受け持たせます。
入社準備では、必要書類やアカウント発行状況を確認し、担当部署ごとの未完了項目を整理する使い方が考えられます。
個人情報へのアクセスを伴うため、閲覧範囲と保存先を先に決めなければなりません。
CRM、製品利用状況、サポートチケット、請求情報、顧客メモを横断し、解約リスクや対応の優先順位をまとめられます。
次のアクションを提案しても、顧客への連絡や契約変更は担当者の承認を挟む設計が必要です。
不具合報告を読み、ステージング環境で再現し、手順、期待結果と実際の結果、スクリーンショット、ブラウザ情報、コンソールの記録をまとめてチケット化できます。
その後、デバッグ担当Botへ修正作業を引き継ぐ流れも公式発表で示されました。
本番データや本番設定を使うのではなく、テストアカウントとステージング環境に限定することが前提です。
原因の仮説と確認できた事実も分けて返すよう指示します。
毎朝の顧客リスク一覧、毎週の広告レポート、競合サイトの変更確認などはRoutineと相性があります。
データが取得できなかったときは古い結果で埋めず、失敗として報告させるルールを入れると、見かけだけ正常なレポートを防げます。
Gmail、CRM、LinkedInといった名称が公式事例に登場しても、それぞれに専用コネクターが必ず用意されているとは限りません。
正式なコネクターはアプリ内のPluginsで確認し、見つからないサービスはブラウザ操作の可否と利用規約を別に判断します。
Grok Botでは、2～6体のBotを同じグループ会話へ参加させたり、あるBotから別のBotへ非同期メッセージを送ったりできます。
調査担当が根拠を集め、営業担当が文案を作り、統括Botが重複や抜けを確認する、といった役割分担が可能です。
一例として、調査Botが候補企業の情報を集め、営業Botが連絡案を作成し、経理Botが取引条件の確認事項を整理し、Chief of Staff型の統括Botが進捗と承認待ちを一つの報告へまとめる構成が考えられます。
Bot同士の引き継ぎは確認できますが、担当を増やしすぎると重複作業や通知が増えるため、各工程の責任者は一体に絞る方が管理しやすくなります。
ここで注意したいのが、Botごとに完全に独立したパソコンが割り当てられるわけではない点です。
各Botには別の作業画面がありますが、同じユーザーが作成したすべてのBotは1台のクラウドコンピューターを共有します。
したがって、営業Botと経理Botを作っても、両者の権限やデータが自動的に隔離されるわけではありません。
分離が必要な業務は、Bot名ではなく、専用アカウント、権限スコープ、保存場所、ユーザーアカウント自体の設計で管理する必要があります。
発表ページでは「操作を一度見せればRoutineとして再実行できる」と簡略化されていますが、現行の公式ドキュメントではSkillとRoutineを分けています。
Skillは、手順、判断ルール、必要な入力、出力形式、検証方法、承認条件を保存した再利用可能な仕事の進め方です。
「Teach a task」が表示されるアカウントでは、利用者がブラウザ操作を実演すると、最大10分の画面操作からSkillの下書きを作れます。
録画された一例だけでは例外処理まで分からないため、失敗時の対応や承認境界を追記し、安全なデータでテストします。
Routineは、指定したBotがSkillやワークフローを予定時刻、または対応するイベントをきっかけに実行する仕組みです。
毎朝8時のレポート、平日夜の見込み顧客調査、特定の通知を受けた不具合再現などに使えます。
1体のBotは最大50件のRoutineを持てますが、実行履歴は各Routineにつき直近20件です。
従来のRPAは、座標、項目、条件分岐をあらかじめ定め、同じ画面で同じ手順を再現する用途を得意とします。
Grok Botは自然言語と画面理解を使うため、入力内容や表示が多少変わっても目的に合わせて判断しやすい反面、毎回まったく同じ操作を再現する保証はありません。
画面構成、コネクター、データ形式、社内ルールが変われば、SkillとRoutineを再テストする必要があります。
定型処理の厳密な再現性が最優先ならRPA、入力や判断が変わる複数工程ならAIエージェント、という使い分けが現実的です。
2026年8月12日時点の早期ベータ版は、主にSuperGrok Heavy、Cursor Ultra、Cursor Teams Premiumが対象です。
公式チーム文書には個人向けの一度限りの試用枠も記載されていますが、一般の無料プランへ常時開放された機能ではありません。
Cursorの公式料金ページでは、個人プランのUltra、チームプランのStandard／Premium、利用超過後のオンデマンド課金を案内しています。
Teams Premiumの金額はCursorの2026年6月の公式発表で確認できます。
税は別で、円換算額は為替や決済方法により変わります。
SuperGrok Heavyについては、SpaceXAIの料金比較ページにプラン名と購入導線はあるものの、確認時点の公開テキストでは現行月額を確認できませんでした。
第三者サイトの金額を公式料金として断定せず、契約画面で確認してください。
Grok Botの利用画面には、対象アカウントで週次の含有利用量とオンデマンド利用が表示されます。
チーム向けにはGrok Botだけの支出上限がまだなく、Cursorアカウント全体のオンデマンド設定が適用されます。
予算管理では、月額だけでなく利用超過分も確認する必要があります。
Grok Botは、メール、CRM、請求書、広告管理画面、ファイルへアクセスできるからこそ、チャットAIより強い権限管理が必要です。
複数Botはセキュリティ上の分離境界にならず、Botを削除しても共有クラウドPCのファイルやブラウザセッションは消えません。
導入時は、操作を次の3段階へ分けると設計しやすくなります。
最初はデータを変更せず、結果をレビューできる仕事に限定します。
メールは下書きまで、広告は変更案まで、経理は照合表まで、不具合調査はステージングでの再現までに止める設計です。
Grok BotのAuto-reviewは便利ですが、公式文書も「最小権限や明示的な承認境界の代わりにはならない」と注意しています。
ブラウザ全体を常に許可するような広いルールは避け、「外部メール送信前」「本番ダッシュボード変更前」のように対象を狭く設定します。
個人のメールや全社管理者アカウントをそのまま接続せず、可能なら読み取り専用、対象部署限定、期限付きのアカウントを用意します。
クラウドPC上のログインは同じユーザーの全Botから利用できるため、Botの役割名だけでアクセス範囲を制限できません。
パスワード、パスキー、2段階認証コード、CAPTCHA、支払い確認は、Agent Computerを一時的に引き継いで人間が入力します。
通常のチャットへパスワードやワンタイムコードを書いてはいけません。対応する安全な秘密情報入力画面が出た場合に限り、その専用欄を使います。
クラウドPCの操作と、利用者のMac・Windows PC上でのコマンド実行は別権限です。
初期値は毎回確認ですが、ローカルファイルを扱う理由がなければ「許可しない」に設定します。
Botを削除しただけではログイン状態や共有ファイルは残ります。
不要になったRoutineを停止し、Webサービスからログアウトし、コネクターを削除して接続先でも認可を取り消し、/workspaceの機密ファイルを削除します。
Cursorアカウントの学習拒否設定はGrok Botにも適用されますが、Grok Bot自体はクラウドへのデータ保存が必要で、Legacy Privacy Modeには対応しません。
Grok Bot、ChatGPT Work、Claude Coworkは、いずれも回答文だけでなく、複数工程の仕事を終わらせてレビュー可能な結果を返すことを目指す業務エージェントです。
ただし、操作環境、アカウント連携、権限、料金、提供段階は異なります。
OpenAIの公式ChatGPT Work文書は、明確な成果物を伴う長めの仕事を委任し、重要操作を承認する使い方を案内しています。
Claude Coworkの公式ページも、ファイルやツールを使う複数工程と、端末を閉じた後のクラウド処理を掲げています。
したがって、Grok Botだけが「作業するAI」で、他は回答するだけという比較は正確ではありません。
優劣を一つのベンチマークで決めるより、会社が使っているメール、CRM、ファイル環境へどの方法で接続できるか、必要以上の権限を渡さずに済むか、操作履歴を確認できるかで選ぶべきです。
詳しい比較は、AI TOP TIERの「ChatGPT WorkとClaude Coworkの違いは？」で確認できます。
Grokの基盤モデルについて知りたい場合は「Grok 4.5のコスト性能」も参考になります。
ここからは、確認できた仕様を基にした編集上の分析です。
Grok Botの意味は、AIの出力先がチャット欄から実際の業務画面へ移ったことにあります。
従来は、AIがメール文や調査結果を作っても、人間がCRMへ貼り付け、ファイル名を付け、別の担当へ送る必要がありました。
コンピューター利用型エージェントは、この「最後の転記と操作」を仕事の一部として扱います。
APIやMCPがない古い業務ツールでも、ブラウザ画面を操作できる点は導入範囲を広げます。
一方で、画面変更やログイン切れの影響を受けやすく、専用API連携ほど安定するとは限りません。
コネクターがある場合は構造化された接続を優先し、ブラウザ操作は補完手段として使う設計が妥当です。
複数Botが役割を分担する設計も、AIを一つの万能チャットとして使う発想とは異なります。
ただし、Botを増やせば自動的に組織が完成するわけではありません。
共有クラウドPCの権限、重複作業、承認待ち、利用料金を管理する統括ルールが必要です。
このため、企業のAI導入で問われる項目は回答精度だけでは足りなくなります。
誰のアカウントで動くのか、何を読めるのか、どこまで書き換えられるのか、誰が承認したのか、失敗時にどこで止まるのかまでが製品評価の中心になります。
AIエージェントの数が増えるほど、アクセス管理と責任分界の設計が価値を左右すると考えられます。
Grok Botは、チャットAIを人間の社員へそのまま置き換える製品ではありません。
正確には、ユーザー単位の共有クラウドコンピューター上で、ブラウザや業務ツールを操作し、複数工程の仕事を進める早期ベータ版のAIエージェントです。
端末を閉じても作業を続け、複数Botへ仕事を分担できる点には大きな可能性があります。
その一方で、対象プランは限られ、日本語と日本での提供には未確認事項が残り、Bot間でログイン状態やファイルが共有されます。
試すなら、公開情報の調査、データ整理、下書き、テスト環境での再現など、失敗しても戻せる仕事から始めてください。
送信、削除、購入、権限変更、本番環境の操作は承認制にし、結果と操作履歴を人間が確認する。
この順番なら、「AI社員」という分かりやすい期待を、現実の業務改善へ落とし込めます。
.png){kind=logo}
