きっかけ

X で、SpaceXAI のエンジニア Lauren Tan 氏のワークショップを紹介するgatsby（@0xg4tsby）のポストを見かけました。要点は「チームを拡大する前に、セットアップにトークンを使え」というものです。

その中で、Tan 氏の言葉として引用されていたのが印象的でした。

"You spend the tokens to set up a codebase so that even the dumbest agents can do a good job."
（一番賢くないエージェントでも良い仕事ができるよう、コードベースのセットアップにトークンを使う）

ポストはワークショップの流れを Job → Rules → Skills → Verification → 6 Bots → 200+ Agents と要約していました。要するに、土台（仕事の定義・ルール・スキル・検証）が先で、台数を増やすのは最後。ボットが失敗したからと台数を増やすのは、ミスを量産するだけだ、という主張です。

そして、そのポストの最後で「詳しいセットアップはこちら」と紹介されていたのが、m4lka（@m4lkxx）の長文記事「Grok Bot: 6 Bots, 200+ Agents, a Smaller Bill」です。こちらは Grok Bot（xAI のエージェント基盤）の運用を題材に、6体のボットで200超のエージェントをどう回すかを具体的に分解した実践記事でした。

本記事では、この m4lka の記事の要点をまとめます。ワークショップ動画へのリンクは末尾の「参考」に置きました。

記事内の数値は、筆者や利用者が公開したデータ・試算が中心で、記事自身も一部は「監査済みではない」「目安」と明記しています。以下では「記事によると」の形で紹介します。

問題：トークンの75%は「再読」で消える

m4lka 本人が、執筆前に自分の Grok Bot の利用履歴（grok.com のダッシュボードからエクスポートできる明細）を集計したところ、トークンの75%が過去チャットの再読に使われ、実際の作業は約1%だったそうです。

ただし、集計期間や総トークン数は記事に書かれていません。

同様に利用履歴をエクスポートした他の利用者の申告でも、再読の割合は75〜88%とされています（記事中の具体例では、約9.7億トークンで78%、約7.1億トークンで87.7%）。

理由は単純で、Grok Bot ではすべての返信とルーチン実行が、そのボットの会話全体を再読するためです。つまり料金は次の掛け算になります。

料金 = 起動回数 × 毎回の再読量

15分ごとに起動するボットが、長く育ったチャットを持っていたら、それだけで請求が膨らみます。上位プランを買っても、使える量が増えるだけで、この構造は直りません。

解法の全体像：6つの席と4つの仕組み

では、台数を増やすこと自体が悪いのかというと、そうではありません。

m4lka の記事は冒頭で、ボットを2体目・5体目・10体目と増やして混乱する失敗例を挙げた直後に、その対照例を紹介しています。

Grok Bot を作るチームのエンジニア Lingxi Li 氏は、同時に動かすクラウドエージェントを15から200超に増やしたそうです。ただし、ボットを200体に増やしたのではありません。

常駐の役割としてのボットは6体のままで、その下で200超のエージェントを回した、という話です。

6つの席

「席」はエージェントの台数ではなく、常駐する役割分担のことです。仕事が来たときに、誰が受けるか、誰が進捗を持つか、誰が完了を認めるか、誰が実作業をするか、どれにも当てはまらない依頼はどこへ行くか、を先に決めておくものです。

席	役割
CHIEF	利用者が話す唯一のボット。振り分け専門で、自分では構築しない
OPS	管理者。ボード・スタンドアップ・プレイブックを担当し、実作業はしない
CHECKER	完了可否を決める。証明がなければ「完了」としない
SPECIALIST ×2	1つの領域と専用メモリを持つ実作業担当
MISC	どこにも属さない依頼を受け、専門家の文脈に雑件を持ち込ませない

200超のクラウドエージェントは、この席の下で必要に応じて立ち上がる実行役です。台数が増えても、責任の置き場はこの6つのまま変わりません。だから台数を増やしても混乱しなかった、というのが対照例の肝です。

4つの仕組み

席が「誰がやるか」を決めるのに対して、仕組みは「仕事がどう流れるか」を決めるものです。席だけ決めても、置き場・進むタイミング・外に出す判断・覚え方がなければ、仕事はチャットに流れて消えていきます。そこで次の4つを用意します。

