通知機能の開発依頼｜未送信・重複・再送の要件を決める

通知機能の開発要件は、「どの操作で誰に何を送るか」だけでは足りません。メールが届かなかった場合、同じ通知が重なった場合、送信を止めるべき場合まで決めて、初めて納品時に合否を判断できます。

見積依頼では、通知契機・宛先・抑止・重複防止・再送・履歴を一つの受入条件表にします。特に未送信については、再送する失敗と再送しない失敗を分け、再送後も失敗した通知を破棄するのか、調査・再処理できる状態に残すのかを先に選びます。ただし、すべての通知に同じ扱いを当てはめる必要はありません。業務上見逃せない通知と、画面を開けば確認できる補助通知では、必要な復旧方法が異なるからです。

通知機能の開発要件は「正常に送れる」だけで決めない

通知の依頼文が「申請されたら担当者へメールを送る」だけだと、開発会社は正常系を見積もれても、失敗時の範囲を確定できません。担当者が未設定なら送らないのか、代替の宛先へ送るのか。送信処理が途中で失敗したら自動でやり直すのか、管理者が操作するのか。画面通知とメールを併用するとき、一方だけ成功した状態をどう扱うのか。ここが曖昧なままでは、納品後に「当然入っていると思った機能」が追加範囲になり得ます。

2026年9月21日時点で、OWASPはセキュリティの監視・警告・報告について、その水準と内容を情報セキュリティリスクに比例させ、要件・設計段階で決めるとしています。同時に、一律に適用できる答えはないとも示しています。OWASP Logging Cheat Sheetが直接扱うのはセキュリティログです。一般の業務通知すべてに同じ監視要件を課す根拠ではありません。以下の受入条件表は、この資料の公式要件ではなく、発注時に失敗時動作を決めるための運用上の提案です。

依頼前には、通知を業務上の重要度で分けてください。見逃すと次の作業が止まる通知、後から画面で確認できる通知、利用者が受信を選べる通知では、抑止や再送の条件を同じにできません。この分類が、後述する表の各行を分ける基準です。

見積依頼に添える受入条件表

次の表は、発注者が開発会社と合意するための運用上の提案です。製品仕様にする際は自社の業務へ置き換えます。通知の種類ごとに一行を作り、空欄を残さず、判断できない箇所は「要相談」として見積条件に含めます。

表中の具体的な通知名と条件は例であり、実在する導入事例や一律の推奨仕様ではありません。自社の業務フローに置き換えたうえで、次の観点から各セルを確定します。

表を埋める順番は、通知契機と宛先を先に固定し、抑止と重複防止で「送らない条件」を分け、最後に再送と履歴を決めると整理しやすくなります。メールと画面通知を併用する場合は、一つの行にまとめずチャネル別に分けます。メールだけ失敗したときに画面通知を成功として終えるのか、メールを再送するのかという部分成功も、別々の結果として合否を決められるからです。

通知契機

通知契機には、通知対象となる業務状態が成立する時点を書きます。ボタン操作を契機にすると、後続処理の失敗や操作の取り消しが通知へ反映されないことがあります。処理が完了しなかった場合も含めて線を引けば、「画面上は失敗したのにメールだけ届く」といった食い違いを受入試験で判定できます。

宛先と抑止

「担当者」だけでなく、どの時点の担当者か、宛先が存在しないときはどうするかを決めます。メールと画面通知の両方があるなら、チャネルごとに宛先と結果を分けます。抑止は送信前の意図した停止です。配信を試みて失敗した未送信とは分けて記録すると、仕様どおり送らなかった状態を障害と誤認しません。

重複防止

同じ操作が複数回処理される可能性を前提に、受信者側で意図しない重複通知が生じないことを受入条件にします。2026年9月21日時点のAWSによるAmazon SQSの説明では、標準キューで同じメッセージを再度受信する場合があり、複数回処理しても悪影響が出ない冪等な設計が求められています。これは採用技術をAmazon SQSに限定する話ではありません。発注時には、重複しないという結果を確認条件にし、実現方法は設計として開発会社と詰めます。

未送信時は再送の入口と出口を対で決める

