Webhook の再送と重複排除：誤通知＝信頼毀損を防ぐ

B 方向·OPC 最佳实践（実装設計）。LINE の Messaging API はWebhook 受信側が 2xx を返さないと同じイベントを再送する——重複排除（idempotency）の設計がないと、家族に「同じ告警が 2 回」届き、それが信頼毀損になる。

背景与问题

• 告警の重複は誤報と区別がつかない——見守り製品で「同じ警告が 2 回来る」状態はシステムの信頼を最も安く壊す。実装段階で潰すべき設計バグ。

发现

設計の骨格【事実：再送挙動は LINE 公式ドキュメントの記載範囲。ヘッダ名等の詳細は要核】：

• 原因：Worker が処理中にタイムアウト/5xx を返す→LINE が再送→家族には同一告警が 2 通。
• 対策の骨格：①イベント ID（Webhook イベント毎の一意 ID）を KV/D1 に記録 ②受信時に ID 照合→処理済みなら 200 を返して破棄 ③記録の TTL は 1-7 日程度で十分【推测：再送窓の期間は要核】。
• 副作用：冪等設計はリトライ安全にもなる（自分側の再処理でも重複しない）——opc-monitoring-basics-solo の心跳設計と同じ「重複しても壊れない」姿勢。

结论

可行动启发：

1. イベント ID 重複排除を Day 1 から実装：KV に eventId: processed を TTL 付きで書くだけの軽量実装——後付けは告警履歴が汚れた後に直すより安い。
2. 「重複排除済み」の数を計測：排除件数が急増したら LINE 側か自 Worker 侧の異常シグナル（opc-monitoring-basics-solo に 1 指標追加）。
3. 通知ハブの出口も冪等に：家族への送信も「同一告警 ID は 1 回だけ」（japan-notification-hub の送信ジョブ設計に組込）——入口だけでなく出口も重複排除。
4. 誤配信時の「二重お詫び」を防ぐ：opc-incident-response-basics の告知フローが重複排除前提で設計されていることを確認。

待办 / 下次继续

• LINE Webhook 再送仕様（再送間隔/上限）の公式ドキュメント存档。
  
• KV 重複排除の実装メモ（TTL/キー設計）を Workers 骨架に追加。
  

关联

• 実装族：opc-line-messaging-cost-structure（通道）× 本篇（重複排除）× japan-notification-hub（出口冪等）× opc-monitoring-basics-solo（计测）；責任 japan-mimamori-liability-boundary。