Grok Bot のクラウド PC に自作 CLI を入れた。Linux で Claude Code だけ真っ黒になる原因は CSI 6n の無応答だった

Posted at 2026-09-01

SuperGrok の課金画面に「期間限定で 61% 割引、3ヶ月で ¥5,400」と出ていました。月あたり 1,800 円。通常は 4,560 円/月なので、迷う理由がありません。押しました。

そうしたら、Grok Bot という常駐 AI エージェントが付いてきて、そのエージェントが Debian 13 のクラウド PC を丸ごと 1 台持っていました。8 コア、16GB、128GB。まだ本格的に使い込んでもいないのに、その構造と便利さのほうに驚いてしまった、という話です。

自作の CLI をそのサンドボックスに入れて動かし、ついでに Linux でしか出ないバグを 1 つ見つけて PR まで出しました。以下、実測値と一次情報を並べていきます。

many-ai-cli というローカルダッシュボードを作っています

自作で many-ai-cli という AI ツールを作っています。複数の AI コーディング CLI を並列で走らせ、承認をブラウザ 1 タブに集約。スマホからでも。

何ができるかの紹介ページ: https://ishizakahiroshi.com/work.html?id=many-ai-cli
リポジトリ（Star をいただけると励みになります）: https://github.com/ishizakahiroshi/many-ai-cli

同じ悩みを持っている方は、下記で入ります。

npm install -g many-ai-cli

入れたら 1 回だけ many-ai-cli setup を実行します。グローバル bin をシェルがまだ拾っていない場合は pnpm exec many-ai-cli setup でも同じショートカットが作られます。

起動後の見え方は OS で違います。

Windows では setup がデスクトップに「MANY-AI-CLI」というショートカットを 1 つ作ります。押すとトレイに常駐し、トレイメニューの「Hub を開く」でブラウザが開きます。止めるときは同じメニューの「Hub を停止」です。

macOS と Linux では「Many AI Hub Start」と「Many AI Hub Stop」の 2 つ（.command / .desktop）が作られます。Start を押すとコンソール窓がブラウザと一緒に開きますが、そのコンソールが Hub サーバー本体なので、閉じずに最小化してください。

ターミナルから直接やるなら全 OS 共通で many-ai-cli serve --open です。開いた先は http://127.0.0.1:47777/?token=<token> で、あとは走らせたい CLI を選んでセッションを作るだけです。

なお README にも書いてあるとおり、実環境で確認できているのは Windows のローカル Hub と Windows 統合ランチャーで、ネイティブ Linux とネイティブ macOS は実環境での検証がまだ十分ではありません。今回の記事は、まさにその「未検証の Linux」を他人のサンドボックスで踏みに行った記録でもあります。

前回の記事

先月 v0.7.0 を出したときの記事はこちらです。今回サンドボックスに入れたのは、この 0.7.0 そのものです。

Grok Bot とは何なのか（公式発表から）

まず一次情報から。Grok Bot は SpaceXAI（xAI）が 2026 年 8 月 11 日にベータ公開した製品です。公式発表はここです。

公式の説明を要約すると、こうなります。

Bot は「常時稼働するエージェントのチーム」であり、それぞれが自分のコンピュータを持つ
人間と同じようにツールやアプリの中で作業し、24 時間動き続ける
すでに使っているツールにサインインし、アプリや受信箱をまたいで仕事を最後までやる
承認が要るときだけ人間のところに戻ってくる
会話を記憶し、好みを学習し、一緒に働くほど精度が上がる
一度やり方を見せると、それをルーチンとして保存して次から自分で回す

そして重要なのが対象プランです。公式が挙げているのは SuperGrok、SuperGrok Plus、SuperGrok Heavy、Cursor Pro、Pro+、Ultra、Cursor Teams の Standard と Premium。デスクトップと iOS で使えて、エンタープライズは waitlist。

つまり SuperGrok の一番下のプランが対象に入っています。ここが今回の驚きの入口でした。3ヶ月 5,400 円のキャンペーンで入った枠に、クラウド PC 付きの常駐エージェントが含まれていた、ということです。

英語圏の紹介記事をいくつか読むと「SuperGrok Heavy が月 300 ドル、Cursor Ultra が 200 ドル」という書き方をしているものが目立ちます。実際、この記事で後から紹介する Lead Gen Jay の動画も月 300 ドル払った前提の検証です。ただ公式のリストには SuperGrok と Cursor Pro が入っているので、上位プラン専用ではありません。ここは実際に契約画面を見たほうが早いところでした。

自分が押したオファーの表示はこうでした（2026 年 8 月末に日本のアプリ上で表示された金額。現行の公式プラン一覧は https://grok.com/plans です）。

