本文へスキップ
SNAMO Logo
SNAMO
小売店の発注担当者が、POSデータや気象情報、予約データを生成AIで分析し、曜日別の需要予測に基づいて在庫を最適化している様子

小売店の発注担当が生成AIで曜日別の在庫最適化を始めるまで

19 min read

月曜の朝、ひだまり商店の在庫担当・紬は、駅前店、郊外店、EC倉庫の発注表を机いっぱいに広げていた。駅前店では週末前に棚が空き、郊外店では同じ商品が残り、EC倉庫では別の商品コードの下に記録されている。

「同じ商品なのに、売れる曜日も、残る場所も違うんだ……」

紬は曜日別の販売数、在庫、欠品、発注履歴を何度も見比べた。これまで、すべての拠点に似たような発注量を当てはめてきたが、それでは需要の違いをつかめない。生成AIに発注量を提案してもらえれば、欠品と過剰在庫を減らせるかもしれない。けれど、SKU、店舗、ECのチャネルをどう結び、売上ゼロの日をどう読み分けるのかが分からなかった。紬は開きかけたAIの画面を、そっと閉じた。

この記事の答え

  1. 結論小売店は生成AIで曜日別の発注候補を作り、承認と補正を経て在庫を最適化できる。
  2. 根拠SKU・店舗・チャネルを統合し、欠品や売上ゼロの原因を区別してAIに渡すことが根拠になる。
  3. 最初の一歩まず商品を結ぶ一意のキーと曜日別販売実績、在庫、入荷予定、欠品理由を整理する。
01

第1章 月曜の朝、同じ商品が違う顔を見せる

生成AIの画面を前に三拠点の発注表を見比べる在庫担当者

第1章 月曜の朝、同じ商品が違う顔を見せる - 本文

月曜の朝、ひだまり商店の事務所には、プリンターの音と紙のこすれる音が重なっていた。窓の外では、駅へ急ぐ人の靴音が細く続いている。紬は机いっぱいに、駅前店、郊外店、EC倉庫の発注表を広げていた。

左には駅前店の表、右には郊外店の表がある。少し離れたところには、EC倉庫から届いた商品一覧が置かれていた。どの表にも、同じ詰め替え用洗剤の名前が見えるのに、並んでいる場所も、書かれた商品コードも違っていた。

紬は先週の金曜に届いた電話メモを手に取った。駅前店の店長からは、「週末を前に棚が空いてしまった」と書かれている。商品の写真には、白い棚の一角だけがぽっかり抜けていた。

「紬さん、あの商品、土曜の朝にはもう足りなかったよ」

電話の向こうで、駅前店の真鍋店長は困った声を出していた。通勤客が帰りに買う商品だったため、金曜の夕方から動きが大きくなったらしい。けれど、次の納品まで追加することはできなかった。

紬は、郊外店の報告書をめくった。こちらの棚には、同じ洗剤がきれいに並んでいる。前の週から動いていない商品もあり、担当者が貼った小さな紙には、「在庫が残っています」と書かれていた。

「駅前店では足りないのに、郊外店では残っている……」

紬は赤いペンで駅前店の金曜に線を引き、青いペンで郊外店の週末に丸をつけた。発注担当になってから、彼女は毎週こうして曜日ごとの販売数と在庫を見比べてきた。表を整えることも、店からの相談に返事をすることも、紬は丁寧に続けていた。

ただ、同じ商品を同じように発注するやり方では、どうしてもどこかに無理が出た。駅前店には少し多く届けたい日があり、郊外店には急いで増やさなくてよい日がある。EC倉庫には、さらに別の表し方があった。

「この商品、ECでは別のコードになっています」

隣の席の理恵が、倉庫の一覧を指でたどった。店舗では商品名で管理しているのに、ECでは別のコードの下に販売実績が集まっているという。見た目は同じ商品でも、表の中では別々の商品に見えていた。

