受注管理システムと倉庫の連携方法｜CSV・API・倉庫側の対応確認から切り替えまで

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

B2B EC-COLUMN

受注管理システムと倉庫の間で何が往復し、どこで手作業とミスが出るのか

受注管理システムに入った注文を倉庫向けのExcelやメールに写し、出荷が済んだら追跡番号を受注側へ打ち直す。
件数が増えるほど、この往復で出荷ミスや在庫のずれが起きやすくなります。
倉庫との連携は、出荷指示を渡し、出荷実績・追跡番号・在庫を受け取る往復を、ファイルの受け渡しかシステム同士の接続に置き換えることです。
CSVは始めやすい代わりに反映が遅れ、APIは速い代わりに準備が要ります。
どちらを選べるかは倉庫側の対応で決まります。
そのため、まず倉庫側の対応を確かめ、商品コードを揃えてから、テスト注文と並行運用で切り替えます。

受注から倉庫へ渡すもの

連携というと、受注を倉庫へ送る一方向の作業を思い浮かべがちです。
実際には行きと帰りがあります。
行きは、受注管理システムに入った注文をもとに、どの商品をいくつ、どこへ送るかを倉庫へ伝える出荷指示です。

製品同士の連携例を見ると、この行きの流れが具体的に分かります。
ロジクラとネクストエンジンの組合せでは、ネクストエンジンの受注伝票がロジクラ側に出荷予定として取り込まれます¹。
BOSSとロジザードZEROのAPI連携を伝える報道では、両者の間で受注データ、出荷指示データ、出荷実績や出荷完了のデータ、在庫の情報がやり取りされると説明されています⁴。
ロジザードZEROのように、入荷・保管・出荷を管理する倉庫側のシステムをWMS（倉庫管理システム）と呼びます。

項目の名前は製品ごとに違います。
ただ、倉庫に届けるべき中身は、どの注文を、どの商品で、どこへ出すかという点で共通しています。
なお、上の二つは特定の製品の組合せでの連携内容です。
他の組合せで同じ項目がやり取りされるとは限りません。

倉庫から受け取るもの

帰りの流れで受け取るのは、出荷が済んだという結果です。
ロジクラとネクストエンジンの例では、倉庫側で出荷を確定すると、受注側のステータスが出荷済みになり、追跡番号が反映され、在庫が増減します¹。
購入者への発送連絡や配送の問い合わせ対応で使う追跡番号は、この帰りの情報に含まれます。

在庫も帰りの情報の一つです。
倉庫の棚で実際に減った数が受注側へ戻らないと、受注管理システムの在庫数は実物とずれていきます。
そのずれに気づかないまま販売を続けると、手元にない商品を売ってしまったり、残っている商品を売り切れ扱いにしてしまったりします。

自社の手作業の箇所を洗い出す

往復を行きと帰りに分けると、どこで人が転記しているかが見えてきます。
たとえば、受注管理システムから注文をExcelに書き出して倉庫へメールで送り、倉庫から返ってきた出荷済みの一覧を見て、追跡番号を一件ずつ受注側に入力している運用を考えます。
この場合、行きでは書き出しと送信が、帰りでは追跡番号と在庫数の入力が手作業です。

報道でも、従来はCSVの受け渡しや手入力、複数システム間の転記があり、属人化や入力ミスの要因になっていたと説明されています⁴。
これは記事中の説明で、ミスの発生率を測ったものではありません。
それでも、転記の回数が多いほど、担当者が休んだ日に作業が止まったり、商品や数量を写し違えたりする余地は増えます。

洗い出しでは、行き・帰り・在庫のそれぞれについて、誰が、どの画面からどの画面へ、何を写しているかを書き出します。
困りごとが帰りの追跡番号の入力に集中しているのか、在庫のずれにあるのかで、連携に求めることが変わるからです。
追跡番号の反映が目的なら出荷確定の戻し方が、在庫のずれが目的なら在庫の増減がどう戻るかが、次に方式を比べるときの見どころになります。

▼ 図の内容を文字で読む

1. 受注管理システムに注文が入る
2. 倉庫へ出荷指示を渡す
3. 倉庫で出荷を確定する
4. 出荷済み・追跡番号・在庫の増減が受注側へ戻る

