2026年 OpenClaw 入向チャンネル運用実戦：Slack／Discord ダイレクトメッセージのペアリング（pairing）とグループ方針（groupPolicy）をリモート物理 Mac で再現する Runbook——無応答、期限切れペアリング、会話別モデル上書きの切り分け（openclaw.json 断片＋FAQ）

2. よくある失敗（「何も起きない」理由）

1. 配信成功を「エージェントが解釈した証拠」にする。 ベンダーは Webhook を受け 200 を返しても、署名誤りや重複エンドポイントでは自アプリに届いていない可能性があります。検証可能な HMAC 等と一つのアクティブなアプリ URL が必要です。
2. DM を、ペアリングなしに許可済みと勘違いする。 ペアリングは user id と社内方針上の主体を紐づけます。期限切れ、未完了、再インストールでボットメンバーシップが壊れていると、ゲートウェイが黙否するのは正しい動きです。
3. groupPolicy とモデル表を切り離して考える。 チャンネルは雑談可でも、より厳しいモデル方針で安価プロファイルに落ちていると、運用者は「違うモデル」症状だけを見ます。明確な優先度と id 別上書き表を一緒に設計してください。外向きツール境界は、リードで触れた Gateway 外向き通信ガバナンスのドメイン許可／Sandbox とも整合を取ると、説明責任が一続きになります。

3. 意思決定表：Slack と Discord の表面

同一 リモート物理 Mac 上のゲートウェイに、既定方針を揃えるときの軽量マトリクスです。

4. openclaw.json 断片（例示）

構造例に過ぎません。キー名は自組織の OpenClaw ビルドに従い、本番は SecretRef／環境間接、既存の gateway ブロックと手作業マージ、適用前必ずバックアップを。

4.1 Slack：署名＋DM ペアリング＋ groupPolicy

{
  "channels": {
    "slack": {
      "enabled": true,
      "appIdRef": "env:SLACK_APP_ID",
      "clientIdRef": "env:SLACK_CLIENT_ID",
      "clientSecretRef": "env:SLACK_CLIENT_SECRET",
      "botTokenRef": "env:SLACK_BOT_TOKEN",
      "signingSecretRef": "env:SLACK_SIGNING_SECRET",
      "inbound": {
        "urlPath": "/openclaw/slack/events",
        "verifyRequestSigning": true
      },
      "dmPairing": {
        "mode": "inline-code",
        "codeTtlMinutes": 15,
        "requireNewPairingOnWorkspaceReinstall": true
      },
      "groupPolicy": {
        "default": "deny",
        "allowChannelIds": ["C0123456789"],
        "allowThreadOnlyChannelIds": []
      },
      "modelByConversation": {
        "C0123456789": "anthropic:claude-3-5-sonnet",
        "DMBIND:U0ABCDEF": "openai:gpt-4.1-mini"
      }
    }
  }
}

4.2 Discord：ボットトークン＋インテント＋許可リスト

{
  "channels": {
    "discord": {
      "enabled": true,
      "botTokenRef": "env:DISCORD_BOT_TOKEN",
      "applicationIdRef": "env:DISCORD_APP_ID",
      "gateway": {
        "intents": ["GUILDS", "GUILD_MESSAGES", "DIRECT_MESSAGES", "MESSAGE_CONTENT"]
      },
      "groupPolicy": {
        "default": "deny",
        "allowGuildIds": ["9876543210"],
        "allowChannelIds": ["111122223333444455"]
      },
      "dmPairing": {
        "mode": "dm-code",
        "codeTtlMinutes": 15
      }
    }
  }
}

codeTtlMinutesはユーザー向け表示と揃えてください。期限切れの問い合わせが多いなら、真っ先に TTL 延長ではなく手順文と NTP です。modelByConversationのキーは、ビルドの正規化済み会話 id（チャンネル・DM・スレッド）に合わせ、同じ id を表記揺れで重複定義しないでください。会話上書きではなくルータ層の多段フォールバックを使う場合は、多モデル fail-over 記事と衝突しないよう階層を揃えます。

5. 七ステップ Runbook（リモート物理 Mac）

1. 設定凍結とスナップショット。 cp openclaw.json openclaw.json.bak.$(date +%Y%m%d%H%M)。OpenClaw のビルド id とチャットアプリの app id をチケットに残す。
2. 公開 INGRESS の実在性。 インターネットからベンダーの challenge URL へ。リバプロが、ゲートウェイが束ねる 127.0.0.1:18789 等のループバックに届くことを確認。
3. 署名と秘密の突合。 Slack：リクエスト署名。Discord：インテント＋bot 認可。一つ違うと表向きは完全沈黙に見えます。
4. DM ペアリングの完遂またはやり直し。 新しいコードを発行。ペアストアがローカルなら掃除前にバインド用バックアップ。info ログ等でマッピングを確認。
5. groupPolicy を引き締めて拒否→許可の順で試す。 新規導入は default: deny から。既知のチャンネル id 一つずつ足して負例→正例を見る。
6. モデル上書きの優先度を検証。 同じ文面を DM とチャンネルに送り、想定どおり別の上流プロファイルに流れるか。違うならモデル名ではなくキー（解決後の会話 id）の誤りのことが多いです。
7. メトリクス＋監査への引き継ぎ。 許可リスト、ペアリング TTL、リバプロの vhost を版管理下に。当番がスクショから id を再推論しなくて済む形に。インジェスト可観測性の実装は導入部の Cron／JSONL 記事の手順と併せて文書化してください。

6. 切り分け：沈黙／期限切れ／誤モデル

7. 引用用の数値とチェック項目

• ペアリング code TTL（例）： 断片では 15 分。SLO に合わせて調整し、必ず OpenClaw バージョン号の横に変更理由を残す。
• groupPolicy の default deny： ツール実行型ボットの 2026 年ベースラインとして default: "deny"。許可リストは小さなバッチで拡大。
• ループバック待受： ゲートウェイを 127.0.0.1 に束ね TLS はエッジで終端する構成は、ZoneMac 流の SSH ＋リバプロと相性が良く、ホスト横展開面を減らせます。

8. FAQ

9. まとめと Mac mini・macOS の位置づけ

Slack／Discord 入向を「初回から破綻させない」コツは、製品名より退屈な順序です。署名の検証、DM バインドの再現性、ツールを広げる前のgroupPolicy 引き締め。そのための 24h 常駐ホストに ZoneMac リモート物理 Mac、特に Mac mini M4 クラスは乗りやすいです。Apple Silicon の待機電力は数ワット級、Unix ネイティブのシェル・openssh・Homebrew・launchd との相性、そして多くの商用 PC 向け OS より低いクラッシュ率が、無人の Webhook／ペア屋敷に効きます。

macOS は Gatekeeper、SIP、FileVault を一続きのストーリーで揃えられる点が、長期公開の署名シークレット集約ホスト向けの安心材料です。3 時に起きるのは仮想マシンの不調より、多くの場合、許可 id とペアログの不整合の方でしょう。

OpenClaw、リバプロ、本 Runbook の可観測性を静かで予測可能な金属の上に載せたいなら、Mac mini M4はコストと安定性のバランスの良い出発点です。ZoneMac で専用ノードを確保し、Slack／Discord 入向を本番相当の挙動で通してからツール枠を広げてみてください。