OpenClaw はユーザーに一つの一貫したエージェントに見えるが、ゲートウェイは実際には 複数のチャット API を扱い、それぞれ再試行セマンティクスが異なる。2026 年、「モデルが壊れた」ように見えるインシデントの多くは 二重配信された Webhook か、主チャネル障害に対するリハーサル済みの副経路がないことに起因する。本マトリクスは Slack・Telegram・Discord のフェイルオーバーを順位付けし、冪等性キーを定義し、NodeMac の 専用 Mac mini M4 ホスト向けに 8 つの再現可能なステップを示す（SSH 自動化、一度きりの権限は VNC、HK・JP・KR・SG・US のリージョン）。
ベースライン統合：Slack と Discord の Webhook、マルチモデル フェイルオーバーとタイムアウト、状態ディレクトリとヘッドレス ゲートウェイ チェックリスト。ヘルス：レディネス プローブ；診断：doctor。料金：料金；ヘルプ：ヘルプ。
実際にデバッグしている故障モード
ゲートウェイが遅い HTTP 応答を返すとチャットプロバイダは積極的に再試行する。ツールの副作用（チケット、デプロイ、返金）が冪等でないと、再試行は重複インシデントになる。別途、Socket Mode やロングポーリングはノート PC のスリープ、Wi‑Fi 変更、企業 TLS ミドルボックスで切断する——固定のクラウド Mac と安定したエグレスでは症状が消える。
- 少なくとも一度配信 が既定の前提——それ向けに設計する。
- 人間エスカレーション は重複排除ストアが利用不能なとき自動化をバイパスすべき。
- 同一返信のクロスポスト は 2 つの主チャネルに同じエージェント返信を送ると監査トレイルを混乱させる。
チャネル層マトリクス
| チャネル | 2026 年の最適役割 | フェイルオーバー時の注意 |
|---|---|---|
| Slack | エンタープライズ向け主チャネル；リッチなスレッド | Socket Mode トークンは文書化されたカレンダーでローテーション |
| Telegram | 高速な個人ボット；良い副ブロードキャスト | グループのプライバシーモードがメンション意味を変える——実グループでテスト |
| Discord | コミュニティ向けエージェント；Webhook ファンイン | ギルドごとにレート制限が異なる；アラートを別々にシャード |
冪等性とリプレイ マトリクス
| 受信パターン | 重複排除キーのレシピ | TTL の目安 |
|---|---|---|
| Slack Events API | event_id + team_id のハッシュ |
最低 24 時間 |
| Telegram updates | ボットごとの update_id |
長時間オフラインメンテが可能なら 48 時間 |
| Discord interactions | インタラクション ペイロードの id + ギルド id |
より長い再試行をプロキシしない限り 12 時間 |
ストレージのヒント：重複排除状態は OpenClaw 状態ディレクトリと同じ非同期ボリュームに置き、launchd 下で SQLite やファイルロックの挙動を一貫させる。
8 ステップのロールアウト
- 層を宣言：所有者付きの 1 ページのアーキテクチャ メモに。
- 重複排除ストアを実装：ヒット率と追い出しのメトリクス付き。
- リプレイ テスト：ステージングで保存したペイロードをチャネルごとに 2 回。
- サーキット ブレーカーを追加：副チャネルもエラーなら人間へ fail closed。
- 相関 ID をログ：ゲートウェイ、ツール呼び出し、外向きチャット返信をまたぐ。
- トークン ローテーションを自動化：Slack Socket Mode は四半期ごとにドリル。
- DNS ブロック ゲームデイ：主プロバイダ API に対して。
- フリーズ スイッチを文書化：設定を削除せずツール実行を止める。
よくある質問
Slack と Discord を両方とも主にすべきか？
いいえ——自動ツール実行には主を 1 つ；他方は通知または劣化モードに。
良い重複排除キーとは？
安定したプロバイダ識別子にワークスペースまたはギルド スコープを加え、ハッシュし、再試行ウィンドウを超える TTL で保存。
専用 NodeMac Mac の理由は？
長寿命接続の稼働時間、予測可能なパス、ユーザーと API に近いリージョン配置。