CSV受け渡しとAPI連携は何が違い、自社はどちらから検討するか

反映の速さと準備の違い

CSV連携は、受注管理システムから出荷指示のファイルを書き出し、倉庫側のシステムに取り込む方式です。
CSVは、項目をカンマで区切って並べた表形式のファイルを指します。
API連携では、システム同士が決まった形式で直接データをやり取りするため、人がファイルを移す工程がありません。

発送代行会社のSTOCKCREWは、CSV連携を定期的にまとめて処理する方式とし、反映に遅れが出る一方で、設定はすぐに始められると案内しています²。
API連携については、注文・在庫・出荷完了がほぼ即時に自動で同期される代わりに、初期設定に期間がかかるとしています²。
どちらも同社の案内で、独立した第三者の調査で裏付けられた比較ではありません。

表のうち判断が分かれやすいのは、反映の遅れが自社の業務に効くかどうかです。
CSVで出荷実績を戻す場合、次の取り込みまでは受注側の在庫や出荷状況が古いままです。
出荷の締め時刻の間際に注文が集中する、在庫の少ない商品を複数の販売先で売っている、といった事情があれば、遅れの影響は大きくなります。
反対に、出荷指示を一日の決まった時点でまとめて渡す運用で困っていないなら、CSVでも書き出しと手入力の転記は減らせます。

どちらの方式でも、手作業がなくなるとは限りません。
API連携でも、商品情報の更新や在庫調整が自動連携の対象外になる例があります¹⁴。
方式を選ぶことと、残る手作業の運用を決めることは、別の作業として考えておく必要があります。

受注量による目安の読み方

STOCKCREWは、受注量が少ない事業者にはCSV、一定以上の受注量ならAPIを推奨し、切り替えの目安となる月間の件数も示しています²。
ただしこれは発送代行を行う一社の案内で、業界で共有された基準ではありません。

件数そのものより、件数が増えたときに何が詰まるかを見るほうが、自社の判断には役立ちます。
たとえば、一回の取り込みで扱う件数が増えてエラーの確認に時間を取られる、取り込みの合間に売れた商品の在庫が合わない、追跡番号の反映が遅れて購入者からの問い合わせが増える、といった症状です。
件数の目安は、こうした症状が出やすい規模についての一社の見立てとして読み、自社の出荷量と実際の症状の両方で判断します。

もう一つ、選択肢は自社の希望だけでは決まりません。
APIを使いたくても倉庫側が対応していなければ選べず、CSVでも倉庫が指定する形式に合わせる必要があります。
実際に選べる方式は、倉庫側の条件を確かめた段階で絞られます。

▼ 図の内容を文字で読む

• CSV連携
  • 定期的な一括処理で反映に遅れが出る
  • 設定はすぐに始められる
• API連携
  • 注文・在庫・出荷完了がほぼ即時に同期される
  • 初期設定に期間がかかる
• 倉庫側の条件
  • 倉庫が対応していなければAPIは選べない
  • CSVでも倉庫が指定する形式に合わせる

倉庫が対応できる連携方式をどう確認するか

聞くべき確認項目

STOCKCREWは倉庫側の確認事項として、受注管理システム（OMS）との連携実績、ネクストエンジンの認定・承認、出荷指示フォーマットへの合わせ込みを挙げ、Logilessとの連携は事前確認が必要としています²。
これは同社の整理で、他の倉庫では項目も答えも変わります。
それでも、受注側の担当者が倉庫へ何を聞けばよいかの出発点にはなります。

前の二つの節で見た往復と方式の違いを踏まえると、倉庫へ聞く内容は次のように整理できます。

• 自社が使う受注管理システムとの連携実績があるか、ある場合はCSVかAPIか
• 受注管理システム側で、その倉庫やWMSが連携先として認定・承認されているか
• CSVの場合、出荷指示ファイルの項目と並びを倉庫が指定しているか
• 出荷実績・追跡番号・在庫を、どの方式でいつ返してもらえるか
• 連携に必要な契約や、拠点ごとの制約があるか
• 自動で連携されない項目は何か

連携実績と認定の見方

