AIエージェントの物流・サプライチェーン活用事例｜需要予測・在庫・配送の連動設計

物流AIエージェントでは予測・在庫・発注・配送を分ける

需要予測は「いつ、どの商品が、どの拠点で、どの程度必要か」を数量の幅で示します。在庫判断は現在庫、入荷予定、安全在庫、賞味期限、保管能力を使い、欠品と過剰のどちらを受け入れるかを決めます。発注は最小ロット、価格、契約納期、仕入先能力へ従い、配送は車両、積載、温度帯、受付時間、運賃、顧客約束を満たす必要があります。

自動化しやすいのは、注文番号、SKU、拠点、数量、予定日を照合し、差分を通知する処理です。下書きに向くのは、補充・移送・代替便の候補と仕入先への確認文です。人が主導するのは、サービス水準を下げる割当、価格や契約の変更、規制品の輸送、災害時の優先順位、顧客への納期確約です。

エージェントを「全体最適の自動装置」と定義せず、制約と根拠を付けた例外案件を担当者へ届ける仕組みとして設計します。

最初からERP、WMS、TMSへ書込みを許可しません。需要・在庫・輸送の読取結果から提案票を作り、既存の購買承認や配車手順で反映します。提案が正しくても、どのデータ版と規則を使ったか追えない場合は実行候補から外します。

分断された計画業務の待ち時間を捉える

物流の負荷は、需要計画担当が表計算を更新する時間だけではありません。販売が販促予定を共有し、調達が仕入先能力を確認し、倉庫が保管余力を返し、輸送担当が車両枠を確認するまでの待ちが計画周期を長くします。計画が確定する頃には在庫・受注・入荷予定が変わり、再び表を作り直します。

導入前には、計画一回ではなく例外一件の流れを記録します。起点は「欠品・過剰・納期遅延の候補が最初に検知された時刻」、終点は「発注、移送、配車、保留のいずれかが責任者付きで確定した時刻」です。能動作業、部門待ち、仕入先待ち、運送会社待ち、データ修正を分けると、AIで短縮できる資料準備と、契約・物理能力による待機を区別できます。

在庫がなかった注文だけでなく、問題なく納品できた注文も比較対象にします。欠品案件だけを見ると、需要急増や供給停止ばかりが学習材料になり、通常の季節変動や定期補充を過剰に警告します。商品特性、拠点、顧客区分、発注リードタイムをそろえた期間を最低一つ持ち、受注残や代替品で需要が隠れた日には注記を付けます。

二つの公表事例が示す範囲と限界

AWSの顧客事例によると、Amazon PharmacyはAWS Supply Chainを需要計画へ導入し、日次予測のMAPEを5％とし、手作業の削減で週約5時間を短縮したと公表しています。過去の販売と現在の注文から予測を作り、最新データで更新して上流・下流の工程へ公開する運用も説明されています^[3]。これは需要計画基盤の公表成果であり、発注・在庫移動・配送を生成AIエージェントが無承認で実行した事例とは書かれていません。

Microsoftの顧客事例では、ニュージーランドのFarmlands CooperativeがDynamics 365 Supply Chain ManagementのProcurement Agentを使い、発注書に関するメールの半分を自動化したと報告しています。対象は数量、価格、梱包単位、到着予定日の変更など、仕入先から届く標準的な連絡の読取りと更新・返信案です^[4]。こちらはエージェントの実運用例ですが、需要予測精度や配送最適化の効果まで同じ数字で説明できません。

事例の読み方

サービス提供企業が掲載した顧客事例は、実装の入口と公表値を知る一次的な材料になります。ただし独立監査の結果とは限らず、母数や費用が非公開の項目もあります。自社のROI表には、確認できた数値と未公表の欄を分けて転記します。

二例をつなげると、予測値をそのまま注文へ変えるのではなく、需要計画が例外を作り、発注エージェントが仕入先連絡を整え、担当者が数量と条件を承認する段階設計が見えます。配送まで広げるときは、さらに積載・温度帯・契約運賃・顧客受付時間を別の制約として追加します。

