Grok Botを使い倒してみた

Grok Bot ざっくり比べると

AIコーディングに親しんでいる人だと「Swarmや/workflowと何が違うの？」と思うかもですね。

• workflowは残像拳
  • チームに見えるけど実体は一人
• Grok Botは六つ子
  • 実体が複数いてそれぞれが別に動く

こんな感じです。

順におはなししていきます。

クラウド上にPCが1個作成される

既存コーディングエージェントの弱点

コーディングエージェントはClaude Code/Desktop、Codex/ChatGPT Desktop、Grok Buildなど、PCアプリとして提供されていますので、起動されたPCの上でだけ動作します。出先からちょっと思いついて何かさせようと思っても

• PCの電源が常時オンで
• リモートデスクトップやSSHでアクセスが可能

というハードルの高さ。基本的にPCを開いてユーザーが操作する前提の設計です。（例外的にClaude Codeモバイル版は後述のVPSタイプです）

クラウドPC（VPS）で動く楽さ

Grok Botの場合、各ユーザに1台のクラウド上で動作するLinuxベースのPCが用意されます。そのPCへのアクセス口がGrokBotアプリ、という建付け。

画像は作りたてのボットのデスクトップです。ボットの数だけデスクトップがある。

クラウド上なのでPCからもモバイルからも、世界中どこからでも自分の環境にアクセスできます。またPCの電源を落としてもGrokBotのVPSは動き続けますので、指示を出して寝ている間にも、クラウド上でボットたちがフル稼働して作業してくれます。

クラウドPC上のボットの群れ

AIコーディングに慣れている人だと、すでにCodexなどに存在しているSwarm・Workflowの機能と何が違うのかが気になるところ。

完全同時並行作業ではない

workflowは一つの大きなタスクを分解し、大量の軽量サブエージェントを同時並行で作業させ短時間で終わらせる目的のもの。人間でいうとタイミースタッフを大量に呼んで数で解決するような方向性です。

Grok Botはそれぞれが中量級エージェントで動作しています。たぶんGrok4.6のEffort Lowっぽい。ある程度自分で考えて自分で解決してくれるので、人間でいうと派遣やSESみたいな感覚です。

実際のアプリを触ることができる

複数のAIエージェントを起動して並列的に作業をする、という意味でWorkflowは似ていますが、workflowから呼び出されるエージェントの権限はかなり狭く、テキスト操作やコーディングエージェントハーネスが準備しているツール（WebSearchなど）に限定されます。

対してGrok BotはクラウドPC上にインストールされたソフト・ツールをユーザ同様に操作することができます。どこまで任せるかはユーザ次第ですけど、ホットペッパーのようなAPI提供が無いサイトの操作もできちゃいます。

こんな感じで、各ボットがそれぞれのデスクトップ環境で作業している内容が見れます。

ボット自体が仕事を覚える

workflowで呼び出されたサブエージェントたちはその場限りで消滅するので、「前と同じ作業」というのが出来ない存在です。呼び出し元の親エージェント側で覚えておいても、サブエージェントの再現性はそんなに高くないです。

Grok Botは「このサイトにアクセスしてこのデータを取得して」という指示をした場合に、行ったログイン操作やページ遷移などを再現することを得意としています。プロンプトで指示する以外にも、RPAソフトのように、VPCの画面でユーザが操作した作業内容を録画して記憶し毎日実行、というようなことをやってくれます。例外的な事態にも対応できるcronジョブというか。

• SEOの検索順位調査と記録
• Githubリポジトリの新規Issueやコメントのチェック
• 複数ECサイト横断で価格推移のデータ作成

もちろん既存のハーネスでも同じようなことはできるんですけど、手軽にスマホからでも指示できるというのはかなりハードル下がるのではと思います。

画像は情報収集のルーティンの例です。ルーティン自体もボットに作らせたり修正させたりできます。

「指示」の部分はボットに「こういうルーティン作って」で生成してもらったものです。

ボットがファイル操作やコマンド実行が可能

上で書いた話に被りますけど、ボットがコマンド実行やアプリ操作が可能なので、PCでできる作業のほとんどをAIが代行可能です。スクリーンショットを取りながらAPIやMCPがないアプリの操作も可能なので、基幹業務システムの定型的な操作の自動化なども可能です。

VPC側に入れたツールはなんでも使えますので、XではGrok BotのPCにClaude CodeやCodex、HermesやOhMyPiなどを入れてVPSとして使っている人もチラホラ見かけました。確かにAI付きVPSと考えると破格です。

PC版は起動しているPC上のファイルやコマンドの実行もできるようになりましたので、

ボット個別に職業・能力を指定

