在庫管理システムを作る前に、入出庫から計算した数、棚で数えた数、新しい注文に使える数を分け、同じ商品・場所・時刻で比べられるようにします。
約9分で読めます
棚にある7個のうち、新しい注文に使えるのは何個？在庫管理を作る前に決めること
棚に残る数と、新しい注文に使える数を区別して考えます。2拠点の入出庫例で残高を計算し、記録する項目を整理。返品、取消、単位換算を自社の条件で試すための在庫照合表も使えます。
影山 湧亮 / NeoLogic株式会社 代表取締役。元警視庁。現場業務の整理と生成AI活用・Webシステム開発を一貫して担当。
たとえば、月末の棚卸しで、画面には7個あるのに棚では6個しか見つからない。履歴を調べても、いつから違っていたのか分からない。在庫管理を作り直したくなるのは、こうした場面です。
自作・外注の前に、2拠点の入出庫例で在庫数の計算と日々の記録方法を確かめます。
差異の原因には、入力の遅れ、数え間違い、返品の未計上、箱と個の取り違えなどがあります。現在数の上書きは、その原因を追いにくくする要因の一つです。自作でも外注でも、普段の入出庫だけでなく、訂正や棚卸しまで具体例で試してから開発範囲を決めます。
棚にある7個のうち、新しい注文に使えるのは何個か
「在庫数」という一つの欄に、記録上の数量、実際に数えた数量、注文へ回せる数量を混ぜると、担当者によって見ている数字が変わります。
| 数量の名前 | 何を表すか |
|---|---|
| 帳簿在庫 | 開始残高と入出庫の記録から求めた数量 |
| 実棚数量 | 決めた場所・時点で実際に数えた数量 |
| 引当済み | 受注などのために確保した数量 |
| 保留 | 検品や品質確認が終わるまで使わない数量 |
| 引当可能数 | 新しい注文へ確保できる数量 |
たとえば、同じ倉庫にある帳簿在庫7個のうち、引当済みが2個、保留が1個なら、新しい注文に使えるのは4個です。引当済みと保留が重ならず、未入荷分を含めない例です（想定例）。実棚数量は別に数え、帳簿の7個と比較します。
図1 帳簿在庫の内訳と、実棚数量との照合。引当済みと保留は重ならない想定例です。
引当を取り消すと、確保していた数量が空きます。まだ出荷していなければ、帳簿在庫そのものは増えません。一方、引当済みの商品を出荷するときは、出庫と引当の消し込みを対応させます。両方を在庫から差し引くと、二重に減らしてしまいます。
未入荷の商品まで予約できる業務では、入荷予定の扱いも決めます。たとえばMicrosoftの在庫管理製品でも、設定により予約可能数に入荷予定を含める場合があります。同じ名前の数字でも計算条件が違うため、導入先の定義を読んでください（出典：Microsoft Learn「Inventory on-hand list」）。
商品コードと単位と保管場所をそろえる
同じ商品でも、個、箱、ケースが混ざると数量を単純に足せません。基準単位を決め、入力時の単位と、その時点の換算率を残します。たとえば1箱6個の商品を2箱入庫するなら、記録は「2箱・1箱6個・基準数量12個」です。あとから入数が変わっても、過去の12個を新しい換算率で計算し直さないようにします。
GS1のGTINは、商品を取引単位ごとに識別するコードです。単品とケース、入数が違う集合包装には、それぞれに対応するコードがあります。自社の商品コードとGTINの対応に加え、コードが指す単位と入数を記録します。バーコードを読めるだけでは、箱を個へ換算する条件までは決まりません（出典：GS1 Japan「GTINとは」、「GTIN設定の基本原則」）。
場所は倉庫だけで足りるか、棚の位置まで必要かを決めます。倉庫間の移動に時間がかかるなら、出発から到着までを「移動中」として追い、受け入れる前の数量を入庫先で使える数に含めるかを決めます。
入出庫と訂正の記録を残す
入出庫台帳には、在庫が増減した理由を一件ずつ残します。最低限そろえたいのは、商品、場所、日時、入出庫の区分、数量と単位、理由、対応する受注・発注・移動指示です。訂正では、元の記録を特定できる番号も残します。
通常の入庫・出庫に加え、試したい場面は次の四つです。
- 取消では、元の記録と打ち消す数量を対応させる。
- 返品では、受け入れた数量と、再び出荷できる数量を分ける。
- 拠点間移動では、出庫元と入庫先を一つの移動番号でつなぐ。
- 棚卸差異や破損・廃棄では、数量と調整理由を残す。
誤った記録を消して現在数だけ直すのではなく、元の移動を打ち消し、正しい移動を追加します。たとえば4個の出荷を3個へ直すなら、元の出荷を取り消す4個と、正しい出荷の3個を対応させます。実際に返品された場合とは、理由を分けて記録します。
返品1個を受け取っても、検品待ちならすぐには新しい注文へ回せません。帳簿在庫と保留をそれぞれ1個増やす想定では、引当可能数は変わりません。検品後に使えると分かった時点で保留を解除します。
マイナス在庫を認める業務では、対象、許容する数量、解消期限と担当者を決めます。数字を保存できることと、現場で出荷できることは別に確かめてください。
5件の処理で2拠点の残高を追う
一つの商品を東京と大阪の倉庫で管理する記入例です（想定例）。単位は個、開始残高は東京・大阪とも0個です。次の5件が成立した場合、残高はこう変わります。
| 処理 | 成立した増減 | 東京 | 大阪 |
|---|---|---|---|
| 1 入荷 | 東京に12個、大阪に8個 | 12 | 8 |
| 2 出荷 | 東京から4個 | 8 | 8 |
| 3 出荷 | 東京から3個 | 5 | 8 |
| 4 移動 | 大阪から東京へ2個 | 7 | 6 |
| 5 調整 | 大阪に1個を加算 | 7 | 7 |
表1 1商品・2拠点の想定例。残高の単位は個。拠点間移動は出庫と入庫が成立した状態です。
東京は「0＋12−4−3＋2＝7個」、大阪は「0＋8−2＋1＝7個」です。入荷と移動はそれぞれ2拠点に増減があるため、拠点別に書くと7行の明細になります。5件という数は処理のまとまりを数えています。
自社の商品一つを、同じ入出庫表で追ってみてください。記入例と空欄表は、下のExcelで使えます。
NeoLogicの簡略模型では、2026年8月2日にこの5件の処理を試し、東京・大阪とも7個になりました。同じ処理を送り直しても数量は増えず、古い状態をもとにした更新1件は差し戻されました。模型は一つのプログラム内で動かしたもので、実倉庫や実データベース、取り置き・取消・返品・単位換算は検証対象に含みません。
自社の検証環境でも同じ入出庫を試し、東京・大阪がそれぞれ7個になるか見てください。同じ処理を送り直した後も、残高と成立した明細数が変わらないことを確かめます。7行の計算表（CSV）で、拠点ごとの増減を追えます。
在庫照合表（Excel）は、記入見本、入力用、追加確認例で構成しています。入出庫の数量から計算する残高とは別に、照合対象の数量を入力します。見本の照合対象は模型で得た7個です。実棚数量には、現物を数えた値を入れます。自社で使うときは、同じ商品・場所・時刻・単位にそろえた数量を記入してください。
印刷して記入する場合は、記入見本（PDF）と空欄版（PDF）を使えます。
5個の棚から6個を動かそうとすると、どうなるか
品目・数量の在庫の操作例は、場所別の数と移動の関係を試す画面です。初期選択の「六角ナット M6 ステンレス」は倉庫1に5個、倉庫2に4個、合計9個あります。前節の東京・大阪の7個ずつとは別の架空データです。
2026年11月1日に、移動元を倉庫1、移動先を倉庫2にして、次を操作しました。
| 入力と操作 | 画面で確認した結果 |
|---|---|
| 数量6、メモ「棚の整理」で移動を記録 | 「記録できません：倉庫1には5個しかありません。」と表示され、記録のボタンも押せなかった |
| 数量を4へ直して移動を記録 | 「M14を記録しました」と出て、倉庫1は1個、倉庫2は8個になった。「この品目の動き」にM14が加わった |
移動後も1＋8＝9個です。全体の在庫を増やす入庫と違い、二つの場所の内訳が変わります。「移動できること」を要件にする際は、総数だけでなく、元と先の数、同じ移動番号で履歴を追えることまで書いてください。
この画面は数量と場所の操作見本です。引当済み・検品保留・移動中まで必要な業務では、冒頭の7個の内訳と同様に区分を追加して試します。また、別の担当者が同時に同じ5個を動かす試験は、実際に使う保存先をつないだ環境で行います。一人の画面で不足を止められた結果だけでは、同時入力まで判断できません。
開始残高と棚卸しの時点を決める
既存Excelから移す場合は、基準日の開始在庫と、未完了の入出庫・引当を分けます。過去の全履歴を移さない場合も、どの数字を開始残高としたかを記録します。
棚卸しでは、基準時刻の帳簿在庫、実棚数量、差異、理由、確認した担当者を一組で残します。数えている途中の入出庫を止めるのか、基準時刻に合わせて差し引くのかも決めます。
たとえば帳簿が7個、実棚が6個なら、差はマイナス1個です。すぐに帳簿を6個へ直す前に、未入力の出荷、別の棚への移動、返品、単位の違いを確かめます。調整が必要なら、確認した理由と1個を減らす記録を残します。原因が不明のまま調整した場合も、不明であることと、その後に調べる担当を記録します。
移動中の品物は、出庫元と入庫先で重ねて数えたり、両方から漏らしたりしやすい箇所です。どちらで、どの時点の数量として照合するかを先に決めておきます。
外部連携の再送で二重に減らさない
外部の受注サービスと連携するときは、同じ注文が届き直しても、引当や出庫を二重に計上しないようにします。注文番号だけでは一部出荷や訂正を区別できない場合があるため、何を一回の処理として識別するかを決めます。
連携が止まったときには、相手側の注文と自社の記録を照合し、足りない処理を特定してから再開します。確認する項目はAPI連携の要件｜待ち時間・再送・二重実行でも整理しています。
自作と外注を同じ記入例で比べる
在庫の標準的な入出庫で足りるなら、既製SaaSが有力です。独自の引当、複数単位、設備連携、固有帳票が事業の中心なら、設定や追加開発、独自システムを比較します。
比較するときは、同じ入出庫の記入例を使います。入荷、出荷、移動、棚卸調整に加え、引当取消、返品の検品待ち、箱から個への換算まで試し、期待した残高と履歴になるか確かめます。中古品のように一点ごとに状態と原価が違う在庫は、数ではなく一点ずつ管理します（中古品の査定から個体在庫までの整理例）。
現場の業務条件と、日々の記録を誰が担うかを決め、SaaS・パッケージ・独自開発｜3年・5年の費用比較の判断軸で選びます。
少ない商品と拠点から試し、引当や同時入力など必要な条件を確かめます。共同編集や閲覧範囲も課題なら、Excel共有をWeb化する前に決める3つのことも参照してください。費用は作る人の時間と保守まで含め、システム開発費は何で決まる？予算別3案の比較と同じ範囲で比べます。
開発前に自社の入出庫を書き出す
まず一つの商品について、入荷から出荷・訂正・棚卸しまでを書き、各時点の帳簿在庫と引当可能数を確かめてください。数字が合わない箇所や、担当者によって扱いが違う箇所が、先に決める業務ルールです。
在庫の種類に合わせて相談先を選ぶ
薬局で包装単位と棚の数量をそろえたい場合は、薬局の在庫照合・発注準備を支えるシステム開発が相談先になります。個体ごとの貸出・返却が中心なら備品・設備・貸出品管理、工事現場をまたぐ工具や仮設資材なら資機材管理の条件も確認してください。
その記入例をもとに、最初に作る機能と費用を左右する条件を整理できます。受注やほかの業務も含めた整理は、業務システム開発の進め方をご覧ください。
帳簿と棚の数量が違うときは、基準時刻をそろえて、後日入力や重複出庫を調べる順番があります（在庫が合わないときに調べる順番｜棚卸差異と訂正）。
他社の商品を預かる倉庫では、同じ品番でも荷主ごとに残数を確かめる必要があります（倉庫の荷主別在庫｜入出庫と棚卸しを混ぜない管理）。
参考出典
あわせて読む
画面に出ないので再実行したら、注文が二重に。API連携で先に決めること
画面に結果が出なくても、注文の登録は済んでいることがあります。注文登録とAI要約の例で、待つ・結果を調べる・やり直す条件を比較。連携を頼む前に決めたい項目と、障害時の判断表を使えます。
同じ型番が3台あるのに、注文に回せるのは0。中古品の個体在庫と原価の管理
同じ型番でも状態が違う3点を、個体番号で見分けます。査定額と買取の合意額を分け、受入、補修、販売可能、売約までを追う例。未確定の費用、返品、既製POSで確かめる項目も整理できます。