販売管理システムの在庫連携、引当タイミングと同期方式はどう決めるか

◆監修・編集責任者　小園 将隆　2026年10月1日

B2B EC-COLUMN

「注文は取れたのに欠品」はなぜ起きるのか——在庫の「引当」の基本

受注伝票は通っているのに、出荷指示を出す段になって在庫が足りない。
別の担当者が同じ商品を先に押さえていた、あるいは倉庫側で減った分がまだ反映されていなかった——。
こうしたズレは確認不足から起きているというより、在庫を「いつ」引当てるか（受注時か出荷準備時か）と、システム間を「どの頻度で」同期するか（即時か定期か）という二つの設計判断が噛み合っていないところから生まれます。
片方だけを直しても解消しません。
自社の受注の入り方、販売チャネルの数、在庫の動きの速さに照らしてこの2軸の組み合わせを選び直すこと、そして複数の窓口で同じ在庫を売っているなら一元管理を前提にした設計へ切り替えることが、欠品と二重販売を減らす出発点になります。

在庫引当とは在庫を「確保」する処理

在庫引当とは、現在保有している在庫や今後入荷予定の在庫のうち、特定の注文や生産計画などに対応する分を「確保」する処理を指します¹。
倉庫の棚から商品を抜き取るわけではないので、物理的には何も動きません。
動くのは数字のほうで、引当を立てた瞬間に、その数量は「他の注文には回せない在庫」として扱われます。

ここで押さえておきたいのは、在庫の数え方が一つではないことです。
棚にある数量、すでにどこかの注文に押さえられている数量、そして残りの売ってよい数量は、それぞれ別の数字です。
受注担当者が画面で見ている「在庫数」がこのうちのどれなのかがシステムごとに違っていると、同じ商品について二人が別の答えを持つことになります。
在庫連携の設計で最初に揃えるべきなのは、連携する数量がどの数字なのかという定義です。

引当の対象には、今後入荷予定の在庫も含められます¹。
手元に実物がなくても、入荷予定日が確定していればその分を特定の注文へ割り当てて納期を回答できる、という考え方です。
便利な反面、入荷が遅れたときに影響を受ける注文がどれかを追えるようにしておかないと、どの顧客へ連絡すべきかが分からなくなります。

販売管理システムと在庫管理システムでズレが生まれる仕組み

システム間で在庫数がずれる原因は、たいてい「確保される瞬間」と「他へ伝わる瞬間」が別々にずれていることにあります。
たとえば、販売管理システムで受注伝票を登録した時点ではまだ引当が立たず、出荷依頼として倉庫側のシステムへ渡した時点で初めて在庫が押さえられる運用を考えてみます。
この場合、受注登録から出荷依頼を作るまでの数時間は、その商品が「まだ誰にも押さえられていない在庫」として画面に残り続けます。

仮に、ある商品の実在庫が10個あるとします。
午前中に5個の受注が入り、午後にも5個の受注が入れば、売ってよい数量は0個になっているはずです。
ところが引当が出荷依頼の作成時にしか立たず、その出荷依頼をまとめて作るのが夕方だとすると、午後に受注を入れる担当者の画面には10個が残っています。
そこへもう1件、5個の注文を受けてしまう。
夕方に出荷依頼をまとめた段階で、15個分の出荷に対して10個しかないことが判明します。

もう一つのずれは、引当は立っているのに相手側のシステムへ伝わっていない場合です。
倉庫側で出荷が完了して実在庫が減っても、その結果が販売管理システムへ届くのが翌朝であれば、その間の受注はすべて古い在庫数を根拠に判断されています。
どちらの場合も、担当者が確認を怠ったわけではありません。
画面に出ていた数字が、その時点の正しい数字ではなかったというだけです。

そう考えると、設計で決めるべき点は二つに絞られます。
一つは、受注から出荷までのどの処理で在庫を押さえるのか。
もう一つは、押さえた結果と減った結果を、他のシステムへどの頻度で渡すのか。
次の節からこの二つを順に見ていきます。

引当は「受注時」と「出荷時」のどちらで行うべきか

即時引当（受注時）が向くケース

