Media > AI活用ユースケース > 生産 > 洋菓子店が販売の記録・曜日・天気・催しから Python で翌日の生菓子の品目ごとの製造の数を予測し、売り切れと売れ残りの釣り合う仕込みの案を出す

洋菓子店が販売の記録・曜日・天気・催しから Python で翌日の生菓子の品目ごとの製造の数を予測し、売り切れと売れ残りの釣り合う仕込みの案を出す

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

洋菓子店のレジの記録と曜日・天気・催しから、Python で翌日の生菓子の品目ごとの売れる数を、ばらつきの幅とともに予測します。品目ごとの売価と原価から「どこまで作るか」の線を決めて製造の数の案を出し、前日に焼く台の数もそろえます。

サマリー
連携・自動化
Python
対象業界
小売/飲食
対象部門
生産
対象業務
集計・分析
主な課題
人手が足りない/判断に時間がかかる/属人化している
AIで行う処理
予測
主な効果
判断支援/属人化解消/機会損失防止
導入難易度
★★★★☆
実装レベル
本格構成
費用感
個別開発(大)
人間の確認
条件付き
現在工数
12h/月
AI導入後
4h/月
想定削減
67%
年間削減
96h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 閉店後、販売の責任者が品目ごとの売れ残りの数と、売り切れた品目の売り切れた時刻をメモする
  2. オーナーが、ノートで前年の同じ曜日と先週の同じ曜日の品目ごとの製造の数と売れ残りを探す
  3. 週間天気予報と、翌日の行事・近くの催し(小学校の運動会、地域の祭り、近くの病院の見舞いの客)を見る
  4. 予約の台帳で、翌日のホールケーキの予約と、ピースケーキの取り置きを確かめる
  5. 品目ごとの仕上げの数を決め、黒板に書く
  6. 前日の14時ごろには、翌日の台の数を勘で決めて焼いておく(閉店後の決定と合わないことがある)
  7. 翌日の昼に売れ行きが見立てと違えば、オーナーが追加で仕上げるかを決める
導入後(After)
  1. 人販売の責任者が、閉店時に品目ごとの売れ残りの数をレジの画面か表に入れる(売り切れた品目は0と入れる)
  2. 人事務か販売の責任者が、翌週の行事と近くの催し、週間天気予報の日ごとの天気と最高気温を予定のシートに入れる
  3. 自動前日の13時に、Python がレジの記録、製造と売れ残りの記録、予約の台帳、予定のシートを読み込み、翌日の台の数の案を出す
  4. 自動閉店後の19時半に、その日の売れ方を足してもう一度予測し、翌日の品目ごとの仕上げの数の案を出す
  5. 自動品目ごとの売価と原価から決めた線で、製造の数を選び、仕上げの手の上限に収まるかを確かめる
  6. 人オーナーが印の付いた品目を中心に見て、仕上げの数を決め、黒板に書く
  7. 人翌日の昼、売れ行きが案と大きく違う品目だけ、オーナーが追加で仕上げるかを決める
各工程の詳しい説明を読む
  1. 閉店後、販売の責任者が品目ごとの売れ残りの数と、売り切れた品目の売り切れた時刻をメモする
  2. オーナーが、ノートで前年の同じ曜日と先週の同じ曜日の品目ごとの製造の数と売れ残りを探す
  3. 週間天気予報と、翌日の行事・近くの催し(小学校の運動会、地域の祭り、近くの病院の見舞いの客)を見る
  4. 予約の台帳で、翌日のホールケーキの予約と、ピースケーキの取り置きを確かめる
  5. 品目ごとの仕上げの数を決め、黒板に書く
  6. 前日の14時ごろには、翌日の台の数を勘で決めて焼いておく(閉店後の決定と合わないことがある)
  7. 翌日の昼に売れ行きが見立てと違えば、オーナーが追加で仕上げるかを決める

(a)売り切れと売れ残りが同じ週に出る。 晴れた土曜にショートケーキが14時に売り切れ、雨の火曜にモンブランが8個残る、ということが同じ週に起きます。売り切れた日は、閉店までに来た客が「もう無いのか」と帰ります。 売れ残りは、店の決まりで廃棄するか、従業員が持ち帰ります。

