Grok Bot に付いてくる常時稼働の Linux 機を何に使うか:プラン条件と実践報告の整理

開発mdx-playground

Grok Bot に付いてくる常時稼働の Linux 機を何に使うか:プラン条件と実践報告の整理

X で「Grok Bot は月30ドルの SuperGrok に常時稼働の Linux マシンが丸ごと付いてくる」という投稿を見て、手元の SuperGrok(X Premium+ に付属するもの)で使えるのかを調べた。 結論は3つある。

  • 使える。2026年8月26日の拡大で、Grok Bot は SuperGrok 無印(月30ドル)と Cursor Pro(月20ドル)まで対象になった。X Premium+ は Cursor 側のヘルプで「Grok Bot の使用量を付与するリンク先」として明記されている
  • 正体は、アカウントごとに1台割り当てられる Debian の仮想マシンで、そのアカウントの全 Bot が1台を共有する。Bot を分けても信頼境界にはならない
  • 任せるのは、PC の前にいなくても回る仕事に絞る。毎日か毎週、あなたのログイン済みの画面を見に行き、変化があったときだけ知らせ、送信や購入は承認だけスマホから返す。1回きりのバッチ処理は Claude Code や Codex で足りるので、この記事では扱わない

以下は、公式ドキュメント30ページ、英語のレビュー記事18本、日本語と中国語の実践記事20本あまり、X の直近3週間の投稿を突き合わせた記録である。 数値はすべて出典の記述をそのまま引いており、二次情報しかないものはその旨を添えた。

正体:アカウントに1台の Debian マシン

Grok Bot は xAI(買収後の社名は SpaceXAI)が2026年8月11日にアーリーベータとして公開した製品で、公式の定義はこうだ。

Bots are AI teammates you can give real work to. Bots can sign and use apps and websites just like you do on a persistent cloud computer. (Bot は実際の仕事を任せられる AI の同僚で、永続するクラウドコンピュータ上で、あなたと同じようにアプリやサイトにサインインして使う)

チャットに答える製品ではなく、名前を付けた Bot に仕事を渡し、成果物を返してもらう製品である。 その Bot が動く場所が、記事の主題である「常時稼働の Linux 機」だ。

Botを何体作っても同じ1台のクラウドLinuxを共有し、ログインとファイルと資格情報が全Botに見える構造
図1: Bot を何体増やしてもマシンは1台のまま。隔離はアカウント単位で、Bot を分けても信頼境界にはならない

中身は Cursor のサンドボックス

複数の利用者が中に入って計測した結果は一致している。

項目実測値
OSDebian 13(trixie)、x86_64、KVM 上
CPU / メモリ8 vCPU / 約16GB(スワップなし)
ディスク約128GB(overlayfs)
GPUなし
実行ユーザーbox。sudo は使えない
最初から入っているものgit、node、python3、curl、wget
入っていないものsshd、docker、systemd、bzip2
ネットワーク外向きは通る。グローバル IP は無く、出口は Cloudflare

環境変数に CURSOR_AGENT で始まる項目が並び、ホスト名も cursor だったことから、note の bright_dietes994 氏は「自分のコンピュータの正体は Cursor のサンドボックス基盤だった」と結論づけている。 これは資本関係と整合する。SpaceX は2026年2月に xAI を買収し、6月には Cursor の開発元 Anysphere の買収に合意しており、Grok Bot のアカウント、課金、サポート窓口はすべて Cursor 側にある。サインインに使うのも Cursor アカウントで、Grok Bot 専用のログインは存在しない。

何が残り、何が消えるか

永続性については観測が割れているので、層で分けて理解する必要がある。

公式ドキュメントは、共有ワークスペース /workspace を durable な領域と定めている。 Settings の Beta にある3つの操作のうち、Update と Recover は durable な状態を保ったまま機体を作り直し、Reset だけが直近のスナップショットに戻して未保存の作業を失う。 手で入れたパッケージは replaceable、つまり消える前提で書かれている。

