OpenClaw で 5 つの役割を持つ AI 協調オペレーティングシステムを構築：技術的詳細解説

結論を先に：これは「マルチボット」ではなく、単一ゲートウェイによるマルチエージェント OS です

「5 つの AI ロール」と聞くと、多くの人は「5 つの独立したボットを動かしているんでしょ？」と最初に思います。

はい、でも違います。

私のアーキテクチャはこうです：

• 1 つの Gateway プロセスが、チャンネルアクセスとルーティングを一元化
• 5 つの独立した Agent：Commander、Strategist、Engineer、Creator、Thinker
• 各 Agent は独立したワークスペースを持つ（人格、ルール、メモリ、セッションはすべて分離）
• Discord + Telegram のデュアルチャンネルを同時稼働（多くのプラットフォームに対応可能ですが、私は Discord のみ使用）、バインディングで精密なメッセージ配信を実現
• プライベートチャットとグループチャットでは完全に異なるメカニズムを使用

例え話をすると、これは 5 人を雇って自由に動かす部屋に放り込むことではありません。これは会社を作ることです。組織構造、職務記述書、コミュニケーションプロトコル、独立したオフィス、会議ルールがあるのです。

OpenClaw 自体は、複数のプラットフォーム（Discord、Telegram、WhatsApp など）と複数のモデル（Claude、GPT、Gemini など）をサポートし、データが完全にローカルに保存される、オープンソースのパーソナル AI アシスタントフレームワークです。

そのマルチエージェント機能こそが、私がこれを選んだ核となる理由です。ネイティブでマルチエージェントの独立ワークスペースとバインディングルーティングをサポートしており、その上に真のコラボレーションシステムを構築できました。

1. 全体アーキテクチャ：シングルゲートウェイ + マルチエージェント + マルチワークスペース + マルチチャンネル

まず、最下層のアーキテクチャ上の決定について説明します。

1) シングルゲートウェイによる一元ホスティング

現在、私は 1 つの OpenClaw Gateway プロセスですべての機能を担っています。メッセージアクセス、ルーティング、セッション管理、ツール呼び出し、メモリインデックス、状態管理のすべてを 1 つのゲートウェイで行っています。

なぜ各ロールに一連のサービスを実行しないのか？理由は 3 つ：

• 集中管理：保守する Gateway は 1 つだけで済み、各ロールに独立したサービスを実行する必要がない。
• 統一設定：1 つのマスター設定でグローバル戦略を管理でき、監視やトラブルシューティングも一元化できる。
• コラボレーションの基盤：ロール同士が連携するには、効率的な通信のために同じランタイムにある必要がある。

2) 5 つの緩いボットではなく、5 つの並列エージェント

私の 5 つの固定ロール：

• Commander（zongzhihui）：全体状況把握、タスク分解、割り当て、修正、終了。
• Strategist（junshi）：戦略分析、提案評価、リスク予測。
• Engineer（engineer）：技術実行、コード実装、システム保守。
• Creator（creator）：コンテンツ生成、表現最適化、外部出力。
• Thinker（zhiku）：知識監査、品質管理、コンプライアンスチェック。

各エージェントには独自のワークスペースがあります。例えば、workspace-engineer、workspace-junshi などです。人格ファイル、ルールファイル、メモリファイル、スクリプトアセットはすべて独立しており、相互に汚染しません。

3) マルチチャンネルデュアルスタックアクセス：Discord + Telegram

同じ Gateway が Discord と Telegram の両方に接続されています。各ロールは両方のチャンネルに accountId レベルのバインディングを持っています。もちろん、この同じ設定ファイルを使用して、Lark や WeChat などのより多くのプラットフォームを統合することもできます。

これは「プラットフォーム間での重複デプロイ」ではなく、「同じ脳のクラスター、異なるアクセス層」です。私は Discord を主要なコラボレーションの戦場として設定しました。

複数のエージェントをグループ内で協力・連携させたい場合は、Discord を選ぶだけで十分です。1 つのプラットフォームで十分です。他のものは完璧ではありません。試しました！

2. ルーティング層：「アカウント」を「ロール」にマッピングするバインディング

これがシステム全体のエントリロジックです。

私はデュアルチャンネルに対して明示的なバインディング戦略を設定しました：channel + accountId -> agentId。

具体的には：

• discord + zongzhihui -> zongzhihui
• discord + engineer -> engineer
• telegram + creator -> creator
• ... 合計 10 のマッピング（5 ロール × 2 チャンネル）

なぜこれを行うのか？

なぜなら、システムはエントリ層で「このメッセージを誰が処理すべきか」を決定し、すべてのエージェントに聞かせてから奪い合いで答えるようにさせるわけではないからです。このステップがうまくいかないと、その後のすべてのコラボレーションが混乱します。

バインディングは、このシステムの「フロントデスクのトリアージ」と考えることができます。メッセージが来ると、まずどのチャンネルとアカウントが受信したかを確認し、次に対応するロールに直接ルーティングします。クリーンで効率的です。

3. セッション分離：プライベートチャットが交差せず、グループチャットが混乱しない理由

