受注管理システムとWMSの連携:受注・出荷指示・在庫の持ち分と連携方式の選び方

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

B2B EC-COLUMN

在庫が合わない・出荷指示を転記する、その原因は受注と倉庫の「時間差」と「二重管理」にある

受注管理システムでは在庫ありと表示されていたのに、倉庫から欠品の連絡が来る。
受注データを見ながら、倉庫のWMS(倉庫管理システム)へ出荷指示を打ち直している。
こうしたずれの多くは、在庫数を受注側と倉庫側が別々に持ち、片方の更新がもう片方へ遅れて届くことから生まれます。
連携で決めることは二つです。
一つは、受注側が注文・引当・出荷指示を持ち、倉庫側が実在庫と出荷実績を持つという分担です。
もう一つは、項目ごとにAPIで自動化するか、CSVで受け渡すかの選択です。
ロット・期限や外部委託倉庫の条件は、相手の仕様書で確かめる項目として整理します。

受注時に見ている在庫が実在庫とずれる流れ

たとえば受注担当者が得意先から注文を受け、受注管理システムの画面で在庫が足りていることを確かめてから受注を確定したとします。
ところが倉庫では、午前中に別の得意先向けの出荷が進んでいて、棚の残りは注文数に届いていない。
受注側の画面に出ていた在庫数は、倉庫から最後に在庫数が届いた時点の値です。
その後の出荷や入荷は、まだ反映されていなかったことになります。

このずれは、在庫数を受注側と倉庫側の両方が更新していることから起きます。
受注側は注文を受けた時点で在庫を減らし、倉庫側はピッキングして出荷した時点で減らします。
入荷、破損、棚卸の差異のように倉庫の中だけで起きる動きは、倉庫側にしか記録されません。
二つの数字を別々に動かしている以上、片方の変化がもう片方へ届くまでの間は、どちらかが古い値を見ていることになります。

物流事業者のSTOCKCREWは、受注管理システム(OMS)と物流の連携が遅れると、実在庫より多く売ってしまう「過剰販売」が起きると説明しています。
同じ商品が複数の販売チャネルで同時に購入されるためです¹。
倉庫管理システムを提供するロジザードも、在庫が分かれて管理されると表示と実数が合わず、出荷トラブルが起きやすいことを連携の背景に挙げています³。
どちらもECの複数モール販売を念頭に置いた説明です。
ただBtoBでも、営業担当の電話・FAX受注とWeb受注のように、複数の窓口が同じ在庫から注文を受けていれば構造は同じです。
窓口が増えるほど、古い在庫数を見て受ける注文が重なりやすくなります。

出荷指示の再入力・転記で起きること

もう一つのつまずきは、出荷指示の転記です。
連携していない場合、受注管理システムで確定した注文を一覧表やCSVに出し、倉庫のWMSの画面や委託先が指定する書式へ打ち直すことになります。
WMSは倉庫管理システム(Warehouse Management System)の略で、棚の位置(ロケーション)ごとの在庫、ピッキング、出荷検品などを管理する仕組みです。

転記のたびに、品番・数量・納品先を読み替える作業が発生します。
BtoBでは、同じ得意先でも支店や現場ごとに直送先が違ったり、得意先ごとに納品時の指定があったりします。
そのため、転記する項目は品番と数量だけにとどまりません。
直送先を一行読み違えれば、物は正しくても届け先を誤ります。
倉庫の当日出荷の締めに間に合わせようと急いで入力する時間帯ほど、確認に割ける時間は短くなります。

転記の影響は、倉庫へ指示を渡したあとにも残ります。
出荷実績が受注側へ戻ってこなければ、受注担当者は倉庫に電話やメールで問い合わせて出荷を確かめてから、売上計上や請求の処理へ進むことになります。
得意先から注文変更の連絡が入ったときも、受注側の修正と倉庫側の修正を両方行わなければなりません。
在庫のずれも転記の手間も、担当者の注意力の問題とは限りません。
同じ情報を二か所で持ち、人が橋渡ししている仕組みから生じています。
では、どの情報をどちらが持ち、何を相手へ渡せば橋渡しが要らなくなるのでしょうか。