紬は三つの表を横に並べた。店舗名、販売日、曜日、販売数、在庫数、発注日が、それぞれ違う順番で並んでいる。ECの表には、店頭では使わない出荷区分まで加わり、目を移すたびに商品の行を見失いそうになった。

「SKUをそろえないと、同じ商品として見られないね」

「SKUって、商品を見分けるためのコードですよね」

「そう。店とECでコードが違うなら、まず同じものだと結びつけないといけない」

理恵の説明を聞きながら、紬はノートに「商品」「拠点」「チャネル」と書いた。チャネルは、店頭で売るのか、ECで売るのかという販売の道筋のことだ。商品だけをまとめても、駅前店と郊外店では売れ方が変わる。

紬は、駅前店の月曜の行を指で押さえた。販売数がゼロの日もあったが、それは本当に売れなかった日なのだろうか。棚が空で売れなかったのか、客が少なくて売れなかったのか、表だけでは判断できなかった。

「売上ゼロを、そのまま『人気がない』と読んだら危ないよね」

理恵がうなずいた。欠品していた日は、買いたくても買えなかった日かもしれない。郊外店のゼロは来店の少ない曜日かもしれず、EC倉庫のゼロは別コードに記録されているだけかもしれなかった。

紬はふたたび発注表を見比べた。駅前店では週末前に棚が空き、郊外店では同じ商品が残り、EC倉庫では別のコードの下に販売が隠れている。ひとつひとつの表には理由があるのに、ばらばらに見ていると、ただの数字の列になってしまう。

机の端には、生成AIを開くためのタブが残っていた。紬はそこをクリックし、「曜日別に発注量を提案してください」と入力しかけた。けれど、商品コードをどれにするか、どの店舗を含めるか、ECの販売をどう結びつけるかが決まっていなかった。

「月曜は多め、火曜は少なめ、と書いてもらうだけなら簡単かもしれない。でも、その理由を間違えたら、また棚が空いてしまう」

紬は入力欄の上で指を止めた。曜日別の販売実績だけでなく、現在庫や欠品の記録も必要に思えた。納品までの日数や、週末の販促予定まで考えるなら、渡す情報はさらに増える。

事務所の時計が、八時半を知らせた。始業のチャイムが鳴り、店から新しい連絡が届く。紬は画面を見つめたあと、生成AIのタブをそっと閉じた。

「まずは、同じ商品を同じものとして並べるところからだね」

机の上には、三つの発注表と、色の違う付箋が残った。紬は駅前店、郊外店、EC倉庫の名前をノートに書き、曜日の欄をゆっくり空けていった。

02

第2章 金曜の棚から消えた商品

空棚と別SKUの在庫表を見つめる発注担当

第2章 金曜の棚から消えた商品 - 本文

金曜の夕方、駅前店の棚から、週末によく売れる商品が消えた。帰宅前の客が増える時間なのに、店長の佐伯は空いた棚の前で立ち止まっていた。レジの呼び出し音が、いつもより近く聞こえた。

「紬さん、売れる時間に商品がない。駅前店の在庫を見てもらえる?」

紬の携帯電話が鳴ったのは、本部の窓に夕日が差し込んだころだった。彼女は机の上の発注表を引き寄せ、駅前店の在庫欄を開いた。表示された残りは、売り場へ補充するには足りなかった。

「今日の分は、もう動かせない……」

配送担当に確認すると、当日の便はすでに出ていた。郊外店なら同じ商品が残っているが、駅前店へ回すための手配は間に合わないという。紬は郊外店の在庫表を開き、画面の端に並んだ残数を見つめた。

「郊外店にはあるのに。どうして、駅前店にはないの?」

郊外店の倉庫には、同じ商品がいくつも残っていた。広い駐車場のある店では、週末の夕方でも売れ方が穏やかだったらしい。駅前店では金曜から土曜にかけて客足が増えるのに、郊外店と似た発注量が続いていた。

紬は過去の発注履歴をたどった。どの拠点にも、前の週の販売数をもとにした同じ計算が使われている。駅前店の立地も、郊外店の来店時間も、曜日ごとの違いも、発注欄にはほとんど残っていなかった。