一方で Qiita の ishizakahiroshi 氏は、昨日入れたものが今日も残り、ブラウザのログインも残ると書き、この永続性を前提に自作 CLI を常設して開発機として使っている。 両方の観測を満たすのが bright_dietes994 氏の運用で、/workspace に置くものと、冪等な bootstrap.sh で再構築するものに分けている。 Dennis Yu 氏の運用ルールはさらに短い。「Reset を押すな。Update を使え」。

全 Bot が1台を共有する

公式ドキュメントは、この点を3つのページで繰り返し書いている。

All of your Bots share one cloud computer assigned to your user account. Files, browser sessions, and command line credentials on that computer are available across your Bot roster. Do not use separate Bots as a security boundary. (全 Bot はあなたのアカウントに割り当てられた1台を共有する。ファイル、ブラウザセッション、コマンドラインの資格情報はどの Bot からも使える。Bot を分けてもセキュリティ境界にはならない)

各 Bot は自分専用のスクリーンを持ち、並列に動ける。 ただし公式の表現を借りれば「スクリーンは別々の作業面であって、別々のセキュリティ境界ではない」。 Bot を削除しても、その Bot がサインインしたセッションやファイルはマシン上に残る。 プラグイン(コネクタ)もアカウント単位で、Bot ごとに分けられない。

使えるプランと、X Premium+ の扱い

2026年8月11日のベータ公開から8月21日、8月26日の2回の拡大で、個人の最低月額が200ドルから20ドルに下がった時系列
図2: 入口は2週間で200ドルから20ドルまで下がった。8月26日以降は SuperGrok 無印と Cursor Pro で使える

公開当初の対象は SuperGrok Heavy、Cursor Ultra、Cursor Teams Premium の3経路で、個人の最低月額は200ドルだった。 8月21日、公式アカウントの @bot が「SuperGrok Plus、Cursor Pro+、Cursor Teams の全契約者に開放し、それ以外の全員に使用量を限定した無料トライアルを提供する」と投稿した。 8月26日には x.ai のニュースで「すべての SuperGrok、Cursor Pro、Cursor Teams プランに含める」と発表され、SuperGrok 無印と Cursor Pro が加わった。

9月2日時点の x.ai/bot の FAQ はこう答えている。

Grok Bot is accessible today for Cursor Pro, Pro+, and Ultra, SuperGrok, SuperGrok Plus, and Heavy, and Cursor Standard and Premium Teams subscribers.

注意点が1つある。docs.x.ai の一部のページ(8月20日から22日に更新されたもの)は「SuperGrok Plus 以上」という古い条件のまま残っている。 現行の条件として信頼できるのは 8月26日の発表と Cursor のプランページで、docs 側の記述は追い付いていない。

X Premium+ に付属する SuperGrok はどう扱われるか

x.ai 側の発表に X Premium+ は一度も登場しない。 これを扱っているのは Cursor のヘルプページだけで、そこにはこう書かれている。

You can also grant usage to your Cursor account by linking an individual SuperGrok, SuperGrok Plus, SuperGrok Heavy, or X Premium+ subscription. (個人の SuperGrok、SuperGrok Plus、SuperGrok Heavy、または X Premium+ の契約をリンクすることで、Cursor アカウントに使用量を付与できる)

同じページの表では、X Premium+ の行が「Link your X account from the Grok Bot plan screen」、使用量は「Linked usage, below SuperGrok Plus」となっている。 つまり手続き上は、Grok アカウントではなく X アカウントをリンクする経路が用意されている。 「X Premium+ に付属する SuperGrok を、SuperGrok 無印として扱う」と明記した文言は公式のどこにも無いので、grok.com 上で SuperGrok と表示されていても、まず X アカウントのリンクを試すのが筋になる。

手順と落とし穴も公式が書いている。

  • Link Grok Account と Link X Account のボタンは、サインイン前の Get Started 画面(ペイウォール)に出る。アプリの中に入った後の Settings には無い
  • リンクは一度作ると恒久で、解除も別の Cursor アカウントへの移動もできない。使う Cursor アカウントを決めてからリンクする
  • Cursor は更新のたびに SuperGrok や X Premium+ の契約状態を再確認する
  • SuperGrok Lite、SuperGrok Team、SuperGrok Enterprise は対象外

