在庫の使用期限を毎日点検して、期限切れと先入先出の乱れを洗い出す

処理の起点を決める

毎朝6時を起点にします。始業前に一覧ができ、朝礼で当日の対応を決められる形にします。

前日の出荷が確定した後にしてください。 夜間バッチでWMSと販売管理システムのデータが確定するなら、その完了後に設定します。確定前に動かすと、前日分の出荷が反映されず、ペースの計算がずれます。

日次にする理由があります。 期限は毎日1日ずつ迫ります。週次にすると、最大6日分の判断が遅れます。特に期限まで30日を切ったロットでは、この差が大きくなります。

もう1つの起点として、入庫があったときに、その品目の先入先出の状態を確認する形が考えられます。新しいロットが入ったのに古いロットが残っている棚を、その時点で検出できます。これは運用が回ってから足してください。

入力データを集める

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

ロット別在庫： WMSから毎日エクスポートします。ロット番号と期限が紐づいていることが前提です。 紐づいていない場合、この構成は成立しません。ロット管理の導入が先です。

出荷実績： ここで重要なのは、「どのロットを出荷したか」が記録されているかです。SKU単位でしか出荷が記録されていないと、先入先出の乱れが検出できません。

ロット単位の記録がない場合でも、この構成の半分は動きます。 先入先出の検出を諦めて、期限切れの見込みだけを扱う形にしてください。

出荷の制約： これを見落とすと、判定が甘くなります。小売のチェーンによっては「賞味期限の3分の1以上が残っていること」を納品の条件にしています。この場合、期限まで残り30日でも、賞味期間が90日の商品なら納品できません。 実質的な期限は、暦の期限より早く来ます。

出荷の制約は、次の形で持ってください。

取引先ごとに違うことが厄介です。 同じロットでも、A社には納品できてB社には納品できないことがあります。この場合、「どの取引先に出す予定か」によって実質的な期限が変わります。 出荷の予定が立っていない段階では、もっとも厳しい取引先の条件で見るのが安全です。

季節性の情報： 過去2年の月別出荷量を使います。「このSKUは12月に出荷が3倍になる」と分かれば、11月時点で余っていても問題ないと判断できます。 逆に、繁忙期を過ぎた品目は厳しく見る必要があります。

ただし、季節性の補正は使いすぎないでください。 「12月に3倍になるはず」という見込みで様子を見た結果、実際には伸びずに廃棄になる、という事故が起きます。補正は、区分を1段階緩めるまでに留めてください。 「期限切れ確実」を「対応不要」にまで動かす使い方は危険です。

拠点マスタには、移動にかかる日数と費用を必ず入れてください。 拠点間の移動を勧めるには、移動の日数分だけ期限に余裕が要ります。移動に3日かかるなら、実質的な期限の3日前までに判断しなければなりません。 費用も同様で、移動費が値引き販売の損失を上回るなら、移動する意味がありません。

AIへ渡す前に整形する

1. 対象の絞り込み … 期限の設定がない品目、在庫数量が0のロット、出荷停止中の品目を除きます
2. 実質的な期限の算出 … 暦の期限から、出荷の制約（残存期限の要求）を引いた日付を出します。以後の判定はこの日付で行います
3. 出荷ペースの算出 … 直近12週の出荷量から、1日あたりの平均と標準偏差を出します。欠品で出荷できなかった期間は除外します。 含めるとペースが実態より低く出ます
4. 先入先出の順位づけ … 同じSKUのロットを期限の早い順に並べ、「このロットの前に何個あるか」を出します
5. 季節の補正 … 過去2年の同月の出荷量と直近12週の平均を比べ、補正の係数を出します。この係数も表計算で出し、AIには渡すだけにします

AIに処理させる

計算処理にさせること：

AI（Claude API）にさせること：

金額の計算も、廃棄の判断もさせません。 廃棄見込み額は「数量 × 仕入単価」の掛け算です。AIに計算させる理由がありません。

計算とAIをこう分ける理由は、再現性のためです。 余裕日数が「マイナス12日」であることは、誰が計算しても同じ結果になります。この数値がぶれると、判定の根拠そのものが信用できなくなります。 一方、「出荷のばらつきが大きいので、この見積もりは幅を持って見るべき」という判断は、いくつもの条件を合わせて言うものです。そこにAIを使います。