商品・拠点・イベントを同じ言葉で結ぶ

国土交通省は2025年2月7日、「物流情報標準ガイドライン」をver.3.00へ改訂したと公表しました。ガイドラインは運送計画情報や出荷情報などの標準化を進め、物流サービス提供者が参加する標準プロセスやCO2排出量報告への対応を追加しています^[1]。自社の全システムを一度に置き換える義務ではありませんが、荷主・物流事業者間で項目名と意味を合わせる際の公的な基準になります。

国際的な可視化データでは、GS1のEPCIS 2.0が、サプライチェーン内のイベントを共通形式で取得・共有する標準を提供します。製品や荷姿について、何が、いつ、どこで、なぜ起きたかを扱い、温度管理などのセンサーデータ、JSON/JSON-LD、REST APIにも対応します^[2]。AIへ自由文だけを渡すより、入荷・格納・梱包・出荷・到着のイベントを識別子付きで渡すほうが追跡しやすくなります。

同じ「在庫」でも、会計在庫、利用可能在庫、検査保留、輸送中、引当済みでは用途が違います。エージェントが補充案を作る列には、利用可能在庫の式と更新時刻を明示します。ケースと個数、パレットとケースの換算が曖昧な商品は提案対象から外し、ゼロや空欄が本当に欠品なのか未連携なのかを分けます。

マスタ変更には発効日と承認者を持たせます。仕入先のリードタイム、最小発注量、倉庫容量、配送曜日が変わったのに旧条件を使うと、予測精度が高くても実行案は誤ります。日次スナップショットだけでなく、提案時点で参照したマスタ版を案件へ保存します。

需要予測は誤差と前提変更を同時に渡す

需要エージェントの出力は一点の数量ではなく、基準予測、上限・下限、前回差、主な変動要因、未反映イベントを含む計画票にします。販促、価格改定、欠品、終売、新店、競合要因は過去販売だけから分かりません。販売・商品担当が事前に登録したイベントと、モデルが観測した変化を別欄に置きます。

AWSの需要計画に関する公式文書は、予測を作った時点から実績化までのラグを設定し、その期間に対応する予測と実績でMAPE、WAPE、Biasなどを計算する仕組みを説明しています^[5]。一週先の補充判断を評価するのに、直前更新した予測を使うと未来情報が混ざります。自社でも「何週前の予測を採用したか」を固定します。

WAPE（加重絶対誤差率）
Σ|実績 - 予測| ÷ Σ実績 × 100
Bias（符号付きの偏り）
Σ(予測 - 実績) ÷ Σ実績 × 100
例: 4週間の実績 100, 120, 80, 100
予測 110, 100, 90, 120
WAPE = (10 + 20 + 10 + 20) ÷ 400 × 100 = 15%
Bias = (10 - 20 + 10 + 20) ÷ 400 × 100 = 5%

WAPE 15％だけを見ると方向が分かりませんが、Bias 5％なら全体として過大予測です。商品・拠点別では過大と過小が相殺されるため、集計値と最低粒度を並べます。実績ゼロの商品では比率が定義しにくく、少量・間欠需要では一回の注文で率が大きく変わります。その場合は絶対数量誤差、欠品日数、予測区間内に実績が入った割合を併用します。

モデル変更前後の比較は、共通の期間と商品集合を使い、予測から実績確定までのラグもそろえます。新商品を片方だけ除外したり、欠品で販売できなかった数量を実需要と見なしたりすると、良く見える方向へ数字が動きます。予測値を人が上書きしたときは、理由、変更前後、承認者を残し、上書きの有無別に結果を確認します。

補充案は在庫リスクと制約から組み立てる

補充・移送では、予測需要、利用可能在庫、確定入荷、安全在庫、リードタイムから不足日を計算します。その後で、同じ商品が余る拠点、移送時間、輸送単位、期限、保管能力を確認します。需要が増えたから即時発注するのではなく、既発注の前倒し、拠点間移送、代替商品、配分変更、販促抑制を比較します。