x.ai/bot に並ぶ「Get Pro」の20ドルは Cursor Pro を新規に契約する入口であって、SuperGrok や X Premium+ を既に持っている人には要らない。

使用量は週次で、量は非公開

課金の骨格は次のとおり。

  • 有料アクセスには週次でリセットされる使用量が含まれる。使い切った後は、オンデマンド課金が有効ならトークン実費で続けられる
  • Grok Bot の使用量は Grok 本体や Cursor の枠とは別のプールで、Bot に渡した仕事は既存の枠を減らさない
  • Cursor と SuperGrok の両方を契約していれば、残りが多いほうが使われる
  • 使用量の計測は Cursor アカウント上で行われ、Grok や X 側に第二のメーターはできない

週次の使用量そのものは、どの公式ページにも数値が無い。 あるのは「Highest」「Generous」「below Plus」という相対表現だけで、利用者が公開の場で推計している状態にある(推計値は後述する)。

無料トライアルの条件は Cursor のヘルプに1ページだけある。

The Grok Bot free trial is a usage credit rather than a set number of days, though a 7-day window also applies. (トライアルは日数ではなく使用量クレジットで、ただし7日間の期限も併せて適用される)

クレジットはメッセージ数ではなく、エージェントのステップ数とトークン数で減る。 大きな仕事を1回投げると全部使い切ることがあり、それは仕様であって補充されない。

何を任せるか:PC の前にいなくても回る仕事

利用者の報告で目立つのは、9万通のメール整理や、10年分のカレンダーから作った約1,000件の Notion データベースのような、数字の派手な事例である。 だがそれらは1回きりのバッチ処理で、API か MCP があれば Claude Code や Codex でも同じことができる。この記事では扱わない。 Grok Bot でしか回らない仕事は、次の表の右側にある。

Claude Code で足りる仕事と、Grok Bot でしか回らない仕事

観点Claude Code や Codex で足りるGrok Bot でしか回らない
回数1回きり。人が起動する毎日か毎週、またはメール着信などのイベントで勝手に動く
入口API、MCP、リポジトリあなたのログイン済みの Web 画面。API が無いサービスも含む
場所手元の PC が起きている時間クラウド機。PC を閉じていても、外出中でも動く
判断ターミナルの前で返すスマホで承認だけ返す
文脈セッションごとに作り直す名前付きの Bot が前回までを持ち越し、Bot 同士で仕事を渡す

Claude Code にもクラウドでスケジュール実行する仕組みはあるが、対象はリポジトリで、あなたの Gmail や乗換案内の画面に自分のログインで入って操作するものではない。 差はスケジュールにではなく、ログイン済みの画面を毎日触る手にある。

公式ドキュメントの用途集も、役割の決め方をこう書いている。

The best Grok Bot roles own a repeatable outcome, not a loose category of questions. Start with read-and-prepare work, review the result, then add approved actions or a routine. (良い役割は、漠然とした質問の分類ではなく、繰り返し出せる成果を1つ持つ。まず「読んで準備する」仕事から始め、結果を確認してから、承認付きのアクションやルーティンを足す)

日常運用の実例