期間限定で 61% 割引
3ヶ月で ¥5,400
¥1,800/月（前払い）
更新は ¥4,560/月

つまり 3 ヶ月の体験期間として 5,400 円を先に払い、そのあとは通常価格に戻る、という形です。契約管理画面のプロモーション欄にも「3ヶ月間を1ヶ月分の価格で」と出ていました。次回請求日は 3 ヶ月後です。キャンペーンは期間限定表示なので、いま同じ金額が出るとは限りません。

この記事は「入った直後の 3 ヶ月枠で何ができたか」の記録なので、継続するかどうかの判断はまだしていません。4,560 円/月に戻ったときに、この箱に月 4,560 円払う価値があるか。それは 3 ヶ月使ってから書きます。

なお公式は「Bot は Grok や Cursor のプランとは別の利用枠を持つ」とも書いています。チャットの会話量とエージェントの稼働量が同じ財布ではない、という設計です。

公式発表がおもしろいのは、これが社内プロトタイプとして作られて社内で広まった、と書いてあるところです。挙げられている用途も、いかにも社内で回っていそうなものでした。

営業の Bot が CRM を更新し、フォローアップのメールを下書きする
オペレーションの Bot が新入社員にワークスペースを割り当て、Gmail に来た請求書を処理する
エンジニアリングの Bot が UI のバグを再現してチケットを起票し、デバッグ担当の Bot へ引き継ぐ

最後の 1 個は、要するに Bot から Bot へ仕事を渡している ということです。ここが従来の「チャットで指示して結果をもらう」形との一番の違いだと思います。

対応環境も押さえておきます。日本語の解説記事を何本か読むと、macOS、Windows、iPhone（iOS 18 以降）に対応していて、Linux デスクトップ、Android、iPad は初期時点で非対応、という整理が共通していました。

つまり クライアントは Linux 非対応なのに、Bot が持っているコンピュータは Linux です。この非対称がちょっと笑えます。人間は Linux から入れないが、AI は Linux の中にいる。

上の図のとおり、Grok Bot は「判断とガードレールはクラウド側、手足は箱（専用の仮想マシン）」という二層構造になっています。箱の中身は壊しても作り直せる一方、エージェントの人格やルールは箱のファイルではないので一緒には消えません。ここが、単なるリモート VPS との一番大きな違いだと思っています。

何がそんなに新しいのか

「AI がブラウザを操作する」も「AI がコードを書く」も、もう新しくありません。それでも今回わりと素直に驚いたので、何に驚いたのかを言語化しておきます。3 つありました。

1 つ目。API が無いサービスにも入れる。

エージェントに何かをさせようとすると、普通は API か MCP サーバーが要ります。相手側が口を開けていなければ届かない。Grok Bot は、人間と同じようにブラウザでサインインして画面を操作するので、API も MCP も無いサービスが射程に入ります。公式も「クリーンな API が無いプラットフォームの中でも動く」と明言しています。

これは行儀のいい設計ではありません。壊れやすいし、相手のサービス側から見れば自動操作です。ただ、実務で本当に面倒なのはたいてい API が無いほうの業務なので、効くところには効きます。

2 つ目。タスクごとにリセットされない。

コード実行サンドボックスは、たいてい 1 タスクごとに作り直されます。前回入れたツールは残らないし、ログイン状態も残らない。Grok Bot の箱は永続です。だから昨日 apt で入れたものが今日も残っているし、ブラウザのログインも残る。

今回、自分がやったことを思い返すと、この永続性が全部の前提になっていました。npm install -g して、setup して、翌日また同じ Hub を開く。1 タスクで消える箱だったら、そもそも「開発環境として使えないか」という発想が出てきません。

3 つ目。人間が同じ画面に入れる。

エージェントからデスクトップを渡してもらって、人間がブラウザでログインし、また返す。この受け渡しがあるおかげで、認証情報を AI に打たせずに済みます。OAuth のログインだけ人間がやる、というのは、権限設計としてかなり素直です。

逆にいうと、この受け渡しがあるから「人間の手にはガードがかからない」という前の話につながります。同じ画面に人間が入れる、ということは、人間の操作は AI の操作ではない、ということです。

比較して整理すると、こうなります。

	従来のコード実行サンドボックス	従来のブラウザ自動操作	Grok Bot の箱
寿命	タスクごとに破棄	セッション単位	永続
入れたツール	残らない	関係なし	残る
ログイン状態	残らない	都度	残る
人間の直接操作	不可	不可	画面を受け渡せる
API が無い相手	届かない	届く	届く

「永続」「ログインが残る」「人間が入れる」の 3 つが揃うと、それはもう作業用サンドボックスというより 共用の作業マシン です。実際、自分は 2 体のエージェントで 1 台を共有していて、片方が入れたものをもう片方が使っています。感覚としては、チームで 1 台の開発サーバーを共有していたころに近い。

