売上の「いつもと違う日」を BigQuery で毎朝知らせる前に、過去の半年を判定し直す｜セール・祝日の扱いと知らせる基準の決め方

売上がいつもと違う日を毎朝知らせる仕組みを入れたのに、セールの翌朝にも祝日の翌朝にも通知が届き、いつの間にか誰も開かなくなった。かといって基準を厳しくすれば、決済が止まった日まで黙ってしまわないでしょうか。

この記事は、通販や小売で売上の急な落ち込みや急増に早く気づきたいマーケティング・営業企画の担当者が、通知を入れる前にやっておく準備の話です。過去の半年を「毎朝判定していたら」でやり直して当たりと空振りを数えておけば、月に何回届き、どの日を見逃すかを、通知を入れる前に見積もれます。

図はすべて、BigQuery の導入とデータ分析を支援する当社が、検証用の環境で作りました。売上は架空で、曜日や季節による増減、ゆるやかな伸び、祝日・セール・お盆による増減、不具合や広告の停止などで落ち込んだ日、急に増えた日を、確かめ方を説明するために入れてあります。

線が半年分の日次売上、橙の三角が知らせてほしかった日、帯がセールの日と祝日・お盆で、下の2段の点が2つのやり方がそれぞれ知らせた日です。上の段の、モデルを作らずに毎朝その場で判定する方法は、半年で27日知らせ、当たりは6日でした。残りは空振りで、そのうち13日がセールと祝日の日です。下の段の、祝日とセール日を教えて作ったモデルは24日知らせ、知らせてほしかった7日はすべて当たりました。

月に4〜5日届く通知のうち半分ほどが、開いてみれば「セールの日だった」「祝日だった」で片づくものなら、開かれなくなるのも無理はありません。以下、自社の売上でこの図を作り、通知の数を決め、毎朝の仕組みにするまでを追います。

通知を始める前に、過去の半年を「毎朝判定していたら」でやり直す

毎朝の通知は、前日の売上を、それより前の売上から見込んだ幅と比べ、幅の外に出たら知らせる、という仕組みです。始める前に知りたいのは、この仕組みが自社の売上で月に何回知らせ、そのうち何回が本当に知らせてほしい日か、です。それは、過去の売上で確かめられます。

やり方は、過去の半年の各日について、その日より前の売上だけを使って判定し直すことです。4月1日なら3月31日までの売上で、4月2日なら4月1日までの売上で判定します。半年なら183日分です。1日ずつ手で実行する必要はなく、BigQuery では1回の実行にまとめられます（作り方は後の節に書きます）。

判定し直した結果と突き合わせるために、もう1つ、印の表を作ります。知らせてほしかった日と、知らせなくてよい日の一覧です。知らせてほしかった日は、決済やサイトの不具合、広告の配信停止、在庫切れのように、あとから振り返って「その朝に知りたかった」と言える日です。障害の記録や、広告・在庫の担当の記録から拾います。知らせなくてよい日は、販促カレンダーにあるセールの日や祝日のように、売上が動くことが前から分かっていた日です（以下、セールと祝日を「予定の日」と呼びます）。お盆の休業のように、会社によって扱いが分かれる日もここに入れておきます。

この記事の半年では、知らせてほしかった日は7日です。決済の不具合、商品ページの表示不具合、広告の配信停止、SNS で話題になって注文が急に増えた日、人気商品の在庫切れ（2日続いた）、配送の受付停止です。知らせなくてよい日は、セールが12日（3日間のセールを4回）、祝日が10日、お盆が4日です。

なお、半年分をまとめて1回で判定すると、毎朝1日ずつ判定した場合とは結果が変わります。この半年では、まとめて判定すると知らせたのは23日で、印の無いふつうの日の空振りは2日でした（1日ずつなら27日と6日）。毎朝の通知の見積もりに使うなら、毎朝と同じ条件、つまり前日までの売上だけで1日ずつ判定します。

7日のうち6日は当たった。空振り21日のうち13日は予定の日だった

まず、モデルを作らずに毎朝その場で判定する方法の結果から見ます。AI が付けた「いつもと違う確からしさ」が知らせる基準を超えた日を知らせる仕組みで、基準は BigQuery の既定の 0.95 にしました（決め方は後の節で書きます）。

