メッセージ¶

このページでは、OpenClaw が受信メッセージ、セッション、キューイング、ストリーミング、および推論の可視性をどのように扱うかをまとめて説明します。

メッセージフロー（概要）¶

Inbound message
  -> routing/bindings -> session key
  -> queue (if a run is active)
  -> agent run (streaming + tools)
  -> outbound replies (channel limits + chunking)

キーノブは設定で動作します:

messages.*：プレフィックス、キューイング、グループの挙動。
agents.defaults.*：ブロックストリーミングとチャンク化の既定値。
チャンネルごとの上書き（channels.whatsapp.*、channels.telegram.* など）：上限やストリーミングトグル。キャップやストリーミングの切り替えを行います

完全なスキーマは設定を参照してください。

インバインドされた¶

チャンネルは再接続後に同じメッセージを再配信できます。チャンネルは、再接続後に同一メッセージを再配信する場合があります。OpenClaw は channel/account/peer/session/message id をキーにした短命のキャッシュを保持し、重複配信が別のエージェント実行を引き起こさないようにします。

受信デバウンス中¶

同一送信者 からの短時間に連続するメッセージは、messages.inbound により単一のエージェントターンにバッチ化できます。デバウンスはチャンネル + 会話単位で適用され、返信のスレッド化/ID には最新のメッセージを使用します。 18. デバウンスはチャンネル＋会話ごとにスコープされ、返信のスレッド化／ID には最新のメッセージが使用されます。

設定（グローバル既定 + チャンネルごとの上書き）：

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

注記：

デバウンスは テキストのみ のメッセージに適用されます。メディア/添付は即時にフラッシュされます。
制御コマンドはデバウンスをバイパスし、単独で扱われます。

セッションとデバイス¶

セッションはクライアントではなく、ゲートウェイが所有します。

ダイレクトチャットは、エージェントのメインセッションキーに集約されます。
グループ/チャンネルは、それぞれ独自のセッションキーを持ちます。
セッションストアとトランスクリプトは、ゲートウェイホスト上に保存されます。

複数のデバイス/チャンネルが同一セッションにマッピングされることはありますが、履歴はすべてのクライアントへ完全に同期されるわけではありません。推奨事項として、文脈の分岐を避けるため、長い会話では 1 台の主要デバイスを使用してください。 Control UI と TUI は常に、ゲートウェイに裏打ちされたセッションのトランスクリプトを表示するため、それらが信頼できる唯一の情報源です。推奨：異なるコンテキストを避けるために、長時間の会話に主要なデバイスを1つ使用してください。 Control UI と TUI は常に、ゲートウェイでバックエンドされたセッショントランスクリプトを表示するため、それらは真実の源となります。

詳細：セッション管理。

受信ボディと履歴コンテキスト¶

OpenClaw は プロンプトボディ と コマンドボディ を分離します。

Body: エージェントに送信されるプロンプトテキスト。これには、チャンネルエンベロープとオプションの履歴ラッパーが含まれます。
CommandBody：指示/コマンド解析用の生のユーザーテキスト。
RawBody：CommandBody のレガシーエイリアス（互換性のため保持）。

チャンネルが履歴を提供する場合、共通のラッパーを使用します。

[Chat messages since your last reply - for context]
[Current message - respond to this]

非ダイレクトチャット（グループ/チャンネル/ルーム）では、現在のメッセージボディ に送信者ラベルがプレフィックスとして付与されます（履歴エントリと同じ形式）。これにより、リアルタイムメッセージとキュー/履歴メッセージが、エージェントプロンプト内で一貫します。これにより、エージェントプロンプトでリアルタイムおよびキュー/ヒストリーメッセージが一貫しています。

履歴バッファは 保留のみ です。つまり、実行をトリガーしなかったグループメッセージ（例：メンションゲートされたメッセージ）を含み、すでにセッショントランスクリプトにあるメッセージは除外されます。

ディレクティブストリップは現在のメッセージ セクションにのみ適用されるため、履歴はそのまま残ります。履歴をラップするチャンネルは、元のメッセージテキストに CommandBody (または RawBody )を設定し、組み合わせたプロンプトとして Body を維持します。ディレクティブのストリッピングは 現在のメッセージ セクションのみに適用されるため、履歴は保持されます。履歴をラップするチャンネルは、元のメッセージテキストとして 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、既定はオフ）
agents.defaults.blockStreamingBreak（text_end|message_end）
agents.defaults.blockStreamingChunk（minChars|maxChars|breakPreference）
agents.defaults.blockStreamingCoalesce（アイドルベースのバッチ処理）
agents.defaults.humanDelay（ブロック返信間の人間らしい間）
チャンネルごとの上書き：*.blockStreaming および *.blockStreamingCoalesce（Telegram 以外のチャンネルでは、明示的な *.blockStreaming: true が必要）

詳細：ストリーミング + チャンク化。

推論の可視性とトークン¶

OpenClaw は、モデルの推論を公開または非公開にできます。

/reasoning on|off|stream が可視性を制御します。
推論コンテンツは、モデルが生成した場合、トークン使用量に引き続きカウントされます。
Telegram は、下書きバブルへの推論ストリームをサポートします。

詳細：思考 + 推論ディレクティブおよびトークン使用量。

プレフィックス、スレッド化、返信¶

送信メッセージのフォーマットは、messages に集約されています。

messages.responsePrefix、channels.<channel>.responsePrefix、channels.<channel>.accounts.<id>.responsePrefix（送信プレフィックスのカスケード）、および channels.whatsapp.messagePrefix（WhatsApp 受信プレフィックス）
replyToMode による返信のスレッド化と、チャンネルごとの既定値

詳細：設定および各チャンネルのドキュメント。

Fundamentals

Bootstrapping

Sessions and memory

Multi-agent

Messages and delivery

Messages

メッセージ¶