すでに Gateway を運用しているチームがつまずくのは、Slack、Discord、Telegram を「インストールできない」ことではありません。管理画面ではチャネルが接続済みなのに、チャットはブラックホールのように感じる。メッセージが届かない、あるいは一方向だけ流れるという点です。本稿はインストール後の doctor 切り分け、Docker ネットワークの切り分け、プロバイダフェイルオーバーと組み合わせます。まず Gateway とモデル層の健全性を確認し、そのうえで各プラットフォームの OAuth スコープ、ボット権限、イベント購読、Telegram のプライバシーモードを順に確認します。オンコール向けの症状タグ六類型、三層の切り分けマトリクス、コピーして使える診断ブロック、六ステップの手順書、Grafana に載せる価値のあるチャネル KPI 三つをまとめます。
チャネルの不具合は、「モデルが壊れた」「compose のネットワークのせいだ」と誤分類されがちです。イメージや network_mode を変える前に、下記のラベルで挙動を分類し、Docker ネットワークの切り分け表と突き合わせてください。並行して二系統をいじると、根本原因の追跡ができなくなります。
.env マウントが揃っていない、といったパターンです。この六類型を、最近の allowedOrigins の変更やイメージのロールアウトと同じ変更チケットに記録しておくと、オンコールは五分以内に分岐を選べます。
このマトリクスは「どの層を最初に調べるか」を決めるためのものであり、排他的な診断ではありません。各行は具体的な次のコマンドかログのキーワードに対応させます。紙に三列を描き、ユーザーに見える症状、Gateway ログで最初に現れる異常、上流モデルの HTTP ステータスを書き分けます。中央の列が空のままなら、プロバイダを触る前に立ち止まります。右列に 429 が先に並ぶなら、OAuth を十回やり直しても課金は直りません。
Docker ネットワークの記事と合わせると、コンテナ内でのチャネルプローブ失敗は第 0 層です。同じ compose ネットワーク上で CLI が Gateway に届くことを確認してからこの表を使います。そうでないと、Slack の webhook コンソールは常に健全に見え、ホスト側だけがタイムアウトし続けます。
| 観測したこと | まず疑う層 | 次の一手（要約） |
|---|---|---|
| ヘルスチェックは緑だが、インバウンドログがゼロ | チャネル入口 | 各プラットフォームを再認可。イベント購読 URL、Socket Mode、Intent、Telegram のプライバシーとメンションを確認 |
| インバウンドはあるが、ルーティングが空のエージェントやポリシー拒否を示す | ルーティングとポリシー | groupPolicy、チャネル紐付け、メンション規則を確認。OpenClaw のエージェント対応付けを揃える |
| インバウンドとルーティングは問題ないが、返信が失敗 | モデルとクォータ | 429、5xx、タイムアウトを確認。プロバイダフェイルオーバーの記事に従いキーやモデルを切り替える |
| コンテナでは失敗するが、ホストの CLI は動く | ネットワークとシークレットのマウント | Docker ネットワークの切り分けに戻り、compose の環境変数とボリュームを確認 |
これらの指標は「ボットが固まった気がする」をアラート可能な数値に変えます。フィールド名は Gateway のログと揃えます。時間単位のバケットを優先し、秒単位のノイズは避けて、夜間のページを意味のあるものにします。
2026 年のコミュニティドキュメントでも openclaw channels status --probe が強調されます。プローブ結果をこの三率と同じグラフに載せ、「再接続して祈る」再現不能な修正を避けます。Gateway のヘルスチェック記事で HTTP プローブを既に設定している場合、プローブ URL が実チャネルコールバックと同じリバースプロキシ経路に従うことを確認してください。ループバックだけを見るプローブと、公開コールバックが別の証明書チェーンを通ると、「監視はすべて緑、ユーザーはすべて赤」になります。
手動での突き合わせ習慣を足します。毎週ユーザー メッセージを十件サンプリングし、プラットフォームのメッセージ ID、Gateway のリクエスト ID、モデルのトレース ID がログ全体に現れるか確認します。リンクが欠けるなら構造化ログが壊れています。スケールの前にフィールドを直します。
# 診断の順序例（環境に応じて sudo / docker exec を前置） openclaw gateway status openclaw channels status --probe openclaw logs --follow | rg -i "slack|discord|telegram|429|oauth|deny" # Telegram：BotFather のプライバシーモードとグループでの @ メンション要件 # Discord：Developer Portal の特権 Intent（Message Content など）
注：三プラットフォームのインストールガイドで、同じマシン上に最小の対話が再現できていない場合は、チャネルと compose を並行して変えないでください。並行変更は根本原因を隠します。
allowedOrigins や TLS 証明書が変わった場合は、前の証明書フィンガープリントへ戻す手順を文書化し、OAuth コールバックと CORS が同時に壊れないようにします。gateway status が doctor 記事と一致することを確認します。systemd や launchd を使う場合は再起動ポリシーを確認します。短時間に何度も再起動すると、チャネルの WebSocket がプラットフォーム側のレート制限にかかります。各ベンダーのコンソールに対して実行します。古いスクリーンショットは信頼しないでください。ステージングと本番のワークスペースを両方持つ場合は、コールバックのホスト名を別列で管理し、ステージングの証明書が本番 DNS に誤って束ねられないようにします。
三プラットフォームとも安定した出口 IPを重視します。家庭用回線や出口ノードが変わる VPN は、悪意のある webhook トラフィックのように見えます。固定リージョンと監査可能な出口を説明するマルチリージョンのクラウド Mac のガイダンスと一致します。チームがボットに依存する前に、到達性を証明できるホストへ制御面を移してください。
スリープ、VPN、ローカルプロキシは出口 IP と TLS フィンガープリントを変えるため、OAuth コールバックとベンダーの許可リストがランダムに失敗します。共有ノートではトークンのローテーションと監査フィールドを中央集約できません。オンコール可能で出口が安定した実行面で Gateway とチャネルワーカーを動かすと、チームのエージェント方針と整合します。
常時稼働、固定コールバックドメイン、予測可能な出口が必要なトポロジーでは、MACCOME がシンガポール、日本、韓国、香港、米国東海岸、米国西海岸で Mac mini M4／M4 Pro のクラウドホストを提供しており、Gateway と Apple ツールチェーンの同居に向いています。チャネルの切り分けのあとはSSH と VNC のガイドとヘルプセンターを併読し、公開料金とリージョンページでレンタル期間を延ばしてください。
パイロットの型：本番ワークスペースを開く前に、専用のテストホストで単一チャネルに対し 24 時間 IER と RCR を計測します。大規模コミュニティを一気に有効にして即座に赤になる事態を避けます。
よくある質問
Docker ネットワークの切り分け記事とどう違いますか？
ネットワークは CLI から Gateway への到達性を扱います。本稿はメッセージプラットフォームの入口と認可です。compose を疑うなら、先にDocker ネットワークの切り分けを読んでください。
上流の OpenClaw FAQ も読むべきですか？
はい。トークンと Intent の一覧は上流ドキュメントと突き合わせます。併せて三プラットフォームのインストールガイドと、表現の確認のためヘルプセンターを開いてください。
クラウド Mac のリージョンとレンタル条件はどこで選びますか？
マルチリージョンのレンタルガイドとレンタル料金を読んでから Gateway を置いてください。