(b)台の数と仕上げの数が合わない。 6番で前日の昼に焼いた台の数は、閉店後の決定より前に決まります。台が足りなければ仕上げの数を減らすしかなく、台が余れば捨てます。 2つの決定がばらばらの時刻に、ばらばらの見立てで行われています。

(c)決め方がオーナーの頭の中にある。 どの品目が雨に弱いか、母の日の前日にどれが動くかは、オーナーの経験の中にあります。オーナーが講習会や仕入の旅に出る日は、職人の責任者が前年のノートの写しで決め、大きく外れることがあります。

(d)売り切れた日の数を「売れた数」として覚えている。 ノートに残るのは製造の数と売れ残りの数で、売り切れた日は「全部売れた」としか書かれません。 何時に売り切れたかを残していないので、本当はあと何個売れたのかが、翌年には分かりません。

  1. 【人】 販売の責任者が、閉店時に品目ごとの売れ残りの数をレジの画面か表に入れる(売り切れた品目は0と入れる)
  2. 【人】 事務か販売の責任者が、翌週の行事と近くの催し、週間天気予報の日ごとの天気と最高気温を予定のシートに入れる
  3. 【自動】 前日の13時に、Python がレジの記録、製造と売れ残りの記録、予約の台帳、予定のシートを読み込み、翌日の台の数の案を出す
  4. 【自動】 閉店後の19時半に、その日の売れ方を足してもう一度予測し、翌日の品目ごとの仕上げの数の案を出す
  5. 【自動】 品目ごとの売価と原価から決めた線で、製造の数を選び、仕上げの手の上限に収まるかを確かめる
  6. 【人】 オーナーが印の付いた品目を中心に見て、仕上げの数を決め、黒板に書く
  7. 【人】 翌日の昼、売れ行きが案と大きく違う品目だけ、オーナーが追加で仕上げるかを決める

6番目で決めるのはオーナーです。 モデルが出すのは数の案で、翌日の果物の入り方、職人の休み、試作の品目を知っているオーナーが決めます。

台の数を前日の13時に、仕上げの数を閉店後に出すのは、第3章の(b)を埋めるためです。 2つの案は同じモデルから出るので、台の数は仕上げの数の上振れに合わせて少し多めに出します。 台が少し余っても、焼き菓子やカフェのデザートに回せる品目があれば捨てずに済みます。

02今回想定するシステム構成

構成図
レジの記録(品目ごとの売れた時刻と数)+ 製造と売れ残りの記録
+ 予約の台帳(ホールケーキ・取り置き)
+ 過去の天気(気象庁の過去の気象データ)+ 祝日(内閣府の CSV)
+ 行事・催し・天気予報(予定のシート)+ 品目の表(売価・原価・台の種類)
   │
   ▼【トリガー】前日の13時(台の数)、閉店後の19時半(仕上げの数)
Python(pandas)
   ├──▶ 売り切れた日の売れたはずの数を、時刻ごとの売れ方から見積もる
   ▼
scikit-learn(HistGradientBoostingRegressor、ポアソン損失)
   │   翌日の品目ごとの売れる数の見込み(平均)
   ▼
SciPy(負の二項分布)
   │   品目ごとのばらつきの幅と、売価と原価から決めた線での製造の数
   ▼
Python ── 台の種類ごとの数、仕上げの手の上限の確認
   ▼
【人】オーナーが仕上げの数を決め、黒板に書く
役割想定する製品代替候補
実行環境Python(pandas・scikit-learn・SciPy)R
処理エンジンscikit-learn の HistGradientBoostingRegressor(ポアソン損失)LightGBM、statsmodels
集計Python(SciPy の負の二項分布での製造の数、台の数と仕上げの手の上限の換算)スプレッドシートの計算式
保管Google スプレッドシート(予定、品目の表、決めた製造の数の記録)-

新しく足すのは、Python の処理と、予定のシート、品目の表です。 レジと予約の台帳はこれまでどおりで、この構成は黒板も仕入の発注も書き換えません。 出すのは品目ごとの案です。

予測のエンジンに HistGradientBoostingRegressor を選んだのは、売れる数を数として扱えるからです。 売れる数は0以上の数で、loss="poisson"(目的の値が0以上であることが要る)が使えます。品目、曜日、行事は pandas の Categorical の列にしておけば、categorical_features の既定の 'from_dtype' でカテゴリとして扱われます。18品目を1本のモデルで学習し、品目ごとの癖はカテゴリの分岐で拾わせます。