「月曜も金曜も、同じように扱っていたんだ……」

そのとき、EC倉庫の担当者から社内チャットが届いた。倉庫には在庫があるように見えるが、店舗で使っている商品コードとは違うコードで登録されているという。商品名は似ていても、画面をまたいで照合しなければ、同じ商品だとすぐには判断できなかった。

「ECでは、この商品が別のSKUになっています。店舗の表と足していいか、確信がありません」

紬は三つの画面を並べた。駅前店の販売表、郊外店の在庫表、EC倉庫の受注表が、別々の言葉で同じ商品を指していた。商品コードの違いを直しながら計算すれば、移せる在庫が見つかるかもしれないが、すぐに発注を決められる状態ではなかった。

佐伯から、もう一度電話が入った。店内では客が棚の前で足を止め、スタッフが別の商品を案内しているという。佐伯の声の後ろで、レジの音と短い謝罪の声が重なった。

「お客さまに、今日は入荷がないと伝えています。明日の朝までに何とかできますか?」

「確認します。けれど、今の表だけでは、どこに本当の在庫があるか決められません」

電話を切った紬は、曜日別の販売実績を開いた。駅前店では金曜と土曜に販売が伸びている。しかし、その曜日に売上ゼロと記録された日もあった。棚が空だったために売れなかったのか、本当に需要がなかったのかは、表からは読み取れなかった。

「売れなかったゼロと、売るものがなかったゼロが、同じなんだ」

紬は欠品の記録を探した。ところが、欠品は店長のメモやチャットに分かれ、販売実績の表にはつながっていない。売上がない日をそのまま需要のない日として扱えば、次の金曜の発注量はさらに小さくなる。

郊外店では、別の問題が起きていた。棚の奥には同じ商品が残り、値引きの予定が近づいている。返品した商品は返品表に、値引きした商品は価格変更の表に、廃棄した商品は倉庫担当の記録に分かれていた。

「在庫は残っている。でも、売れる在庫なのか、処分に近い在庫なのかが分からない」

紬は、発注表の隣に返品、値引き、廃棄のファイルを重ねた。どの表にも必要な情報はあるのに、商品、店舗、曜日をそろえて眺められる一枚の判断材料になっていない。小売・ECの在庫最適化でデータをそろえる考え方を紹介した小売・EC業界のAIエージェント活用事例のページが、紬の画面の端に残っていた。

生成AIの画面を開けば、発注案を文章にしてくれるかもしれない。けれど、違う商品コードを同じものとして扱うのか、売上ゼロを欠品として読むのか、その前提が決まっていなかった。予測AIに渡す販売実績も、生成AIに説明させる理由も、まだ同じ土台に乗っていない。

「数字を増やす前に、何を数えたのかをそろえないと……」

紬は駅前店の空棚を思い浮かべた。郊外店の残った商品と、EC倉庫の別コードが、同じ画面の中で離れたまま並んでいる。閉じたままのAI画面に、夕方の窓明かりが細く映っていた。

03

第3章 古い発注表に線を引く

SKUと店舗を結ぶ発注判断表を整える紬と蓮

第3章 古い発注表に線を引く - 本文

火曜の朝、紬は社内のデータ担当・蓮を発注室に呼んだ。蓮は古い発注表を抱え、紙の山を一枚の判断表に変える準備を始めた。二人は、生成AIに何を見せるかを決めることから、作業を始めることにした。

窓の外では、駅前を行き交う人の足音が続いていた。机の上には、駅前店、郊外店、EC倉庫の表が重なっている。商品名は同じでも、コードの書き方や記録される場所がばらばらだった。

「まず、商品名だけでつなぐのはやめよう」

蓮は赤い鉛筆で、三つの表の端に線を引いた。

「商品名は、同じ名前でも少し変わることがあるんだ。だから、商品を見分けるSKU、どの店舗か、どの販売チャネルかを組み合わせる。これを一意のキーにするんだよ」