実績があると答えられても、その中身によって準備は変わります。
2026年の報道では、GoQSystemがロジザードZEROとmimosaというWMSとAPI連携し、これらのWMSを使う複数の倉庫とすでにデータ連携していると伝えられています³。
このように、受注管理システムが倉庫ごとではなく倉庫の使うWMSとつながっている場合、同じWMSを使う倉庫なら連携の土台があることになります。
ただし、どの項目がどの頻度で連携されるかといった細目は、報道からは分かりません。

製品同士がつながっていても、条件が付くことがあります。
ロジクラとネクストエンジンの連携では、ネクストエンジン側の連携オプションの契約が必要で、対応は通常拠点のみ、拠点別の連携はできないとされています¹。
複数の拠点から出荷している会社なら、この条件によって連携できる範囲が変わります。

そのため、連携できるかどうかを一言で聞くより、どの製品やWMSとの組合せで、どの情報が、どの条件で連携されているかを聞くほうが、倉庫ごとの答えを比べやすくなります。
一つの倉庫と複数の候補を比べる場面でも、同じ問いで聞けば違いがはっきりします。

自社WMSと外部委託先の違い

倉庫を外部に委託しているなら、聞く相手は委託先の窓口です。
委託先がどのWMSを使い、どの受注管理システムと連携した実績があるかは、委託先がいちばん把握しています。
自社が受注管理システムを変えたくない場合は、その組合せに対応しているかどうかが、委託先を選ぶときの条件の一つになります。

自社倉庫でWMSを使っているなら、聞く相手は受注管理システムとWMSそれぞれの提供元です。
両製品の間に既存の連携があるか、なければCSVの形式をどちらに合わせるかを確かめることになり、間に立って調整するのは自社の担当者です。
WMSを使わず表計算で在庫を管理している場合は、受け取る側のシステムがないため、出荷指示をどの形式で受け取り、在庫をどこで持つかを決めるところから始まります。

▼ 図の内容を文字で読む

• 連携実績と認定
  • 自社の受注管理システムとの連携実績があるか
  • 連携先として認定・承認されているか
• 返してもらう情報
  • 出荷実績・追跡番号・在庫をどの方式でいつ返すか
• 契約と拠点の条件
  • 連携に必要な契約はあるか
  • 拠点ごとの制約はあるか
• 自動連携されない項目
  • 自動で連携されない項目は何か

連携で決めておくデータ項目と、ずれを防ぐ運用ルール

商品コードを揃える

連携は、受注側と倉庫側が同じ商品を同じ商品として認識できることが前提です。
ロジクラとネクストエンジンの連携では、商品を商品コードで突き合わせてから入出庫の連携を始めます¹。
STOCKCREWも、受注管理システムと倉庫でSKUのコードを一致させる必要があるとしています²。
SKUは、色やサイズの違いまで区別した在庫管理の単位です。

たとえば、受注側ではTシャツの赤のMサイズに一つのコードを付け、倉庫側では入荷時に別の番号を振っていたとします。
この状態で連携しても、倉庫は出荷指示に書かれた商品を自分の在庫と結び付けられません。
セット商品や、販売先ごとに別のコードで登録している商品がある場合は、受注側でどのコードに変換して倉庫へ送るかも決めておく必要があります。

商品コードの整理は、方式をCSVにするかAPIにするかに関係なく必要な作業です。
先に済ませておくと、倉庫との打ち合わせで形式の話に集中でき、後で触れるように準備期間にも影響します。

自動連携されない項目の扱い

API連携にすれば何もかも自動になる、とは限りません。
ロジクラとネクストエンジンの連携では、在庫調整、棚卸しの結果、商品情報の更新は連携されません¹。
BOSSとロジザードZEROの連携を伝える報道でも、商品マスタはCSVによる手動の受け渡しとされています⁴。
自動連携の範囲は製品ごとに違うため、ここで挙げた項目がどの製品でも対象外というわけではありません。

日々の業務に置き換えると、倉庫で破損品を在庫から外した、棚卸しで数が合わずに修正した、といった変更は受注側へ自動では届きません。
受注側で新商品を登録しても、倉庫側の商品情報は別に更新する必要があります。
こうした差が少しずつ積み重なると、出荷の連携は正しく動いているのに在庫がずれる、という状態になります。