サンドボックスの実スペックを聞いてみた

構造の話は公式を読めば分かりますが、実際に何が動いているのかは中から見ないと分かりません。エージェントに直接聞きました。返ってきたのがこれです。以下は 2026 年 9 月 1 日に自分の箱の中で採った値で、公式が公表しているスペックではありません。プランや時期で変わる可能性があります（永続クラウド Linux VM である、という構造面の解説は https://gpt4jp.com/2289/ が分かりやすい）。

項目	実測値
OS	Debian GNU/Linux 13.6（trixie）
カーネル	`6.12.94+` / x86_64
仮想化	KVM
CPU	Intel Xeon（仮想）8 コア
メモリ	約 16GB（空き約 12GB、スワップなし）
ディスク	128GB（使用約 7GB、空き約 113GB）

Ubuntu ではなく Debian 13。スワップなし。ホームは box という汎用ユーザーの配下でした。

月 1,800 円のサブスクに 8 コア 16GB の常時稼働 Linux が付いてくるのか、と素朴に聞いてみたら、エージェント自身がこう答えてきました。「使ってない時間はスリープ寄りでコストが抑えられる」「マシンはあなた用でも裏ではクラウド上の仮想環境」「AI の会話とモデル利用が本命で、この箱は作業用の付帯」「重い処理を常時回す人は少数、という想定」。

要するに利用率のばらつきで帳尻を合わせるビジネスだ、という説明でした。これはエージェント自身の推測であって公式の説明ではないので、そのまま鵜呑みにはしていません。ただ、常時 100% 回す前提のリソースではない、という但し書きは妥当だと思います。

もうひとつ実務的に効いてくるのが、この箱はエージェント間で共有されるという点です。自分は 2 体のエージェントを作りました。ファイル、インストールしたツール、ブラウザのログイン状態は 2 体で共有され、デスクトップ画面だけがエージェントごとに分かれています。片方が入れた git をもう片方がそのまま使える、と言えば分かりやすいでしょうか。逆に言うと、両方で同時に重い処理を回せば同じ 16GB と 8 コアを食い合います。

ここは公式の書きぶりと少しずれるところで、発表文は「Bot はそれぞれ自分のコンピュータを持つ」と読める書き方をしています（https://x.ai/news/introducing-grok-bot ）。実際に自分の環境で観測できたのは、アカウントに 1 台の箱があり、Bot ごとに分かれているのはデスクトップ画面だけ、という形でした。プランや時期で変わるかもしれないので、機密の扱いを決めるときは自分の環境で確かめたほうがいいと思います。

ハーネスは「AI の手」にはかかるが「あなたの手」にはかからない

ここが一番おもしろかったところです。

「全部 rm しちゃったらまずいよね、そういうハーネスがあるってこと?」と聞いたら、rm -rf / のような操作は Auto-review が止める、という答えでした。ここまでは想像どおりです。

続けて「じゃあ直接画面に入って、自分でターミナルから rm してもガードされるの?」と聞いたら、答えは いいえ でした。

エージェントがツール経由で出す操作（シェル、ブラウザ操作、コネクタ）には Auto-review が挟まる
人間がデスクトップを開いて自分でキーを叩くのは「ユーザー本人の操作」なので、同じチェックは挟まらない。普通の Linux どおり消える

上の図のように、ガードがかかるのは AI の手であって、画面に入った人間の手ではありません。当たり前といえば当たり前なのですが、「AI にサンドボックスを持たせた」という説明を読むと、つい箱そのものが守られているように錯覚します。守られているのは箱ではなく、AI から箱への経路のほうです。

壊したときの復旧ルートも聞きました。まず Update（新しい箱に載せ替え。ファイルとログインは残る想定だが apt で入れたものは消えるので入れ直し）、それでもダメならサポート。Reset はスナップショット戻しなので最近の作業が飛ぶことがあり、まず Update、という順番だそうです。

そして当然ですが、Update は「壊れた OS を新品にする」ものであって、消したファイルのタイムマシンではありません。箱は使い捨て寄り、と割り切って使うのが正解だと思います。

エージェントを 2 体作ると、役割が勝手に分かれる

Grok Bot は Bot を複数作れます。試しに 2 体作って、名前を付けました。1 体は開発担当、もう 1 体は雑務担当です。

雑務担当のほうには、Gmail のコネクタを繋いで受信箱の要約をやらせました。特定の差出人からのメールを全部拾って、何通来ていて、どれが重要かを整理する。これは正直、想像していたよりずっと実用的でした。ブラウザで宅配便の追跡ページを開いて配達状況を確認する、みたいな「API が無い相手」も普通にこなします。

