AIが実在庫と有効在庫を取り違える2026｜受注可能数が3.3倍ずれるのを防ぐ5つの手順

ECサイトや受発注の在庫をAIに確認させると、「在庫は100個あります」と返ってくることがあります。ところが実際に受けられる注文は30個しかない、ということが起こります。原因は、倉庫にある数と、これから売ってよい数が別物だからです。

この取り違えがやっかいなのは、AIの答えが嘘ではない点です。棚には確かに100個あります。ただし70個はすでに他の注文に割り当てられています。この記事では、どれだけずれるのか、なぜ起きるのか、そして受注可能数を正しく出させる5つの手順を解説します。

同じ100個が「100個売れる」にも「30個しか売れない」にもなる

在庫には少なくとも3つの数があります。実在庫、引当済み在庫、有効在庫です。呼び方は会社やシステムによって変わりますが、意味の区別は共通しています。

実在庫は、倉庫の棚に物理的にある数です。引当済み在庫は、受注済みでまだ出荷していない注文に割り当てられた数です。有効在庫は、実在庫から引当済み在庫を引いた残りで、これがこれから売ってよい数になります。

100個から70個を引くと30個になる

ある商品の実在庫が100個、引当済みが70個だとします。有効在庫は30個です。ここでAIに「在庫はいくつですか」と聞くと、在庫テーブルの数量列を読んで100個と答えます。

この100個を受注可能数だと思って販売すると、70個分が出荷できません。受注可能数として見れば、100個と30個は3.3倍の差です。差の70個は、そのまま欠品連絡とお詫びの件数になります。

ずれは売れている商品ほど大きくなる

回転の遅い商品なら引当済みは少なく、実在庫と有効在庫はほぼ一致します。問題になるのは、売れている商品です。セール期間や新商品の発売直後は引当済みが積み上がり、実在庫の大部分を占めます。

つまり、取り違えの影響が最も大きくなるのは、いちばん売りたい商品のいちばん売れている時期です。平常時に検証して「ほぼ合っている」と判断すると、繁忙期に破綻します。

取り違えが起きやすい4つの場面

「在庫」という言葉をそのまま渡す

日本語の「在庫」は、社内でも人によって指すものが違います。倉庫担当は実在庫、EC担当は有効在庫、経理は棚卸資産の金額を思い浮かべます。この曖昧さを解消しないまま指示を出すと、AIはそのときどきで解釈を選びます。

同じ会話の中でも揺れます。前半では有効在庫で答え、後半では実在庫で答えることがあります。どちらも「在庫」としか書かれないため、出力を眺めても判別できません。

システムごとに列名の意味が違う

倉庫管理システムのquantity列が実在庫を指す一方で、ECカート側のstock列が有効在庫を指す、ということがよくあります。CSVを渡して集計させると、AIは列名の字面から意味を推測します。

英語の列名はさらに紛らわしくなります。on_hand、available、reservedといった語は、製品によって定義が違います。列の定義書がないままCSVを渡すのは避けてください。列そのものがずれる問題はAIが出力したCSVの列がずれる問題の記事で扱っています。

入荷予定を在庫に足してしまう

来週入荷予定の200個を有効在庫に足すと、数字の上では販売可能数が増えます。しかし入荷が遅れれば、その200個分はそのまま納期遅延になります。

入荷予定を含めた数は、有効在庫とは別の指標として扱ってください。予約販売として先に売るのか、入荷後に売るのかは商品ごとの判断です。AIに自動で足させる指示は出さないでください。

複数チャネルで同じ在庫を共有している

自社ECとモール2つで同じ倉庫の在庫を売っている場合、引当はチャネルをまたいで発生します。自社ECのデータだけをAIに渡すと、モール側の引当が見えません。

各チャネルが枠を別々に確保していると、確保数の合計が実在庫を超えることもあります。チャネル横断で数えるのか、チャネルごとの配分で数えるのかを先に決めてください。集計の重なりについては合計行の二重計上を防ぐ記事もあわせてご確認ください。

受注可能数を正しく出させる5つの手順

手順1：「在庫」と書かず計算式で指示する

プロンプトに「在庫を教えて」ではなく「有効在庫（実在庫 − 引当済み在庫）を出してください」と書きます。日本語の語を渡すのではなく、引き算の式そのものを渡すのが要点です。

社内で呼び方が決まっていない場合は、この機会に定義を1枚にまとめてください。文書になっていない定義は、AIにも人にも正しく伝わりません。

手順2：使う列を名指しで固定する

「quantity列を実在庫、reserved列を引当済みとして扱ってください」と、列名と意味の対応を明示します。AIに列の意味を推測させないことが目的です。

定例で回す集計なら、この対応表をプロンプトのテンプレートに固定で入れておきます。毎回書く手間は数行ですが、推測を挟ませない効果は大きくなります。

手順3：時点を日時で指定する

引当済み在庫は刻々と変わります。「今日の在庫」ではなく「2026年9月13日9時00分時点」のように、日付と時刻で指定してください。

データの抽出時刻も一緒に記録します。抽出が9時、AIの計算が11時なら、その2時間分の受注は反映されていません。レポートには抽出時刻を必ず書き添えてください。

手順4：計算式と内訳を出力させる

結果の数字だけでなく、「実在庫100 − 引当済み70 = 有効在庫30」の形で内訳を出させます。内訳があれば、どの数から引いたのかが一目で分かります。

内訳が出ていれば、在庫担当者が目視で確認できます。数字だけのレポートは、間違っていても気づけません。

手順5：マイナスをゼロに丸めさせない

有効在庫がマイナスになったら、それは計算結果ではなく異常のサインです。引当が実在庫を超えている、つまりすでに売り過ぎている状態です。

「マイナスの場合はゼロにせず、マイナスのまま出力して警告を付けてください」と指示します。ゼロに丸めると、単なる在庫切れと売り過ぎが同じ表示になり、対応の緊急度を見誤ります。

よくある質問

安全在庫はどう扱いますか

安全在庫は、有効在庫からさらに差し引く枠として扱うのが一般的です。有効在庫30個のうち10個を安全在庫とするなら、販売可能数は20個になります。この差し引きもAIに任せず、計算式として明示してください。

リアルタイムに近づける方法はありますか

受注可否の判断はAIではなく在庫管理システム側で行い、AIには結果の説明やレポート作成を任せる分担が安全です。AIに最終判断をさせる構成では、データ更新の遅れがそのまま二重販売になります。

AIの出した在庫数が実地棚卸と合いません

まず、比べている数が同じ種類かを確認してください。実地棚卸で数えるのは実在庫です。有効在庫と比べれば、引当済みのぶんだけ必ずずれます。種類が同じであれば、次に抽出時点と対象倉庫の範囲を確認します。

まとめ

在庫の取り違えは、計算ミスではなく言葉の曖昧さから生まれます。棚にある100個と、売ってよい30個は別の数です。どちらも「在庫」と呼ばれるため、出力された数字を見るだけでは区別できません。

防ぐ方法は単純です。計算式で指示する、列名と意味を固定する、時点を日時で指定する、内訳を出力させる、マイナスを丸めさせない。この5つを在庫レポートのテンプレートに組み込めば、毎回の手間はほとんど増えません。

在庫の数字は、いくつあるかより、いつ時点の何の数かが大切です。内訳と時刻が書いてあるレポートは、欠品のお詫びを出す前に間違いに気づかせてくれます。