THE BOARD: 仕事の置き場所。チャットの中に置かない
THE CLOCK: 仕事が動くタイミング。リマインダーではなくルーチン
THE GATE: 何を外に出してよいかの関門。判断基準はモデルの確信度ではなく「取り消しコスト」（後から元に戻す大変さ）
THE MEMORY: 保持すべきもの。会話の書き起こしではなく原則

ただし、6つの席と4つの仕組みは最初から全部そろっていたわけではありません。記事は、1体のボットに全部やらせる状態から、役割と仕組みを1つずつ足していく成長の段階として、この成熟度を Level 0〜7 に整理しています。各レベルで増えるものは1つだけです。

Level 0（出発点）: 1つのボットが全役割、利用者自身が振り分け役
Level 1: 説明文（description）でボットが自分の仕事を理解する。席が「役割」を持ち始める
Level 2: 「証明」によって完了に意味を持たせる。CHECKER の考え方がここで入る
Level 3: 利用者は1つの窓口（CHIEF）とだけ話す。入口が1つに絞られる
Level 4: 仕組みの1つ目「ボード」が入り、仕事がチャットから消えなくなる
Level 5: 仕組みの2つ目「時計（ルーチン）」が入り、利用者が寝ている間も進む
Level 6: 仕組みの3つ目「関門」が入り、誤りが小さい範囲にとどまる
Level 7: 仕組みの4つ目「腐らない記憶」が入り、毎週改善する

各レベルの要点

ここからは、Level 1〜7 を1つずつ見ていきます。各レベルは「その段階で何ができるようになるか」と「飛ばすとどうなるか」の2点で読むと分かりやすいです。

Level 0 は、1体のボットに全部やらせて利用者自身が振り分け役になる出発点なので、個別の節は設けていません。

順番にも意味があって、たとえば証明（Level 2）の前に信頼して任せたり、関門（Level 6）の前に自動で回し始めたりすると、後ろの節に出てくる失敗例のようになります。

Level 1：説明文こそが仕事そのもの

各ボットの「説明文」は挨拶文ではなく実質的なシステムプロンプトで、求人票のように書くべきだとされています。ポイントは：

説明文は毎タスクの前に読まれる。ボットを複製すると説明文は引き継がれるが、記憶は引き継がれない。だからルールは記憶ではなく説明文に入れる
書くべきは「役割（所有する成果を1文で）」「入力」「出力（形と保存場所）」「完了条件（他人が確認できる形）」
ルールは「出来事の物語」ではなく「原則」で書く。特定の日付と不具合に紐づいた狭いルールは二度と発火しないが、「レイアウト変更後は操作要素が覆われていないか確認する」のような一般ルールは繰り返し使える

Level 2：信頼より先に証明

「推測する5つのボットより、証明手段を持つ1つのボット」。仕事を渡す前に、機械が読める成功の合図があるかを問います。

コードがある場合：ボットに一度だけ検証ツールを作らせ、リポジトリに置く（データ投入・フロー実行・スクリーンショット・検査の4コマンド）。説明文には「PRを開く前に必ず検証コマンドを実行する」と1行入れる
コードがない場合：チェックリストで代用する（例：すべての返信がチケットIDを名指しか、価格表にない価格を引用していないか）。1行でも不合格なら、該当行を示して止まる
仕事には段階を割り当てる：INVESTIGATE（報告のみ）→ DRAFT（準備して待つ）→ AUTOPILOT（実行＋検証が通れば送信）→ FULL AUTOPILOT（使い捨てプロジェクトのみ）。対象が本番になった瞬間に段階を下げる
原則は「証明なしに完了なし」

Level 3：玄関口は1つ

利用者は CHIEF とだけ話し、CHIEF が他と話します。分割の単位は作業ではなく記憶・領域です。

最初のボットの仕事を列挙して領域でまとめ、最大の2グループが最初の2体の SPECIALIST になります。

CHECKER は独自の文脈に置くのが大事で、作った本人が自分の仕事を採点すると自分の前提を繰り返すだけ、という理由です。

Level 4：ボード（チャットは流れ去る）

仕事の状態はボードで管理し、ステータスは Todo / Working / Blocked / Ready for Review / Done の5つだけです。