利用者の報告から、毎日か毎週、人が PC の前にいない時間に回っているものだけを挙げる。

  • 平野太一氏(note)の Chief は、毎日 Google カレンダーから当日のタスクを取り、Gmail に届くサブスクの領収書 PDF を Google ドライブに保存する。Gmail Bot は新着を要約し、2日以上前の未読を自動で既読にする。Transit Bot は「出社」「帰宅」のショートカットで最速の電車を返す
  • inady 氏(note)のニュース調査 Bot は毎朝7時に自動で走り、台本作成と TikTok 分析の Bot とグループチャットで分業する。それぞれが過去の会話を覚えているので、前提を毎回説明し直さない
  • Billy Howell 氏は読者6,000人の地域ニュースレターを週次で回している。リサーチ Bot が週2回ソースを巡回して Notion カードに材料を詰め、木曜に配信し、セールス Bot が Gmail を見張って広告枠の値付けとセールスシートの作成をする
  • Mo Bitar 氏の8体には、サーバの稼働を見張る UptimeBot、サイトの変化を見張る PressBot、競合を追う EspionageBot、API の無いダッシュボードを読む Analytics Watcher がいる
  • Dennis Yu 氏の12デスクには、稼働監視の Fleet Monitor と、各ツールの有料 AI シートの利用量を追う Meter Maid がある
  • Flavio Copes 氏が設計例として挙げる Blog Pulse は、Plausible のアナリティクス、Cloudflare のデプロイ状況、GitHub、RSS を毎日確認して報告する
  • Gergely Orosz 氏は、サポートの受信箱と Stripe を接続し、明確な返金依頼の特定から規約の確認、返金の実行または準備、例外のエスカレーションまでを任せている
  • Remy 氏の Gordon は、ニュースレターを X と LinkedIn に転載し、コメントに対応する
  • Yoginth 氏は、クラウド機に Tailscale を入れて自宅のホームラボにつなぎ、照明やサービスの操作を Bot 経由で行っている

公式が8月26日に「いま Bot がやっている仕事」として挙げた9種類のうち、常時型は5つある。 受信箱を片付けて人が要るものだけ残す Inbox manager、出られない会議に出て要約を送る Meeting stand-in、メールと Drive とサブスクを常時監査する Digital declutterer、受注を取り込んで予約まで入れる Office manager、規約内の返金を処理する Customer support である。

型で整理する

頻度とログインの有無で並べ直すと、6つの型になる。

  1. 受信箱の番人(毎日から数回)。要返信だけを残し、返信案を用意し、古い未読を片付ける。送信はしない
  2. 見張り(毎日から毎時)。サイトの稼働、競合の変化、アナリティクス、明細の増減。変化があったときだけ知らせる
  3. 定期の仕込み(毎朝か毎週)。会議前のブリーフ、ニュースの調査、当日のタスク、ニュースレターの材料集め
  4. 外出中の手(随時)。乗換の検索、予約、購入の準備、書類の署名。判断はスマホで返す
  5. キューの一次処理(随時)。サポートの返金、受注の取り込み。例外だけ人に上げる
  6. 発信の自動化(定期)。SNS への転載、コメント対応。公開は承認付き

見張り型を組むときは、Bot にページ全体を毎回読ませない。 前回の状態を /workspace に書かせておき、次回はそれと比べて差分があるときだけ知らせる形にすると、1回の実行が短く済む。

本領と急所が同じ場所にある

日常運用は、週次枠をいちばん食う使い方でもある。 Craig Hewitt 氏は受信箱の整理を1日4回、Sentry の確認を1日2回のルーティンにして、Ultra プランの週次枠を1日で使い切った。 この製品の本領である常時運用と、課金の急所である週次枠が同じ場所にあるので、頻度の設計が使い方の本体になる。 最初は1日1回か2回から始め、最初の3日で Usage の減り方を見てから上げる。

マシンとして使い倒す:SSH、Claude Code、公開

冒頭の X の投稿が言う「Botに Tailscale 入れさせればSSHが通って 中は普通のLinuxなんで Claude Code も Codex も入る」は、複数の報告で裏が取れた。

あなたはGrok Botに指示と報告だけをやり取りし、クラウドマシン内のClaude CodeやCodexが重い処理を担い、Tailscale経由のSSHでworkspaceに直接入る構成
図3: Grok Bot は指示役に置き、重い処理は中の Claude Code や Codex に回す。減るのは Coding Agent 側の契約枠で、Grok Bot の週次枠は温存される

Tailscale で SSH を通す

グローバル IP が無いので、外から直接は繋げない。 Dan Wahlin 氏の手順はこれだけだった。

  1. Bot に「Tailscale を入れて、このマシン名で参加して」と頼み、表示された認証 URL を自分の Tailscale アカウントで承認する
  2. Bot に SSH の接続設定を出してもらい、手元の ~/.ssh/config に足す
  3. ssh で入る

