2026年 OpenClaw 複数インバウンド実践：Discord Bot と WhatsApp を独占リモート Mac（SSH）で併用する際のセッション分離、身元紐付け、ゲートウェイのレート制限、ログイン／切断エラーの再現可能デプロイ＋FAQ
本稿は、独占リモート Mac上で OpenClaw に Discord Bot と WhatsApp の二系統インバウンドを同居させるときの設計メモです。セッション分離（会話状態の衝突を防ぐ）、身元紐付け（チャネル横断の主体を監査可能にする）、ゲートウェイのレート制限（429 とバックオフの協調）、ログイン／切断の症状を意図的に再現して runbook に落とす手順までを一枚にまとめます。SSH は管理面、公開 HTTP はループバック＋リバースプロキシに閉じる前提です。
TL;DR──インフラメモに貼る用
要点：二つのチャット面は、OpenClaw 側では別のインバウンド IDと名前空間付きセッションキーで常に分離します。Discord の guild_id / channel_id と WhatsApp の from / wa_id をそのままキーにすると、DM とグループの衝突や番号再割当で履歴が混線します。内部主体 ID（社員番号・顧客 UUID 等）への写像表を単一ソースにし、ゲートウェイは 127.0.0.1 束縛＋チャネル別トークンバケットで外向き API を守ります。
- セッション分離：プレフィックス
discord:とwa:をメモリ／ディスクのキーに強制。共有スキルでも会話スコープは分ける。 - 身元紐付け：外部 ID→内部主体の対応を append-only ログと監査ビューで追えるようにする。
- レート制限：プロバイダ別にキュー深さと同時実行上限を分ける。429 は
Retry-Afterを第一級で扱う。 - 再現ドリル：意図的にトークン失効・プロキシ切断・二重コンシューマを起こし、期待ログ行を固定する。
ゲートウェイ承認フローやノード既定ポリシーとの整合は、2026年 OpenClaw ノードペアリング（Node Pairing）新ルール後：`node` 既定ブロック、承認フローと独占リモート Mac ゲートウェイの SSH 再現対照表＋FAQ と突き合わせてください。マルチチャネル運用の土台は 2026年版 OpenClaw 安全デプロイ：Mac mini と SSH で構築する iMessage/Slack 自動化 PR 運用アーキテクチャ のパターン（秘密の境界・PR ゲート）を流用できます。
1. 単一ホスト上の「二重インバウンド」の責務分割
独占リモート Macはシングルテナントなので、CPU 争いよりも状態の争いが障害の主因になります。Discord は低遅延のイベント駆動、WhatsApp はセッション維持と再送の挙動がプロバイダ実装に依存します。OpenClaw ゲートウェイは一つの HTTP 面に集約しつつ、背後のブリッジプロセスはチャネルごとに OS ユーザまたは launchd ジョブ境界で分けるのが安全です。
設計上のゴールは、(a) どちらか一方がハングしても他方を殺さない、(b) ログに相手チャネルの秘密が混ざらない、(c) アップグレードを片系からローリングできる、の三つです。
2. セッション分離──キー設計とストレージ
| 観点 | アンチパターン | 推奨 |
|---|---|---|
| 会話キー | ユーザー表示名のみでハッシュ | provider:tenant:opaque_thread_id の三段 |
| ツール副作用 | 共有ワーキングディレクトリ | チャネル別サンドボックスディレクトリ＋クォータ |
| ワーカー | 単一プロセスで二ブリッジを無限ループ | async タスクでもキューは物理分割し、障害伝播を遮断 |
LanceDB やファイルキャッシュを併用する場合は、単一ライター規律をチャネル単位で繰り返し適用します。ディレクトリロックの取り合いが出たら、まずキーのプレフィックス衝突を疑ってください。
3. 身元紐付け──外部 ID と内部主体
Discord の user.id（snowflake）と WhatsApp の送信元は別名空間です。社内の「誰がどの会話にいるか」を一貫させるには、内部主体 UUIDを正とし、外部 ID は属性としてぶら下げるモデルが監査に強いです。
- 初回ハンドシェイクで
/verifyコマンドやワンタイムコードを使い、外部 ID を内部主体に手動または IdP 連携で結びつける。 - 写像テーブルは append-only。失効は「上書き」ではなく失効フラグ＋理由コード。
- ログには内部 UUID のみを出し、Discord／WhatsApp の生 ID はマスクか別ストア。
4. ゲートウェイのレート制限とバックオフ
二チャネル合算でモデル API やツール HTTP に突き抜けると、どちらのユーザー体験も同時に劣化します。ゲートウェイ層で チャネル別トークンバケットと グローバル上限の二段を切ると、片系のバーストが他方を飢餓状態にしにくくなります。
- 429 応答は
Retry-Afterをキューに伝播し、同じスレッドの後続メッセージを同じクールダウンに乗せる。 - Discord のインタラクション応答期限と、WhatsApp のセッション再開タイムアウトを別タイマーで管理する。
- スパイク検知時は「全体停止」ではなくフェイルクローズした優先度キュー（例：インシデント用チャネルのみ残す）。
5. ログイン／切断エラーの再現デプロイ
以下は SSH セッションから安全に再現できるドリル例です。本番トークンではなくステージング用アプリ／ボットで実施してください。
- 意図的 401：ゲートウェイ用 API キーを 1 文字だけ壊して再起動。期待：両チャネルのブリッジがフェイルクローズし、構造化ログに
auth_failureが 1 行。 - 意図的切断：
pfctlまたはローカルファイアウォールで外向き 443 を 30 秒ブロック。期待：再接続ジッターが設定通りか、片系だけ切断される設計ならもう一方が生存。 - 二重コンシューマ：ステージングで同一 Discord アプリトークンを二ホストに export。期待：衝突ログと重複イベントの検知（べき等キーでドロップ）。
- 502 エッジ：リバプロの上流を落とし、クライアント側再試行とサーバ側重複排除の両方を確認。
各ドリル後は launchctl kickstart -k 相当の単一ジョブグラフに戻し、launchctl print で重複プロセスが残っていないことを確認します。
6. SSH 前提のチェックリスト（貼り付け用）
- サービスユーザを分離し、Discord と WhatsApp の資格情報ファイルを
0400で分割。 - ゲートウェイは
127.0.0.1のみリッスン。TLS は nginx／Caddy／トンネルで終端。 - 環境変数に生トークンを置かない。キーチェーンまたは
securityラップで LaunchAgent に注入。 - 構造化ログに
inbound、internal_subject、trace_idを必須フィールド化。 - 429／5xx／切断カウンタをメトリクス化し、SSH 越しのダッシュボードに載せる。
FAQ
Discord と WhatsApp で OpenClaw を二重に起動してよい？
同一ホストでもプロセスは分離し、状態ストアのキー空間を絶対に共有しない構成を推奨します。単一プロセスマルチブリッジは実装コストが下がりますが、障害半径が広がります。
WhatsApp 側の番号変更で会話が混線した
外部 ID を正にしていたのが原因です。内部主体 UUIDを正にし、番号は属性として履歴を追跡してください。
429 が片方のチャネルからしか来ないのに全体が遅い
ゲートウェイのグローバルセマフォが共有されています。チャネル別キューに分割し、モデル呼び出しの同時実行上限もチャネル別に割り当て直してください。
SSH セッションが切れるとブリッジも死ぬ
対話シェル上でブリッジを起動していませんか。launchd 常駐に移し、SSH はメンテナンス専用に限定してください。
この負荷パターンに Mac mini と macOS が向く理由
Discord と WhatsApp の二系統は、ピーク時は軽くても常時ソケットとタイマーが残り続けるワークロードです。Apple Silicon の Mac miniはシングルスレッド性能が高く、複数ブリッジとゲートウェイを同一筐体に載せても応答性の尾部が読みやすいです。待機電力は数ワット程度に抑えやすく、コロケーションや自宅ラボの電気代試算にも向きます。
macOS は launchd による監督、APFS スナップショットでのロールバック、Gatekeeper・SIP・FileVault による多層防御を一体で提供します。チャット資格情報は実質ネットワーク上の鍵に等しいため、一般的なユーティリティ向け Windows ホストより脅威面を小さく保ちやすいです。
第 6 節のチェックリストをそのままメタルに載せ替えるなら、2026 年時点でも Mac mini M4 は価格対性能の基準点のままです。ループバックだけでゲートウェイを立て、外向きはトンネルに任せ、メトリクスでレート制限の余裕を見ていくのが現実的です。
今すぐ Mac mini を手に入れ、第 5 節のドリルをステージングで一度ずつ通し、本番の当番手順に落とし込んでください。