幅を SciPy の負の二項分布で出すのは、品目ごとに違う線で製造の数を選ぶためです。 分位点のモデルを品目ごとの線の数だけ作ると、線を変えるたびに学習し直しになります。平均の見込みに、品目ごとのばらつきの大きさを組み合わせて分布を作れば、線を変えても学習は要りません。 SciPy の nbinom は、平均とばらつきから引数を決める書き方がページに示され、分位から数を返す ppf を持っています。

生成AIは使いません。 予測は数の問題で、オーナーに渡すのは品目ごとの表です。

03どうやって実装するのか

Step1

処理の起点を決める

前日の13時と、閉店後の19時半の2回動かします。 13時は台を焼き始める前で、職人の責任者が台の数の案を見てから、午後の焼成の段取りを組める時刻です。19時半は閉店して売れ残りの数が入った後で、その日の売れ方まで足した見込みで、翌朝の仕上げの数を決められる時刻です。事務所のパソコンの定時実行の仕組み(Windows ならタスク スケジューラ)で Python のスクリプトを起動します。

閉店後の回は、売れ残りの数が入ったことを確かめてから動かします。 売れ残りの表に当日の行が無ければ、10分おきに3回まで待ち、それでも無ければ「当日の売れ残り未入力」の印を付けて案を出します。

月に1回、モデルを作り直します。 定休日の前の閉店後に先月までの記録で学習し直し、作り直す前と後で、先月の当たり方を比べた結果を残します。悪くなっていれば、前のモデルのまま使います。

定休日の前の日は、翌々日の分を出します。 定休日の翌日の台は定休日に焼けないので、定休日の前日の13時に、2日先の台の数の案を出します。

Step2

入力データを集める

データ中身取得元
販売品目ごとの売れた時刻と数(1回の会計ごと)レジの記録(CSV)
製造と売れ残り日ごとの品目ごとの製造の数、売れ残りの数、売り切れた時刻製造の記録の表
予約ホールケーキの予約、ピースケーキの取り置き(受け取りの日と品目と数)予約の台帳
過去の天気日ごとの降水量・最高気温など気象庁の過去の気象データ・ダウンロード(CSV)
祝日国民の祝日の日付内閣府の祝日の CSV
予定季節の行事、近くの催し、天気予報の天気と最高気温、臨時の営業時間予定のシート
品目の表品目、売価、1個あたりの原価、台の種類と1台から取れる個数、仕上げの手間(分)、ショーケースの段の上限、販売の期間品目の表(オーナーと決める)

質を決めるのは、売り切れた時刻の記録です。 ノートに「全部売れた」としか残っていない日は、本当はあと何個売れたのかが分かりません。レジの記録の最後に売れた時刻が分かれば、多くの日は後からでも見積もれます。 閉店の1時間以上前に最後の1個が売れていれば、売り切れた日として扱います。

品目の表の原価は、材料費だけで足ります。 作りすぎた1個で失うのは、その1個に使った材料で、職人の手間は作っても作らなくても同じ朝の時間にかかっているからです。 線の決め方は「AIに何をさせるのか」で示します。

天気は日ごとの値を使います。 気象庁の過去の気象データ・ダウンロードでは、地点と項目と期間を選んで観測値を CSV で落とせるので、店の近くの観測地点の日ごとの降水量と最高気温を取ります。

Step3

データの取得方法を決める

取るものどこから何に使うか
販売レジの管理画面から毎日閉店後に CSV を書き出し、決まったフォルダに置く日ごとの品目の売れた数と、時刻ごとの売れ方
製造と売れ残り製造の記録の表を CSV で書き出して読む製造の数、売れ残り、売り切れた時刻
予約予約の台帳を CSV で書き出して読む店頭の分から外す数
過去の天気月に1回、気象庁のページから CSV を落とす降水と気温の項目
祝日年に1回、内閣府の CSV を入れ替える祝日の印

レジの書き出しは、閉店の処理が終わってから行います。 閉店の処理の前に書き出すと、最後の1時間の会計が入りません。書き出しの時刻を表の上に印字し、閉店の時刻より前なら案に印を付けます。

