エラー通知
送信失敗、外部連携失敗、サーバーエラーを運用者へ知らせます。
エラー通知は、利用者には見えにくい送信失敗、外部API連携失敗、定期処理失敗、サーバーエラーを運用者が早く把握するための機能です。Roundtableでは「どの失敗を通知対象にするか」「誰に、どの手段で知らせるか」「通知後にどこで調査するか」を先にそろえると、発注者、実装者、AIに指示する人が同じ前提で運用保守を設計できます。
この機能でできること
メールやLINEの送信失敗、決済や外部APIの連携失敗、CSV取込エラー、定期実行エラー、サーバーエラーを検知し、管理者や担当者へ通知できます。対象レコード、発生日時、失敗した処理、エラー要約、再実行や確認の状態を残すことで、発生後の調査と復旧を進めやすくします。
失敗を画面の裏側に埋もれさせず、対応対象として見える状態にします。
通知だけで終わらせず、対象データ、エラー内容、対応状況、再通知の条件をセットで残すと、運用者が次に何を確認すればよいか判断できます。
よくある利用場面
通知送信の失敗検知
申込完了メール、予約リマインド、請求案内、LINE通知が送れなかったときに、運用者へ失敗内容を知らせます。
外部連携の停止や失敗
決済、Webhook、外部API、配送CSV連携などで失敗した処理を記録し、再実行または手動確認へつなげます。
公開ページや定期処理の異常
公開フォーム送信時のエラー、夜間バッチの失敗、想定外のサーバーエラーを早めに把握して対応します。
プロンプト例
通知対象にするエラー種別、通知先、保存するエラー情報、一覧での検索条件、再実行や確認済みの扱いをまとめて伝えると、実装範囲を決めやすくなります。
プロンプト
予約管理にエラー通知を追加してください。予約完了メール、前日リマインド、決済完了Webhook、日次リマインド処理で失敗が起きた場合、運用者へメール通知し、エラー通知一覧に発生日時、処理種別、対象予約ID、通知先、エラー要約、対応状況、再実行可否を保存してください。管理側では未対応エラーだけを検索でき、詳細画面から対象予約と通知ログを確認できるようにしてください。公開側の利用者には内部エラー詳細を表示せず、必要な場合だけ受付済みの案内を出してください。
この機能を使うときのポイント
通知対象の基準すべての警告を通知すると埋もれるため、運用者が対応すべき失敗、確認だけでよい失敗、ログ保存だけでよい失敗を分けます。
通知先と時間帯通常時の担当者、緊急時の管理者、夜間の扱い、同じエラーの連続通知をどう抑えるかを決めます。
調査に必要な情報対象レコード、処理名、送信先、外部サービスの応答要約、発生日時、再実行結果を追えるようにします。
利用者への見せ方公開側では内部エラー全文を出さず、受付状況、再送予定、問い合わせ先など利用者に必要な情報だけを表示します。
この機能を実装するときのコツ
エラー通知は、例外が出た瞬間にメールを送るだけではなく、エラー記録、通知済み状態、対応状況、再実行結果を分けて設計すると運用しやすくなります。親レコード種別、親ID、処理種別、重要度、エラー要約、エラー詳細の保存範囲、通知先、通知結果、対応ステータスを持たせると、一覧検索と詳細調査の両方に使えます。同じ原因で短時間に大量発生する処理では、重複通知の抑制や集約通知を用意し、公開側から発生するエラーは本人が閲覧できる情報だけに変換して返します。