通知系リソースの選び方
通知の実装は「送れること」より「届くこと」と「読まれること」で評価が決まる。送信 API が成功を返しても、迷惑メール判定されたり、通知が多すぎて読まれなくなったりすれば、機能としては失敗している。
経路ごとの性格
- メール — 到達率の作り込み（SPF / DKIM / DMARC）が前提。バウンス処理を自動化しないと送信元評価が落ちる
- チャット（Slack / Discord 等） — 導入は最も手軽。ただし通知量の設計を誤ると誰も読まなくなる
- SMS / 電話 — 到達性は高いが単価も高く、課金攻撃の標的にもなる
- メッセージングアプリ（LINE 等） — 国内の到達率は高いが、配信数がそのまま課金に効く
「何を通知しないか」の設計が本体です
導入直後は全部通知したくなりますが、読まれない通知は重要な通知を埋もれさせる分だけ有害です。重大度で送り先を分ける、軽微なものは日次サマリにまとめる、といった設計を最初から入れてください。後から減らすのは、増やすより難しくなります。
通知に載せてよい情報
エラー通知にスタックトレースやリクエスト内容をそのまま流すと、トークンや個人情報がチャットのログに長期間残る。通知に含めるのは識別子と種別に留め、詳細は権限のある画面で確認する構成にしておくのが安全だ。チャットのログは検索可能で、参加者全員が閲覧できる点を忘れないようにしたい。
重要な通知は冗長化する
リアルタイム通知は切断される前提の技術で、チャットサービス自体が障害を起こすこともある。決済失敗や障害検知のように取りこぼしが許されない通知は、経路を二重にするか、受信側で「一定時間通知が来ていない」ことを検知する仕組みを持たせておきたい。