このテーマで解決したいこと
「入荷したらメールでお知らせします」という機能は、言葉にすると単純です。ところが実際に動かし始めると、同じ人に何度も通知が飛んだ、送ったはずの通知が届いていない、届いた頃にはもう売り切れていた、といった相談が次々に出てきます。
原因の多くはメールの文面ではなく、その手前の作りにあります。在庫が戻ったことをどう判断するのか、送る相手をどの時点で確定させるのか、送信に失敗したとき誰がどうやって気づくのか。この3つを決めないまま作り始めると、後から直すのに大きな手間がかかります。
このシリーズでは、再入荷通知を「在庫変化の検知」「通知の配信」「管理画面」の3つの層に分けて設計する進め方をまとめました。ここではその全体像を先に示し、それぞれの詳しい話は続く3記事で解説しています。
通知が届くまでの4段階
在庫の変化をShopifyから受け取り、ゼロだった商品に在庫が戻った瞬間を見つける
その商品の入荷連絡を希望していた人を突き合わせ、送信待ちの一覧に並べる
ペースを調整しながら送信し、失敗したものは条件を見て送り直す
送れたもの、失敗したもの、送り直し待ちのものを管理画面に表示する
通知は「在庫の変化に気づく、送る相手を決める、順番に送る、結果を確認する」という4段階で進みます。この4つのどこで止まっているかが一目で分かる状態にしておくと、運用中に問い合わせが来ても調べる場所に迷いません。
情報を4つに分けて持っておく
再入荷通知の仕組みでは、扱う情報を最初から4種類に分けておくと、後から要望が増えても作りが崩れにくくなります。通知を希望した人の登録情報、在庫の記録、送信待ちの一覧、送信した結果の記録。この4つです。
誰が・どの商品の連絡を 希望しているか
いつ・いくつあったか （判断のもとになる値）
いつ・誰に・何を送るか （実行の予定表）
送れたか・失敗したか （送り直しの履歴）
上の2つが「判断に使う情報」、下の2つが「実行の記録」という分け方です。特に、通知を希望した人の一覧と、送信待ちの一覧を別々に持つことが効いてきます。在庫が戻った時点で送る相手を確定させて控えておけるので、その後で配信停止の手続きをした人がいても、どちらの状態が正しいのかを迷わずに判断できます。
シリーズ記事（詳細解説）
設計を3つの層に分けて解説しています。作る順番としても、上から読み進めるのがおすすめです。
再入荷判定（0→1）を安定化させる検知設計
在庫が戻った瞬間だけを見つけ出し、同じ通知を二度送らないための判断基準を整理します。
通知配信パイプライン設計（キュー・レート制御・再送）
送信待ちの一覧を使った配信の組み立て方、送るペースの調整、失敗時の送り直しを解説します。
Back in Stock管理UIの実装ポイント
運用チームが毎日使い続けられる、確認・送り直し・設定変更の画面設計を解説します。
想定している構成
- Shopify（商品と在庫の情報を持っている元データ）
- Webhook（在庫などが変わったときに自動で知らせてくれる仕組み）
- 送信待ちの一覧を管理する仕組み（順番に処理するための置き場所）
- メール配信サービス（実際に通知を送る外部サービス）
- Next.js / Vercel（管理画面の表示と、配信処理を動かす場所）
現時点での実装状況
このリポジトリでは、再入荷通知の配信基盤と管理画面はまだ作っていません。この記事群は、作り始める前に設計の意図を書き残し、開発と運用で同じ前提を共有するためのものです。
通知経由の売上といった成果の数字も、計測できる状態を整えてから追記する前提にしています。どこまでが現状で、どこからが予定なのかを先に書いておくと、読む側にも誤解が生まれません。