サブエージェントは万能型で、親エージェントからの指示以外のこともやりがちです。いろんなモデル・いろんなハーネスで使ってみてますが、サブエージェントのオーバーエンジニアリングを親が直す光景を日常的に見てます。

Grok Botは各ボットに肩書と指示書（CLAUDE.md/AGENTS.md的なもの）を与えて、職能を制限する事ができます。

たとえば「Webデザイナ」という名前で説明にこのように書くと

こんな感じで見た目以外は触らないキャラになってくれます。

複数ボットを組み合わせて連携動作

「複数のAIエージェントが連携動作する」という表現的にはworkflowもGrok Botも同じように聞こえますけど、違う点を上げると

• ボットが記憶を持っている
  • 「前にこうやった」を覚えているので、違うタスクでも前の作業をリファレンスにして効率よくやってくれる
  • 逆に、前のやり方にこだわる時があるので「これは新規アーキテクチャです」とか予め指定しないといけないときもある
• ボット同士が通信できる 
  • workflowはエージェント同士は横のつながりがない
  • 「このタスクは自分の職責の内容ではないから専門のボットを呼ぶ」ということができる
• 各ボットに担当・責任の概念がある
  
  • 例えばデザイナーで設定しているボットに「このシステムのバグを修正して」と頼むと断られる
  • 他のボットへ作業を依頼したときは結果を依頼元のボットが検収して、「直しきれていないから再修正して」と突き返したりする

この辺が記事冒頭に書いた、「残像拳」と「六つ子」の違いという感じです。

残像拳＝workflowは結局全部自分なので、サブエージェントの不手際を親エージェントが修正してます。サブエージェントは非常に限られたスコープでしか情報を与えられていないので、前提条件がわからないゆえの間違いをしがちで、それを親が地道に直すという、チームメイクがうまくいってないPMみたいな切なさと愛しさと心強くなさを感じるときがしばしばあります。

六つ子＝Grok Botは、「これは専門じゃないから〇〇へ回す」「〇〇の作業待ちだからまだ進められない」と、ボット同士ですこし険悪になったりしてます。

Grok Botの作業適正

Grok Botに向いている作業

1個1個のボットの推論性能はそんなに高くないので、質より量の作業に向いているように感じます。

• QA業務
  • Webアプリの動作確認
  • 全機能を総当りでアプリのバグ探し
  • スクショ付きの手順書の作成
• 24時間体制の情報収集
• 比較的簡単なルールのテキストファイルの生成
  • 定時レポート作成など
• スパムメールの仕分けルール実行と調整

いわゆる「PC雑務」の範疇のものは幅広く使えそう。

あと私はアカウント持ってないので使ってないですけど、SalesforceやAhrefsなどの営業や販促のプラグインも充実しているので、データドリブンな自動化チームとかも作れそうな感じです。

Grok Botに向かない作業

AI全般に言えることですけど、発想の飛躍が必要なものは難しいです。また強い推論が必要なもの、人間の五感に関わる部分もちょっと弱いです。

ボット1個ずつの能力もそれほど高くないので、長すぎるコンテキストはかなりカットされます。そのためコーディングもあまり得意じゃないです。

• アイディア出し
  • 検索して出てくるような内容
• デザイン
  • 結構絶望的なセンス
• 長いテキストファイル
  • 500行の文書は最後の100行しか読んでいない感じ
• 規模の大きいプロジェクトのコーディング

Grok Botのチームを作る上で覚えておいたほうがいいこと

「グループ」の機能はいまのところは使わないほうがいい

ボットを6体までまとめて一斉に指示を出せるグループ機能。

一見チーム管理しやすい機能に見えるのですが、チャット内容が決定事項として全ボットのコンテキストに入ります。これの何が問題かというと、最初のボットが間違った回答をした場合、ユーザプロンプトと同じ強度で他のボットにも伝わってしまい、間違いを強化していくエコーチャンバーが発生します。この誤りを訂正する指示を打っても、多数決的に無視されるという現象が2回ありました。

グループの代わりに`@ボット名`を使わせる

じゃぁチームはどう作ったらいいのかというと、@を付けてボット同時で会話をさせることができます。

代表になる1体から、他のボットへ作業を移譲して結果をまとめて返すアグリゲータースタイルが現状のベターのような気がします。

ボット同士のファイルは隔離されていない

会話の内容はそれぞれのボットで隔離されているんですけど、ファイルシステム上は全てのボットが /workspace 上で起動しています。

ボットやグループにワーキングディレクトリを指定する事もできますが指示が守られる保証はないので、ファイルを作成してもらうときはパス指定をする方が安全です。

またそれを逆手に取って、ボット同士の掲示板を作成することも可能です。これは妄想ですけど、過去の類似作業を探したりとかできたらボットのトークンの効率化ができるかも。