▼ 図の内容を文字で読む

1. 在庫数を二か所で更新
   • 受注側は注文を受けた時点で減らす
   • 倉庫側は出荷した時点で減らす
2. 反映の時間差
   • 最後に在庫数が届いた時点の値を見ている
3. 古い在庫数での受注
   • 倉庫からの欠品の連絡
4. 人が橋渡しする負担
   • 出荷指示の転記
   • 出荷済みかどうかの問い合わせ
   • 注文変更の二重修正

受注から出荷実績まで、注文は何を受け渡しながら流れるか：持ち分と在庫の正の置き方

受注側と倉庫側の持ち分(注文・引当・出荷指示／実在庫・出荷実績)

注文の流れに沿って見ると、受注側と倉庫側が持つべき情報は自然に分かれます。
受注側は得意先から注文を受け、どの商品をいくつ、いつまでに、どこへ届けるかを確定させます。
倉庫側は、その指示に従って棚から商品を取り出し、検品して出荷し、その結果を記録します。
つまり受注側が持つのは「何を出すべきか」、倉庫側が持つのは「実際に何があり、何を出したか」です。

• 受注側が持つ情報：受注(得意先・品番・数量・納期・直送先)、引当(注文に対して在庫を割り当て、ほかの注文に使われないよう押さえること)、出荷指示(倉庫へ出荷を依頼するデータ)
• 倉庫側が持つ情報：実在庫(棚に実際にある数量)、ロケーション(どの棚に置いているか)、出荷実績(いつ・何を・いくつ出荷したか)

STOCKCREWは、OMSが注文を一元的に受け取り、発送代行へ出荷指示を送る設計を説明しています。
在庫数は出荷完了後に更新します¹。
受注側から倉庫へは出荷指示が、倉庫から受注側へは出荷完了の結果が返り、その結果で在庫が動く。
連携とは、この往復を人の転記なしで回すことだと言い換えられます。

連携項目の実例(受注・出荷実績・在庫・マスタの方向)

実際の製品どうしの連携では、どの項目がどちらの向きに流れているのでしょうか。
ロジザードは2026年に、受注管理システムTEMPOSTARとの自動連携を発表しました。
この連携では、TEMPOSTARからロジザードZEROへ商品マスタと受注データを渡し、ロジザードZEROからは出荷実績データと在庫情報を返します³。
受注が倉庫へ、出荷実績と在庫が受注側へという、前の項で見た往復そのものの形です。

BtoB向けの例としては、販売管理システムPCAクラウド 商魂・商管とロジザードZEROのAPI連携があります。
PCAクラウドからロジザードZEROへは、受注データ・発注データに加えて、商品・得意先・直送先・仕入先のマスタを渡します。
ロジザードZEROからは、出荷実績データと入荷実績データを返す構成です⁴。
EC向けの例と比べると、得意先と直送先のマスタが受け渡しの対象に入っている点が目を引きます。
得意先ごと、現場ごとに届け先が変わるBtoBでは、倉庫が「誰のどの届け先か」を判別できなければ出荷できないためです。
発注データと入荷実績も同じ線に乗っており、仕入先からの入荷予定と実際の入荷が、販売管理側へ戻る形になっています。

ただし、これらはそれぞれの製品の組み合わせについて発表された内容です。
PCAとの連携を伝える記事には、出荷指示や在庫の項目が明記されていません。
どの項目がどの頻度で連携されるかは、別の製品の組み合わせにそのまま当てはまりません。
自社の受注管理システムとWMSの組み合わせでは、受け渡せる項目と向きを、両方の提供元の仕様で一つずつ確かめることになります。
その際は、前の項の二つの持ち分(受注側と倉庫側)に項目を振り分けていくと、足りない項目が見つけやすくなります。

