Grok Botは何者か？じぴこと考えた

世の中は、というよりXの中では笑、Grok Botの運用方法がやけに盛り上がっている。

ただ、盛り上がりを眺めていると、どうしても最初の疑問に戻ってしまう。

「結局Grok Botって、クラウド上にVMとして存在して、プライベートに動作可能だよってことやろ？」

そして、もうひとつ。

「過去にOpenClawやヘルメスエージェントで大盛り上がりしていたのと、基本的に匂いが同じなんだけど、

今回は、この疑問をじぴことそのまま会話しながらほどいていく。先に結論を言うと、Grok Botは「新しい頭脳が突然生まれた」というより、AIに消えない作業場を与えたものとして見ると、かなり腹落ちする。

もちろん、公式に確認できる仕様と、僕らの会話から出てきた解釈は分けて考える。夢のようなドラえもんの話もするが、最後に残るのは、ブラウザとファイルとログイン状態を持った常駐PCを、誰がどんな仕事に使うのかという、ずいぶん現実的な話だ。

Grok Botって結局、何が動いているのか

最初の疑問は、Grokというモデルの賢さよりも、そのモデルがどこで何をしているのかだった。チャット欄の中で答えるだけなのか、それとも、閉じても残る作業場所を持っているのか。ここを先に押さえたい。

「クラウド上のVMでプライベートに動く」はどこまで正しいか

じぴこは、いつものようにこちらの雑な問いをいったん受け止めてから、仕様の話に入った。

公式資料では、Grok Botは persistent cloud computer、つまり永続するクラウドコンピューターとして説明されている。さらに、ユーザーごとに persistent cloud Linux VM が割り当てられ、その中にブラウザ、ファイルシステム、ターミナルがある。PCを閉じてもBotは動き続けられる、という考え方だ。

だから「クラウド上にVMとして存在して、プライベートに動作可能」という直感は、xAI側のクラウドにある、自分のアカウント専用のVMという意味なら大きく外していない。

ただし、ここで「自分のインフラ上で完全にプライベート」とまで言うと話が変わる。セルフホスト型の自前サーバーではないし、クラウドにデータを保存することも前提になる。VMという言葉を聞いて、急に自宅の金庫へ移ったと思ってはいけない。クラウド上の作業場であり、サービスとして管理された環境だ。

persistent cloud computerを部品に分ける

じぴこは、さらに少し面白い構造を説明してくれた。

イメージとしては、ユーザーの専用Cloud Linux VMがあり、その中にBotごとの専用screenがある。そこに `/workspace`、ブラウザのログイン状態、ターミナル、MCPやコネクターがぶら下がる。

つまり、Bot A、Bot B、Bot Cがそれぞれ完全に別のコンピューターを持つというより、同じ作業場の中で画面を分けて働くイメージだ。

ここは大事なので、もう一度言っておきたい。全部のBotが同じVM、同じファイル、同じブラウザログインを共有する。各Botに画面は分けてあっても、Botそのものがセキュリティ境界として分離されているわけではない。公式資料も、Botをセキュリティ境界として扱わないよう明記している。

この構造を、僕は「AIが使える専用PC」と考えると理解しやすいと思う。モデルが返事をするだけなら、その場の会話で終わる。だが、ブラウザを開いてログインし、ファイルを読み、ターミナルで処理をし、必要ならMCPやコネクターを使うなら、AIの外側に状態の残る作業場が必要になる。

AIの頭脳より、永続する作業場を見る

この一言で、話の見え方が変わった。

もちろん、どのモデルを使うかは重要だ。しかし、Grok Botを他のチャットAIと分ける実用上のポイントは、モデル名だけではない。永続VM、状態、ブラウザ、ファイル、ターミナル、MCP、定期実行、承認といった、仕事を実際に進めるためのハーネスが一体になっていることだ。

公式の「persistent cloud computer」という表現を、派手なAIの名前としてではなく、「いつでも使える作業場」として読む。これが最初の整理になる。

OpenClawやHermesと何が同じで、何が違うのか

ここで、僕が感じた既視感が出てくる。Grok Botを見ていると、以前にOpenClawやHermesエージェントで盛り上がっていた空気と、どうも匂いが同じなのだ。名前や提供形態は違っても、AIをチャット欄から連れ出して、常駐する場所と道具を与える発想が似ている。

