2026、OpenClawでTelegramとDiscordを二重チャネル運用：Bot設定、ペアリング許可、権限マトリクス、マルチチャネル衝突の排障FAQ

窓口がTelegram・開発がDiscordのように経路が分かれ、OpenClawは小さなGatewayになります。ここでは二つのBotを載せる際の実務観点だけを並べます。本番のTLS／WebhookはLinux Gateway本番運用、短命トークンと到達性は短周期Runner登録チェックリストと併読してください。

二重チャネルが「アダプタ追加」より難しい理由

ID・スレッド・メンション・レート制限の前提が異なります。セッションとツール呼び出しの単一の正を先に決めず配線すると、対人問題がバグに見えます。承認の権威チャネル、破壊的ツールを許すチャネル、ブリッジの1対1か扇状かの三問を紙に書きます。

Bot設定（トークン／トランスポート／Webhook）

TelegramとDiscordは別アプリ・別トークンを別変数／別ファイルへ。貼り間違え防止と即ローテーションの運用をセットにします。受信方式は片方ずつ一方式に固定し、TelegramのWebhookとロングポーリング混在は二重イベントの典型です。切替後は再接続を一巡させてから成功とします。

ペアリングと許可リスト

新IDはペアリングコードか管理者許可のどちらかを必須にします。Telegram数値IDとDiscordスノーフレークはファイルを分け、混在させません。DMは既定オフ、例外は文書化してからにします。

権限マトリクス

曖昧さは深夜の障害に直結するので、Runbookへ表をそのまま貼ります。

マルチチャネル衝突と排障

二重配送はブリッジとネイティブAPIの併用で起きやすいです。部屋単位で取り込み経路を一つにし、相関IDで外向きを揃えます。レイテンシ非対称はDiscordの「考え中」とTelegramの無表示の差で誤認されます。キュー深さをログへ出し、重要通知は文言を合わせます。