在庫の正の置き方の考え方(編集上の提案)

「在庫の正(正本)」とは、二つのシステムの数字が食い違ったときに、どちらを正しい値とみなすかという取り決めです。
これを決めないまま連携すると、ずれが見つかるたびに受注側と倉庫側のどちらを直すかで迷います。
結果として修正が二重になったり、両方が相手に合わせて数字を直したりします。

どちらを正本にすべきかを明示した一次情報は見当たらず、ここから先は編集部としての提案です。
判断の手がかりは、STOCKCREWの説明にあります。
同社は、在庫数を出荷完了を起点に更新し、OMSと発送代行の在庫数を毎日突き合わせる運用を勧めています¹。
物が実際に動いたことを記録できるのは倉庫であり、日次の突合はその数字との差を見つける作業だと読めます。

そこで、実在庫の正は倉庫側に置き、受注側は倉庫から届く在庫情報をもとに「受注できる数」を計算して表示する分担が考えられます。
受注できる数は、倉庫の在庫数から、引当済みでまだ出荷されていない数量を差し引いたものです。
受注側は引当の正を持ち、倉庫側は実在庫の正を持つ。
こう分けておけば、食い違いが出たときにどちらを直すかが決まります。

ただし、この分け方がそのまま合うかは、二つの条件で変わります。
一つは注文確定の定義です。
引当を確定させる時点が受注入力時か与信の確認後かによって、「引当済み・未出荷」の数字の中身が変わります。
もう一つは引当の粒度です。
品番単位で押さえるのか、倉庫別・ロット別まで押さえるのかによって、倉庫から受け取るべき在庫情報の細かさが変わります。
ロット単位の引当が必要なのに、倉庫からは品番単位の合計しか返ってこない組み合わせでは、受注側で正しい受注可能数を出せません。
自社の確定の定義と引当の粒度を先に言葉にしておくと、仕様の確認で何を聞けばよいかがはっきりします。

▼ 図の内容を文字で読む

1. 注文の確定と引当
   • 受注側が持つ
2. 出荷指示を倉庫へ渡す
   • 受注側から倉庫側へ
3. ピッキング・検品・出荷
   • 倉庫側が持つ
4. 出荷実績と在庫情報を返す
   • 倉庫側から受注側へ
5. 受注できる数を更新
   • 倉庫の在庫数から引当済みで未出荷の数量を引く

API・ファイル(CSV)・手作業：連携方式で変わるのは反映の速さと運用の手間

方式ごとの比較表(反映の速さ・出荷指示・運用負担)

持ち分と受け渡す項目が見えたら、次はそれを何で運ぶかです。
STOCKCREWは、API連携とCSV連携を、在庫同期の速さ・出荷指示の方法・推奨する規模で比べています¹。
APIは、システム同士がプログラムで直接データをやり取りする方式です。
CSVは、表形式のファイルを書き出して相手側へ取り込む方式です。
連携しない手作業の転記は、CSVと同じ遅れに加えて、前の節で見た打ち直しの手間とミスを抱えます。

表の数字は物流事業者の解説記事での記述で、ベンダーが保証する性能値ではありません。
それでも、方式の違いが何を変えるのかは読み取れます。
APIでは出荷実績や在庫の変化がほぼ即時に受注側へ戻るため、受注担当者が画面で見る数字と棚の数字の差が小さくなります。
CSVでは、取り込みの間隔がそのまま在庫の遅れになります。
その間に受けた注文は、古い数字をもとにしています。
STOCKCREWは、CSVについては在庫差異のリスクが構造的に高いとして、長期運用を勧めていません¹。
取り込みの回数を増やしても、間隔はゼロにならないためと考えられます。