受注が確定した時点で即座に在庫を引当てる方式は、即時引当と呼ばれます¹。
この記事で言う「受注時の引当」はこれにあたります。
即時引当は納期遵守を最優先とする場合に有効とされ、生産計画・供給計画を立案するシステムの中で自動的に処理されることも多い方式です¹。

実務の感覚で言えば、受注を取った瞬間に「この注文の分は確保済み」と言い切れる状態を作る方式です。
顧客へ納期を回答する場面で強く、同じ在庫を複数の担当者や複数の販売窓口が同時に見ている環境ほど、その差がはっきり出ます。
先に受けた注文が確実に優先され、後から来た注文はその時点で在庫不足として扱われるからです。

一方で、受注の段階から数量が動きやすい業務では、引当が空振りします。
受注後に数量が減れば、押さえたままの在庫が他の注文へ回らず、システム上は売れる在庫がないのに棚には残っている、という状態が生まれます。
キャンセルや数量変更のたびに引当を解放する処理が確実に動くかどうかが、この方式を選ぶときの前提条件です。
解放が手作業に残っていると、そこが新しいズレの発生源になります。

タイムリー引当（出荷時）が向くケース

出荷や生産の直前に在庫を引当てる方式はタイムリー引当と呼ばれ、在庫の変動が激しい場合や、直前まで需要が不確定な場合に適しているとされます¹。
受注の時点では在庫を押さえず、実際に出荷作業へ入る段で、そのときの実在庫から割り付けます。

入出荷が一日に何度も発生し、受注の内容も出荷直前まで動く業務では、早く押さえてもその引当が正しいまま残る保証がありません。
出荷の直前に決めれば、その時点で最も確からしい在庫を根拠に割り付けられます。
そのかわり、受注を受けた時点では「確保できています」と言い切れないため、納期回答は見込みの性格を帯びます。
出荷直前に在庫が足りないと分かった場合、連絡と調整は受注のあとから発生することになります。

どちらを選ぶかは、納期を確約する必要の強さと、在庫がどれだけ速く動くかの兼ね合いで決まります。
受注から出荷までが短く、在庫も潤沢なら、どちらを選んでも結果はさほど変わりません。
差が出るのは、受注から出荷まで日数があり、その間に同じ在庫を狙う注文が複数入る業務です。
そこでは押さえる時点を早めるか、それとも在庫の見え方を常に最新へ保つかという、次の節の同期方式の話と必ず組みになります。

システム間の同期は「リアルタイム連携」と「バッチ連携」のどちらを選ぶか

リアルタイム連携（API）の特徴と注意点

リアルタイム連携とは、データが発生・更新された瞬間に、即座に他システムへ反映する連携方式です²。
在庫で言えば、引当が立った瞬間、出荷が確定した瞬間に、その結果が相手のシステムの在庫数へ届きます。
即時反映が必須の場面としては受注処理・在庫管理・顧客対応が挙げられており²、在庫連携はまさにこの性格の処理にあたります。

ただし、瞬間ごとに通信するということは、通信が失敗したときの扱いを先に決めておかなければならないということでもあります。
リアルタイム連携の実装では、API呼び出し上限への対応、エラーの検知と自動再送、同時更新による不整合リスク、システムダウン時のデータ保留機能といった点を考慮する必要があるとされています²。
在庫に引き直せば、更新が一件届かなかったときにその一件をどう拾い直すか、同じ商品の在庫を二つの処理が同時に書き換えたときにどちらを正とするか、相手が止まっている間に発生した更新をどこへ溜めるか、という設計です。

これらは「できれば用意したい機能」ではなく、リアルタイムにした時点で必ず発生する宿題です。
更新が一件でも落ちれば、その商品の在庫数は以後ずっとずれたままになります。
定期的に全件を突き合わせて差分が出た商品を洗い出す処理を併走させるかどうかも、ここで一緒に決めておきたい論点です。
再送の仕組みがあることと、ズレが残らないことは別の話だからです。

バッチ連携の特徴と向く場面

バッチ連携は、スケジュールに基づいてデータをまとめて処理する方式です²。
大量データの集計や、効率を重視した夜間の一括処理が向く場面として挙げられています²。
在庫で言えば、一日の終わりに倉庫側の在庫実績をまとめて取り込み、翌朝の受注はその数字を基準に進める、といった運用になります。

