公式アカウントの導入によって、店舗の担当者が新しい情報を適切な時点で知る必要性が明確になった。管理画面に故障報告を表示しても、新着を探すために開き続けなければ負担は残る。問い合わせの返信や管理設定の案内にも同じ課題がある。

報告画面だけにプッシュを追加すると、後から問い合わせ、DM、お知らせを作る際に通知先確認と端末登録を繰り返すことになる。現在のPreviewでは、アカウントの通知を保存し、必要に応じて同意済み端末へ届ける共通システムを使う。公式アカウントから生まれた要件を、複数の機能で利用する構成である。

通知の種類とアカウントの通知一覧

通知一覧は、サービス内で自分に知らせることが発生したときに見返せるリストである。運営者には新しい報告、報告者にはほかの利用者の反応、問い合わせた人には返信が必要になる。DMとお知らせにもそれぞれの対象があるが、保存して確認する仕組みは共用できる。

flowchart LR
    accTitle: 複数の機能が共有する通知基盤
    accDescr: 公式アカウントの運営業務、故障報告、お問い合わせ、個人メッセージ、お知らせが共通基盤につながる。ブログ公開はまだ接続していない拡張対象である。
    O["公式アカウントの運営業務"] --> F["故障報告とお問い合わせ"]
    F --> N["共通の通知処理"]
    D["個人メッセージ"] --> N
    A["更新ストーリーの公開"] --> N
    B["ブログの新しい記事"] -. "今後の接続対象" .-> N
    N --> I["アカウントの通知一覧"]
    N --> P["同意した端末へのプッシュ"]

現在は公式アカウントの設定案内、故障報告と反応、問い合わせの受付と返信、個人メッセージと共有問い合わせ、公開した更新ストーリーを接続している。旧問い合わせの通知も読めるようにしている。図と表はこの範囲を示す。Markdownブログ記事の公開に伴う自動通知は未実装であり、発行イベントと受信方針を別途組み込む必要がある。

通知先と現在の閲覧資格

通知を作る前に、その情報を誰へ届けるか決める。例えば通常の店舗問い合わせは現在の公式担当者に知らせればよく、閲覧資格のあるプラットフォーム職員全員を呼ぶ必要はない。Musecat担当者を呼ぶ場合は明示的なメンションを使い、送信者自身には同じメッセージを通知しない。

サーバーはアカウント状態、役割、店舗の所有関係、会話へのアクセス、イベント別の受信条件を適用する。登録済み端末と設定があればプッシュ待ちを作り、なくてもアカウントの通知は保存できる。プッシュ設定を変えても問い合わせを読む資格まで変更しない。

flowchart TD
    accTitle: 出来事から受信者と配信経路を選ぶ
    accDescr: サーバーが出来事ごとの受信資格を判断してアカウント通知を作り、登録済み端末と該当する受信設定がある場合だけプッシュを待機させる。
    E["サービス内で出来事が発生"] --> R{"現在の受信資格があるか"}
    R -->|"いいえ"| X["そのアカウントの新規通知は作らない"]
    R -->|"はい"| I["アカウント通知を保存"]
    I --> V["通知一覧で確認できる"]
    I --> C{"同意した端末と受信設定があるか"}
    C -->|"はい"| Q["端末ごとの配信待ち"]
    C -->|"いいえ"| W["通知一覧の記録だけを保持"]

過去の通知を読む際にも、元の報告、問い合わせ、会話の現在の権限を確かめる。担当交代などで資格を失った人に、以前受信したという理由だけで内容を表示し続けない。送信待ちのプッシュにも、後で条件を確認する処理が必要になる。

通知の保存とoutboxの処理

外部のプッシュサービスが遅くても、故障報告の登録を待たせる必要はない。例えば報告だけ保存されて送信が失敗した場合、報告を取り消さず配信を再試行できる方法が必要になる。outboxは外部へ送る作業を先に保存する仕組みである。

アカウント通知にはuser_notification、端末にはuser_notification_device、端末ごとの配信待ちにはuser_notification_deliveryを使う。報告やメッセージの保存では原本、通知、対象端末の配信待ちを同じトランザクションで確定する。実際の送信はコミット後に別のワーカーが行い、外部の待ち時間を保存から切り離す。

