賞味期限・ロットまでつなぎ、廃棄ロスと欠品を同時に減らす
賞味期限とロットは各拠点のWMSに閉じている。全社の期限別在庫は、どこにもない。日配と季節品の波動に発注が追いつかず、欠品と廃棄が同じ月に並んで出る。
業界に共通する課題
期限・ロット情報が拠点に閉じる
賞味期限・ロットが各拠点のWMSに閉じ、全社の期限別在庫が見えない。「あと何日で期限切れになる在庫がいくらあるか」に即答できない。
欠品と廃棄が同時に発生
日配・季節品の需要波動に発注が追従できず、機会損失と廃棄ロスが併発する。片方を改善するともう片方が悪化する構造。
トレーサビリティ対応が手作業
回収・照会のたびにロット追跡を各拠点へ問い合わせ、数時間〜数日かかる。取引先からの照会に「お時間ください」と答えるしかない。
モデル企業の前提
会社・売上・拠点数は、すべて架空の数字です。
データはどこで切れているか
システムは揃っていますが、データが分断されている状況です。
- 自社DC1 WMS（ロット・期限あり）
- 自社DC2 WMS（ロット・期限あり）
- 委託3PL P社（月次報告のみ）
- 委託3PL Q社（CSV日次）
- 全社の期限別在庫
- ロット追跡（出荷先まで）
- 廃棄見込みと対策
- 需要予測に基づく発注
症状：ロットと賞味期限は各拠点のWMS内に閉じており、拠点をまたいだ照会経路がない。委託先2社の在庫は月次報告のExcelのみで、ロット番号の桁数と日付書式も社ごとに異なる。全社の期限別在庫を一覧するには、4系統のデータを人手で読み替えて突き合わせる必要がある。
W3 Data Platform 適用シナリオ（想定）
つなぐ → 揃える → 使う の3ステップ。既存システムは入れ替えません。
つなぐ
自社・委託先のWMSと基幹・受注データをロット粒度のまま接続・収集。委託先にはデータ提供のみを依頼すればよく、システム改修は発生しません。
揃える
期限・ロットを含む標準化モデルへ変換し、全社の期限別在庫を一元化。拠点ごとに違うロット番号の桁数・書式もETLで吸収します。
使う
出荷期限アラート、需要予測による発注最適化、ロット照会の即答（トレースの数分化）。欠品率と廃棄ロスを同時に改善する打ち手が見えます。
WMSに期限とロットの項目があれば、追加開発は要りません。委託先に依頼するのはデータ提供だけです。委託先のシステムに手を入れる交渉が要らないぶん、着手までの調整が短くなります。
AIとのやりとり
MCP接続により、AIが統合データを直接参照します。SQLの記述もBIツールの操作も不要で、会話で引き出せます。
自社2拠点と委託先2社のロット情報を、期限の書式を揃えたうえで統合しました。残日数30日以内を原価金額順に並べています。
| SKU | ロット | 拠点 | 残日数 | 原価金額 |
|---|---|---|---|---|
| SKU-2210 | L26071 | 委託3PL P社 | 8日 | ¥4,820,000 |
| SKU-1877 | L26066 | 自社DC1 | 14日 | ¥3,140,000 |
| SKU-0932 | L26059 | 自社DC2 | 26日 | ¥1,780,000 |
SKU-2210（残8日・482万円）は現在の出荷ペースでは67%が廃棄見込みです。① 販促枠のある得意先2社への優先提案（想定 廃棄▲310万円）、② 自社DC1の同一SKU（残45日）と出荷順序を入れ替え、の2案を提示します。承認すればWMSへ出荷優先度を書き戻します。
※ 画面・数値はイメージです。実際の項目・粒度は接続するシステムとデータ内容により異なります。
揃えたあとのデータの並び
各データの列名・粒度・書式を同じ定義に揃えます。拠点ごとのExcelも、同じ表の中に入ります。
mart.inventory_lot- 商品コード
sku - ロット番号
lot_no - 賞味期限
expiry_date - 拠点コード
site_id - 数量
qty - 期限まで残日数
days_left - 出荷先
shipped_to - 更新日時
updated_at
ロット番号の桁数・日付書式の違いを吸収し、全社の期限別在庫を1本に。ロット照会が「各拠点へ問い合わせ（数時間〜数日）」から「1クエリ（数分）」になります。
誰が、いつ、何に使うか
定型の集計とアラートは自動で届くため、担当者がダッシュボードを開く必要がありません。
- 朝 7:30生産計画
「期限接近在庫と今週の需要予測」をAIが要約。増産・減産の判断材料が出社時点で揃っている。
- 昼 11:00営業
期限接近SKUの販促提案先リストをAIが生成。廃棄予定の在庫を売り切る打ち手が先手で回る。
- 午後品質保証
取引先からのロット照会に即答（従来は数時間〜数日）。出荷先まで一気に追跡できる。
- 夕 17:00物流部
出荷優先度の変更（先入先出の例外）を承認。WMSへ書き戻され、翌日の現場は通常作業として実施。
想定効果（仮定に基づく試算イメージ）
記載の数値は代表値・想定値です。実環境（データ量・システム構成・ネットワーク）により変動する可能性があります。費用は対象システムの仕様確認が必要なため、個別にお見積りいたします。
3つの使い方のうち、どれを使うか
3つは排他ではありません。Cだけで始めて、あとからBへ広げることもできます。
W3 WMS × AI照会
弊社WMS（W3 sirius / W3 mimosa）のデータをデータレイクに取り込み、MCP経由でAIが直接参照します。SQLの記述もBIツールの操作教育も要りません。聞けば返ってきます。
データレイク蓄積（データ基盤 格納型）このモデルケースの主軸
他社システムのデータ連携サーバー、基幹DB、ECカートなどをCDC（変更差分取得）で接続し、毎日流れてくるデータをraw／mart 2層に溜め込みます。既存システムは無改修です。溜まったデータを、自然言語の指示で分析・加工できる状態にします。
ETL単体（システム直接連携）
データレイクを作らないまま、「抽出→変換→格納」だけのシステム間インターフェースとして使えます。個別IF開発をノーコードのGUI設定に置き換えることで、IF開発費が従来比 1/3〜1/2 になります。ここから始めて、あとからBへ広げることもできます。
本ページは架空のモデルケースです。記載の企業は実在せず、数値・効果は仮定に基づく試算イメージであり、実際の導入実績ではありません。効果は対象業務・データ規模・システム構成により変動します。
記載の数値は代表値・想定値です。実環境（データ量・システム構成・ネットワーク）により変動する可能性があります。費用は対象システムの仕様確認が必要なため、個別にお見積りいたします。