AIで在庫の補充候補を整理するときは、倉庫にある数と、新しい依頼へ使える数を分けます。引当済みの品や検品待ちの品まで足すと、台帳上は足りていても、必要な日に使える在庫が足りない場合があります。
この記事では、架空の3商品から不足候補と確認質問を作ります。到達点は発注書ではなく、商品別の計算根拠と入荷確認の一覧です。実在庫の取得、AIによる抽出、需要予測、発注、納品は検証していません。
目次
在庫の状態と、数える対象をそろえる
最初に、商品コード、拠点、集計日時、数量単位を固定します。同じ商品名でもサイズ違いをまとめず、別拠点の在庫は移動できると確認するまで合算しません。今回の例は1拠点、全商品が個数単位、2026年10月20日9時の日本時間の記録とします。
Shopifyの公式説明では、On handは拠点にある在庫で、Committed・Unavailable・Availableの合計です。Availableは販売できる数、Committedは注文などへ確保した数、Unavailableは破損や検品などの理由で販売できない数です。Incomingは移動中などの入荷予定で、受け入れてAvailableへ変わるまでは販売可能在庫ではありません。Shopify:在庫の状態(新しいタブで開く)
以下では、この区別を参考に「手持ち」「引当済み」「使用不可」「使用可能」と呼びます。すべての在庫システムで同じ列名や計算規則になるとは限りません。自社の台帳で各状態が排他的か、数がどの時点で更新されるかを確認してから対応させます。
架空台帳を、元の状態を残して読む
表は横にスクロールできます
| 在庫行ID | 商品 | 手持ち | 引当済み | 使用不可 | 使用可能 |
|---|---|---|---|---|---|
| S01 | A | 100 | 30 | 10 | 60 |
| S02 | B | 70 | 10 | 0 | 60 |
| S03 | C | 30 | 5 | 5 | 20 |
この例では各行で「手持ち=引当済み+使用不可+使用可能」が成り立ちます。Aなら100−30−10=60です。すでに使用可能60という列を使う場合、さらに引当済み30を引くと、同じ制約を二度差し引いてしまいます。
一方、手持ち100だけを使えば、引当済み・使用不可を新しい依頼へ使えるように見せてしまいます。AIへは、原資料の列と比較用の列を両方渡し、計算後もS01へ戻れる形にします。
数が一致しない行を見つけても、帳尻を合わせるためにAIへどれかの値を訂正させません。集計時刻のずれ、状態定義、移動中の処理などを確認する行として残します。欠けた値を0で補うことと、資料に0と書いてあることも区別します。
必要数は、既存の引当と重ならない範囲で置く
次は10月22日までに新たに用意したい、架空の追加依頼です。台帳の「引当済み」に含まれる既存注文は、この追加依頼へ重ねていません。必要数は説明用の指定値であり、過去販売から推定した需要ではありません。
表は横にスクロールできます
| 依頼行ID | 商品 | 追加の必要数 | 使用可能数 | 現時点の不足候補 |
|---|---|---|---|---|
| R01 | A | 80 | 60 | 20 |
| R02 | B | 50 | 60 | 0 |
| R03 | C | 30 | 20 | 10 |
不足候補は、商品ごとに max(必要数−使用可能数, 0)で計算します。Bには10個の余りがありますが、AやCへ代替できる設定ではありません。3商品を先に合算すると必要160、使用可能140で差20になりますが、商品別不足の合計は20+0+10=30です。この例では、合算した差20を補充数として使えません。
30は3商品の不足候補を個数で足した集計値です。「同じ品を30個発注すればよい」という意味ではありません。Aを20個、Cを10個という商品別の内訳を残します。
入荷予定は、数量だけで不足を埋めない
表は横にスクロールできます
| 入荷行ID | 商品 | 入荷予定数 | 資料にある予定 | 今回の扱い |
|---|---|---|---|---|
| P01 | A | 40 | 10月25日入荷予定 | 必要日の10月22日より後。今回の不足を解消する数へ入れない |
| P02 | C | 25 | 日付の記載なし | 間に合うか不明。使用可能へ足さない |
Aは「使用可能60+入荷予定40=100だから、必要80を満たす」とは書けません。予定どおりでも必要日より後です。Cも25個という量だけでは、10月22日に使えると判断できません。現在の不足候補はA20・C10のまま残し、入荷前倒しや納期確認が可能かを別の質問にします。
必要日より前の予定が見つかった場合でも、入荷予定は現在の使用可能数とは別です。受入、検品、使用可能になる時点、対象拠点へ届く時点を確認し、将来の条件付きシナリオを作るならその前提を明記します。予定日を実納品日へ言い換えません。
掲載例の計算を検算する
次は、上の固定例をPythonで照合するコードです。商品別不足と、先に合算した差の違いも検査します。入力はコード内の架空値で、台帳へ接続する処理はありません。
stock = {
"A": (100, 30, 10, 60),
"B": (70, 10, 0, 60),
"C": (30, 5, 5, 20),
}
need = {"A": 80, "B": 50, "C": 30}
assert set(stock) == set(need)
for on_hand, committed, unavailable, available in stock.values():
assert on_hand == committed + unavailable + available
shortage = {
sku: max(need[sku] - values[3], 0)
for sku, values in stock.items()
}
assert shortage == {"A": 20, "B": 0, "C": 10}
assert sum(shortage.values()) == 30
pooled_gap = max(sum(need.values()) - sum(v[3] for v in stock.values()), 0)
assert pooled_gap == 20
print(shortage, sum(shortage.values()), pooled_gap)
辞書へ格納する前の重複商品行、負数や欠損、拠点違いを検出する汎用の入力検査は含みません。実台帳では商品と拠点などのキーで行を識別し、許容する在庫状態を確認してから集計します。この固定例の検算が通っても、実システムの在庫が正しいことにはなりません。
AIへ依頼する出力と、確認質問を固定する
架空の在庫S01~S03、追加依頼R01~R03、入荷予定P01~P02を整理してください。
追加依頼は既存の引当済み注文と重なっていません。
使用可能数から既存の引当をもう一度差し引かないでください。
商品ごとの不足候補、計算式、在庫行ID、依頼行IDを返してください。
入荷予定は現在の使用可能数へ足さず、日付と状態を別欄で示してください。
入荷未定を0個や納期内へ置き換えず、必要な確認質問を返してください。
異なる商品間で余剰を相殺しないでください。
需要予測、安全在庫の最適化、発注数の確定、発注処理は行わないでください。
この入力から作る確認質問は、「P01の40個は10月22日に使用可能となる前倒しが可能か」「P02の25個の入荷予定日と使用可能になる日はいつか」です。どちらも実際に問い合わせた結果ではなく、担当者が確認するための文案です。
報告文なら、「10月20日9時の使用可能在庫と、既存引当と重ならない追加依頼を比較した結果、A20個・C10個の不足候補。Bの余剰10個は代替不可の前提で相殺していない。Aの入荷予定は必要日より後、Cは日付未記載のため、入荷を加えた充足判定はしていない」とまとめられます。
補充候補と、発注の決定を分ける
不足候補は、そのまま発注数量にはなりません。すでに発注した入荷予定の調整、他拠点からの移動、依頼日の変更、調達単位、最小発注量などで次の行動が変わります。今回の例には、その条件がありません。AIに「A20・C10を今すぐ注文」と補完させず、確認先と未確定条件を残します。
整理後は、商品、拠点、集計日時、状態別数量、追加必要数、計算式、入荷行、確認質問が対応しているかを見ます。確認回答で条件が変わったら、新しい時点の表を作り、前の不足候補を残します。用途に合う数量が見えたことと、現場で品物を確保できたことを別の完了条件として管理してください。
参考資料
公式資料の確認日:2026年10月20日。商品、在庫、追加依頼、入荷予定、報告文は独自の架空例です。掲載コードと計算をローカルで検査しました。実台帳、Shopify管理画面、AI抽出、需要予測、発注、納品、画面表示は未検証です。
