設定

チャネルルーティング

OpenClawは返信をメッセージが送られてきたチャネルに戻すようにルーティングします。モデルがチャネルを選択することはなく、ルーティングは決定論的でホストの設定によって制御されます。

主要な用語

  • チャネル: whatsapp, telegram, discord, slack, signal, imessage, webchat。
  • AccountId: チャネルごとのアカウントインスタンス（サポートされている場合）。
  • オプションのチャネルデフォルトアカウント: channels.<channel>.defaultAccount は、アウトバウンドパスが accountId を指定していない場合に使用するアカウントを選択します。
    • マルチアカウント設定では、2つ以上のアカウントが設定されている場合、明示的なデフォルト（defaultAccount または accounts.default）を設定してください。設定がない場合、フォールバックルーティングが最初に正規化されたアカウントIDを選択する可能性があります。
  • AgentId: 分離されたワークスペース + セッションストア（「脳」）。
  • SessionKey: コンテキストを保存し、並行性を制御するために使用されるバケットキー。

セッションキーの形式（例）

ダイレクトメッセージはエージェントのメインセッションに統合されます:

  • agent:<agentId>:<mainKey> (デフォルト: agent:main:main)

グループとチャネルはチャネルごとに分離されたままです:

  • グループ: agent:<agentId>:<channel>:group:<id>
  • チャネル/ルーム: agent:<agentId>:<channel>:channel:<id>

スレッド:

  • Slack/Discordのスレッドは、ベースキーに :thread:<threadId> を追加します。
  • Telegramのフォーラムトピックは、グループキーに :topic:<topicId> を埋め込みます。

例:

  • agent:main:telegram:group:-1001234567890:topic:42
  • agent:main:discord:channel:123456:thread:987654

メインDMルートの固定

session.dmScope が main の場合、ダイレクトメッセージは1つのメインセッションを共有する可能性があります。非所有者のDMによってセッションの lastRoute が上書きされるのを防ぐため、OpenClawは以下の条件がすべて満たされた場合、allowFrom から固定された所有者を推論します:

  • allowFrom にワイルドカード以外のエントリがちょうど1つ存在する。
  • そのエントリが、そのチャネルの具体的な送信者IDに正規化できる。
  • インバウンドDMの送信者が、その固定された所有者と一致しない。

この不一致の場合、OpenClawは依然としてインバウンドセッションメタデータを記録しますが、メインセッションの lastRoute の更新はスキップします。

ルーティングルール（エージェントの選択方法）

ルーティングは各インバウンドメッセージに対して1つのエージェントを選択します:

  1. 完全なピアマッチ (bindings の peer.kind + peer.id)。
  2. 親ピアマッチ (スレッド継承)。
  3. ギルド + ロールマッチ (Discord) guildId + roles 経由。
  4. ギルドマッチ (Discord) guildId 経由。
  5. チームマッチ (Slack) teamId 経由。
  6. アカウントマッチ (チャネルの accountId)。
  7. チャネルマッチ (そのチャネルの任意のアカウント、accountId: "*")。
  8. デフォルトエージェント (agents.list[].default、それ以外はリストの最初のエントリ、フォールバックは main)。

バインディングに複数のマッチフィールド (peer, guildId, teamId, roles) が含まれる場合、提供されたすべてのフィールドが一致する必要があります。一致したエージェントが、使用されるワークスペースとセッションストアを決定します。

ブロードキャストグループ（複数エージェントの実行）

ブロードキャストグループを使用すると、OpenClawが通常返信する場合に同じピアに対して複数のエージェントを実行できます（例: WhatsAppグループ内でのメンション/アクティベーションゲーティング後）。設定:

{
  broadcast: {
    strategy: "parallel",
    "120363403215116621@g.us": ["alfred", "baerbel"],
    "+15555550123": ["support", "logger"],
  },
}

参照: ブロードキャストグループ。

設定概要

  • agents.list: 名前付きエージェント定義（ワークスペース、モデルなど）。
  • bindings: インバウンドチャネル/アカウント/ピアをエージェントにマッピング。

例:

{
  agents: {
    list: [{ id: "support", name: "Support", workspace: "~/.openclaw/workspace-support" }],
  },
  bindings: [
    { match: { channel: "slack", teamId: "T123" }, agentId: "support" },
    { match: { channel: "telegram", peer: { kind: "group", id: "-100123" } }, agentId: "support" },
  ],
}

セッションストレージ

セッションストアは状態ディレクトリ（デフォルト ~/.openclaw）の下に存在します:

  • ~/.openclaw/agents/<agentId>/sessions/sessions.json
  • JSONLトランスクリプトはストアと同じ場所に存在

session.store と {agentId} テンプレートを使用してストアパスをオーバーライドできます。

WebChatの動作

WebChatは選択されたエージェントに接続し、デフォルトでそのエージェントのメインセッションを使用します。このため、WebChatではそのエージェントのクロスチャネルコンテキストを1か所で確認できます。

返信コンテキスト

インバウンド返信には以下が含まれます:

  • 利用可能な場合、ReplyToId、ReplyToBody、ReplyToSender。
  • 引用されたコンテキストは [Replying to ...] ブロックとして Body に追加されます。

これはすべてのチャネルで一貫しています。

ブロードキャストグループチャネル位置情報解析