知らせてほしかった7日のうち、当たったのは6日です。見逃したのは、在庫切れが2日続いた2日目（8月19日）で、確からしさは 0.939 と、基準の 0.95 にわずかに届きませんでした。1日目（8月18日）の分は翌朝に知らせているので、在庫切れには8月19日の朝に気づけたことになります。

空振りは21日ありました。内訳は、セールの日が9日、祝日が4日、お盆が2日、印の表に何も無いふつうの日が6日です。ふつうの日の6日は、売上が見込みの幅を下に外れた日が3日、上に外れた日が3日でした。

空振りのうち13日は、予定の日、つまり売上が動くと前から分かっていた日です。お盆の2日を足すと15日になります。この方法は、前日までの売上の動きから見込むので、販促カレンダーに書いてあることは知りません。空振りを減らすには、知らせる基準をいじる前に、予定の日の扱いを決めます。

予定の日の扱いは2通り。知らせる前に外すか、モデルに教えるか

1つ目は、知らせる前に印の表と突き合わせ、予定の日は知らせないことにするやり方です。モデルを作らずに判定する BigQuery の関数には、祝日やセール日を渡す指定がありません（公式ドキュメントで指定できる項目に無い）。そのため、判定のあとで外します。外すと、知らせた日は27日から14日になりました。残ったのは、当たり6日、お盆2日、ふつうの日6日です。ここでは外す対象を予定の日（セールと祝日）にしたので、お盆は残りました。お盆の落ち込みも知らせなくてよいなら、外す対象に加えます。

このやり方には代償があります。外した日に本当の落ち込みが重なると、それも知らせません。たとえばセールの日に決済が止まっても、その日の通知は来ません。外した日は、通知とは別に、誰がどう売上を確かめるかを決めておきます。

2つ目は、モデルに教えるやり方です。BigQuery の時系列モデルは、作るときに国の祝日（日本を指定できる）と、自社のセールのような独自の日の一覧を渡せます。祝日を扱えるのは、日次か週次で、1年より長いデータのときだけ、と公式ドキュメントにあります。ここでは、2025年1月から2026年3月までの15か月の売上と、その15か月と判定する半年に開いたセールの日を渡してモデルを1回作り、4月からの半年を判定しました。同じ種類のモデルで売上そのものを予測し、前年同月の売上に伸び率を掛けるやり方と並べて実績と比べた結果は、売上予測ツールの選び方の記事に書いています。

結果は、知らせたのが24日で、知らせてほしかった7日はすべて当たりました。予定の日の空振りは6日、お盆は0日です。セール・祝日・お盆の日ごとに、2つのやり方が知らせたかを並べたのが次の図です。

教えたモデルは、お盆の4日（13〜16日）を1日も知らせていません。お盆は日本の祝日ではありませんが、BigQuery が日本向けに持っている祝日の一覧に、8月15日とその前後1日のお盆が入っていました。この一覧には、ほかに母の日やクリスマス、米国の感謝祭や夏時間の切り替えの日まで入っています。反対に、振替休日と国民の休日の行はありませんでした。ただ、5月6日と9月22日にも、近くの祝日などの効果がモデルの中で見込まれていて、空振りにはなっていません。自社の印の表と、この一覧を一度突き合わせておくと、何を教えたことになるのかが分かります。

セールは、モデルを作った3月31日までにも開いていたセール（父の日・夏・秋）の9日のうち、知らせたのは2日でした。一方、それまで一度も開いていない大型連休前セールは、一覧に入れて教えたのに、3日とも知らせています。モデルが見込んだ効果を日ごとに見ると、この3日の効果は0で、このセールの効果の列そのものがありませんでした。作った時点までの売上にこのセールが無く、効果の大きさを見込む材料が無かったと考えられます。初めてのセールの日は、教えるだけでなく、1つ目のやり方で外しておきます。