規模の目安として、同記事はAPIを月200件超や複数チャネルの場合、CSVを月100件以下の場合に勧めています¹。
ただしこれはEC・発送代行を前提にした推奨で、BtoBの受注にそのまま当てはめる基準ではありません。
BtoBでは、1件の注文に多くの明細行が並んだり、得意先ごとに届け先が分かれたりします。
そのため件数が少なくても、転記する量や確認の手間は大きくなりえます。
自社に当てはめるなら、件数そのものより二つの点を基準にするほうが判断に近づきます。
在庫の遅れで受注判断を誤ったときの影響と、毎日の転記にかかっている時間です。

項目ごとに自動と手動が混在する例

方式を選ぶとき、連携全体を「APIかCSVか」の一択で考える必要はありません。
先ほどのTEMPOSTARとロジザードZEROの連携は、従来のCSVによる標準連携から自動連携に変わりました。
ただし、商品マスタだけは手動のCSV連携のまま残っています³。
PCAクラウドとの連携でも、得意先・直送先・仕入先のマスタはCSVの手動連携にも対応しています⁴。
同じ製品の組み合わせの中で、項目によって自動と手動が混在しているわけです。

この二つの例とSTOCKCREWの比較を合わせると、方式は項目ごとに選べるものだと分かります。
そこから、遅れの影響が大きい項目から自動化するという考え方が成り立ちます。
以下は編集部としての整理です。

• 在庫情報・出荷実績：一日に何度も変わり、遅れがそのまま受注判断や得意先への回答のずれになるため、自動化の優先度が高い項目です。
• 受注データ(出荷指示)：転記の手間とミスが集中しやすい項目で、締め時刻までに確実に倉庫へ届くことが求められます。
• 商品・得意先・直送先などのマスタ：変更の頻度は比較的低い一方、登録漏れがあると受注データが倉庫側で処理できない原因になりえます。
  手動CSVで運ぶなら、新しい商品や届け先を登録する手順と順番を決めておく必要があります。

マスタを手動で運ぶ場合、次のような抜けが考えられます。
受注側で新しい直送先を登録したのに、倉庫側へのCSV取り込みを忘れる。
すると、その届け先宛ての受注だけが連携で止まります。
自動化した項目と手動のまま残した項目の境目は、作業の抜けが生まれやすい場所として意識しておきたいところです。

API連携の障害に備える監視

APIで自動化すると、転記はなくなる一方で、止まったことに気づきにくくなります。
STOCKCREWは、API連携は障害時に静かに止まることがあるとしています。
そのうえで、失敗したら3〜5分後に再送し、ログを毎時監視する運用を勧めています¹。

CSVの取り込みは人が毎回行うので、取り込めなければその場で分かります。
APIは、エラーが出ても画面上は普段どおりに見えることがあります。
その間、受注側の在庫表示は止まった時点の数字のままで、受注担当者は受注を続けてしまいます。
最初の節で見た「古い数字を見て受ける注文」が、今度は気づかれないまま積み上がる形です。

APIを選ぶなら、次のことをあらかじめ決めておくことになります。

• エラーの通知を誰が受け取り、どこまでを受注側、どこからを倉庫側やシステムの提供元が対応するか
• 再送しても回復しない場合に、一時的にCSVの取り込みや手作業へ切り替える手順
• 日次の在庫の突合で差が出たとき、連携の停止を疑って確かめる順番

更新の頻度や一度に送れる件数の上限などは、製品ごとの仕様書に書かれる事柄です。
たとえばロジザードZEROの公式サイトでは、API・自動連携できるシステムが増えていることを示しています。
あわせて、CSV・APIの仕様書を求める連携パートナー向けの窓口や、データ連携API利用規約を案内しています⁵。
仕様は公開ページだけでは分からず、提供元への問い合わせを通じて確かめる場合がある。
そう見込んで段取りを組んでおくと、検討が止まりにくくなります。

▼ 図の内容を文字で読む

• 在庫情報・出荷実績
  • 一日に何度も変わる
  • 遅れが受注判断のずれになり自動化の優先度が高い
• 受注データ（出荷指示）
  • 転記の手間とミスが集中しやすい
  • 締め時刻までに確実に倉庫へ届くことが必要