「一意のキーって、同じものが二つ出てこない目印?」

「そう。たとえば『SKU×店舗×チャネル』だね。駅前店で売る商品と、ECで売る商品を、同じ箱に入れないための目印だよ」

紬は古い表の「商品コード」欄を見つめた。駅前店では短いコードが使われ、EC倉庫では別のコードが使われている。蓮は対応表を横に置き、別々のコードが同じ商品を指すことを確認していった。

「コードが違っても、同じ商品なら結び直せる。ここを先にそろえないと、AIは別の商品として数えてしまうからね」

蓮は新しい表の列を、左から順番に書いた。日付、SKU、商品名、店舗、チャネル、販売数、在庫、欠品、発注、値引き、廃棄、そして入荷予定だった。すべてを同じ期間で並べると、売れた数だけでなく、売れなかった理由も見えるようになる。

「販売数と在庫だけでは、発注の良し悪しは分からないんだ。欠品して売れなかったのか、商品が残って値引きしたのか。廃棄になったのか。発注した日と入荷する予定も、同じ表で見よう」

紬は、先週の月曜の行を指でなぞった。販売数の欄は空白に近く、在庫は残っている。けれど、その日は朝から棚が空いていたはずだった。

「この売上ゼロは、需要がなかった日なのかな」

蓮は首を横に振った。

「ゼロには、いくつかの顔があるよ。お客さまが求めなかった『需要なし』かもしれない。売り切れて販売できなかった『欠品』かもしれない。店が休みだった、データがまだ届いていない、ということもある」

新しい表には、「ゼロの理由」という欄が加わった。そこには、需要なし、欠品、営業していない、データ未連携と書かれ、必要なら担当者が選べるようになった。紬は、数字のない日にも、出来事が隠れていることに気づいた。

「これならAIが、売れなかった日と、売れなかったように見える日を間違えにくいね」

「うん。AIに考えてもらう前に、何が起きた日なのかを、人が分かる形にしておくんだ」

午後になると、二人は入荷予定の表記をそろえた。「納品予定」「入荷待ち」「次回入荷」といった言葉を、そのまま別の意味として扱わないようにした。予定日が分かるもの、未定のもの、すでに入荷したものに分けると、発注後の時間も比べられるようになった。

「入荷予定が分からないままだと、AIは在庫が増える日を読めない。発注してもすぐ届かない商品なら、その分を待つ必要があるからね」

蓮は、整えた表を画面に映した。行には日付が並び、横には店舗とチャネルが並んでいる。赤い線は欠品、青い線は値引き、鉛筆の丸は担当者が確認した記録だった。

「生成AIに渡す単位は、商品全体ではなく、まず『SKU×店舗』にしよう。ECの商品なら『SKU×チャネル』で見る。駅前店、郊外店、ECでは、同じ商品でも売れる曜日も、届くまでの時間も違うからね」

紬は、駅前店の表とEC倉庫の表を並べた。駅前店では週末前の棚が大切で、ECでは注文が集中する日と出荷の締め時間が大切だった。同じ商品名の下にまとめてしまえば、その違いが消えてしまう。

「商品全体で一つの発注量を出したら、駅前店には足りなくて、郊外店には余るかもしれない」

「その通り。AIに賢く考えてもらう前に、何を見ているかを間違えない表を作ろう」

その言葉を聞いたとき、紬の胸に小さな明かりがともった。生成AIの画面を閉じたのは、AIが怖かったからではない。見せるデータの形が、まだ決まっていなかったからだ。

紬は新しい表を保存し、ファイル名の先頭に「発注判断用」と入力した。続けて、駅前店のいくつかの商品を選び、販売、在庫、欠品、発注、値引き、廃棄、入荷予定を同じ期間で並べた。最後に、蓮へ確認の印を送った。

「蓮さん。この表を使って、まずはAIに発注候補を聞いてみたい」