気象庁の CSV には、値の列のほかに品質情報や均質番号の列が並びます。 値の列だけを名前で選んで読みます。祝日の CSV は、翌年の分が前の年の2月に載るとされているので、年に1回、2月に入れ替えます。

予約の台帳には、客の名前と電話番号が含まれます。 読み込むときに、受け取りの日と品目と数以外の列を捨てます。予測に要るのは数だけです。

Step4

AIへ渡す前に整形する

  1. 日ごと・品目ごとにそろえる … レジの会計を、営業日ごと・品目ごとの売れた数に合わせます。取り置きの受け取りは店頭の売れた数から外します
  2. 売り切れた日を見つける … 売れ残りが0で、最後に売れた時刻が閉店の1時間以上前の日に印を付けます
  3. 時刻ごとの売れ方を作る … 売り切れなかった日から、品目・曜日・季節ごとに「何時までに1日の何割が売れるか」の表を作ります
  4. 売れたはずの数を見積もる … 売り切れた日は、売れた数を、売り切れた時刻までに売れる割合で割って見積もります。見積もった値は別の列に持ち、元の売れた数は残します
  5. 販売していない日を外す … 季節の品目の販売期間の外、材料が入らず作らなかった日は、0ではなく行ごと外します
  6. 項目を作る … 品目、曜日、祝日とその前日、連休の何日目か、月、降水の有無と量、最高気温、季節の行事、近くの催し、前年の同じ週の同じ曜日の売れた数、直近4週の同じ曜日の平均、閉店後の回だけ当日の売れた数
  7. 品目・曜日・行事を Categorical にする … pandas の Categorical の型にしておきます

4番目が、この構成の肝です。 14時に売り切れた土曜のショートケーキの売れた数をそのまま学習すると、モデルは「土曜のショートは24個」と覚え、また24個作って14時に売り切れます。 土曜に14時までに1日の6割が売れるなら、24個は40個ほどの欲しかった客のうちの24個です。ただし見積もりは推計なので、月に1回の当たり方の確認で、見積もった日だけの外れ方を分けて見ます。

5番目で作らなかった日を0にしないのは、0の日を学習すると、その季節の見込みが実際より少なく出るからです。 栗が入らずモンブランを作らなかった日を「売れなかった日」と覚えると、秋の雨の日のモンブランを低く見込みます。

Step5

AIに処理させる

させるのは、翌日の品目ごとの店頭の売れる数の平均の見込みを出すことだけです。 幅と製造の数は、その見込みと品目ごとのばらつきから計算で出します。

段階中身使うもの
平均の見込み品目ごとの翌日の売れる数の平均HistGradientBoostingRegressor(loss="poisson")
ばらつきの大きさ品目ごとに、過去の見込みと実績の外れから、平均に対する散らばりを出す過去3か月の外れ
製造の数品目ごとの線(分位)で、分布から数を選ぶSciPy の nbinom.ppf

品目ごとの線は、売価と原価から決めます。 作り足りなかった1個で失うのは「売価−原価」の粗利、作りすぎた1個で失うのは原価です。線を「粗利 ÷(粗利+原価)」、つまり「粗利 ÷ 売価」に置くと、捨てる損と取り逃しの損の合計が小さくなるという、古くから使われている考え方です。

品目売価原価線(粗利÷売価)作り方の傾向
ショートケーキ520円180円0.65平均より多めに作る
季節のタルト(果物が高い時期)680円360円0.47平均よりやや少なめ
プリン380円90円0.76多めに作る

オーナーが線を手で上げ下げできるようにしておきます。 看板の品目は、売り切れて客をがっかりさせることのほうが重いので、粗利の計算より高い線にしてかまいません。線を変えても学習のやり直しは要らないのが、分布で出す作りの利点です。

仕上げの手の上限も見ます。 品目ごとの製造の数に仕上げの手間(分)を掛けて足し、朝の仕上げの時間に収まらなければ、線が低い品目から順に1個ずつ減らした案を出し、印を付けます。