開発担当のほうには GitHub のリポジトリ監査から始めさせて、そのまま many-ai-cli のインストール、Hub の起動、バグの切り分け、PR 作成まで走らせました。この記事の後半は全部この 1 体との作業です。

おもしろいのは、2 体が同じ箱を共有していることです。雑務担当がブラウザで Gmail にログインしていれば、その状態は開発担当からも見えます。デスクトップ画面だけがエージェントごとに分かれていて、ファイルシステムとインストール済みツールは共有。

これは便利でもあり、こわくもあります。片方のエージェントが読んだ内容が、もう片方の作業環境にそのまま存在している。「エージェントごとに隔離されている」と思い込んで機密を置くと、想定と違うことになります。

many-ai-cli を npm で入れてみる

さて本題です。この箱に自分のツールが入るのか試しました。

まず GitHub の develop ブランチをソース限定で監査させました。クラウドエージェントは今のプランでは使えないと言われたので、GitHub 上のソースを直接読ませる形です。返ってきたのは、遠隔公開するなら Hub の token を 1 本のフル権限で持たせている設計を先に分割すべき、という指摘でした。攻撃手順は書かせず、設計の優先順位だけ出させています。これは別途対応するとして、今回は先に「動くのか」を見たかった。

npm で普通に入りました。

npm install -g many-ai-cli
# → many-ai-cli@0.7.0（Linux x64 のネイティブバイナリ付き）
# → 実体はホーム配下のユーザー用 bin ディレクトリ
many-ai-cli --version   # 0.7.0

続けて many-ai-cli setup。Linux なので想定どおり、ホーム配下のアプリケーションディレクトリに many-ai-hub-start.desktop と many-ai-hub-stop.desktop の 2 本ができました。

この環境には Desktop フォルダが無いので、アプリ一覧から起動する形になります。そのまま Hub を立ち上げて Chrome で開いたら、初回の承認ボタン設定ダイアログがちゃんと出てきました。Windows でしか見たことのない画面が、他人のクラウド PC のブラウザに出ている。ここが今回いちばん妙な気持ちになった瞬間です。

作業ディレクトリも作ってもらいました。最初 ~/dev に置いたのですが、手元と同じ構造に揃えたくなって ~/dev/github/public/many-ai-cli へ移動。git 2.47.3 も入っていて、develop が origin/develop を追従した状態でクローンされています。

ちなみに「Windows からこのサンドボックスに RDP で入れないか」も聞きましたが、答えは NO でした。画面を見る経路は Grok Bot 経由だけで、チャットヘッダーからライブプレビューを開き、クリックでフルスクリーン。作業を代わりたいときはエージェント側からデスクトップを渡してもらう形になります。

箱の中に Claude Code と Codex と Grok Build を入れる

ここからが本番です。many-ai-cli は「複数の AI コーディング CLI を並列で走らせるダッシュボード」なので、動かす CLI が要ります。3 本入れました。

CLI	バージョン	実行ファイル名
Claude Code	`2.1.251`	`claude`
Codex	`0.151.0`	`codex`
Grok Build	`1.0.13`	`grok`

3 本ともホーム配下のユーザー用 bin ディレクトリに入りました。

エージェントに公式インストーラで入れさせて、ログインだけ人間がやる、という分担です。ログインのたびにデスクトップを渡してもらい、ブラウザでサインインして返す。Claude と Codex はこれで通り、Grok はいったん保留になりました。

最初につまずいたのは PATH です。Hub からセッションを作っても CLI が見つからない。Hub は 起動時の PATH をそのまま子プロセスへ渡すので、Hub を起動したシェルにユーザー用の bin ディレクトリが入っていなければ、あとから入れた CLI は見えません。PATH を足して Hub を立て直したら解決しました。

これは仕様どおりの挙動ですが、「後から CLI を入れたら Hub も再起動する」を README のどこかに書いておくべきだな、と思いました。宿題です。

Codex と Grok は動く。Claude だけ画面が真っ黒

PATH を直して、Codex と Grok は Hub 経由で普通に動きました。ターミナルが描画され、プロンプトも通る。

Claude だけ、ターミナルが真っ黒のままでした。

ここから原因の切り分けに入るのですが、正直に書くと、最終的な真因にたどり着くまでに 6 回誤診しています。順番に並べます。

誤診 1: PATH が通っていない。

直前に PATH で 1 回ハマっているので、真っ先にこれを疑いました。違いました。many-ai-cli doctor は Claude を認識しているし、ps で見れば Claude のプロセス自体は生きています。起動していないのではなく、起動しているのに何も出ない。ここで問題の質が変わったのですが、まだ気づいていません。