「見積もりの確からしさ」を出させることが、この構成の実用性を決めます。 余裕日数がマイナス5日でも、出荷が安定している品目なら見積もりどおりに進みます。ばらつきが大きい品目では、マイナス5日はほとんど意味がありません。 数値だけを示されると、担当者は同じ重みで受け取ってしまいます。「この見積もりはどれくらい信用できるか」を添えることで、確認の優先順位がつけられます。

「着眼点」の出力も、実務では効きます。 「このSKUは先月から出荷が半減している。販売終了の予定がないか営業に確認」といった一文があると、担当者はすぐ動けます。区分だけを示されても、次に何をすればよいかは分かりません。

指示内容を固定する

あなたは在庫管理を支援する担当者です。
下のロットについて、期限までに使い切れるかを見て、区分と着眼点を出してください。

【厳守事項】
- 数値は下に与えた計算済みの値をそのまま使ってください。
  独自に計算し直さないでください。四則演算をしないでください。
- 区分は、下の一覧からのみ選んでください。複数に当たる場合はすべて挙げてください。
  どれにも当たらない場合は "対応不要" としてください。
  **無理に問題を見つけようとしないでください。大半のロットは対応不要です。**
- 見積もりの確からしさは、下の「出荷のばらつき」と「季節の補正係数」から判断してください。
  ばらつきが大きい、または季節の補正が1.5倍を超える場合は "low" にしてください。
- 着眼点は、担当者が最初に確かめるべきことを1〜2点書いてください。
  **データから読み取れる事実に基づいて書き、需要の理由を推測しないでください。**
  例：「直近4週の出荷が平均の4割に落ちている。取引先の発注が止まっていないか確認する」は可。
  例：「競合の新商品の影響と考えられる」は不可。
- 値引きの幅、廃棄すべきか、いつ廃棄するかを書かないでください。
  判断は在庫管理担当と営業が行います。
- 廃棄見込み額を計算しないでください。金額は後段の処理で出します。
- 「至急」「危険」といった強い語を使わないでください。
  期限までの日数と余裕日数を示せば、緊急度は読み手が判断できます。

【区分の一覧】
期限切れ確実 ... 余裕日数がマイナスで、通常の出荷では使い切れない
期限切れの見込み ... 余裕日数が14日未満で、出荷のばらつきによっては間に合わない
先入先出の乱れ ... より新しいロットが直近30日に出荷されており、このロットが残っている
動きが止まっている ... 直近30日の出荷が0、または平均の2割未満
対応不要 ... 上記のいずれにも当たらない

【ロットの情報】
{lot_info}

【計算済みの値（平均出荷ペース / ばらつき / 番までの日数 / 使い切るまでの日数 / 実質的な期限までの日数 / 余裕日数）】
{metrics}

【季節の補正係数（過去2年の同月と直近12週の比）】
{seasonality}

【先入先出の状況（直近30日に出荷されたロットの一覧）】
{fifo_status}

【他拠点の同じSKUの在庫と不足】
{other_sites}

【前日のこのロットの判定と対応】
{previous_status}

「無理に問題を見つけようとしない」の1行が、この構成でもっとも重要です。 これを書かないと、3,000件すべてに何らかの指摘が付きます。指摘が3,000件出れば、担当者は読まなくなります。 大半のロットが「対応不要」であることが正常です。

「需要の理由を推測しない」も必須です。 出荷が落ちた理由は、競合かもしれませんし、取引先の在庫調整かもしれませんし、単に発注のタイミングかもしれません。データからは分かりません。 推測を書くと、それを前提に営業が動いてしまいます。

「強い語を使わない」の指示も効きます。 「至急」が毎日20件並ぶと、その語の意味がなくなります。日数を示せば十分です。

出力形式を固定する

{
  "site_code": "",
  "sku": "",
  "sku_name": "",
  "lot_no": "",
  "quantity": 0,
  "expiry_date": "",
  "effective_expiry_date": "",
  "categories": [
    { "category": "", "evidence": "" }
  ],
  "days_to_effective_expiry": 0,
  "days_to_consume": 0,
  "slack_days": 0,
  "estimate_confidence": "high | medium | low",
  "confidence_reason": "",
  "fifo_note": "",
  "other_site_note": "",
  "talking_points": [],
  "previous_status": "improved | unchanged | worsened | no_previous",
  "data_gaps": []
}

