Grok Botとは何か　xAIが示すAI社員時代の働き方

この記事のまとめ

Grok BotはxAIが公開した、AI社員に近いコンセプトの仕組みで、「AI teammates you can give real work to」を掲げています。仕組み、料金、他サービスとの違い、導入時の注意点を整理します。

Grok BotはxAIがベータとして公開した常駐型のAIです。
共有のクラウドコンピュータで既存のアプリにサインインして仕事を進めます。
SuperGrok Heavy、Cursor Ultra、Cursor Teams Premiumの対象プランで利用できます。
共有コンピュータや承認設計など、導入時の注意点があります。

Grok Botの基本と登場の背景

Grok Botの定義とコンセプト

Grok Botは、xAIが打ち出した「AI teammates you can give real work to」というコンセプトのAIです。日本語に訳すなら「本当の仕事を任せられるAIチームメイト」といったところで、これは単なるキャッチコピーではなく、設計思想そのものを表しています。

Botはクラウドコンピュータを使い、ふだん人が使うツールにサインインし、アプリや受信箱をまたいで仕事を進め、承認が必要なときだけ人に戻ると公式に説明されています（参照*1）。

この位置づけの核は「委任」です。会話を開いたまま結果を別ツールに移すのではなく、Botが仕事を引き受け、関係するソフトを横断して進め、判断が必要なときに人間に戻る設計とされています（参照*2）。チャットに答えを返す道具ではなく、作業を最後まで完了させる道具として設計されている点が、従来のAIアシスタントとの本質的な違いです。

提供形態と対応環境

提供形態はベータで、対応環境も絞られています。

Grok BotはデスクトップとiOSで利用できます。対象プランにはSuperGrok Heavy、Cursor Ultra、Cursor Teams Premiumが含まれます（参照*1）。

対応OSはAppleシリコンとIntelのmacOS、x64とArm64のWindows、iOS 18以降のiPhoneで、Linuxデスクトップ、Android、iPadは初期提供では非対応と明記されています（参照*3）。

2025年agentからの潮流変化

AIエージェントの役割は、応答から業務の完了へと広がっています。私がコンサルティングの現場でAI導入を支援してきた経験でも、この変化は明確に感じます。「ChatGPTに質問したら答えが返ってきた」という段階から、「AIが実際のツールを操作して仕事を終わらせた」という段階への移行が、2025年以降に急速に進んでいます。

Grok Botは、AIエージェントにクラウドコンピュータを与え、ユーザーがログオフしたあとも仕事を続けられる設計です。プロンプトへの応答から、職場のタスクを最初から最後まで進める方向性が示されています（参照*4）。

常駐して働くAIエージェントへの関心が高まるなか、Grok Botもその流れに位置づけられます。ただし、関心が高まることと、現場で定着させることは別の話です。この点については後述します。

Grok Botの仕組みと働き方

専用クラウドコンピュータでの常駐稼働

Grok Botが従来のチャット型AIと根本的に異なるのは、クラウドコンピュータ上で仕事を進める点です。チャットは「答えを返す」のに対し、Grok Botは「作業を完了させる」設計になっています。

Botは共有のクラウドコンピュータを使い、ユーザーが席を離れてもジョブが止まらないよう設計されています。APIやMCPのないプラットフォームを含め、アプリやウェブサイトにサインインして作業を進めると公式に説明されています（参照*1）。

このクラウドコンピュータには、ブラウザ、ファイルシステム、ターミナルが備わり、Botはツールを使ってジョブを最初から最後まで進めます（参照*5）。

各Botは共有コンピュータ上の画面を使い、ラップトップを閉じても作業を続けられます（参照*3）。

アプリ操作とcomputer useの実際

Botは、ブラウザ上の画面を操作してアプリを動かします。

コンピュータ操作では、画面上のボタンや入力欄を使ってクリックやキー入力を行います。APIやMCPコネクタを持たないシステムでも、ブラウザベースのツールを利用できると説明されています（参照*3）。

一方で、サイトが自動化をブロックしたり、新規ログイン、CAPTCHA、人間による確認を求めたりする場合は、ユーザーに引き渡す必要があります。コネクタが使えるときは、より構造化され信頼性の高い連携のために利用が推奨されています（参照*3）。

routineとskillによる学習

Botに手順を覚えさせるには、作業を一度見せる方法があります。私がAI導入支援で繰り返し見てきた課題の一つが「AIに何をさせるかを言語化できない」という問題です。このroutine・skill機能は、その課題に対する一つの答えになりえます。

仕事をするときにBotについてこさせると、Botは手順を観察し、好みのやり方を記憶し、ワークフローをroutineとして保存します。同じ工程を何度も説明し直す必要がなくなると紹介されています（参照*1）。