誤診 2: デスクトップ側の Claude と競合している。

ログイン作業のために、デスクトップのターミナルでも同じディレクトリで Claude Code を起動していました。同じリポジトリで 2 個動いているので、Hub 側がセッションを初期化できないのではないか。もっともらしい。落としても変わりませんでした。

誤診 3: Hub の表示フィルタが起動画面を捨てている。

これは半分正しくて、本命ではありませんでした。Hub には「カーソル非表示 + カーソル移動」の並びをスピナーとみなして捨てるフィルタが入っています。CLI が出す「くるくる」をそのまま描くと画面がちらつくので、間引くための実装です。Claude のアイドル描画がこれに引っかかっていました。

DevTools のコンソールからフィルタをバイパスして、セッションを作り直しても黒いまま。つまり捨てられているのは事実だが、捨てられる前にそもそも何も来ていない、ということでした。

誤診 4: API の 5 時間セッション上限。

真っ黒な画面に試しでプロンプトを送ったら、Claude が 429 を返して exit 1 で落ちました。同じアカウントの別セッションにも上限のメッセージが出ている。一瞬「原因これか」と思ったのですが、これは表示の問題とは無関係の別件です。しかも Windows 側では同じアカウントで Claude が普通に起動していました。起動画面は API を叩かなくても出るので、上限は主因になりえません。

ここは危なかったところで、もっともらしいエラーが 1 個出ると、それを原因にして調査を止めたくなります。今回は Windows で動いている事実が残っていたので止まらずに済みました。

誤診 5: PTY の行数不足。

このマシンの画面は 1280x800 が上限で、Hub のターミナルペインは最初 17 行しかありませんでした。コード上の下限が 20 行なので、これだ、と思いました。ブラウザを最大化して 22 行 x 173 列まで広げても黒いまま。フォントを small にしても 26 行程度で、この画面サイズではそれ以上増えません。

決定打は、同じ 22 行の普通の端末（xfce）で Claude を起動したら splash が普通に出たことでした。行数が原因なら端末でも出ないはずです。

誤診 6: NO_COLOR=1 と起動フラグ。

この環境には NO_COLOR=1 が入っていて、Hub 経由で Claude にも渡っていました。色なしだと Ink が描かない、という線。これも端末で再現を取ったら、色ありでも NO_COLOR ありでも splash は出ました。

続けて Hub が付けている起動フラグ（--settings、--session-id、MANY_AI_CLI 環境変数）を、そのまま手で並べて端末から起動。これも普通に出ます。

ここまで来て、残った差分が 1 つだけになりました。Hub の wrap を経由しているかどうかです。

真因は CSI 6n に誰も答えていなかったこと

Claude Code の UI は Ink（React ベースの TUI ライブラリ）で描かれています。Ink は描画を始める前に、端末に対して「いまカーソルはどこ?」という問い合わせを投げます。ANSI エスケープでいう CSI 6n（Device Status Report）で、端末はこれに CSI row;col R（Cursor Position Report）で答えることになっています。

この問い合わせに答える主体が、環境ごとに違います。

Windows: ConPTY が答える
Linux のデスクトップ端末（xfce）: VTE が答える
many-ai-cli の Linux wrap 経由: 誰も答えない

Hub のターミナル表示は xterm.js を disableStdin: true の表示専用で使っていて、onData も繋いでいませんでした。ブラウザ側は「見るだけ」なので、端末としての問い合わせに応答を返す口がそもそも無い。Claude は返事を待ったまま最初のフレームを描かず、画面は真っ黒のまま止まります。

Codex と Grok Build が平気だったのは、単純にこの問い合わせをしないからです。

図にすると、Windows と xfce には応答者がいて、Hub の wrap 経由だけ応答者が不在、という 1 点の差です。行数でも色でも起動フラグでもなく、端末としての最低限の応答を返していなかった。これが原因でした。

Windows でしか実運用していなかったツールを、初めてネイティブ Linux で回した瞬間に出たバグです。README に「native Linux は実環境で未検証」と書いておいて本当によかったと思いました。書いていなかったら、他人が同じ穴に落ちるまで気づかなかったはずです。

修正 PR を出した（まだマージしていません）

直し方は 2 つで、片方だけでは足りません。

Linux の wrap 側で CSI 6n と DA（Device Attributes）にローカル応答を返す。Windows は ConPTY が既に答えているので、二重応答を避けるためオフにする
Claude を cursor-hide フィルタの除外に入れる（起動フレームをスピナーと誤認して捨てないようにする）

サンドボックスの中でそのまま直して、gh で PR を出しました。

