Grok Bot 複数プロジェクト運用ガイド：1つのチャンネル、固定メンバー、そして2層のNotionボード

1つか2つのAI Botを使ってちょっとした雑務をこなす程度なら、左側に2つの独立したチャットウィンドウを開き、片方でコードを書き、もう片方で文章を作成するというやり方は極めて直感的です。しかし、手元で2〜3件の複雑な実務プロジェクトを並行して進めるとなると、こうした「1対1の個別チャット（1:1 Chats）」モデルはたちまち破綻します。コンテキストがばらばらに分断され、ノイズだらけのウィンドウ一覧の中から誰がどの作業を進めているのかを把握するのが困難になるだけでなく、各工程を担当するBot同士で進捗を同期させることもできなくなってしまうからです。

xAIのエンジニアであるEric Zakariassonは、エンジニアリングガイドの中で自身が模索した組織モデルを公開しました。彼の基本的な発想は極めてシンプルですが、マルチエージェントの実装における核心的な課題を見事に捉えています。「人間のチームが『プロジェクト制』で協調しているのなら、検証済みのそのワークフローをそのままAIに移植すればよいのではないか？」という点です。

人間の組織では、すべてのプロジェクトに専用の仕様書（Spec）、アクションプラン、専用のコミュニケーション窓口（Slackチャンネルなど）、そして個別の担当者に割り振られたタスクカンバンが存在します。Ericはこの仕組みをGrok Botへとマッピングし、凝集度の高い1つの組織ユニットとして再定義しました。

1つのプロジェクト = サイドバーの専用チャンネル（Channel） + 固定のメンバー名簿（Roster） + Notion内の2層カンバン（Notion Board）

これはすべてを網羅すると謳う公式の決定版ソリューションではなく、実際の業務の中で絶えず反復改善されている実験的な協調フレームワークです。

システムの骨格：2層のNotionデータベースと「プロジェクトマネージャー」Bot

複数のBotをチームのように協調させるには、まずプロジェクト全体のメタ情報（Meta work）を具体的な業務の詳細から切り離す必要があります。

EricはNotion内に互いに連動する2つの基盤データベースを構築し、マクロなプロジェクトとミクロなタスクをそれぞれ管理しています。

1. Projectsデータベース（プロジェクトボード）：マクロなプロジェクトのライフサイクルを記録します。ボードの列には、Planning（計画中）、In progress（進行中）、Paused（一時停止）、Backlog（バックログ）が含まれます。公式の例で挙げられているTypeScriptクライアントSDKの開発やリーダーボード機能なども、ここでは独立したプロジェクトカードとして管理されます。
2. Tasksデータベース（タスクボード）：最小単位の実行タスクを記録します。すべてのタスクカードは所属するProjectに紐づけられています。ボードの中核となるステータス列には、Todo（未着手）、In progress（進行中）、Blocked（ブロック中）、Done（完了）が用意されています。

データ構造が整った後、それをいかに動かすかが課題になります。人間が毎回手作業でグループを作成し、メンバーを招集し、ステータスを更新していては、かえって生産性が低下してしまいます。そのため、このシステム全体の中心的なハブとして、Projects Manager（プロジェクトマネージャーBot、略称 PM）と呼ばれる常駐型のエージェントが配置されています。

原典においてPM Botに与えられている役割は、プロジェクト運用とメタ業務（Meta work）です。このBotにはProject Opsという専用のスキル（Skill）が付与されており、以下の3つの役割に専念します。

• プロジェクトの発足とチャンネル開設：Grok Botのサイドバーに、新規プロジェクト名と同名の専用チャンネルを作成する。
• メンバーの編成：プロジェクトの性質に応じて、「ベンチ（待機リスト）」から最適な専門Botを選抜してチャンネルに追加する。
• カンバンの同期：グループ内のやり取りを常時把握し、バックグラウンドでNotionのプロジェクトおよびタスク項目を保守・更新する。

メンバー編成の原則：チーム規模の抑制と人間の承認ゲート

多くのマルチエージェントシステムで陥りがちな典型的な過ちは、モデルが無制限に新しいサブエージェントを派生させてしまうことです。これにより、コンテキストの肥大化、役割の重複、計算リソースや処理精度の著しい分散が引き起こされます。

