ショートピック（棚に現物が足りない）が起きたとき、代替ロケーションへの再引当・対象棚の在庫0調整・注文保留のどれを選ぶか。出荷SLAと棚差のどちらを優先し、どの金額・数量から人の承認に戻すかを、WMS APIとルール／AIで組み立てる判断設計として整理します。
ピッキングの現場で、指示されたロケーションに行ったが数が足りない、あるいは現物が無い——この状態をショートピックと呼びます。このとき現場で起きているのは、作業者が商品を取り違えたことでも、取り忘れたことでもありません。WMS上の論理在庫が「ある」と言っているのに、棚に現物が「ない」という食い違いが、ピックという行為によって初めて発見された、という状態です。
ピック作業そのものの正確性——誤品・数量違い・取り忘れをどう検知して出荷前に止めるか——は、本記事とは別の設計対象です。そちらは物流のピッキングミス防止（ピック作業自体の改善はこちら）で、カメラ・画像AIによる商品照合や数量カウントの考え方として整理しています。工程全体の高度化の順序については倉庫ピッキング自動化の進め方が地図になります。
本記事が扱うのは、その手前でも後でもなく、現物が無いと分かった後に、在庫データと注文をどう扱うかという分岐だけです。作業品質の話と在庫整合の話は、関わる人も承認経路も判断材料も異なるため、同じ「ピッキングの課題」として一括りにすると、どちらの打ち手も中途半端になりやすいと考えます。
業務仕様として確認できる事実（FACT）を先に置きます。一般的なWMSは、在庫を「品目 × ロケーション × ロット／期限 × ステータス」といった単位で保持し、受注に対する引当（アロケーション）はこの論理在庫に対して行われます。ピッキングリストは、その引当結果を作業指示に展開したものです。したがってショートピックは、引当済みの論理在庫に対応する現物が見つからない状態を指し、放置すれば同じロケーションが次の波でも引当対象として選ばれ続けます。
同じくFACTとして、在庫の数量を実地の結果に合わせて書き換える操作（在庫調整・棚卸調整）は、通常のWMS／基幹系で理由コードの付与と操作者の記録を伴う独立したトランザクションとして扱われ、入出庫とは別の権限で管理されるのが一般的な設計です。つまり「再引当」と「在庫0調整」は、システム上そもそも重さの違う操作として定義されています。
ここからは当社の応用仮説（Nsight VIEW）です。ショートピックの発生そのものより運用上の負担になりうるのは、発生後の判断が現場の裁量に委ねられている点だと考えます。ある作業者は隣の棚を探しに行き、別の作業者はハンディで欠品報告だけ入れて次へ進み、責任者は締め時間の直前にまとめて相談を受ける——という状態では、同じ事象に対して出荷結果も在庫データの状態もばらつきます。判断基準を明文化し、どこまでを自動で回し、どこから人に戻すかを決めることが、技術導入より先に来る整理だと考えられます。
ショートピック発生時に取りうる選択肢を、性質で並べて比較します。ポイントは「出荷を継続できるか」「在庫データを書き換えるか」「間違えたときに巻き戻せるか」の3軸です。この3軸で見ると、3つの選択肢はまったく異なる性格を持つことが分かります。
| 選択肢 | 出荷への影響 | 在庫データへの影響 | 巻き戻しやすさ | 検討に向く場面 |
|---|---|---|---|---|
| 代替ロケーションへ再引当 | 継続できる可能性がある（動線と時間のコストは増える） | 引当先が変わるのみで、在庫数そのものは書き換えない | 比較的容易（引当の付け替えで戻せる） | 同一品目の在庫が他ロケーションに存在し、締め時間に余裕がある場合 |
| 対象棚を在庫0調整 | 当該明細は欠品確定になるか、他在庫への再引当へ連鎖する | 論理在庫を書き換え、以後その棚は引当対象から外れる | 容易ではない（取り消しには逆調整と理由の記録が必要） | 探索を尽くして現物が無いと確認でき、後続の誤引当を止めたい場合 |
| 注文を保留 | 止まる（納期・SLAに直接影響する） | 書き換えない（引当は保持されたまま） | 容易（保留解除で戻せる） | 判断材料が足りず、誤った出荷や誤った調整のほうが損失が大きい場合 |
代替ロケーションへの再引当は、在庫数を書き換えないという点で最も可逆性の高い選択肢です。一方で、可能であることと、してよいことは別だと考えます。代替先が別フロアや別エリアであれば動線コストが増え、その1件のために波動全体のピッキング順序が崩れる可能性があります。また、引き当て直した在庫が、締め時間の近い別注文のために確保されていたものであれば、問題を別の注文へ移しただけになりかねません。ロット指定・期限先入先出・出荷先別の在庫区分がある場合は、そもそも代替が許されないこともあります。
対象ロケーションの在庫を0に調整すれば、以後その棚は引当候補から外れ、同じショートピックが繰り返されることを防げます。効果は明快ですが、代償は論理在庫を書き換えたという事実が残ることです。もし現物が別段や隣接ロケーションに置かれていただけであれば、調整によって帳簿上の在庫を不当に減らし、棚差を別の形で作り直したことになります。だからこそ、探索を尽くしたかの確認と、理由コードを伴う承認が意味を持つと考えます。
3つ目は、出荷を止めて判断を人に戻す選択です。一見すると後ろ向きですが、誤った再引当や誤った在庫調整が引き起こす後処理のコストを考えると、情報が足りない局面で意図的に保留することには合理性があると考えられます。重要なのは、保留が「誰かが気づくまで放置される箱」にならないよう、保留キューの責任者と解除期限をあらかじめ決めておくことです。
現場からいただく相談の中心は、「出荷を止めたくないが、在庫の整合も崩したくない」という二律背反にどう線を引くか、という点です。この二つは同時に最大化できないため、どの条件でどちらを優先するかを事前に決めておく設計が要になると考えます。以下はNsight VIEWとしての設計案であり、単一の正解ではなく、自社の取引条件に合わせて調整する前提のたたき台です。
実務的には、次のような順序で分岐を組む設計が考えられます。第一に、締め時間と代替在庫の有無で再引当の可否を判定する。第二に、再引当が不可なら、金額・数量・品目区分の閾値で「自動で欠品確定へ進めてよい範囲」と「承認へ戻す範囲」を分ける。第三に、在庫0調整はこの流れとは切り離し、探索結果の記録が揃ってから別トランザクションとして承認に回す。つまり、出荷の判断と在庫データの判断を同じ画面・同じワンクリックに載せないことが、設計上の勘所になると考えます。
金額や数量の閾値は、最初から正しい値を当てられるものではないと考えます。運用開始時はやや保守的に（承認へ戻る件数が増える方向に）置き、承認された判断の履歴を蓄積してから、承認者が一貫して同じ判断を下している領域を自動化の範囲へ広げる——という順序が現実的です。逆に、承認者の判断が割れる領域は、自動化してはいけない領域を示すシグナルとして読むことができると考えられます。
ここまでは「起きた後」の話ですが、同じロケーションで繰り返しショートピックが起きるなら、原因側の調査が本筋です。入庫時のロケーション登録、補充のタイミング、返品・仮置きの戻し漏れなど、在庫が合わなくなる工程は複数あります。工程の可視化によって、どの工程の後で在庫が合わなくなるのかを追えるようにしておくことが、調整の頻度そのものを下げる方向の打ち手になりうると考えます。
判断基準が決まったら、それをどう動かすかという実装の話になります。ここでの基本方針として当社が現実的と考えるのは、再引当は条件付きで自動、在庫調整は承認後に確定という非対称な切り分けです。可逆性の高い操作は自動化の恩恵が大きく、不可逆な操作は承認のコストを払う価値がある、という整理になります。
既存のWMSやハンディ運用を置き換えるのではなく、その上に判断の層を乗せる設計が望ましいと考えます。必要になるのは、ショートピック事象の受け取り（ハンディからの欠品報告や数量差異の入力）、同一品目の在庫照会、引当の付け替え、在庫調整の申請、保留の設定・解除、といったインターフェースです。自社のWMSでどの操作がAPIとして公開され、どの操作が画面操作でしか行えないかを最初に棚卸ししておかないと、設計が絵に描いた餅になります。ハンディ端末の運用や倉庫AIの取り組みも、接続設計を考える際の参考になると考えます。
締め時間の判定、ロット指定の可否、金額・数量の閾値といった条件は、決定的なルールとして明示的に書くべき領域です。判断の根拠が追跡可能でなければ、在庫にかかわる操作の説明責任を果たせないためです。一方、Nsight VIEWとしてAIの寄与を期待しうるのは、次のような「候補を作り、根拠を添えて提示する」部分と考えられます。
いずれも提案であって決定ではありません。提示には必ず根拠（なぜその候補か、どのデータを見たか）を添え、承認者が根拠を否定できる形にしておくことが、運用に載せる条件になると考えます。
再引当を自動化する場合も、無条件ではなく、たとえば次のような条件付きにする設計が考えられます。同一品目・同一ロット条件を満たす在庫が、同一エリア内に必要数以上ある。締め時間まで一定以上の余裕がある。代替先の在庫が他注文に引き当てられていない。対象がリスク区分の品目でない。これらを満たさない場合は自動処理を行わず、候補提示にとどめて人に渡す——という形です。自動化の範囲を条件で囲い、囲いの外は人に返す構造にしておけば、想定外のケースで黙って誤った処理が進むことを避けやすくなると考えられます。
在庫データを書き換える仕組みを扱う以上、どこまでを機械が進め、どこからを人が確定するのかを曖昧にしたまま運用に入るべきではないと考えます。以下は、AIやルールエンジンが代替しない領域として明示しておきたい範囲です。
承認を挟む設計には、承認者の時間という原資が必要です。閾値を厳しくすれば安全側に寄りますが、承認待ちの行列が伸びて出荷が滞れば、結局は現場の裁量で処理される運用に戻りかねません。設計段階で「1日あたり何件が承認に回る想定か」「承認者は何人で、1件あたり何分かけられるか」を見積もり、成立しないなら閾値か承認フローのどちらかを見直す——という検算を、Nsightは重要な工程と考えます。
誰が何を承認したかだけでなく、そのとき何を見て判断したか（提示された候補、探索の履歴、想定された影響）まで記録されていることが、後から運用を改善するための材料になると考えられます。承認履歴が「承認：担当A」だけでは、閾値の妥当性を検証できません。
在庫データに触れる自動化は、検知や可視化の仕組みと違い、間違えたときに状態が残る点が特徴です。当社が設計の相談を受ける中で論点になりやすいポイントを整理します。いずれもPoCの段階で確かめておきたい項目です。
本テーマは、いきなり全品目・全工程に適用するのではなく、事象の実態を数え、限定範囲で判断支援を試し、自動化の範囲を条件付きで広げる、という順序が現実的と考えます。
発生件数、発生ロケーションの偏り、発生時間帯、対象品目の特性、そして発生後に現場が実際に何を選んだか（探しに行った／欠品報告した／責任者に相談した）を記録します。ここで、再引当で救えたはずの件数がどれだけあるかが見えれば、仕組みの効果の上限が概算できます。あわせて、判断に要した時間と、締め時間に間に合わなかった明細も記録します。
最初の段階では自動処理を行わず、ショートピック発生時に代替候補と推奨アクション（再引当／調整申請／保留）を提示するだけの運用を試す方法があります。現場や責任者が実際にどれだけ提案を採用したか、採用しなかった場合の理由は何かを集めることで、ルールと閾値の妥当性を、在庫を書き換えずに検証できると考えられます。
提案の採用率と理由が安定してきた範囲に限って、再引当の条件付き自動化を適用し、在庫調整は申請から承認までのフローとして接続します。範囲の拡大は、品目区分や金額帯を単位に段階的に行い、拡大のたびに指標を確認する進め方が安全と考えます。
これらに加えて、承認へ戻った件数と承認者の所要時間も併せて見ないと、現場の負荷が承認者へ移動しただけという結果を見落としかねないと考えます。数値目標は、自社の現状値を測ったうえで設定する性質のものであり、事前に一般的な水準を約束できる類のものではありません。
当社は、現場の事象と既存システムの制約を踏まえて、判断基準の明文化・自動化範囲の切り分け・評価指標の設計を一緒に整理することを重視しています。WMSのどの操作がAPIで扱えるか、どの判断を人に残すか、どの指標で拡大可否を決めるか——この3点を最初に決めておくことが、PoCが検証として成立するための条件だと考えます。PoC・導入コンサルティングの枠組みでは、検証範囲の設計から評価までを対象に議論します。倉庫全体の段階的な高度化については倉庫の物理AIロードマップも見取り図としてご参照ください。
工程の順序としては先に検討する価値があると考えられます。再引当は在庫データそのものを書き換えずに出荷を継続できる選択で、判断を誤った場合の巻き戻しが比較的容易だからです。ただし「再引当が可能か」と「再引当してよいか」は別の問いです。代替ロケーションが遠い、後続の出荷波動で他注文の引当を奪う、ロット・賞味期限の指定に反する、といった副作用が起こりうるため、可否だけでなく影響まで見たうえで判定する設計が前提になると考えます。
在庫0調整は論理在庫を書き換える操作であり、誤れば棚差を別の形で作り直すことになります。調整の前段として、隣接ロケーション・上段・入荷仮置き・返品仮置きなどの探索を尽くしたかの確認が必要です。当社は、調整の提案（候補・理由コード・想定影響の提示）までを自動化し、確定は承認を経る設計を基本と考えます。自動確定の範囲を設けるとしても、金額・数量の上限や品目区分で限定し、上限を超えるものは人に戻す線引きが現実的と考えられます。
どちらか一方が常に正しいという設計は現実的ではないと考えます。締め時間が迫った注文では再引当や分納で出荷を継続し、棚差の解消は後追いの棚卸タスクへ回す優先順もあり得ますし、棚差が繰り返し発生しているロケーションでは、出荷を一時保留してでも原因を止めるほうが結果的に損失が小さい場合もあります。重要なのは、金額・数量・顧客区分・締め時間といった軸で優先の境界を事前に決めておき、境界付近のケースは人の判断に戻すことだと考えます。
AIに期待しうるのは、代替在庫の候補提示、注文優先度の推定、後続波動への影響の見積もりといった、根拠付きの提案を作る部分と考えられます。一方で、在庫調整の最終承認、取引先との納期・数量の確定、欠品連絡や価格・契約解釈にかかわる判断、作業者の安全にかかわる判断は、人が確定する範囲です。AIの出力は判断材料であって確定行為の代替ではない、という線引きを運用規程と画面設計の両方に落としておくことをお勧めします。
本テーマでは、再引当成功率（提案した代替ロケーションで実際にピックできた割合）、誤調整率（在庫0調整の後に現物が見つかった等、取り消しが必要になった割合）、出荷遅延（当日締めに間に合わなかった明細の割合と遅延時間）、復旧時間（ショートピック検知から出荷可否が確定するまでの時間）の4点を軸に置く考え方があります。あわせて、承認に戻した件数と承認者の所要時間も記録しないと、現場の負荷が別の場所へ移っただけかどうかを判断できないと考えます。
ピック作業そのものの正確性、つまり誤品・数量違い・取り忘れをどう検知して止めるかは別テーマで、当社では「物流のピッキングミス防止」の記事で扱っています。本記事が扱うのは、現物が棚に無いと分かった後に、在庫データと注文をどう扱うかという分岐です。前者は作業の実行品質、後者は在庫の整合と出荷継続の意思決定であり、担当者も承認経路も異なるため、分けて設計することをお勧めします。
再引当・在庫0調整・保留のどこまでを自動で回し、どこから承認に戻すかは、既存WMSの制約と取引条件に即して決める設計事項です。判断基準の明文化と評価指標の置き方から、一緒に整理します。
判断設計の相談を申し込む