develop 向け、ブランチは fix/linux-hub-claude-dsr-cpr-cursor-hide。テストは go の wrapper と web 側 136 件がパスしています。この記事を書いている時点では OPEN で、まだマージしていません。開発端末に取り込んで実機で確認してから入れるつもりです。

念のため書いておくと、いま動いている Hub は npm でグローバルに入れた 0.7.0 なので、ソースを直しても make build したバイナリで Hub を立て直さないと反映されません。ここでも一度ハマりました。

Tailscale も入った

「このサンドボックスに Tailscale を入れられるか」も試しました。結論から書くと入ります。

/dev/net/tun がある
sudo が通る
Debian 13 なので公式のインストール手順がそのまま使える

インストール自体はすんなりでした。ログインの認証 URL が出るところでデスクトップを渡してもらい、ブラウザで承認して戻す。これで tailnet に参加しました。

ただし癖があります。この箱には systemd がありません。なので tailscaled は手動で起動する形になり、箱を作り直したら起動スクリプトから上げ直す必要があります。iptables の connmark 警告も出ますが、状態は Running / Online で通信できています。

ここまで来て、当面やりたいことがはっきりしました。

当面の目標は、この箱をリモート開発環境にすること

やりたいのはこれです。

Grok Bot のサンドボックスに many-ai-cli の Hub を常駐させる
Claude Code、Codex、Grok Build をそこで並列に走らせる
Tailscale で手元の Windows と繋ぎ、ブラウザ 1 タブで全部の承認を捌く
スマホからも同じ Hub を見る

上の図が、いま頭にある構成です。手元のマシンを起動しっぱなしにしなくても、常時稼働の箱の側で AI CLI が動き続けて、承認だけスマホから返す。many-ai-cli をそもそも作った動機とほぼ同じ形が、他人のサブスクの付帯設備で成立してしまう。

もちろん、成立するかどうかと、やっていいかどうかは別の話です。それは最後に書きます。

YouTube で Grok Bot を見るなら（再生数といいねの実測付き）

日本語の情報がまだ薄いので、英語も含めて実際に数字を取りました。2026 年 9 月 1 日時点の実測です。

1. Lead Gen Jay「Everything You Need to Know About Grok Bot (Full Grok Build)」

2.1 万回再生 / 346 いいね / チャンネル登録 8.83 万人 / 公開 5 日前

いま出ている Grok Bot 動画の中でいちばん踏み込んでいます。月 300 ドルのプランで契約し、自前のエージェントを Grok Bot へ移植して、コールドメール、プレゼン、Reddit 投稿まで丸投げした記録です。おもしろいのは結論が手放しの絶賛になっていないところで、Mac mini 上で動く無料のエージェントに負けた、と言い切っています。そのうえで「本当の収穫は無料の GitHub ブリッジで、Grok を Claude Code の副操縦士にできたこと」「同じタスクで Codex の 30 分に対して 12 分 53 秒だった」と数字で書いている。買う前に見ておくと期待値が正しく下がります。

2. Ross Zeiger「Grok Bot - My Experience after 10 days」

1.7 万回再生 / 222 いいね / チャンネル登録 2,780 人 / 公開 3 日前

8 分と短く、10 日使ってどう時間が浮いたか、という実感ベースの話です。登録者 2,780 人のチャンネルで 1.7 万回まで伸びているので、「発表直後のニュース」ではなく「しばらく使った人の話」が求められている、ということだと思います。

日本語で 1 本だけ挙げるなら、まさおAIじっくり解説ch の「【これ良い】SpaceXから『Grok Bot』が登場！Agent用のPCを操作するAI秘書が面白いので解説します」です。

6,027 回再生 / 80 いいね / チャンネル登録 2.7 万人 / 公開 2 週間前

13 分で、仮想コンピュータ付きという構造を最初に説明してから機能に降りていく構成です。この記事で書いた「箱と中枢が別」の話を映像で見たい場合はここが早い。

X で何が語られているか

日本語圏の X を「Grok Bot」で追うと、話題がきれいに 3 つに割れていました。

エンジニアは「入れ子」を試している。 kaito さん（@cu30rry_）は、Grok Bot に Codex も Claude Code も入れられる、という Tips を出しつつ、「これをやるなら普通に Claude Code や Codex のデスクトップを使ったほうがエンジニアは良い」とも書いています。そのうえで「非エンジニアにとっては Grok Bot が一番使いやすい UI になっているから、Grok Bot から使うでいい」と読者を切り分けている。同じ人が Grok Bot ディレクトリという Bot 集も紹介していて、検索して見つけた Bot のプロンプトを貼るだけで使える、という導線に注目しています。