• 商品・得意先・直送先のマスタ
  • 変更の頻度は比較的低い
  • 手動CSVなら登録の手順と順番を決めておく

倉庫の形態・ロット期限管理・取引先別条件で、どこから始めるかを決める

自社倉庫の場合の始め方

ここまでの持ち分と方式の考え方を、自社の状況に当てはめてみます。
最初の分かれ道は、倉庫を自社で運営しているか、外部へ委託しているかです。
どちらかによって、連携の仕様を誰と決めるか、受注側で変えられる範囲がどこまでかが変わります。

自社倉庫でWMSを使っている場合は、受注管理システムとWMSの両方を自社で選び、設定できます。
まず確かめたいのは、二つの製品の間に既存の連携があるかどうかです。
先に見た例のように提供元どうしが連携を発表している組み合わせなら、受け渡せる項目や方式があらかじめ決まっています³⁴。
既存の連携がない場合は、CSVの書式を合わせるか、APIを使った個別の開発が必要になります。
どちらを選ぶかで、かかる費用と期間が変わります。
どこから始めるかは、いま最も転記が多い項目か、在庫のずれで最も困っている項目から選ぶのが現実的です。

自社倉庫の利点は、締め時刻や例外のルールを、受注担当と倉庫担当が社内で話し合って決められることです。
その反面、同じ社内だからと、ずれが出るたびに電話で調整する運用が残りやすい面もあります。
連携を入れても受注側の画面で在庫を手直しする習慣が続けば、二重管理は形を変えて残ります。
前の節で決めた在庫の正を、倉庫担当と受注担当の両方が同じ理解で運用できるかが、自社倉庫ではとくに問われます。

外部委託倉庫(3PL)の前提条件

外部の倉庫(3PL：物流業務をまとめて請け負う事業者)に委託している場合、WMSを選ぶのも設定するのも委託先です。
受注側は、委託先のWMSが受け付ける形式に合わせてデータを渡す立場になります。
ロジザードZEROの公式サイトでは、10荷主以上で採用した大手3PL企業の事例や、3PL向けの支援サービスが紹介されています⁵。
委託先の一つのWMSを複数の荷主が使う運営もあるため、受注側の都合だけで項目や書式を変えられるとは限りません。

STOCKCREWは、外部委託と連携するときの前提として三つを挙げています¹。
SKU(商品を識別する最小単位の商品コード)の一致、対象の受注管理システムとの連携実績、本番前のテスト注文による全フローの検証です。
SKUの一致が先に来るのは、受注側の品番と倉庫側の商品コードが一対一で対応していなければ、倉庫側でどの商品か特定できないからです。
受注側で色やサイズ、入数違いをまとめて一つの品番にしている場合は、倉庫側の管理単位に合わせて整理し直す作業が発生します。

連携実績の確認とは、自社の受注管理システムと委託先のWMSの組み合わせで、すでに稼働している例があるかを聞くことです。
実績があれば、受け渡せる項目と方式の見通しが立ちます。
なければ、CSVの書式合わせから始めるのか個別の開発をするのかを、委託先と受注側の提供元を交えて詰めることになります。
なお、STOCKCREWの記事は契約条件や責任の分かれ目には触れていません。
締め時刻を過ぎた受注、出荷指示後のキャンセル、誤出荷が起きたときの扱いは、システムの連携とは別に、委託契約や運用の取り決めとして決めておく事柄です。

ロット・賞味期限管理がある場合の確認項目

ロット番号や使用期限・賞味期限で在庫を管理する商品では、出荷指示の中身が一段複雑になります。
同じ品番でも、どのロットを出すかで得意先に届く商品の期限が変わるためです。

STOCKCREWのロット管理の解説では、出荷時に最も古いロットから出す先入れ先出し(FIFO)を適用する運用を紹介しています。
期限切れのロットは自動で在庫から除外し、出荷指示の対象にしません²。
同じ解説では、期限の15日前に警告を表示する運用例も挙げています。
期限の確認を手作業にしていて、期限切れの商品を誤出荷した失敗例にも触れ、WMSのアラートや自動除外の設定を勧めています²。
15日という日数はその事業者の運用例であり、標準の値ではありません。

