6体のBotに「断る仕事」を決めて回す、Doneyli De Jesus氏のチーム運用

AIのBotを何体も動かすと、どのBotに何を頼むかを覚えるだけで手間が増える。ClickHouseのDoneyli De Jesus氏は、Grok Botを6体、担当のレーンを分けた「チーム」として回し、自分が話しかける相手を1体に絞っている。各Botには、受け持つ仕事と並べて「断る仕事」の一覧も持たせた。10月18日付のブログで、その組み方と、顧客に出るものの線引き、起きた失敗までを書いている。

窓口を1体にして振り分ける

De Jesus氏は本人の自己紹介のページで、ClickHouseのPrincipal AI Architectを名乗り、それ以前はSnowflakeのAI部門の創設メンバーだったと書いている。Substackでは「Signal Over Noise」を書いている。

10月18日付の6体のBotをチームとして回す記事によると、同氏はGrok Botを6体動かし、それぞれに担当のレーンと「断る仕事」の一覧を持たせている。話しかけるのは「Point Guard」と名付けた窓口の1体だけで、そこが残りの5体に仕事を振り分ける。同氏はこれを「I talk to Point Guard. It routes.」と短く書いた。

「断る仕事」の一覧は、受け持つ仕事の一覧の裏返しだ。何を引き受けるかだけを書くと、2体が同じ頼みを取り合ったり、どのBotも拾わない頼みが出たりする。断る側も書いておけば、窓口のBotは、どのBotに回せばよいかを迷いにくくなる。6体それぞれの線をはっきりさせることと、話しかける相手を1体にすることは、同じ狙いの両面になっている。

作業の置き場も分けている。組み立てて検証まで要るコードはクラウドのエージェントに、ファイルや資料はMac上のClaude Codeに回す。どこに回すかはBotが決め、実際の作業はそれぞれの道具がする形だ。

決まった時刻に動き、変化が無ければ黙る

Botが決まった時刻や出来事で動く作業を、同氏は「play」と呼ぶ。今は18本あり、15本が時刻、3本が出来事をきっかけに動く。たとえば採用を担当するBotは、毎朝8時51分に動く。どのplayも、何も変わっていなければ何も言わないように書いてある。

18本が毎回何かを報告すれば、本人が読む量は増え続ける。黙る設計にしておけば、知らせが来た時だけ目を通せばよい。Botの数を増やしても、人の手間が同じだけ増えないようにする工夫と読める。

顧客に出るものは、送信を押すまで出さない

線引きの既定は「下書き」だ。同氏は「Nothing customer-facing leaves until I press send.」と書き、顧客の目に触れるものは、本人が送信を押すまで外に出さない。

例外は2つだけで、どちらも範囲を文書で決めている。1つは、運用を担当するBotが、本人の作業の一覧にチケットを作ったり直したりすること。もう1つは、採用を担当するBotの送信だ。送信を許した時に、件数の上限、本人の文体に固定すること、朝の1本のplayに限ること、止まる決まりの4つを付けた。任せる範囲を広げる時ほど、条件を細かく書いている。

失敗とその後の手当ても書き残す

この送信のレーンは、サインインの壁に当たり、招待を1件、誤った相手に送った。同氏は、サインインの壁や警告が出たらBotが止まって本人に知らせる決まりを置いている。ほかのBotの失敗から、窓口のBotの方針に決まりを足したことも書いている。失敗を個々のBotの直しで終わらせず、全体の決まりに戻している点が目を引く。

Claude Codeの側の組み方

Claude Codeの使い方は、3月19日付の妻のコンテンツ制作を自動化した記事に詳しい。半年以上前の記事だが、同じ考え方が見える。最初は約2,000行あったCLAUDE.mdを約200行に縮め、「routing table, not a novel」とした。中身を書き込むのではなく、どの資料を読むかを指す表にしたという意味だ。24のskillは決まった言葉で呼び出され、文体の決まりは共有のフォルダに1か所でまとめた。

15本のシェルスクリプトがmacOSのlaunchdで決まった時刻にClaude Codeのコマンド「claude -p」を動かす。予定表を本人が見直していなければ、制作の段は「人のレビュー待ち」として何もせずに終わる。

この記事にも失敗が書かれている。あるエージェントの失敗に1週間気づかなかったので、全部のエージェントがGatusに状態を報告し、ntfyで失敗を知らせる形にした。最初の月はAPIの費用が必要な額の約4倍になり、Opus、Sonnet、Haikuを仕事の難しさで使い分けて直した。数字はどれも本人の申告だ。

10月5日付の夫婦で同じアプリを作り比べた記事では、妻のクライアントの在庫管理のアプリを、妻はReplit、本人はClaude Codeで作った振り返りを書いた。そこには「The stack is rarely the reason a build fails.」という一文がある。道具の選び方より、何を誰のために作るかを先に決める方が結果を左右する、という同氏の考えを短く言い表した言葉だ。

編集部の見方

取り入れるかは別として、まず理解するなら、Botごとの担当と「断る仕事」の一覧、そして顧客に出るものは人が送信を押すまで出さないという線引きを、De Jesus氏がどの場面で決めているかを見てみるといいかもしれない。Claude CodeやCodexで定時の仕事を回しているなら、自分の仕組みで何を止め、どこで人が押すかを書き出す手がかりになる。