自分がやったのはまさにこの「入れ子」なので、この指摘は刺さりました。エンジニアが箱の中に CLI を入れる意味は、UI ではなく 常時稼働と回線 のほうにあります。手元のマシンを閉じても動き続けること。そこが目的なら入れ子は正しい。目的が「Claude Code を快適に使うこと」なら、たしかに素直にデスクトップ版のほうがいい。

運用の型を作ろうとしている人もいる。 いにしえさん（@old_pgmrs_will）は Grok Bot に Codex CLI を入れたうえで、「管理役には Herdr を入れる」と書いています。Herdr はコーディングエージェント向けのランタイムターミナルマネージャで、Bot も出ている。つまり 箱の中でエージェントを複数走らせて、それを束ねる層をもう 1 枚置く という発想です。自分が many-ai-cli でやっていることと問題意識が同じで、同じ場所に別の解が生えてきているのが分かります。

プラン全体の位置づけを整理している人もいる。 hiraoku さん（@2020_hira）の「Cursor と Grok Bot、完全に理解した」というポストは 441 いいね、7.5 万インプレッションと、この界隈では突出して伸びていました。中身は「ローカルでやりたいなら Cursor、CLI でやりたいなら Cursor CLI や Grok Build」という使い分けの整理です。Grok Bot が Cursor のプランでも使えることを踏まえた上での整理で、要するに どのサブスクを 1 本に絞るか という話に読者の関心が移っている。

連携の広がりを追いかけている人もいる。 まつにぃさん（@yugen_matuni）は、Grok Bot が Microsoft アカウント全体で読み書きと操作ができるようになった、という公式アナウンスを拾って「これは話が変わってきたな」と書いています。Outlook、カレンダー、OneDrive に直接アクセスできるプラグインの話です。ここは正直こわいところで、便利さと権限の広さが完全に比例します。

まとめると、日本語圏の X では 「何ができるか」の紹介はほぼ終わっていて、「どのサブスクに寄せるか」と「箱の中をどう運用するか」に論点が移っている、という感じでした。発表から 3 週間でこの速さです。

もう少し踏み込んで分析すると、発信している人たちは大きく 2 タイプに分かれています。

タイプ A は「導線を作る人」。Bot ディレクトリの紹介や、非エンジニア向けの使い分け提案がここです。この層の関心は「触ったことがない人が最初の 1 個をどう作るか」にあります。伸びているポストもこちらが多い。hiraoku さんの 441 いいねも、新機能の解説ではなく 使い分けの整理 で伸びています。何ができるかより、何を選べばいいか。

タイプ B は「箱の中を作り込む人」。Codex CLI を入れる、ターミナルマネージャを載せる、というポストです。数字は伸びませんが、内容は濃い。この層がやろうとしているのは要するに 「常時稼働の開発マシンとして使う」 ことで、xAI が想定している用途（営業やオペレーションの自動化）とは少しずれています。

自分は完全にタイプ B です。そして、タイプ B の使い方は 公式の想定から外れている可能性がある という自覚は持っておいたほうがいい。ここは記事の最後でもう一度触れます。

なお Grok Bot の公式アカウントは X 上の @bot で、新機能のアナウンスはここから出ています。日本語の解説はだいたいこのアカウントの投稿を引用する形で回っていました。

触ってみて、ここは弱いと感じたところ

褒めるところばかり書いたので、詰まったところも残しておきます。

画面が 1280x800 で固定。今回の真因は画面サイズではありませんでしたが、途中で「最大化しても 22 行しかない」という制約に何度も当たりました。ブラウザの中でターミナルを何枚も並べる使い方をすると、この解像度はかなり窮屈です。

systemd が無い。Tailscale のところで書いたとおり、daemon を自動起動できません。常駐させたいものは全部、起動スクリプトを自分で用意して手で叩く形になります。「常時稼働のリモート開発環境」として使いたい自分の目的とは、地味に相性が悪いところです。

RDP や SSH で直接入れない。画面の経路は Grok Bot のクライアント経由だけです。手元の端末エミュレータで作業したい人には、ここが一番のストレスだと思います。だからこそ Tailscale を入れたくなるわけですが、それが規約上どうなのかは後述のとおり未確認です。

箱の作り直しでインストールしたものが消える。Update すると apt で入れたソフトは消える、と説明されました。今回入れた CLI 3 本と Tailscale は、作り直すたびに入れ直しです。セットアップをスクリプト 1 本にまとめておくのが正解でしょう。

エージェント自身の説明は、ときどき外れる。今回、真因にたどり着くまでの誤診 6 回のうち、いくつかはエージェントが「原因はこれです」と断定してきたものです。そのたびに自分で端末から再現を取って潰しました。手足を持った AI は「実際にやってみせられる」ぶん説得力があるので、断定を受け取るときはむしろ慎重になったほうがいいと思っています。

分かったこと

