Grok Bot 登場、専用クラウドPCを持つ常駐型エージェント。ただし全 Bot が同じ計算機を共有する

要約

SpaceXAI が 2026-08-11、Grok Bot を公開しました。Bot は「実務を任せられる AI チームメイト」という位置づけで、人間と同じようにアプリや Web サイトへサインインして操作します。

従来のチャット型エージェントとの最大の違いは、Bot が自分専用のクラウドコンピュータを持つことです。各 Bot はブラウザ・ファイルシステム・ターミナルを備えた永続クラウド VM 上で動きます。コネクタや MCP が使える場合はそれを使い、きれいな API を持たないアプリに対しては computer use で直接操作します。成果がチャットの下書きではなく、実際のツールの中に残る設計です。

状態が持続する点も特徴です。名前付きの Bot はメモリ、ファイル、ブラウザセッション、好みをターン間で保持します。タスクごとにまっさらな環境へ戻らず、文脈が積み上がっていきます。複数の Bot を並列で走らせることもでき、Bot 同士が直接メッセージを送り合い、スレッドやグループチャットで文脈を共有し、担当を引き継げます。公式の言い方では「ユーザーがツール間のルーターになる必要がない」ということです。

ワークフローの獲得方法も独特です。多段・多システムにまたがる手順を一度実演して見せると、Bot はその経路を routine として保持し、スケジュール実行やオンデマンドでの再実行ができるようになります。ワークフロービルダーや事前設定は不要とされています。

そしてセキュリティ上の重要な制約があります。すべての Bot が同一の永続クラウドコンピュータを共有します。この計算機はアカウント単位で分離されており、Bot 単位では分離されていません。公式ドキュメントは「そのコンピュータに置いたログイン情報やファイルは、自分の全 Bot から利用可能だと考えること」と明記しています。Bot ごとに画面は分かれますが、セキュリティ境界は分かれません。

提供は SuperGrok Heavy、Cursor Ultra、Cursor Teams Premium の3つの既存サブスクリプションに含まれる形で、デスクトップアプリと iOS で利用できます。

何が変わったか

• 各 Bot がブラウザ・ファイルシステム・ターミナルを持つ永続クラウド VM 上で動く
• API を持たないアプリにも computer use でサインインして操作できる
• メモリ・ファイル・ブラウザセッション・好みがターン間で持続する
• 手順を一度実演すると routine として保持され、スケジュール実行や再実行ができる
• 複数 Bot を並列稼働でき、Bot 同士でメッセージ・文脈共有・担当の引き継ぎができる
• 全 Bot が同一のクラウドコンピュータを共有する。分離はアカウント単位で、Bot 単位ではない
• SuperGrok Heavy / Cursor Ultra / Cursor Teams Premium に同梱。デスクトップと iOS で利用可能

業務インパクト（一般企業向け）

この製品の評価は、共有クラウドコンピュータの制約をどう見るかでほぼ決まります。

「Bot ごとに役割を分けて、経理用の Bot には会計システムだけ、営業用の Bot には CRM だけ触らせる」という設計を考えたくなります。しかしそれはできません。分離はアカウント単位で、置いたログイン情報は全 Bot から使えます。役割分担は Bot の振る舞いの話であって、権限の話ではありません。最小権限の原則を Bot 単位で適用したい組織にとって、これは決定的な制約です。

したがって現実的な使い方は、一人の担当者が自分の権限の範囲で使う形になります。自分がアクセスできるシステムを、自分の代わりに Bot が触る。この構図なら共有計算機であることは問題になりません。逆に、複数人の権限を1つのアカウントに集約して運用しようとすると、権限が合成された状態になります。

そのうえで、業務価値がある部分ははっきりしています。API を持たないシステムに手が届くことです。社内には API のない基幹システムやレガシー画面が必ず残っており、自動化の話が「連携できないから」で止まることが多い。computer use で画面を直接操作するアプローチは、この壁を越える手段になります。実演から routine を作れる点も、手順書の形式知化が進んでいない業務ほど効きます。

導入を検討するなら、まず担当者個人の反復作業から始めるのが妥当でしょう。毎週の集計、複数システムをまたぐ転記、定型的な調査。こうした作業を一度実演して routine 化し、スケジュール実行に載せる。組織的な権限設計の話に踏み込まずに価値を確認できる範囲です。

なお、computer use でアプリにサインインさせる以上、認証情報をクラウド VM 上に置くことになります。ここは情報システム部門の承認が要る領域です。技術的に動くかどうかとは別の判断が必要になります。

副業・個人活用視点

個人利用なら、共有計算機の制約はほとんど問題になりません。自分の権限しかない環境で自分が使うだけなので、そもそも分離する相手がいないからです。企業導入では致命的になる制約が、個人利用では気にならない。この非対称性は理解しておくと判断が速くなります。

副業で効いてくるのは、API のないサービスを扱う作業です。クライアントが使っている業務システムに API がない、管理画面から手作業でデータを取るしかない、という状況は珍しくありません。こうした作業を Bot に実演して routine 化できれば、時間単価の低い作業から手を引けます。

ただしクライアントの認証情報を自分のクラウド VM に置く構図になる点は、案件として受ける前に整理が必要です。全 Bot が同じ計算機を共有する以上、複数クライアントの案件を並行して持っている場合、A 社の認証情報と B 社の認証情報が同じ場所に載ります。これは技術的な問題ではなく、契約と信義の問題です。受託で使うなら、この構造を説明したうえで合意を取っておくべきでしょう。

案件の切り口としては、「API がなくて自動化を諦めていた業務」の掘り起こしが素直です。これまで n8n や既存の RPA で見積もって断念した案件を、別のアプローチで再提案できます。ただし computer use は画面の変更に弱く、UI が変わると routine が壊れます。壊れる前提で保守込みの提案にするか、壊れても影響の小さい作業に絞るか、どちらかを最初に決めておいてください。

発信のネタとしては、「実演から routine を作る」体験そのものが記事になります。プロンプトで手順を書き下ろす方式と、一度やって見せる方式で、どちらがどの作業に向くか。エージェントへの仕事の渡し方が変わるという論点は、ツールを問わず関心を持たれる話題です。