メッセージ

このページでは、OpenClaw が受信メッセージをどのように扱い、セッション管理、キューイング、ストリーミング、および推論プロセス（Reasoning）の可視化をどのように行っているかをまとめて説明します。

メッセージフローの概要

受信メッセージ
  -> ルーティング/バインディング -> セッションキーの決定
  -> キューイング (実行中のエージェントがある場合)
  -> エージェント実行 (ストリーミング + ツール使用)
  -> 送信返信 (チャネル制限に合わせた分割/チャンク化)

主な設定項目は構成ファイル (openclaw.json) 内にあります:

messages.*: プレフィックス、キューイング、グループチャットの挙動。
agents.defaults.*: ブロックストリーミングやチャンク化のデフォルト設定。
チャネルごとのオーバーライド (channels.whatsapp.*, channels.telegram.* など): 各プラットフォームの制限事項やストリーミングの有効・無効。

詳細はゲートウェイ構成を参照してください。

受信メッセージの重複排除 (Dedupe)

チャネルによっては、再接続後に同じメッセージを再度配信することがあります。OpenClaw は、チャネル、アカウント、送信者、セッション、メッセージ ID をキーとした短期間のキャッシュを保持し、同じメッセージによってエージェントが二重に実行されるのを防ぎます。

入力メッセージの集約 (Debouncing)

同じ送信者 から短時間に連続して届いたテキストメッセージは、messages.inbound 設定により 1 つのエージェントターンにまとめて処理できます。デバウンス（集約）はチャネルと会話（conversation）ごとに適用され、返信のスレッドや ID には最新のメッセージの情報が使用されます。構成例 (グローバルデフォルト + チャネルごとの上書き):

{
  messages: {
    inbound: {
      debounceMs: 2000,
      byChannel: {
        whatsapp: 5000,
        slack: 1500,
        discord: 1500,
      },
    },
  },
}

補足:

デバウンスはテキストのみのメッセージに適用されます。メディアや添付ファイルは即座に処理されます。
制御用コマンドはデバウンスをバイパスし、単独で実行されます。

セッションとデバイス

セッションはクライアント側ではなく、ゲートウェイ側で管理されます。

ダイレクトチャット（DM）は、エージェントのメインセッションキーに集約されます。
グループチャットやチャネルは、それぞれ独自のセッションキーを持ちます。
セッションのデータや記録（トランスクリプト）はゲートウェイが動作しているホスト上に保存されます。

複数のデバイスやチャネルから同じセッションにアクセスできますが、履歴がすべてのクライアントに完全に同期されるわけではありません。長い会話を行う場合は、文脈の食い違いを避けるために 1 つのメインデバイスを使用することを推奨します。コントロール UI や TUI は常にゲートウェイ側の完全な履歴を表示するため、これらが「真実のソース」となります。詳細はセッション管理を参照してください。

受信本文と履歴コンテキスト

OpenClaw は、エージェントへ送るプロンプト用本文と、コマンド解析用のコマンド用本文を分けて扱います:

Body: エージェントに送信されるプロンプトテキスト。チャネル固有の情報や、オプションの履歴情報が含まれる場合があります。
CommandBody: ディレクティブやコマンド解析に使用される、生のユーザーテキスト。
RawBody: CommandBody の古い別名（互換性のために保持）。

チャネルが履歴情報を付加する場合、以下の共有ラッパーを使用します:

[Chat messages since your last reply - for context] (前回の返信以降のメッセージ - コンテキスト用)
[Current message - respond to this] (現在のメッセージ - これに応答してください)

ダイレクトチャット以外（グループ、チャネル、ルーム）では、現在のメッセージ本文の先頭に送信者のラベルが付与されます（履歴エントリと同じスタイル）。これにより、リアルタイムのメッセージと、キューに溜まっていたメッセージや過去の履歴が、エージェントのプロンプト内で一貫した形式になります。履歴バッファに含まれるのは未処理のメッセージのみです。具体的には、メンション（言及）制約などにより実行がトリガーされなかったグループメッセージが含まれ、すでにセッション記録に保存済みのメッセージは除外されます。ディレクティブ（コマンド）の除去は「現在のメッセージ」セクションにのみ適用されるため、履歴内の指示はそのまま残ります。履歴をラッピングするチャネルは、CommandBody (または RawBody) に元のメッセージテキストをセットし、Body には結合されたプロンプトをセットする必要があります。履歴バッファの制限数は、グローバル設定の messages.groupChat.historyLimit、またはチャネルごとの上書き（channels.slack.historyLimit, channels.telegram.accounts.<id>.historyLimit など。0 で無効化）で調整可能です。

キューイングとフォローアップ

すでに実行中のエージェントがある場合、新しく届いたメッセージはキュー（待ち行列）に入れられるか、実行中のプロセスに割り込む（ステアリング）か、あるいは現在のターン終了後にまとめて処理（フォローアップ）されます。

messages.queue (および messages.queue.byChannel) で設定します。
モード: interrupt, steer, followup, collect、およびそれぞれのバックログ（未処理分）対応バリアント。

詳細はキューイングを参照してください。

ストリーミング、チャンク化、およびバッチ処理

ブロックストリーミング機能を使用すると、モデルがテキストを生成するそばから部分的な返信を送信できます。チャンク化（分割）の際はチャネルごとの文字数制限を遵守し、コードブロックなどが途中で途切れないよう配慮されます。主な設定項目:

agents.defaults.blockStreamingDefault (on|off。デフォルトは off)
agents.defaults.blockStreamingBreak (text_end または message_end)
agents.defaults.blockStreamingChunk (minChars, maxChars, 分割優先度)
agents.defaults.blockStreamingCoalesce (アイドル時間に基づくバッチ処理)
agents.defaults.humanDelay (ブロックごとの返信間に挟む人間らしい一時停止)
チャネルごとの設定: *.blockStreaming, *.blockStreamingCoalesce (Telegram 以外のチャネルでブロック返信を有効にするには、明示的に true に設定する必要があります)

詳細はストリーミングとチャンク化を参照してください。

推論プロセス（Reasoning）の可視性とトークン

モデルの思考プロセス（推論内容）を表示するかどうかを制御できます:

/reasoning on|off|stream コマンドで切り替え可能です。
推論内容は表示設定にかかわらず、モデルが生成した時点でトークン消費の対象となります。
Telegram では、ドラフト（下書き）バブル内への推論ストリーミングをサポートしています。

詳細は思考と推論の指示およびトークン利用を参照してください。

プレフィックス、スレッド、および返信

送信メッセージの形式は messages セクションで一元管理されています:

messages.responsePrefix, channels.<channel>.responsePrefix, channels.<channel>.accounts.<id>.responsePrefix (送信時のプレフィックス階層)、および channels.whatsapp.messagePrefix (WhatsApp 受信時のプレフィックス)。
replyToMode およびチャネルごとのデフォルト設定による、返信スレッドの紐付け。

詳細はゲートウェイ構成 - メッセージおよび各チャネルのドキュメントを参照してください。

基礎

ブートストラップ

セッションとメモリ

マルチエージェント

メッセージと配信