蓮はうなずき、画面の閉じた生成AIをもう一度開いた。紬は、今度はそっと閉じなかった。

04

第4章 AIの提案に赤い鉛筆を入れる

ChatGPTの発注提案に赤鉛筆で修正を加える在庫担当者

第4章 AIの提案に赤い鉛筆を入れる - 本文

火曜の朝、紬と蓮は、曜日別の販売・在庫データを生成AIに読み込ませる準備を始めた。駅前店、郊外店、EC倉庫を分け、同じ商品でも別の場所として見られるようにする作業だった。

紬はGoogle スプレッドシートに、商品を表すSKU、店舗名、ECチャネル、曜日、販売数、欠品時間、現在庫、発注履歴を並べた。さらに、入荷予定、値引き、廃棄、特売、地域の催事、天候のメモも加えた。

「売れた数だけでは、足りなかったのか、売れなかったのか分からないものね」

「そう。AIに渡すのは、数字の山じゃない。判断できる形にした記録だよ」

蓮は、個人情報を含まないCSVを作った。会社で承認されたChatGPTの環境に、商品名と店舗コードを確認してから貼り付ける。発注確定まで自動で進まないように、指示の最後には「提案のみ。発注は担当者の承認後」と書いた。

紬は、画面に指示文を入力した。「SKU×店舗・チャネルごとに、月曜から日曜までの推奨発注量を出してください。予測販売数、前週との差、主な理由、欠品リスク、在庫が余る可能性、確認が必要な項目を分けてください。入荷予定、発注単位、目標在庫日数、特売、天候も考慮してください」

しばらくして、表が返ってきた。月曜は発注を抑え、金曜は増やす商品があり、その横には「週末の販売増加」「雨予報」「駅前店の欠品時間が長い」と理由が添えられていた。

「思ったより、読みやすいね」

紬が笑った直後、赤い警告が目に入った。EC倉庫の飲料が、売上ゼロのまま「需要がないため、発注不要」と表示されていた。けれど、その商品は前日に何箱も出荷されている。

蓮がECの受注画面と在庫表を見比べた。店舗ではSKU「D-104」、ECでは商品コード「EC-771」となっている。同じ商品なのに、別の商品として記録されていた。

「コードがつながっていない。これはAIの間違いというより、渡した表の入り口がずれているんだ」

二人は商品マスタを開き、旧コード、店舗SKU、ECコードを一行にまとめた。対応するコードがない商品には「整備待ち」と印を付け、該当行は次の提案から外した。紬は同じCSVを作り直し、読み込み後に「コードが一つしかない商品を一覧にしてください」と追加で指示した。

二度目の結果では、コードの不一致が一覧で示された。AIは、つながらない商品について発注量を出さず、「確認が必要」と表示した。紬は、空白を勝手に埋めない出力に、少し安心した。

しかし、別の問題が残った。季節限定の桜柄の菓子が、前年の販売記録だけを見て、毎日少ない発注量になっていた。昨年は催事が中止され、今年は駅前広場で春の催しが予定されている。

「季節商品は、過去の平均だけでは決められないね」

蓮は画面の分類欄に、発注方針を四つ書いた。Aは欠品を防ぐ「守る在庫」。Bは低回転品や期限品の量と発注頻度を抑える「減らす在庫」。Cは新商品や季節品を「人が判断」。Dはデータが整うまで自動提案の対象にしない「整備待ち」だった。

同じ菓子でも、駅前店はA、郊外店はB、ECはCになった。駅前店では催事の日に売り切れを避け、郊外店では残りやすさを見て量を減らす。ECは出荷のまとまりと予約数を店長が確認してから決める。

「商品ごとではなく、商品と場所の組み合わせで方針を変えるんだね」

「うん。AIが一つの答えを押しつけるのではなく、判断の入口をそろえるんだ」

午後、駅前店の店長・美和が発注表を見に来た。AIは金曜の飲料を増やしていたが、美和はさらに少し上乗せした。週末の特売に加え、近くの球場で試合があると知っていたからだ。