させないこと理由
品目の入れ替えと新しい品目の数記録が無い。オーナーが決める
原材料の仕入の発注果物の入り方と値段を知る人が決める
衛生と消費期限の管理店の衛生の決まりで行う
売れ残りの扱い(値引き・廃棄・持ち帰り)店の決まり。予測に合わせて変えない
天気予報そのもの事務が予報を見て入れる

3行目は、とくに気を付けてください。 多めに作る線にした品目でも、売れ残りを翌日に回して売る判断に、この構成を使わないでください。 生菓子の扱いは、店の衛生の決まりで行います。

Step6

指示内容を固定する

生成AIを使わないので、プロンプトはありません。 かわりに、平均の見込みと製造の数の出し方の中身を示します。

from sklearn.ensemble import HistGradientBoostingRegressor
from scipy.stats import nbinom

FEATURES = ["item", "weekday", "is_holiday", "is_pre_holiday", "holiday_seq",
            "month", "rain_mm", "temp_max", "season_event", "local_event",
            "last_year_same", "recent4w_same_mean"]
# item・weekday・month・season_event・local_event は pandas の Categorical にしておく

mean_model = HistGradientBoostingRegressor(
    loss="poisson", max_iter=500, learning_rate=0.05,
    early_stopping=True, validation_fraction=0.15, random_state=0)
y = train["demand_est"].fillna(train["sold"])    # 売り切れた日は見積もった値
mean_model.fit(train[FEATURES], y)

def make_qty(mu, alpha, line):
    """平均 mu、ばらつき alpha(分散 = mu + alpha*mu^2)、線 line から製造の数"""
    if alpha <= 0:                         # ばらつきが小さすぎる品目はポアソンに近い扱い
        alpha = 1e-3
    var = mu + alpha * mu ** 2
    p = mu / var
    n = mu ** 2 / (var - mu)
    return int(nbinom.ppf(line, n, p))

n と p の出し方は、SciPy のページに示された、平均とばらつきからの書き方に合わせています。 p = μ/σ²、n = μ²/(σ² − μ) で、分散が平均より大きいときにしか使えません。 そのため、過去の外れから出した alpha が0以下になる品目は、小さな正の値に置き換えます。

alpha は品目ごとに、過去3か月の外れから出します。 品目ごとに「(実績−見込み)の2乗 − 見込み」を「見込みの2乗」で割って平均した値が目安になります。季節の品目は販売の期間が短く、外れの数が少ないので、同じ台の種類の品目の値を借ります。

early_stopping を明示的に有効にしているのは、既定の 'auto' では学習の行が10,000を超えるときなどにしか有効にならないからです。 18品目の3年分は1万行を少し超える程度で、品目を減らした店では既定のままだと早期の打ち切りが働きません。

新しい品目は、学習のときに無かったカテゴリになります。 公式の解説では、学習のときに見なかったカテゴリは予測のときに欠けた値として扱われるとされています。新しい品目の見込みはあてにならないので、表に「新しい品目:オーナーが決める」と出します。

Step7

出力形式を固定する

オーナーに渡すのは、次の表です。 閉店後に印刷して、黒板に書く前に見ることを前提にします。

【明日(11月14日・土)の生菓子の製造の案(金曜 19:34 作成/レジの書き出し 19:21)】

品目予約・取り置き店頭の見込み(平均)幅(2割〜8割)線製造の案台印
ショートケーキ431.626〜370.6539スポンジ 5台-
季節のタルト014.210〜180.4714タルト台 2台-
モンブラン212.88〜170.6016-黄(昨日の売れ残り5)
新作の和栗ロール0----ロール生地 1枚赤(新しい品目)

製造の案は、店頭の見込みから出した数に、予約と取り置きの数を足したものです。 予約の分は予測に入れていないので、二重には数えません。台の列は、製造の案を台の種類ごとに合わせ、1台から取れる個数で割って切り上げた数です。

表の一番下には、仕上げの手の合計を出します。 製造の案の仕上げの手間の合計と、翌朝の仕上げの時間を並べ、超えていれば線の低い品目から減らした案を並べます。 あわせて、初めての催しには「催しの上乗せ未定」、予定のシートが空の日には「予定未入力」を出します。

機械で読む用には、同じ内容を CSV でも残します。 列は、日、品目、予約の数、平均、幅、線、製造の案、台の数、印、モデルを作った日付です。翌日に実績と並べて当たり方を見るのは、この CSV です。

