一つのグループチャット内で二つのTelegramボットを橋渡しする:HTTP上の配信セマンティクス

同じグループチャットで2つの独立したTelegramボットを接続するのは、思ったより難しい。ある開発者がr/openclawで、Telegramがグループ内で一方のボットからもう一方のボットへのメッセージを確実に配信しないため——人間は両方のメッセージを見られるにもかかわらず——ブリッジ層を構築した経験を詳しく説明している。
核心の問題
Telegramは、ボットAがグループにメッセージを送信しても、ボットBに更新を配信しない。そこでチームは、Telegramの制限を回避する小さなブリッジを構築した:
- ボットB → ボットA: ボットBはHTTPエンドポイント(テールゲート)を介して投稿し、ボットAに到達する。
- ボットA → ボットB: ボットAは、ボットBがポーリングする制御されたフィードを通じて、選択された送信メッセージを公開する。
- メッセージにはメタデータが含まれる:
source、direction、chat ID、nonce、およびsafe_to_bridgeフラグ。 - ACK: ボットBは特定のメッセージにACKを返し、少なくとも1ホップが機能したことを確認できる。
- 共有フィードには、ブリッジセーフなグループコンテキストのみが含まれる——プライベートDMや無関係なトラフィックは含まれない。
- ボットBのローカルポーラーは、古いメッセージやデバッグメッセージ、プロトコルメッセージ、ステータスメッセージをフィルタリングし、イベントの重複を排除し、新しい会話のターンのみを通過させる。
最初のバージョンからの教訓
最初の実装はあまりにも緩すぎた:生のTelegramコンテキストが共有フィードに漏れ出し、「なぜあのボットがそれを知っているのか?」という混乱を招いた。修正方法は、生の共有ログから明示的なブリッジセーフイベントのみに移行することだった。
現在の状態は制御されたテストで機能している:
- リレー経由でボットB → ボットA
- フィード経由でボットA → ボットB
- ACKはリレーパスを通じて流れる
- 一方のボットに明確に宛てられたメッセージの安全な自動ミラーリング
目標のフロー
目標とする会話ループ:
- 人間またはボットAが、ボットBに宛てたメッセージを書き込む。
- ブリッジがそれを安全にミラーリングする。
- ボットBがそれを一度見て、一度返信する。
- 安全かつ関連性があれば、返信がミラーリングされる。
- 重複、古いバックログ、プライベートDMの漏洩、デバッグエコー、ボットループがない。
アーキテクチャの方向性
著者は、ブリッジをチャットのハックではなく、小さなイベントバスのように扱うことを提案している:
- 厳格なメッセージIDとノンス
- ACK、重複排除、チェックポイント
- プライベートとグループセーフコンテキストを厳密に分離したスコープ付きフィード
難しいのは配信セマンティクス——新鮮さ、重複排除、ACK、そして無限ループを起こさずにボットが自動応答すべきタイミングの判断——である。
📖 全文を読む(英語): r/openclaw
👀 See Also

CludeCodeをWebアプリに接続して自動化されたインタラクションを実現
CludeCodeをAIツール(ブラウザやスクレイピングユーティリティなど)を活用してWebアプリケーションと自動的にやり取りする方法を探る。

WSL2でのUSBウェブカメラへのアクセスによるローカルモーション検出
開発者がusbipd-winを使用してUSBウェブカメラをWindowsからWSL2にパススルーする方法を共有し、クラウド依存なしでOpenCVによるローカルな動体検知を可能にします。

OpenClaw v2.0 アップデート:破壊的変更を回避するための重要なアップデート前チェックリスト
OpenClawの最新アップデートでは、12の破壊的変更、新しいプラグインシステム、30以上のセキュリティパッチが導入されました。このガイドでは、環境変数のリネーム、状態ディレクトリの移行、ブラウザ自動化の再設定など、アップデート前に実施すべき5つの重要なチェック項目を説明します。

小規模モデルの評価プロンプトが誤解を招く理由とその修正方法
Redditの投稿によると、小規模モデルの評価プロンプトは、トランスフォーマーの誤った認知経路をトリガーするため、しばしば誤解を招く結果を生み出します。具体的には、事実の想起、応用・指示の遵守、感情的・共感的推論という3つの異なるモードを特定しています。