Ericは実践を通じて、PM Botに対して極めて抑制的な3つのメンバー編成ルール（Staffing Rules）を設定しました。

1. 既存メンバーの再利用を最優先（Reuse existing bots first）：安易に新しい役割を作成しません。プロジェクト立ち上げ時、PMはまず既存の「ベンチ（Bench）」を確認し、あらかじめ定義されている汎用ロール（コードを書くCoder、リサーチを担当するResearcher、ドキュメント作成を担うWriterなど）を優先して招集します。
2. 厳格な上限人数（At most five bots besides PM）：各プロジェクトチャンネルにおいて、PM以外に提案できる専門Botは最大5体までとし、チャンネル全体のBot数の上限を6体としています。Eric自身も、この6体という制限は自身が便宜的に設定した値であり、技術的・物理的な絶対上限ではないと認めています。著者はチーム規模に関する比較テスト結果を提示していないため、読者は自身のタスク要件に応じて調整可能です。
3. 新規ロールの追加には人間の承認が必須（Create a new bot only after I say yes）：既存のベンチメンバーでは現在のタスクを到底処理できない場合に限り、PMは新しいBotの作成を提案できます。ただし、人間が明示的に同意（Say yes）するまで作成を実行してはなりません。新しく作られた役割は、ニーズに応じて将来も再利用可能な特定分野の専門Botとして蓄積することも、現在のプロジェクト限定の一時的なBot（Ephemeral）として扱うこともできます。

実際の運用メカニズム：要件定義から「明示的ブロック」への遷移

プロジェクトチャンネル、メンバー名簿、Notionボードが揃った後、一連のワークフローはどのように稼働するのでしょうか。これは4つの連続したアクションとして整理できます。

1. チャンネル内での共同スコープ定義（Scoping）

人間のリードが新設されたチャンネルに入り、名簿に登録された専門Botたちと直接対話を開始します。プロジェクトの大目標を、独立して実行可能な個別のタスクへと全員で分解していきます。このプロセスは、人間のチームで行われる要件定義ミーティングと同様であり、人間が制約や期待値を提示し、専門Botが具体的な実装方針を補完します。

2. PM Botによるバックグラウンド監視と台帳管理

議論が進む間、PM Botも常にチャンネル内に常駐していますが、ほとんどの場合は会話に口を挟みません。その主な任務はバックグラウンドの監視役であり、参加者の会話の結論を解析して、合意されたタスクをNotionのTasksデータベースへ正確に登録し、プロジェクトの進行に伴ってデータベースを最新状態に保ち続けることです。

3. タスクの着手とカンバンによる可視化

役割分担が決まると、専門Bot（Coderなど）は自身のタスクカードを自律的に実行し始めます。作業の開始に伴い、Notion上のカードは自動的にIn progressへと移動します。人間のリードは「進捗はどうなっているか」と何度も尋ねる必要はなく、ボード上のカードが各列を移動していく様子を確認するだけで済みます。

4. 耐障害性の要：Blockedの明示的付与と人間への自発的エスカレーション

専門Botが実行中に予期せぬ障害（特定の認証情報の不足、外部APIのエラー、指示の曖昧さなど）に直面した場合、プロンプトの設定により、その場で明確に作業を中断して助けを求めるよう義務付けられています。

その標準的な動作は、直ちにそのタスクカードのステータスをBlocked（ブロック中）に変更し、プロジェクトチャンネル内で人間のリードを明示的にメンション（@）して、障害の原因を説明した上で人間の追加情報を待つことです。

この設計により、人間は「作業を最初から最後まで常時監視する」負担から解放され、「目標の設定 ＋ 重要な障害の排除（Blocker Remover）」というレバレッジの高い役割へとシフトできます。

チーム協調のためのプロンプト設定リファレンス

原典にはProject Opsスキルの完全な内容は記載されていませんが、実際の運用メカニズムと3つのメンバー編成原則に基づき、以下に設定例を作成しました。なお、他のプラットフォームで再現する場合は、チャンネル作成、Bot管理、カンバン更新の各機能を備えている必要があります。

以下の設定例はEricのプロジェクト制協調ロジックを忠実に再現したものであり、数値や名称にはプレースホルダーを使用しています。読者は自身のツールチェーン（NotionをLark Base、DingTalk AI Table、GitHub Projectsなどに置き換えるなど）に合わせて適宜調整してください。