これは私のシステムで最も重要なエンジニアリングポイントの 1 つです。

コア設定：session.dmScope = per-account-channel-peer

このパラメータは、プライベートチャットのコンテキストが「アカウント + チャンネル + ピアユーザー」の 3 次元で分離されることを意味します。

なぜこれを選ぶのか？

• 同じ人物が Discord と Telegram で同じロールに連絡しても、コンテキストは交差しません。
• 異なるユーザーが同じロールに連絡しても、コンテキストは完全に分離されます。
• マルチエージェント + マルチアカウントのシナリオでは、「クロストーク」のリスクが最小限に抑えられます。

言い換えれば、私は「マルチロール」を作成しただけでなく、「コンテキスト分離戦略のエンジニアリング」も行ったのです。

多くの人がマルチエージェントシステムを構築するとき、ロールは明確に分けられていますが、コンテキスト管理は混乱しています。ユーザー A のプライベートチャットの内容がユーザー B の返信に混ざったり、Discord の会話のメモリが Telegram のコンテキストを汚染したりします。

per-account-channel-peer は、マルチアカウントシナリオで OpenClaw が推奨する分離戦略であり、私のテストでは確かに最も安定した選択肢であることが示されています。

4. グループチャットオーケストレーション：ルール駆動のコラボレーション、自由な会話ではない

この部分は最も興味深く、最も落とし穴が多い部分です。

コア戦略：Commander のグローバルリスニング + 他のロールは @ トリガー

Discord 側のグループチャット戦略は次のとおりです：

Commander：requireMention = false（グローバルリスニング）

• グループ内のすべてのメッセージをデフォルトで見ることができます。
• 全体状況を把握し、コラボレーションが必要かどうかを判断し、タスク分解と作業割り当てを行います。

他の 4 つのロール：`requireMention = true`（@ トリガー）

• 明示的に @メンションされた場合にのみ行動します。
• ノイズを減らし、お互いに話し合うのを避けます。

各ロールには `mentionPatterns` が設定されています

• たとえば、Engineer は @Engineer または [@engineer](https://x.com/@engineer) でトリガーできます。
• グループ内での呼び出しをより安定して予測可能にします。

この組み合わせの本質は何ですか？

• Commander は「全体像を見る」、まるでチームの PM のようです。
• 専門ロールは「必要に応じてトリガーされる」、まるでさまざまなポジションのエキスパートのようです。
• グループの発言は「自由形式」から「制御されたリレー」に変わります。

実際の効果：グループで質問をすると、Commander が最初にそれがどのタイプのタスクかを判断し、次に対応するロールを @メンションして処理させます。ロールが終了したら、Commander がループを閉じます。プロセス全体は、まるで実際のチームが会議をしているかのようです。

5. Discord vs Telegram：なぜ Discord が主戦場なのか

厳密に言えば、「Discord だけがコラボレーションできる」というわけではありません。単に、私の現在の設定では、Discord がマルチロールの公開コラボレーションオーケストレーションに最も適しているということです。

具体的な理由：

1. Discord に 5 つの並列アカウントと明確な @コラボレーションメカニズムを設定しました。
2. ロールのアイデンティティ、会話の連鎖、リレープロセスはすべて可視化されており、チームの議論のように見えます。
3. Commander のグローバルリスニング + 他のロールのメンションゲートの戦略は、グループチャットのシナリオでより直感的です。
4. 現在、Discord の groupPolicy を open に設定しており、より高い柔軟性を提供します。

Telegram 側では、私の戦略は allowlist + mention gate に傾いており、より制約があり安全で、「制御された本番チャンネル」に適しています。

まとめると、Discord はコラボレーションのステージです。

6. 設定層 + プロンプト層：デュアルトラックガバナンス

これが、このシステムと「ただ遊んでいるだけ」の最大の違いです。

設定だけに頼るのでも、プロンプトだけに頼るのでもありません。私は 2 つの重複するトラックを使用しています。

A. 設定トラック（プラットフォームレベルの制御）

これらは OpenClaw プラットフォームレベルのハード設定です：

• channel policy：groupPolicy、dmPolicy、グループとプライベートチャットの基本戦略を制御。
• requireMention：誰がデフォルトで @メンションされて応答する必要があるか。
• bindings：メッセージルーティングマッピング。
• dmScope：セッション分離の粒度。
• agentToAgent ping-pong 制限：これを 0 に設定し、エージェント間の無意味なやり取りを直接抑制。

最後のものは非常に重要です。エージェント間の ping-pong を制限しないと、グループ内で 2 つの AI が礼儀正しく、互いに確認し合い、無限にループするのを目にすることになります。0 に設定すると、システムに「エージェントは自動的にお互いに ping を送るべきではない」と伝えます。

B. ルールトラック（行動レベルの制御）

これらは各ワークスペースに私が書いたルールファイルです：

• SOUL.md：ロールのソウルファイル。人格、口調、責任、出力品質の最低基準。
• AGENTS.md：オペレーションマニュアル。コラボレーションチェックプロセス、メモリ読み書き規範、遅延ローディング戦略。
• ROLE-COLLAB-RULES.md：ロール固有のコラボレーション境界とレッドライン。
• TEAM-RULEBOOK.md：チームの統一されたハードルール（全ロールで共有）。
• TEAM-DIRECTORY.md：ロールと実際の ID のマッピングテーブル。@メンションの誤りを防ぐため。

これら 2 つのトラックを重ね合わせる効果は次のとおりです：プラットフォーム層がフローを制限 + 行動層が制約を追加。

すべてをモデルの「自己認識」に委ねるわけではありません。モデルは間違いを犯し、ドリフトし、ルールを忘れます。したがって、最初に設定層でハード制約を設定し、次にプロンプト層でソフトなガイダンスを提供する必要があります。二重の保険です。

7. ワークスペースファイルシステム：各ロールの「独立したオフィス」

各ワークスペースのファイルの骨格は基本的に一貫しています。これは重要です。私は各ロールにランダムにファイルを積み上げているのではなく、標準化していることを示しています。

標準ファイル構造

8. メモリシステム：遅延ローディング + 階層化 + アーカイブ

メモリ管理は、マルチエージェントシステムで最も見落とされがちですが、最も問題を引き起こす部分です。

私の戦略は「できるだけ覚える」ではなく、明確な階層化です：

1) 短期ログ（日次メモリ）