Step8

システムへ連携する

つなぎ先方式内容
レジ毎日閉店後、管理画面から CSV を書き出してフォルダに置く品目ごとの売れた時刻と数
製造と売れ残りの記録表を CSV で書き出して読む製造の数、売れ残り、売り切れた時刻
予約の台帳表を CSV で書き出して読む(名前・電話番号の列は捨てる)受け取りの日と品目と数
予定と品目の表スプレッドシートを CSV で書き出して読む行事、天気予報、売価と原価、台の種類
黒板と仕入の発注書き込まない(オーナーが決めてから書く)-

黒板にはオーナーが書きます。 案をそのまま印刷して貼る作りにすると、オーナーが直した数と案の数が混ざり、職人がどちらを作るか迷います。 決めた数を製造の記録の表にも入れ、翌日の当たり方の確認に使います。

Step9

人が確認する

  1. 作った日時とレジの書き出しの日時を見る … どちらも当日の閉店後であることを確かめます
  2. 印の付いた品目を見る … 赤(新しい品目)と黄(昨日の売れ残りが多い・売り切れが早い)の品目の数を決めます
  3. 仕上げの手の合計を確かめる … 翌朝の職人の数と、試作や予約のホールケーキの手間と突き合わせます
  4. 予測の外の事情を足し引きする … 果物の入り方、近くの店の休み、テレビや雑誌での紹介などを足し引きします

目標は、24営業日をならして1件10分です。 印の無い品目は案を写すだけで、時間を使うのは印の付いた品目と、行事の前日です。

Step10

例外に対処する

起きること対応
売れ残りの数が入っていない10分おきに3回待ち、無ければ印を付けて案を出す
レジの書き出しが閉店より前の時刻当日の分が欠けている。案に印を付け、書き出し直して再実行
材料が入らず作らなかった品目行ごと外す。売れなかった日として学習しない
新しい品目見込みを出さず、オーナーが決める
ばらつきが平均より小さく出る品目小さな正の値に置き換えて分布を作る
仕上げの手が足りない線の低い品目から減らした案を並べる
作り直したモデルが前より外れる前のモデルのまま使い、作り直しの記録を残す
パソコンが止まっていて動かなかった事務が手で実行。作った日時の古い表は使わない

3行目を間違えると、季節の見込みが崩れます。 作らなかった日を0として学習すると、その品目の旬の時期を低く見込みます。 製造の記録の表に「作らなかった」の区分を設けておきます。

Step11

記録を残す

  • 実行の日時、使ったモデルの作成日、読み込んだレジの書き出しの日時と期間
  • 品目ごとの平均、ばらつき、線、製造の案、台の数、印
  • オーナーが決めた製造の数と、案から変えた理由
  • 翌日の実績(品目ごとの売れた数、売れ残り、売り切れた時刻)
  • 品目ごとの線を変えた日と、変えた理由
  • 月ごとの当たり方(品目ごとの平均の外れの大きさ、売り切れた日の割合、売れ残りの原価の合計)と、モデルの作り直しの結果

売り切れた日の割合と、売れ残りの原価の合計を並べて見ます。 線を0.65にした品目は、ならせば3日に1日ほど売り切れるのが線のとおりの動きです。それより多く売り切れていれば見込みが低く、少なければ多めに作りすぎています。

04実装レベルの3段階

最小構成:手で写した3か月の記録で Python を動かし、過去の4週で当たり方を見る / 予測の当たり方の確認
半自動化:上記+毎日閉店後に翌日の品目ごとの売れる数の見込みの表を出す / 売れる数の見込み
本格構成:上記+品目ごとの線で製造の数を選び、台の数と仕上げの手の上限まで出し、前日の13時の台の案も出す / 見込みから製造の数と台の数まで