ただし、教えたモデルにも弱いところがありました。印の無いふつうの日の空振りが11日と、モデルを作らない方法の6日より多く、すべて4〜6月で、そのうち10日は売上が見込みより下がった日です。この売上には、6月ごろに低く12月に高くなる季節の波を入れてあります。ところが、このモデルが売上の中に見つけた波は週の波だけで、年の中の波は見込みに入っていませんでした。拾えなかった理由がデータの長さ（15か月）なのかどうかは、確かめていません。予定の日を外すと、知らせた日は18日で、モデルを作らない方法（14日）より多くなりました。

祝日とセール日を教えずに作ったモデルでも、同じ半年を判定しました。知らせたのは37日で、当たりは3日、見逃しが4日ありました。この売上では、教えるかどうかで、当たりの数まで変わっています。

知らせる基準は、見逃してよい落ち込みを先に決めてから選ぶ

知らせる基準（しきい値）は、0以上1未満の値です。値を上げると、見込みの幅が広がり、知らせる日は減ります。どちらの方法でも、基準を 0.90・0.95・0.99 の3通りに変えて、同じ半年を判定し直しました。

基準を 0.90 に下げると、どちらの方法も知らせてほしかった7日をすべて知らせますが、知らせた日は40日と38日に増えます。半年でこの数なら、月に6日以上です。0.99 に上げ、予定の日を外すと、モデルを作らない方法は8日、教えたモデルは10日まで減りました。見逃したのは、どちらも在庫切れの2日のうちの1日だけです（モデルを作らない方法は2日目、教えたモデルは1日目）。

ここで決めるのは、どの見逃しなら許せるかです。2日続いた落ち込みなら、どちらか1日の分に知らせが来れば、出来事には気づけます。出来事の単位で数えると、0.99 でも、6つの出来事のすべてに、少なくとも1日は知らせが来ていました。「2日続く落ち込みは、どちらかの日の分で気づければよい」と決めるなら、この半年では、モデルを作らない方法に予定の日を外す処理を足し、基準を 0.99 にすると、知らせるのは半年で8日、そのうち6日が当たりです。反対に、1日で戻る小さな落ち込みも翌朝に知りたいなら、基準は下げ、空振りの数を受け入れます。

モデルは作り直すたびに幅が変わる。作り直す間隔を決めたら、基準も決め直す

教えたモデルは、3月31日までの売上で1回作ったきりで、半年を判定しました。先のことほど見込みは不確かになるので、見込みの幅は日を追って広がります。1か月の平均で、4月は 265,828 円、9月は 530,511 円と、約2倍になりました。幅が広いほど、同じ落ち込みでも幅の内に収まりやすくなります。

そこで、同じ設定のモデルを毎月1日に作り直し、その月を判定する形も試しました。9月の幅の平均は 293,073 円と狭いままで、知らせてほしかった7日はすべて当たりましたが、知らせた日は48日と、1回作ったときの24日の2倍になりました。幅が狭くなった分、ふつうの日の空振りが30日に増えています。作り直すほど通知が減る、とは限らないということです。

作り直す間隔を変えると、幅が変わり、知らせる日の数も変わります。間隔を決めたら、その間隔で過去の半年をやり直し、基準を決め直します。モデルを作らずに毎朝その場で判定する方法には、この作り直しがありません。毎朝、前日までの売上をそのまま使います。なお、モデルを作る作業は、判定より費用の単価が高く設定されています（金額は作り方の節に書きます）。

毎朝の仕組みは、知らせた日を残す表と、朝のクエリ1本で作る

基準と予定の日の扱いが決まったら、毎朝の仕組みにします。作るものは2つです。1つは、判定の結果を1日1行で残す表です。もう1つは、前日の売上を判定し、印の表と突き合わせて、その表に書き込む朝のクエリです。通知は、この表で「知らせる」になった行だけを、メールやチャットで送ります。通知の送り先との連携は、この記事では試していません。

表に残すのは、判定した日、売上、見込みの下限と上限、確からしさ、いつもと違うか、予定の日の名前（セール・祝日）、知らせるか、状態、判定した時刻です。朝のクエリを、配送の受付停止の日、秋のセールの日、ふつうの日、売上がまだ入っていない日の4つの朝として実行すると、表には次のように残りました（モデルを作らない方法、基準 0.95）。