JSON Schema を指定して出力を固定します。Claude API では output_config の format にJSONスキーマを渡すことで、応答をスキーマに沿った形に制約できます。

effective_expiry_date を別に持つことが、この構成の実務上の要です。 暦の期限ではなく、出荷の制約を差し引いた実質的な期限で判断します。この2つを混同すると、「まだ60日ある」と思っていたものが、実際には出荷できない状態になります。

slack_days（余裕日数）が、判断のもっとも重要な数字です。 「期限まで45日」だけでは判断できません。「使い切るまで38日、余裕7日」と分かれば、手を打つべきかが決まります。

estimate_confidence は、見積もりをどれだけ信用できるかです。出荷のばらつきが大きいSKUでは、余裕日数が7日でも実際には間に合うことがあります。 ここが low のものは、数字より現場の感覚を優先する判断もありえます。

システムへ連携する

期限監視の一覧をスプレッドシートに作ります。区分ごとにシートを分けます。

各シートの列は次の構成です。

「先入先出の乱れ」のシートは、倉庫の現場へ渡してください。 これは在庫管理担当が解決する問題ではなく、棚の配置とピッキングの指示の問題です。担当者が営業へ連絡しても直りません。

WMSへの書き戻しは行いません。 出荷の優先順位を自動でWMSへ反映すると、現場の作業指示が予告なく変わります。変更は人が判断して指示します。

人が確認する

「対応不要」以外を、在庫管理担当が確認します。

3,000件すべてを確認すると効果が出ません。実際に対応が要るのは、月に300〜500件程度のはずです。 それ以上出るなら、区分の閾値を見直してください。

確認の深さを分けます。

• 「期限切れ確実」 … 全件。すでに手遅れに近いので、打てる手を急いで決める
• 「期限切れの見込み」で金額の大きいもの … その日のうちに営業へ連絡する
• 「先入先出の乱れ」 … 倉庫の現場へ渡す。個別の対応より、棚の配置を見直す
• 「動きが止まっている」 … 週1回まとめて見る。日次で見る必要はない
• previous_status が worsened … 前日の対応が効いていない。やり方を変える

確認を速くするための設計が効きます。

• 余裕日数の少ない順に並べる
• 金額を併記する（同じ余裕日数なら金額の大きいものから）
• 暦の期限と実質的な期限を並べて表示する
• estimate_confidence が low のものに印を付ける
• 前日の対応内容を併記する（同じ連絡を繰り返さない）
• 他拠点に不足がある行を色分けする（すぐ打てる手がある）

最後の項目が効きます。 A拠点で余っているロットがB拠点で不足しているなら、値引きも廃棄も要りません。移動するだけです。 この組み合わせを毎日出せることが、この構成の分かりやすい価値になります。

担当者の判断を、必ず記録に残してください。 「営業へ連絡」「様子見」「値引きを検討」のどれを選んだかを、一覧の中で入力できる形にします。別の場所へ書く形にすると、記録されません。

この記録がないと、判断が当たっていたかを後から検証できません。 「様子見」としたロットが廃棄になったのか、使い切れたのか。これが分かって初めて、閾値や見る順番を直せます。 半年分たまれば、「様子見の判断が外れるのはどういう場合か」が見えてきます。

判断を記録する運用は、面倒がられます。 だからこそ、一覧の中で1クリックで選べる形にしてください。入力に10秒かかる仕組みは、3日で使われなくなります。

例外に対処する

記録を残す

この記録は、廃棄がなぜ起きたかを振り返る材料になります。

• 日ごとの判定結果（区分、余裕日数、確からしさ）
• 担当者が取った対応と、その結果
• 前日からの変化
• 実際に廃棄に至ったロットと、その直前30日の判定履歴
• 拠点間の移動で救えたロットと、その金額
• data_gaps の内容

「廃棄に至ったロットの判定履歴」を必ず残してください。 廃棄が起きたとき、この仕組みで兆候が見えていたかを振り返れます。 見えていたのに対応しなかったなら運用の問題、見えていなかったなら判定の型の問題です。どちらかを特定できます。

「拠点間の移動で救えた金額」も記録してください。 この仕組みの効果を、金額で説明できるようになります。時間の削減より、こちらのほうが伝わります。