2026年 OpenClaw × 企業 Slack：Socket Mode 長寿命接続と HTTPS Webhook をインターネット側からのインバウンドなしで比較選定——社内 HTTPS プロキシ、断線・再接続とリモート物理 Mac ゲートウェイの再現 Runbook（設定断片＋FAQ）

1. 企業で実際に踏む痛点

1. 安定したインターネット側インバウンドが無い：NAT／CGNAT／社内規程でノート PC へのポート開放が禁止され、HTTPS Events に進んでも「恒久 DNS と証明書ライフサイクルを誰が持つか」で詰まる。
2. TLS 検査と署名のズレ：ミドルボックスが再署名し、HMAC 検証がユーザーごとにだけ失敗する。パケットキャプチャ無しの口頭デバッグでは日数が溶ける。
3. アイドル切断と Slack 再試行：300〜900 秒で静かなトンネルを閉じるプロキシが多く、キープアライブ無しだとセッションが落ちる。イベントループを塞ぐハンドラは再試行嵐を増幅する。
4. 監査責務の置き場：Socket Mode はアプリレベルトークンとセッション実体ホストに信頼が集約され、HTTPS は URL・証明書・WAF に分散する。同じボットでも紙面が異なる。

2. 意思決定表：Socket Mode vs HTTPS Events

セキュリティレビューに転送できるよう、OpenClaw を専用リモート Mac上で動かす前提の比較です。

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

1. 搬送とセキュリティで合意：Socket Mode のアプリトークンが SaaS 方針に収まるか確認。NG なら承認済み Ingress ブローカー経由の HTTPS Events を設計する。
2. ホストを固定：有線 Ethernet、MDM でホスト名固定、NTP 強制。プールまたはコロケーションの据え置き Mac を推奨。
3. ループバックにバインド：127.0.0.1:PORT で待ち受け、TLS は nginx／Envoy またはゼロトラストエージェント前段で終端する。
4. シークレットを GUI 無しで注入：SecretRef や launchd の環境変数を暗号化ストアから。シェル履歴に平文トークンを残さない。
5. 本番プロキシ経路で検証：エンドユーザと同じ PAC／プロファイル経由で openssl s_client と curl を実行する。
6. 再接続 SLO を文書化：Socket Mode はプロキシ断後の中央値再接続、HTTPS は署名検証＋キュー投入までの p95 レイテンシを定義する。
7. ゲームデイ：ローカル逆プロキシを kill し、Slack 起点のワークフローが文書化ウィンドウ内で自動回復するか確認する。

4. 設定断片（例示）

4.1 localhost 上流への nginx TLS フロント

server {
  listen 443 ssl;
  server_name slack-hooks.internal.example;
  ssl_certificate     /etc/ssl/internal/fullchain.pem;
  ssl_certificate_key /etc/ssl/internal/privkey.pem;

  location /slack/events {
    proxy_pass http://127.0.0.1:18789/slack/events;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_read_timeout 120s;
  }
}

4.2 launchd 向け環境変数の骨子

<key>EnvironmentVariables</key>
<dict>
  <key>SLACK_SIGNING_SECRET</key>
  <string>${SECRET_REF_SLACK_SIGNING}</string>
  <key>OPENCLAW_HTTP_BIND</key>
  <string>127.0.0.1:18789</string>
</dict>

キー名は利用中の OpenClaw リリースに合わせて置換してください。意図はループバック固定＋リポジトリ外シークレットです。

5. 設計メモに貼れる数値

• プロキシアイドル：多くのフォワードプロキシは静かな TLS を 300〜900 秒で切る。TCP キープアライブとアプリ ping を下限より短く設定する。
• HTTPS ハンドラ ACK：Slack Events のホットパスでは署名検証後すぐ非同期キューへ載せ、3 秒未満で 200 を返す計画にする。
• 合成プローブ：5 分おきのスラッシュコマンドまたはヘルスチャンネル ping で、一方向外向き障害をエグゼクティブより先に検知する。

6. FAQ

いつ Socket Mode を HTTPS Events より優先すべきですか？

インターネット公開 URL が現実的でないとき、検査で Webhook 署名が壊れるとき、ファイアウォール承認を「既知ホストからの外向き 443 一本」に集約したいときは Socket Mode が有利です。マネージド Ingress と LB 背後の水平展開が前提なら HTTPS を選びます。

社内逆プロキシで TLS 終端し、Mac を素のインターネットから隠せますか？

OpenClaw を 127.0.0.1 にバインドし、nginx／Envoy またはゼロトラストの前扉で終端する構成は一般的です。HTTPS モードでは Slack が到達できる URL が依然必要で、分割 DNS・トンネル・IT 管理 VIP などとセットで設計します。

営業時間帯だけ配信がフラつくのはなぜですか？

プロキシプールのローテーション、SSL セッション再ネゴシエーション、Wi-Fi 輻輳が典型です。Slack の再試行ヘッダとアクセスログを相関させ、Socket Mode はノートのスリープで落ちるため据え置き Mac が効きます。

運用に書く再接続バジェットの目安は？

Socket Mode は一過性切断後の中央値再接続を 30 秒未満、HTTPS は署名検証とエンキューを 3 秒以内に収めるのが現実的です。構造化ログと合成プローブで測定します。