sudo は無いが、Bot に頼めば Tailscale の導入と tailnet への参加は通る、というのが複数の報告で一致している。 sshd が入っていない点は、Tailscale 自身の SSH 機能で吸収する。ishizakahiroshi 氏はマシン側で tailscale set --ssh を実行し、管理コンソールの ACL に対象ノードと22番ポートを明示的に足した。 この記事で示唆に富むのは失敗のほうで、tailscale ping は通るのに SSH がタイムアウトした原因は、ACL が別マシン宛てだけを許可していたことだった。疎通確認が通っても、ACL は別に見る必要がある。

SSH が通る前の同氏は、手元の Claude Code が出した調査コマンドを Grok Bot に貼り、返ってきた出力をまた Claude Code に貼る「人力の伝書鳩」をしていた。 生のログを一度も見ないまま推論で原因を当てにいき、実際に誤診している。 「観測経路を最初に1本通しておくのが、いちばん効きます」という教訓は、この製品に限らない。

外部に公開したいサービスがあるなら、中国語圏の投稿が整理したとおり、Tailscale(内側から繋ぐ用)と Cloudflare Tunnel(ドメイン付きで公開する用)の2択になる。

中で Claude Code や Codex を動かす

中国語圏で「額度を節約する究極の裏技」として広まった使い方がある。

利用 Grok bot 的云电脑终端,登录自己的 Codex/Claude Code/Cursor 账号,然后跟 bot 说"复杂的任务或编程,请使用云电脑上的 Codex/Claude Codex/Cursor 额度完成,完成后你再向我汇报" (Grok Bot のクラウド機のターミナルで自分の Codex や Claude Code や Cursor にログインし、Bot には「複雑な仕事やコーディングはクラウド機上のそれらの枠で片付けて、終わったら報告して」と言う)

こうすると、中規模以上の仕事で減るのはコーディングエージェント側の契約枠で、Grok Bot の枠は指示文を書いて仕事を配るぶんしか使わない。 図3はこの構成である。

Rick Hightower 氏はさらに進めて、Grok Bot、Claude Code、Codex、Grok Build を1つの Git リポジトリに向け、「main は読むだけ、書くのはブランチ」を原則に、セッション開始時の git pull --ff-only と、書き込み前に切る作業者ごとの worktree で衝突を避けている。

TUI をラップして使う場合の罠が1つ報告されている。 ishizakahiroshi 氏が自作ハブ経由で Claude Code を起動すると画面が真っ黒のままになり、6回の誤診を経て、Claude Code の UI(Ink)が起動時に端末へ投げるカーソル位置の問い合わせ(CSI 6n)に誰も応答していなかったことが真因と分かった。 普通の端末エミュレータはこの問い合わせに応答するので、SSH で入って直接使うぶんには起きにくい。

sudo 無しで開発環境を作る

apt が使えないので、bright_dietes994 氏は micromamba で conda-forge のパッケージを /workspace 配下に入れた。 micromamba の配布形式は .tar.bz2 で、このマシンには bzip2 が無い。 Python の標準ライブラリ bz2 で展開するという回避策で ffmpeg まで入れ、GIF の生成に到達している。

覚えておく制約は2つある。 takeover モード(クラウド機の画面を直接操作する機能)は画面を配信しているだけなので、手元へのコピペができない。ログは /workspace/logs に残す。 そして sshd を自前で立てる場合、コンテナの再起動を生き延びないので、nohup で仕込み直す必要がある。

任せ方の型:役割、階段、承認

先行者の設計原則は同じ方向を向いている。

akira_papa_IT 氏は、指示を4点セットで渡すことを勧めている。

指示は「お願い」じゃなく、仕事の受け渡し。目的・場所・条件・完了形を渡すと、Botが自分で進めやすくなる。 「調べて」ではなく「上位5社を比較し、明日の会議で選べる状態に」

役割の粒度については、Nate 氏の「A Bot owns a theme, not a task」(Bot が持つのはタスクではなくテーマ)、Dennis Yu 氏の「1役割につき1デスク、同じ仕事を Claude や ChatGPT に黙って振らない」という原則、dariusgaynor 氏の「3つの仕事を持つ Bot は、1つも仕事を持っていない」が一致している。 公式も「General Helper」のような何でも屋を非推奨とし、Talent Scout や Expense Manager のような具体的な役割を推奨する。