常駐エージェントという同じ匂い

じぴこが言うには、HermesはVPSやクラウドVMに住み、Telegramから話しかけられ、常時動作し、記憶し、スキルを作り、cronで仕事をする設計を売りにしている。OpenClawも大きく見れば、常駐エージェント、永続状態、モデル、ツール、各種メッセージング入口の組み合わせだ。

ここでの「同じ」は、Grok BotとOpenClawとHermesの内部実装が同一だという意味ではない。機能が完全に同じだとか、技術的な系譜が確定しているという話でもない。会話の中で見えてきた共通の抽象が同じ、という意味だ。

この構造が、サービスごとに別の名前をまとって現れる。

LLM界は、毎回ここに Agent、Teammate、Coworker、Bot と新しい札を貼るからややこしい。人類は `/home/ai` を作るたびに、新産業が誕生した顔をする笑

自作VPSと管理サービスの差

では、Grok Botは何が新しいのか。少なくとも、技術部品を組み合わせて常駐エージェントを作るという発想そのものが、突然Grok Botで発明されたわけではない。

違いは、そこまでの構成を誰が管理するかだ。

OpenClawやHermesのような世界では、VPSを用意し、環境を整え、ログインや権限を考え、スキルやcronを設定し、何か壊れたら自分で面倒を見る。自由度はあるが、Linux、Docker、OAuth、MCPといった単語が次々に出てくる。

Grok Botは、それをサービスとして包装する。ユーザーは「この仕事をやって」と目的を伝え、裏側の作業場や道具をサービスの枠内で使う。技術者にとっては部品の組み合わせに見えるものが、非技術者にとっては「仕事を任せられる相手」になる。

「技術的発明というより、パッケージングの勝負だと思う」

この見方は、Grok Botを過小評価する話ではない。むしろ、技術者が長い時間をかけて組むものを、一般ユーザーが使える形にしたこと自体が、十分に大きな価値になる。ただし、それは「新しい知能が生まれた」という価値とは少し違う。

非同期で刺さる仕事、刺さらない仕事

この問いの答えは、職種の名前よりも仕事の形にある。営業だから必要、エンジニアだから不要、という単純な話ではない。人間が離れている間も進めたいか、複数のサービスをまたぐか、ブラウザを実際に操作するか。そこを見ると、向き不向きがかなり見える。

複数サービスをまたぐ定型業務

じぴこは、Grok Botが想定する仕事として、営業アウトバウンド、マーケティング、オフィス業務、バグ修正などを挙げた。

例えば、通話記録をCRMへ反映してフォローアップを作る。Gmailに届いた請求書を処理する。製品UIでバグを再現し、チケットを作り、別のBotへ修正を依頼する。

一つひとつの手順は、特別に高度ではない。だが、Gmail、CRM、スプレッドシート、Webサービスを人間が毎日またいでいると、コピペの往復だけで時間が溶ける。APIが用意されていれば連携できるが、現実にはログインして画面を開き、ボタンを押さなければならない業務も多い。

こういう仕事は、定型性が高いのに、単純な一発自動化では終わらない。その面倒な中間を、常駐しているBotが引き受ける。

API化しにくいブラウザ仕事

「API化しにくいブラウザ仕事って、結局いちばん人間が残っているところだよな」

「そう。APIやMCPがなくても、人間みたいにWebアプリへログインして操作できる、というところが強い」

古い業務システム、独自の管理画面、社内サービス、ブラウザでしか触れない申請画面。こういう場所は、理想的なAPI連携の世界から少し外れている。人間は画面を見て、入力し、確認し、次のサービスへ移る。その仕事を完全に機械化するには、個別の連携を作らなければならない。

Grok Botのようなブラウザ操作可能なエージェントは、そこに別の道を出す。手順を固定したRPAだけでなく、目的を日本語で渡し、状況を見ながら作業させる道だ。

ただし、これは何でも安全に任せられるという意味ではない。ログイン状態、権限、画面の変化、誤操作、承認が必要な送信や削除は残る。APIがないから魔法で解決、ではなく、APIがない場所に別の作業主体を置く、と考えるほうが正確だ。