ここで判断が分かれるのは、ロットや期限を選ぶのが倉庫側のWMSか、受注側かという点です。
倉庫側が古い順に自動で出すのであれば、受注側は品番と数量を渡せば足ります。
一方で、得意先によって受け入れられる残り期限が違う場合や、特定のロットを指定して出荷したい場合もあります。
そうした条件があれば、受注側の引当や出荷指示にロット・期限の情報を載せる必要が出てきます。
受注側からロットや期限を指定して引当できるかは製品によって異なり、仕様書で確かめる項目です。

確認しておきたいのは次の点です。

• 受注データや出荷指示に、ロット番号や期限の条件を指定する欄があるか
• 倉庫から返る出荷実績に、出荷したロット番号や期限が含まれるか
• 在庫情報がロット別・期限別に返るのか、品番ごとの合計だけなのか
• 得意先ごとの期限条件を、受注側と倉庫側のどちらで判定するか

取引先ごとの条件も、二つに分けて考えると整理しやすくなります。
一つは、期限やロットのように「どの在庫を引き当てるか」に関わる条件です。
もう一つは、届け先や納品時の指定のように「どう出荷するか」に関わる条件です。
前者は引当の粒度に影響するので、在庫の正の置き方と合わせて決める必要があります。
後者は、マスタや出荷指示の項目として倉庫へ届けられるかを確かめる事柄です。
PCAクラウドとの連携例で、得意先・直送先マスタが倉庫へ渡されていたのがこの形です⁴。
この二分は編集部の整理であり、個々の条件をどの項目で渡せるかは、組み合わせる製品の仕様によります。

連携を始める前の確認事項と、失敗しにくい進め方

注文確定の定義と出荷指示のタイミング

連携の方式と範囲が決まったら、本番の前に運用のルールを決めます。
STOCKCREWは、最も重要なのは注文確定のタイミングの定義だとしています。
そのうえで、与信や入金の確認を終えてから出荷指示を送る設計を勧めています¹。
連携で出荷指示が自動になると、確定した注文はそのまま倉庫へ流れていきます。
そのため、「どの状態になったら倉庫へ送るか」を先に決めておかなければなりません。

この推奨はEC・発送代行を前提にしたもので、BtoBでは自社の取引条件に読み替える必要があります。
掛売りの得意先なら、与信枠の範囲内かどうかの確認が、ECの入金確認に当たります。
前払いや代金引換の得意先が混在していれば、得意先の支払条件ごとに確定の条件が変わることもあります。
締め日をまたぐ受注をどちらの月の出荷として扱うかも、出荷指示を送るタイミングと関わります。

もう一つ決めておきたいのが、出荷指示の締め時刻です。
倉庫が当日出荷できる指示の受付時刻と、受注側が確定処理を終える時刻がかみ合っていなければ、自動連携にしても当日分が翌日に回ります。
APIで即時に届く場合も、CSVで決まった時刻に取り込む場合も、締め時刻と連携のタイミングは合わせて決めることになります。

キャンセル・返品・障害の例外処理

通常の注文が流れるようになっても、つまずきやすいのは例外です。
STOCKCREWは、出荷指示を送ったあとの注文が受注側でキャンセルされた場合の取り決めが必要だと指摘しています¹。
受注側で取り消しても、倉庫ではすでにピッキングが始まっていることがあるためです。

編集部としては、注文の状態ごとに誰が何をするかを決めておく方法を提案します。

• 出荷指示を送る前：受注側で取り消せば済みます。
• 出荷指示を送った後、出荷前：受注側の取り消しだけでは倉庫の作業は止まりません。
  倉庫への取消依頼の方法(連携で送れるか、電話や画面での依頼か)と受付期限を決めておきます。