発注メールを処理するエージェントには、注文番号と変更箇所を明示させます。仕入先メールから「24個入りから20個入りへ変更」を読んだ場合、数量24を20へ置換するだけでは総個数が変わります。梱包単位、ケース数、単価、税、納期への波及を差分表にし、元メールと注文書の両方を購買担当が開けるようにします。

自動反映の上限を置く場合も、金額だけでなく商品リスクを使います。低額でも医薬品、危険物、温度管理品、顧客専用品は別承認です。数量が上限内でも、初回取引、振込先変更、契約外価格、期限が短いロット、品質保留中の商品が含まれれば処理を止めます。

完了は注文更新ではなく、仕入先の確認、ERPへの反映、在庫見通しの再計算までです。返信だけ送って計画値が変わらない状態や、ERPだけ変わって倉庫の入荷予約が古い状態を未完了として検知します。

配送例外は代替案の比較までに限定する

配送エージェントは、遅延便、影響注文、顧客受付時間、積載、温度帯、運送契約を集め、待機、別便、別拠点出荷、特急、分納の候補を並べます。最短到着だけを最適化すると、運賃上限、CO2、荷役能力、ドライバーの拘束、顧客の受入不可時間を無視します。

1. 事実確認：便、車両、積荷、現在地、遅延理由、更新時刻を確定する。
2. 影響抽出：注文、数量、顧客約束、後続便、倉庫作業を一覧にする。
3. 代替作成：到着見込、追加費、積替え、温度・品質、必要承認を案ごと示す。
4. 担当判断：輸送・営業・品質が採用案と顧客説明を承認する。
5. 実行確認：TMS、運送会社、倉庫、顧客の状態が同じ案へ更新されたか確認する。

災害、通行止め、倉庫停止、温度逸脱、盗難、事故、通関保留は通常の遅延分類へ混ぜません。担当者と連絡先を変え、品質・法務・危機管理へ切り替えます。位置情報が一定時間更新されない場合は現在地を推測せず、最後に確認できた場所と時刻を表示します。

採用しなかった案も保存します。追加費が高い、別顧客を欠品させる、温度保証がないなどの理由が残れば、次回は実行不能な候補を早く除外できます。運送会社の評価へ使う場合は、一件の遅延を担当者個人の責任へ直結させず、天候、荷主待機、倉庫混雑など原因区分を確認します。

架空卸売業の想定例で導入差を計算する

次は、1,200 SKUを三つの物流拠点で扱う架空の卸売業を想定した計算です。公表事例の効果を換算したものではありません。月に需要例外180件、仕入先メール320件、在庫移送候補60件を確認し、担当者の時間価値を一時間4,800円、データ基盤・AI・保守の月額を250,000円と置きます。

短縮時間
12.0 + 18.7 + 9.0 = 39.7時間/月
作業時間の価値
39.7時間 × 4,800円 = 190,560円/月
作業時間だけの差
190,560円 - 月額250,000円 = -59,440円
想定上、廃棄・特急費を月100,000円回避した場合
190,560円 + 100,000円 - 250,000円 = 40,560円/月

この前提では、作業短縮だけでは月59,440円のマイナスです。廃棄・特急費を100,000円減らせた場合に月40,560円のプラスになります。ただし100,000円は計画値です。実測では、期限切れ廃棄の単位原価、特急便の通常便との差額、AI提案を採用した案件番号を結び、通常運用でも回避できた費用を除きます。

欠品による売上機会を入れる場合、欠品数量すべてが失注したとは限りません。後日購入、代替品、別拠点出荷、受注取消を分け、粗利で計算します。在庫金額が減ってもサービス水準が下がれば成功ではありません。納期遵守、充足率、期限切れ、在庫日数、特急費、確認分数を同じ期間で見ます。

試行費には初期連携、マスタ修正、教育、監視、例外調査も加えます。既存担当者の残業が減らず、別の確認作業が増えた場合は短縮を便益へ数えません。二か月目以降に対象を増やすときは、件数に比例しない基盤費と、件数に比例する人の確認費を分けて更新します。

