バージョン: 2026.1.9 で追加
概要
ブロードキャストグループを使うと、複数のエージェントが同じメッセージを同時に処理し、それぞれ応答できます。これにより、1 つの WhatsApp グループまたは DM の中で、役割ごとに分担したエージェントチームを 1 つの電話番号で運用できます。 現在対応しているのは WhatsApp のみ です (web チャンネル)。
ブロードキャストグループは、チャンネルの allowlist とグループの有効化ルールを評価したあとに適用されます。WhatsApp グループでは、OpenClaw が通常なら返信する場面でのみブロードキャストが実行されます。たとえば、グループ設定によってはメンション時にだけ反応します。
ユースケース
1. 特化したエージェントチーム
責務を小さく分けた複数のエージェントを配置できます。2. 多言語サポート
3. 品質保証ワークフロー
4. タスク自動化
設定
基本設定
トップレベルにbroadcast セクションを追加します (bindings と同じ階層です)。キーには WhatsApp の peer ID を使います。
- グループチャット: グループ JID (例:
120363403215116621@g.us) - DM: E.164 形式の電話番号 (例:
+15551234567)
処理戦略
メッセージ処理の進め方も指定できます。Parallel (並列、デフォルト)
すべてのエージェントが同時に処理します。Sequential (順次)
エージェントを順番に処理します。後続のエージェントは、前のエージェントの完了を待ちます。完全な例
動作の仕組み
メッセージフロー
- 受信メッセージ が WhatsApp グループに届きます。
- ブロードキャスト判定: システムが peer ID が
broadcastに含まれているか確認します。 - ブロードキャストリストにある場合:
- 指定されたすべてのエージェントがメッセージを処理します。
- 各エージェントは固有のセッションキーと独立したコンテキストを持ちます。
- 処理方式は並列 (デフォルト) または順次です。
- ブロードキャストリストにない場合:
- 通常のルーティングが適用されます (最初に一致した binding が使われます)。
セッションの分離
ブロードキャストグループ内の各エージェントは、次の要素をそれぞれ独立して持ちます。- セッションキー (
agent:alfred:whatsapp:group:120363...vsagent:baerbel:whatsapp:group:120363...) - 会話履歴 (ほかのエージェントの発言は見えません)
- ワークスペース (設定されている場合は別々のサンドボックス)
- ツールアクセス (異なる許可 / 拒否リスト)
- メモリ/コンテキスト (別々の IDENTITY.md、SOUL.md など)
- グループコンテキストバッファ (直近のグループメッセージに基づくコンテキスト) は peer ごとに共有されるため、トリガー時にはすべてのブロードキャストエージェントが同じ入力コンテキストを参照します。
- 異なる性格や役割
- 異なるツールアクセス (例: 読み取り専用と読み書き可能)
- 異なるモデル (例:
opusとsonnet) - 異なるインストール済みスキル
例: セッション分離
グループ120363403215116621@g.us に ["alfred", "baerbel"] を割り当てた場合の例です。
Alfred のコンテキスト
ベストプラクティス
1. エージェントの焦点を絞る
各エージェントは 1 つの明確な責務に絞って設計してください。2. 役割が分かる名前を付ける
エージェント名から役割が分かるようにします。3. 必要なツールだけ許可する
各エージェントには必要最小限のツールだけを与えます。4. パフォーマンスを意識する
エージェント数が多い場合は、次の点を検討してください。- 速度重視なら
"strategy": "parallel"(デフォルト) を使う - ブロードキャストグループの規模を 5〜10 エージェント程度に抑える
- 単純な役割のエージェントには高速なモデルを使う
5. 障害は個別に扱う
各エージェントは独立して失敗します。1 つのエージェントのエラーが、ほかのエージェントを止めることはありません。互換性
プロバイダー
現時点でブロードキャストグループが動作するのは次のプロバイダーです。- ✅ WhatsApp (実装済み)
- 🚧 Telegram (予定)
- 🚧 Discord (予定)
- 🚧 Slack (予定)
ルーティング
ブロードキャストグループは既存のルーティング設定と併用できます。GROUP_A:alfredのみが応答します (通常ルーティング)GROUP_B:agent1とagent2が応答します (ブロードキャスト)
broadcast は bindings より優先されます。
トラブルシューティング
エージェントが応答しない場合
確認事項:- エージェント ID が
agents.listに存在する - peer ID の形式が正しい (例:
120363403215116621@g.us) - エージェントが denylist に入っていない
1 つのエージェントしか応答しない場合
原因: peer ID がbindings には存在するものの、broadcast に入っていない可能性があります。
対処: broadcast 設定へ追加するか、bindings から削除してください。
パフォーマンスに問題がある場合
多数のエージェントで遅いとき- 1 グループあたりのエージェント数を減らす
- より軽量なモデルを使う (
opusの代わりにsonnet) - サンドボックスの起動時間を確認する
例
例 1: コードレビューチーム
- code-formatter: “インデントを修正し、型ヒントを追加しました”
- security-scanner: “12 行目に SQL インジェクションの脆弱性があります”
- test-coverage: “カバレッジは 45% です。エラーケースのテストが不足しています”
- docs-checker: “関数
process_dataの docstring がありません”
例 2: 多言語サポート
API リファレンス
Config Schema
フィールド
strategy(オプション): エージェントの処理方法"parallel"(デフォルト): すべてのエージェントを同時に実行します"sequential": 配列の順序でエージェントを実行します
[peerId]: WhatsApp グループ JID、E.164 番号、またはその他の peer ID- 値: その peer のメッセージを処理するエージェント ID の配列
制限事項
- 最大エージェント数: 厳密な上限はありませんが、10 個を超えると遅くなる可能性があります。
- 共有コンテキスト: エージェント同士は互いの応答を見ません。これは設計上の仕様です。
- メッセージ順序: 並列実行時は応答順が保証されません。
- レート制限: すべてのエージェント実行が WhatsApp のレート制限にカウントされます。
今後の機能強化
予定されている機能:- 共有コンテキストモード (エージェント同士が互いの応答を参照できる)
- エージェント間の連携 (エージェント同士でシグナルを送れる)
- 動的なエージェント選択 (メッセージ内容に応じて実行対象を決める)
- エージェント優先順位 (一部のエージェントを先に応答させる)