連携の手段も一つではありません。
モールが提供するAPIを使った自動連携が中心ですが、APIに対応していないモールや自社システムについては、CSVデータの取り込みによって連携することもあります^{4</tsup>。
CSVでのやり取りは必然的にまとまった単位になるため、方式としてはバッチ寄りになります。
相手のシステムが何に対応しているかで、選べる方式が先に絞られる場合があるということです。}

重要なのは、どちらか一方を選ばなければならないわけではない点です。
実務ではリアルタイム連携とバッチ連携の両方を組み合わせるのが一般的とされています²。
売ってよい在庫数だけはリアルタイムで共有し、売上実績や入荷予定のような大量データは夜間にまとめて取り込む、といった分け方が現実的な落とし所になりやすい領域です。
全部を即時にする必要はなく、ずれたときに困る情報から優先的に即時へ寄せる、という順序で考えると判断しやすくなります。

外部モールの仕様変更が招く売り越し・出荷遅延のリスク

自社システム同士の連携と、外部のモールやカートとの連携で決定的に違うのは、相手の仕様を自社で決められないことです。
仕様変更への対応が遅れると在庫連携が一時的に停止し、売り越しや出荷遅延といったリスクが発生する可能性があるとされています⁴。
連携が止まっている間、販売側の画面には止まった時点の在庫数が残り続けます。
その数字を見た注文は通常どおり入ってくるので、気づくのが出荷の段になってから、ということも起こり得ます。

だからこそ、連携が止まったことに気づく仕組みと、止まっている間の販売の扱いを事前に決めておく価値があります。
一定時間更新が届かなければ警告を出す、販売側に持たせる在庫数を実在庫より絞っておく、といった備えは、止まる可能性そのものをなくすものではありません。
それでも、気づくまでの時間と、気づくまでに受けてしまう注文の量を抑える方向には働きます。

費用の面も、方式の選択と無関係ではありません。
取扱商品数や受注件数が多い場合は、従量課金の影響でコストが大きく変動することもあるため注意が必要とされています⁴。
連携の回数そのものが課金対象になるサービスでは、リアルタイム化は通信回数の増加と直結します。
自社でサーバーを構えて連携する場合も、その処理を受け止める側のリソースが要ります。
一例として、ECサイト稼働の負荷分散および社内外システム連携用のリソースを確保した構成のモデルケースでは、ASP利用料金が月額260,000円と示されています⁵。
これはWebサーバーやDBサーバー、バッチサーバーの台数まで含めた特定構成でのモデルケースであり、構成が変われば金額も変わります⁵。
相場として読む数字ではなく、連携のためのリソースを別に確保するとどの程度の規模の話になるのか、という目安として見てください。

実店舗・EC・卸など複数の販売経路で同じ在庫を扱う場合の設計

チャネルごとに在庫を分けた場合に起きる表示と実在庫のズレ

複数のECモールへ展開したり、実店舗との連携を進めたりする場合、在庫を統合的に管理することが不可避の課題になるとされています³。
避けられないのは、販売の窓口がいくつに増えても、在庫の実体は一つしかないからです。

窓口ごとに在庫を分けて割り当てる運用は、設計としては単純です。
各窓口は自分の持ち分だけを見て売るので、他の窓口の動きを気にする必要がありません。
そのかわり、ある窓口で売れ残っている在庫を別の窓口が売れない、という状態が生まれます。
売れ行きに差が出るたびに持ち分を手で振り替えることになり、振り替えた結果がシステムへ反映されるまでの間が、また新しいズレになります。

統合しないまま運用した場合の典型的なトラブルも示されています。
ネットショップと実店舗の間で情報共有がスムーズでないと、ネット上では「在庫あり」と表示されているにもかかわらず、実際には欠品しているといったことが起こります³。
店頭で売れた一点がECの在庫数へ反映されていなければ、画面上の在庫は実体より多いままです。

この指摘はアパレル・小売のEC・実店舗運営を主な対象とした解説によるものですが、同じ在庫を複数の窓口が見ているという構造は、卸や法人向けの受注サイトを併用する場合にも共通します。
ただし卸のチャネルには掛売りや取引先ごとの条件が絡み、どの注文の引当を優先するかという判断が加わります。
この優先順位は在庫の持ち方だけでは決まらないため、取引条件の側から別途決める必要があります。