現場で詰まるデータと組織の障壁

最も多い障壁は、販売・在庫・発注・輸送の更新周期が違うことです。受注は分単位、WMS在庫は作業確定時、仕入先回答はメール受信時、輸送位置は車両ごとの間隔で変わります。異なる時点の情報を「現在」として結合すると、すでに引き当てた在庫を余剰と判定します。各値に基準時刻と有効期限を持たせます。

第二は需要の欠測です。欠品中の販売実績はゼロでも、本当の需要がゼロとは限りません。第三は単位です。個、ケース、パレット、重量、容積が混在し、丸め方で発注量が変わります。第四はリードタイムの固定化で、曜日、繁忙期、通関、工場休暇による差を一つの平均へ押し込みます。第五は所有者の不在で、AI提案を採る責任も却下する責任も決まりません。

部門KPIの衝突も設計対象です。購買は単価、倉庫は保管効率、輸送は積載率、営業は欠品回避を優先しやすく、単一指標を最大化すると別部門へ費用が移ります。提案票に、在庫金額、サービス、輸送費、廃棄、CO2の変化を並べ、どの条件を優先したかを承認者が残します。

外部パートナーのデータがメール・PDFだけでも試行は可能ですが、自動実行の信頼度は上げません。注文番号がない連絡、添付と本文が矛盾する連絡、多言語で単位が曖昧な連絡は人へ渡します。取引先に無断で学習へ二次利用せず、契約上の利用目的と保存期間を確認します。

継続判定と発注・配送を止める条件

経済産業省・総務省の「AI事業者ガイドライン第1.2版」は、AIの開発・提供・利用でリスクに応じた対応を行うための公的資料として、チェックリストやワークシートも公開しています^[6]。物流で特定の発注上限を定める法令ではないため、自社の契約、商品規制、物流手順へ置き換えて使います。

即時停止するのは、振込先や価格を未承認で変更した、別顧客の在庫を割り当てた、品質保留品を利用可能と扱った、温度帯の異なる便を選んだ、契約外の運送会社へ個人・貨物情報を送った場合です。資格情報を無効化し、注文・在庫・輸送のどこまで反映されたかを確認して、購買、品質、物流、情報セキュリティへ案件を渡します。

通常の差戻しは、予測データが一日以上遅い、仕入先回答が曖昧、在庫差異が許容幅を超える、顧客受付時間が取れないケースです。この場合は全システムを止めず、該当SKU・拠点・注文だけを保留します。担当者が補正した値は元値を消さず、理由と有効期限を付けます。

二週間ごとに、提案採用率、確認分数、誤更新、欠品、廃棄、特急費を確認します。採用率が低くても、例外を正しく人へ渡せているなら即座に失敗とはしません。反対に採用率が高くても、担当者が内容を読まず承認しているなら監視が機能していないため、無作為抽出で原記録との照合を行います。

再現に必要な前提と向かないケース

再現に必要なのは、商品・拠点・取引先の一意なID、数量単位、在庫状態、注文・出荷イベント、予測期間、承認権限です。試行対象の一商品群と一物流レーンで、受注から納品まで追跡できれば開始できます。正常納品、欠品、余剰、分納、返品、遅延、情報不足を含む代表案件を用意し、計画・購買・倉庫・輸送が期待する処理を先に書きます。

担当は、需要計画の所有者、在庫・購買の承認者、輸送例外の責任者、連携・権限を守るシステム管理者に分けます。取引先との契約変更、危険物、医薬品、冷凍・冷蔵、通関、リコールは品質・法務・貿易管理などの専門部署へ切り替えます。AIの提案が早くても必要書類と許可を省略しません。

向かないのは、在庫数が棚卸しまで分からない、商品の単位換算が確定していない、発注権限が口頭、遅延の更新が数日後、結果指標を取得できない組織です。また、一品ごとの特注品、履歴のない新商品、需要が極端に間欠的な保守部品、災害支援や人命に関わる緊急配送では、統計予測や通常ルールだけで割当を決められません。