xAI の Bot Engineering 資料を要約したという投稿は、任せ方を階段で表現している。

  1. タスクを渡す
  2. 訂正したタスクにする
  3. スキルにする
  4. ルーティンにする

公式ドキュメントも同じ順序を要求している。「A test run performs real work.」つまりテスト実行は本物のサイトを操作し、本物のファイルを変え、本物のツールを呼ぶ。 実証済みの手順だけをルーティンに乗せる、という運用が前提になる。

承認の境界は公式が列挙している。メッセージや招待の送信、公開、購入と送金、データの削除や上書き、権限の変更、本番環境の変更、法的条件の同意。 Auto Review では「Require Approval」と「Always Allow」の両方に一致した場合、常に「Require Approval」が勝つ。 パスワード、パスキー、二要素コード、CAPTCHA、支払い確認は Bot がやらず、Agent Computer を開いて人が操作してから制御を返す。 資格情報を渡すときはチャットに書かず、secure secret card(値がマスクされ、履歴に残らず、モデルにも見えない入力欄)を使う。

記憶の置き場所も決めておく。 Bot のメモリは好みや役割の文脈のためのもので、変わる事実はソースシステムに置き、Bot に毎回開き直させる。 公式 FAQ も「重要な判断ではメモリに頼らず現在のソースを確認させよ」と書いている。

グループチャットは2〜6体で、Bot 同士が非同期に仕事を引き渡せる。 最大で50体まで作れるが、sinksxbt 氏の投稿が言うとおり、共有マシンである以上「50体より、アクセスを絞った3体のほうが役に立つ」。

落とし穴

週次枠は思ったより速く減る

利用者の実測(いずれも二次情報)を並べる。

  • 6体構成で初日に週次枠の42%を消費
  • 基本的なチャット100回とスクリプト1本で週次枠の5%
  • Heavy 契約者が1つのワークロードで週次枠の約半分
  • 10分の作業で週次枠の約40%
  • 200ドルのプランで週次枠を1日で使い切った
  • ある利用者は Heavy の週次枠を約1,640万トークンと逆算した

xAI は8月24日に消費量への苦情を認め、8月26日に全利用者の上限をリセットした。 Ultra プランで週次枠を1日で使い切った Craig Hewitt 氏の仮説は、原因の見当として役に立つ。チャット履歴を消せないので毎ターン全履歴を読み直すこと、受信箱の整理を1日4回のように高頻度のルーティンにしていたこと、Bot ごとに軽いモデルを選べないこと、Bot 単位の使用量が見えないこと、の4つである。

Grok Bot 固有の支出上限は、公式ドキュメントのどこにも設定手順が無い。 トラブルシューティングの章が「on-demand spending limit」に触れているだけで、設定は Cursor 本体の課金設定に委ねられている。 公式が勧める対策は「大きな仕事の前に plan 画面で使用量を見る」で、実務的には毎日見るしかない。

試し打ちができず、証跡も薄い

ドライランが無い。テスト実行は本番動作である。 監査ビューは「coming」とだけ書かれ、現状の記録はチャット履歴と、ルーティンごとの直近20回の実行記録だけだ。 1つの Bot は1本の無限スレッドで、新規セッションの開始も手動の圧縮も残量メーターも無い。 メモリの中身を検査したり削除したりする手段も公開されていない。

ベータの不安定さ

8月20日から21日にかけて、共有マシンが stuck 状態になり、その利用者の全 Bot が同時に止まった。Cursor のスタッフが認めている。 8月24日から26日には「Bots failing to respond」と「overbooked」のエラーが記録されている。 データセンターの IP を理由にブラウザのサインインを弾かれる例、サイトのレイアウト変更で記録した手順が壊れる例もある。 Remy 氏は「Bot が X への投稿に1時間かかりきりになったが、どのツールを呼んでいるかも、なぜ詰まっているかも見えず、止めることもできなかった」と書いている。

共有マシンをどう扱うか

