再入荷判定（0→1）を安定化させる検知設計

この記事の目的

現時点ではBack in Stock機能のアプリ実装は未着手です。
なので本記事は「実装済みの機能紹介」ではなく、今後着手する際に仕様ブレを防ぐための設計ドキュメントとしてまとめています。

特に検知は後工程へ連鎖しやすいですよね。
判定条件と例外ルールを先に言語化し、運用・開発で同じ前提を共有することを目的にしています。

検知条件の設計方針

0→1判定を中心に据える理由

通知トリガーを「在庫がある状態」ではなく、
「在庫がゼロから復活した瞬間」に限定すると、同じ在庫状態で何度も通知してしまう事故を抑えられます。

商品単位ではなくバリアント単位で判定を持つと、色・サイズ違いの誤通知も減らせます。
実装前にこの判定軸を固定しておくことが、後工程の複雑化を防ぐ最短ルートです。

境界条件を先に定義する意義

「在庫1件のときだけ通知するのか」
「在庫が戻って5分以内に売り切れた場合はどうするか」など、曖昧なまま実装するとチームごとに解釈が割れます。

仕様書段階で境界条件を明文化すれば、開発・QA・運用の判断基準が揃い、問い合わせ時の説明も一貫します。
設計時点で例外ケースを洗い出すことが、結果的に工数削減につながります。

冪等性と再処理対策

イベント重複を前提に設計する

在庫イベントはネットワーク遅延や再送で重複受信する可能性があり、
1回しか来ない前提は危険です。

イベントIDやハッシュをキーに既処理判定を入れる設計にしておくと、誤通知を抑えられます。
通知の信頼性は配信文面よりも先に、この冪等性の層で決まるため、最優先で仕様化するのが安全です。

スナップショット比較の役割

イベントだけで判定すると順序逆転や取りこぼしで誤判定が起きるため、
前回在庫のスナップショットと比較する設計が有効です。

prev=0, current>0 を満たしたときのみ候補化するルールを持てば、重複検知の説明責任も果たしやすくなります。
将来の監査や障害調査に備えて、判定根拠をログとして残せる形で設計しておくことが重要です。

運用を意識した安全設計

在庫揺れへのデバウンス

再入荷直後に在庫が短時間で上下する商品では、即時通知を行うと
「通知されたのに買えない」体験を招きますよね。

数分待って再確認するデバウンス方針を入れることで、誤通知率を抑え、購買体験の信頼を守れます。
通知速度だけを追わず、受信者の実感品質を守る視点でルールを決めるのがコツです。

セキュリティと情報最小化

検知設計の段階でも、個人情報を不要に扱わない設計が重要です。
検知層では顧客連絡先を保持せず、必要な識別子のみで処理を回す構成にすると漏えいリスクを下げられます。

ログにもメールアドレスなどを直接残さず、マスク済み識別子で追跡可能にする方針を定めておくと安心です。
こうしておくと、後から監査しやすく安全な運用につながります。

まとめ

この段階での価値は、実装コードではなく「誤通知を防ぐための判断基準」を合意することです。0→1判定、冪等性、デバウンス、情報最小化を先に定義しておけば、配信基盤と管理UIの実装時に大きな手戻りを避けられます。