運営通知をNextcloud Talkへつなぐ：検知・送信・対応完了を分ける

注文処理の問題や確認が必要な投稿を見つけても、担当者が気づかなければ対応は進みません。社内の運営通知をNextcloud Talkへつないだ事例を、顧客情報・ルームURL・内部構成を伏せて整理します。

一種類の通知で再送と管理導線を試す

まず「処理失敗」のような一種類を選び、個人情報を含まないテスト通知から、権限のある担当者が管理画面へ進めるか確かめます。同じ問題を再検知した場合と送信だけに失敗した場合を別々に試し、重複通知や業務処理の二重実行を起こさず再送できるか確認します。

Nextcloud Talk：BotとWebhookの接続仕様

通知は気づく入口にする

非公開の通知先へは問題の種類と、権限確認のある管理画面へのリンクを送ります。詳細な注文情報や個人の連絡先をチャットへ複製しません。通知を受ける人と、管理画面で対応できる人は別々に管理します。実際の承認・担当割当・対応完了は管理画面へ残す設計です。

Botの接続と秘密管理を分ける

TalkにはBotからメッセージを送る公式APIがあります。接続先とBotの認証情報を限定し、秘密値はコード・設定画面・通知本文へ出しません。外部への接続は通知を担う処理で行い、ブラウザーへBotの秘密を渡さない構成にします。

検知・配信・対応を別々の結果にする

通知対象の検知、送信要求、APIの送信結果、実際の受信、担当者の対応は異なる段階です。送信失敗を業務上の問題が解消した結果へ置き換えず、通知だけの再試行で注文処理などを再実行しないようにします。本文の生成でも顧客データを必要最小限にし、管理リンクの公開元を固定します。

1. 1 検知して送信 問題の種別と管理画面へのlinkを、最小限の情報で通知する。
2. 2 テスト受信を確認 APIの送信結果と、通知を実際に受け取った記録を分けて照合する。
3. 3 人が確認・対応 問題から解決までの業務受入とスマートフォンpushは未確認。

本番接続テストから業務受入へ進む

実装のテストとCI、DB変更と本番配信の後、通知先を有効にして無害な接続テストを送り、受信と送信成功の記録を照合しました。開発環境での成功だけを本番接続の証明にはしません。

この事例では実受信まで確認済みですが、実際の業務上の問題を解決する一連の受入とスマートフォンのpush確認は未実施です。通知APIの成功は、担当者が読んだことや対応を完了したことの証拠ではありません。

定期監視の通知整理はOpenClawの監視・障害調査も参照してください。