最小権限 · channels status とプローブ · コールバックと WebSocket · 無言時の順序
すでに OpenClaw Gateway をローカルで動かしつつ、Slack・Discord・Telegram で安定配信しなければならないチームが失敗する主因は「モデルが弱い」ことではありません。プラットフォームのスコープ、イベント購読、Webhook コールバックの到達性、リバースプロキシ背後の WebSocket アップグレードが揃っていないと、チャネルはオンラインに見えるのにメッセージが消えるという偽の正常値になります。本稿は3 プラットフォームの最小権限と管理者作業のマトリクス、公式診断からプローブまでの段階的判定、代表的な 4xx/5xx に対する TLS と HTTP の症状表、そして無言時の順序（スレッド文脈→レート制限→ツール失敗→モデル枠）を再現可能な Runbook に束ねます。本番強化、ランタイム障害、インストールと doctor へ相互リンクし、原因をモデル盲信ではなくチャネル層に留めます。
多くのチームはテストメッセージ 1 件をもって本番合格とみなし、未完了のイベント購読、Bot トークン更新、プロキシ背後で Upgrade を失うコールバック URL、スレッド文脈を伴うチャネル単位のレート制限を見落とします。モデルを責める前に 三段切り分け と証拠の鎖を揃えないと、意味のないリトライだけが増えます。以下五つは 2026 年に最も戻し作業が出る要因です。レビュー表に落としてください。
権限ギャップ：Slack で chat:write がない、message.channels を購読していない、Discord で Message Content Intent がない、Telegram のコマンドや webhook secret が不一致—受信はあるが返信が途切れる症状。
コールバック経路：公開 Ingress、証明書チェーン、HSTS、プロキシタイムアウトが重なり、プラットフォームは Gateway を未到達とみなす一方でステータスだけが一瞬オンラインに見える。
リバプロ WebSocket：Upgrade と Connection を転送しない HTTP だけでは握手は成功しても、Discord や一部 Slack 経路でメッセージがずれる。
スレッド文脈：Slack スレッドで起きたイベントを本チャで待つ、Telegram の update offset を確定させず重複処理で自己ロック。
観測の混線：チャネルリトライ・ツール失敗・429 を同一アラートに詰め込み広域再起動に走る。許可リストと監査表 が求める最小フィールドと衝突します。
五つの行をオーナー（プラットフォーム管理者／インフラ／OpenClaw 設定）に割り当てれば議論は半日からおよそ 1 時間に縮みます。まだ詰まる場合は次節の権限表の前に インストールと doctor でランタイムとバージョンを固定してください。
表はベンダー文書の写経ではなく、チェックできるレビュー表です。空欄は本番トラフィックで断続的な無言に膨らみます。スコープ名は各コンソールに従い、順序は固定で「身元と権限→イベント購読→コールバック URL」です。
| プラットフォーム | 最低限の Bot 能力 | 管理者が必ず行う作業 |
|---|---|---|
| Slack | チャネル読み書き、アプリレベルのトークン更新、対象チャネル種別を覆うイベント購読。Socket Mode ならトンネルも別レビュー | ワークスペースへインストール、チャネル承認、イベント URL を到達可能な HTTPS に、監査ログで購読変更を確認 |
| Discord | 必要時のみメンバー読取、Message Content Intent、登録と整合したスラッシュ／アプリコマンド | 開発者ポータルでインテント有効化、Bot を招待して権限付与、Gateway インテントとシャード安定性を確認 |
| Telegram | BotFather トークン、Webhook と long polling は意図して選択、コマンド許可とプライバシーモード方針 | Webhook 設定、secret 保存、ファイアウォールでプラットフォーム出口 IP を許可、変更ウィンドウを記録 |
チャネル障害の多くは権限・コールバック・購読のどれかに還元でき、モデルはその後です。
本番強化 を既に実施しているなら、本表を待受アドレス・リバプロ・TLS と同じ変更票で見て、チャネルだけ半端な展開を避けてください。
六歩は公式または互換 OpenClaw CLI を想定します。サブコマンドは変わり得ますが、判定順は入れ替えないでください。プロセスと設定が読めること、チャネル登録、外向きプローブ、その後にモデルルーティング。ランタイム障害 と組み合わせ、各ステップのコンソール出力を同じチケットに添付します。
Gateway 設定をディスク上で確認：パス、環境変数注入、ファイル権限。シェルでは動くがデーモンが読めない状態を防ぐ。
チャネル列挙：ベンダーの一覧または status で三つの IM が重複なく登録されているか。
ヘルスを分離：プロセス生存・ポート・外部コールバック到達を一つの真偽値に畳まない。
プローブ：公開 Ingress に対する TLS と HTTP 意味論、ステータスと遅延。ローカルバイアスを外すため外部 VPS から再測定。
送受信と確認：最小の入出力メッセージ、イベント ID または update id の単調性。
監査フィールド：チャネル ID、リトライ回数、最終エラーコードをログに残し、モデル側 request_id と接続。
# 例：列挙してからプローブ（CLI は環境に合わせる）
openclaw channels status --json
openclaw channels probe slack --timeout 15s
openclaw channels probe discord --timeout 15s
curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://your-public-host/openclaw/callback
ヒント：probe が通っても本番が失敗するなら、モデル温度より先にイベント購読とチャネル権限を確認します。
本節は「プラットフォームが Ingress を正当なバックエンドとみなせるか」だけを扱います。ここが失敗すればモデルの強さは無関係です。HTTP コードと TLS 症状を 強化チェックリスト の TLS 確認と同じ変更記録に紐づけます。
| 症状 | 有力な原因 | 対処 |
|---|---|---|
| 401/403 | 署名検証失敗、時刻ずれ、プロキシでヘッダ欠落 | NTP 合わせ、必須ヘッダ復元、秘密鍵ローテ後に E2E 再試験 |
| 404/405 | パス未マウントまたは HTTP メソッド不一致 | Ingress と Gateway ルートを照合しヒットパスをログ |
| 502/504 | 上流タイムアウト、プール枯渇、cold start | プロキシタイムアウト引き上げ、Gateway 最小レプリカ、ヘルスドレイン |
| 握手は成功だがメッセージがずれる | WebSocket が遮断、HTTP/2 と WS パスが衝突 | WS 専用 location、Upgrade と Connection を明示転送 |
先に TLS：外部スキャンと透明性ログで SAN とチェーン—ブラウザは通るがコールバックは落ちるパターンを潰す。
次にパス：コールバック URL でべき等な GET/POST、レスポンスがベンダーのリトライ意味と一致するか。
最後に WebSocket：長寿命や Socket Mode では企業 FW と外向きプロキシの切り詰めを疑う。
注意：Discord のインテントや権限欠落は読めるが書けない断続症状を作り、モデル再起動では直りません。
以下三つは Agent と IM 運用でよく使う経験レンジです。計画レビュー向けであり性能保証ではありません。数値はログと請求で置き換え、README に貼って無意味な再起動を減らしてください。
channel_id のバックオフが 5 分以内にベンダー上限の半分を超えるなら読み取り専用にサーキットブレークし人へエスカレーション。| チーム規模 | チャネル形態 | 安定化の第一選択 |
|---|---|---|
| ≤5 名 | 単一ワークスペースまたはグループ | 固定コールバックドメイン、単一プロキシ、権限表と当番 Runbook |
| 6〜20 名 | 複数チャネルと自動化 | チャネル別レート予算、スレッド方針、読み取り専用劣化 |
| 20 名超 | マルチテナントと監査 | 監査フィールド必須、トークン更新、不変の変更記録 |
| 高コンプライアンス | データ所在地が敏感 | リージョン分離、egress 許可リスト、責任者付きログ保持 |
個人ノート PC はスリープや OS 更新、キーチェーン隔離で偽陽性を量産します。チャネル権限が一度合っても土台が不安定だとコールバックとヘルスが歪みます。対照的に、契約可能なクラウド Mac 常駐ノードなら Gateway・ハートビート・SLA を検証可能な条件に固定できます。
よくある誤り：コールバックとインテントを直す前にモデル遅延だけ最適化する。多くのチケットはチャネル整合が取れてから初めてモデル段階の話になる。
複数 IM チャネルで OpenClaw を監査可能・ロールバック可能・SLA と整合させたい一方、ローカル開発機では 24/7 と安定した公開 Ingress を満たせない場合、VpsMesh の Mac Mini クラウドレンタルの方が適することが多いです。リージョン選択、専用ノード、実際にオンラインを維持するホストへコールバックとヘルスを結べるため、「オンライン表示」と「メッセージが流れる」が一致します。