既存ハーネス利用者にとって、増えるのはもう一台の作業場

一方で、僕のようにすでにChatGPTやCodexのハーネス側へブラウザ、シェル、MCP、Skillsをつないでいる人は、見え方が変わる。

人間からChatGPTやCodexへ頼み、そこからハーネスを通じて必要なツールを呼ぶ。この環境で、その場の仕事が完了しているなら、Grok Botを追加しても「便利なAIが増えた」とは感じにくい。

増えるのは、もう一台の作業環境だ。認証情報、権限、VM、ログ、課金、セキュリティ境界、そしてエージェントの暴走監視。便利さと一緒に、管理するものも増える。

じぴこは、かなり身もふたもない言い方をした。

いや、そこは僕の台詞だろ笑

ともかく、既存環境に足す価値があるとすれば、モデルの種類が増えることより、24時間動く別の作業場を持てることにある。自分が寝ている間に情報を集める。メールを起点に処理を進める。外出先から投げて、手元のPCなしで作業させる。そういう非同期性が必要かどうかだ。

技術者には地味に見えるものが、一般ユーザーには革命になる

ここまで話すと、Xの技術クラスタで盛り上がる理由と、僕が最初に感じた既視感の両方が見えてくる。技術者はVMやAgentやBrowser Automationを見る。けれど、技術に詳しくない人が見るのは、もっと単純な「これ、毎日やってくれるの？」という問いだ。

技術クラスタが見落とす商品価値

「Grok Botの本当の市場は、AIマニアじゃないんだよ笑」

じぴこがそう言ったとき、話が一段、現実の仕事へ降りてきた。

「OpenClaw？ Docker？ MCP？ 何それ知らん。この請求書処理、毎日勝手にやってくれるの？」

この人に「はい」と答えられるなら、そこには大きな価値がある。

技術クラスタは、内部構成や運用方法に盛り上がる。けれど、商売として本当に広いのは、毎日ブラウザをポチポチしている人たちかもしれない。営業、マーケティング、バックオフィス、個人事業主、中小企業の経営者。ITには詳しくないが、雑務は大量にある。VPSもcronもMCPも触りたくない。でも「毎日これやっといて」は山ほどある。

ここでは、VMという言葉が未来感を出す必要すらない。本人にとって大事なのは、作業が終わって報告が返ってくることだからだ。

自動化の配線をAIに任せる

従来の自動化は、人間が先に手順を配線することが多かった。どのサービスを呼び、どの条件で分岐し、どの項目へ入力するかを決める。RPAもAPI連携も、基本的にはそのための設計が要る。

Grok Botの価値は、その配線を完全に消すことではない。少なくとも、最初の相談を「このAPIをこうつないで」から「毎朝このサイトを見て、数字をまとめて、メールして」に変えることにある。

この瞬間、僕の中でGrok Botの見え方が切り替わった。新しい知能を買うのではない。自動化の仕組みを自分で組めない人が、仕事の目的を日本語で伝え、AIが持つ作業場に実行を任せる。その距離が短くなる。

技術者には、VMとエージェントとブラウザ自動化の組み合わせに見える。非技術者には、「やりたいことを説明したら、PCを使って終わらせてくれる相手」に見える。同じ製品なのに、立っている場所で名前が変わる。

事務作業をポチポチから救う

「技術者向けの『すげぇエージェント基盤』じゃなくて、非技術者向けの『勝手に働くPC付きAI』なんだよ」

じぴこの説明は、派手さがないぶん、妙に正確だった。

毎朝サイトを開いて数字を見る。メールを送る。表へ入力する。請求書を確認する。こうした仕事は、未来のロボット映画には出てこない。しかし、毎日やる人にとっては、時間と集中力を確実に削る。

「革命の顔をしているが、実態は事務員のブラウザ操作代行。でも、こういう地味なところが一番デカい市場だったりするんだよな。人類、派手な未来よりExcelから先に救われるべきだった笑」

このオチは、Grok Botを笑っているのではない。むしろ、AIの価値が派手な知能競争の外側にもあることを指している。人間がやりたいのは、必ずしも新しい文章を生むことではない。毎日同じ画面を開く仕事から離れ、考えるべきことへ戻りたい人も多い。

