エージェントに「自分のコンピュータ」を与えた日——Grok Bot が開く常時稼働チーム

Grok Botは、チャットで指示する「アシスタント」ではなく、専用クラウド PC を持つ常時稼働の AI 同僚として設計されたプロダクトである。公式ブログ（2026-08-11）では Early beta として公開され、社内プロトタイプが営業・マーケ・運用・バグ修正まで広がった後に一般提供へ進んだ。

• 自分のコンピュータ：ブラウザ・ファイル・ターミナルを持つ持続 VM。API が無い Web アプリも computer use で操作
• 同僚のようにメッセージ：ワークフロービルダー不要。タスクを渡すと承認が要る所まで進めて戻る
• 複数 Bot の自律協調：スレッドやグループで互いに委譲し、人間がハブにならない
• デモから覚える：一度見せた手順をルーチン化し、次回から自律実行

コーディングエージェント（Claude Code / Codex / Grok Build）やチャット型エージェントとの差分は、実行環境の持続性と仕事の完遂境界にある。

• チャット下書きで終わらない：ログイン済みセッションで、人間が仕事をする同じ画面に成果を置く
• セットアップ摩擦が低い：複雑な自動化の事前設計より、「同僚に頼む」一文から始まる
• Grok Build との役割分担：Build はターミナル上のコーディング・ハーネス。Bot はクラウド PC 上の業務同僚（営業・運用・跨ぎアプリ）
• 提供面：デスクトップと iOS から同じ Bot に続きのスレッドでアクセス

公式ドキュメントの核心は、Bot = 名前付きの持続エージェントであり、実行基盤はアカウント単位の共有クラウド PCだという点である。

• 各 Bot はブラウザ・ファイルシステム・ターミナルを持つ持続 VM 上で動く
• 全 Bot が同一コンピュータを共有：ログインやファイルはアカウント境界。Bot ごとには別スクリーンだが、セキュリティ境界は分離されない
• だから handoff が簡単：別 Bot に渡しても「もう一度ログインして」が発生しにくい
• 裏を返すと、1 Bot に渡した認証情報は他 Bot からも見える前提で権限設計が必要

社内利用では「参謀 Bot + 専門 Bot」構成が典型例として語られる。人間がツール間の伝書鳩になる構造を、Bot 間メッセージで置き換える。

• 並列実行：inbox / 経費 / 採用 / バグ修正などレーン別に Bot を分ける
• スレッドとグループチャットで文脈共有・オーナーシップ委譲
• 判断が要る所だけ人間を呼ぶ（approval gate）
• 事例：営業 Bot が CRM 更新とフォロー下書き、ops Bot が入社セットアップと請求書処理、engineering Bot が UI 再現→チケット→デバッグ Bot へ

Grok Bot の差別化のもう一本は、ライブデモからのワークフロー学習と、時間とともに蓄積する好み・境界感である。

• 一度一緒に手順を見せるとルーチンとして保存し、次回から自律実行
• 訂正を取り込み、声・例外・「いつ聞くか」を学習
• 止まった handoff の nudge、過去スレッドからの再開
• 最終的には「聞かれる前に動く」プロアクティブな同僚へ

公開時点のアクセスは SuperGrok Heavy、Cursor Ultra、Cursor Teams Premium（デスクトップ / iOS）。Enterprise は waitlist。

• 向く仕事：複数ツール横断・明確な成果物・翌朝までに欲しい調査/下書き/衛生タスク
• 公式が示す一例：Salesforce の見込みリスト抽出→既存シーケンス除外→上位アカウント調査→LinkedIn/メール下書きを朝までに承認待ちで用意
• 注意：共有 PC 上のログインは全 Bot 共通。セキュリティと承認設計を先に読む（docs: approvals / security / privacy）
• 一次情報：Introducing Grok Bot · Docs overview