2026 OpenClaw Slack / Discord Webhook：Macクラウド常駐デーモン再現手順

初回5ステップのあと、多くのチームがSlack/Discord通知を欲しがりますが、WebhookとBotの取り違え、ノートスリープでブリッジ停止、重複メッセージで詰まります。本稿は2026年版としてWebhook/Slack App/Discord Botの判断表、envファイル・curlスモーク・launchd常駐を含む5ステップ以上を整理し、本番ハードニングとエラー切り分けと相互参照します。ゲートウェイポート18789と同列のインフラとしてIM出口を扱えます。

1. 認証モデル・プロセス寿命・メッセージ嵐の三痛点

IM連携はURL貼り付け以上の話です。第一に認証の深さの誤り：Slack Incoming Webhookは固定チャンネル投稿のみ、BotはOAuthスコープ不足で403ループ。第二にGUIセッションに縛られた寿命：ノートでnpm startはスリープやWi‑Fi瞬断で死に、ホスト要因をOpenClawの不安定と誤認します。第三にスロットリングなき嵐：ツール呼び出しのたびにIMへ投稿すると数秒でチャンネルが埋まり、運用は連携オフにします。

Webhook URLをリポジトリに入れない：ベアラトークン同様、SSH秘密、mode 600のenv、オーケストレータsecretsで注入。
外向き通信をゲートウェイ方針に揃える：ゲートウェイはファイアウォール記事どおり127.0.0.1:18789が多く、IMは443。厳格な出口ならSlack/Discordホスト名を明示許可。
Docker/npm/ソース切替でenvパスを同期：比較記事の方式を変えたらログとenvを揃えないと「ローカルだけ届く」が起きます。

次表を設計レビューで使い、Webhookで足りるのにBotを盛らないようにします。

2. Webhook vs Slack App vs Discord Bot

Slackは細かいBotトークンとイベントAPI、Discordは一方通行通知にWebhook、双方向はBot+Gateway。OpenClawの夜間サマリやビルド通知はWebhookで止めることが多く、会話型@agentはBotが必要です。

選択肢	できること	複雑さ	秘密の形	OpenClaw用途例
Slack Incoming Webhook	固定チャンネル投稿	低	長いHTTPS URL	アラート、サマリ、ジョブ完了
Slack App + Bot	イベント、ボタン、スレ	中高	Bot token + signing secret	対話型運用Bot
Discord Webhook	一方通行embed	低	Webhook URL	コミュニティ/開発チャンネル
Discord Bot	メッセージ、コマンド、Gateway	高	Bot token	会話トリガ

本番ハードニング済みなら、IMクレデンシャルとゲートウェイトークンは別ローテで、一漏洩両面失守を避けます。

3. 再現手順：Slack、Discord、launchd、検証

OpenClawがSSH付きMacクラウド上の非対話ユーザーで動いている前提。順序を守るとロールバックが楽です。

最小権限で統合を作る：Slack Incoming WebhookまたはDiscordチャンネルWebhook。所有者とローテ日を秘密管理に記録。
ノードに制限付きenv：例 /usr/local/etc/openclaw/im.env chmod 600、SLACK_WEBHOOK_URLまたはDISCORD_WEBHOOK_URLのみ。
OpenClaw設定から環境変数参照：gitにURL直書き禁止。Dockerは--env-fileまたはsecrets。
curlスモーク：エージェント配線前にサーバから最小JSONをPOSTし、HTTPとチャンネル到達を確認。
launchd plist等：RunAtLoad、KeepAlive、ThrottleInterval。stdout/stderrを/var/log/openclaw/im-bridge.logのようにローテ。
レート制限と要約：30秒以内の同一トピックはマージ、ERRORのみ等。

# Slack Incoming Webhook スモーク（URLはコミット禁止）
curl -X POST -H 'Content-type: application/json' \
  --data '{"text":"OpenClaw: smoke test from mac-cloud node"}' \
  "$SLACK_WEBHOOK_URL"

# Discord Webhook スモーク
curl -X POST -H 'Content-type: application/json' \
  --data '{"content":"OpenClaw: smoke test from mac-cloud node"}' \
  "$DISCORD_WEBHOOK_URL"

                ヒント：ユーザ領域とシステム領域のlaunchdは挙動が異なり、CI用SSHユーザーとGUIログインユーザーを混ぜると「SSHではあるが再起動後に消える」環境変数が起きます。
            

4. 引用できるパラメータ

Runbook向け：①Slack webhookはHTTPS POST JSON、textやBlock Kit—失敗時は本文をログ。②Discordは429でバックオフ。③ゲートウェイがループバックのままなら将来のIMコールバックは18789公開方針に沿ったリバプロ/トンネルが必要。④送信成功/失敗カウンタや構造化ログをトラブルシュートと突き合わせ。

5. IMブリッジを専用Macクラウドに置く理由

共有ノートだけにブリッジを置くとスリープ穴、セッション共有の監査弱さ、ゲートウェイOOMで通知も同時停止の相関失敗が出ます。SSH管理のMacクラウドで明示的再起動方針に載せると「チャット配信」と「エージェント計算」の劣化を分離できます。

OpenClaw+IM出口にVPSMACのM4 Macクラウドをレンタルする方が、個人端末依存より予測しやすいことが多いです。電源と回線はプラットフォーム、launchdとログローテはLinux運用に近い。基線は5分セットアップ記事、その後に本稿でSlack/Discordを。

6. FAQ

Slackが重複する

ハンドラ重複や2xx無視のリトライ、同一チャンネルへのWebhook多重を確認。

WebhookなしBotのみ？

可能だがコスト高。一方通行はWebhook、対話が要るならBot。

WeComとの違いは

企業微信は別API・コンプラ経路。本稿はSlack/DiscordのHTTPS Webhookが対象。