他のチャットプラットフォーム

統合が動作しているが、まだ個別のガイドに分離されていないチャンネル。各チャンネルは機能ゲートで制御されており、ビルド時に channel-<name> 機能を有効にしてください。

送信応答のペース調整 (`reply_min_interval_secs`)

すべての送信チャネルは、オプションの reply_min_interval_secs = N フィールド（範囲 0..=REPLY_MIN_INTERVAL_MAX_SECS、デフォルト 0）を受け付けます。設定すると、オーケストレーターはチャネルを (channel, recipient) ごとのペーシングレイヤーでラップし、同じピアへの連続した送信応答が少なくとも N 秒の間隔を空けるようにします。0（デフォルト）はパススルーで、ラッパーは割り当てられず、オーバーヘッドもありません。

フロアがアクティブな間、フロアが経過する前に到着した送信は、境界付きのFIFOキューに入ります。バックグラウンドワーカーがフロアレートでキューを排出するため、設定されたケイデンスで応答が順序どおりに届きます。キューの深さはデフォルトで 16（「エージェントが一時的にバースト状態になった」ケースに適しています）で、REPLY_QUEUE_DEPTH_CEILING（1024）が上限です。キューが満杯の場合、最新の送信が破棄され、channel_alias、編集済みのrecipient、queue_depth、queue_max、dropped_charsを含むWARNが出力されます。本文の内容はログに残りません。

単一の返信内のストリーミングによる下書き更新は、ペース調整の対象にはなりません（ライブプレビューがフリーズしてしまうため）。キューに入るのは最終的な send（およびターミナルの finalize_draft 書き込み）のみです。異なる受信者は互いに独立しており、ある相手へのペース調整が別の相手へのメッセージをブロックすることはありません。このラッパーは、アイドル状態のLRU方式による退避を通じて、最大 PACING_RECIPIENT_CAP（1024）個の異なる相手の状態を保持します。キューに入っている処理がなく、送信中でもない行のみが回収されるため、この上限はアイドル状態に対する目標値であり、すべてがアクティブなバースト時における無条件のハードリミットではありません。

用途: ミリ秒未満の即時応答がAIであることを露呈してしまう、ペアになったアイデンティティを持つチャネル。ワイヤレベルの対応は9つのチャネル(Telegram、Discord、Slack、Mattermost、Webhook、iMessage、Matrix、Signal、WhatsApp)でエンドツーエンドに実装済み。統合テストでは、TelegramとWhatsApp Webで下限値とオーバーフローのコントラクトを固定しています。

Webhook に関する注意: 同期 Webhook チャネルでは、送信側の応答は呼び出し元のリクエストに対する HTTP レスポンスになります。reply_min_interval_secs の下限値が 0 以外の場合、そのレスポンスは下限値の期間だけ保留されることがあり、呼び出し元自身のリクエストタイムアウトを超える可能性があります。Webhook の呼び出し元が遅延応答を許容できる場合にのみ下限値を設定するか、0 のままにして上流側でペース調整を行ってください。

iMessage

iMessage は Linq Partner API（[channels.linq.<alias>]）または実験的な直接アダプター（[channels.imessage.<alias>]）を使用できます。

direct アダプターはmacOS専用です。AppleScriptのオートメーションを使って送信し、~/Library/Messages/chat.db を読み取って受信します。Messages を制御するには「オートメーション」へのアクセスを許可し、データベースを読み取るには「フルディスクアクセス」を許可してください。

WeChat personal iLink Bot (微信个人号 iLink)

WeChat personal iLink Bot は、個人の WeChat 会話向けに iLink Bot API に対して QR コードログインを使用します。

WeCom (企業微信 / WeChat Work)

Two WeCom variants are implemented. They map to different WeCom products, build features, and config keys, so pick the one that matches how the bot is provisioned:

Translation to ja:

2つのWeComバリアントが実装されています。これらは異なるWeCom製品、ビルド機能、設定キーに対応しているため、ボットのプロビジョニング方法に合わせて適切なものを選んでください:

	Bot Webhook (群機器人)	AI Bot WebSocket (AIボット)
機能をビルド	`channel-wecom`	`channel-wecom-ws`
設定キー	`[channels.wecom.<alias>]`	`[channels.wecom_ws.<alias>]`
メッセージの流れ	送信テキストのみ	双方向（ストリーミングドラフト付き）
エンドポイント	`https://qyapi.weixin.qq.com/cgi-bin/webhook/send`	`wss://openws.work.weixin.qq.com` のロングコネクション

Bot Webhook (群機器人)

A WeCom group robot (群机器人) sends text messages to the group it was created in. Add a robot to the target group from the WeCom client, copy the webhook key out of its webhook URL, and configure the channel under the default alias:

Wait, let me correct that: the source is English and needs translating.

WeCom グループボット（群机器人）は、作成されたグループにテキストメッセージを送信します。WeCom クライアントから対象グループにボットを追加し、Webhook URL から key をコピーして、default エイリアスでチャネルを設定してください:

[channels.wecom.default]
enabled = true
webhook_key = "<GROUP-BOT-WEBHOOK-KEY>"

次に、channels = ["wecom"] を使ってエージェントに紐付けます。

この方式は送信専用です。WeCom のグループボット Webhook には ZeroClaw が購読するコールバックがないため、グループ内のメッセージがこの方式経由でエージェントに届くことはありません。この方式は、エージェントの通知をグループへ送信する用途に使ってください。受信した WeCom メッセージから始まる会話については、下記の AI Bot WebSocket 方式を使用してください。

AI Bot WebSocket (AIボット)

WeCom の AI Bot (智能机器人) ロングコネクション API は双方向チャネルを提供します。1対1チャットとグループチャットのメッセージを受信し、ストリーミングのドラフト更新を含めて、同じソケット経由で返信します。ボットの認証情報（bot_id と secret）は、WeCom 管理コンソールで AI Bot を作成する際に発行されます。

[channels.wecom_ws.primary]
enabled = true
bot_id = "<AI-BOT-ID>"
secret = "<AI-BOT-SECRET>"

# 受信認可。空のリストはすべてを拒否します。少なくとも1つのエントリがなければ、受信メッセージは一切受け付けられません。"*" はすべての送信者を許可し、許可リストを無効にするため、具体的な ID の指定を推奨します。
allowed_users = ["<wecom-user-id>"]
allowed_groups = ["<group-chat-id>"]

# 任意: グループのテキストでボットを呼び出す際の名前です。例: "@danya say hi" における "danya"。これにより、汎用の返信意図の事前チェックが、グループメッセージがボット宛てであると認識できるようになります。
bot_name = "<BOT-NAME>"

次に、channels = ["wecom_ws.primary"] を指定してエージェントにバインドします（設定キーのエイリアスを使用してください）。

デフォルト設定の注意点:

ダウンロードしたメディア添付ファイルは復号され、チャネルのワークスペース配下にキャッシュされ、file_retention_days（デフォルト7）を経過すると削除されます。max_file_size_mb（デフォルト20）を超えるダウンロードは拒否されます。
返信はデフォルトで下書きの更新としてストリーミング表示されます（stream_mode = "partial"）。返信を一括で1回だけ配信するには stream_mode = "off" を設定してください。このチャネルでサポートされているのは partial と off のみで、multi_message は起動時に拒否されます。
チャンネルごとの proxy_url および excluded_tools フィールドは、通常どおり適用されます。

Inbound の送信者 ID は、上記の allowed_* リストの代わりに、channel が wecom_ws または wecom_ws.<alias> である peer group から取得される場合もあります。

DingTalk

Alibabaのエンタープライズメッセンジャー。

Lark / Feishu

Lark または Feishu のどちらにも channel-lark を使ってビルドします。ルートの channel-feishu 機能は channel-lark のエイリアスです。実行時の選択は引き続き use_feishu = true で行われます。

QQ

Tencentのコンシューマー向けメッセンジャーです。Bot APIへのアクセスには開発者登録が必要で、[channels.qq.<alias>] にはコンソールの app_id と app_secret を指定します。

Inbound送信者はプラットフォームの不透明なIDです。単一チャットのメッセージではuser_openid、グループの@メッセージではmember_openidを使用します。ピアグループ（external_peers）を通じて認可します。ピアセットが空の場合はすべての送信者が拒否されるため、接続済みでありながら応答しないボットは、通常、送信者のピアグループエントリを持っていません。

返信メッセージは受信メッセージの msg_id をそのまま返すパッシブな送信のため、追加の権限は不要です。返信ではない送信（cron配信や zeroclaw channel send）はアクティブメッセージとなり、ボットのアクティブメッセージのクォータを消費します。インスタンスは qq.<alias> で指定し、宛先は1対1チャットの場合は user:<user_openid>、グループの場合は group:<group_openid> で指定します。グループIDは送信者の member_openid ではなく、メッセージの group_openid から取得します。--channel-id qq のみを指定した場合は、default のエイリアスのみが解決されます。

zeroclaw channel doctor は、チャネルの認証情報を使ってボット自身の ID（GET /users/@me）を照会します。そのため「正常」という判定は、アプリのシークレットからトークンが発行できることだけでなく、送信と受信で使われるのと同じトークンを API が受け入れていることを意味します。このプローブで受信者を検証することはできません。プラットフォームは 1 対 1 チャットの相手の ID を検索する手段を提供していないため、使用できないアドレスは送信を試みたときにはじめて表面化します。

Matrix: E2EE、デバイス検証、Synapse/Dendrite固有の事項
Telegram: ボット作成、エイリアス、ペアリング、およびピア認証
Discord
Slack
Mattermost
LINE
Nextcloud Talk
Signal
WhatsApp

上記のいずれかのチャンネルで設定に問題が発生した場合は、再現手順を記載してIssueを提出してください。その後、専用のガイドとして公開するかどうかを検討します。

ZeroClaw Docs