「このまま確定せず、修正前と修正後を残しましょう。特売と試合が理由です」

紬は表の右側に、修正前の数量、修正後の数量、修正者、理由、確認日を記録した。雨予報で来店が減ると見た郊外店では、店長が発注量を下げ、その理由も同じ欄に書いた。

最初は、修正欄を作るだけで時間がかかった。けれど、次の朝には、AIの提案と店長の判断を横に並べて見られた。どの商品が欠品を恐れて増やされたのか、どの商品が余る心配で減らされたのかも分かった。

紬は最後に、出力された候補を一つずつ確認した。欠品時間が長いのに発注不要となった商品には原因区分を「欠品による販売機会損失」と付け、在庫があり、何日も売れていない商品には「本当に需要が少ない」と付けた。原因の分からない売上ゼロには、無理に判断せず「確認中」と残した。

夕方、承認済みの発注だけが発注表へ移された。画面の横には、赤い鉛筆で直した跡がいくつもある。それは失敗の印ではなく、AIの提案に現場の天気や催事を重ねた記録になっていた。

「明日も、この差を見よう」

紬がそう言うと、蓮はうなずいた。発注表には、曜日別の量だけでなく、提案の理由と、人が決めた理由が並んでいた。

05

第5章 火曜日の発注画面に生まれた余白

生成AIの曜日別発注提案を確認する店長

第5章 火曜日の発注画面に生まれた余白 - 本文

導入後の火曜日、紬は新しい発注画面を開いた。前は駅前店、郊外店、EC倉庫の表を机に並べていたが、今は商品ごとの情報がひとつの画面に集まっている。

商品名の横には、曜日別の推奨発注量が並んでいた。その下には、欠品の有無、入荷予定、現在の在庫状態、そして提案理由が表示されている。駅前店の画面には、土曜日の販売数と週末の販促をもとにした説明が出ていた。

「月曜の販売が多かったから、火曜はこの量。入荷予定を入れても、棚を切らさない提案です」

駅前店の店長、水野が画面をのぞき込んだ。以前は、発注量だけを見て、別の表を開き、入荷日を確かめていた。今日は理由を読んでから、迷いのない手つきで承認のボタンを押した。

「この提案なら、承認します。もし変えたら、その理由も残るんですね」

「はい。店長の判断も、次の確認に使える記録になります」

蓮が答えると、水野の声が少し明るくなった。発注確定のように影響が大きい操作は、人が確認してから進める設計だと、蓮は説明した。生成AIは理由を文章にし、曜日別の量を計算する予測AIや業務システムとつなぐ役割を持つ。その役割分担は、小売・EC業界のAIエージェント活用事例にも示されている。

郊外店の画面には、同じ商品について別の表示が出ていた。在庫の残りが多く、入荷予定も近い。AIは、火曜日の推奨発注量を抑え、「現在庫と入荷予定で需要をまかなえる見込み」と理由を添えていた。

「前なら、駅前店の発注表を見て、同じだけ頼みそうになっていました」

郊外店の店長、遠藤は、画面の在庫欄を指でなぞった。

「この店は、今ある分を先に売る。今日は追加を見送ります」

遠藤が修正欄に理由を残すと、画面に「郊外店は在庫余剰のため発注抑制」と記録された。あとから見ても、なぜこの曜日だけ量を減らしたのかが分かる。数字だけが残るのではなく、店の判断が一緒に残るようになった。

新商品の欄には、別の色がついていた。販売実績が少ないため、AIの提案は参考値として表示されている。水野は来週の売場計画と予約分を確認し、自分で数量を決めた。

「新商品は、去年の同じ曜日とは比べられません。今回は売場の場所を広げる予定なので、少しだけ上乗せします」

その理由も入力され、承認に進んだ。過去のデータだけでは見えない特売や新商品の動きは、店長が補う。蓮は、その補正を無理に消さず、次に確かめられる形で残すことを大切にしていた。