在庫一元管理で求められる3つの機能

在庫の一元管理で重要とされる機能は、実店舗や複数ショップの在庫データ連携、在庫表示・取り置きサービス、受注管理システムや出荷管理システム・POSレジとの連携・自動化の3点です³。
この3点は、ここまで見てきた2軸をそのまま言い換えたものとしても読めます。

在庫データの連携は同期方式の話であり、取り置きは引当そのものです。
店頭での取り置きは、実店舗の側で在庫を押さえる処理にほかなりません。
そしてPOSレジや出荷管理システムとの連携・自動化は、在庫が減る瞬間を人の転記に頼らずに拾う仕組みです。
店頭での販売がレジを打った瞬間に在庫へ反映されるのか、閉店後の集計で反映されるのかで、ECの在庫表示の鮮度が決まります。

複数チャネルを持つと、引当タイミングと同期方式の選択には、単独チャネルのときほどの余裕がなくなります。
単独チャネルであれば、引当が遅くても同期が遅くても、在庫を見ているのが一つの画面である限り深刻な衝突は起きにくいためです。
窓口が二つ以上になった瞬間に、「どの画面の在庫数を正とするか」を決める必要が生まれます。
一元管理とは、その問いに「ここが正」と一か所で答えられる状態を作ることだと考えると、必要な機能の輪郭がつかみやすくなります。

自社の受注件数・チャネル数に応じた組み合わせの選び方

受注件数・SKU数が多い場合の判断

ここまでの2軸を自社に当てはめるとき、最初に数えたいのは受注件数そのものよりも、同じ在庫を見ている窓口の数です。
窓口が一つで、受注から出荷まで同じ担当者が追えるのであれば、引当を出荷直前に寄せ、同期を一日数回のまとめ処理にしても衝突は起きにくい。
窓口が複数ある、あるいは一つの窓口でも同時に複数人が受注を入れるのであれば、引当を早める理由がそこで生まれます。

件数と取扱商品数が増えると、方式の選択は費用と運用の問題に変わります。
取扱商品数や受注件数が多い場合、従量課金の影響でコストが大きく変動することがあるとされています⁴。
全商品を常時リアルタイムで同期する設計は、更新の通信量がそのまま増え続ける構造になります。
実務ではリアルタイムとバッチを組み合わせるのが一般的とされている²とおり、ここで効いてくるのは対象を分ける考え方です。
在庫が薄く回転の速い商品群は即時に、在庫に余裕のある定番商品は定期の同期に寄せる。
そうすれば通信量を抑えながら、衝突が起きやすいところだけを押さえられます。

何件以上ならリアルタイムにすべき、という線引きを示す資料は見当たりませんでした。
件数は目安にはなりますが、同じ商品へ注文が重なる確率を決めるのは件数そのものではなく、在庫数に対する受注の密度だからです。
月に数千件あっても商品が分散していれば衝突は起きにくく、月に数十件でも特定の人気商品に集中していれば衝突します。
自社の過去の欠品や二重受注が、どの商品で、どの時間帯に起きたかを振り返るほうが、件数の総計より判断の役に立ちます。

在庫変動が激しい・需要が読みにくい場合の判断

在庫の変動が激しい場合や、直前まで需要が不確定な場合には、出荷・生産の直前に引当てるタイムリー引当が適しているとされています¹。
一方、納期遵守を最優先とする場合には、受注確定時点の即時引当が有効とされます¹。
この二つは方向として対立していますが、同じ会社の中で両方の条件が同時に成り立つことは珍しくありません。

たとえば、納期を確約して受注する法人向けの取引と、在庫の動きが速い一般向けの販売を併せ持つ場合を考えてみます。
前者では受注の時点で確保しなければ約束が守れず、後者では早く押さえても出荷までに状況が変わります。
商品や取引区分ごとに引当のタイミングを変えること自体は考え方として成り立ちますが、同じ在庫を両方が取り合う場合には、どちらの引当を優先するかの順位づけが必ず要ります。
そこを決めずに運用だけを分けると、優先したい注文の在庫が、後から入った別区分の注文に先に押さえられる事態が起こり得ます。

