1. 課題整理：モデル以前に「チャネル契約」を揃える
（1）Discord：Intent とチャンネル権限。Message Content Intent が無効だと一般ユーザーの本文が Bot に届かないことがあります。送信・埋め込み・添付が不足していると、イベントは残るのにチャンネルには返信が出ません。これはモデル品質の問題ではなく、Bot が「話せる権利」を持っていない状態です。
（2）WhatsApp：ペアリングとポリシーは別物。QR ログイン後も channels.whatsapp 配下の dmPolicy や allowFrom が実際の送信元（E.164 形式やグループ ID）と一致しないと、接続は成功していてもメッセージがポリシー層で静かに破棄されます。
（3）Gateway のライフサイクル。Discord も WhatsApp も長寿命コンシューマに依存します。ノート PC のスリープ、二重起動した openclaw gateway、ポート競合は、両チャネルを同時に「ランダム無応答」に見せかけます。
2. 対照表：Discord Bot と WhatsApp チャネル（OpenClaw 視点）
| 観点 | Discord | |
|---|---|---|
| 身元と資格情報 | Bot Token、Application ID、OAuth インストール範囲 | 電話ログイン／ペアリング；明示的な許可リスト |
| 典型の切り分け先 | Developer Portal → Bot → Privileged Gateway Intents | openclaw channels login --channel whatsapp とポリシーブロックの整合 |
| リスクとコンプライアンス | サーバー招待とロール境界；監査ログの確認 | 個人番号と業務番号の分離；未知の番号への開放を避ける |
| Gateway との関係 | イベントは Gateway 経由で配信；長寿命接続が前提 | セッションと再接続も Gateway 依存；断線は観測可能であるべき |
2b. channels.* の最小露出
openclaw.json で Discord はサーバー／チャンネル、WhatsApp は allowFrom で送信元を絞る。全開放はリンク／番号流出時にエージェントが意図しない会話へ届く。
3. 再現可能な五ステップ
- スコープ固定：単独か並行か決め、並行時はデフォルトモデル経路とツール優先を決定。
- Discord 最小権限：Portal で必要 Intent のみ、チャンネルに合う Bot 権限。トークンはシークレットのみ。
- WhatsApp 整合：ペア後すぐ
dmPolicy／許可リストを実番号で照合し、変更後は Gateway 再起動。 - 検証→常駐：フォアグラウンドでポート確認後、launchd 等でログパス固定。
- 一週間の実トラフィック：無返信が偏れば Intent／ポリシー優先、モデル差し替えは後。
4. 計画・レビューで引用できる閾値
インシデントで使える目安：
- Gateway・モデル前に OS 常駐込みで4GB以上の空きを確保（メモリ不足は無応答を招く）。
- ピークに三回無返信＋再接続／レート制限ログなら、先に API 上限と単一インスタンス並列を疑う。
- 7×24なら蓋閉めノートを本番に据えず、常時給電ノード（固定イメージのリモート Mac 等）を検討。
5. いつリモート Mac に載せ替えるか
| シグナル | 推奨 |
|---|---|
| コミュニティと DM の両方を監査可能な形で運用したい | Gateway 専用ノード；開発者 PC は設定・灰度のみ |
| スリープや省電力で毎日切断が発生 | 常時給電のリモート Mac またはデータセンターノードへ移行 |
| チームで同一 Bot 身元を共有 | 固定イメージと環境変数で「各人のノート設定ドリフト」を防ぐ |
6. FAQ
Discord でイベントはあるが返信がない。 まず Bot がそのチャンネルを閲覧・送信できるか、Intent と送信権限を確認してからモデルを疑います。WhatsApp は接続済みだが無返信。 番号形式と allowFrom を優先し、次に Gateway が単一インスタンスかを確認します。多チャネル同時運用は？ 可能ですが、並列度とツール予算を文書化しないとタイムアウトが「モデル不安定」に見えます。
7. 深掘り：コミュニティ自動化は「運用」の問題である
2026 年、本番の差はモデルよりチャネル契約（権限・ポリシー・再接続・ログ）です。個人ノートだけで Gateway を回すと再現不能チケットが増え、原因はプロセス／ネットワークのライフサイクルです。夜間運用でスリープ・二重起動が重なると再接続ログが積み、「API 不安定」と誤診されがちです。
会話エージェントにも API と同様に SLO・構造化ログ・設定変更とインシデント時刻の突き合わせが要ります。Gateway を監視可能な固定ノードへ移すのはスノビズムではなく再現性のためであり、電源・ネットワーク・単一の正規設定が揃って初めて「サービス」と言えます。
8. 収束：汎用 Linux／個人 PC の限界とリモート Mac、MACGPU
（1）汎用 Linux VM と個人ノートの限界。Linux 上で Gateway を動かすこと自体は可能ですが、クリエイティブ業務で macOS 専用ツールやメディアパスに依存するチームでは摩擦が増えます。個人ノートはスリープ、VPN、OS アップデート後の設定ドリフトを抱え、コミュニティ向け本番入口には不向きです。
（2）リモート Apple Silicon が合う理由。ユニファイドメモリはモデル推論と Gateway を同居させやすく、launchd とログの置き場所は多くのデザイン／映像チームの自動化と整合しやすいです。
（3）MACGPU。固定イメージとオンライン率が必要なら、時間課金のリモート Mac でコストと信頼性を揃える選択が現実的です。公開料金はログイン不要—CTA 参照。