2026 OpenClaw チャネル側トラブルシュート：グループ @mention、pairing 承認、Slack/Discord Bot 権限チェックリスト（接続は緑・無応答）
最短デプロイと18789 の5ステップは通っているのに、DMは返るがグループだけ無音、あるいはチャネル表示は緑のまま誰も返さない——多くはモデルではなくIMポリシーとBot権限です。本文はheartbeat/思考の沈黙やMatrix 記事と役割分担し、requireMention・pairing/新規送信者承認・Slack/Discord 最小スコープに絞ります。対照表、6段コマンド手順、Runbookに貼れるパラメータで「チャネル側」と誤再インストールを切り分けます。
目次
1. 三つの痛み：接続はあるが無応答の典型原因
ログは処理済みでもユーザー側は空白——多くはチャネルポリシーで、APIキー即死ではありません。モデル差し替え前に「プラットフォームがBotに渡したか」と「ゲートウェイがモデルに渡したか」を分けます。
ユーザー送信の直後にSlackのEvent DeliveryやDiscordのGatewayログに生のペイロードが現れるかを先に確認してください。現れない段階でnpm ciやプロンプト調整をしても再現性がありません。儀表板の緑ランプはTLS疎通や単発ヘルスを示すだけで、全ワークスペース・全ギルドへの配信保証ではありません。
- @mention と requireMention：
@Bot必須なら通常メッセージはポリシーで捨てられ、障害に見えます。DMは例外。テストチャンネルでオフまたは許可リスト化し、運用ドキュメントに「公開チャンネルでは@必須」と明記。チャンネルごとに挙動が違う場合は部屋単位の上書きを疑います。 - pairing と新規承認：
pairing approve前はモデルに届きません。接続テストは通るが新人だけ無反応。本番ハードニングと併読しポリシー遮断と認証失敗を分離。アップグレード後は「pairing list必須」を変更メモに。 - Slack/Discord 権限とintents：
chat:write欠如、チャンネル未招待、DiscordでMessage Content Intent未設定など、Inboundは見えてOutboundだけ失敗することがあります。WebhookとSocketで必要スコープが異なります。Slack複数ワークスペースでは実際に使うWSにアプリが入っているか、イベントURLが本番ゲートウェイを指すかを確認。ダッシュボードが緑でもWSごとにpayloadが来ないことがあります。
次節の表で仮説を一つに絞ってからモデル層へ。設定ファイルを複数人で編集しているチームは、メインブランチへマージした瞬間にrequireMentionだけ古い値へ戻ることがあるため、デプロイ前にgit diffでポリシー差分を必ずレビューしてください。
Runbookは二枚に分割：チャネル側＝probe・pairing・mention・ACL・コールバック、セッション/モデル側＝models・thinking・heartbeat・Cron。一枚にまとめると毎回キー回転から始まります。
Matrixは動くがIMだけ死ぬなら、HomeserverよりIMポリシーを先に疑います。変更は一度に一変数、前後でプローブを記録します。
2. 症状対照表
| 症状 | 先に疑う | 検証 | 後回しでよい |
|---|---|---|---|
| グループのみ無音、DMは可 | requireMention・部屋設定 | @付き短文 | グローバルモデルキー |
| 新メンバーだけ無音 | pairing滞留 | pairing list | 18789番ポート |
| 全チャネル無音・doctor警告 | トークン/握手 | channels status --probe | CPU飽和 |
| Discord DM可・ギルド不可 | intents・ロール・可視性 | 開発者ポータルと権限表 | temperature |
| Slackはスレ内のみ | イベント購読・インストール範囲 | 再認可とURL整合 | 「不安定」ごまかし |
「後回し」列は誤診しやすい方向：18789が本当に死んでいればDMも通常死にます。temperatureは文体だけでイベント配信は変わりません。
3. 六手順：probe・pairing・doctor・logs
外から内へ。一手順一仮説。同時に三か所を直すと、どれが効いたか分からずオンコールの学習資産になりません。
- probe：
openclaw channels status --probe。各チャネルのOK/失敗とレイテンシをメモ。断続失敗はリバプロタイムアウト・TLS中間証明書・443上のヘルスパスが実Webhookパスと不一致などを先に疑う。Discordのintent以前の話になりがちです。 - pairing：
openclaw pairing list --channel <name>で滞留解消後に群れテスト。一晩で招待リンクが拡散するとpendingが全員ぶん溜まる典型パターンです。 - mention：設定の
requireMentionをサンドボックスで切替。@の有無比較。一般ユーザーアカウントで試す（管理者例外に注意）。 - doctor：
openclaw doctor。Docker併用時はコンテナとホストの設定一致。doctor合格≠プラットフォーム権限十分。 - logs：
openclaw logs --followでpolicy drop等を確認。プローブに[OC-PROBE]接頭辞。 - 永続化：launchdのcwdと
openclaw.jsonがSSH編集と一致するか。launchd環境と同系の落とし穴。
4. 引用可能なパラメータと運用指標
① Discord本番では多くの場合Message Content Intentが必要。メンバー一覧やプレゼンスに触れるならServer Members Intentなど追加だが、最小権限で足りるものだけを有効化。② Slackは送信と履歴読取（Event APIとSocket Modeで必要スコープが異なる）、チャンネルへ/inviteしないとmessage.channels系イベント自体が来ない。
③ コールバックURLはHTTPSでゲートウェイの公開ホストと一致。リバプロがパスプレフィックスを剥がす場合はアプリ側basePathと揃える。④ ポリシー変更・再認可後はキャッシュで数分遅れるため、検証は二サイクル空ける。⑤ ユーザー向けに「公開チャンネルでは@Bot」を明文化するとサポート工数が下がる。⑥ pairing一括承認はチケットIDと実行者をログ化（ハードニングのトークン記録と同様）。
運用上の粗い目安として、通常負荷で「ユーザー送信→ゲートウェイの最初のログ行」がだいたい2〜3秒以内に収まっているなら、ボトルネックはLLMレイテンシより前段のキューやポリシーである可能性が高い。逆にprobeは成功するがログにpolicy dropだけが増えているなら、mention/pairingの設定差分を優先してください。
5. Token回転から安定Macクラウドへ
無応答のたびにBotトークンを回すとmention/pairingの本命が隠れ、監査もできません。probe→pairing→doctor→logsをRunbookに固定し、キー轮换は別の承認フローに分離する方が再現性があります。
ノートPCではスリープとローカルFWでイベント再現がブレ、今日は通っても明日落ちるように見えます。常時通電のMacクラウドならSlack/Discordの再接続や指数バックオフも追跡しやすいです。
Windowsや汎用Linuxだけにゲートウェイを置き、別チームがXcodeや署名をMacで回す構成は、手戻りと説明コストが積み上がります。VPSMAC M4 Macクラウドにゲートウェイとlaunchdジョブを同居させれば本番に近い挙動で切り分けできます。骨格は5分セットアップから。
6. FAQ
DMは可、グループは不可？
まずrequireMentionと部屋単位の上書き。同一文を@Botあり/なしで送り比べ。@ありで直るなら運用ドキュメントへ明記するか、内部チャンネルだけ例外化（セキュリティレビュー後）を検討。
pairing空でも無音？
channels status --probeに戻り、Botのスコープ行列とopenclaw logsのpolicy行を確認。ステージング用ワークスペースのトークンを本番ゲートウェイに載せていないか、多職場環境で取り違えがよくあります。
heartbeatとの違い？
heartbeatやthinkingはCron・空出力・スケジュール寄り。群のみ・mentionと強く相関するならチャネル側を優先。DMも含め全チャネル沈黙ならheartbeat記事を並行で開く。
Discord intent済みでギルド不可？
チャンネル閲覧・履歴読取、プライベートチャンネルのロール付与。開発者ポータル保存後は数分待ってから再テスト。キャッシュのせいで「直したのにダメ」に見えることがあります。
Slackオンラインだが発火しない？
イベントリクエストURL、再認可完了、ワークスペースごとのインストール漏れ。Slack側の配信ログとゲートウェイaccessログを秒単位で突き合わせ、404や署名エラーを先に潰す。