セキュリティで見落としやすいのは、Bot が受け取る権限が読み取り専用トークンではなく、生のログインセッションだという点である。 1体がプロンプトインジェクションに従えば、ほかの Bot がサインインしているサービスにも1ホップで届く。 ishizakahiroshi 氏の表現が正確で、「守られているのは箱ではなく、AI から箱への経路のほう」である。

公式の最小権限の推奨はこうだ。ワークフローに要るツールだけ接続する、可能ならスコープを絞ったサービスアカウントを使う、読み取り専用の仕事から始める、送信と公開と購入と削除と本番変更は承認の後ろに置く、接続と稼働中のルーティンを定期的に見直す。 顧客情報を扱う仕事なら、顧客データのあるサービスへのログインをこの共有マシンに置かないことが、この推奨の具体的な適用になる。

なお Legacy Privacy Mode は非対応で、データのクラウド保存が前提になる。学習のオプトアウトは Cursor のアカウント設定に従う。

向く仕事、向かない仕事

eesel のレビューは用途別に点数を付けている。 API の無いツール(古いベンダーポータル、ダッシュボード)の操作と、誤りのコストがレビュー時間で済む「下書き先行」の知識労働には向く。 カスタマーサポートのキューは10点中4点(ドライラン無し、確信度のゲート無し、返信単位の監査無し)、規制産業は3点(認証の主張が無い)と低い。

flaviocopes の整理では、使うべきでないのは、入力が固定された決定論的な処理(コードで書く)、ハードリアルタイムの処理、信頼ゾーンを分ける必要がある場面、使用モデルを制御したい場面、曖昧な指示で高リスクの自律動作をさせる場面である。

対応 OS は macOS、Windows(x64 と Arm64)、iPhone(iOS 18 以降)で、公式には Linux デスクトップ、Android、iPad は非対応となっている。 ただし非公式の Linux 移植は8月30日にアーカイブされ、その README は「Cursor が公式の Linux パッケージを配布し始めた」と案内している。公式ドキュメントの記述が追い付いていない可能性がある。 iPhone からはルーティンの編集や実演による教示ができず、Agent Computer の更新もデスクトップからしかできない。

今日から始める手順

SuperGrok を X Premium+ 経由で持っている場合の順序である。

  1. Cursor アカウントを用意する。リンクは恒久で移動できないので、Grok Bot を使い続ける Cursor アカウントを先に決める
  2. cursor.com/bot/onboarding からデスクトップ版を入れる。Windows は x64 と Arm64、macOS は Apple silicon と Intel
  3. Get Started 画面で Link X Account を選び、X Premium+ の X アカウントでサインインする。grok.com 上の SuperGrok 表示を根拠に Link Grok Account を試す価値はあるが、公式には別系統として書かれている
  4. どちらも通らなければ、使用量限定の無料トライアルで触る。クレジットは戻らないので、最初は小さな仕事だけ投げる
  5. 最初の Bot には、毎日1回あなたのログイン済みの画面を見に行き、変化があったときだけ知らせる役割を1つだけ持たせる。送信、購入、削除は承認必須のままにする
  6. Bot に Tailscale を入れさせて SSH を通し、/workspace に置くものと bootstrap.sh で再構築するものを分ける
  7. Claude Code や Codex を中に入れて自分のアカウントでログインし、Bot の description に「重い処理はそちらで」と書く
  8. 最初の3日は毎日 Usage & Billing を見て、週次枠の減り方を把握してからルーティン化する

冒頭の投稿は「自由に使わせるほど ユーザーのユースケースがそのままxAIに集まるんですよね」とも書いていた。 この製品の値打ちは、安い常時稼働の Linux 機でも、Claude Code の代わりでもなく、PC を閉じている間にあなたのログインで画面を見に行く手にある。 毎日回る雑務を1〜2本、差分だけ知らせる形で置き、承認だけスマホから返す。 この線から外れる仕事は、Claude Code や Codex に任せたほうが安い。 そうして決めた役割の定義とスキルは、Bot を別の製品に乗り換えても持ち出せる。

出典

公式(一次情報)

英語のレビューとまとめ

日本語と中国語の実践記事

X の投稿(2026年8月11日から9月2日の検索)