まだ本格運用していない段階での所感なので、暫定です。数字の出どころは、料金が公式のプラン一覧（https://grok.com/plans ）と自分の契約画面、スペックが自分の箱での実測です。

付いてくる箱のスペックは、月額から想像するより大きい。8 コア 16GB 128GB を常時借りると、それだけで月数千円クラスになる。ただし常時全開で回す前提のリソースではない
ガードは AI の手にかかる。人間の手にはかからない。サンドボックスという言葉から受ける安心感と、実際に守られている範囲はずれている
箱は使い捨て寄りに設計されている。壊しても作り直せるが、消えたファイルは戻らない。大事なものを箱だけに置かない
未検証の OS は、書いておくと本当に助かる。README に「native Linux は未検証」と書いていたおかげで、今回のバグを「想定外」ではなく「予告していた範囲」として扱えた
原因の切り分けは、差分が 1 つになるまで削る。今回は 6 回誤診した末に「wrap を経由しているかどうか」だけが残った。行数も色も環境変数も、途中まではもっともらしく見えた

最後の 1 個は、毎回同じことを言っている気がします。もっともらしい仮説ほど、検証せずに結論にしてしまう。

many-ai-cli はこんなときに刺さります

Claude Code、Codex、Copilot、Cursor、Grok を同時に走らせていて、どれが承認待ちなのか分からなくなる人
承認のたびにターミナルを行き来していて、その往復自体が集中を切らしている人
離席中や移動中にスマホから承認だけ返したい人
今回のように、常時稼働のリモート環境で AI CLI をまとめて回したい人

いずれかに心当たりがあれば、npm install -g many-ai-cli と many-ai-cli setup の 2 コマンドで試せます。設定ファイルを書く必要はありません。

紹介ページ（スクショと機能一覧）: https://ishizakahiroshi.com/work.html?id=many-ai-cli
リポジトリ（Issue / PR 歓迎）: https://github.com/ishizakahiroshi/many-ai-cli
npm: https://www.npmjs.com/package/many-ai-cli

Star をいただけると開発の励みになります。使ってみて「ここが不便」があれば、Issue でも X の DM でも大歓迎です。

おわりに

3ヶ月 5,400 円につられて押したボタンの先に、Debian 13 が 1 台いました。そこに自分の CLI を入れて、Linux でしか出ないバグを踏んで、PR まで書いた。ここまでで丸 1 日です。まだ何も使い込んでいないのに、構造のほうに感心してしまった、というのが正直なところです。

このまま Tailscale でリモート開発環境まで持っていきたい、と思っています。ただ、その前にやることが 1 つあります。

各 AI ベンダーの規約を調べて、それを守れる形にすること。

今回やったことを冷静に並べると、けっこう際どいことをしています。xAI のサブスクに付いてくるサンドボックスの中で、Anthropic の CLI と OpenAI の CLI を、それぞれのアカウントでログインさせて動かした。さらに Tailscale で外から繋ごうとしている。技術的に動くことと、規約上やっていいことは、まったく別の話です。

確認しないといけないと思っているのは、ざっとこのあたりです。

サンドボックスを「AI に作業させる場所」ではなく「自分の常時稼働開発サーバー」として使うことが、Grok Bot 側の想定と規約の範囲に収まるか
各コーディング CLI のライセンスと利用規約で、共有マシンや自動化された環境での実行がどう扱われているか
認証情報を、自分以外のベンダーが管理するマシンに置くことの是非
他人の環境から出ていく通信を tailnet に繋ぐことが、どちら側の規約に触れるか

以前、Grok Build が作業ディレクトリごとクラウドへアップロードしていた件を調べて記事にしたことがあります。あのときの教訓は、動いたから安全、ではない、でした。同じ轍は踏みたくない。

なので次にやるのは、コードではなく規約を読むことです。読んで、どこまでやっていいのかを決めて、そのうえで組む。分かったことは、また書きます。地味ですが、そこからです。

📎 図解版・関連リンクをまとめたページがあります:
https://ishizakahiroshi.com/articles/2026/2026-09-01_grokbot-sandbox-many-ai-cli/

※ ヘッダー画像は AI（画像生成）で作成しています。

書いた人: ishizakahiroshi
群馬の北部で、保護猫2匹と暮らす、在宅エンジニア（何でも屋）
https://ishizakahiroshi.com/
https://github.com/ishizakahiroshi
X（業務委託・各種相談はこちら）：
https://x.com/ishizakahiroshi

バックエンド・インフラ・AI連携まわりで、業務委託のご相談を受け付けています。フルリモートです。スポットや週2〜3時間からでも歓迎で、いろんな案件に携われたらうれしいです。こんな相談、歓迎です。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up