引き継ぎは会話の書き起こしではなく「送り手・受け手・目的・成果物・決定・未解決の問い」の形で渡します。そうすると次のボットが履歴を再読せずに済み、そのまま節約になります。

Level 5：時計（ルーチン）の設計

順序が大事で、「手作業でやる → 信頼できる結果を得る → スキルとして保存 → ルーチンを与える」。ルーチンの例：

30分ごと：OPS がボードを点検（失敗したCIやレビュー待ちを戻す）
03:00：夜間監査。小さな PR を作るが決してマージしない
05:00：各ボットと1対1のスタンドアップ（プレイブック確認と障害の洗い出し）
08:30：CHIEF の朝のまとめ。何もなければ無言

見落としがちな罠：バックグラウンドの承認は約10分で失効するので、午前3時の仕事が承認待ちになるとそのまま死にます。事前に許可ルールを書くか、ルーチンを下書きで止める設計にしておく必要があります。

Level 6：関門は「取り消しコスト」で決める

ここでいう「取り消しコスト」は、やってしまった後に元に戻すのがどれだけ大変か、という物差しです。

下書きや調査は、間違えても消せば済むのでコストはほぼゼロ。一方、送信したメールは回収できませんし、公開・購入・削除・本番変更は、元に戻すのが難しいか不可能です。

モデルの「自信があります」は当てにならないので、自信の度合いではなく、この「戻しやすさ」で止まるかどうかを決めます。そういう考え方です。

尋ねずに終えてよい：調査、要約、分類、下書き、整理、ステージング
承認のために止める：送信、公開、購入、削除、権限変更、本番変更
良い実行は「10%終わって質問」ではなく「90%終わって1つの判断」。可逆な手順を全部終えて、最初の不可逆な手順の手前で止まる
注意点として、すべてのボットが1台のコンピュータを共有する場合、ファイルやログインは全員分共有される。「財務を開くな」と説明文に書くのは願望で、持っていないログインこそが壁になる

Level 7：腐らない記憶

記憶は層に分けます。

層	内容
DESCRIPTION	仕事と厳しいルール（利用者が書く）
SKILL	繰り返し作業の方法（全ボット共有）
MEMORY	安定した決定と定義（変化が遅い）
LIVE SOURCE	状態・価格・プランなど（覚えずに取得する）
TASK STATE	今回の実行の状態（ボードに置く）

高コストな誤りは「速く変わる事実を遅い記憶に入れる」こと。繰り返し起きる問題への対処順序は、①構成を直す ②検査に組み込む ③スキルやルールとして（原則で）書く ④記憶は最後、出典付きで。

トークンの9つの漏れ

ここまでが「どう作るか」の話でした。最後に、話を冒頭の問題に戻します。

冒頭の式を思い出してください。料金 = 起動回数 × 毎回の再読量。せっかく席と仕組みを整えても、このどちらかが太る使い方をしていると、請求は静かに膨らみ続けます。

元記事が挙げる「請求を食う漏れ」は、その具体例です。どれも、起動回数を増やすか、1回あたりの再読量を増やすか、その両方で効いてきます。

自分の構成に当てはめるチェックリストとして読んでください。記事が挙げる漏れは次の9つです。