1. Projects Manager（プロジェクト統括Bot）設定リファレンス

本記事のワークフローに基づき編集者が作成した設定例

役割の定義：プロジェクトのメタ業務（Meta work）コーディネーター。プロジェクトのチャンネル開設、メンバー編成、カンバンの同期を担当する。

作業原則と厳格な制約事項：

1. ベンチ優先：新規プロジェクトの立ち上げ要求を受けた際は、既存のメンバープール（[利用可能なBotリスト：Coder、Researcher、Writerなど]）を優先して検索すること。独断で新しいBotを作成することを固く禁ずる。
2. 人数上限のゲート：あなた自身を除き、各プロジェクトチャンネルに招集を提案できる専門Botは最大[5]体までとし、1つのチャンネル内のBot総数は人間のメンバーを除いて[6]体を超えてはならない。
3. 新規作成の承認ゲート：既存のベンチメンバーではプロジェクトの専門要件を満たせない場合、人間のリードに対して新規作成を提案し、理由と役割の構想を説明できる。ただし、人間が明示的に承認の返答をした後でのみ、作成インターフェースを呼び出すことができる。
4. バックグラウンドでの静かな保守：プロジェクトチャンネル内では発言頻度を抑え、グループ内のタスク分担とステータス変更の監視に注力し、[Projectsデータベース]と[Tasksデータベース]の状態をリアルタイムで最新に維持すること。

2. 専門実行Bot（Coder / Researcherなど）の協調規約リファレンス

本記事のワークフローに基づき編集者が作成した設定例

役割の定義：プロジェクトチャンネル内の専門実行者。個別のタスクを引き受け、具現化を担当する。

ブロックと支援要請のプロトコル：

1. タスクの引き受けと着手：タスクを引き受けた後、紐づくNotionのタスクステータスをIn progressに更新し、実行を開始する。
2. 障害時のサーキットブレーカー（Blocked）：以下の理由によりタスクをこれ以上進められない場合、実行結果の捏造や無制限の盲目的なリトライを固く禁ずる：
   • 必要な設定情報、環境依存関係、または認証パラメータが不足している場合
   • 要件の詳細に論理的矛盾があるか、コンテキストが不足している場合
   • 呼び出しの連続失敗が[設定した回数]回を超えた場合
3. エスカレーションのトリガー：障害が発生した場合、必ず以下の2段階のアクションを実行すること：
   • ステップ1：タスクボード上の当該タスクのステータスをBlockedに変更する。
   • ステップ2：プロジェクトチャンネル内でメッセージを送信する。送信フォーマットの規則：@人間のリード [障害の概要]、不足している情報は以下の通りです：[具体的なリスト]。人間の返信を待ってから、作業を再開すること。

日常業務への実践的な示唆

Ericが締めくくりで感慨深げに語っているように、「このマルチBot協調システムを作り込めば作り込むほど、本来人間のために設計された業務システムそのものに近づいていく。すなわち、1つのタスクカンバン、1人の進行管理マネージャー、作業を引き受ける専門家たち、ひときわ目を引くBlockedの列、そして専用のコミュニケーションチャンネルだ」。

実務で常駐型エージェントを活用したいと考える読者にとって、この実験的なフレームワークは非常に実践的な3つの示唆を与えてくれます。

1. 「万能な単一チャット画面」の幻想から脱却する：すべてのプロジェクトの背景、コーディング規約、ビジネス目標を1つの長いチャットに詰め込もうとしてはなりません。複雑な業務を個別の「プロジェクトチャンネル」に分割し、チャンネルの境界によって業務ごとのコンテキストノイズを自然に分離します。
2. 暗黙的な状態を徹底的に外在化する：エージェントがバックグラウンドで動く際、最大の懸念となるのはブラックボックス化です。タスクを視覚的なカンバンの4つの標準列（Todo、In progress、Blocked、Done）として外在化することで、チーム全体が今どのような状態にあるのかをいつでも一目で把握できます。
3. 障害の明示化こそが人間とAIの最適な協調インターフェースである：人間がエージェントのフルタイムの世話係になる必要はありませんし、完全に放任するのも危険です。エージェントが困難に直面した際に明確に赤信号（Blocked）を点灯させて人間を呼ぶ仕組みこそが、現段階において自動化と信頼性を両立させる最も合理的な接点と言えます。