メッセージ

このページでは、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.* など）— 上限とストリーミング切り替え。

完全なスキーマについてはConfigurationを参照してください。

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

チャネルは再接続後に同じメッセージを再配信する場合があります。OpenClawはchannel/account/peer/session/message IDをキーとする短命キャッシュを保持し、重複配信で別のエージェントランがトリガーされないようにします。

受信メッセージのデバウンス

同一送信者からの連続した素早いメッセージを、messages.inbound で単一のエージェントターンにまとめることができます。デバウンスはチャネル＋会話ごとにスコープされ、返信のスレッディング/IDには最新のメッセージが使用されます。

設定（グローバルデフォルト＋チャネルごとのオーバーライド）:

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

注意:

  • デバウンスはテキストのみのメッセージに適用されます。メディア/添付ファイルは即座にフラッシュされます。
  • コントロールコマンドはデバウンスをバイパスし、スタンドアロンのまま処理されます。

セッションとデバイス

セッションはクライアントではなくGatewayが所有します。

  • ダイレクトチャットはエージェントのメインセッションキーに集約されます。
  • グループ/チャネルは固有のセッションキーを持ちます。
  • セッションストアとトランスクリプトはGatewayホスト上に存在します。

複数のデバイス/チャネルが同じセッションにマッピングされることがありますが、履歴はすべてのクライアントに完全に同期されるわけではありません。推奨: 長い会話には1つの主要デバイスを使用し、コンテキストの乖離を避けてください。Control UIとTUIは常にGatewayバックのセッショントランスクリプトを表示するため、信頼できるソースです。

詳細: セッション管理

受信メッセージの本文と履歴コンテキスト

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|breakPreference）
  • agents.defaults.blockStreamingCoalesce（アイドルベースのバッチング）
  • agents.defaults.humanDelay（ブロック応答間の人間らしい間合い）
  • チャネルオーバーライド: *.blockStreaming と *.blockStreamingCoalesce（非Telegramチャネルでは明示的に *.blockStreaming: true が必要）

詳細: Streaming + chunking

推論の可視性とトークン

OpenClawはモデルの推論を表示または非表示にできます:

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

詳細: Thinking + reasoning directives および Token use

プレフィックス、スレッディング、返信

送信メッセージのフォーマットは messages で一元管理:

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

詳細: Configuration およびチャネルドキュメント

arrow_back
前へ
Presence
次へ
Streaming
arrow_forward