memo: route webhooks into the room as a participant instead of per-session mcp

[smileygames]

観測

現状、webhook は github-webhook-mcp をセッションごとに channel として読み込ませることで各エージェントへ届いている。イベント一つに対してセッション数ぶんの push が飛ぶ。

案（Master、2026-08-21、対話中）: MCP 経由で個々の AI へ渡すのではなく、liplus-chat の部屋そのものへ流す。

現時点で採用しない。 可能性として記録する。

境界の判定

仕様の第一制約は「アプリは部屋であってランタイムではない」。webhook 受信がこれに当たるかを確認した結果、当たらないと判断する。

• 却下される形 = アプリが部屋の中（参加者の仕事：ファイル、git、CLI 出力）を覗く
• webhook = アプリが部屋の外から来たものを壁に貼る

部屋には扉があってよい。外部が部屋に向かって発言する形であれば、アプリは何も解釈していない。

ただし条件付き。アプリが「このイベントは PR #31 の話だから Claude へ」といった振り分けを始めると、それは解釈であり運搬ではなくなる。配るだけ。誰が拾うかは部屋の規律が決める。

より強い形

アプリの機能として実装しない。

部屋プロトコルは既に hello / reply を持つ。webhook 中継をサイドカーと同じ一参加者として書けば、部屋ソケットへ接続して hello を送り、イベントを reply として発言するだけで済む。アプリ側に webhook の知識が一行も要らず、境界が完全に保たれる。

利点

• 枠の消費が N 分の 1 になる。 現状はイベント一つにつきセッション数ぶんの反応が起きる。部屋へ流せば発言は一つで、誰が拾うかは宛先と沈黙の規律（feat(room): give utterances an addressee so agents can stay silent #31）が決める。
• 人間にも見える。 現状 webhook はエージェントの文脈へ直接入るため、その子が言及しない限り人間の目に触れない。部屋に流れれば全員が同じものを見る。仕様の「発言者と会話の流れを追える形で観測できる」に直接効く。
• セッション起動時の channel エントリが減る。

未解決の点

1. 騒音。 このワークスペースの webhook は量が多い（2026-08-21 の一セッション中に未処理 100 件超、大半は workflow_run）。そのまま流すと会話が埋まり、反応が起きれば枠が溶ける。フィルタ / 専用ルーム / 既定ミュートのいずれかが要る。

2. 受領保証の喪失。 github-webhook-mcp は未処理イベントを保持し mark_processed で明示的に消す。アプリ停止中のイベントも残る。チャットルームにはその仕組みが無く、流れて消える。

したがって設計の分岐は「MCP をやめて部屋へ一本化」か「MCP を残して部屋にも流す」か。前者は受領保証を部屋側に作る必要がある。後者は二重通知になるため、どちらの経路をエージェントが見るかを決める必要がある。

関連

• feat(room): give utterances an addressee so agents can stay silent #31 — 宛先。誰が拾うかの規律はこちらが前提になる。