2026年 OpenClaw を Telegram Bot で独占リモート Mac（SSH）に載せる：チーム向け常時入口──Long Polling と Webhook、ゲートウェイ束縛とトークン境界、レート制限・409 の再現デプロイ＋FAQ
監査可能な単一の入口として、独占リモート Mac上の OpenClaw をチームに開く構成です。Telegram をチャット面にし、SSH は管理面のままにします。本稿は getUpdates 長期ポーリングと HTTPS Webhookを比較し、Bot API トークンとゲートウェイ資格情報の境界を引き、Telegram の 409 Conflict を意図的に再現して当番が推測で消耗しないようにします。
TL;DR──インフラメモに貼る用
要点：1 つのボットトークンに対し、Telegram サーバ側では同時に有効な受信トランスポートは一系統に収束します。Webhook を張ったまま別ホストが getUpdates を叩く、ステージングの古いポーラが残る、といった状態は 409 Conflict と更新の二重取り込みを招きます。OpenClaw ゲートウェイの HTTP は ループバック束縛にし、TLS はリバースプロキシで終端します。Bot トークンをクライアント向けログに出さないこと。
- 長期ポーリング：NAT 裏でも単純。Mac 上に常駐プロセス 1 本。メモリと FD 上限に注意。
- Webhook：安定した 443 / TLS URL と高エントロピーなパスが必要。Cloudflare Tunnel 等を既に運用しているなら向き。
- ゲートウェイ用トークン（使う場合）は
TELEGRAM_BOT_TOKENと交換不可。ローテーション周期も別管理。 - 409 ドリル：同一トークンで消費者を 2 つ起動し競合を観測し、ステージングと本番の kill 順序を文書化する。
ヘッドレス macOS で launchd 配下のゲートウェイ環境変数を揃えるには、2026年最新 OpenClaw デプロイ・安定運用マニュアル：SSH、systemdから24時間自動再起動まで と 2026年 OpenClaw & SSH自動化深掘り実践：落とし穴回避・安定バックグラウンド実行・安全デプロイ を突き合わせてください。
1. 「チーム向け常時入口」とは（独占メタル上）
独占リモート Macはシングルテナントです。OpenClaw のプロセス群、ファイルディスクリプタ、キーチェーン項目が他顧客の CI ピークと競合しません。Telegram は人が触る制御面（承認、ステータス、当番スレ）に使い、SSH は設定差し替え・秘密のローテーション・ログ閲覧に限定するのが定石です。
設計目標は、最小権限（ボットからシェル不可）、観測可能（構造化ログとメトリクス）、429／二重ポーラ時にフェイルクローズすることです。
2. 長期ポーリングと Webhook──意思決定表
| 観点 | 長期ポーリング（getUpdates） |
Webhook（setWebhook） |
|---|---|---|
| パブリック受入口 | 不要。外向き HTTPS があればよい | 到達可能な 443 と有効な TLS チェーンが必要 |
| NAT／自宅ラボ | 多くの場合そのまま動く | トンネルかエッジホスティングが必要 |
| 二重消費者リスク | 同一トークンの第 2 プロセスがあると高い | 中程度──古いポーラを止めてから Webhook を張る必要 |
| 遅延の尾部 | 長期ポールのタイムアウトとキュー深さで上限が決まる | エッジが健全なら中央値は低めになりやすい |
| リモート Mac 上の運用感 | LaunchAgent 1 本＋ログ | LaunchAgent＋リバプロ＋証明書更新 |
ゼロトラストのエッジを既に持っているなら、遅延は Webhook 有利。上りが厳しい回線の裏に Mac があるなら、シングルトン消費者を強制できる前提で長期ポーリングが無難です。
3. ゲートウェイ束縛とトークン境界
束縛アドレス：OpenClaw ゲートウェイの HTTP リスナーは 127.0.0.1（またはビルドが対応する Unix ドメインソケット）に置き、nginx／caddy／トンネルエージェントで TLS を終端します。Telegram 連携プロセスはループバック越しにそのローカル面へだけ話せばよく、ゲートウェイの管理系ルートをインターネットに晒す理由はありません。
トークン種別（混ぜない）：
TELEGRAM_BOT_TOKEN──BotFather 発行。そのボットアイデンティティの送受信のみ。- OpenClaw ゲートウェイ用トークン／API キー──自社の自動化とツール経路の認可。別カデンスでローテーション。
- モデルプロバイダ鍵──Telegram チャットにエコーしない。失敗は不透明なインシデント ID に写像。
3 種とも macOS キーチェーンか、サービスユーザのみ読める密封 env ファイルに置き、Git には入れない。集約ログに出す前に 1 行トランスフォームで Telegram トークンをマスクする。
4. Telegram レート制限──実務で痛いところ
チャット単位の送信スロットルとグローバルなフラッド制御を前提にします。症状は 429 Too Many Requests と retry_after 秒、エージェントが人間の読む速度を超えて返信したときの連鎖失敗、バックオフを協調的にしないと Mac 上のキューが雪だるま式に膨らむことです。
- ブリッジ層でチャット ID ごとにトークンバケットで送信ペースを制御する。
- うるさいステータス行は 1 本のピン留めやスレ返信戦略に集約する。
retry_afterを OpenClaw に第一級の「クールダウン」として渡し、ツールが空回りしないようにする。
5. 409 Conflict の再現と収束
Telegram は、同じボットセッションについて互換のない方法で 2 クライアントが奪い合うと 409 を返します。典型は Webhook が有効なのに getUpdates ポーラが残っている、または 2 ホストが同一トークンでポーリングしているパターンです。
- ステージングシェルで誤って本番トークンを export し手動ポールを走らせる──本番ポーラが即エラーまたはフラップする。
getWebhookInfoを呼び、URL が空でなければ迷子のポーラを止め、deleteWebhookするか Webhook 専用に揃える。- リモート Mac で 単一の LaunchAgent ジョブグラフを再起動し、
launchctl printでボット監督プロセスが 1 つだけ載っていることを確認する。
このドリルを runbook に書き、新入社員がノート PCから「とりあえず」本番 BotFather トークンを試さないようにします。
6. 再現可能デプロイ・チェックリスト（SSH 前提）
- サービスユーザ（例：
openclaw-svc）を作り、ホームを絞り、SSH は break-glass 用の forced-command のみ、などにする。 - ベンダ手順で OpenClaw を導入。バージョンはインフラ用リポのロックファイルに固定（秘密は含めない）。
- LaunchAgent plist：
ThrottleInterval、StandardOutPath／StandardErrorPath、キーチェーンラップした秘密を参照するEnvironmentVariables。 - Webhook か長期ポーリングのどちらか一方を選び、対応する Bot API セットアップを呼ぶ。
getWebhookInfoと合成メッセージで検証。 - Webhook なら nginx／Caddy を前段に：TLS 1.2+、OCSP stapling、任意で IP 制限、ランダムな高エントロピー URL パス。
- ヘルスチェック：同一 UID からゲートウェイ
/health等へローカルcurl。 - トークン除去したログをオフボックスへ。429／409 の持続カウンタでアラート。
FAQ
フェイルオーバーで Webhook と長期ポーリングを同時に回せる？
同一ボットトークンでは同時に有効にできません。ボットを 2 つ（本番／ステージ身份）に分けるか、一方のモードを明示的に解体してから他方を起動する制御スクリプトを用意してください。
Telegram のために Mac に固定 IP は要る？
長期ポーリングなら不要です。Webhook では 安定した DNS と TLS エンドポイントが要ります。Mac はトンネル背後でも、公開ホスト名が正しくルーティングされれば構いません。
macOS 上のボットトークンはどこに置く？
キーチェーン＋起動時に security find-generic-password で LaunchAgent の EnvironmentVariables を埋める方法、またはリポ外の root 所有 0400 env ファイルを推奨します。
409 を直したのに二重メッセージが残る
ブリッジが更新を二重に ackしているか、べき等キーなしで POST を再送している可能性があります。update_id をキーにサーバ側で重複排除してください。
この制御面に Mac mini と macOS が向く理由
Telegram ブリッジと OpenClaw ゲートウェイは、常時オンで負荷は低いがゼロではないワークロードです。TLS 終端、チームが大きなログを貼ったときのスパイク、バックグラウンドのタイマーが重なります。Apple Silicon の Mac miniはシングルスレッド性能が高く、軽負荷設定では待機電力が数ワット程度に抑えやすく、コロケーションや自宅ラックの電気代を読みやすく保てます。ファンレスに近い静音性も、デスク横ラボに置き続ける用途と相性がよいです。
macOS はそのハードウェアと launchd によるサービス監督、ロールバックに使える APFS スナップショット、そして Gatekeeper・SIP・FileVault による防御層を一体で提供します。ボットトークンは実質ネットワーク資格情報に等しいため、一般的な Windows ユーティリティホストより脅威面が小さい構成を選びやすいです。
SSH で理由のわかるメタル上に第 6 節のチェックリストをそのまま載せたいなら、2026 年時点でも Mac mini M4 は価格対性能の錨のままです。ループバックのみでサービスを立て、エッジはトンネルに任せ、メトリクスでリージョン追加の要否を判断するのが現実的です。
24/7 の常時入口を自前メタルで回す準備ができたら、今すぐ Mac mini を手に入れ、第 6 節の項目をそのままボックス上で線引きしてください。