編集部の提案としては、自動連携されない項目を一覧にし、変更が起きたときに誰がどちらのシステムへ伝えるか、両方の在庫数をいつ突き合わせるかを決めておく方法があります。
突き合わせの頻度は出荷量や商品数で変わるため、一律の目安は示しません。
これでずれがなくなるわけではありませんが、ずれを見つけたときに、どの変更が相手に届いていなかったかを追いやすくなります。

返品・キャンセルの扱い

注文のステータスは、未処理・処理中・出荷済み・キャンセルなどで管理されます²。
迷いやすいのは、出荷指示を送った後に注文がキャンセルされた場合です。
倉庫がすでにピッキングや梱包を始めていれば、止められるかどうかは倉庫側の運用によります。
キャンセルをどの方式で倉庫へ伝え、止められなかったときに受注側の記録をどう直すかは、倉庫と事前に決めておくべき点です。

返品は、さらに範囲が分かれます。
STOCKCREWでは、連携の対象は物流起因の返送のみで、購入者都合の返品処理は対象外とされています²。
他の倉庫や製品でも範囲が同じとは限りません。
購入者都合の返品を受け付けたあと、商品を在庫に戻すのか、誰が受注側の記録を修正するのかは、連携とは別の運用として倉庫と取り決めます。

▼ 図の内容を文字で読む

1. 在庫調整や商品情報の変更が起きる
2. 担当者がもう一方のシステムへ伝える
3. 両方の在庫数を突き合わせる
4. ずれたときは届いていない変更を追う

導入手順と切り替え時の確認で出荷を止めない

テスト注文で確かめる項目

連携を有効にした初日に本番の注文を流すと、うまく動かなかったときに出荷そのものが止まります。
STOCKCREWの手順では、API設定と商品マスタの整備、テスト出荷を行ったうえでテスト注文による確認を行い、負荷テストを経て本番へ進みます²。
ロジクラはネクストエンジンとの連携で、入荷連携、受注取込、出荷確定連携、出荷数反映の順を推奨しています¹。
倉庫に在庫が登録されてから受注を流し、出荷の確定を受注側へ戻すという順序は、最初に見た往復と同じ並びです。

テスト注文では、STOCKCREWの手順に沿うと次の五つを順に確かめます²。

• 受注管理システムが注文を受信したか
• 出荷指示が送信されたか
• 倉庫のWMSが出荷指示を受信したか
• 在庫の減算が反映されたか
• 追跡番号が受注側へ返ってきたか

途中のどこかで止まれば、止まった場所で原因の見当が付きます。
倉庫側で受信できていなければ送信やファイル形式、在庫が減っていなければ商品コードの突き合わせ、追跡番号が戻らなければ帰りの連携の設定、という具合です。
本番で同じ症状が出たときにも、この順にたどれば切り分けができます。

障害時の再送とログ確認

本番運用に入っても、通信の不調などで送信が失敗することはあり得ます。
STOCKCREWは、送信に失敗したら時間をおいて再送し、送信ログを定期的に確認する運用を示しています²。

受注側の担当者にとっての論点は、失敗に誰がいつ気づくかです。
送信ログを見る担当者を決めていないと、倉庫に届いていない注文が、購入者からの問い合わせで初めて見つかることになりかねません。
あわせて、再送したときに倉庫側で同じ出荷指示が二重に登録されないかも、事前に倉庫へ聞いておきたい点です。

既存方式との並行運用

CSVからAPIへ切り替える場合、STOCKCREWは既存の連携を続けたまま並行してテストし、問題がないことを確かめてから切り替えるとしています²。
並行運用をどのくらいの期間続けるかについて、確認できた目安はありません。

並行運用中に同じ注文がCSVとAPIの両方から倉庫へ届くと、二重に出荷されるおそれがあります。
テスト用の注文だけを新しい方式に流すのか、どの時点で古い方式を止めるのかは、倉庫と日程を合わせて決めます。
切り替えの判断には、テスト注文の確認がすべて通ったこと、出荷量の多い日でも遅れや送信失敗が出ないこと、自動連携されない項目の運用が回っていることを使います。

