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

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

API/MCP がある所はコネクタ、無い所は computer use。接続の綺麗さで仕事を切り捨てないのが設計思想。

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

• 各 Bot はブラウザ・ファイルシステム・ターミナルを持つ持続 VM 上で動く
• 全 Bot が同一コンピュータを共有：ログインやファイルはアカウント境界。Bot ごとには別スクリーンだが、セキュリティ境界は分離されない
• だから handoff が簡単：別 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