第 24 章 役割ごとに AI チームを編成する
Grok Bot を単なるチャット欄や何でも屋のアシスタントとして扱ってはいけません。 雑務をすべて同一のセッションに詰め込むと、コンテキストの肥大化、応答の遅延、クォータの浪費を招き、夜間の無人監視時にはメールの誤送信、本番コードの意図しない変更、資金の引き落としといった事故を引き起こしやすくなります。
Grok Bot の基盤は独立したブラウザとローカルファイルシステムを備えたクラウドコンピュータであり、使いこなすには役割ごとに明確な編制を構築する必要があります。
- 承認のレッドラインを厳格に管理する。5 つの明確なシグナルに基づいて役割の責任範囲を分割し、未確認のメール、本番コード、資金の引き落としは必ず人間の承認前で停止させます。
- ルーティンの引き継ぎを確立する。7 つの主要な役割に対して最初の検証タスクと定期ルーティンを設定し、日常的な巡回点検の中で検収基準を確立します。
《How to master Grok Bot in 16 minutes - Full Course｜CyrilXBT》
《GrokBot Agents: build a team that works for you 24/7 in 10 steps (Full-Course)｜Movez》
役割分割の 5 つのシグナルと組織原則
境界の画定と環境の隔離
同一アカウント下のすべての Bot は同一のクラウドコンピュータを共有しており、ファイル、Web ログイン状態、コネクタが相互に接続されています。しかし、各 Bot のメモリと対話スレッドは独立しているため、異なる業務を混在して処理するとメモリが無関係な情報で埋め尽くされ、指示のドリフトを引き起こします。
《Grok Bot Agents: how to automate your life in 10 Steps (Full-tutorial)｜Codez》
役割分割の 5 つのシグナル
業務に以下のいずれかの特徴が現れたら、独立した専任 Bot を設置すべきです。
- 目標が異なる：例えば、システムの不具合検出を担当することと、コピーのコンバージョン率改善を担当すること。
- ツールが異なる：例えば、主にコードリポジトリに接続することと、CRM スプレッドシートに接続すること。
- 業務スタイルが異なる：例えば、カスタマーサポートは穏やかで控えめ、データ分析は厳格かつ客観的で数字のみを列挙すること。
- 承認の境界が異なる：例えば、社内メモの起草と外部への送信権限は必ず分離すること。
- スケジュールが異なる：例えば、毎時チケットを巡回監視することと、毎週月曜日に財務レポートをまとめること。
汎用アシスタントと専任チームの比較
専任チームは汎用アシスタントと比較して、コンテキストと権限リスクを効果的に隔離できます。
| 比較項目 | 汎用アシスタント（落とし穴に陥りやすい） | 専任 Bot チーム |
|---|---|---|
| コンテキスト | 複数の業務が混在し、記憶の混乱やハルシネーションが発生しやすい | 独立したスレッドで専用の記憶を維持し、安定して動作 |
| 権限とトラブルシューティング | 権限が過剰になり高リスク操作を誤ってトリガーしやすく、衝突の原因特定が困難 | きめ細かな承認管理、失敗の原因特定が直接的 |
| ルーティンの拡張 | 定期タスク同士が干渉し、スケジュールが詰まりやすい | 独立したタイムテーブルまたはイベントトリガーにより非同期で実行 |
承認の人的ゲートと可逆性の原則
権限管理においては、可逆性を中核とする人的ゲートのルールを厳格に順守しなければなりません。
《Top 10 Grok Bot Prompts That Replace an Entire Team｜maestro》
| 操作の分類 | 典型的なアクション例 | 処置原則と承認メカニズム |
|---|---|---|
| 可逆的な操作 | ドキュメントの起草、照合、タグ付け、要約の抽出 | Bot に自律的に完了させ、ログを記録する |
| 不可逆な操作 | 外部への送信、公開、コードのマージ、資金の引き落とし | 実行前に必ず停止して下書きや差分比較を生成し、人間が UI 上で承認をクリックするまで保留する |
7 段階の検証から永続的な Bot の導入まで
Bot を作成した直後にすぐ定期実行を設定してはいけません。まずは公式の手順に従って手動で実行を確認してください：Grok Bot 使用场景。
- 説明欄（Description）でルールを定める：職務、データソース、レッドラインを明記します。説明欄のルールはすべてのタスクに恒久的に適用され、チャット欄の指示は単一の実行にのみ適用されます。
- 安全な範囲で単発実行する：入力ソースを限定し、実際の業務を手動で実行します。
- レビュー可能な水準まで修正する：人間の介入なしでレビュー可能な基準に達するまで、対話を通じて調整します。
- スキル（Skill）として保存する：手順を直接保存します。複雑な Web ページの場合は「Teach a task」で実演し（上限 10 分、マイク音声は録音されません）、分岐の承認フローを補完します。
- 2 組目の独立した入力で検証する：データを変えてテストし、最初のサンプルへの過度な適合を排除します。
- Routine ポリシーを設定する：Schedule または Trigger を作成する前に、タイムアウト時の再試行とエラー通知を定義します。ネットワーク切断やデータ欠損が発生した際に、決してでっち上げ（幻覚）をしてはいけません。
- 重要操作には承認ゲートを残す：送信や支払いには手動確認（Allow once/Deny）を残し、極めて低リスクな操作にのみ Auto Review を適用します。
7 大コア役割の編制、ルーティン、プロンプト
上記の原則に従い、業務ニーズに応じてデジタルチームをコンテンツ、エンジニアリング、セールス、リサーチ、オペレーション、パーソナルアシスタント、マネージャーの 7 つの標準的な役割に分割します。各役割には、明確な編制の最低基準、最初の軽量な検証タスク、自動化ルーティンのロジック、およびそのままコピーして使用できるプロンプトが設定されています。
1. コンテンツ担当：ポジショニング比較とコンテンツパイプライン Bot
この Bot は毎週月曜日 08:00 に 1 回実行され、競合 3 社のページを取得して自社のファーストビューと比較します。変更があれば PR ブランチを作成し、変更がなければ待機します。
- 権限：PR またはスケジュール表の下書き作成のみとし、直接のマージや公開は厳禁とします。
- 検収：成果物はテーブル 1 つとコピー 1 段落に限定し、30 秒以内に確認完了できるものとします。
- 注意点：パースに失敗した場合は即座にリンク切れとして報告し、推測による補完は行いません。
1. 内容岗：定位比对与内容管线 Bot
每周一上午 08:00，对比我们产品定位页 <our_landing_url> 与以下三个竞品页面：
1. <competitor_url_1>
2. <competitor_url_2>
3. <competitor_url_3>
产出以下内容：
- 主张对比表格：我方主张、对方主张、哪一方表述更直接明确。
- 竞品提到但我们未提及的三项内容，需附带原句引用。
- 我们提及但竞品均未提及的三项独有优势。
- 改写我方定位页前两段文案的草稿，使其更具针对性。
在代码仓库 <repo_name> 中针对文案修改开启一个 Pull Request，仅允许改动定位页文案文件。
严禁合并该 Pull Request。严禁触碰定位页以外的代码或文件。
运行结束时汇报：自上周以来竞品侧发生的主要文字变化；若无变化则明确注明。2. エンジニアリング担当：バグ再現と診断 Bot
- 権限のレッドライン：必ず専用のテストアカウントを使用し、ステージング環境で実際の顧客データを使用することや、アラートまたは本番パラメータを変更することは固く禁じます。機密認証情報は Safe handoff を通し、プレーンテキストでの送信は禁止します。
- 調査手順：
needs-reproラベルが付与された Issue を監視し、Staging 上で隔離されたブラウザを起動して再現を実行します。 - 検収基準：期待される動作と実際の動作、ネットワークステータスコード、およびスクリーンショットを含む下書きを Issue のコメントに書き戻し、その後ラベルを削除してエンジニアの確認を待ちます。
2. 工程岗：缺陷复现与诊断 Bot
阅读工单 <issue_url> 中的缺陷报告，并在预发布环境 <staging_url> 中尝试复现该问题。
执行规则：
- 必须使用全新分配的测试账号登录，严禁调用或导入生产环境客户数据。
- 详细记录完整的复现操作步骤、预期行为与实际出现的不一致表现。
- 捕获异常发生时的控制台报错日志、网络请求状态以及页面截图。
- 尝试提取导致该问题的最小复现步骤。
输出规范：
将整理好的复现包整理为 Markdown 文本附在下方。
严禁修改系统的报警规则，严禁更改预发布或生产环境配置。
若尝试三次仍无法复现，详细说明每次尝试的输入参数并标记为“未能稳定复现”，不要伪造成功的结论。3. セールス担当：リード調査とアウトリーチ Bot
- 毎営業日 07:00 にスプレッドシートの先頭 20 行の未アプローチリードを読み込み、3 つのコア ICP 基準に基づいてスコアリングします。
- 最も適合度の高い連絡先 3 名を選定し、それぞれ 4 文以内のメール下書きを作成してシートに入力します。
- 顧客への実際のメール送信や自動アウトリーチへの追加は厳禁です。パーソナライズされた文言には必ず情報源のリンクを付記し、アクセスが制限されている場合は即座に中断して人間に報告します。
3. 销售岗：潜在客户调研与外联 Bot
每个工作日早晨 07:00，处理表格 <sheet_url> 中最早未触达的 20 行销售线索。
针对每一行数据执行以下操作：
1. 访问该公司官网及其公开社交账号，提取过去 30 天内的实质性变动（如产品发布、高管变动、业务调整或受关注动态）。
2. 根据以下三条 ICP 标准逐一判定：
- 目标团队规模在 20 至 200 人之间；
- 核心业务包含多工具协同流程；
- 过去一个季度内有公开扩张动态。
若不符合标准，在状态栏标记“不匹配”并跳过后续步骤。
3. 为符合条件的线索撰写一段不超过 4 句话的首触邮件草稿。必须直接引用第一步中查到的具体变动事实，禁止使用任何寒暄客套套话。
4. 将邮件草稿填入表格的“首触草稿”列，并在相邻列贴上佐证该事实的公开链接。
安全要求：
严禁向任何邮箱发送真实邮件。严禁将联系人导入自动发送队列。严禁调用未授权的个人账号。
运行结束时汇报：已处理行数、排除行数，以及如果你是销售代表会优先发送的前三位名单。4. リサーチ担当：ファクトチェックとデータ集計 Bot
《Top 10 Grok Bot Prompts That Replace an Entire Team｜maestro》
公開 Web、ナレッジベース、利用実績 CSV と連携します。データ不足時は必ずエラーを報告して不足しているフィールドを説明し、経験則による推測や根拠のない提案を行うことは固く禁じます。
- 最初のタスク：業務上の課題を検索して照合チェックリストを出力し、主張を「証拠による裏付けあり」「証拠と矛盾」「証拠による裏付けなし」に分類し、情報のギャップをリストアップします。
- 実行ルーティン：毎週月曜日午前 09:00 に実行し、前週の請求 CSV を読み込んで 4 つの固定された定量的な質問に回答し、1 ページ以内の純粋なデータレポートを生成します。
4. 研究岗：事实核查与数据核算 Bot
研究课题：<research_topic_or_question>
阅读并分析知识库及公开检索信源，生成一份可供直接发布的简报。
执行规则：
- 打开每一个引用来源页面，严禁仅凭模型内部记忆作答。
- 针对报告中的每一个核心结论，摘录支持该结论的原文章节段落。
- 对每一个主张进行事实状态标注：分为“有证据支持”、“与证据矛盾”或“证据未证实”三类。
- 当不同信源存在分歧时，同时列出双方原文，并注明发布时间先后。
- 整理在调研过程中未能找到确证信息的内容列表，将其作为正式结论的一部分列在文末。
输出规范：
输出一份精简报告、一张事实来源对比表、以及尚未解决的疑问清单。
严禁使用似是而非的推测性语句填充信息空白。如果数据源完全未提及某事，直接记录“未找到相关记录”。5. オペレーション担当：チケット対応と財務照合 Bot
- チケット対応：毎時自動的に回答を下書きしますが、返信は Internal Note への書き込みのみとし、ユーザーへの直接送信は厳禁とします。
- 請求書照合：営業日の 17:00 に最新の請求書 10 件を取得して PO シートと照合し、一致、超過、発注なしの項目をマークし、異常がある場合は保留して人間のレビューを待ちます。
- 権限のレッドライン：金額の乖離が 2% を超える場合や新規ベンダーを検知した場合は必ずアラートを発報し、独断での承認や送金の実行は固く禁じます。
5. 运营岗：工单支持与账务对账 Bot
每天下午 17:00，读取财务收件箱 <finance_inbox> 中的新增发票，与采购订单表格 <po_sheet_url> 进行逐笔核对。
针对每张发票执行以下比对：
- 提取金额、币种、开票日期、采购订单号（PO Number）与供应商全称。
- 在采购表格中查找对应的 PO 记录。若无匹配记录，在备注栏标明“无对应订单”。
- 比对发票金额与 PO 批准金额。若偏差绝对值超过 2%，立即将其标记为“金额异常偏差”，并记录具体差额。
- 检查供应商名称是否属于本季度首次出现的新供应商，若是，打上“新供应商待核实”标签。
结果写入规范：
将比对明细写入表格 <po_sheet_url> 的“对账结果”工作表中，并附带该发票的原件查看链接。
严禁执行任何批准报销、发起付款或向供应商发送邮件的操作。
运行结束时汇报：成功匹配笔数、异常待查笔数，以及所有存在异常的发票总金额。6. パーソナルアシスタント担当：受信トレイとスケジュール管理 Bot
《Grok Bot Agents: how to automate your life in 10 Steps (Full-tutorial)｜Codez》
- 日常実行：営業日の 07:30 に直近 24 時間のメールとカレンダーをスキャンし、1 ページのモーニングレポートを生成します。
- 最初のタスク：不要な通知を整理し、重要なメール 2 通に対してそれぞれ 4 文以内の下書きを作成して「承認待ち」に保存し、その後停止して人間の確認を待ちます。
- 権限のレッドライン：スパムや通知のアーカイブのみ許可します。会計、法務、主要顧客、または経営陣からのメールを削除・変更することは厳禁です。返信は下書きの保存のみで勝手に送信せず、カレンダーは変更しません。
6. 个人助理岗：收件箱与日程管家 Bot
每个工作日早晨 07:30，扫描我的工作邮箱 <email_account> 与日历 <calendar_url>。
处理规则：
1. 自动归档系统通知、营销推广与电子发票。若邮件发件人包含会计师、法务顾问或核心客户，严禁自动归档。
2. 提取需要我亲自处理的事项，按紧急程度列出，注明发件人、主要诉求与截止期限。
3. 针对其中最需要紧急回复的 2 封邮件，以我的口吻起草回复方案：
- 语言简短直接，不使用套话与客套感谢语；
- 整体控制在 4 句话以内，明确给出下一步行动建议；
- 若涉及约定会议时间，主动从我日历中调取明天下午的 2 个空闲时段供对方选择。
4. 汇总今天必须参加的会议日程，标出准备资料缺失的场次。
安全边界：
所有生成的回复只能存入邮箱的“待审核草稿”文件夹中，严禁点击发送。
严禁拒绝、更改或新建任何日历日程。
文末以一页纸以内的篇幅汇报：今日概览、已归档数量、待审草稿列表，以及今天唯一一件必须由我做决定的事项。7. マネージャー担当：チーフ・オブ・スタッフとチーム間調整 Bot
チームの中枢として、全体像の把握、ボトルネックの検知、および週次巡回レビューの取りまとめを担当します。
権限のレッドライン
- 業務に進展がない場合は静観を維持する。
- メッセージの代理送信やカンバンカードの移動は厳禁であり、提案のみを行い、人間に代わって意思決定を行うことは決してしません。
タスクとルーティン
- 最初のタスク：カンバンおよび Slack の直近 24 時間の履歴を精読し、ボトルネック、停滞、決定待ち項目を含む動的な注力リストを整理します。
- 営業日 18:00：イブニングレポートを整理する。
- 金曜日 16:30：各専任 Bot のログと成果物を照合し、非効率なタスクを特定して最適化または廃止・削減の提案を行う。
《Top 10 Grok Bot Prompts That Replace an Entire Team｜maestro》
7. 管理者岗：幕僚长与跨团队协调 Bot
每个工作日傍晚 18:00，审阅过去 24 小时内已批准的通讯频道 <slack_channels>、收件箱与项目看板 <board_url>。
提炼并输出以下四部分内容，篇幅严格控制在一页以内：
- 今日实质进展：提炼 5 行关键动态，说明关联系统与具体推进事项。
- 潜在风险预警：列出 3 项如果不做干预明天可能会恶化或延期的事情，说明阻碍人与卡阻天数。
- 待办决议选项：对于必须由我决策的事项，给出选项 A 与选项 B 的利弊对比，并附带你推荐的选项及一句理由。
- 日程减负建议：检查我明天的日历，挑出 1 个可以被取消或改为异步跟进的会议，并说明原因。
输出要求：
不发送任何外部消息，不修改任何会议日程，不挪动看板卡片。
若全天各项指标平稳且无异常阻塞，直接输出“今日运行平稳，无需要升级的决策事项”，不要为了凑字数生成冗余报告。役割間の連携と複数 Bot のオーケストレーション事例
複数 Bot による連携の核心はチケットの受け渡しにあり、人間は重要ノードでの承認のみを行い、手動でコピペする作業員になってはいけません。
SpaceXAI プロダクトチームにおける複数役割の連携
Movez は SpaceXAI の 9 つの専任ポジションを整理しました。これにはチーフ・オブ・スタッフ、ディレクター、データアナリスト、採用担当、および 5 つの開発 Bot が含まれます。 《GrokBot Agents: build a team that works for you 24/7 in 10 steps (Full-Course)｜Movez》
- 目標の疎結合化：人間が大目標を提示し、ディレクター Bot がそれを細分化して各モジュール開発 Bot に割り当てます。
- チェーンによる引き継ぎ：再現 Bot が検証パッケージを出力して直接引き継ぎ、調査 Bot が修正後に PR を作成し、人間の Code Review ノードで停止して承認を待ちます。
- ステータスの同期：チーフ・オブ・スタッフ Bot がリストを動的に維持し、カードに何日もコミットがないことを発見した場合、ディレクターに確認を促します。
《Grok Bot Agents: how to automate your life in 10 Steps (Full-tutorial)｜Codez》
独立チームによる軽量な海外展開運用
CyrilXBT と Codez は 3 つの Bot を使って日常の運用パイプラインを確立しました。 《How to master Grok Bot in 16 minutes - Full Course｜CyrilXBT》
| 役割 Bot | 連携の職務 | 人間によるチェック |
|---|---|---|
| コンテンツ Bot | 業界や競合の動向を監視し、ブログを起草してマルチチャネル配信の下書きを作成 | - |
| セールスアウトリーチ Bot | リードを検索してスコアリングし、毎営業日の朝に 20 通のメール下書きを生成 | 責任者が朝 10 分かけて確認・承認 |
| カスタマーサポート Bot | チケットを監視し、ナレッジベースと照合して社内向け提案を記述 | 誤りがないことを確認後、ワンクリックで公開返信に変換 |
陥りがちな落とし穴
汎用の何でも屋 Bot を作らない：1 つの Bot に経費精算と SNS 投稿の両方を担当させると、メモリの肥大化やトラブルシューティングの困難を招きます。1 つのタスクに 1 つの Bot という原則を徹底してください。
《How to master Grok Bot in 16 minutes - Full Course｜CyrilXBT》
ステップ 6 の前に定期実行を有効にしない：再試行とエラーハンドリングの仕組みが機能することを確認する前に定期実行を行うと、夜間に無限ループでエラーを吐き続けるだけになります。
アカウント共有をサンドボックスの隔離と混同しない：同一アカウント下の Bot はクラウドコンピュータとブラウザを共有しているため、専用のメールアドレス、専用ブランチ、専用調達カードを設定し、個人の重要なプライベートアカウントの紐付けは厳禁です。
《Top 10 Grok Bot Prompts That Replace an Entire Team｜maestro》
長期的な規約をチャット欄に書かない：チャットで話したルールはいずれ消えてしまいます。プロセスと境界は必ず Bot の説明欄（Description）に記入してください。
監視ルールを緩く設定しすぎない：「新着メッセージがあったら」というトリガーにすると、大量のクォータを無駄に消費し、誤動作を引き起こしやすくなります。
《GrokBot Agents: build a team that works for you 24/7 in 10 steps (Full-Course)｜Movez》
データ欠損時のアラートを省略しない：API エラーやフィールド不足に遭遇した際、Bot は勝手に補完・捏造してしまいます。規約に必ず明記してください：データソースの欠損や期限切れが発生した場合は直ちにありのまま失敗を報告し、独断での臨機応変な変更は固く禁じます。
作成後の検収方法
30 秒の即時検証
新規 Bot に課す最初のタスクは、人間の手による検証が 30 秒から 1 分以内に完了できるものでなければなりません。例えば、経理 Bot に先頭 5 行の請求書から欠損項目を探させたり、セールス Bot に指定した 3 社をスコアリングさせたりします。元データの突き合わせに 30 分もかかるようなら、入力範囲が広すぎるか検収基準が不明確であることを意味するため、差し戻して再設計してください。
《Grok Bot Agents: how to automate your life in 10 Steps (Full-tutorial)｜Codez》
ストレステストと人的ゲート
正式に運用を開始する前に、意図的に高リスクな指示を与えてストレステストを行います（例：督促メールを処理させ、即時支払いを要求するなど）：
- 下書き状態で停止し、承認カードを生成できるかを確認します。
- 承認を得ていないにもかかわらず勝手に送信、マージ、または支払いを行った場合は、直ちにツール権限を取り消し、境界制約を書き直します。
運用開始前の 6 要素チェックリスト
UI 上で有効化をクリックする前に、まず 6 つの基本設定を明確に確認してください：
- 担当責任 Bot の明確化（Owning bot）
- トリガー時間とタイムゾーンの設定（Schedule and time zone）
- 入力ソースのパス（Input source）
- 構造化された期待される出力形式（Expected result）
- 厳格な手動承認のレッドライン（Approval boundary）
- ネットワーク切断やデータ欠損時のエラー報告ポリシー（Missing data policy）
週次レビューと廃止・削減メカニズム
Web ページのレイアウトやフィールドの変更により、ルーティンがバックグラウンドで人知れず機能しなくなることがあります。毎週金曜日の午後に 15 分間、週次レビュープロンプトを実行し、チーム全体の Bot に状況を報告させます：
《GrokBot Agents: build a team that works for you 24/7 in 10 steps (Full-Course)｜Movez》
周检与裁撤机制
全体 Bot 成员，请按各自岗位汇报本周的运行情况：
1. 本周累计触发运行多少次，其中发生失败或报错的次数是多少？
2. 在运行过程中，有哪些步骤因数据缺失而跳过、重试或进行了推测？
3. 有哪些挂起等待审批的事项，我一直没有给出答复？
4. 本周生成的哪些文档或表格，我从未打开查阅过？
最后回答两个核心问题：
- 在本周的执行中，哪两个岗位之间存在明显的重复劳动？
- 综合目前的业务价值，你认为团队中哪一个例程或席位最应该被精简裁撤，理由是什么？報告に基づいて、以下の 3 つの長期指標を継続的に評価します：
- 真の工数削減：手作業と比較し、実際に節約された有効時間を算出します。
- 成果物の修正幅：人間による下書き修正の量が継続的に増加している場合、ルールの逸脱を示しているため、再調整が必要です。
- 信頼性の軌跡判定：何度も微調整を行っても安定した出力が得られない役割は、躊躇なく停止または削除します。
《How to master Grok Bot in 16 minutes - Full Course｜CyrilXBT》