sequenceDiagram
    accTitle: ドメイン処理と通知する仕事を一緒に確定する
    accDescr: 報告やメッセージのトランザクションで元の記録、アカウント通知、端末ごとのoutboxを保存する。確定後に別のワーカーが外部プッシュを送信する。
    participant U as リクエスト元の画面
    participant D as 報告またはメッセージ処理
    participant S as データベース
    participant W as 配信ワーカー
    participant P as 外部プッシュサービス
    U->>D: 報告またはメッセージを登録
    D->>S: トランザクション開始
    D->>S: 元の記録とアカウント通知を保存
    D->>S: 対象端末のoutboxを保存
    D->>S: 一緒に確定
    D-->>U: 元の保存結果を返す
    W->>S: 確定済みの配信待ちを取得
    W->>P: トランザクションの外で送信
    W->>S: 完了または次回の試行を記録

アカウントとevent_keyで通知を、通知と端末で配信を識別する。再処理しても同じ作業を重複生成しないためである。元の報告、メッセージ、発行物への参照は、後の権限検査と移動にも使う。

多くの人へ配るお知らせは、公開状態を保存した後に受信者を分割して処理する。各単位で進行位置、通知、端末別待機をまとめて確定する。途中停止で同じ単位を再処理しても、既読を初期化したり同じ公開を新しいイベントにしたりしない構成である。

通知を開く操作とプッシュ設定

ブラウザープッシュを使わなくても通知一覧は確認できる。ある端末の失敗、アカウントの既読、ほかの端末への配信はそれぞれ管理する。画面は定期取得とメッセージの変更信号で更新し、以前読み込んだ履歴と新しい結果を通知IDで統合する。表示項目と未確認数は現在閲覧できる原本から求める。

項目を選ぶと既読保存の成功後に会話や元の画面を開き、移動先でも権限を確認する。既読保存に失敗した場合はエラーと再試行を提供する。

flowchart TD
    accTitle: 通知一覧から元の画面へ移動する
    accDescr: 現在のアカウントと元の記録への権限を確認し、指定言語で通知を取得する。既読保存の成功後に移動し、移動先でもアクセス権を再確認する。
    L["通知一覧の取得または更新"] --> V["現在のアカウントと元の権限を確認"]
    V --> C["言語に応じた一覧と未読件数"]
    C --> T["通知項目を選択"]
    T --> R{"既読保存に成功したか"}
    R -->|"いいえ"| E["エラー表示と再試行"]
    R -->|"はい"| O["会話または元の画面を開く"]
    O --> A["移動先で現在のアクセス権を再確認"]

プッシュ権限は利用者が明示的に有効にするときに要求する。通知一覧を開くだけでは要求しない。endpointは現在のアカウントに関連付け、アカウント変更後も以前の所有者に購読が残らないようにする。

端末登録には言語も保存する。画面言語の変更では、現在のアカウントが同意済みの登録だけを更新し、新規登録やプッシュの有効化はしない。お知らせは公開言語に対応する端末へ送り、非公開の問い合わせとDMにはロック画面で本文を漏らさない一般的な到着案内を使う。

送信前の再確認と再試行

待機中に報告が解決したり担当者が変わったりすることがある。端末の解除やお知らせのアーカイブも起こり得る。送信担当のBackend Fullは、原本の状態、受信者の権限とメッセージ受信条件、端末の所有者と設定を再確認し、無効になった配信は外部へ送らず終了する。

一時的な失敗では回数と次の実行時刻を保存し、指数的に間隔を延ばして最大5回試行する。提供元が404または410で失効を返したら、そのアカウントの端末登録と関連する待機を整理する。元の報告やメッセージを変更せず配信を復旧できる。

flowchart TD
    accTitle: 端末への配信の再確認と失敗からの復旧
    accDescr: 元の記録、受信者、端末が現在も有効な配信だけを送る。一時的な失敗は上限内で再試行し、失効した端末登録は削除する。
    Q["確定した配信待ち"] --> V{"元の記録と受信者、端末はまだ有効か"}
    V -->|"いいえ"| X["送信せずに終了"]
    V -->|"はい"| S["端末の言語でプッシュ送信"]
    S -->|"プロバイダーが受理"| D["配信完了を記録"]
    S -->|"一時的な失敗"| R["回数上限と待機時間を設けて再試行"]
    R --> V
    S -->|"端末登録の失効"| C["登録と残った配信待ちを整理"]

提供元の受理はOSが実際に表示した証拠ではない。送信直後、完了保存前に停止すれば再送も起こり得るため、通知ID由来のpush tagで繰り返し表示をまとめる。問い合わせとお知らせはこの制約を踏まえた基盤を使う。ブログを追加する場合も、発行処理、識別子、通知先の方針を実装する必要がある。

関連する記事と資料：API境界の変化