▼ 図の内容を文字で読む

1. 倉庫が対応する方式と条件を確かめる
2. 商品コードを揃え、自動連携されない項目の担当を決める
3. テスト注文で行きと帰りの往復を確かめる
4. 出荷量の多い場面でも遅れや失敗がないか確かめる
5. 既存の方式を続けたまま並行して動かす
6. 倉庫と決めた時点で古い方式を止める

費用と準備の負担は方式でどう違い、いつ見直すか

確認できた費用・期間の条件

連携の費用は、受注管理システム、倉庫、契約の組合せで決まります。
方式ごとの一般的な相場として示せる額はありません。
手掛かりになるのは、特定の事業者や製品について公開されている条件です。

STOCKCREWは、同社では受注管理システムとの連携設定に追加費用は発生しないと記載しています²。
ロジクラとネクストエンジンの連携では、ネクストエンジン側の連携オプションの契約が必要で、トライアル期間中は無料とされています¹。
前者は倉庫を運営する発送代行側の条件、後者は受注管理システム側の条件です。
同じ連携でも、費用がどちらの側でかかるかは組合せによって変わります。

費用とは別に、準備の作業量という負担もあります。
STOCKCREWは、APIの初期設定には期間がかかる一方、商品マスタが整っていれば標準より短い期間で設定できるとしています²。
前の節で触れた商品コードの整理が、準備の大きさを左右するということです。
見積もりを取るときは、受注管理システム側のオプション、倉庫側の設定、自社で行う商品マスタの整備を分けて、それぞれ誰が負担するかを聞くと比べやすくなります。

見直しの判断時期

CSVで始めた場合の見直しは、件数そのものより、反映の遅れや転記の負担が業務に表れた時点が目安になります。
取り込みの合間に売れた商品の在庫が足りなくなる、追跡番号の反映が遅れて購入者からの問い合わせが増える、ファイルの書き出しと取り込みを担当者が一日に何度も繰り返している、といった状態です。
STOCKCREWが示す切り替えの件数目安も、こうした症状が出始める規模についての一社の見立てとして参考にできます²。

一方で、見直しのきっかけが在庫調整や棚卸しのずれなら、方式を変えても解決しない可能性があります。
APIにしても、在庫調整や棚卸しの結果が自動連携の対象外になる例があるためです¹。
この場合は、方式の変更より先に、対象外の項目を誰がどう伝えるかという運用を見直すほうが効果に直結します。

倉庫や受注管理システムを変えるとき、出荷拠点を増やすときも、見直しの時期です。
拠点別の連携ができない組合せもあるため¹、拠点の追加は連携の範囲そのものを変える可能性があります。

▼ 図の内容を文字で読む

• 反映の遅れや転記の負担が出たとき
  • CSVからAPIなど方式の変更を検討する
• 在庫調整や棚卸しのずれが出たとき
  • 方式より先に対象外の項目の伝え方を見直す
• 倉庫・受注管理システム・拠点を変えるとき
  • 拠点別の連携ができるかなど、連携の範囲を確かめる

標準化の動きは、倉庫との連携を選ぶ判断を変えるか

物流情報標準ガイドラインの位置づけ

国土交通省は2025年に、物流情報標準ガイドラインをVer.3.00へ改訂したと発表しました⁵。
運送計画や出荷情報などを標準化してデータの共有と効率化を図るもので、管理はフィジカルインターネットセンターが担っています⁵。

ただし、このガイドラインは運送・物流情報の標準です。
受注管理システムと倉庫のつなぎ方そのものを定めたものではありません。
発表では対応が義務かどうかは示されておらず、出荷指示や出荷実績にあたる個別の項目がどう定義されているかも、発表からは分かりません。

そのため、いま連携方式を選ぶ判断は、倉庫側がどの方式と製品に対応しているかを確かめることから変わりません。
今後、受注管理システムや倉庫の提供元が標準への対応を案内したときに、それが自社の連携項目に関係するかを提供元に聞けば足ります。

倉庫が対応する方式や、自動連携されない項目は組合せごとに違い、受注側の担当者だけでは何を聞けばよいかを整理しにくいためです。