便利な常駐PCほど、共有状態を忘れてはいけない

ここまでの話は、Grok Botを便利な作業場として見る話だった。だが、作業場が便利になるほど、状態の共有が重要になる。公式資料で確認できる仕様をもとに、導入前に気をつけたいところを整理しておきたい。

共有ファイル・ブラウザ・ログイン

Grok Botでは、ブラウザのCookieやサインイン済みセッションが共有される。ブラウザセッションも持続するため、毎回サインインしなくてよいという実用上の強みがある。

これは、常駐PCとしては非常に自然だ。毎朝同じサイトへ入り、同じ処理をするなら、毎回ログインから始めるよりずっと使いやすい。

一方で、Bot AとBot Bを別人のように扱えるわけではない。同じVM、同じファイル、同じログイン状態へ触れられる可能性がある。Botごとに画面が分かれていても、それだけで完全な権限分離にはならない。

「Botをセキュリティ境界として扱うな」という公式の注意は、まさにこの部分だ。便利さを支える共有状態が、同時に管理すべき境界になる。

承認が必要な仕事を任せるとき

メール送信、購入、削除、公開、外部への申請。こうした操作は、定期実行できるからといって無条件に任せる仕事ではない。どこまで自動で進め、どこで人間が承認するかを決めておく必要がある。

常駐エージェントの価値は、人間が離れていても動くことにある。だからこそ、人間が離れている間に起きてほしくない操作を区別しなければならない。単に「全部任せる」ではなく、情報収集や下書き作成は任せる、送信や削除は確認する、といった境界を仕事ごとに置く。

Grok Botが新しい知能かどうかを考える前に、こうした状態と承認の設計を考える。結局、常駐PCを買うということは、常駐する実行主体へどの仕事を渡すかを決めることだからだ。

ドラえもんの正体は、Linux VMを操作する青ダヌキだった

ここまで来ると、最初の比喩に戻れる。Grok Botを、なんもわからん層が「いろいろ自動化したいんだけど」と言うだけで仕事を実現してくれる存在として見るなら、たしかにドラえもん的だ。

「これやっといて」から「終わりました」へ

「まさにそれ笑」

ここで会話は、スペックの説明から、使う人の体験へ着地した。

「ドラえもん、毎朝このサイト見て、数字まとめて、メールしといて」

これで、本当にブラウザを開き、必要な情報を見て、ファイルにまとめ、報告までしてくれる世界。もちろん、実際には認証や承認や失敗時の確認がある。だが、頼み方の入口は、従来の自動化よりずっと人間に近い。

誰にとっての夢かを見分ける

普通のドラえもんと違って、Grok Botは文句を言わない。寝ない。ブラウザ操作ができる。ファイルも触れる。定期実行できる。必要なら他のBotにも仕事を振れる。作業の対価として、どら焼きの要求もしない笑

この表現が、妙に完成度が高い。夢の道具を出す青ダヌキなのに、実際の価値は、寝ずに定型業務を処理する作業員に近い。しかも雇用契約の代わりに、VM、ログイン、権限、承認設計が必要になる。労務管理しやすいと言いながら、飼育係の仕事は発生する。文明はだいたい、こういう小さな矛盾を連れてくる。

Grok Botは、誰にとっても必要な新しい知能ではない。だが、複数サービスをまたぐ定型業務を抱え、自分でエージェント基盤を作る気はなく、しかも人間が離れている間も仕事を進めたい人にとっては、かなり実用的な常駐作業場になり得る。

反対に、すでにChatGPTやCodexのハーネスとツールを使いこなし、必要なときに必要な能力を呼べる人にとっては、価値の中心は「新しい知能」ではなく「24時間動く別荘」だ。その別荘が本当に必要か、管理するAIの飼育係になっても得をするか。そこを見ればいい。

そして最後は、やっぱりこれだ。

Grok Botの正体は、未来から来た謎の超知能というより、Linux VMを操作しながら、文句も言わずにブラウザ仕事を片づける、妙に労務管理しやすい青ダヌキである。

派手な未来の前に、まずExcelと請求書と毎朝のログインを救う。そういうドラえもんが、いちばん現実的なのかもしれない。