「失敗したら再送する」だけでは、失敗が続いたときの状態が決まりません。運用上の提案として、失敗をまず「再送するもの」「再送しないもの」「人が判断するもの」に分けます。そのうえで、自動処理を終えた後に破棄するのか、調査・再処理の対象として残すのかを選びます。

2026年9月21日時点で、Amazon SNSは到達できない失敗をクライアント側エラーとサーバー側エラーに分け、前者は再送せず、後者はバックオフを用いて再送すると説明しています。また、クライアント側エラーまたは再送方針を超えたサーバー側エラーのメッセージは、デッドレターキューがなければ破棄され、あれば分析や再処理のため保持できます。Amazon SNSのデッドレターキューに関する公式資料で確認できる考え方です。

この事実を受入条件へ置き換えるときは、特定サービスの設定名を使わず、業務上確認できる結果で表します。

• 再送する失敗と再送しない失敗を区別できる
• 自動処理が終了した通知の行き先が決まっている
• 保持する場合、担当者が失敗理由を調査し、必要な通知を再処理できる
• 破棄する場合、その判断が対象通知の重要度と合っている

箇条書きのうち最後の二つは代替関係です。すべてを保持するとも、すべてを破棄するとも決めず、通知ごとの業務影響を基準に表へ記入します。再処理の管理画面、担当者への警告、手動再送の操作まで必要なら、それぞれ開発対象です。「履歴を残す」と「履歴から再送できる」は別の受入条件として見積もる必要があります。

履歴は宛先と結果を結び付けて確認する

通知全体の結果が「一部失敗」だけでは、対応すべき宛先を特定できません。そこで、宛先ごとの結果を判定できることを受入条件にします。Amazon SNSのデッドレターキューは購読単位に関連付けられ、元の配信先を識別しやすくなると公式資料で説明されています。この仕組みも、配信先と失敗結果を結び付ける必要性を支えます（2026年9月21日時点）。

同日時点でOWASPは、セキュリティログに「いつ・どこで・誰が・何を」を含め、操作、対象、成功・失敗・保留などの結果状態、結果理由、同じ操作に属する複数イベントを結ぶ相互作用識別子を記録候補に挙げています。この項目を一般の通知履歴へ転用することは運用上の提案です。受入確認には、少なくとも次の対応関係を使えます。

これは保存期間や閲覧権限まで自動的に決める表ではありません。それらが必要なら、履歴の表示、検索、再処理とは別の要件として明記します。要件の抜けを先に整理するときは、システム要件定義のチェックリストも併せて確認すると、通知以外の前提との境界を揃えやすくなります。

見積範囲と納品時の確認を分けない

依頼書には受入条件表とともに、既存機能のどこを変えるかを書きます。通知本文を変えるだけなのか、新しい通知契機や宛先判定を加えるのか、失敗履歴の画面や手動再送まで作るのかでは、作業範囲が異なります。見積項目を比較する前に、システム開発の見積もりで確認したい項目を使って前提と対象範囲を揃えてください。

納品時は表の一行ごとに、正常送信に加えて、抑止、同じ要求の再処理、宛先別の失敗、再送終了後、履歴の追跡を確認します。受入結果には、与えた条件、宛先ごとの結果、履歴で確認できた内容を残します。「通知機能が動いた」という記録だけでは、失敗時の合否を後から確かめられません。

追加範囲かどうかも同じ表で判断できます。合意済みの通知契機で失敗結果が記録されない場合は、受入条件との差です。合意に含めていなかった代替宛先、手動再送画面、履歴検索を後から求める場合は追加候補になります。表のどのセルを変更する依頼かを示せば、発注者と開発会社が同じ材料で境界を判断できます。

見積依頼には、業務に置き換えた受入条件表と、既存機能の変更箇所を添付します。納品時には同じ表へ確認結果を記録し、変更依頼では該当セルを示します。たとえば、合意済みの再送結果が履歴に残らないなら受入条件との差であり、表になかった履歴検索や手動再送を加えるなら追加候補です。未送信時の扱いを口頭の期待ではなく、発注・検収・追加判定で共通の条件にできます。

費用、期間、契約、法務・税務上の扱いは条件により異なります。記事の確認日とリンク先の一次情報を確認し、個別判断は専門家へご相談ください。

システム開発・発注ガイドへ戻る