skillはタスクの実行手順を記述したものです。routineはワークフローを1つのBotに割り当て、スケジュールやイベントに応じて実行させる指示です。

Teach a taskでは、ブラウザワークフローを録画するとBotが下書きのskillに変換します。提供は段階的で、録画は10分に制限されています（参照*3）。

複数Bot連携とAI社員としての運用

複数Bot並列とオーケストレーション

Grok Botでは、複数のBotを並列で動かす使い方が想定されています。

xAI社内では、複数のBotを並列で走らせ、1体が他を束ねる運用が紹介されています。トップにchief of staff役のBotを置き、受信箱管理、経費、採用、バグ修正、オペレーションなどの役割ごとに専門Botを置く形です（参照*1）。

複数のBotは並列で動作し、他のBotを調整する役割も置けます。Bot同士はコンテキストを交換し、共有のグループ会話に参加できると整理されています（参照*4）。

Bot同士のハンドオフとグループチャット

Bot同士は、スレッドやグループチャットで仕事を引き継げます。

Botは互いにメッセージを送り、スレッド内でコンテキストを共有できます。グループチャットにBotを置くと連携して仕事を引き継ぎ、判断が必要なときだけユーザーを呼ぶと説明されています（参照*1）。

ログインやCAPTCHAに突き当たった場合は、制御をユーザーへ返し、対応後に作業を再開します（参照*3）。

共有クラウドコンピュータの前提

複数Botで動かす際に、まず理解しておくべき前提があります。クラウドコンピュータが共有される点です。ここを見落とすと、セキュリティ設計が崩れます。

アカウント上のすべてのBotは1台の永続的なクラウドコンピュータを共有し、ファイル、ブラウザセッション、ログインを共有します。コンピュータはユーザー単位で割り当てられるため、別々のBotをセキュリティ境界として使わないよう公式に明記されています（参照*3）。

コンピュータはアカウントに隔離されるため、そこに置いたログインやファイルは、自分のすべてのBotから利用可能なものとして扱う必要があります（参照*5）。

この共有モデルは、個人が複数の作業を並列で走らせる用途には向いていますが、業務の種類によってアクセス権を分けたい企業用途では設計が難しくなります。導入前に、どのBotにどのシステムへのアクセスを許可するかを整理しておく必要があります。

社内活用例とユースケース

営業とCRM運用のBot

営業業務は、Grok Botの活用例として紹介されている領域の一つです。

営業アウトバウンドBotは夜間にアカウントを調査し、コンタクトを意図でスコアリングし、メールとLinkedInのメッセージを担当の口調で下書きし、承認待ちの受信箱を用意します。別のBotはCRMの情報を整理し、案件の停滞やコミットリスクを検知し、月曜のスコアボードを揃える例が紹介されています（参照*1）。

通話トランスクリプトからCRMにメモを書き込み、フォローアップを下書きする営業Botの使い方も紹介されています（参照*1）。

オペレーション・経理・採用のBot

決まった手順が多い仕事は、Botとの相性がよい領域です。私がAI導入支援で感じているのも、まさにこの点です。オペレーション系の定型業務は、手順を言語化しやすく、成果物の良否も判断しやすいため、AIへの委任が最もうまくいきやすい。

公式では、営業BotがCRMに通話メモを書き、オペレーションBotが新入社員のオンボーディングを進め、Gmailの請求書を処理し、エンジニアリングBotがバグを再現してチケットを起票し、デバッグBotに渡す例が挙げられています（参照*1）。

Grok BotはxAI社内のプロトタイプとして開発され、社内チームは営業アウトリーチ、マーケティング、請求書処理、採用、ソフトウェア開発などに使うようになったと紹介されています（参照*4）。

エンジニアリング・リサーチのBot

エンジニアリングや調査系でも、外部テスターによる利用例が紹介されています。こうした事例を見ると、Grok Botが最も力を発揮しやすいのは、手順が明確で、出力の品質が検証しやすいタスクだと感じます。

採用ソーシングでは、平易な言葉で要件を渡し候補者リストとLinkedInプロフィールが返ったという報告があります。リポジトリ調査では、GitHubリポジトリのダウンロードや実行、機能テスト、ドキュメントファイルの生成、プロダクトリサーチでのPPT生成が紹介されています（参照*6）。

会話がタスク単位ではなくBot単位で進む点も特徴として紹介されています。名前付きBotのサイドバーにメール、LinkedInリサーチ、交渉、汎用といった役割が割り当てられていました（参照*7）。

料金体系とアクセス方法

3つのアクセス経路と価格