短い賞味期限の商品は予測誤差が小さくても、受入可能日数や先入先出が崩れると廃棄が増えます。高価な低回転品では、欠品率を下げるための在庫増が資金を圧迫します。サービス水準、在庫、廃棄、輸送費のどれを守るかを商品群ごとに決められない場合は、エージェント導入より在庫方針の合意が先です。導入を見送る条件

「AIが全体最適を判断する」という説明だけで、制約、承認者、原記録、戻し方を示せない場合は運用へ進めません。提案を実行しない観測モードでデータ差異を洗い出し、人の計画会議で同じ入力を使える状態を作ります。

物流AIエージェントのFAQ

需要予測の精度が高ければ自動発注へ進めますか？

精度だけでは進めません。最小発注量、賞味期限、保管能力、供給制約、販促、欠品時の影響を満たすか確認し、金額と数量の上限を持つ承認を残します。集計精度が良くても、重要商品だけ過小予測なら発注には使えません。

AIエージェントは配送遅延時に運送会社を変更できますか？

初期範囲は代替案の提示までです。運賃、温度帯、危険物、荷役条件、契約、顧客約束を担当者が確認し、既存の配車・発注手順で変更します。事故・災害・通関保留は通常の遅延から分けて危機管理へ渡します。

新商品にも既存商品の予測モデルを使えますか？

販売履歴がない新商品へ同じ精度を期待できません。類似商品の根拠、初回投入上限、短い見直し周期を設定し、人の計画値と別列で管理します。発売後の実績がたまるまでは、販促、配荷店舗、欠品による需要欠測を担当者が補足します。

どの質問でも、予測や候補が業務システムへ届く前に、商品・数量・拠点・日付・承認者を照合できることが前提です。追跡できないデータは精度スコアで補わず、案件を保留して正本を確認します。

一つの物流レーンで始める行動

過去八週間から、一商品群・一出荷拠点・一仕入先または一配送レーンを選び、通常20件、欠品10件、余剰5件、変更メール10件、配送例外5件を抽出します。各案件へ、使用した予測、在庫時点、注文版、数量単位、承認者、結果、確認分数を記載します。正本が判別できない案件は無理に埋めず、データ修正の対象として数えます。

最初の成果物は自動発注ではなく、毎朝の例外一覧にします。需要差、欠品予定日、余剰拠点、仕入先変更、遅延便を別分類で示し、元データへのリンクと更新時刻を付けます。価格変更、振込先、品質保留、危険物、温度帯、顧客配分を検出したら購買・品質・物流の担当へ切り替え、エージェントから更新できない設定にします。

四週間後、50件すべてで誤結合、確認分数、採否理由、欠品・廃棄・特急費を確認します。公表事例のMAPE 5％やメール半減を自社の合格値として借りず、同じ商品・期間・ラグで取った導入前の数字と比べます。限定運用へ進むのは、重大誤更新がなく、原記録を追え、サービス水準を落とさず確認負荷が下がった範囲だけです。

参考文献・出典

1. 国土交通省 公的ガイドライン改訂発表「「物流情報標準ガイドライン」をver3.00に改訂しました」（2025年2月7日、2026年7月30日参照）
2. GS1 公式標準「EPCIS & CBV」（EPCIS/CBV 2.0の機能・利用例、2026年7月30日参照）
3. AWS Customer Case Study「Amazon Pharmacy Increases Forecast Accuracy and Reduces Manual Efforts Using AWS Supply Chain」（顧客公表値を掲載、2026年7月30日参照）
4. Microsoft Customer Stories「Farmlands Cooperative: Sowing the seeds of innovation with autonomous agents in Dynamics 365」（2026年3月25日公開、2026年7月30日参照）
5. AWS 公式ドキュメント「Monitoring Forecast Performance」（予測ラグと精度指標の仕様、2026年7月30日参照）
6. 経済産業省・総務省 公的ガイドライン「AI事業者ガイドライン（第1.2版）」（2026年4月1日最終更新、2026年7月30日参照）