設計を決める順番としては、まず在庫を見ている窓口を洗い出し、次にどの処理で引当を立てるかを決め、そのうえで同期の頻度と方式を選び、最後に連携が止まったときの運用を決める、という流れが扱いやすくなります。
窓口の数が定まらないうちに同期方式だけを検討しても、どこへ何を伝えるべきかが決まらないためです。

引当のタイミングと同期の方式は、どちらか一方だけを決めても設計にはなりません。
次に、この2軸を組み合わせたときに在庫の見え方がどう変わるかを並べます。

引当をどの処理で立て、どこまでを即時に同期するかは、受注の入り方や倉庫側の運用、既存システムが公開している機能の範囲に左右されます。一般論としての向き不向きは整理できても、自社の受注画面と倉庫・カート側の仕様を突き合わせないと、どこを即時にできてどこができないかは決まりません。

現在の販売窓口と在庫の持ち方、既存システムの連携状況をお伝えいただければ、どの処理で引当を立て、どのデータを即時にしてどれをまとめ処理へ寄せるか、連携を受け止めるサーバー構成まで含めた現実的な形を一緒に確認できます。無料相談で要件を整理する

引当タイミング×同期方式の組み合わせ整理

引当を立てる時点（受注確定時／出荷・生産の直前）と、システム間の同期方式（リアルタイム／バッチ）の2軸で、在庫が確保される瞬間と、他システムから見える在庫数の鮮度がどう変わるかを並べています。

• 受注時に即時引当×リアルタイム連携：受注が確定した瞬間に在庫が確保され、その結果が他システムの在庫数へも即座に届く。納期回答を優先し、同じ在庫を複数の窓口で売る場合に噛み合う。ただしエラー時の再送や同時更新の扱いを設計に含める必要がある。

• 受注時に即時引当×バッチ連携：自システムの中では受注した分がすぐ押さえられるが、他システムへ伝わるのは次のまとめ処理まで待つ。窓口が実質一つで、同期の間隔内に在庫が売り切れるほどの変動がない場合に成り立つ。

• 出荷準備時にタイムリー引当×リアルタイム連携：受注の時点では在庫を押さえず、出荷直前のその時点の在庫で割り付ける。在庫変動が激しく、受注後も数量変更が入る業務で、最新の実在庫を各システムで共有したい場合。納期回答は見込みの性格になる。

• 出荷準備時にタイムリー引当×バッチ連携：押さえるのも伝わるのも遅く、受注から出荷までの間で在庫の見え方が最も粗くなる。受注件数が少なく在庫に余裕がある、あるいは取り寄せや受注生産が前提で即時の在庫確保を必要としない場合。

同じ在庫を見ている販売窓口が増えたとき、または在庫の回転が速くなったときは、引当を早める側・同期の間隔を短くする側へ見直します。費用や開発の負荷で全面的な即時化が難しい場合は、在庫が薄く動きの速い商品群だけを即時側へ寄せる判断もあります。

要点の整理

軸	判断の基準
引当を立てる時点	納期を確約する必要が強いなら受注確定時の即時引当、在庫変動が激しく需要が直前まで動くなら出荷直前のタイムリー引当
同期の方式	売ってよい在庫数など即時性が要るものはリアルタイム、売上や入荷予定など大量データはまとめ処理。両方の併用が前提
チャネル数	同じ在庫を見る窓口が二つ以上になったら、どの在庫数を正とするかを一か所に決める
止まったときの備え	連携停止の検知、停止中に販売へ見せる在庫の絞り込み、復旧後の突き合わせ手順をセットで決める
費用	従量課金は取扱商品数・受注件数で変動。連携用のリソースを自社で構える場合は構成次第で費用が変わる

卸や法人向けの受注を併せ持つ場合、引当の優先順位は取引先ごとの条件とも結び付くため、在庫の仕組みだけでは決めきれません。既存の販売管理システムをどこまで残し、どこを連携で補うかという切り分けも、現状の運用を見ないと判断が難しい部分です。 受注経路ごとの件数や在庫の共有範囲を伺えば、一元管理に踏み切るべき範囲と、当面は現行の運用で足りる範囲の線引き、そのために必要な連携の形と費用の見通しを具体的に確かめられます。

よくある質問

在庫連携でAPI呼び出しにエラーが起きた場合、どのような設計対応が必要ですか