一方、EC倉庫のDの商品には、「データ整備待ち」と表示されていた。商品コードの対応がまだ確認できないため、自動発注の候補には入らない。紬はその表示を見て、以前のように売上ゼロを需要ゼロと決めつけずに済むことを感じた。

画面の下には、発注量だけでなく、欠品率、欠品による推定逸失粗利、在庫日数、在庫金額、値引き、廃棄、発注工数、緊急対応の記録欄が並んでいた。売上だけで判断せず、欠品と余剰在庫の両方を追う見方は、小売・EC業界におけるAI活用の進め方を参考にしたものだった。

以前の火曜日、紬は三つの表を何度も行き来していた。コードを照らし合わせ、在庫を探し、店長に同じ質問を繰り返しているうちに、発注の締め切りが近づいていた。今日は画面の理由を確かめながら、駅前店へ一本の電話をかける時間が残っていた。

「水野店長、週末の販促は予定どおりですか。画面の提案はその予定を含めていますが、売場の場所だけ確認したくて」

「はい。場所は変わりません。提案どおりで進めます」

短い電話が終わると、紬はゆっくり息を吐いた。空いた時間は、表を探すためではなく、店の様子を確かめるために使えた。発注画面の余白は、仕事の隙間ではなかった。人が判断するための、静かな時間になっていた。

06

第6章 土曜の朝、店長が最後のボタンを押す

土曜朝の店内で生成AIの発注提案を確認する店長

第6章 土曜の朝、店長が最後のボタンを押す - 本文

土曜日の開店前、AIの提案と店長の判断がひとつの発注画面に並び、駅前店の朝が静かに始まった。先週まで机に重なっていた紙の発注表はなく、窓からの淡い光が、ひとつの画面を照らしていた。

店長の佐伯は、曜日の欄を土曜に合わせた。商品ごとに提案量が並び、その横には、理由、入荷予定、過去の欠品、前回の修正履歴が表示されている。赤い印は、ただの注意ではない。いつ、どの店で、なぜ棚が空いたのかを確かめるための道しるべだった。

紬は佐伯の隣に椅子を置いた。画面にはPOSに残る販売記録と在庫の動きがつながり、売上がゼロだった日も、欠品で売れなかったのか、もともと動きが少なかったのかを見分けられるようになっていた。

「前は、ゼロという数字だけを見ていましたね」

「今は、その日の棚の様子まで近づいて見られる。数字の後ろに、店の時間があるんだな」

画面を横に送ると、同じ商品でも拠点ごとに違う案が出てきた。駅前店には週末の来店に備えた発注が並び、郊外店には残り方を考えた控えめな量が出ている。EC倉庫では、オンラインの注文に合わせた案と、出荷を止めないための在庫が示されていた。

「同じ商品を、同じ量にしなくてよくなりました」

紬は商品名の下にあるSKUを指した。SKUは、商品を見分けるための番号だ。店舗とECで別々に呼ばれていた商品も、同じものとして結びつき、販売と在庫を一緒に確認できる。

「売れ方を読むのは予測AIです。過去の曜日や在庫から、まず案を出します。生成AIは、その理由を人に分かる言葉にしてくれる。でも、最後に店の事情を重ねるのは、私たちですね」

佐伯は駅前店の土曜分に目を止めた。午後から、駅前商店街の特売が予定されている。画面の提案にはその情報がまだ十分に反映されておらず、佐伯は数量の補正欄を開いた。

「店頭分を少し増やします。駅前商店街の特売で、午後の来店増を見込みます」

理由の欄に、佐伯の言葉が残った。修正前の提案も、修正した数量も、変更した人も、同じ画面に記録された。紬はその履歴を見ながら、誰かの勘が消えずに、次の判断へ渡っていくことを感じていた。

佐伯は入荷予定をもう一度確認した。欠品の記録に目を通し、郊外店とEC倉庫の案も確かめる。それから、画面の端にある承認ボタンへ指を置いた。