• その日のタスクプロセス、コンテキスト断片、現場での決定を記録します。
• ファイルは日付で名前が付けられ、自然にタイムラインを作成します。

2) 長期記憶（MEMORY.md）

• 安定した好み、長期決定、再利用可能な経験、ハードルールを抽出します。
• すべてが入るわけではなく、検証され安定した情報のみが書き込まれます。

3) グループ長期記憶（GROUP_MEMORY.md）

• グループからの再利用可能で安全な情報のみを保持します。
• プライベートチャットの内容は混在させません。これはプライバシーのレッドラインです。

4) コールドアーカイブ（archive）

• 古いデータは定期的にアーカイブされ、アクティブなコンテキストが制御不能に拡大するのを防ぎます。
• 削除されるのではなく、優先度の低いストレージに移動されます。

5) 検索メカニズム（memory_search + memory_get）

• まずセマンティックリコール、次に正確な読み取り。
• フルローディングを回避します。コンテキストウィンドウは限られたリソースであり、無駄にすることはできません。

この階層化の核となる価値：

• プライベートチャットの品質がグループチャットの履歴によって汚染されない。
• グループコラボレーションが個人のプライベートコンテキストによって妨害されない。
• コンテキストウィンドウは「必要に応じてロード」され、「完全に注ぎ込まれる」わけではない。

私はコンテキスト予算をリソース管理の問題として扱っています。トークンは有限であり、詰め込まれたメモリはすべて推論空間を占有します。したがって、すべてのビットを慎重に計算する必要があります。

9. プライベートモード vs グループモード：同じロールのための 2 つの戦略

これは多くの人が考えないことです。同じロールは、プライベートチャットとグループチャットで異なる動作をするべきです。

私は各ロールの SOUL.md で 2 つのモードを明示的に区別しています：

プライベートモード：

• 各ロールはソロエキスパートとして行動し、ユーザーの問題をエンドツーエンドで処理します。
• コラボレーションプロセスは不要で、完全な回答を直接提供します。
• 品質基準は「1 人で処理できる」ことです。

グループモード：

• チームコラボレーションプロトコルに従って、インクリメンタルリレーを実行します。
• 各ロールは自分の得意なことだけを担当します。
• Commander がリンクとクローズを担当します。

各ロールに固有の内容：

• Commander：グループ内ではデフォルトで沈黙し観察し、必要なときにのみ強く介入して、他の人の話を遮らないようにします。
• Engineer：成果物は実行可能で、検証可能で、ロールバック可能でなければなりません。単にアイデアを提供するだけではいけません。
• Strategist：結論には前提条件と検証パスが伴わなければなりません。単なる思いつきではいけません。
• Thinker：監査は問題のグレーディングと修復計画を提供しなければなりません。単に「問題がある」と言うだけではいけません。
• Creator：表現は真正性と実行可能性を犠牲にしてはいけません。単に美学を追求するだけではいけません。

これが「同じロールが異なるシナリオで異なるパフォーマンスを発揮する」ことの源泉です。モデルの独自の判断に依存するのではなく、ルールファイルを通じて明示的に伝えられます。

最後に

マルチエージェントは、単にいくつかのボットを増やすことではありません。それはエンジニアリングシステム全体です。アーキテクチャ設計、ルーティング戦略、セッション分離、コラボレーションオーケストレーション、メモリ管理、ルールガバナンス、自動チェックまで、すべての層で慎重な設計が必要です。

OpenClaw は素晴らしい基盤を提供しますが、「実行可能」から「うまく実行できる」までのエンジニアリングの量は、ほとんどの人が想像するよりもはるかに大きいです。

もしあなたが同様のことをしているなら、この記事が何らかの参考になれば幸いです。もちろん、この内容は始まりに過ぎません。今後、さらにいくつかの記事を公開し、より「具体的で洗練された」問題を共有する予定です。