AI発注は、在庫を見て自動的に大量発注する仕組みではありません。 実務では、在庫監視、発注候補の作成、異常検知、承認、発注実行を分け、低リスクな条件だけを自動化する設計が重要です。
特にECでは、セール予定、仕入価格、入荷予定、最低発注数量、在庫差異などが発注判断へ影響します。 AIの予測精度だけを見るのではなく、「どの条件なら自動実行し、どの条件なら人へ戻すか」を先に決めてください。
この記事の要点
- AI発注は「監視→提案→承認→限定自動化」の順で進める
- 発注数量の計算とAIの判断補助を分ける
- 高額・異常数量・新商品・セール商品は人へ戻す
- 仕入価格やリードタイムの大幅な変化も承認対象にする
- 在庫データに異常があるときは発注そのものを停止する
- 承認・修正・却下の履歴を保存する
- 自動化率より欠品・過剰在庫・発注修正率を見る
AI発注とは？発注候補と例外判断を支援する仕組み
AI発注とは、販売実績、現在庫、入荷予定、仕入先のリードタイム、発注ロットなどの情報から、発注が必要な商品や数量を判断する仕組みです。
ただし、AIだけで最終発注数量を決めて仕入先へ送信する必要はありません。
実務では、次のように役割を分ける方が安全です。
| 処理 | 向いている仕組み |
|---|---|
| 現在庫の取得 | 在庫管理システム |
| 発注点の計算 | ルール・計算式 |
| 需要予測 | 予測モデル・AI |
| 異常商品の抽出 | ルール＋AI |
| 発注理由の説明 | AI |
| 承認 | 担当者・責任者 |
| 発注書送信 | 購買・発注システム |
AIに計算と責任をまとめて渡さない
発注点、最低発注数量、発注ロット、上限金額など明確なルールはシステム側で保持し、AIは予測・例外検知・理由説明などへ使う方が検証しやすくなります。
AI発注と通常の自動発注の違い
通常の自動発注は、あらかじめ設定した条件を使って処理します。
たとえば「販売可能在庫が発注点を下回ったら担当者へ通知する」といった処理です。
一方、AIを組み合わせると、複数の情報から通常と異なる状態を抽出したり、発注候補の理由を説明したりできます。
| 項目 | ルール型 | AI活用 |
|---|---|---|
| 低在庫判定 | 設定した発注点で判定 | 販売速度や入荷予定も参考にする |
| 発注数量 | 設定ロット・計算式 | 需要予測を加えて候補を作る |
| 異常検知 | 設定済み条件のみ | 複数データから注意対象を抽出 |
| 説明 | 条件に合致したことを表示 | 提案理由を要約する |
| 例外対応 | ルール外は人が確認 | 確認優先度の判断を補助 |
固定条件で解決できる処理へ無理にAIを使う必要はありません。
AI発注は現在どこまで自動化できる？
発注・購買領域では、すでに発注候補の生成、購買依頼作成、承認への振り分け、仕入先との情報処理などを支援する仕組みが提供されています。
ただし、ここで重要なのは「AIが使えるか」ではなく、EC事業者が利用している在庫管理・ERP・購買システムと連携できるかです。
| 処理 | 現在の実用性 | 人の関与 |
|---|---|---|
| 在庫監視 | 自動化しやすい | 例外のみ確認 |
| 補充候補抽出 | 自動化しやすい | 結果を確認 |
| 発注数量提案 | 実用化されている | 重要SKUは確認 |
| 発注要求作成 | 実用化されている | 条件によって承認 |
| 承認振り分け | 自動化可能 | 高リスクのみ人へ |
| 発注実行 | システム連携次第 | 限定条件で自動化 |
| 仕入先変更 | 慎重に扱う | 原則として人が確認 |
企業向けAI機能＝そのまま小規模ECで使えるわけではない
大規模なERP・SCM製品では高度な購買AIが提供されていますが、利用中のECカートや在庫管理サービスで同じ機能が使えるとは限りません。 API、CSV、権限、発注先システムとの連携可否を確認してください。
AI発注は4段階で自動化する
最初から完全自動発注を目指す必要はありません。 自動化範囲を次の4段階に分けます。
在庫監視
現在庫、入荷予定、発注点、販売速度を定期的に確認し、発注判断が必要なSKUだけを抽出します。
発注候補の提案
発注時期、数量、根拠となるデータを担当者へ表示します。まだ発注処理は行いません。
人が承認して発注
AIまたはシステムが発注案を作り、担当者が承認・修正・却下してから実行します。
低リスク条件のみ自動発注
十分な履歴があり、金額・数量・仕入先などが設定範囲内の注文だけを自動実行します。 条件から外れた注文は承認へ戻します。
目標は「完全自動」ではない
担当者が全SKUを見る状態から、例外だけを見る状態へ変えられれば、AI発注を導入する価値があります。
AI発注で人が承認すべき7つの条件
承認基準は他社の金額や割合をそのまま使わず、自社の仕入額、粗利、販売履歴、資金繰りから決めます。
1．発注金額が大きい
1回の誤発注で資金繰りへの影響が大きい注文は、金額上限を設定して人へ戻します。
2．通常より数量が大きく変わる
過去の発注数量や需要予測から大きく外れた提案は、セール・データ異常・一時的需要ではないか確認します。
3．新商品で履歴が少ない
販売履歴が十分でない商品は予測の不確実性が高いため、自動発注の対象から外します。
4．セール・広告予定がある
通常時と販売速度が変わるため、販促開始前と終了後の需要を分けて確認します。
5．仕入価格が変わった
数量が同じでも仕入総額や粗利が変わるため、価格変更時は原価を確認します。
6．リードタイムが変わった
仕入先の納期が通常より長い・短い場合は、発注点や安全在庫の前提も確認します。
7．仕入先・商品条件が変わった
最低発注数量、発注ロット、取引条件、仕入先が変更された場合は自動処理を止めます。
承認条件は「金額×異常×データ信頼性」で作る
| 条件 | AI・システムの動作 | 人の対応 |
|---|---|---|
| 通常範囲の定番SKU | 発注候補を作成 | 設定次第で自動化 |
| 社内上限を超える金額 | 実行停止 | 担当者・責任者承認 |
| 通常数量から大きく乖離 | 要確認 | 原因確認 |
| 新商品 | 提案のみ | 数量判断 |
| セール対象 | 提案のみ | 販促計画と照合 |
| 仕入価格変更 | 実行停止 | 原価確認 |
| 仕入先変更 | 実行停止 | 取引条件確認 |
AI発注を自動停止すべき条件
承認条件とは別に、データそのものを信用できないときは発注案を作らせない方が安全です。
- 在庫管理システムと倉庫在庫が一致しない
- 在庫データの最終更新が失敗している
- 販売可能在庫が不明
- 入荷予定が取得できない
- 仕入単価が未登録
- 発注ロット・最低発注数量が不明
- 仕入先情報が欠落している
- API・CSV連携でエラーが発生している
- 同一発注がすでに送信済みか確認できない
データ異常時は「推測して発注」させない
在庫や仕入条件が欠落している場合は、AIが不足部分を推測して発注するのではなく、処理を停止して担当者へ通知する設計にします。
AI発注に必要なデータ
AIモデルより先に、発注判断に使うデータを揃えます。
| データ | 用途 |
|---|---|
| SKU | 商品を一意に識別 |
| 販売可能在庫 | 現在販売できる数量 |
| 入荷予定 | 発注済み在庫を考慮 |
| 販売履歴 | 販売速度・需要予測 |
| 発注履歴 | 通常数量・通常周期を確認 |
| 安全在庫 | 欠品リスクを調整 |
| リードタイム | 発注時期を判断 |
| 最低発注数量 | 発注可能数量を制約 |
| 発注ロット | 仕入先の発注単位へ合わせる |
| 仕入単価 | 発注金額・粗利確認 |
| 仕入先 | 発注先を特定 |
| 販促予定 | 一時的な需要変動を判断 |
AI発注の承認ワークフローを作る
発注案が作られた後の流れを固定します。
- 在庫・販売データを取得する
- 発注候補を抽出する
- 必要数量を計算する
- AIが異常・例外を確認する
- 承認条件に該当するか判定する
- 必要な場合は担当者へ通知する
- 承認後に発注処理へ送る
- 実行結果を記録する
担当者が確認するときは、発注数量だけでなく次を同じ画面に表示できると判断しやすくなります。
- 現在庫
- 入荷予定
- 予測販売数
- 発注数量
- 発注金額
- 前回発注数量
- 仕入単価の変化
- リードタイム
- AI・システムが提案した理由
承認ボタンだけでは不足
「承認」「修正」「却下」と、修正理由を残せるようにします。 人の修正履歴は、承認ルールや予測条件を改善する材料になります。
AI発注では権限・ログ・停止機能を先に決める
自動発注では、動かす機能と同じくらい止める機能が重要です。
最低限用意したい停止単位
- 全自動発注の停止
- SKU単位の停止
- 仕入先単位の停止
- カテゴリ単位の停止
残しておきたい操作ログ
- 発注候補を作成した日時
- 使用した在庫・需要データ
- 提案数量
- 提案理由
- 承認者
- 修正前後の数量
- 修正・却下理由
- 発注実行日時
- 発注先
- 処理エラー
後から「なぜこの発注が実行されたのか」を追跡できない仕組みは、発注額が増えるほど運用リスクが高くなります。
AI発注で確認するKPI
自動化率だけを追わないことが重要です。
| KPI | 確認すること |
|---|---|
| 発注確認時間 | 担当者の確認作業が減ったか |
| 発注修正率 | AI・システムの提案を人がどれだけ直したか |
| 発注却下率 | 不要な発注候補が多くないか |
| 欠品件数 | 必要な発注が遅れていないか |
| 過剰在庫 | 不要な仕入れが増えていないか |
| 緊急発注件数 | 通常発注でカバーできているか |
| 在庫金額 | 自動化後に資金が在庫へ偏っていないか |
| エラー停止件数 | データ連携に問題がないか |
発注時間だけ減っても成功とは限らない
作業時間が減っても、欠品や過剰在庫、不要な仕入れが増えていれば改善とは言えません。 時間と在庫健全性を同時に確認します。
AI発注を導入する7つの手順
発注判断の現状を整理する
誰が、どのデータを見て、どの条件で発注しているかを書き出します。
在庫・仕入データを整える
SKU、在庫、入荷予定、発注ロット、単価、仕入先、リードタイムを確認します。
承認条件を決める
金額、数量、新商品、販促、価格変動など、人へ戻す条件を文章化します。
停止条件を決める
在庫差異、連携エラー、単価未登録など、自動処理を禁止する状態を決めます。
最初は提案だけで運用する
AIまたはシステムの提案と、実際に担当者が行った発注を比較します。
承認制へ進める
精度とデータ連携が安定したら、発注案作成まで自動化し、人が承認して実行します。
低リスクSKUだけ自動実行する
十分な実績がある定番SKUなど、条件が安定している範囲だけを対象にします。
AI発注の導入チェックリスト
- SKUが重複していない
- 販売可能在庫を取得できる
- 入荷予定を取得できる
- 販売履歴を取得できる
- 発注履歴を取得できる
- 仕入単価を管理している
- 最低発注数量を登録している
- 発注ロットを登録している
- 仕入先リードタイムを把握している
- 承認が必要な金額を決めている
- 数量異常の判定条件がある
- 新商品を自動発注対象から分けられる
- 販促予定を発注判断へ反映できる
- データ異常時に自動停止できる
- 担当者が発注数量を修正できる
- 承認・修正・却下履歴を残せる
- 発注を緊急停止できる
- 処理エラーを確認できる
- 欠品・過剰在庫を測定できる
- 導入前後の発注作業時間を比較できる
AI発注に関するFAQ
Q. AIだけで発注を完全自動化できますか？
システム上は条件に応じて自動実行できる場合がありますが、すべての商品を無条件で自動発注する必要はありません。 高額商品、新商品、販促商品、価格や納期が変化した商品などは人の承認を残す方が管理しやすくなります。
Q. AI発注と需要予測は同じですか？
同じではありません。 需要予測は今後どれくらい売れるかを予測する処理で、AI発注ではその結果に現在庫、入荷予定、安全在庫、発注ロット、仕入条件などを組み合わせて発注判断へつなげます。
Q. 小規模ECでもAI発注は必要ですか？
商品数や発注回数が少なく、手作業で正確に管理できているなら急いで導入する必要はありません。 発注候補の確認に時間がかかる、欠品や過剰在庫が増える、SKUが増えて人だけでは確認しにくい場合に検討します。
Q. 何円以上なら人が承認すべきですか？
共通の金額基準はありません。 自社の月間仕入額、粗利、資金繰り、1回の誤発注で許容できる損失をもとに上限を決めてください。
Q. AIが出した数量をそのまま使ってよいですか？
導入初期はそのまま使わず、人の最終発注数量と比較します。 提案数量、実際の数量、修正理由を記録すると、どの条件でAIやルールが外れやすいか確認できます。
Q. AI発注で最も重要な機能は何ですか？
予測機能だけでなく、承認、権限、操作ログ、エラー通知、緊急停止を確認してください。 誤った発注候補が出たときに、人が止めて原因を追跡できることが重要です。
まとめ｜AI発注は「何を自動化するか」より「どこで止めるか」を決める
AI発注は、全発注を人からAIへ置き換えることが目的ではありません。
在庫監視や発注候補作成を自動化し、金額・数量・商品・仕入条件に異常がある発注だけを人へ戻すことで、確認作業を絞り込めます。
AI発注の基本順序
- 在庫監視
- 発注候補の作成
- 人による承認
- 低リスク条件だけ自動実行
まず自社の発注履歴を確認し、「必ず人が確認する条件」と「データ異常時に停止する条件」を1枚の表にしてください。 AIツールを選ぶのは、そのルールを整理した後で十分です。
参考にした公式情報
- AWS Supply Chain「Auto Replenishment business workflow」
- AWS Supply Chain「Configuring Auto Replenishment」
- Oracle「AI Agent: Purchase Requisition Creation Guide」
- Microsoft Dynamics 365「Procurement Agent」
- SAP「Flexible Workflow for Purchase Orders」
AI機能、自動承認、連携可能なシステム、API、権限設定などは製品・契約・更新時期によって異なります。 導入時には利用中の在庫管理・購買システムの最新公式仕様を確認してください。