リアルタイム連携の実装では、API呼び出し上限への対応、エラーの検知と自動再送、同時更新による不整合リスク、システムダウン時のデータ保留機能といった点を考慮する必要があるとされています²。
在庫連携に引き直すと、最低限の設計対象は三つです。
失敗した更新を検知して自動で送り直すこと、相手が応答しない間の更新を溜めておき復旧後に順序を保って流すこと、同じ商品の在庫を複数の処理が同時に書き換えたときにどちらを正とするかを決めることです。
加えて、再送でも埋まらないズレが残る前提で、定期的に全件を突き合わせて差分の出た商品を洗い出す処理を併せるかどうかを検討します。
再送の仕組みがあることと、在庫数が合い続けることは別の話だからです。

即時引当とタイムリー引当を商品カテゴリーごとに使い分けることはできますか

考え方としては成り立ちます。
即時引当は納期遵守を最優先とする場合に有効とされ、タイムリー引当は在庫の変動が激しい場合や直前まで需要が不確定な場合に適しているとされており¹、この条件は商品ごとに異なってよいものだからです。
実際に分けるなら、同じ在庫を両方の方式で取り合うかどうかを先に確かめてください。
カテゴリーが完全に分かれていて在庫を共有しないなら、それぞれ独立に設計できます。
共有する場合は、どちらの引当を優先するかの順位と、優先度の低い側の引当をいつ解放するかを決めておかないと、運用の中で衝突します。
なお、商品区分ごとに引当方式を切り替えられるかどうかは製品の設定範囲によるため、既存システムで何がどこまで設定できるかの確認が前提になります。

モール側の仕様変更で在庫連携が一時的に止まった場合、二重販売を防ぐにはどうすればよいですか

仕様変更への対応が遅れると在庫連携が一時的に停止し、売り越しや出荷遅延といったリスクが発生する可能性が指摘されています⁴。
止まること自体を完全には避けられない前提に立つと、現実的な備えは二つです。
一つは、止まったことに早く気づく仕組みで、一定時間同期が成立しなければ警告が出るようにしておくこと。
もう一つは、止まっている間の販売在庫の扱いを先に決めておくことです。
販売側に見せる在庫を実在庫より絞っておけば、停止中に入った注文が実在庫を超えるまでの余裕が生まれます。
ただしこれは余裕を作る措置であって、停止が長引けば超えます。
復旧後に、停止中の受注と実在庫を突き合わせる手順まで含めて決めておくと、出荷前の段階で不足に気づけます。

在庫を一元管理する際、実店舗の在庫もリアルタイムでシステムに反映させる必要がありますか

一元管理で重要とされる機能には、実店舗や複数ショップの在庫データ連携と、POSレジを含む各システムとの連携・自動化が挙げられています³。
また、ネットショップと実店舗の情報共有がスムーズでないと、ネット上は「在庫あり」でも実際には欠品というトラブルが起こるとされており³、店頭での販売を在庫へ反映する経路そのものは必要です。
ただし、すべての商品を常時リアルタイムで反映しなければならないわけではありません。
判断を分けるのは、店頭とネットで同じ在庫をどれだけ奪い合うかです。
店頭でよく動き、ネットでも売れる商品は、反映が遅れるほど表示と実体が離れます。
店頭ではほとんど動かない商品であれば、閉店後の一括反映でも実務上の支障は出にくくなります。
どこまで即時にするかは、商品ごとの回転と、欠品連絡が発生したときの手間を見比べて決めることになります。

1. 1　出典：株式会社日立ソリューションズ東日本「「在庫引当」とは？その考え方と重要性、システム活用法の解説」（確認時点・発行年不明）
2. 2　出典：アステリア株式会社「リアルタイム連携とは｜仕組みとバッチ連携との違いを解説」（確認時点・発行年不明）
3. 3　出典：株式会社大塚商会「ネットショップの在庫管理を最適化！複数店舗の一括管理方法（ERPナビ）」（2024年）
4. 4　出典：freee株式会社「EC事業の在庫連携とは？在庫管理を自動化する方法やメリット・デメリット、システム選定のポイント」（確認時点・発行年不明）
5. 5　出典：株式会社フライトソリューションズ「EC-Rider B2B Ⅱ 料金プラン・費用ページ」（2026年）