Configuration
チャネルルーティング
チャンネルとルーティング
OpenClaw は、返信をメッセージの送信元チャンネルへ返します。モデルがチャンネルを選択することはありません。ルーティングは決定論的であり、ホスト設定によって制御されます。
主要な用語
- チャンネル:
discord、googlechat、imessage、irc、line、signal、slack、telegram、whatsappなどの同梱チャンネル Plugin、およびインストール済み Plugin のチャンネル。webchatは内部の WebChat UI チャンネルであり、設定可能な送信チャンネルではありません。 - AccountId: チャンネルごとのアカウントインスタンス(サポートされている場合)。
- オプションのチャンネル既定アカウント:
channels.<channel>.defaultAccountは、送信パスでaccountIdが指定されていない場合に使用するアカウントを選択します。- 複数アカウント構成で 2 つ以上のアカウントを設定する場合は、明示的な既定値(
defaultAccountまたはdefaultという名前のアカウント)を設定してください。設定しない場合、フォールバックルーティングによって、正規化された最初のアカウント ID が選択される可能性があります。
- 複数アカウント構成で 2 つ以上のアカウントを設定する場合は、明示的な既定値(
- AgentId: 分離されたワークスペースとセッションストア(「頭脳」)。
- SessionKey: コンテキストの保存と同時実行制御に使用するバケットキー。
送信先プレフィックス
明示的な送信先には、telegram:123 や tg: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-peer、per-channel-peer、per-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:42agent:main:discord:channel:123456:thread:987654
メイン DM ルートの固定
session.dmScope が main の場合、ダイレクトメッセージは 1 つのメインセッションを共有することがあります。所有者以外からの DM によってセッションの lastRoute が上書きされるのを防ぐため、次の条件をすべて満たす場合、OpenClaw は allowFrom から固定所有者を推測します。
allowFromにワイルドカードではないエントリがちょうど 1 つ含まれている。- そのエントリを、対象チャンネルの具体的な送信者 ID に正規化できる。
- 受信 DM の送信者が、その固定所有者と一致しない。
この不一致が発生した場合でも、OpenClaw は受信セッションのメタデータを記録しますが、メインセッションの lastRoute の更新はスキップします。
保護された受信記録
保護されたパスで新しい OpenClaw セッションを作成してはならない場合、チャンネル Plugin は受信セッションレコードを createIfMissing: false としてマークできます。このモードでは、OpenClaw は既存セッションのメタデータと lastRoute を更新することがありますが、単にメッセージを検出しただけでルート専用のセッションエントリを作成することはありません。
ルーティングルール(エージェントの選択方法)
ルーティングでは、受信メッセージごとに1 つのエージェントを選択します。
- 相手の完全一致(
peer.kindとpeer.idを含むbindings)。 - 親の相手との一致(スレッドの継承)。
- 相手のワイルドカード一致(相手の種別に対する
peer.id: "*")。 - Guild とロールの一致(Discord):
guildIdとrolesを使用。 - Guild の一致(Discord):
guildIdを使用。 - チームの一致(Slack):
teamIdを使用。 - アカウントの一致(チャンネルの
accountId)。 - チャンネルの一致(そのチャンネル上の任意のアカウント、
accountId: "*")。 - 既定のエージェント(
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)以下にある各エージェントの 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-agents と Doctor の検証手順を使用してください。
移行およびオフラインメンテナンスのワークフローでは、引き続き session.store と {agentId} テンプレートを使用して従来のストアパスを選択できます。
Gateway と ACP のセッション検出では、既定の agents/ ルートおよびテンプレート化された session.store ルートの下にある、ディスク上のエージェントストアもスキャンします。検出されるストアは、解決されたエージェントルートの内部に留まり、通常ファイルである従来の sessions.json を使用する必要があります。シンボリックリンクとルート外のパスは無視されます。
WebChat の動作
WebChat は選択されたエージェントに接続し、既定ではそのエージェントのメインセッションを使用します。このため、WebChat では、そのエージェントのチャンネル横断コンテキストを 1 か所で確認できます。
返信コンテキスト
受信した返信には、次の情報が含まれます。
- 使用可能な場合は、
ReplyToId、ReplyToBody、ReplyToSender。 - 引用されたコンテキストは、
[Replying to ...]ブロックとしてBodyに追加されます。
これはすべてのチャンネルで一貫しています。