おしゃべりボットに住むルーチン：普段の会話に使うボットは、会話が育って一番長い文脈を持っています。そのボットにルーチンを置くと、定期実行のたびに長い会話全体が再読されて割高になります。ルーチンは、会話を持たない専用ボットに移します
終わらないチャット：チャットは続くほど長くなり、再読量も増え続けます。一番長いチャットが一番高い、ということです。対策は、履歴だけ落として新しいチャットに作り直す「複製」で、記事内の測定例では1ターン158.8K→35.7Kトークン（約75%減）。ただし消す前に、必要な状態はファイルへ書き出しておきます
時計が速すぎる：ルーチンの間隔を短くすると、起動回数がそのまま増えます。5分ごとなら月8,640回で、API料金換算の目安では月約397ドル。1時間ごとだと約33ドルで、約12倍の差がつきます。しかも実行自体が5〜37分遅れることもあり、短い間隔にしても「新しさ」すら買えていない場合があります。本当に必要な間隔まで落とすことが大事です
実行前のチェックなし：まず状態（件数・最終更新など）だけ読んで前回と比較し、変化がなければ止まる。起動のたびに全体を「ちょっと見て回る」こと自体が再読になって請求を食うので、見回りから始めない、というのが核心
ボット同士の会話：ボット同士のやり取りも、利用者との会話と同じようにトークンとして数えられます。特に、グループチャットで全ボットが毎回起動して応答し合う構成は、起動回数も再読量も膨らみます。仕事の受け渡しは会話ではなく、ボード経由に変えます（Level 4 の話です）
聞き耳（リスナー）と曖昧な依頼：「全ての新着メッセージに反応する」設定にすると、メッセージが来るたびにボットが起動して文脈全体を再読するので、間隔ゼロで繰り返し実行するのと同じコストになる。反応する条件（相手やキーワード）を絞ること。依頼の出し方も同じで、「Alexに返信して」だけでは、ボットは対象を探して会話を読み返してしまう。チケットIDのように一意に指せる形で指定する。また、ブラウザで画面を開いて読みに行くより、連携機能（コネクタ）でデータを直接取る方が安い
スクリプトで済む仕事をモデルがしている：毎回同じ手順で同じ答えになる仕事を、わざわざモデルに考えさせる必要はありません。普通のコード（スクリプト）にすれば、トークンはほぼかからず、確実に動きます。記事内の支援例では、価格監視をコードに移して週441ドル→9.40ドルになりました
ボットにしなくていいものをボットにしている：ボットを1体増やすと、その分の文脈が再読の対象に加わります。独自のルーチン・認証情報・非公開の文脈・直接話すチャンネルが必要な場合だけボットにします。それ以外は、呼び出されたときだけ読まれる手順書である「スキル」で足ります
二重課金：ルーチンの実行中にそのボットへメッセージを送ると、処理がもう一度走って二重に課金されることがあります。テスト実行も本番と同じ実コストがかかります。「ちょっと試す」も無料ではない、という前提で設計します

この9つは、1つ1つは小さく見えます。でも記事内の例では、全部の対策を入れた結果、1日の起動回数が 567回 → 36回（約1/15） になりました。

ボットの台数を減らしたわけではありません。無駄な起動そのものを消した、というのがポイントです。

冒頭の式で言えば「起動回数」の側を約1/15にしたわけで、料金はその分だけ素直に下がります。

自分への落とし込み

Grok Bot 固有の話に見えますが、構造はどのエージェント基盤でも同じだと感じました。

料金は「起動回数 × 毎回の再読量」。長い文脈を抱えた定期実行が一番危ない
ルールは会話の記憶ではなく、毎回読まれる場所（説明文・設定ファイル）に書く
「完了」の定義を先に作る（検証コマンドかチェックリスト）。採点者は実行者と別の文脈に置く
不可逆な操作の手前で止まる関門を、モデルの自信ではなく取り消しコストで設計する（取り消しコスト＝後から元に戻す大変さ。消せば済む下書きは低く、送信・公開・削除のような戻せない操作は高い。詳しくは Level 6）
定期実行は「チェックして変化がなければ止まる」を挟む。スクリプトで済む仕事はスクリプトに寄せる

エージェントを増やすのは最後で、先に説明文・証明・ボード・関門。働く相手が人間から AI ボットに変わっても、役割分担と仕事の流し方を先に決めるという、組織の設計の順番は変わらないんですね。

参考

ワークショップ動画: Lauren Tan「Lauren Tan Reveals How to Build a 21+ Agent GrokBot Team」（Maven ワークショップ「How Cursor Turned AI Agents Into Better Engineers」の録画） https://www.youtube.com/watch?v=PcO998TSzIs
元ポスト: gatsby（@0xg4tsby） https://x.com/0xg4tsby/status/2115791677105291629
解説記事: m4lka（@m4lkxx）「Grok Bot: 6 Bots, 200+ Agents, a Smaller Bill」 https://x.com/m4lkxx/status/2115775972536434946

※ 本記事は上記のポストと記事をもとにした二次まとめです。数値や事例は各出典の主張であり、正確な内容は元記事を確認してください。