自社で転記している箇所と倉庫へ確認する項目を一緒に整理し、CSVから始めるかAPIを検討するかの見当を付けられます。無料相談で要件を整理する

要点の整理

軸	基準
往復の把握	行きの出荷指示と、帰りの出荷実績・追跡番号・在庫で、手作業の箇所を分ける
方式の選択	反映の遅れが業務に効くか、倉庫がその方式に対応しているかで決める
倉庫への確認	連携実績の組合せ、方式、契約や拠点の条件、返してもらう情報、対象外の項目
データの統一	商品コードを先に一致させ、自動連携されない項目は担当と突き合わせの時期を決める
切り替え	テスト注文で往復を確かめ、既存方式と並行してから古い方式を止める
見直し	件数そのものより、遅れや転記の負担が業務に表れた時点や、倉庫・拠点の変更時

切り替えの段取りを誤ると、テスト中の注文の二重送信や送信失敗の見落としで出荷が止まるおそれがあるためです。 テスト注文で確かめる項目、送信ログを見る担当、並行運用から古い方式を止める時点の決め方を、自社の体制に合わせて確認できます。

よくある質問

CSV連携からAPI連携へはいつ切り替えるのが妥当ですか。

件数より、反映の遅れや転記の負担が業務に表れたかで判断します。
取り込みの合間に在庫が合わなくなる、追跡番号の反映遅れで問い合わせが増える、といった症状が目安です。
発送代行会社が切り替えの件数目安を示している例もありますが、一社の案内で一般基準ではありません²。
切り替えるときは既存のCSV連携を続けたまま並行してテストし、問題がないことを確かめてから古い方式を止めます²。

商品マスタや在庫調整は、連携後も手作業が必要ですか。

製品によっては必要です。
ロジクラとネクストエンジンの連携では在庫調整、棚卸しの結果、商品情報の更新は連携されず¹、BOSSとロジザードZEROの例でも商品マスタはCSVで手動の受け渡しとされています⁴。
自動連携の範囲は製品ごとに違うため、倉庫と受注管理システムの提供元に対象外の項目を聞き、担当と突き合わせの時期を決めておきます。

外部倉庫が自社の受注管理システムに対応していないときはどうすればよいですか。

まず、倉庫が使っているWMSと自社の受注管理システムの間に連携があるかを聞きます。
受注管理システムが倉庫ごとではなくWMSとつながっている例があるためです³。
それもなければ、倉庫が指定する出荷指示ファイルの形式にCSVで合わせ込めるかが次の選択肢になります²。
いずれも難しい場合は、委託先を選び直すか受注管理システムを見直すかの判断になり、どちらを優先するかは自社の事情で決まります。

連携後に在庫がずれたら、どこを確認すればよいですか。

次の順に見ていくと、原因を切り分けやすくなります。
一つ目は商品コードで、受注側と倉庫側で一致していないと在庫が正しく減りません¹²。
二つ目は自動連携されない変更で、倉庫での在庫調整や棚卸しの修正が受注側に伝わっていない可能性があります¹。
三つ目は送信ログで、送信に失敗して倉庫に届いていない注文がないかを見ます²。
CSVの場合は、まだ取り込まれていない分がずれに見えていることもあります。

返品やキャンセルは連携の対象になりますか。

キャンセルは注文ステータスの一つとして扱われます²。
ただし出荷指示を送った後のキャンセルが止められるかは倉庫側の運用によるため、伝え方を事前に決めておきます。
返品は範囲が限られる例があり、STOCKCREWでは物流起因の返送のみが対象で、購入者都合の返品処理は対象外です²。
他の倉庫でも同じとは限らないため、個別に確認が必要です。

1. 1　出典：株式会社ロジクラ「基本:ネクストエンジン連携の仕組み」（2026年閲覧）
2. 2　出典：STOCKCREW「OMSと物流の連携に関する解説」（2026年閲覧）
3. 3　出典：LNEWS「GoQSystemとWMSのAPI連携強化に関する報道」（2026年）
4. 4　出典：commercepick「ロジザードZEROとBOSSがAPI連携開始」（2025年）
5. 5　出典：国土交通省「物流情報標準ガイドラインVer.3.00改訂の報道発表」（2025年）