秋のセールの日は、いつもと違うと判定されましたが、印の表で知らせなくてよい日にしてあるので「知らせない」になっています。前日の売上がまだ入っていない朝も、クエリはエラーにならずに終わりました。判定の結果だけを書き込む作りにすると、その朝は表に何も残らず、通知が来ないことにも気づけません。そこで、判定した日の行は売上が無くても作り、その場合は状態を「no_data」にして残すようにしました。売上の取り込みが遅れた朝に、通知が来なかったのか、判定できなかったのかを区別するためです。

同じ朝にクエリが2回動いたときのことも確かめました。表に追記する形（INSERT）で同じ日を2回実行すると、その日の行が2行になりました。判定した日ごとに、行があれば上書きし、無ければ追加する形（MERGE）なら、2回実行しても1行のままです。毎朝の自動実行には、BigQuery のスケジュールされたクエリが使えます。公式ドキュメントには、ちょうど9時00分のような正時に設定すると複数回動くことがあり、追記する形ではデータが重複しうるので、8時58分のように正時を外すよう書かれています。既定の頻度は毎日で、日本時間で入れた時刻は UTC に変換されます。この記事では、スケジュールの作成と、決まった時刻での実行は試していません。

朝のクエリは、1回あたり4〜9秒で終わり、課金は30 MB でした（東京の単価で1回 約0.0002米ドル、無料枠を引く前）。クエリは次のとおりです。判定するのは前日（日本時間）で、表の名前は置き換えています。planned_days は、印の表のうち知らせなくてよい日（セール・祝日）の日付と名前だけを入れた表です。上の4つの朝は日付を固定して実行しましたが、このクエリも書いてあるとおりの形で1回実行し、前日の分（売上の無い日）は状態が「no_data」の行になること、日付だけ9月8日に替えると上の表と同じ行になることを確かめました。

MERGE mydataset.sales_alerts AS a
USING (
  WITH target AS (SELECT DATE_SUB(CURRENT_DATE('Asia/Tokyo'), INTERVAL 1 DAY) AS check_day),
  det AS (
    SELECT * FROM AI.DETECT_ANOMALIES(
      (SELECT d, sales FROM mydataset.daily_sales WHERE d < (SELECT check_day FROM target)),
      (SELECT d, sales FROM mydataset.daily_sales WHERE d = (SELECT check_day FROM target)),
      data_col => 'sales', timestamp_col => 'd', anomaly_prob_threshold => 0.95)),
  plan AS (SELECT d, STRING_AGG(label, '・') AS planned FROM mydataset.planned_days GROUP BY d)
  SELECT t.check_day, det.time_series_data AS sales, det.lower_bound, det.upper_bound, det.anomaly_probability, det.is_anomaly,
    plan.planned,
    IFNULL(det.is_anomaly, FALSE) AND plan.planned IS NULL AS notify,
    CASE WHEN det.time_series_timestamp IS NULL THEN 'no_data' WHEN det.ai_detect_anomalies_status != '' THEN det.ai_detect_anomalies_status ELSE 'ok' END AS status,
    CURRENT_TIMESTAMP() AS checked_at
  FROM target AS t LEFT JOIN det ON DATE(det.time_series_timestamp) = t.check_day
  LEFT JOIN plan ON plan.d = t.check_day
) AS s
ON a.check_day = s.check_day
WHEN MATCHED THEN UPDATE SET sales = s.sales, lower_bound = s.lower_bound, upper_bound = s.upper_bound, anomaly_probability = s.anomaly_probability,
  is_anomaly = s.is_anomaly, planned = s.planned, notify = s.notify, status = s.status, checked_at = s.checked_at
WHEN NOT MATCHED THEN INSERT ROW;

この図の作り方と、かかった費用

図は、当社の検証用の BigQuery（東京のデータセット）に、2025年1月1日から2026年9月30日までの638日分の日次売上と印の表を入れて作りました。判定し直したのは2026年4月1日から9月30日までの183日です。

モデルを作らない方法は AI.DETECT_ANOMALIES 関数（既定の TimesFM 2.5 を使う）です。毎朝1日ずつの判定は、判定する日を系列の名前にして（id_cols）、「その日より前の全部の日」を履歴、「その日」を判定の対象にした183本の系列を作り、1回の実行で判定しました。1回の実行は74〜99秒かかりました。基準ごとに3回実行しています。この節のコードも、表の名前を置き換え、基準を残すための列を省いています。

