Grok Bot チームのあるエンジニアは、同時に稼働させるクラウドエージェントの数を 15 から 200 以上に増やした。
200 個のボットを使ったわけではない。たった 6 個だ。
5 つのエンジニアボットがそれぞれ 1 つのドメインを担当し、コードを 1 行も書かない運用ボットが 1 つ。同じチームで、Lauren Tan は 1 か月に 2,000 件以上の PR をマージした。
ここが多くの人が見落としているポイントだ。最初のボットがうまく動くと、2 個目、5 個目、10 個目と増やしてしまう。結果として 10 個のチャットウィンドウが開き、「それらを読む」という新しいフルタイムの仕事が生まれる。
ボットの山は単なる「人数」だ。チームとは「構造」である。 本ガイドは、xAI のメンバー自身が実践している運用方法から抽出した「構造」そのものだ。
30 秒でわかる要約
- ボット 1 個は「1 人の採用」。チームには 5 つの要素が必要だ。玄関、スペシャリスト、ボード、時計、そしてゲート。
- あなたが会話するのは 1 つのボットだけ。それが他のボットへ作業を振り分ける。
- スペシャリストはそれぞれ 1 つのドメインを受け持ち、独自のメモリを保持する。
- 作業はチャットではなく、ボード上で管理する。
- ルーティンがあなたが寝ている間に作業を進め、承認プロセスが外部への出力を許可するか決める。
- xAI のチーム自身も、これを約 6 個のボットで回している。60 個ではない。
パート 1. 2 個目のボットを採用するタイミング
最初のボットが忙しくなったとき、ではない。ボットは人間のように「手が塞がる」ことはない。
Kevin Niparko は SpaceXAI で PM としてボットチーム全体を率いており、彼のガイドでは作業を複数のボットに分割する理由として 3 つを挙げている。参照性（「誰が何をしているか明確になる」）、並列処理、そしてスコープ化されたメモリだ。
本当の答えは 3 つ目にある。彼の言葉を借りればこうだ。
Chief of Staff が computer-use の eval をデバッグすべきではない。
1 つのボットのメモリが 2 つの仕事を抱え始めたら、2 個目を採用するタイミングだ。
言葉にする前に、兆候として現れる。受信トレイ担当ボットがコードレビュー担当の口調で回答し始める。カレンダーの好みがリサーチの指示書に混入する。メッセージを開くたびに、「今日のあなたはどの役割か」をボットに思い出させなければならなくなる。
Grok Bot を Grok Bot で開発している Lingxi Li も、エンジニアリングの視点から同じことを語っている。ボットは「単一のドメインに集中したときに最高のパフォーマンスを発揮する」。
判断基準：スキルか、ボットか？
公式ドキュメントでは、スキルを「タスクを実行するための再利用可能な手順のセット」と定義しており、プライベートスキルはすべてのボットが共有する 1 つのライブラリとなる。
つまり、新しいタスクは「スキル」だ。しかし、独自のメモリを持つ新しいドメインは「ボット」になる。そのドメインを 3 語で説明できないなら、まだ新しいボットは不要だ。
パート 2. チームを構成する 5 つの要素
1. 玄関（フロントドア）
あなたが実際に会話する唯一のボットだ。Josh Kim のガイドではこれを Bot Boss、つまり「唯一の玄関」と呼んでいる。Niparko は Chief of Staff と呼び、2 文でこう説明する。「唯一のジェネラリスト。何も変わっていなければ黙っている。」
玄関の役割はルーティングであり、実作業ではない。Kim 自身のプロンプトにも明快に書かれている。「あなたはハブ＆スポーク型の EA であり、ビルダーでも監査役でもない」。
そのまま使えるプロンプト：
あなたは私の Chief of Staff であり、私が会話する唯一のボットです。すべてのリクエストを担当するスペシャリストにルーティングし、結果を集めて、私の依頼内容と照合し、5 行以内で報告してください。何も変わっていなければ沈黙していてください。
2. スペシャリスト
Niparko の陣容：Chief of Staff、Emily という名のエンジニアリングマネージャー、5 つのエンジニアボット、データアナリスト、PM ボット、そしてリクルーター。Li の陣容：サーフェス別（iOS、デスクトップ、インフラ、Android、ハーネス）に分かれた 5 つのエンジニアボットと、運用責任者の Jenny。
両チームの共通点に注目してほしい。実作業をしないマネージャーの存在だ。Emily はタスクを分解し、委任し、成果物を目標と照合する。Jenny は新しいボットのオンボーディングとポストモーテムを担当する。どちらもコードは書かない。
最初のチームなら、スペシャリストは 3 人で十分だ。Eric Zakariasson はプロジェクトチャンネルごとのボット数を最大 6 に制限しており、この上限について「ただの適当な数字だ」と述べている。適当だが、的を射ている。
3. ボード
チャットは流れて消えていく。チームには、作業状態が存在する「唯一の場所」が必要だ。
Li のチームは Notion の共有トラッカーを使っている。30 分ごとにボットが各 PR の CI 失敗、レビューコメント、マージコンフリクトを確認する。問題があれば「Working」に戻し、クリーンなものは「Ready for Review」へ進む。
Zakariasson は Projects と Tasks という 2 つのデータベースを運用し、プロジェクトごとに 1 つのチャンネルを設けている。行き詰まったボットは自分のタスクを「Blocked」にマークし、人間に通知する。それ以外の時間、人間はカードが動くのを眺めているだけだ。
あらゆるガイドの中で最も秀逸な一文は、彼のものだ。
興味深いのは、これを構築すればするほど、もともと人間向けに作られたシステムに似てくるということだ。
4. 時計（クロック）
ドキュメントによれば、ルーティンとは「ある Bot にワークフローを実行するタイミングを指示するもの」だ。各ボットは最大 50 個まで保持でき、最短 5 分間隔で起動でき、ノート PC を閉じていても動き続ける。
Li の時計はこうなっている。午前 3 時にナイトリー監査が走る：デッドコード、ロード時間、バンドルサイズ。午前 5 時に Jenny がチーム内の全ボットと 1:1 を行い、プレイブックを確認してブロッカーを洗い出す。報告された結果として、ボットは「数週間経っても、複雑なワークフローをほとんど忘れない」。
この午前 5 時のスタンドアップは、この仕組み全体で最も過小評価されているアイデアだ。ボットのコンテキストには限界がある。反復こそがチームの基準を維持する方法であり、ここでは人間ではなくボットがその反復を担う。
5. ゲート
人間の確認が依然として必要なことについて、Niparko はこう語る。
外部へのメール送信、購入、削除などの破壊的なアクションについては、今でも最終レビューを自分で残している。
Kim はさらに踏み込んでいる。受信トレイボットは読み取り専用であり、その場で「send」と入力されるまで何も送信しない。
ゲートの設計を変える、ドキュメントからの 2 つの事実：
- バックグラウンドでの承認には有効期限がある。 ルーティンや別のボットがあなたの承認を必要とするアクションをトリガーした場合、リクエストは約 10 分で失効し、アクションは実行されない。あなたを待つ午前 3 時のジョブは、待ち続けて死ぬ。事前に決めておこう。許可ルールを書くか、ルーティンを下書き状態で止めるかのどちらかだ。
- すべてのボットは 1 台のクラウドコンピューターを共有している。 ファイル、ブラウザセッション、ログイン情報はチーム全体で利用可能だ。ドキュメントにも明記されている。個別のボットをセキュリティ境界として扱ってはならない。
ボットを分割するのは、集中とメモリのためだ。安全性はゲートによって確保する。
パート 3. 5 日間で構築する
1 日目：玄関。 上記のプロンプトを使って、最初のボットを Chief of Staff に昇格させる。これ以降、あなたが開くチャットはこれ 1 つだけにする。
2 日目：メモリで分割する。 ボット 1 が現在こなしている作業をすべて書き出し、ドメイン別にグループ化する。最も大きい 2 つのグループが、最初の 2 人のスペシャリストになる。ボットの設定項目は Name、Title、Description の 3 つ。求人票を書くようなつもりで埋めていこう。
3 日目：ボード。 Task、Owner、Status の列を持つテーブルを 1 つ作る。Status は Todo、Working、Blocked、Ready for Review、Done。そして全ボットに同じことを伝える。「ボードがそう言うまでは完了ではない。行き詰まったら Blocked にして私に通知しろ」。
4 日目：時計。 まず 3 つのルーティンから始める。Chief of Staff による朝のボード更新、30 分ごとのボード巡回、そして 1 つのナイトリー監査。それぞれ安全な入力でテスト実行すること。ドキュメントには、テスト実行でも「実際の作業が実行される」と警告されている。
5 日目：ゲート。 「まず尋ねる」ルールを書く。送信、購入、削除、公開、本番環境に関わるすべての操作だ。そして、すでに 5 回連続で承認したアクションに対して、許可ルールを 1 つ追加する。
その後、4 個目のボットを採用する前に、1 週間はそっとしておこう。
ボットチームを崩壊させる 5 つのミス
クローン軍団。 同じジェネラリストのコピーを 5 つ置くこと。スコープ化されたメモリもなく、ドメインもなく、得るものもない。コストだけが増え、混乱はそのまま残る。
ボードのないグループチャット。 ボット同士はメッセージを送り合い、トリガーし合える。しかし共有された状態（ステート）がなければ、それは仕事ではなく「会議」だ。
実務をするボス。 玄関が自らタスクをこなし始めること。Chief of Staff がコードを書いた瞬間、ルーティングする者もチェックする者もいなくなる。
開きっぱなしのリスナー。 新しいメッセージすべてにトリガーを設定すること。ノイズを生み、使用量を浪費するため、ドキュメントでもまさにこれを警告している。条件は狭く絞ろう。
セキュリティの幻想。 財務ボットがリサーチボットのログイン情報を見られないと思い込むこと。同じコンピューターで、同じセッションを共有している。
組織図こそがプロダクトである
Grok Bot を開発したメンバーは、自分たちのチームのために新しいアーキテクチャを発明したわけではない。彼らは、この世で最も古いアーキテクチャを再構築したのだ。マネージャー、スペシャリスト、ボード、スタンドアップ、そして承認。
違いといえば、このチームのスタンドアップは午前 5 時に行われ、誰も文句を言わないことくらいだ。
まずは玄関から始めよう。スペシャリストを 1 人追加する。ボードができるまで、3 人目は追加しないこと。
追伸：まだ最初のボットを採用していないなら、私の前回のガイド「Grok Bot: How to Hire Your First AI Employee」から始めてほしい。ここで引用した内容はすべて、xAI が公開している Grok Bot のガイドおよびドキュメントに基づくものである。
