第9章 グループチャットとチームBot：1つのBotからBotチームへ
すべての作業を1つのBotに詰め込まず、複数のBotをグループチャットに追加することも避けてください。複数のBotはお互いに返信し合って循環起動を起こし、1週間分のクォータを使い果たしやすく、個人BotをSlackに追加しても連携できません。
- 統括Botを単一エントリーポイントとして使用し、ローカルとクラウドPCの共有ファイルを通じてタスクを引き継ぎます。
- チーム全員でノウハウを共有する必要がある場合は、チームBotを公開します。
- 2026-10-12に発効した The X Subscription 統一サブスクリプションメカニズムに従い、利用量を適切に管理します。
グループチャットのメカニズムとインタラクションルール：複数Botが同一会話内で連携する方法
グループチャットには複数のBotを追加できますが、チームBotとローカルBotを同一グループに入れることはできません。
メッセージを送信するとデフォルトで全員が返信するため、特定する場合は @Bot名称 を使用します。複雑なタスクにおけるBot間のダイレクトメッセージでの引き継ぎは、グループには同期されません。
ダイレクトメッセージが分散するのを防ぐため、明確なルールを定めます：
- 一時的な制約：グループ内で指示を送信します。
就在群里回复，这件事不要私信我。- 長期的な制約：長期記憶に記録させます。
记住：在群组聊天中，要在群里回复。システムにはBot同士の会話を一括で禁止するスイッチはありません。連鎖的な呼び出しによるクォータの浪費を防ぐには、以下の方法があります：
- 一時的な禁止：グループ内で指示を送信します。
不要给其他 Bot 发消息，先问我。- 長期ルール：確認なしに裏で他のBotを起動することを厳禁とします。
- 緊急停止：停止しない場合は、そのBot専用のダイレクトメッセージに入って停止させます。
- 補助的なミュート：通知をオフにするか、サイドバーで右クリックして Hide from sidebar を実行します。
管理と制限：
- 名前変更と方向転換：右クリックで Rename chat（モバイルアプリではグループ名をタップして Edit name）。方向転換はグループ内で直接説明します。
- 機能制限：グループチャットは音声に一切非対応（個別チャットのみ対応）であり、個別のBotごとに通知のオン/オフを切り替えることはできません。
受け入れ基準：
- メンバーが3体以内で、責務の重複がないこと。
- 質問時は
@で正確に起動すること。 - 出力がグループ内に集約され、不要なダイレクトメッセージがないこと。
- Bot同士の連鎖起動が発生していないこと。
Bot間通信とSlack権限ルーティング
Botは特定の個人を代表している場合にのみ、Bot間でメッセージを送信できます。 個人BotはパブリックなThreadにおいて代表権を持たないため、他のBotを起動できません。一方、チームBotは @ メンションされた際に質問者の身元を引き継ぎ、その人専用の個別Botにタスクを引き渡した上で、結果を同一Threadに返信します。
| Botの種類 | 質問場所 | Bot間送信権限 | 誰を代表するか | 返信場所 |
|---|---|---|---|---|
| 個人Bot | アプリ内DM / Slackダイレクトメッセージ | 送信可能 | 個人 | アプリ内チャットウィンドウ（Slack以外） |
| 個人Bot | SlackパブリックThread | 送信不可（実行不可と表示） | なし | 元のスレッド |
| チームBot | Slackチャンネル / ダイレクトメッセージ | 送信可能（質問者の専用Botに転送） | 質問メンバー | 同一のSlackスレッドに返信 |
チームBotの導入とトラブルシューティング
- チームBotの公開後、オーナーはチャット上部のBot名をクリックし、Bring to your team's Slack の Connect をクリックします（未公開時はグレー表示の Connect after publishing）。
- 画面に Awaiting admin approval と表示された場合はセキュリティ管理が有効になっているため、管理者に承認を依頼します。ステータスが Connected に変われば連携成功です。
- チームメンバーは使用前に、クライアントの Settings > General > Team Bots で Link をクリックしてアカウントを連携する必要があります。 未連携のままSlackで直接メッセージを送信しても、Botは連携案内を返信するのみとなります。
受け入れ基準
- Slackチャンネル内の複数Botの連携が、チームBotによって一元的にスケジューリングされていること。
- チームメンバーのアカウントLinkが完了していること。
- タスクがThread内で完結し、途切れや権限エラーが発生しないこと。
チームBotの全手順設定：作成、公開、メンバー間共有
チームBotはメンバーによって作成され、全員で共有されます。ダイレクトメッセージは相互に分離されています。クラウド上でのみ動作し、ローカルにバインドすることはできません。公式ガイドを参照。
作成とチームBotへの変換
- サイドバーで New chat（+）をクリックし、Create new Team Bot を選択します。
- 要件を伝え、公開プラグイン、Secrets、ファイルを構成します。
- 名前を変更し、About を入力します。デフォルト名のままで説明が空の場合、他のメンバーはリスト内でそのBotを検索できません。
- カード上の Publish to Team をクリックします。
既存の個人Botは、インターフェースで Share > チームに公開をクリックして独立した複製を作成し、Slackアカウントを生成して、必要に応じてシークレット、記憶、ルーティン（Routines）を移行できます。
検索と呼び出し
- 検索と一覧：New chat（+）でチームBotを選択してブラウズするか、検索ボックスに名前の先頭3文字を入力します。
- リンク直行：右クリックして Copy link を選択します。全員でベースモデルと記憶を共有し、複製テンプレートではありません。
- 一括配信：管理者がダッシュボードの Manage Team Bots で Auto-add にチェックを入れます。チェックされたメンバーのサイドバーには自動的に最上位固定され、非表示にできなくなります。
権限と実行メカニズム
個人アカウントを呼び出す際に Allow 認証がトリガーされます（Allow once：今回のみ、Always allow：常に許可、Skip：スキップ）。リセットするには Settings > General > Team Bots に進み Clear をクリックします。
承認カードはオーナーのダイレクトメッセージでのみポップアップします。グループチャットやSlackでは、Botは自律的に動作するしかありません。
| シーン | 実行環境 |
|---|---|
| ダイレクトメッセージ | デフォルトで個人のクラウドPC（プライバシー要件が厳しい場合は分離マシンを割り当て） |
| Slack / グループチャット | 専用の共有仮想マシン |
受け入れ基準
- 名前と職務内容が明確であること。
- オーナーのシークレットが適切に分離されていること。
- 3文字検索またはリンクから起動できること。
- 他のユーザーからの呼び出し時に Allow 認証がトリガーされ、権限逸脱のリスクがないこと。
1+N メインBotタスク割り当てパターン：単一エントリーポイントと遂行規約
すべてのBotを直接ユーザーに対応させないでください。ウィンドウ間での伝言に追われ、グループチャットで無駄にトークンを消費することになります。
推奨されるのは 1+N パターンです。ユーザーは統括メインBotとだけやり取りし、そのBotがタスクの分解、割り当て、集約を行います。詳細は 『1つのBotから組織全体へ、Grok Botの上級活用法共有：ローカルPC、AI分業、ナレッジベースの連携方法』 を参照してください。
メインBotの6行規約と専門特化境界
メインBotはルーティングと監視のみを担当し、決して自身で長大なコードや長文を書いてはなりません。 個人Botには6行規約を対話内で送信して記憶させ、共有Botには詳細 About の Description に記述します。何もないときは沈黙を守り、タスクがあるときは割り当てを行い、長大なレポートはファイルとして保存します。
チームの組織規約については 『4.2 チームオーケストレーション：規約、役割、権限委譲』 を参照してください。
Own: 负责需求的统一拆解、分派、汇总与五行简报汇报。
Sources: 人工下发的指令、项目看板文件。
Output: 纯文本状态摘要，超出五行时输出为指定文件路径。
Approval: 任何对外通信、采购、删除操作必须暂停等待确认。
Failure: 下游专职 Bot 报错时如实上报，不使用过期数据假装完成。
Never: 永远不直接编写业务代码，不擅自修改生产配置。専門特化Botにはネガティブバウンダリ（禁止境界）を送信して記憶させる必要があります（共有Botは詳細 About に記述）：
- 広告運用Bot：データを分析して承認待ちリストを作成し、決して管理画面や入札単価に触れず、予算を変更せず、キーワード追加や広告グループ作成も行いません。
- コピーライティングBot：下書きファイルのみを出力し、APIを呼び出してコンテンツを直接公開することは厳禁とします。
- 競合調査Bot：フロント画面の閲覧のみを行い、購入・カート追加は厳禁、レビュー投稿や出品者への質問も行わず、スクレイピング対策によるアカウント停止を防ぎます。
広告運用担当者はプロンプトテンプレートをそのまま適用します。
Own: 负责广告投放数据诊断与策略输出。
Sources: 运营分析文件 /workspace/project/ad_data.json。
Output: 待批操作清单 /workspace/project/pending_actions.md，列出出价建议与预期影响。
Approval: 绝不直接写入广告后台，不修改出价，不修改预算，不加否定词，所有操作必须等待人工审批。
Failure: 数据缺失时明确标注缺失字段，不推测填充。
Never: 绝不执行任何后台写入与线上提交操作。承認待ちリストと受け入れ基準
専門特化Botは構造化された承認待ちリストのみを出力し、決定権は人間に委ねます。 例えば、メインBotが5件の広告入札競合項目を要約し、人間が「提案を承認」と返信するか修正指示を出した後に初めて次のステップに進みます。
システムが要件を満たしているかは、以下の3つの基準で受け入れ判定を行います：
| 検査項目 | 適合基準 |
|---|---|
| インタラクションとメインBot | 単一エントリーポイントとして明快に動作すること。メインBotが長いコードや長文記事を書かないこと |
| 専門特化Bot | それぞれの役割に専念し、構造化リストのみを生成すること |
| 高リスクアクション | 不可逆な操作にはすべて明確な人間による確認チェックポイントがあること |
引き継ぎファイルの規約：対話履歴の代わりに共有ファイルシステムを活用
Bot Aがチャットウィンドウに結果を貼り付けてBot Bに読ませるような運用は避けてください。ウィンドウ間でのやり取りはコンテキストを急速に圧迫し、履歴が失われやすくなります。また、各Botの対話は基盤レベルで論理的に分離されており、互いに検索することは一切できません。
| 側面 | 特徴と含まれる内容 |
|---|---|
| 物理共有層 | 同一アカウント下の全Botが仮想マシン、/workspace ディレクトリ、コネクタ、パブリックSkillライブラリを共有。 |
| 論理分離層 | 対話履歴は相互に閲覧不可。Bot AはBot Bとユーザーのプライベートな対話を取得できない。 |
物理ディスクが共有されている以上、タスクの受け渡しはローカルの構造化ファイルに頼り、チャットウィンドウはステータスとパスの同期のみに使用します。
ファイル引き継ぎパイプラインの標準仕様
標準的な引き継ぎは、ディスクへの書き出し、パスの伝達、そして読み込みとアーカイブまでを含みます。
ファイル引き継ぎパイプラインの標準仕様
[用户指令] ──> (主调度 Bot)
│
1. 派发任务 (指定输出路径)
│
▼
[专职 Bot A] ──> 写入 /workspace/proj/data.json
│
2. 交付：仅返回文件绝对路径
│
▼
(主调度 Bot)
│
3. 调度下发 (附带输入路径)
│
▼
[专职 Bot B] ──> 读取 data.json ──> 写入 output.md
│
4. 汇总简报至用户- タスクの割り当て：メインBotが納品先の絶対パス（例：
/workspace/project-alpha/data.json）を明確に指定します。 - データのディスク書き出し：専門特化Bot Aがクレンジングを実行してファイルに書き込み、チャットウィンドウには保存パスを伝える1行のみを返信します。
- パスの伝達と読み込み：メインBotがBot Bを起動してパスを伝達し、Bot Bはディスクから読み込んで分析した後、結論を
/workspace/project-alpha/report.mdに書き込みます。 - 成果物の提示：メインBotが要約を抽出し、確認用のローカルまたはクラウドドキュメントのリンクを添付します。
ツイートのペルソナ分析パイプラインもこのパターンに従います。整理担当がスクレイピングして tweets.md に保存し、アナリストがファイルを読み取ってタグを抽出して profile.md に書き込み、デザイナーが design.md を出力し、エンジニアがそれに基づいてコードを書いてプレビューのスクリーンショットを提示します。
実践例は 『4.2 チームオーケストレーション：規約、役割、権限委譲』 を参照してください。
Feishuクラウドドキュメントとの連携によるトレーサブルな納品の実現
チームでの共同作業やインラインコメントが必要な場合は、仮想マシンにFeishu CLIを設定してMarkdownをクラウドドキュメントとして送信します。配布しやすい固有リンクが発行され、段落ごとのコメント付与に対応しており、エンタープライズデータのセキュリティも確保できます。
ワークフローが要件を満たすための条件は以下の通りです：
- パイプライン内の各Botが、
/workspace配下の固定ファイルを個別に読み書きできること。 - チャットウィンドウではステータス通知とファイルの絶対パスのみをやり取りすること。
- 異常が発生した際、該当するディスクファイルを調べるだけで原因を再現・特定できること。
利用量への影響とクォータ管理：The X Subscription 下でのマルチBotガバナンス
2026-10-12以降、Grok Botは The X Subscription に統合され、週単位でクォータが一括共有されます。
| プラン | 価格 |
|---|---|
| Premium | $30/月 |
| Super | $100/月 |
| Ultra | $200/月 |
ルールとクォータ枯渇防止策
- 返信とハンドシェイクメッセージの双方が課金対象となります。チームBotとの個別チャットは自身のクォータから消費され、グループチャットでは発信者のクォータから消費されます。週の初めに使い果たすと、その週全体で利用停止となります。
- グループチャットのBotは3体以内に抑え、自由なグループチャットの代わりに必ず 1+N のシリアル処理を採用します。
- クレンジングなどの軽量タスクにはベースモデルを使用し、高度な推論モデルはコアな思考タスクにのみ使用します。
- 安定稼働が確認できるまでは、30分ごとや毎時の定期ルーティン（Routines）を設定しないでください。夜間に数百回リトライしてクォータを枯渇させる事態を防ぎます。
受け入れ基準
- 週間クォータが安定して消費され、夜間の無限ループが発生していないこと。
- モデルの階層分けが明確で、コストが個々の質問者に適切に配分されていること。
実践事例：社内専門家ノウハウの形式知化と越境チームにおける 1+N の導入
SpaceXAI チームBot
n2parkoチームは業務エキスパート自身にBotのルールを設定させ、全社共有アシスタントを構築しました。
- 高頻度ノードの特定：データチームがデータレイク照会用の Databot を作成し、専門家への重複した問い合わせを削減。
- 役割の拡充：10x Engineer、Marketing、およびSalesforceを照会する Sales Assistant（SDR/AEを補助）を配置。
- 記憶の階層化：共通ルールをグローバルに蓄積しつつ個人の好みも保持。詳細は 『Meet your Team Bots｜n2parko』 を参照。
越境 1+12 オーケストレーション
Zach（@1999Zach22）は、1人のキャプテンが12の役割を率いる構成を採用し、自動化のクローズドループには必ず承認待ちリストを設け、書き込み権限を厳格に管理しています。
- ローカルデプロイ：専用Skillをローカルで調整・動作確認した後、クラウドPCへ一括デプロイ。
- ネガティブバウンダリ：広告運用者は管理画面の操作を厳禁とし提案のみを行う。リサーチ用バイヤーアカウントはカート追加、質問、レビュー投稿を厳禁とする。
- 単一エントリーポイントによるインタラクション：日次ブリーフィングを毎日集約し、コンフリクト発生時は5件の競合承認待ちリストを出力、承認後に実行。
- レポートの蓄積：Feishu CLI を使用してレポートをクラウドドキュメントの永続リンクとして保存。詳細は 『1つのBotから組織全体へ、Grok Botの上級活用法共有：ローカルPC、AI分業、ナレッジベースの連携方法』 を参照。
陥りやすい落とし穴
- 3つの単語で固有のスキルを定義できないものは、メインBotのSkillとして集約してください。ウィンドウの切り替えに追われるのを防ぐため、役割の曖昧なアシスタントを一気に7〜8個も作成しないでください。
- 同一アカウントのすべてのBotはクラウドPCの仮想マシン、ローカルパス、ブラウザのログインセッションを共有します。共有Botには個人のプライベート認証情報を絶対に保存しないでください。
- グループへの指示を曖昧にしすぎないでください。Bot同士がお互いに確認やお世辞のやり取りを交わしてクォータを激しく消費し、半日で1週間分の呼び出し枠を使い果たす恐れがあります。
New team botのデフォルト名のままで説明を書かずに公開しないでください。他のメンバーの検索一覧に一切表示されなくなります。- チームBotとローカルBotは同じグループに入ることができず、グループチャットには音声入力の導線もありません。これらの機能が必要な場合は、単一Botとのダイレクトメッセージに切り替える必要があります。
- 何千行ものコードを書くとコンテキストが埋まり、全体像が見失われます。メインBotはディスパッチと進捗管理のみを担当し、具体的な実装アクションは専門特化Botに実行させてください。
完了後の受け入れテスト手順
- メインBotのルーティング：モジュールをまたぐ業務指示を送信し、メインBotが目標を正確に復唱して専門特化Botのパスを提示できることを確認します。外部ステータスの変化がない場合は沈黙を維持します。
- グループチャットでのBot間相互送信防止：「他のBotにメッセージを送らず、まず私に確認すること」と指示を出した際、Botがグループ内でのみ返信し、ダイレクトメッセージウィンドウに通知を出したり、裏で互いに呼び出し合ったりしないことを確認します。
- 検索と認証：別のメンバーの Cursor アカウントに切り替え、New chat > チームBot で先頭3文字を検索します。プラグイン呼び出し時に Allow once、Always allow、Skip を含む認証カードが必ずポップアップすることを確認します。
- ファイルの引き継ぎ：Bot Aが中間ファイルを
/workspaceに保存し、Bot Bが絶対パスのみを手がかりに単独でタスクを完了できることを確認します。全行程で手動によるコピーは不要です。 - ヒューマンゲートによる遮断：公開、管理画面の修正、削除などの指示を出した際、Botが必ず実行を中断して承認待ちリストを出力することを確認します。人間の承認なしに本番環境への書き込みを決して行わないようにします。