Configuration

チャネルルーティング

チャンネルとルーティング

OpenClaw は、返信をメッセージの送信元チャンネルへ返します。モデルがチャンネルを選択することはありません。ルーティングは決定論的であり、ホスト設定によって制御されます。

主要な用語

  • チャンネル: discordgooglechatimessageirclinesignalslacktelegramwhatsapp などの同梱チャンネル Plugin、およびインストール済み Plugin のチャンネル。webchat は内部の WebChat UI チャンネルであり、設定可能な送信チャンネルではありません。
  • AccountId: チャンネルごとのアカウントインスタンス(サポートされている場合)。
  • オプションのチャンネル既定アカウント: channels.<channel>.defaultAccount は、送信パスで accountId が指定されていない場合に使用するアカウントを選択します。
    • 複数アカウント構成で 2 つ以上のアカウントを設定する場合は、明示的な既定値(defaultAccount または default という名前のアカウント)を設定してください。設定しない場合、フォールバックルーティングによって、正規化された最初のアカウント ID が選択される可能性があります。
  • AgentId: 分離されたワークスペースとセッションストア(「頭脳」)。
  • SessionKey: コンテキストの保存と同時実行制御に使用するバケットキー。

送信先プレフィックス

明示的な送信先には、telegram:123tg:123 などのプロバイダープレフィックスを含めることができます。コアは、選択されたチャンネルが last または未解決の場合に限り、かつ読み込まれた Plugin がそのプレフィックスを公開している場合に限り、そのプレフィックスをチャンネル選択のヒントとして扱います。呼び出し元がすでに明示的なチャンネルを選択している場合、プロバイダープレフィックスはそのチャンネルと一致する必要があります。WhatsApp から telegram:123 へ配信するようなチャンネル間の組み合わせは、Plugin 固有の送信先正規化が行われる前に失敗します。

channel:<id>user:<id>room:<id>thread:<id>imessage:<handle>sms:<number> などの送信先種別およびサービスのプレフィックスは、選択されたチャンネルの文法内に留まります。これら単独でプロバイダーを選択することはありません。

セッションキーの形式(例)

ダイレクトメッセージは、既定でエージェントのメインセッションにまとめられます。

  • agent:<agentId>:<mainKey>(既定: agent:main:main

session.dmScope は DM の集約方法を制御します。main(既定)は 1 つのメインセッションを共有しますが、per-peerper-channel-peerper-account-channel-peer は DM を個別のセッションに保持します。ルートバインディングでは、bindings[].session.dmScope を使用して、一致した相手のスコープを上書きできます。

ダイレクトメッセージの会話履歴がメインセッションと共有されている場合でも、外部 DM に対するサンドボックスとツールのポリシーでは、アカウントごとに派生したダイレクトチャットのランタイムキーを使用します。これにより、チャンネルから送信されたメッセージがローカルのメインセッション実行と同様に扱われることを防ぎます。

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

  • グループ: 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.dmScopemain の場合、ダイレクトメッセージは 1 つのメインセッションを共有することがあります。所有者以外からの DM によってセッションの lastRoute が上書きされるのを防ぐため、次の条件をすべて満たす場合、OpenClaw は allowFrom から固定所有者を推測します。

  • allowFrom にワイルドカードではないエントリがちょうど 1 つ含まれている。
  • そのエントリを、対象チャンネルの具体的な送信者 ID に正規化できる。
  • 受信 DM の送信者が、その固定所有者と一致しない。

この不一致が発生した場合でも、OpenClaw は受信セッションのメタデータを記録しますが、メインセッションの lastRoute の更新はスキップします。

保護された受信記録

保護されたパスで新しい OpenClaw セッションを作成してはならない場合、チャンネル Plugin は受信セッションレコードを createIfMissing: false としてマークできます。このモードでは、OpenClaw は既存セッションのメタデータと lastRoute を更新することがありますが、単にメッセージを検出しただけでルート専用のセッションエントリを作成することはありません。

ルーティングルール(エージェントの選択方法)

ルーティングでは、受信メッセージごとに1 つのエージェントを選択します。

  1. 相手の完全一致peer.kindpeer.id を含む bindings)。
  2. 親の相手との一致(スレッドの継承)。
  3. 相手のワイルドカード一致(相手の種別に対する peer.id: "*")。
  4. Guild とロールの一致(Discord): guildIdroles を使用。
  5. Guild の一致(Discord): guildId を使用。
  6. チームの一致(Slack): teamId を使用。
  7. アカウントの一致(チャンネルの accountId)。
  8. チャンネルの一致(そのチャンネル上の任意のアカウント、accountId: "*")。
  9. 既定のエージェントagents.list[].default。なければリストの最初のエントリ、さらにフォールバックとして main)。

バインディングに複数の一致フィールド(peerguildIdteamIdroles)が含まれる場合、そのバインディングを適用するには、指定されたすべてのフィールドが一致する必要があります

一致したエージェントによって、使用するワークスペースとセッションストアが決まります。

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

ブロードキャストグループを使用すると、OpenClaw が通常返信する状況(例: WhatsApp グループでメンション/アクティベーションのゲートを通過した後)に、同じ相手に対して複数のエージェントを実行できます。

設定:

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

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

設定の概要

  • agents.list: 名前付きエージェント定義(ワークスペース、モデルなど)。
  • bindings: 受信チャンネル/アカウント/相手をエージェントにマッピングします。

例:

json5
{  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)以下にある各エージェントの SQLite データベースに保存されます。

  • ~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite

古いインストールでは、~/.openclaw/agents/<agentId>/sessions/ 以下に、従来のトランスクリプト JSONL ファイルと sessions.json 行ストアが存在する場合があります。Gateway の起動時と openclaw doctor --fix の実行時に、使用頻度の高い従来の行と履歴が SQLite に自動的にインポートされます。明示的な移行証跡が必要な場合は、openclaw doctor --session-sqlite inspect --session-sqlite-all-agentsDoctor の検証手順を使用してください。 移行およびオフラインメンテナンスのワークフローでは、引き続き session.store{agentId} テンプレートを使用して従来のストアパスを選択できます。

Gateway と ACP のセッション検出では、既定の agents/ ルートおよびテンプレート化された session.store ルートの下にある、ディスク上のエージェントストアもスキャンします。検出されるストアは、解決されたエージェントルートの内部に留まり、通常ファイルである従来の sessions.json を使用する必要があります。シンボリックリンクとルート外のパスは無視されます。

WebChat の動作

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

返信コンテキスト

受信した返信には、次の情報が含まれます。

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

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

関連項目

Was this useful?
On this page

On this page