「発注を確定します」

小さな音がして、注文が送られた。AIが決めた音ではない。データから出た案に、店長の目と、土曜の町の気配が重なった音だった。

開店すると、駅前店の棚には商品が並んだ。郊外店では必要な分だけが静かに届き、EC倉庫では正しい商品コードの箱が、出荷台へ順番に運ばれていく。紬は店から届いた短い確認を読み、画面の欠品欄から赤い印がひとつ消えるのを見た。

昼の明るさが事務所の床まで伸びたころ、紬は新しい週の判断表を開いた。月曜の欄には、まだ誰にも押されていない提案が並んでいる。紬は画面を閉じず、そのまま次の曜日の気配を待った。

関連キーワード

小売店の発注
曜日別在庫
生成AI
SKU
EC倉庫
欠品
過剰在庫
SKU統合
売上ゼロ
在庫最適化

著者について

鈴木信弘(SNAMO)

鈴木信弘(SNAMO)- 静岡県を拠点に活動する総経験19年のフルスタックエンジニア。AI時代の次世代検索最適化技術「レリバンスエンジニアリング」の実装者として、GEO(Generative Engine Optimization)最適化システムを開発。2024年12月からSNAMO Portfolioの開発を開始し、特に2025年6月〜9月にGEO技術を集中実装。12,000文字級AI記事自動生成システム、ベクトル検索、Fragment ID最適化を実現。製造業での7年間の社内SE経験を通じて、受注システム自動化による業務時間の短縮や検品作業のデジタル化など、現場の課題を技術で解決してきた。富山大学工学部卒、基本情報技術者保有。

プロフィールを見る

よくある質問

Q1小売店の発注業務に生成AIを活用するには、どのようなデータが必要ですか?
SKU、店舗、販売チャネル、曜日別の販売実績、在庫数、入荷予定、欠品や返品の理由、値引き・廃棄の記録などが必要です。特に、店舗やECで商品コードが異なる場合は、同じ商品を結び付ける一意のキーを整備することが重要です。
Q2生成AIで曜日別の在庫最適化はできますか?
できます。曜日ごとの販売傾向や店舗特性、在庫状況、入荷予定などをAIに渡すことで、曜日別の発注候補や提案理由を作成できます。ただし、特売や地域イベントなどの現場事情は自動では把握しにくいため、店長や担当者による確認と補正が必要です。
Q3売上ゼロの商品は、需要がないと判断してよいのでしょうか?
いいえ。売上ゼロには、欠品、販売停止、未入荷、商品コードの不一致、返品処理中など複数の原因が考えられます。売上ゼロをそのまま「需要なし」と判断せず、原因区分を付けて確認することが大切です。
Q4店舗とECで商品コードが違う場合、生成AIで在庫を分析するにはどうすればよいですか?
店舗SKU、EC SKU、商品名などを対応付け、店舗・チャネルをまたいで同じ商品を識別できる一意のキーを作成します。そのうえで、販売実績や在庫数を共通の単位に整理してから生成AIに渡します。
Q5生成AIが作成した発注提案を、そのまま自動発注しても安全ですか?
そのまま自動発注するのではなく、承認を前提に運用するのが安全です。AIには発注数量だけでなく、曜日別の販売実績、現在庫、欠品原因、入荷予定、提案理由を表示させ、店長や発注担当者が確認・修正できるようにします。
Q6生成AIを使った発注で、特売や店舗ごとの事情は反映できますか?
反映できますが、特売、地域イベント、店舗独自の販売計画などは、現場担当者が補正情報として入力する必要があります。記事では、店長が特売の予定を確認してAIの提案を修正・承認しています。
Q7生成AIによる在庫最適化で期待できる効果は何ですか?
欠品や余剰在庫の削減、発注判断の根拠の可視化、店舗やECをまたいだ在庫状況の把握、発注担当者の確認作業の効率化が期待できます。また、担当者が発注データの整理だけでなく、店舗への確認や判断に時間を使えるようになります。