本記事の想定は本格構成です。 半自動化では見込みの表までで、どこまで作るかと、台の数への置き換えはオーナーの手に残ります。 第3章の(b)の、台と仕上げが合わない問題も残ります。 半自動化で1件30分が18分ほどに、本格構成で10分になります。 差が大きいのは、品目ごとの線での数の選び方と、台の数への換算が、品目の表があれば機械で出せる作業だからです。 段階を飛ばさないでください。 半自動化の表を1か月見ると、どの品目の見込みが当たり、どれが外れるかが分かります。外れる品目の記録を直してから、本格構成に進みます。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
2 名
月間件数
24 件
1件あたり現在時間
30 分
1件あたり導入後時間
10 分
現在  24件 × 30分 ÷ 60 = 12 時間/月
導入後 24件 × 10分 ÷ 60 = 4 時間/月
月間削減時間
8h
削減率
67%
年間削減時間
96h
年間金額換算(時間単価2,500円)
24万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. ショーケースのピースケーキが十数品目から二十品目ほどある、店の奥で作って店頭で売る洋菓子店。レジで品目ごとの売れた時刻が記録に残っている場合。翌日の製造の数をオーナーのパティシエが毎日の閉店後に決めていて、昼過ぎに売り切れる品目と、閉店時に売れ残る品目が同じ週に出る場合。カフェを併設する店や、パン屋の生菓子の棚にも使える。
向いていない
  1. 予約と注文の製造が中心で、店頭で見込みで作る生菓子が少ない店。レジで品目を分けずに金額だけを打っている場合。開店から1年未満で、季節と天気の動きが記録に無い場合。クリスマスのように予約で数が決まる日(予約の台帳で決める)。なお、品目の入れ替え、原材料の仕入、衛生と消費期限の管理、売れ残りの扱いの決定は、この構成では代替できません。

07最小構成で試す方法

  1. レジから、去年の秋の3か月分の品目ごとの売れた時刻と数を書き出す
  2. 製造の記録のノートから、同じ期間の品目ごとの製造の数と売れ残りを表に写す
  3. 気象庁の過去の気象データ・ダウンロードで、近くの地点の日ごとの降水量と最高気温を落とす
  4. Python で第7章の設定を動かし、その3か月の最後の4週を「翌日」として毎日予測させる
  5. 当時のオーナーの決めた数と、案の数で、売れ残りの原価と売り切れた日の数がどう違ったかを比べる

3か月・4週で十分です。 確かめたいのは、「品目ごとに、オーナーの決めた数より売れ残りと売り切れの両方を減らせるか」です。

出てきた内容判断
売れ残りの原価と売り切れた日がどちらも減る予定のシートと品目の表を作り、毎日の表を出す段階に進む
人気の品目が低めに出る売り切れた日が見積もられていない。最後に売れた時刻を確かめる
季節の品目が大きく外れる作らなかった日が0で入っている。製造の記録の区分を確かめる

2行目は、ほとんどの店で出ます。 売り切れた日の記録がノートに残っていないためで、失敗ではなく、売り切れた時刻を記録する理由が数字で分かったということです。

秋を選ぶのは、品目の入れ替わりと天気の振れが大きい時期だからです。 栗と柿の季節の品目、雨の続く週、連休が入り、線の効き方を短い期間で確かめられます。

08実装時につまずきやすいポイント

問題対策
売り切れた日の売れた数をそのまま学習する最後に売れた時刻から売れたはずの数を見積もる
予約・取り置きまで予測して二重に数える店頭の分だけを予測し、予約は台帳の数を足す
作らなかった日を0で学習する行ごと外す
全品目を同じ線で作る売価と原価から品目ごとの線を決める
ばらつきが平均より小さく出て分布が作れない小さな正の値に置き換える
台の数と仕上げの数を別々に決める同じ見込みから両方を出す
レジの書き出しが閉店の処理より前書き出しの時刻を印字し、古ければ印を付ける
気象庁の CSV を列の位置で読む品質情報などの列が並ぶ。列名で選ぶ
新しい品目の見込みをそのまま使う見なかったカテゴリは欠けた値の扱い。オーナーが決める
予約の台帳の名前・電話番号を読み込む受け取りの日と品目と数以外の列を捨てる

