「帳簿では在庫が500個あるはずなのに、数えたら498個しかない」。物流倉庫の現場では、こうした実在庫と帳簿のズレ、いわゆる在庫差異（棚卸差異）が日常的に起きています。少しのズレだからと放置すると、欠品による出荷遅延、過剰在庫による保管コストの増加、棚卸のたびに発生する原因調査の残業など、じわじわと利益を削っていきます。
「システム化したほうがいいのは分かっているが、何から手を付ければいいのか」「バーコードやWMSという言葉は聞くが、自社の倉庫に本当に合うのか」。発注を検討しながらも、そこで止まってしまう経営者・倉庫責任者の方は少なくありません。
先に、要点をまとめます。
- 在庫差異の大半は倉庫の能力の問題ではなく「手入力・目視カウント」という記録のしくみの問題で、構造的に発生し続ける
- バーコード・QRスキャン、WMS（倉庫管理システム）、ロケーション管理を組み合わせれば、記録ミスと差異の両方を減らせる
- 既製ソフトに現場を合わせるのではなく、自社の数え方・検品ルール・既存システムとの連携まで含めて設計できるかが、定着の分かれ目になる
本記事では、在庫差異がなぜ起きるのかを整理したうえで、バーコード・QRスキャンとWMS、ロケーション管理によって入出庫を正確に管理する考え方を、できるだけ具体的に解説します。後半では、こうした在庫管理の基盤を実際にどう設計するかも具体的に示します。
在庫差異はなぜ起きるのか
在庫差異の多くは「人の手による記録」と「ルールの曖昧さ」から生まれます。倉庫そのものの問題というより、記録のしくみの問題であることがほとんどです。
日本通運のDCXブログは、在庫不一致を「システム上の在庫数と実在庫が合わない状態」と定義し、その根本原因として次のような点を挙げています（出典: 日本通運「在庫不一致（棚卸差異）」 https://www.nipponexpress.com/dcx/jp/blog/warehouse-inventory-issues/index.html ）。
- 人的要因: 入庫・出荷時の数量のカウント間違い
- 業務プロセスの不備: ケースとピースなど「数え方のルール」が明確でない
- 消失在庫: 倉庫内での破損や期限切れの廃棄が在庫数に反映されない
- システムの問題: 複数システム間の連携ミスによるデータ同期のズレ
つまり、在庫差異は「誰かがサボったから起きる」のではなく、紙の入出庫伝票やExcelへの手入力、目視でのカウントといった「ミスが入り込みやすいやり方」を続けている限り、構造的に発生し続けます。気合いやダブルチェックの追加では根本解決になりにくい、というのが大切な前提です。
もう一つ見落とされがちなのが、原因の切り分けができていないという問題です。差異が見つかったとき、「入庫時のカウントミスなのか」「出庫時のピッキングミスなのか」「そもそもシステムへの反映漏れなのか」を特定できなければ、対策の打ちようがありません。紙の伝票だけでは「いつ・誰が・どの工程で」記録したかが残らないため、差異の原因究明そのものが手間のかかる作業になってしまいます。記録の粒度を細かくし、工程ごとにデータを残せる状態にしておくことが、差異を減らす以前に「差異の原因を特定できる状態」を作る第一歩になります。
在庫精度を「数字」で把握する
まず自社の在庫精度を数値で測ることが、改善の第一歩です。感覚ではなく、棚卸誤差率という共通のものさしで現状を把握します。
富士電機の物流倉庫向け解説によると、棚卸誤差率は「在庫差異量を棚卸後数量で割った比率」で求められ、一般に0.1%以下が望ましいとされています（出典: 富士電機「棚卸方法と棚卸誤差率」 https://www.fujielectric.co.jp/products/logistics/solution_detail/basic_tanaoroshi.html ）。逆に言えば、数%単位でズレている場合は、改善の余地が大きいサインと考えられます。
ここで重要なのは、棚卸のやり方そのものです。同じ解説では、一斉棚卸（期間を決めて一度に全商品を数える方法。通常作業を一時停止する必要がある）と、循環棚卸（エリアを限定して少しずつ進める方法）が紹介されており、循環棚卸は「在庫数に差異があった場合でも早期発見・修正できる」とされています。
年に1〜2回の一斉棚卸だけに頼ると、差異が見つかっても「いつ、どこで生まれたズレなのか」をさかのぼれず、原因不明のまま帳簿を合わせるしかなくなります。日々スキャンで記録を残し、エリアごとに循環棚卸を回せる状態にしておくことが、在庫精度を保つ近道です。
棚卸誤差率を継続的に測るうえでは、月ごと・エリアごとの推移を記録しておくことも欠かせません。今月は差異が減ったのか増えたのか、どのエリア・どの商品カテゴリで差異が集中しているのかが見える化されて初めて、次にどこへ手を打つべきかの判断ができます。単発の棚卸で終わらせず、数値を継続的に追える体制にしておくことが、改善サイクルを回すための土台になります。
バーコード・QRスキャンで記録のミスをなくす
手入力をスキャンに置き換えることは、在庫差異の主な原因の一つである「記録ミス」を減らすうえで効果的です。これは特別なことではなく、多くの倉庫で取り入れられている基本動作です。
入庫時に商品のバーコードやQRをスキャンすれば、品名・数量・入庫日・保管場所を機械的に読み取って登録できます。出庫やピッキングでも同じようにスキャンするため、伝票への転記や目視カウントに頼らずに記録が完成します。前述の日本通運の記事も、すべての在庫の動きをハンディターミナルなどでスキャン登録し、機械的に情報を読み取ることで手作業によるミスを減らせると述べています。
よりどころべーすの場合、この入出庫管理を貴社の業務フローに合わせて構築します。具体的には次のような形が考えられます。
- 入庫時にバーコード／QRをスキャンするだけで、品名・数量・ロケーションを自動登録
- 出庫・ピッキングもスキャンで完了し、在庫数がリアルタイムに更新される
- ピッキングリストを倉庫内の移動距離が短くなる順序で生成し、歩く距離を削減
- 棚卸もスキャンで進められるため、循環棚卸を日常業務に組み込みやすい
紙やExcelの二重入力がなくなることで、記録のための残業や、月末にまとめて転記する手間も同時に減っていきます。
導入時に検討しておきたいのが、既存の商品コード・型番との整合です。すでに社内で使っている品番体系がある場合、それをそのままバーコードの読み取り対象にできるかどうかで、現場の移行負担が大きく変わります。新しいコード体系を一から覚え直すのではなく、今の呼び方・型番のまま運用に乗せられる設計にしておくことが、スキャン運用を早く定着させるコツです。
ロケーション管理で「探す時間」と差異を同時に減らす
どこに何があるかをシステムで管理するロケーション管理は、ピッキングの効率化と在庫差異の削減を同時に進められる打ち手です。
商品の保管ルールが曖昧で、置き場所が人によって変わってしまう倉庫では、「あるはずの在庫が見つからない」「別の棚から間違って出荷する」といったことが起こりがちです。これはそのまま在庫差異につながります。WMSやロケーション管理の解説でも、保管ルールやロケーション管理ができていない場合に在庫差異が発生しやすいと繰り返し指摘されています（参考: 富士電機「棚卸方法と棚卸誤差率」ほか各WMS解説記事）。
ロケーションを番地のように管理し、スキャンで「どの棚に・何が・何個あるか」を常に最新化しておくと、次のような効果が見込めます。
- 新人や応援スタッフでも、表示されたロケーションへ行けばピッキングできる（探す時間が減り、属人化がやわらぐ）
- 先入れ先出しや賞味期限管理がしやすくなり、期限切れ廃棄による差異を抑えやすくなる
- 循環棚卸をエリア単位で計画的に回せる
物流倉庫の在庫差異をなくす入出庫管理の流れを示す図解。記録の課題（手入力・目視カウントによる数え間違い）から、バーコード・QRスキャンによる入出庫記録、ロケーション管理による棚番地の可視化、循環棚卸による早期発見までの4ステップを線形プロセスで表現している。
「ベテランの頭の中にしか倉庫のレイアウトがない」状態は、その人が休んだ日に品質が落ちるリスクそのものです。配車計画の属人化と同じ課題が、倉庫内でも起きていると考えると分かりやすいかもしれません。配車側の属人化解消については運送業の配車業務の属人化を解消する方法でも触れています。
ロケーション管理を機能させるには、棚の物理的な区画分けだけでなく、「移動したらすぐ記録する」という運用ルールとセットで設計する必要があります。棚番地のマスタだけ作っても、現場が移動のたびにスキャンする習慣を持たなければ、システム上のロケーション情報はすぐに実態とズレていきます。ここは仕組みと運用ルールの両輪で考えるべき部分です。
発注前に押さえておきたい3つの確認点
システムは「入れること」より「現場が使い続けられること」が成否を分けます。発注前に、次の3点を社内で確認しておくと失敗を避けやすくなります。
倉庫管理システム（WMS）は、かつては導入率が低い時期もありました。2022年に株式会社ダイアログが倉庫の在庫管理担当者などを対象に実施した調査では、在庫管理をExcelで行う企業が23.9%で最多、WMS利用は7.4%にとどまっていたと報告されています（出典: 株式会社ダイアログ プレスリリース https://prtimes.jp/main/html/rd/p/000000054.000053900.html ）。以前は「大手の倉庫が使うもの」という印象が強かったものの、近年はクラウド型の普及により、中小規模の倉庫でも導入しやすくなってきています。だからこそ、自社に合うかどうかの見極めが大切です。
確認しておきたいのは次の3点です。
- 現場のフローに合わせられるか: 既製の在庫管理ソフトに業務を寄せるのか、自社の入出庫フローに合わせて作るのか。扱う商品の数え方（ケース／ピース）や検品ルールが特殊なほど、業務に合わせた構築が効きます。
- 既存システムと連携できるか: 受注システムや会計、配車管理など、すでに使っているものとデータをつなげられるか。連携ミスは在庫差異の原因にもなるため、設計段階での確認が重要です。
- 定着まで伴走してくれるか: スキャン運用は、最初の数週間の習慣づけが肝心です。操作研修や運用開始後のサポートがあるかを確認しておきます。
この3点を考えるうえで土台になるのは、ツールの機能比較ではなく「自社の在庫差異という課題を、どう解くか」という業務側の整理です。どの工程で、どんな数え方のときに、ズレが生まれているのか。それを先に言語化しておけば、必要な機能の優先順位も、自社で作り込むべき範囲も自然と見えてきます。逆に課題の整理が後回しになると、機能は揃っているのに現場で使われない、という失敗につながりがちです。まずは現状のフローを書き出すところから始めるのが堅実です。
費用感の目安としては、既製のクラウド型WMSは月額数万円程度から利用できるものが多く、初期費用を抑えて素早く始められる一方、扱う商品や工程の特殊性が高いほど「型に合わせるための運用の工夫」が必要になりやすい傾向があります。逆に、自社の入出庫フローに合わせて一から作り込む場合は、初期投資は既製ソフトより大きくなりますが、現場のやり方を変えずに導入できるため、定着までの時間を短くできる場合があります。どちらが向いているかは、扱う商品点数や検品ルールの複雑さ、既存システムとの連携の要否によって変わるため、自社の業務量を整理したうえで比較するのが現実的です。
導入の進め方としては、おおむね次のような流れで検討している企業が多く見られます。まず現状の入出庫フロー・棚卸差異の発生状況を洗い出し、どの工程にどれだけの手間とミスが集中しているかを可視化します。次に、既製ソフトで足りる範囲と、自社独自のルールに合わせて作り込む必要がある範囲を切り分けます。そのうえで、バーコード運用とロケーション管理の設計に入り、一部エリアや一部商品カテゴリでの試験運用を経てから、倉庫全体へ展開していく進め方です。いきなり全商品・全エリアに導入するのではなく、影響範囲を区切って試してから広げるほうが、現場の混乱を抑えられます。
私たちなら物流倉庫の在庫管理基盤をこう設計する
ここまでは、在庫差異への一般的な対処の考え方を解説してきました。ここからは、よりどころべーすが実際にこの業種の在庫管理システムを受託するつもりで、仕組みの設計を具体的に書き下ろします。
データ設計: 入出庫記録・在庫マスタ・ロケーションマスタ・商品マスタを1つの基盤に集約します。入出庫記録は「いつ・誰が・どの商品を・どのロケーションで・何個」動かしたかを1件ずつ蓄積するログ形式にし、現在の在庫数はこのログの積み上げから算出します。これにより、差異が発生したときに「どの入出庫の記録が疑わしいか」を後から遡って特定できます。商品マスタには、ケース／ピースなど貴社の数え方のルールをそのまま反映させ、既製ソフトの型に合わせて数え方を変える必要をなくします。
情報の流れ: 倉庫スタッフはハンディ端末やスマホでスキャンするだけで入出庫を記録し、内容の入力や転記作業は発生しません。倉庫責任者は棚卸誤差率の推移やエリアごとの差異件数をダッシュボードで確認し、差異が増えているエリアや商品カテゴリを早期に把握できます。経営者は月次のサマリーで、欠品件数・過剰在庫額・棚卸差異の傾向を数値で把握し、現場に降りなくても状況を判断できます。
AIの回答設計: 社内AIチャットに「先週、ロケーションA-12で差異が出た商品は何ですか」と尋ねると、入出庫ログとロケーションマスタを突き合わせ、「A-12では商品コードXXXが3件の出庫記録に対して在庫が2個少なく、直近の入庫記録との整合を確認する必要があります」といった形で、根拠となる記録を示しながら回答します。物流ナレッジbotの仕組みを在庫差異の原因究明にも応用し、担当者が過去の記録を手作業で洗い直す手間を減らします。
権限・運用ルール: ロケーションマスタや商品マスタの登録・変更は倉庫責任者のみが行い、日々の入出庫スキャンは現場スタッフ全員が行える権限設計にします。棚卸結果の確定・帳簿の修正は責任者の承認を経てから反映される運用にすることで、記録の正確性と現場の入力しやすさを両立させます。
既存環境との連携・移行: 現在Excelで管理している在庫台帳や、受注システム・会計システムとのデータ連携は、既存の商品コード体系を維持したまま段階的に移行できるように設計します。全商品・全エリアを一度に切り替えるのではなく、差異が発生しやすいエリアや商品カテゴリから先行導入し、運用が定着してから対象を広げていく進め方も選べます。
以下は、よりどころべーすの物流・運送向けダッシュボードのデモ画面（サンプルデータ）です。実際の導入企業のデータではなく、機能のイメージを伝えるための架空の数値です。
よりどころべーすの物流・運送向けダッシュボードのデモ画面（サンプルデータ）。本日配送件数・遅延件数・車両稼働率のKPIカード、配送件数の月次推移グラフ、担当者別の直近タスク一覧、業務データから自動生成されるAIインサイトのコメントが1画面にまとまっている。
この画面のように、KPIカード・推移グラフ・担当者別タスク・AIインサイトを1画面にまとめる設計を、在庫管理の指標（棚卸誤差率の推移、エリア別の差異件数、欠品・過剰在庫の件数など）に置き換えて構築することで、倉庫責任者は複数の帳票を見比べなくても、日々の在庫状況を1画面で把握できるようになります。AIインサイトの欄には、たとえば「今週のロケーションB-05での差異件数が先週比で増加しています。入庫時のスキャン漏れの可能性があるため確認を推奨します」といった形で、日々のデータから気づきにくい変化を自動で拾い上げる使い方も想定しています。
定着の仕掛け: スキャン操作は「かざすだけ」で完結する設計にし、入力の手間を最小限にします。棚卸誤差率の推移をダッシュボードで数値として見える化し、改善が進んだときにその変化を現場が確認できるようにすることで、自分たちの取り組みの効果を実感できるようにします。効果が見えることは、スキャン運用を習慣として定着させるうえで欠かせない要素です。
こうした設計は、既製のWMSパッケージや在庫管理ソフトでは、貴社の数え方のルールや既存システムとの連携部分まで踏み込んで作り込むことが難しい場合があります。よりどころべーすは、物流・運送業向けパッケージを基盤にしながら、足りない部分だけをスクラッチで追加する形で構築するため、既製ソフトの「型に合わせる」窮屈さと、フル自作の「コストと期間がかかりすぎる」問題の中間を狙えます。エンジニアが直接ヒアリングするため、営業と開発の間で「言った・言わない」の伝言ゲームが起きにくく、貴社の数え方・検品ルールをそのまま設計に反映できるのも、ここまで書いてきた設計を実際に形にするうえでの土台になります。
まとめ
在庫差異は、倉庫の能力の問題ではなく「記録のしくみ」の問題です。手入力や目視カウントを続ける限り構造的に発生し続けますが、バーコード・QRスキャンによる入出庫記録、ロケーション管理、そして循環棚卸を組み合わせれば、棚卸誤差率を下げ、欠品や過剰在庫、原因調査の残業を減らしていく土台ができます。
人を1人増やしてダブルチェックを強化するより、記録そのものを正確にするしくみを整えるほうが、結果として現場の負担も少なく、効果も長続きしやすいと考えられます。まずは自社の棚卸誤差率を一度測ってみて、どこでズレが生まれているかを把握することから始めてみてください。在庫管理と同様に属人化しやすい配車業務の改善は運送業の配車業務の属人化を解消する方法もあわせてご覧いただけます。
ここに書いた設計は、あくまで一般化した叩き台です。実際の在庫差異の原因は、扱う商品の特性や倉庫のレイアウト、既存システムの構成によって倉庫ごとに異なります。まずは実際のデモ画面を15分ほどでご覧いただきながら、貴社の帳簿差異がどこで生まれているのかを一緒に整理するところから始められます。在庫管理だけでなく倉庫業務全体を見直したい方は物流・運送業向けの業務システムもご確認ください。
よくある質問
Q. 棚卸誤差率はどのくらいを目指せばよいですか？
一般的には0.1%以下が望ましいとされていますが、これはあくまで目安です。まずは自社の現在値を測定し、そこからどれだけ改善できたかを追っていくほうが実務的です。数%単位でズレている場合は、記録のしくみそのものを見直す余地が大きいサインと考えられます。
Q. 小規模な倉庫でもバーコード運用は必要ですか？
取扱商品点数や入出庫の頻度が少ない場合は、Excel管理でも大きな問題が出にくいこともあります。ただし、扱う商品が増えたり、スタッフの入れ替わりが多かったりする場合は、記録の属人化が進む前にスキャン運用へ移行しておくほうが、後からの切り替えよりも負担が少なく済みます。
Q. 既存の会計システムや受注システムと連携できますか？
貴社が既に使っているシステムとのデータ連携は、設計段階で確認すべき重要なポイントです。連携方法はシステムの種類によって異なるため、現状お使いのシステム構成を伺ったうえで、どこまで自動連携できるかを個別にご提案します。