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

在庫がゼロから戻った瞬間だけを見つけ出し、同じ通知を二度送らないための判断基準を決める

再入荷判定在庫イベント0→1デバウンス冪等性
読了時間: 10分

通知の質は、送る前の判断でほぼ決まる

「同じ商品の入荷連絡が3回届いた」「通知が来たので開いたら、もう売り切れていた」。再入荷通知への不満として挙がるのは、だいたいこの2つです。どちらもメールの文面を書き直しても解決しません。原因は、その手前にある「在庫が戻ったと判断する部分」にあります。

この記事では、在庫が戻った瞬間をどうやって見つけるのか、その判断をどこまで細かく決めておくべきかを整理します。なおこの仕組みは、まだ作っていません。着手する前に判断基準を書き残しておくための設計メモとして読んでいただければと思います。検知は後ろの工程すべてに影響するので、ここが曖昧なまま先に進むと、配信側や管理画面側で辻褄を合わせる作業がずっと続くことになります。

「ゼロから戻った瞬間」だけを合図にする

「在庫がある」を合図にすると何度も送ってしまう

通知を送る合図を「在庫がある状態」に設定すると、在庫を確認するたびに条件を満たしてしまいます。10個あった商品が9個に減っても、条件としては「在庫がある」まま。確認のたびに通知の候補として拾い上げられ、結果として同じ人に同じ知らせが何度も飛びます。

そこで合図を「在庫がゼロだった商品に、在庫が戻った瞬間」に限定します。前回見たときはゼロ、いま見たら1個以上。この変化が起きたときだけ候補にする。条件をひとつ絞るだけで、二重送信の相談はほとんど起きなくなります。判断の軸は、作り始める前に固定しておくのが一番ラクです。

商品ではなく、色やサイズごとに判断する

同じ商品でも、色やサイズの選択肢ごとに在庫は別々に動きます。ここを商品単位でまとめて判断すると、Mサイズの入荷を待っていた人に、Lサイズが入荷したときの通知が届くことになります。受け取った側からすれば「入荷したと言われたのに買えない」という体験です。

判断の単位は、ユーザーが実際に選んで買う単位、つまり色やサイズなどの選択肢ごとにそろえます。通知の登録を受け付ける時点でも同じ単位で預かっておけば、在庫の変化と登録者を突き合わせる処理も素直な形になります。

再入荷と判断するまでの流れ
前回の在庫数を見る

控えておいた「前に確認したときの数」を取り出す

いまの在庫数を見る

Shopifyからの連絡、または再確認で現在の数を取る

変化を確かめる

前がゼロで、いまが1個以上のときだけ候補にする

送信待ちの一覧へ

候補になったものだけを配信の順番待ちに並べる

図の要点は「いまの在庫数だけを見ない」という一点です。前回の数と見比べて、ゼロから増えた変化が起きたときにだけ先へ進めます。

迷いやすい場面を、作る前に決めておく

残り1個でも知らせるのか

在庫が1個だけ戻った場合に通知するかどうかは、決めておかないと現場で判断が割れます。1個でも送る方針なら、多くの人に知らせが届いて、買えるのは最初の1人だけ。数個そろってから送る方針なら、届く人は減りますが「買えなかった」という声も減ります。

どちらが正解ということはなく、扱う商品の性質次第です。単価が高くて再入荷が珍しい商品なら1個でも送る、日常的に補充される商品なら数個そろってから送る、という分け方もできます。大事なのは、この基準を実装より先に文章にしておくことです。

戻ってすぐ売り切れたときの扱い

在庫が戻った5分後に売り切れた場合、送信待ちに並んでいる通知をそのまま送るのか、止めるのか。これも決めておく必要があります。送れば「開いたら売り切れ」という体験になり、止めれば「入荷したのに知らせが来なかった」という声が出ます。

送る直前にもう一度在庫を確認して、ゼロに戻っていたら送らずに保留する。この扱いにしておけば、少なくとも買えないものを知らせる事態は避けられます。保留したものを在庫が戻ったときに再開するのかどうかも、あわせて決めておきます。

同じ知らせが二度届かないようにする

在庫の連絡は、重複して届く前提で作る

在庫の変化を知らせてくれるWebhook(何かが起きたときに自動で連絡を送る仕組み)は、通信の遅れや再送によって、同じ内容が2回届くことがあります。1回しか来ない前提で作っていると、そのまま2回分の通知が送られてしまいます。

対策は、受け取った連絡それぞれに識別用の番号を持たせて、処理済みのものを記録しておくこと。同じ番号の連絡が再び届いたら、何もせずに終わらせます。処理を二度実行しても結果が変わらない作りにしておく、ということですね。通知の信頼性は文面よりも先に、この部分で決まります。

前回の在庫数を控えておく理由

届いた連絡だけを頼りに判断すると、連絡の到着順が入れ替わったときに誤った判定が起きます。「ゼロになった」という連絡より先に「1個になった」という連絡が届くと、順番どおりに処理していないので、変化を正しく読み取れません。

そこで、いつ・いくつ在庫があったかを自分の側に控えておき、そこと見比べて判断します。判断のもとになった数字が手元に残るので、「なぜこの通知が送られたのか」を後から説明できます。問い合わせが来たときに調べられる状態を作っておくのは、運用に入ってからかなり効いてきます。

数分待ってから、もう一度確認する

在庫が上下する商品への対処

再入荷の直後は、在庫の数が短時間で上下することがあります。仕入れの登録が段階的に入る、キャンセルで一時的に戻る、といった動きです。この揺れの最中に即座に通知を送ると、届いた頃には在庫がない、という状態になりやすいんですよね。

そこで、変化を見つけてもすぐには送らず、数分置いてから在庫を確認し直します。そのときも在庫が残っていれば送信待ちへ、ゼロに戻っていれば見送る。通知が数分遅れる代わりに、「知らせが来たのに買えない」という体験を減らせます。

すぐ送る場合と、数分待つ場合
BEFORE
見つけてすぐ送る

通知は速いが、在庫が上下する商品では「開いたら売り切れ」が起きやすい

AFTER
数分待って確認してから送る

通知は数分遅れるが、届いた時点で買える状態が保たれやすい

少し待ってから在庫を見直すだけで、「知らせは来たけれど買えない」という状況をかなり減らせる、という比較です。

検知の段階では連絡先を持たない

在庫が戻ったかどうかを判断する部分に、メールアドレスなどの連絡先は必要ありません。必要なのは「どの商品の、どの選択肢が、いつゼロから戻ったか」だけです。連絡先を扱うのは、送る相手を確定させる段階からで足ります。

扱う情報を必要な分だけに絞っておくと、個人情報が残る場所そのものが減り、調査や確認の作業でそれに触れる機会も減ります。動作の記録にも連絡先をそのまま書き残さず、一部を伏せた形で追跡できるようにする。この方針も検知の設計と一緒に決めておきます。

まとめ

この段階で価値があるのは、動くコードよりも「誤通知を防ぐための判断基準」を先にそろえておくことです。ゼロから戻った瞬間だけを合図にする、重複した連絡を弾く、数分待って確認し直す、扱う情報を最小限にする。この4つを決めておけば、配信の仕組みと管理画面を作る段階で大きな手戻りを避けられます。

決めた内容をどう配信につなげるかは、続く2記事で解説しています。