• 出荷した後：キャンセルではなく返品として扱い、倉庫での入荷と検品を経て、在庫に戻すかどうかを判断します。

注文変更も同じ考え方で整理できます。
出荷指示を送ったあとの数量や直送先の変更は、一度取り消して出し直すのか、変更として送れるのかが製品の仕様で変わります。
連携の障害については、前に見た再送と監視の手順に加えて、障害中に受けた注文をどう倉庫へ渡すかまで決めておきます。
そうしておけば、復旧後に同じ注文が二重に送られる事態を避けやすくなります。

テスト注文での検証

ルールが決まったら、本番前にテスト注文で流れを一通り確かめます。
STOCKCREWは、外部委託との連携の前提として、本番前のテスト注文による全フローの検証を挙げています¹。
確かめたいのは、注文が倉庫へ届くことだけではありません。
出荷実績と在庫が受注側へ正しく戻り、受注できる数が想定どおりに動くことまでを見ます。

これまでの確認事項を、進める順に並べると次のようになります(順序は編集部の提案です)。

1. 両方の提供元の仕様書で、受け渡せる項目と向き、方式、更新の頻度や制限を確かめる
2. 在庫の正をどちらに置くかと、引当の粒度を決める
3. 注文確定の定義と出荷指示の締め時刻を決める
4. キャンセル・変更・返品・連携障害のときの取り決めを決める
5. テスト注文で全体の流れを確かめ、在庫の数字を突き合わせる

テスト注文は、通常の注文だけで終えないことが大切です。
直送先を指定した注文、出荷指示後のキャンセル、在庫が足りない注文、ロットや期限の条件がある商品の注文を流してみます。
例外として決めたルールを一つずつ実際に試すと、仕様書を読んだだけでは見えなかった食い違いが表に出ます。
本番に入ったあとも、しばらくは受注側と倉庫側の在庫を毎日突き合わせておきます。
差が出たときにどの連携で止まったのかをたどれるようにしておくと、ずれの原因を早く見つけられます。

▼ 図の内容を文字で読む

1. 仕様書で項目と方式を確かめる
   • 受け渡せる項目と向き
   • 更新の頻度や制限
2. 在庫の正と引当の粒度を決める
   • 実在庫は倉庫側、引当は受注側
3. 注文確定の定義と締め時刻を決める
   • 出荷指示を送る状態
4. 例外の取り決めを決める
   • キャンセル・変更・返品・連携障害
5. テスト注文で全体を確かめる
   • 在庫の数字を突き合わせる

受け渡す項目や在庫の正の置き方は、自社の注文確定の定義や得意先ごとの条件によって変わります。そのため、仕様書を読み比べるだけでは決めきれないことがあります。

要件定義の段階で外部システムとの連携要件を整理しながら、受注側で持つ情報と倉庫へ渡す情報を、自社の取引条件に沿って洗い出せます。無料相談で要件を整理する

要点の整理

軸	基準
受け渡しの分担	受注側＝注文・引当・出荷指示、倉庫側＝実在庫・ロケーション・出荷実績
在庫の正	実在庫は倉庫側、引当は受注側を正とし、日次で突き合わせる(編集上の提案)
方式の選び方	連携全体ではなく項目ごとに選び、在庫・出荷実績など遅れの影響が大きい項目から自動化を検討する
API運用	再送・監視・CSVや手作業への切替手順を事前に決める
外部委託倉庫	SKUの一致、連携実績、テスト注文を前提に確かめる
ロット・期限	受注側から指定できるか、実績や在庫にロットが返るかを仕様書で確かめる
運用ルール	注文確定の定義、締め時刻、キャンセル・変更・返品・障害時の取り決め

連携の方式や例外のルールは、受注管理側の要件が固まらないと、倉庫側や提供元との確認が進みにくい事柄です。 注文確定の条件、締め時刻、キャンセルや直送先の扱いなど、外部システム連携の要件として何を決める必要があるかを、要件定義の中で一緒に整理できます。

よくある質問

