フォーラム（話題）付き Telegram スーパーグループでは、MessageThreadId の有無で transcript パスが分岐し、Heartbeat やツール応答がルートチャットへ落ちる事故が起きやすくなります。OpenClaw v2026.4.14 前後の 4.x を前提に、痛みの分解、意思決定表、症状とログの対応表、Webhook / ロングポーリングの運用差、再現手順となる 8 ステップ、引用メモ、VNC 検収までを一気通貫でまとめます。
1) 痛みの分解
- スレッド ID 欠落：転送や一部クライアント経路で
message_thread_idが落ち、同じ人間でも「裸の transcript」と「話題付き transcript」に分裂します。General 根話題と子話題を混在させると、人間の認知と Gateway ログがすれ違います。 - Heartbeat の着地点ドリフト：
lastや明示ターゲットが無いと自動メッセージがグループ根へ出ます。本文にツール呼び出しや長い URL を混ぜると、活発フォーラムでは実質ブロードキャストになります。頻度・@all 可否・根投稿ポリシーを Runbook に書きます。 - ツール outbound の不一致：受信スレッドを踏襲しない送信は「A 話題で質問し根で回答」になります。検索やファイル書き込みなどカード型プラグインは内部キューが分岐しやすく、承認 UI と最終回答が別スレッドに割れる二次事故が起きます。送信ヘルパーは常に直近の受信 thread id を運ぶのが規律です。
表象とログの対応
チケットに貼れる言い方で整理しました。Telegram UI・Gateway コンソール・ローカルログを VNC 上で同時に見る前提です。
| チャットで見えること | 先に取るログ証拠 | まず試す対策（モデル変更なし） | それでもダメなら |
|---|---|---|---|
| 同じ人が突然文脈喪失 | 2 件の受信で transcript パスやキーが異なる／片方に thread が無い | 検証アカウントを単一子話題に固定、転送チェーン禁止 | 一話題一 Bot、またはフォーラムを止め通常群へ |
| 定期 Heartbeat が別スレッドを荒らす | 送信 JSON に thread が無い／古い id | 明示 topic か last に束縛し Gateway を再起動 | 間隔を伸ばしジッタ付与、本文を記号一行に |
| ツール結果が「別室」に出る | 受信は thread あり、送信は無し／既定 chat | thread 無しなら自動送信を拒否するアサーション | reply_to_message_id でスレッド追従 |
マルチチャネル記事と同じく、単一チャネルで閉ループを作ってから拡張するのが最短です。
2) マトリクス
| 協業スタイル | トポロジー | コスト | リスク |
|---|---|---|---|
| 話題で分離したい | フォーラム + 1 Bot + 厳格ルーティング | 高 | ID 欠落で transcript 分岐 |
| 小規模単一スレッド | 通常スーパーグループ | 低 | フォーラムは過剰 |
| 強いテナント分離 | Bot 分割 / グループ分割 | 運用高 | トークン面拡大 |
| 放送のみ | チャンネル分離 | 中 | 多ターンエージェントと相性悪 |
| 既にマルチ IM | Telegram フォーラム試験窓を独立 | 中 | 横断変更で原因不明化 |
7) 症状・ログ・修正と転送形態
感覚で設定をいじると永遠に終わりません。順序は固定で：Telegram イベントが Gateway に届いているか → thread フィールド → 最後にモデル／ツール許可。Webhook とロングポーリングはどちらも可能ですが、Webhook はリバースプロキシ・証明書更新・重複配送で頭を悩ませ、ロングポーリングはリモート Mac のスリープと相性が悪いと「スレッド消失」に見えるだけ、という罠があります。
| 転送 | フォーラム向きの利点 | 典型障害 | VNC での見方 |
|---|---|---|---|
| Webhook | 即時性、HTTP ログと相関しやすい | 公開入口、プロキシタイムアウト、重複 | リモート Mac のブラウザでヘルス URL を開きヘッダと TLS をスクショ |
| Long polling | ラボ向けに単純 | ワーカー停滞で状態機が止まる | top と Telegram の受信時刻が前に進むか同時監視 |
マスク済みの受信サンプルで目を慣らします。フィールド暗記より「thread があるか／null か／reply と整合するか」です。
{
"update_id": 100000000,
"message": {
"message_id": 2048,
"chat": { "id": -1001234567890, "title": "Demo", "is_forum": true },
"message_thread_id": 99,
"from": { "id": 12345, "is_bot": false },
"text": "この話題で前ステップのツールチェーンを続行"
}
}
"message_thread_id": null や欠落を見たら、まず転送やクロスチャット引用をやめて素のテキスト送信で再現するか確認します。
3) 8 ステップ
クライアントでフォーラム有効を確認
設定と話題一覧をスクショし chat_id と検証話題を記録。
macOS Telegram Desktop では既定投稿先が General かを確認し、テスターの最終話題と Gateway の last を揃えます。
Bot 権限を最小付与（VNC で点検）
話題名のためサービスメッセージ読取が必要なら方針に明記。
読取禁止なら固定タイトル白名单など代替を文書化し、話題改名を意図変化と誤認しないようにします。
単一話題でツール多ターンを完走
2 話題目の前に、二人が別子話題で短い連投をして transcript 競合やロック警告を確認。
マスク済み JSON で message_thread_id を追跡
forum_topic_created や reply_to_message もセットで。
同一秒の受信＋送信ペアを保存し、欠落が受信側か送信側かを切り分けます。
Heartbeat を last / 明示ターゲットへ
変更後は Gateway 再起動。
GW=ok thread=99 のような機械可読一行にすると人間の目視でもズレに気づけます。
プラグイン承認と outbound スレッド検証
カード型とプレーンテキストを両方試し、描画パス差で落ちないか見る。
openclaw doctor とバージョン指紋
チケットに openclaw --version を添付。
TLS 警告はリバプロ記事と切り分け、スレッド問題と混ぜない。
通常群へ戻す手順を Runbook 化
フォーラム無効化、webhook 失効、設定復元。
ロールバック後もフォーラム前 transcript の保管場所を法務向けに残す。
4) 引用メモ
5) VNC 検収
リリース直前 10 分のゲートとして回すリストです。マイナーアップのたびに再スモークしないと「先週は動いた」系の退行に弱いです。
- □ 期待
message_thread_idが受信に付随 - □ Heartbeat がルートに落ちない
- □ 二話題並列で transcript が壊れない
- □ ロールバック手順のスクショ保存
- □ プラグイン承認カードと最終回答が同一スレッド（分岐したらキュー名をチケットに）
- □ リモート Mac の過剰スリープ無効（NIC スリープは Gateway 死を偽装）
- □ リバプロと証明書期限をカレンダー化し TLS を thread 不具合と混同しない
6) FAQ
Q: 4.14 固定？ インストール済みビルドを正とする。
Q: 他 IM と同時？ マルチチャネル記事の順序を守る。
まとめ：SSH だけでは話題ツリーと Gateway を同時に見られない。VNC 付きリモート Mac（VNCMac）で証跡を揃えると、フォーラム運用の再現性が上がります。