Grok Botは単体プランではなく、既存の対象プランに付随する形で利用できます。この点は、新たに専用のサブスクリプションを用意する必要がないという意味で導入障壁を下げていますが、逆に言えば、対象プランを持たない場合はすぐには使えません。

対象プランには、SuperGrok Heavy、Cursor Ultra、Cursor Teams Premiumが含まれます。利用条件や料金はアカウントとプランによって異なります（参照*3）。

対象プランを持たないユーザー向けの限定無料トライアルも紹介されています（参照*6）。

週次アロワンスとオンデマンド課金

料金の仕組みには、週次利用枠と超過時のオンデマンド利用があります。

対象サブスクリプションには毎週のGrok Bot利用枠が含まれます。超過時には、対象アカウントでモデルとトークンのコストに基づくオンデマンド利用を追加できます（参照*3）。

チーム導入時の実務

チーム利用では、プランや設定によって利用条件が変わります。

チームおよびエンタープライズ向けの提供は段階的に進められており、利用可否や必要なプラン、対応する管理機能は組織によって異なる場合があります。詳細はCursorのアカウントチームへの確認が案内されています（参照*3）。

他のAI agentとの違い

chat型agentとの違い

Grok Botと従来のチャット型AIの違いは、「答えを返すか、仕事を完了させるか」という一点に集約されます。私がよく使う表現で言えば、チャット型は「優秀な調べ係」であり、Grok Botは「実際に手を動かす担当者」に近いコンセプトです。

Grok Botは共有のクラウドコンピュータで動作し、端末を閉じても作業を続けられます。出力は受信箱やCRM、ドキュメントなど、実際のツールに反映されることが想定されています（参照*1）。

公式はこの違いを「90%と100%の完成度の差」として説明しています（参照*1）。この表現は的確だと思います。チャット型で90%まで進められても、残り10%の「実際のツールへの反映」を人間がやらなければならない場面が、業務では非常に多い。Grok Botはその10%まで自動化しようとしている設計です。

チーム常駐型AI employeeとの違い

同じ常駐型AIでも、チームチャットに置くタイプとは使い方が異なります。

Grok Botはクラウドコンピュータ上で動く複数のBotを使う仕組みです。一方、Viktorはチームがすでに使っているチャットの中にいる1体のAI employeeで、SlackやMicrosoft Teamsのチャンネルやスレッドに常駐すると紹介されています（参照*8）。

単独の利用者や複数の作業を並行して進める人には並列Bot型が向き、同じアカウントを複数人で扱うチームでは共有コンテキストを持つスレッド型が求められる場合があると整理されています（参照*8）。

導入時の注意点とリスク

共有コンピュータとNHI的リスク

Grok Botを導入する際に最初に把握すべきリスクは、共有コンピュータを前提とした権限管理の問題です。生成AI導入支援の現場で私が繰り返し見てきたのは、「便利だから使い始めた」という段階でセキュリティ設計を後回しにして、後から問題が出るパターンです。

アカウント上のすべてのBotは1台のクラウドコンピュータ、ブラウザセッション、ログインを共有します。サイトに一度サインインすると、自分のどのBotでも使える状態になり、Bot間のセキュリティ境界ではないと明記されています（参照*3）。

一般論として、非人間アイデンティティは広範な高権限アクセスを横断で持つことがあり、誤設定や侵害が起きるとデータ漏えいや横方向の移動につながりえます（参照*9）。

モデル選択不可とspend cap未整備

技術チームが評価する際には、モデル選択と支出管理の条件も確認が必要です。

Grok Botでは、タスクに使うベースモデルをユーザーが選ばず、ジョブに応じて自動選択すると紹介されています。モデル選択やアドバンストモードがないことは、実務ワークフローを評価するチームにとって制約になりえます（参照*7）。

オンデマンド利用はモデルとトークンのコストに基づいて請求されます。利用条件はアカウントとプランにより異なります（参照*3）。

承認設計と人間のオーバーサイト

Grok Botは常駐しますが、承認ルールの設計が前提です。「常駐する」という言葉の響きに引っ張られて、何でも任せてしまう運用は危険です。私が企業のAI導入を支援するときに必ず確認するのが、「送信・公開・削除・購入のような不可逆的なアクションに、誰の承認を挟むか」という点です。

公式は、各Botの説明に恒常的な境界を書き込み、送信、公開、削除、購入、本番システムの変更に対して、狭いRequire Approvalルールを追加するよう推奨しています（参照*3）。

AIエージェントのセキュリティと相互運用性に関する標準化の動きも進んでいます。NISTのCenter for AI Standards and Innovation（CAISI）は、AI Agent Standards Initiativeを2026年2月17日に立ち上げたと紹介されています（参照*10）。

AI社員時代の働き方の変化

知識労働の再設計

