第 18 章 事例：一人会社と AI チーム
同一アカウント配下のすべての Bot は同一のクラウド PC を共有し、ブラウザ、ファイルシステム、ターミナルを標準搭載しています。
一気に十数個の Bot を新規作成して全アカウントを渡してしまうと、落とし穴にはまりがちです。
- 外部ウェブページで誤ったパスを辿り、データを警告なく上書きしてしまう
- 深夜に頻繁に承認がトリガーされ、確認作業で疲弊してしまう
職務の境界線、認証情報の分離、承認のレッドライン（許容限界）を整理すれば、最初の AI 社員の配備から 29 体の Agent の管理へとスケールアップできます。
最初の AI 社員：採用活動のように職務と権限を定義する
Bot を単なるツールとして扱うか社員として扱うかは、単発のプロンプトを書いているのか、それとも職務定義を確立しているのかによって決まります。単発プロンプトは目の前の一件の作業しか面倒を見ず、ウィンドウを閉じればコンテキストは消滅します。一方、職務定義は恒久的なドキュメント（プロファイルファイル）であり、その Bot が日々タスクを処理する際の行動規範（レッドライン）や思考パターンを決定づけます。
職務定義と適合テスト
不可逆な権限はまだ与えず、退屈で高頻度、かつ取り消しが容易な雑務から着手しましょう。
Bot に実務を任せる前に、2 つの適合テストを実施して事前トラブルシューティングを行います。
- 一言での職務責任テスト：成果物を一言で説明できるか。無関係な動詞を 4〜5 個も詰め込むのは 1 人に 3 人分の仕事をさせるようなもので、エラー発生時に根本原因を特定できなくなります。
- テキストシミュレーション（Trial in text）：所要時間は 2 分未満。実行手順、アクセス予定の URL、判断に迷う箇所を事前に報告させます。
職務記述書は 5 つの項目に分割して明確な境界線を引きます。
- Owns：作成・納品すべき決まった成果物。
- Inputs：閲覧・読み取りが許可されたチャネル。
- May：自己判断で実行可能な操作。
- Must ask before：出金や設定変更などの高リスクな動作。必ず人間の承認を待つ必要があります。
- Done when：客観的に確認できる検収チェックリスト。
先不要执行任何实际操作。请逐步向我推演你的完整执行方案：
1. 列出你准备依次打开的工具、网址与调用的插件。
2. 列出你在过程中需要做出的业务判断。
3. 标出你目前信息不足、存在疑虑或拿不准的决策点。
推演完毕后等待我的指令，严禁自行操作。職務定義と適合テスト
岗位名称：收件箱管理员（Inbox Manager）
Owns：
每天上午梳理工作邮箱，归档垃圾邮件与订阅通讯，起草客户咨询的回复草稿，标出需要我决策的紧急邮件。
Inputs：
仅限于 Gmail 中收件箱的未读邮件与公司提供的常见问题回复模版。
May：
阅读邮件、按标签分类、打上处理标记、撰写回复草稿、归档无回复价值的宣传邮件。
Must ask before：
严禁直接点击发送任何邮件；严禁归档来自财务、法务或房东的邮件；如果邮件涉及转账、退款、重置密码或修改凭证，立即停下向我确认。
Done when：
工作日上午 9:00 前收件箱所有未读邮件分类完毕；生成的草稿不超过四句话，语气平实直接，不使用任何客套空话；所有待办事项单独列出截止日期。遇到不确定如何处理的邮件，保持未读并挂起询问，严禁自行猜测意图。職務設定と一時的なプロンプトはまったく異なります。
| 次元 | 一時的プロンプト | 職務設定 |
|---|---|---|
| 目標と形態 | 単発対話、単一のアクションに着目 | 長期的な構成、ビジネス成果物を納品 |
| 境界と権限 | 口頭指示は権限逸脱しやすく、失敗時はやり直し | 可逆な操作は自律実行、不可逆な操作は承認待ち、人的関門をハードコード |
3回実行による試用期間と昇格ステップ
出典：Grok Bot: How to Hire Your First AI Employee (Full Guide)
著者：distort @distortgeekin
新しい Bot の動作が確認できた直後は、決してそのままバックグラウンドで無人実行させてはいけません。まずは distort 氏の「3 回実行の法則」に従ってテストします。
- 1 回目（完全同席・観察）：画面を見張りながらすべての操作を確認し、指示の誤認、コンテキストの喪失、根拠のない推測を行った箇所をメモします。
- 2 回目（ルールの修正）：同等の難易度の別タスクに変更し、過去の失敗はあえて指摘しません。職務ルールと権限変更が有効に機能しているかを重視し、人間が結果を手直ししないようにします。
- 3 回目（完全自律の実テスト）：一切介入せず、承認要請時またはリトライ上限に達した時のみ関与します。達成度、介入回数、所要時間、消費クォータを検証します。
3 回のテストに合格した後は昇格ステップに入り、5 段階の権限に分かれます。
| レベル | メカニズム | 境界線 |
|---|---|---|
| Level 0 | 観察のみ | いかなるデータも変更しない |
| Level 1 | 準備のみ | 検索、要約、フォーマット調整などの可逆的な作業 |
| Level 2 | 人間による承認 | 重要ステップで一時停止し確認を待つ |
| Level 3 | 独立実行 | 定期実行またはトリガー実行、定期的にエビデンスチェーン（証跡）レポートを出力 |
| Level 4 | 複数 Bot 協調 | タスクの振り分けおよび品質検査のノードを担当 |
次のレベルへ昇格するには、4 つの必須指標を満たす必要があります。
- 連続 5 回、瑕疵なく本番実行できた
- 検証ステップをすべてパスした
- 未解決の副作用が存在しない
- ロールバック機構が利用可能であることを確認済み
実践的な参考資料：『Grok Bot: How to Hire Your First AI Employee (Full Guide)｜distort』、『Grok Bot Agents: how to automate your life in 10 Steps (Full-tutorial)｜Codez』。
ゼロから回る会社へ：チーフ・オブ・スタッフと専任チームのオーケストレーション
一人で Grok Bot を使って完全なビジネス運用体制を構築する際、最も陥りやすい袋小路は、単一の Bot にあまりにも多くの能力を詰め込みすぎることです。営業リードの管理、コンテンツの執筆、さらには帳簿の照合やコード修正まで兼任する Bot は、無関係な設定や好みでコンテキストウィンドウがすぐに埋め尽くされてしまいます。業務の文脈を取り違えやすくなるだけでなく、クォータの消費も加速させてしまいます。
チーフ・オブ・スタッフ体制と部門分割
チームを立ち上げる際は、まずチーフ・オブ・スタッフ（Chief of Staff）Bot を作成します。日常的にはチーフ・オブ・スタッフのみとやり取りを行い、タスクの分解、専任ポジションへの指示・割り振り、成果物の取りまとめを任せます。
チーフ・オブ・スタッフ体制と部門分割
你是一人公司的幕僚长（Chief of Staff），也是我日常沟通的唯一入口。
你的核心职责：
1. 接收我的业务目标，拆解为明确的工作阶段，派发给对应的专职 Bot（调研、内容、代码、运维）。
2. 在群聊中调度各岗位接力，跟踪各任务交付状态。
3. 检查专职 Bot 提交的产物是否符合完成标准，核对数据来源与执行录屏。
4. 每天晚上汇总团队进展，用不超过五行文字向我汇报核心结果、阻塞问题与需要我决策的审批项。
行为底线：
若无任何新进展或异常，保持静默；严禁越权代替专职 Bot 编写业务交付内容；严禁绕过人工审批直接执行外发、扣款或修改生产环境。- リサーチ Bot：判断や結論には日付と URL の明記が必須。疑わしい点は自発的に明記し、無理に捏造（ハルシネーション）しない。
- コンテンツ Bot：テンプレートに沿ってレイアウトを行い、外部への直接公開は厳禁。
- セールス Bot：アプローチメールはすべて下書きトレイに保存し、人間の確認を経てから送信。
- エンジニアリング Bot：GitHub PR の起票時は必ずテスト通過のスクリーンショットを添付。
- 財務 Bot：資金移動や調整に関わる事項は、確認待ちとして必ず個別にリストアップ。
チーフ・オブ・スタッフ体制と部門分割
团队总体目标：
在两周内针对新上线的知识库产品，完成竞品定价调研，产出一份对比简报，并根据简报结构生成 3 篇官网更新草稿。
协作规则：
1. 调研 Bot 先行检索 5 家竞品公开定价，生成包含引用网址的 Markdown 表格。
2. 调研完成后在群内移交给内容 Bot，内容 Bot 根据数据起草 3 篇文案，放入指定 Notion 页面。
3. 幕僚长全程跟进看板状态，若遇到数据缺失，要求责任 Bot 重新抓取或报错，不得擅自编造。
4. 全流程中所有涉及对外发布的操作全部挂起，等待我在看板中勾选通过。| アーキテクチャ | 単独フルスタック | チーフ・オブ・スタッフ主導パイプライン |
|---|---|---|
| 協調 | メモリが混在し特定が困難 | 各役職が独立したメモリを持ち、責任の所在を明確化 |
エビデンスチェーン（証跡）の審査と4週間の信頼移行
出典：From Zero to a Running Company: The Grok Bot Agent Team Playbook
著者：NO1ennn @N01ennn
安心して PC を閉じるための大前提は、証拠（Show the tape）を確認できることです。 Bot の納品時には、必ず以下の 3 つのエビデンスを揃えさせる必要があります。
- 操作の画面録画または呼び出しログ：完全なウェブページ遷移の軌跡、あるいはツール呼び出しシーケンスを提示する。
- データおよび数値の一次情報源：出所の明記されない引用は禁止。
- エラーによるスキップ項目および推測による結論の説明。
信頼は 4 週間かけて段階的に移行します。
- 第 1 週（ドラフト段階）：Bot は下書きの作成のみを担当し、人間が全文を精読して手動で実行する。
- 第 2 週（承認段階）：Bot が重要なステップまで進んで一時停止し、人間は動作を確認して承認するだけにする。
- 第 3 週（例外報告段階）：低リスクの業務は自律実行させ、異常や権限逸脱が発生した時のみポップアップで支援を要請させる。
- 第 4 週（ルーティン巡回段階）：ルーティンに従って完全自律実行させ、週末に監査レポートを確認するだけにする。
関連する実践事例の参考：『From Zero to a Running Company: The Grok Bot Agent Team Playbook｜NO1ennn』、『Grok Bot: How to Build Your First AI Team (Full Guide)』。
一人会社の実践：単一クラウド PC の境界線と独立運用
物理的な境界線
同一アカウント配下のすべての Bot は 1 台の PC を共有し、ディレクトリやセッションも共有されます。公式からも Bot をセキュリティ分離の境界とみなしてはならないと明記されています。プロンプトではインジェクション攻撃を完全に防ぐことはできず、誤ったコマンド実行によって Cookie や Session が漏洩する危険があります。
日常的に以下の 3 原則を厳守してください。
- メインのオンラインバンキングや基幹リポジトリにはログインせず、機密性の高いクラウドストレージは保存しない。
- 外部プラットフォームでは最小権限のサブアカウントのみを使用する。
- 外部へのログインは Handoff（引き継ぎ）を利用し、パスワード入力は人間が行い、Bot には Session のみを引き継がせる。
API のないシステムの自動化
API がないシステムは、コンピュータ操作能力によるクリックやフォーム入力に頼ることになります。まずは以下の 4 種類のタスクから引き継ぐのが適しています。
- リード獲得リサーチ：コミュニティの名簿・ディレクトリを巡回してメールを下書きする。
- 履行（フルフィルメント）追跡：在庫切れを確認し、遅延している配送伝票をフォローアップする。
- コンテンツスケジュール管理：原稿を下書きトレイに登録する。
- コード保守：自社サイト（独立系 EC・ウェブサイト）のエラーを調査してパッチを作成する。
API のないシステムの自動化
岗位名称：供应链履约跟踪员（Supplier Logistics Bot）
Owns：
每天上午 10:00 登录供应商门户，核对昨天未发货订单状态，提取物流单号，更新至运营表格。
Inputs：
供应商订货后台会话、本地待处理订单表格。
May：
在供应商后台查询订单状态、下载发货清单 CSV、更新本地表格对应列的运单号与发货时间。
Must ask before：
严禁点击「重新下单」或「取消订单」；严禁修改收货地址；若供应商后台提示账户欠款或商品缺货，停止处理并立即向我报警。
Done when：
所有处理过的运单在表格中均标注状态与回填时间；遇到后台页面改版导致按钮无法识别时，截取当前屏幕报错并退出，不得盲目重试。導入基準とスコアリング
出典：One-Computer Company: A Real Playbook For Running Solo On Grok Bot
著者：ZER @zerqfer
負担の増大を防ぐため、人間の確認時間が 1 日 15 分以内に安定して収まるようになってから、新しい Bot を追加するようにしてください。また、知らぬ間の品質劣化（サイレント劣化）を防ぐために、月に一度スコアカードを記入します。
導入基準とスコアリング
Bot 月度运行评分卡
评估周期：2026 年 10 月
岗位名称：[例如：订单跟进助理]
1. 实际工时节省：本月相比纯手工操作，实际节省了约多少小时？
2. 人工介入程度：产出草稿中，需要人工手动大幅修改的比例是多少（低于 10% 算达标）？
3. 信任度变化趋势：对该岗位的自主执行信任度处于上升、持平还是下滑？
4. 异常与回滚记录：本月出现过几次页面识别错误或越权报警？
5. 处置结论：[保留继续运行 / 降级为人工审批执行 / 彻底停用删除]参考資料：『One-Computer Company: A Real Playbook For Running Solo On Grok Bot｜ZER』。
AI エージェンシーの納品体制：月次納品パイプラインと品質管理の人的関門
複数クライアントへの納品を請け負う AI エージェンシー（AI Agency）にとっての最大の難所は、複数クライアントの並行稼働時における品質の安定とクォータコストの抑制です。
コミュニティ執筆者の maestro 氏は、1 人で 5 社の顧問（Retainer）クライアントを担当し、月次の業務運用を実現したアーキテクチャを共有しています（コミュニティ執筆者 maestro 氏の自己申告によると月商 1.8 万ドル、5 社に対応。未検証）。
サービスメニューの「3つの適合テスト」
完全フルオーダーメイドを受注して手作業のアウトソーシングに逆戻りしてはいけません。業務を自動納品メニューに組み込むには、3 つのハードルをクリアする必要があります。
- Brief（要件概要）が構造化されたチェックリストとして記述できること。
- 成果物に第三者による客観的な検収基準が存在すること。
- 過去に完全な手作業で最低 10 回は納品実績があること。10 回以上こなしていないとレッドライン（許容限界）が把握できず、エージェントに任せても中身のない成果物しか出力されません。
基準を満たす業務の例としては、500K のコンテキストで 40 件の資料を比較分析してリサーチレポートを作成する業務、音声・トーンサンプル（Voice File）に基づいた原稿の一括執筆、あるいはダッシュボードの構築や軽量なスクレイピングツールの開発などが挙げられます。
モデルルーティングと 19.5 万 Token の課金クリフ（急崖）インターセプト
モデルはタスクに応じて配分し、すべてにフラッグシップモデルを投入しないようにします。
- Grok 4.1 Fast：2M コンテキスト。データクレンジングと一次スクリーニングを担当。
- Grok Build 0.1：開発成果物の 80% を担当。
- Grok 4.6：500K。長期 Agent タスクと推論を担当。
入力が 200,000 Token を超えると料金レートが倍増します。ゲートウェイには195,000 Token のしきい値をハードコードし、制限を超えた場合はエラーを返して切り詰めるかプルーニング（剪定）する必要があります。
独立した読み取り専用レビューアーと3回リトライの人為的関門
出典：How to Build an $18K/Month AI Agency on Grok (Exact Setup Inside)
著者：maestro @maestrooth
生成 Bot が自らの成果物をレビューすると自己正当化のバイアスが働き、プロンプトの不具合を見過ごしがちになります。レビューは必ず独立した読み取り専用ループに切り分ける必要があります。
- 独立したコンテキスト：元の Brief、クライアントのレギュレーション、最終成果物のみを入力し、中間の推論過程は渡さない。
- 厳格な読み取り専用：欠陥を発見しても FAIL を報告するのみで代筆は絶対に行わない。勝手な手直しによる問題の隠蔽を防ぐ。
- 敵対的アラ探し：致命的な不備（ハードエラー）を徹底的に摘発し、裏付け資料のない数値は無条件で失格（FAIL）とする。
独立した読み取り専用レビューアーと3回リトライの人為的関門
# 独立审查者审核准则（reviewer.md）
你是一名独立质量审查员，负责评估一份并非由你生产的交付产物。
你的唯一任务是找出交付物不符合客户要求的地方。你绝不需要去赞美它的优点。
输入物料：
原始需求 Brief、服务核对清单、客户品牌声音规范文件、最终交付草稿。
你未被提供、也严禁索取生产 Bot 的思考草稿。
审查规则（按顺序严格执行）：
1. 逐条核对需求 Brief 中的清单项。指出任何未被完全覆盖的要点。
2. 检查全文，严禁残留任何占位符文字、TODO 标记或括号说明文本。
3. 全文中的每一个具体数字、引文、统计百分比与人名，必须能在客户资料库中找到对应出处。发现任何未注明来源的数字，必须直接判定为 FAIL。
4. 语言风格是否符合客户过往已批准作品的语气标准。
输出格式：
第一行必须且只能输出一个词：PASS 或 FAIL。
如果判定为 FAIL，按以下格式列出所有缺陷：[清单条款] - [出现位置] - [具体问题及修正要求]。第一行后严禁输出任何空洞的总结段落。
若因上下文缺少凭据导致无法核验某一项，直接判定为 FAIL。单任务自动化生产循环规则：
1. 生产 Bot 基于需求与声音规范生成第 1 版草稿。
2. 独立审核 Bot 执行审查。若返回 PASS，记录日志并进入待交付队列。
3. 若返回 FAIL，系统将审查不通过的具体原因拼接入下一轮 Brief，由生产 Bot 进行针对性修复重试。
4. 重试上限（MAX_ATTEMPTS）严格设定为 3 次。
5. 若连续 3 次均无法通过审查，系统立即终止自动重试，触发报警将原始 Brief、草稿与审查报错完整推送到人工桌面由人工兜底接管。高額な Token 請求を招く無限ループを防ぐため、手戻りリトライは最大 3 回までに制限します。マシンが 3 回試行しても基準に達しない場合は要件の矛盾が疑われるため、必ず人間が介入して判定を下す必要があります。
参考資料：『How to Build an $18K/Month AI Agency on Grok (Exact Setup Inside)｜maestro』。
29 体の Agent 実践録：単独稼働から軍団組織へとスムーズにスケールさせる方法
1 体の社員の構成と 2 体の Bot による品質検査ループに慣れてくると、ビジネス上のニーズから必然的にチームを拡大していくことになります。
コミュニティ執筆者の Melvin Vivas 氏は、Grok Bot を段階的に 29 体の専任エージェントへと拡大していった実践の全貌を記録しています（コミュニティ執筆者 Melvin Vivas 氏の自己申告によると 29 体の Bot を運用。未検証）。
29 体の Agent の機能配置と段階的進化
これら 29 体の Bot は、すべて実需に応じて有機的に増えていったものです。日常業務で反復作業が発生するたびに専任ロールを作成し、ロールが増えた段階でチーフ・オブ・スタッフの Emma に全体を統括させました。業務は大きく 7 つの領域に分かれています。
- 指揮コントロールセンター：Emma が全体の統括とタスクの振り分けを担当。
- 技術研究開発：CTO がアーキテクチャを管理。Coder は Cursor を操作してコードを自動作成し、PR を起票してエラーを修復。ローカルエディタを一度も開く必要がありません。
- 最先端リサーチ：X（旧 Twitter）上のオープンソース動向を終日スキャンしてブリーフィングを作成。
- コンテンツマトリクス：各チャネルのテキスト作成と振り返りを担当。
- ビジネス開発：ビジネスチャンスや提携リードの開拓。
- 運用セキュリティ：メール、バックアップ、セキュリティ監査を担当。
- 自己成長：習慣記録、相場追跡、意思決定の論証を処理。
複数 Agent 協調パイプライン：技術プロトタイプからコンテンツへの変換を例に
各 Bot は共有クラウド PC とセッション参照を活用してバトンをつなぎます。
複数 Agent 協調パイプライン：技術プロトタイプからコンテンツへの変換を例に
端到端跨团队协同案例：
1. 【情报捕获】：X 调研员监控到某大模型最新发布，抓取官方文档与代码仓库地址，整理为技术要点。
2. 【任务调度】：幕僚长 Emma 捕获该报告，根据设定规则判定该模型具备测试价值，自动将任务下发给技术团队。
3. 【工程交付】：编码员 Coder 接收技术说明，调起 Cursor Cloud coding agent 在云端编写 Google Colab 演示笔记本，推送到 GitHub 仓库并自动创建 Pull Request。
4. 【排错闭环】：执行测试出现依赖包版本冲突，终端 Traceback 自动返回 Coder，Coder 修复代码再次提交 PR 通过测试。
5. 【内容物料转译】：PR 合并后，Emma 将成功代码仓库与技术参数推送给内容创作团队，YouTube 脚本助手与 X 内容经理在半小时内完成多平台发布草稿，存入指定待审目录。
6. 【人闸闭环】：创始人全程不介入代码编写与格式排版，仅在最后核验 Colab 实际运行效果，并点击确认对外发布推文。変更を加える際も、29 個のウィンドウを 1 つずつ開く必要はありません。統括マネージャーが一斉同報（ブロードキャスト）指示を出せば、わずか数秒で同期できます。
ロール分割の5大シグナルと自動化7ステップ
評価目標、呼び出すツール、作業スタイル、承認の境界線（下書き作成と対外コミュニケーションは絶対に混同してはならない）、または実行スケジュール周期が異なる場合は、必ず独立した Bot に分割する必要があります。
- 目標、データソース、フォーマット、停止の境界線を Bot に送信して記憶させる。共有 Bot の場合は詳細の About に記述する。
- 影響範囲がコントロールされた実タスクを選んで単発実行する。
- 人間による確認・調整を行い、無検査で通過できるレベルまでチューニングする。
- 再利用可能な Skill として蓄積・定石化する。
- 新しいデータに差し替えて汎化性能を再テストする。
- リトライ上限とデータ欠損時のアラートを設定した上で、初めて Routine を有効化する。
- メール送信、支払い、設定変更には、Require Approval の人的関門を強制的に紐付ける。
| フェーズ | 規模 | アーキテクチャとボトルネック |
|---|---|---|
| 1 ソロ（単独） | 1 Bot | 全量の人為的関門による検証ループ。常時監視が必要 |
| 2 チーム（小グループ） | 2-3 Bot | 作成とレビューの分離。日次メンテナンスを 15 分以内に圧縮 |
| 3 チーフ・オブ・スタッフ | 4-6 Bot | タスク分配とカンバン。チーフ・オブ・スタッフに雑務をやらせない |
| 4 アーミー（軍団） | 10-30 Bot | マルチラインのスタンドアップミーティング。無効なルーティンを定期的に整理・削減 |
カンバンシステムと朝会メカニズム
出典：How I use Grok Bot: My team of 29 AI agents
著者：Melvin Vivas @melvindvivas
Bot が 5 体を超えたら、複数のチャットウィンドウを使うのはやめましょう。到底目を通しきれません。複数 Bot の協調は、主に「カンバン」と「定期巡回」の2つに頼ることになります：
ステータス共有カンバン：タスクをチャット履歴の中に散乱させず、Notion やデータベースカンバンに集約し、5 つのステータス（
Todo、Working、Blocked、Ready for Review、Done）を定めます。Bot は未知のエラーに遭遇したり権限が不足したりした場合、ステータスを即座に
Blockedに変更して人間を呼び出します。平時はカードの推移を見るだけで済みます。定期巡回と照合：単一の Bot には最大 50 個の Routine を設定でき、最短 5 分ごとに実行可能です。
深夜 3:00 にコードのデッドリンクやパッケージサイズを自動点検し、5:00 に統括 Bot（Jenny など）が専任 Bot の Playbook を 1 つずつ照合することで、時間が経つにつれてモデルが設定を忘れてしまうのを効果的に防止できます。
全体专职 Bot，开始进行本周团队回顾审计。请各岗位汇报：
1. 本周你实际执行了多少次任务，其中失败或异常的中断有多少次？
2. 在执行过程中，有哪些步骤存在推测行为、跳过行为或由于数据缺失强行拼凑的情况？
3. 有哪些挂起的审批事项我一直没有回应？有哪些生成的物料我从来没有打开查看过？
4. 请指出：在当前的工作流中，你发现哪两个 Bot 存在职责重叠或重复工作？
5. 给出客观建议：为了节省整体用量额度，我们下周最应该裁撤哪一个无效的 Routine 或岗位？関連する実践事例の参考：『How I use Grok Bot: My team of 29 AI agents』、『GrokBot Agents: build a team that works for you 24/7 in 10 steps (Full-Course)｜Movez』、『Grok Bot: How to Build Your First AI Team (Full Guide)』。
陥りがちな落とし穴
権限と承認
- 共有クラウド PC では Session が共有され分離されていないため、メインアカウントや機密システムには絶対にログインしないでください。
- Require Approval は未実行の操作をブロックできるだけで、破壊的な操作を取り消すことはできません。高リスクな動作には最初から厳格な人的関門を設定してください。
- 承認は約 10 分間放置されると失効（Lapse）するため、夜間は必ず Allow rule ホワイトリストを設定するか下書き作成の段階で停止させてください。
コストとアーキテクチャ
- 入力が 20 万（200,000）Token を超えると単価が倍増します：ルーティング層に 195,000 Token のハードインターセプトとプルーニング（剪定）を設定してください。
- 1 体の Bot にすべての仕事を抱え込ませたり、汎用 Bot を 5 体複製したりしてはいけません。役割分担の不明確さはコンテキストを汚染し、クォータを浪費するだけです。
- 5 分ごとのポーリングや全メッセージの監視を設定してはいけません。No-data policy（データなし時のポリシー）がないと、ネットワーク切断時にデータを勝手に捏造してクォータを使い果たしてしまうリスクがあります。
ルールとハンドオーバー（引き継ぎ）
- チャット欄での指示はリフレッシュすると消滅してしまいます。タスクをまたぐ規律は Bot に記憶させてください。共有 Bot の場合は詳細の About に記述します（個人用 Bot にはすでに Description がありません）。
- Bot 間で全ログを持ち回ってはいけません。引き継ぎパッケージには目標と成果物のパスのみを残し、結論と次のステップへの要件を添えるだけにしてください。
実装後の検収方法
- 認証情報の確認：Plugins やブラウザから銀行やメインアカウントの認証情報を削除し、サブアカウントまたは Session に切り替える。チャットログには平文パスワードを絶対に保存しない。
- 職務定義の検証：Bot には Owns / Inputs / May / Must ask before / Done when を必ず含め、末尾にドリフト（設定逸脱）防止の宣言を付与する。データ不足時は即座にエラーを報告させ、捏造は厳禁とする。
- 人的関門のテスト：出金や削除コマンドを送信し、100% Require Approval がトリガーされて一時停止するか確認する。
- レビュー耐性の確認：ダミーデータの下書きを入力し、品質検査 Bot が1 行目に FAIL を返し、勝手な修正を行わないことを確認する。連続 3 回失敗した場合は停止してアラートを出す。
- ルーティンの安定化：カンバンのステータスがリアルタイムで遷移し、有効化前に Test run で正常終了することを確認する。定期実行タスクが 10 分を超える夜間の承認待ちに依存しないようにする。
関連リンク・参考文献
公式ドキュメント
コミュニティの実践事例
出典：GrokBot Agents: build a team that works for you 24/7 in 10 steps (Full-Course)
著者：Movez @0xMovez
- 『From Zero to a Running Company: The Grok Bot Agent Team Playbook｜NO1ennn』
- 『How to Build an $18K/Month AI Agency on Grok (Exact Setup Inside)｜maestro』
- 『One-Computer Company: A Real Playbook For Running Solo On Grok Bot｜ZER』
- 『GrokBot Agents: build a team that works for you 24/7 in 10 steps (Full-Course)｜Movez』
- 『Grok Bot: How to Hire Your First AI Employee (Full Guide)｜distort』
- 『Grok Bot: How to Build Your First AI Team (Full Guide)』
- 『How I use Grok Bot: My team of 29 AI agents』
- 『Grok Bot Agents: how to automate your life in 10 Steps (Full-tutorial)｜Codez』