外部委託倉庫(3PL)に変えるとき、受注管理システム側で先に揃えておくデータは何ですか。

まず揃えたいのは商品コードです。
物流事業者のSTOCKCREWは、外部委託と連携する前提としてSKUの一致を挙げています¹。
受注側の品番と委託先の商品コードが一対一で対応するよう整理しておくことが出発点になります。
BtoBでは、得意先と直送先の情報も倉庫が出荷に使う情報です。
販売管理システムとWMSの連携例でも、得意先・直送先マスタが受け渡しの対象になっています⁴。
あわせて、自社の受注管理システムと委託先のWMSの組み合わせに連携実績があるかを委託先に確かめます。
本番前にはテスト注文で全体の流れを検証します¹。

在庫の正を倉庫側に置くと、受注側の画面で見る在庫はどう扱えばよいですか。

編集部の提案としては、受注側の画面の数字を「受注できる数」として扱う方法があります。
倉庫から届いた在庫数から、引当済みでまだ出荷されていない数量を差し引いた値です。
この数字は、倉庫から最後に在庫情報が届いた時点のものです。
方式によって反映の遅れが変わるため、遅れの大きい連携ほど、受注側の数字は目安と考える必要があります。
ずれは日次の突合で見つけ、直すのは倉庫側の実在庫ではなく、受注側の引当や連携の止まりの側です。

CSV連携から始めて後でAPIに切り替える場合、何に気をつければよいですか。

切り替えは連携全体を一度に行う必要はなく、在庫情報や出荷実績のように遅れの影響が大きい項目から順に移す考え方があります。
実際の製品の連携でも、自動連携になったあとも商品マスタだけ手動CSVのまま残る例があります³。
注意したいのは、APIは障害時に静かに止まることがある点です¹。
CSVのときは人の目で気づけた失敗が見えにくくなるため、エラーの通知先と再送の手順を切り替え前に決めておきます。
切り替え日をまたいで同じ注文がCSVとAPIの両方で送られないよう、境目の扱いも決めておく必要があります。

出荷指示を出したあとに得意先から注文変更・キャンセルが来たらどうすればよいですか。

出荷指示を送ったあとのキャンセルには、受注側と倉庫側の取り決めが必要です¹。
注文の状態ごとに整理するとよいでしょう。
出荷指示前なら受注側の取り消しで済み、出荷後なら返品として扱います。
判断が難しいのは、指示を送ったあと出荷前の段階です。
倉庫への取消依頼を連携で送れるのか、電話や画面で依頼するのか、何時までなら止められるのかを決めておきます。
数量や直送先の変更を変更データとして送れるかは製品の仕様によるため、仕様書で確かめます。

得意先ごとの直送先や指定条件は、倉庫システムにどう渡すのですか。

直送先については、販売管理システムから得意先・直送先マスタをWMSへ渡す連携の例があります⁴。
この例ではCSVの手動連携にも対応しています。
受注データでは直送先を指し示し、届け先の詳細はマスタとして倉庫側に持たせる形です。
納品時の指定などの条件をどの項目で渡せるかは、確認できた資料には書かれておらず、組み合わせる製品の仕様で確かめる事柄です。
期限やロットのように引当に関わる条件と、出荷作業に関わる条件を分けて洗い出すと、仕様書のどこを見ればよいかが分かりやすくなります。

1. 1　出典：STOCKCREW（監修：株式会社KEYCREW）「EC受注管理(OMS)と物流の連携ガイド」（2026年）
2. 2　出典：STOCKCREW Inc.「EC事業者のためのロット管理と発注最適化の実務」（2026年）
3. 3　出典：ロジザード株式会社「ロジザードZERO×TEMPOSTAR 自動連携開始」（2026年）
4. 4　出典：ロジザード株式会社「ロジザードZEROとPCAクラウド 商魂・商管がAPI連携開始」（2025年）
5. 5　出典：ロジザード株式会社「ロジザードZERO 公式サイト」（2026年）