上の2行が、この構成の失敗のほとんどです。 どちらも、記録に残っている売れた数と、本当に欲しかった客の数がずれることから起きます。ここを押さえれば、残りは他の売上の予測と同じ注意で足ります。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 品目ごとの売れた時刻と数、製造と売れ残りの数、品目ごとの売価と原価、予約の受け取りの日と品目と数です。予約の台帳には、客の名前と電話番号が含まれます。 品目ごとの原価は、店にとって外に出したくない情報です。

  1. 客の名前と電話番号を予測に使わない … 予約の台帳を読み込むときに、受け取りの日と品目と数以外の列を捨てます。予測に要るのは数だけです
  2. データを外に出さない … 予測は事務所のパソコンの中で動き、生成AIや外部のサービスに記録を送りません。原価の表もパソコンの中に置きます
  3. 製造の数は人が決める … 案はあくまで案で、黒板に書く数はオーナーが決めます
  4. 衛生と消費期限の管理に使わない … 多めに作る線の品目でも、売れ残りを翌日に回す判断に使わないでください。生菓子の扱いは、店の衛生の決まりで行います
  5. 売れ残りの扱いを予測に合わせて変えない … 値引き・廃棄・持ち帰りの決まりは店の決まりで、予測が外れた日に急に変えないでください
  6. 気象庁のデータの出典を書く … 天気のデータを店の資料に載せるときは、気象庁のデータであることを書きます

誤りが起きた場合のリスクは、売り切れて客が帰ることと、作りすぎて捨てることの2つです。 前者は売り切れた日の見積もりが足りないと起き、後者は線が高すぎると起きます。品目ごとの売り切れた日の割合と売れ残りの原価の確認で、両方を抑えます。

10まず何から始めるか

1週目:売り切れた時刻を記録し始める

販売の責任者が、閉店時に品目ごとの売れ残りの数と、売り切れた品目の売り切れた時刻を表に入れる決まりにします。過去の分は、レジの記録の最後に売れた時刻から拾えます。

2週目:3か月分で試す

第8章のとおり、去年の秋の3か月分のレジの記録と気象庁の日ごとの天気で、最後の4週を毎日予測させます。人気の品目が低めに出ていないか、季節の品目が作らなかった日で崩れていないかを最優先で見ます。

3週目:品目の表を作る

オーナーと一緒に、品目ごとの売価、材料の原価、台の種類と1台から取れる個数、仕上げの手間を表にし、線を計算します。看板の品目の線を上げるかも決めます。

4週目:翌日の表を毎日出す

閉店後に品目ごとの見込みの表を出す半自動化を始め、オーナーはこれまでどおり自分で決めながら、表と見比べます。 翌日の閉店後に、オーナーの決めた数と案の数のどちらが売れ残りと売り切れが少なかったかを書き残します。

2か月目以降: 品目ごとの線での製造の数と、前日の13時の台の数の案を足します。オーナーが案から変えた理由、品目ごとの売り切れた日の割合、売れ残りの原価を毎月見ます。 オーナーが印の付いた品目だけを見て製造の数を決められるようになった時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-10-29/最終更新:2026-10-29
確認した内容情報源確認日
HistGradientBoostingRegressor の loss に 'poisson'(目的の値が0以上であることが要る)があること。categorical_features の既定が 'from_dtype' であること。early_stopping='auto' は行が10,000を超えるときなどに有効になること(版 1.9.1)scikit-learn: HistGradientBoostingRegressor2026-10-29
カテゴリの特徴の種類の数が max_bins より少ない必要があること。学習のときに見なかったカテゴリは予測のときに欠けた値として扱われることscikit-learn: Ensembles(Histogram-Based Gradient Boosting)2026-10-29
負の二項分布 nbinom の確率の式と引数(n・p)、平均と分散から p = μ/σ²、n = μ²/(σ² − μ) で引数を決める書き方、分位から値を返す ppf があること(SciPy 1.18.0)SciPy: scipy.stats.nbinom2026-10-29
過去の気象データ・ダウンロードで複数地点・複数項目の過去の観測値(日別値など)を CSV で落とせること。CSV に品質情報・均質番号の列が並ぶこと気象庁: 過去の気象データ・ダウンロード(このページでできること)2026-10-29
国民の祝日の CSV が昭和30年から令和9年までを収録し、令和10年の分を前年の2月に掲載するとされていること内閣府: 国民の祝日について2026-10-29

品目の入れ替え、仕入、衛生と消費期限の管理、売れ残りの扱いは、店の判断で行ってください。 本記事は公開されている仕様で確認できた範囲だけを扱っています。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-2303)についてのご相談はこちらから。

AI活用について相談する
目次