SELECT * FROM AI.DETECT_ANOMALIES(
  (SELECT FORMAT_DATE('%F', c.d) AS check_day, s.d, s.sales
     FROM mydataset.daily_sales AS c JOIN mydataset.daily_sales AS s ON s.d < c.d
     WHERE c.d BETWEEN DATE '2026-04-01' AND DATE '2026-09-30'),
  (SELECT FORMAT_DATE('%F', d) AS check_day, d, sales FROM mydataset.daily_sales
     WHERE d BETWEEN DATE '2026-04-01' AND DATE '2026-09-30'),
  data_col => 'sales', timestamp_col => 'd', id_cols => ['check_day'], anomaly_prob_threshold => 0.95);

祝日とセール日を教えたモデルは、BigQuery ML の時系列モデル（ARIMA_PLUS）です。作るときに、日本の祝日（HOLIDAY_REGION を JP）と、セールの日の一覧（custom_holiday）を渡しました。セールは3日間なので、真ん中の日を中心に前後1日を効果の幅にしています（前後の日数は1以上、と決まっているため）。sale_days は、セールの日付（d）とセールの名前（event）の表です。判定は ML.DETECT_ANOMALIES 関数に、知らせる基準と4月からの売上を渡しました。モデルを作ったあとの新しい日を判定するときは、基準の指定が必要です（公式ドキュメント）。

CREATE OR REPLACE MODEL mydataset.sales_arima_holiday
OPTIONS(model_type = 'ARIMA_PLUS', time_series_timestamp_col = 'd', time_series_data_col = 'sales',
        data_frequency = 'DAILY', horizon = 200, holiday_region = 'JP') AS (
  training_data AS (SELECT d, sales FROM mydataset.daily_sales WHERE d < DATE '2026-04-01'),
  custom_holiday AS (
    SELECT 'JP' AS region, event AS holiday_name, DATE_ADD(MIN(d), INTERVAL 1 DAY) AS primary_date,
           1 AS preholiday_days, 1 AS postholiday_days
    FROM mydataset.sale_days GROUP BY event, EXTRACT(YEAR FROM d))
);

比べるために、祝日とセール日を教えないモデルと、毎月1日に作り直すモデル（6回）も作りました。モデルの作成は合わせて8回、1回5〜9秒です。BigQuery ML の単価は、東京のオンデマンドで、時系列モデルの作成が1 TiB あたり375米ドル、判定が7.50米ドルです（2026年10月時点の価格ページ）。判定は毎月の無料枠（1 TiB）の対象と書かれていますが、モデルの作成は無料枠の対象と書かれていません。ただ、日次の売上1本の表は小さく、作成1回あたりの課金は10 MB か20 MB で、8回合わせて0.054米ドル（無料枠を引く前）でした。店舗や商品ごとに何百本もの売上を作り直すなら、読む量に応じて費用は増えるので、先に処理量を確かめます。表の作成・判定・削除まで含めると55本の処理（表の読み込みを除く）で、課金の対象になった量は合わせて約740 MB、東京の単価で換算して0.058米ドル（無料枠を引く前）でした。毎朝の仕組みの節で書いた、朝のクエリを載せた形のまま確かめた実行（7本、約70 MB）を足しても、0.058米ドルです。作った表とモデルは、確かめたあとに削除しました。

誰も開かない通知を立て直す前に、過去の半年に印を付ける

誰も開かなくなった通知を立て直すとき、基準だけを厳しくすると、今度は肝心な日に黙るかもしれません。手を入れる前に、過去の半年の日次売上を手元に出し、知らせてほしかった日（障害・広告の停止・在庫切れの記録）と、知らせなくてよい日（販促カレンダーのセール、祝日、休業）に印を付けてください。その印の表が、通知を入れ直す前に当たりと空振りを数えるための物差しになります。

当社は、この印の表づくりから、BigQuery で毎朝の判定を動かし、知らせた日を表に残すところまでを、BigQuery の導入支援としてお手伝いしています。