常駐型AIは、知識労働の切り分け方を変える可能性があります。私自身、Webメディア運営やコンサルティング業務でAIを毎日使ってきて、変わったのは「仕事の量」ではなく「仕事の中身」だと実感しています。下書き、要約、調査、構成案はAIに任せ、判断、取材、事実確認、最終的な責任は自分が持つ。この切り分けが明確になるほど、仕事の質が上がります。

AIエージェントの働き方を対比した例として、あるAIは数秒で要約とリンクを返し、ユーザーがタブを開き、数字をスプレッドシートにコピーし、チャートを作り、メモを自分で書きます。もう一方は20分あまり後に、スプレッドシートとチャート、下書きのメモを添付して返すと対比されています（参照*11）。

公式にも、早期アクセスのユーザーがGrok Botを「プロンプトを与える感覚より、有能なチームメイトに仕事を渡す感覚に近い」と語ったと紹介されています（参照*1）。この感覚の変化は重要です。AIを「聞くと答える道具」から「仕事を渡せる相手」として扱えるようになると、業務設計の発想そのものが変わります。

人間側の役割の変化

AIエージェントが常駐すると、人が使う時間の中身も変わります。私が生成AI事業を立ち上げて2年半ほど運営してきた実感では、AIに仕事を渡せるようになるほど、人間に残る仕事は「判断」「取材」「関係構築」「責任を持った確認」に寄っていきます。これは仕事量が減るというより、仕事の性質が変わるということです。

財務領域では、Corporate Finance & Accounting Talent Study 2026によると、53%の回答者が現在AIを社内スタッフで評価、パイロット、実装しており、12%はコンサルタントと組んで実装しています。AI研修を計画済みまたは実施中は16%、現在AIを使っていないのは19%とされています（参照*12）。

Grok Botの利用者は、最初は15分ごとに様子を見てマイクロマネジメントしていたが、今は任せており、時間とともに良くなっていると振り返っています（参照*1）。

導入企業に求められるガバナンス

AI社員を本番運用するには、技術の準備より先に、企業側のガバナンス設計が必要です。私が企業のAI導入支援で最もよく見る失敗パターンは、プロンプトや機能の検証には熱心なのに、「誰が最終確認をするか」「問題が起きたときの責任はどこか」が決まらないまま運用が始まるケースです。

エンタープライズAIプログラムに共通する性質として、本番システムでの名前付きオーナーシップ、パイプラインに埋め込まれた機械可読なガバナンス、ドリフトを捉える評価基盤の3つが挙げられています。生成AIプロジェクトのおよそ30%がPoC後に破棄されるというGartnerの予測もありますが（参照*13）、私の経験でも、PoCで止まる最大の理由はモデル性能ではなく、組織の意思決定とルール整備の不足です。

国家レベルでも、NISTのCenter for AI Standards and Innovation（CAISI）が、AIエージェントシステムのセキュリティと相互運用性の標準に特化したAI Agent Standards Initiativeを2026年2月17日に立ち上げたと紹介されています（参照*10）。

おわりに

Grok Botは、AIを「聞いて答える相手」から「仕事を渡せる相手」へと動かす流れを体現した製品です。共有のクラウドコンピュータで常駐し、複数体で連携し、承認が必要なときに人間に戻る設計は、「AI社員」という言葉のイメージに実態を与えています。私が生成AI事業を立ち上げてから繰り返し見てきた、「使ってみたはいいが定着しない」という問題への一つの答えが、この常駐型・委任型の設計思想にあると感じます。

一方で、共有クラウドコンピュータのセキュリティ設計、モデル選択の制約、利用条件の確認といった注意点は現実的な課題として残ります。任せる仕事の範囲、承認ルール、責任者、監査ログをセットで用意する。そして最初は小さな業務で試し、入力・出力・確認・修正のサイクルを回してノウハウを貯める。この順序を守らないと、便利な実験で終わります。

監修者

安達裕哉（あだちゆうや）

デロイトトーマツコンサルティングにて品質マネジメント、人事などの分野でコンサルティングに従事しその後、監査法人トーマツの中小企業向けコンサルティング部門の立ち上げに参画。大阪支社長、東京支社長を歴任したのち2013年5月にwebマーケティング、コンテンツ制作を行う「ティネクト株式会社」を設立。ビジネスメディア「Books&Apps」を運営。
2023年7月に生成AIコンサルティング、およびAIメディア運営を行う「ワークワンダース株式会社」を設立。ICJ2号ファンドによる調達を実施(1.3億円)。
著書「頭のいい人が話す前に考えていること」が、95万部（2026年6月時点）を売り上げる。
（“2023年・2024年上半期に日本で一番売れたビジネス書”（トーハン調べ／日販調べ））