受注管理システムとWMSの連携：自動化の範囲・方式の選び方・導入前の確認項目

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

B2B EC-COLUMN

受注から出荷・在庫反映まで、連携で自動になる作業と手作業に残る作業

毎朝、受注管理システムから出荷分をCSVで書き出し、倉庫へメールで送る。
夕方には倉庫から届いた出荷済みの一覧を見ながら、受注の状態と在庫数を手で直す。
この往復のどこかで転記が漏れると、出荷遅れや在庫のずれにつながります。
受注管理システムと倉庫のWMSを連携すると、商品マスタや受注・出荷指示の受け渡しと、出荷実績・在庫の戻しを自動にできる余地があります。
ただし、どの項目をどちら向きに渡せるかは製品の組合せごとに違います。
標準連携が用意されているか、個別開発になるかが分かれ目です。

受注・商品マスタを倉庫へ渡す

手作業で回している受け渡しを並べると、向きが二つあります。
受注管理システムから倉庫へ渡すものと、倉庫から戻ってくるものです。
倉庫へ渡すのは、どの商品をどれだけ、どこへ出すかという情報です。
WMS（倉庫管理システム：入荷・保管・ピッキング・出荷と在庫を管理する仕組み）は、受け取った品目コードを自分の商品マスタと照らし合わせ、棚の場所や数量を引き当てます。
このため、出荷指示より先に商品マスタが両方でそろっていることが前提になります。

公表されている連携の例でも、最初に自動化されているのはこの部分です。
ネクストエンジンとロジザードZEROの組合せでは、2020年に受注と商品マスタのAPI連携から始まり、同じ年のうちに在庫と出荷実績の連携が加わりました¹。
ERPのApaRevoとロジザードZEROの組合せでは、ApaRevoから商品マスタ・取引先マスタ・入荷予定・出荷指示を渡す形が示されています²。
取引先マスタまで倉庫へ渡す組合せがある点は、企業間取引では見ておきたいところです。
出荷先が取引先ごとに決まっている場合、倉庫側で出荷先を判別する材料になり得るためです。

一方で、同じロジザードZEROでも、相手のシステムによって渡す項目の並びは異なります。
ネクストエンジンとの発表では、出荷指示の自動化は明示されていません¹。
「WMSにつなげば受注から出荷まで全部自動になる」とは言えず、組合せごとに項目を確かめる必要があります。
まずこの点を押さえておくと、後の方式選びで期待と実際がずれにくくなります。

出荷指示と出荷実績・送り状番号の戻し

倉庫が出荷を終えると、今度は逆向きに、どの注文をいつ出したかという出荷実績が戻ります。
ApaRevoとロジザードZEROの例では、ロジザードZEROから入荷実績・出荷実績・ロケーション移動を受け取る向きが示されています²。
手作業の運用では、倉庫から届く出荷済み一覧を見て受注の状態を「出荷済み」に変え、得意先への出荷連絡や請求の準備に進んでいるはずです。
この戻しが自動になると、一覧との照合と状態の書き換えが減ります。

送り状番号（配送伝票の追跡番号）が出荷実績と一緒に戻るかどうかは、ここで取り上げた発表資料では項目として確認できません。
得意先から配送状況を問い合わせられたとき、受注画面で番号が見られるかどうかは担当者の手間に直結します。
出荷実績の項目に送り状番号や運送会社が含まれるかは、連携先ごとに見ておきたい点です。

在庫の反映と、手作業に残る作業

在庫の戻しは、受注管理システム側で「いま引き当てられる数」を正しく保つためのものです。
倉庫で実際に出荷した数や入荷した数がWMSに記録され、それが受注側へ反映されることで、次の受注を受けるときの在庫表示がずれにくくなります。
ネクストエンジンとロジザードZEROの例でも、在庫は出荷実績とともに後から追加された連携項目でした¹。

連携しても、すべての手作業が消えるわけではありません。
入荷予定や返品の情報が組合せの連携範囲に入っていなければ、その分は従来どおり人が渡すことになります。
また、項目がそろっていても、エラーで送られなかったデータに気づく仕事や、キャンセルの扱いのように両者の取り決めが要る仕事は残ります。
どの作業が自動になり、どれが残るかを一覧にしておくと、次に方式を選ぶときの判断がしやすくなります。

▼ 図の内容を文字で読む

1. 商品マスタ・受注を倉庫へ渡す
   • 品目コードが両方でそろっていることが前提
2. 出荷指示を倉庫へ渡す
   • 自動化の対象かは組合せで異なる
3. 出荷実績を受注側へ戻す
   • 送り状番号を含むかは連携先ごとに確認
4. 在庫を受注側へ反映
   • 次の受注の引当に使う

連携方式の選び方：API・ファイル授受・標準連携の違いと向く条件

反映のタイミングの違い

方式の違いは、技術の名前で覚えるより、次の三つで比べると自社に合うかを判断しやすくなります。
データがいつ相手に届くか、使うために何を追加で用意するか、作った後に誰が直すかです。
ここでいうAPI連携は、システム同士が決められた形式で直接データをやり取りする方式です。
ファイル授受は、CSVなどのファイルを書き出して所定の場所に置き、相手が取り込む方式です。
標準連携は、ベンダーが特定の相手製品との接続をあらかじめ用意したもので、中身がAPIの場合もファイルの場合もあります。

反映のタイミングについて、EC発送代行事業者のSTOCKCREWは、API連携では在庫の同期がほぼ即時なのに対し、CSV連携では取り込みまでに時間差が生じると説明しています³。
その間に複数の販売チャネルで売れると、在庫以上に販売してしまうという指摘です³。
これは消費者向けECの発送代行の立場からの説明です。
企業間取引で、得意先からの注文を決まった時刻にまとめて処理しているなら、ファイルの取り込み間隔がその区切りに合っていれば、時間差が問題になりにくい場面もあります。
逆に、受注のたびに在庫を回答する運用や、複数の受注経路から同じ在庫を引き当てる運用では、時間差の分だけ引当のずれが起きやすくなります。

利用条件・追加契約と個別開発の要否

標準連携があれば手軽に使える、とは限りません。
ネクストエンジンとロジザードZEROの連携では、両サービスの契約に加えて、連携アプリ「ネクストエンジン カスタムデータ作成」の申込みが条件とされていました¹。
SFTPでのアップロードは、月額の追加オプションとして案内されています¹。
いずれも2020年の発表時点の条件で、現在の内容は各社の案内で確かめる必要があります。

個別開発の負担については、ApaRevoとロジザードZEROの発表で、WMSとERPの自動連携は従来個別開発が必要で、標準連携が進みにくかったと説明されています²。
この組合せでは、API連携オプションとして標準で提供され、最初の利用企業が稼働していると発表されました²。
個別開発では、項目の対応付けやエラー時の処理を自社用に作り込むため、どちらかのシステムが仕様を変えたときの改修も発生します。
標準連携は、提供する側が接続を用意しているぶん自社で作り込む部分は小さくなりますが、連携できる項目や向きは用意された範囲に限られます。
仕様変更時の改修を誰が担うかは、契約条件で確かめる点です。

これらを並べると、方式の違いは技術の種類よりも、標準連携の有無、追加の契約や申込み、反映の遅れという負担の種類で比べたほうが判断しやすい、と編集部では考えています。
次の表は、確認できた発表と解説の範囲で整理したものです。
資料で確かめられなかった欄はそのように記しています。

方式を選ぶときの目安

STOCKCREWは、出荷件数が一定の規模を超える、複数のチャネルで販売している、定期便がある、のいずれかに当てはまればAPI連携を勧めています³。
この基準は一事業者の見解で、業界共通の線引きではありません。
ただ、挙げられている条件には共通点があります。
どれも、在庫の引当が頻繁に起きるか、同じ在庫を複数の経路が取り合う状況です。

企業間取引に置き換えると、判断の手掛かりは次のような問いになります。

• 得意先へ在庫数や納期を回答するとき、どの時点の在庫を見ているか
• 営業の入力、受発注サイト、EDIなど受注経路が複数あり、同じ在庫を引き当てているか
• 出荷締め時刻の直前に受注が集中するか
• 自社のシステム担当者が、連携部分の改修やエラー対応を引き受けられるか

前の三つに当てはまるほど反映の早さが効き、最後の問いに不安があるほど、標準連携が用意されている組合せを選ぶ意味が大きくなります。
ただ、どの方式も相手の製品が対応していなければ選べません。
そこで次に、自社の組合せで何が用意されているかを確かめます。

▼ 図の内容を文字で読む

• API連携
  • 在庫の同期がほぼ即時（発送代行事業者の説明）
  • 個別開発では作り込みと仕様変更時の改修が自社に生じる
• ファイル授受
  • 取り込みまでに時間差が生じる（発送代行事業者の説明）
  • 決まった時刻にまとめて処理する運用なら問題になりにくい場面もある
• 標準連携
  • 両サービスの契約に加え、連携アプリの申込みが条件だった例
  • 連携できる項目や向きは用意された範囲に限られる

自社のシステムと倉庫は連携できるのか：確認する資料の順序

連携対応システム一覧で確認すること

最初に見るのは、受注管理システムとWMSの双方が公開している連携対応の一覧です。
相手の製品名が載っていれば標準連携の候補になり、載っていなければAPIやファイル授受を使った個別の接続を検討することになります。
一覧に名前があっても、連携の範囲が同じとは限りません。
同じロジザードZEROでも、ネクストエンジンとの組合せは受注・商品マスタから始まって在庫・出荷実績へ広がりました¹。
ApaRevoとの組合せでは、入荷予定や出荷指示、ロケーション移動まで含まれていました²。

一覧や製品案内で拾っておきたいのは、次の四点です。

• 標準連携か、個別対応か
• どの項目を、どちら向きに渡すか
• 即時に送るか、決まった時刻にまとめて送るか
• 連携アプリやオプションなど、追加の申込み・契約があるか

申し込む窓口も組合せで変わり得ます。
ネクストエンジンとの連携は、受注側の連携アプリの申込みが条件でした¹。
ApaRevoとの連携は、ロジザードの発表でAPI連携オプションとして案内されています²。
どちらのベンダーに申し込み、どちらに問い合わせるのかを早めに把握しておくと、確認の行き違いが減ります。

API仕様・倉庫側の受入条件で確認すること

一覧で候補が見えたら、API仕様や連携仕様書で項目の中身を確かめます。
見たいのは、自社の受注データに必要な項目の受け皿が、相手側に用意されているかです。
たとえば受注側で得意先ごとの出荷先や納品書の備考を持っていても、WMS側の出荷指示に対応する項目がなければ、その情報は倉庫に届きません。
取り込みでエラーになったときに再送できるか、処理の記録（ログ）を誰が見られるかも、稼働後の手間を左右します。

最後に、倉庫側の受入条件です。
倉庫を自社で運用しているなら、WMSの設定と倉庫の作業手順を自社で決められます。
外部の倉庫（3PL：物流業務の受託事業者）が運用するWMSにつなぐ場合は、受け付けるファイル形式や送信の時刻、連携の窓口を倉庫事業者の条件に合わせることになります。
自社運用なら受注管理システムとWMSの両ベンダー、3PLならそれに加えて倉庫事業者が確認の相手です。

この順序は、範囲の広い資料で先に候補を絞り、細かい仕様の確認を候補だけに使うための編集部の提案です。
一覧を飛ばして仕様書を読み込むと、標準連携が用意されていた、あるいは相手先が対応していなかった、と後で分かることがあります。

▼ 図の内容を文字で読む

1. 連携対応システム一覧
   • 標準連携か個別対応か
   • 追加の申込み・契約があるか
2. API仕様・連携仕様書
   • 自社の受注データの項目の受け皿があるか
   • 取り込みエラー時の再送とログ
3. 倉庫側の受入条件
   • 受け付けるファイル形式と送信の時刻
   • 3PLの場合は倉庫事業者の窓口

取引先別単価・分納・欠品・返品は連携で崩れないか

ベンダーへ確認する項目

企業間取引の受注には、取引先ごとに決めた単価、一つの注文を何回かに分けて出す分納、得意先の複数の店舗や現場への出荷といった事情が加わります。
ここで取り上げた発表や解説には、これらを連携でどう扱うかの記載がありません。
扱えるかどうかを一般論で決めず、自社の組合せで一つずつ確かめることになります。

迷いやすいのは、その情報が倉庫に必要かどうかです。
単価はピッキングや梱包の作業には使いません。
ただ、倉庫で納品書を印刷して同梱している場合は、取引先別の単価が出荷指示に載っていないと正しい納品書が作れません。
倉庫に何を任せているかによって、渡すべき項目が変わります。

ベンダーへ確かめたい点は、次のとおりです。

• 取引先別の単価や掛率を、出荷指示や納品書の項目として渡せるか
• 分納のとき、一つの受注に対して複数回の出荷指示と出荷実績を紐付けられるか
• 一つの受注で出荷先が複数ある場合、出荷先ごとに指示を分けられるか
• 受注側の「一部出荷済み」の状態を、戻ってきた出荷実績から判別できるか

分納の扱いは、出荷実績が戻ったときに受注の残数をどう計算するかに関わります。
一回目の出荷実績で受注全体が「出荷済み」になってしまうと、残りの出荷指示が出せなくなるか、手で状態を戻す作業が生まれます。
連携前の運用で分納をどう記録しているかを書き出しておくと、ベンダーとの確認で話が具体的になります。

欠品・返品・キャンセルの取り決め

欠品と返品、キャンセルについては、発送代行事業者の解説に手掛かりがあります。
STOCKCREWは、定期便で欠品が出た場合に出荷を自動で保留し、入荷後に再開する例を挙げています³。
また、配送の過程で戻ってきた荷物（物流起因の返送品）は、受注管理システム側へ通知して在庫に戻せるとしています³。

いずれも消費者向けの定期通販を中心にした説明です。
企業間取引で得意先が商品を返品する場合、検品して良品として在庫に戻すのか、不良として別に管理するのか、返品の伝票を受注側でどう起こすのかは、連携より前に業務として決めることになります。
連携が担うのは、決まった結果を相手のシステムへ渡す部分です。
良品か不良かの判断そのものは人に残ります。

キャンセルは、タイミングによって扱いが変わります。
STOCKCREWは、受注側でキャンセルした注文がすでに出荷指示として倉庫へ渡っている場合の扱いを、事前に取り決めておく必要があると指摘しています³。
倉庫ではピッキングが始まっているかもしれず、受注側の状態を変えただけでは出荷を止められないことがあるためです。
どの時点までなら連携で取り消せ、どの時点からは電話などで倉庫に直接止めてもらうのかを倉庫と決めておくと、得意先からの急なキャンセルにも手順どおりに動けます。

導入前に決めること：ステータス・SKU・締め時刻・テスト

ステータスと出荷指示を送る条件

STOCKCREWは設計時の確認点として、注文ステータスの対応、出荷指示の確定タイミング、SKUの統一、締め時刻前の送信、エラー検知、テスト注文での全フロー検証を挙げています³。
消費者向けECの発送代行を前提にした整理です。
企業間取引では、与信や締め請求、取引先ごとの条件を足して読み替える必要があります。

ステータスの対応付けとは、受注管理システム側の状態とWMS側の状態のどれとどれが対応するかを決めることです。
受注側の「出荷待ち」「出荷済み」「キャンセル」と、たとえばWMS側の「指示受付」「作業中」「出荷完了」を一つずつ結び付けます。
名前が似ていても意味が違うことがあり、対応を決めずにつなぐと、倉庫では出荷完了なのに受注側では出荷待ちのまま、といったずれが生まれます。
特にキャンセルは、前の節で触れた倉庫との取り決めを、ステータスの上でどう表すかまで決めておきます。

出荷指示を送る条件も、企業間取引では決めることが増えます。
前払いの得意先なら入金の確認後、掛け取引の得意先なら与信枠の確認後というように、取引先によって出荷してよい状態が違うことがあるためです。
受注が確定した瞬間に出荷指示を自動で送る設定にすると、こうした確認の前に倉庫が動いてしまいます。
取引先ごとに送る条件を変えられるかは受注管理システム側の機能によるため、要件として書き出しておきます。

品目コードと出荷締め時刻

品目コード（SKU：在庫を管理する最小単位の商品コード）は、受注側とWMS側で統一しておくことが確認点に挙げられています³。
受注側では色違いを一つの品番で持ち、倉庫では色ごとに別のコードで管理している、といった食い違いがあると、出荷指示が取り込めないか、別の商品が引き当てられます。
連携の前に両方の商品マスタを書き出し、コードと単位（ケース、ボール、バラなど）を突き合わせておくと、取り込みエラーの原因を事前に洗い出せます。

出荷締め時刻は、倉庫がその日のうちに出荷できる指示の受付期限です。
STOCKCREWは、締め時刻より前に余裕を持って出荷指示を送ることを確認点に挙げています³。
ファイル授受で決まった時刻にまとめて送る方式なら、最後の送信が締め時刻に間に合うように送信の時刻を組む必要があります。
締め直前の受注が翌日扱いになる境目も、そこで決まります。
得意先に当日出荷を約束している場合は、約束している受付の時刻、連携の送信時刻、倉庫の締め時刻が一続きになっているかを見ておきます。

本番前のテスト

本番の前に、テスト用の注文で受注から出荷指示、出荷実績、在庫の戻しまでを一巡させます³。
通常の注文だけでなく、キャンセル、欠品、分納、複数の出荷先といった例外の注文も混ぜておくと、ここまでに決めた取り決めが実際の画面と帳票でどう表れるかを確かめられます。
テストで戻ってきた出荷実績を受注側の画面で開き、分納の残数や送り状番号の表示まで見ておくと、稼働後に得意先から問い合わせを受けたときの動きも想定できます。

受注管理システムを新しく入れる場合は、こうした連携の要件整理が導入作業の中に組み込まれていることもあります。
たとえばEC-Rider B2B Ⅱの導入では、要件定義の段階に外部システム連携の連携要件の整理と、外部連携先・外部仕様の整理が含まれ、連携の費用は要件定義の後に見積もる形になっています⁴。
システムの入れ替えと連携を同時に進めるなら、ここまでに挙げた項目を先に洗い出しておくと、要件定義の場で自社の事情をそのまま伝えられます。

連携後の在庫差異・データ不整合を検知し、運用で防ぐ

差異が出る主な原因

連携が動き始めても、受注側とWMS側の在庫数が食い違うことはあります。
STOCKCREWは在庫差異の原因として、CSVの更新の遅れ、APIのタイムアウト（応答待ちの時間切れ）による更新漏れ、入荷データの反映の遅れを挙げています³。

この三つは起き方が違います。
CSVの更新の遅れは、取り込みまでの間に受注が入ることで起き、次の取り込みで追い付く性質のずれです。
タイムアウトによる更新漏れは、失敗したデータが再送されない限り残り続けるため、気づくまでずれが積み上がります。
入荷データの反映の遅れは、倉庫に商品が届いているのに受注側では在庫がない状態を生み、受けられる注文を断ってしまう方向に働きます。
ずれが一時的か、残り続けるか、どちらの方向に出るかが違うため、見つけ方も変わります。

日次の突き合わせと緊急時の手順

STOCKCREWが挙げる対策は、API連携への移行、WMSの在庫レポートとの日次の突き合わせ、差異が出たときの手順の事前整備です³。
方式の移行は前の節で見た判断の話なので、ここでは稼働後の運用を考えます。

日次の突き合わせは、WMSから出した在庫の一覧と受注管理システムの在庫数を品目コードで並べ、差がある品目だけを見る作業です。
差が出た品目について、その日の出荷実績や入荷実績が受注側に届いているかをたどると、前の項で挙げたどの原因によるものかの見当がつきます。
全件を転記していた頃と比べると、見る対象が差のある品目に絞られます。

差異が見つかったときに誰が何をするかは、事前に決めておきます。
出荷実績が戻っていない注文を見つけたら、倉庫に再送を依頼するのか、受注側で取り込み直すのか。
在庫数を直すときは、どちらのシステムの数を正とするのか。
差が大きい品目は、原因が分かるまで受注の受付を止めるのか。
連携の仕組みが再送やエラー通知をどこまで備えているかは製品の仕様によるため、仕様で足りない部分を、こうした運用の取り決めで補う形になります。
決めておけば、差異に気づいた担当者がその場で判断に迷う時間が減ります。

▼ 図の内容を文字で読む

• CSVの更新の遅れ
  • 次の取り込みで追い付く一時的なずれ
  • 取り込み前の受注で引当がずれる
• APIのタイムアウトによる更新漏れ
  • 再送されない限り残り続ける
  • 気づくまでずれが積み上がる
• 入荷データの反映の遅れ
  • 倉庫にあるのに受注側では在庫がない
  • 受けられる注文を断る方向に働く

連携の可否は製品の組合せと自社の受注業務の両方で決まり、連携対応一覧や仕様書を読むだけでは、自社の得意先条件をどの項目で倉庫へ渡すかまで整理しきれないことがあるためです。

受注管理システムの導入時の要件定義で、外部連携の要件と連携先の仕様を整理し、WMSへ何を渡し何を受け取るかを要件として書き出せます。連携の費用は、要件定義の後の見積もりで確かめられます。無料相談で要件を整理する

要点の整理

軸	基準
自動化の範囲	受注・商品マスタ、出荷指示、出荷実績、在庫のどれをどちら向きに渡せるかは組合せごとに違う
方式の選択	反映のタイミング、追加の契約・申込み、個別開発と保守の負担で比べる
確認の順序	連携対応一覧で候補を絞り、API仕様、倉庫側の受入条件の順に確かめる
企業間取引の扱い	取引先別単価・分納・複数出荷先は公開資料で扱いを確かめにくく、ベンダーへの確認項目にする
導入前の準備	ステータス対応、出荷指示を送る条件、品目コード、締め時刻、例外を含むテスト
稼働後の運用	在庫レポートとの日次の突き合わせと、差異時の担当・正とするシステムの取り決め

取引先別の単価や分納、取引先ごとの出荷条件は公開資料で扱いを確かめにくく、自社の取引条件に即して一つずつ詰める必要があるためです。 自社の取引条件や出荷指示を送る条件を、外部連携の要件と連携先の仕様に照らして要件定義の場で整理し、連携でどこまで扱い、どこを運用で補うかを確かめられます。

よくある質問

WMSが自社運用か3PLかで、連携の確認先はどう変わりますか。

自社で倉庫を運用している場合は、受注管理システムとWMSの両ベンダーが主な確認先で、WMSの設定や作業手順も自社で決められます。
3PLが運用するWMSにつなぐ場合は、それに加えて倉庫事業者が確認先になり、受け付けるファイル形式や送信の時刻、連携の窓口を倉庫事業者の条件に合わせることになります。

CSV連携からAPI連携へ移行するとき、並行して動かす期間はどう決めますか。

期間の長さについて根拠のある目安は示せません。
決め方としては、通常の注文に加えてキャンセル・欠品・分納・複数出荷先といった例外の注文が一通り流れ、両方式の出荷実績と在庫数が一致することを確かめられるまで、と考えるのが現実的です。
出荷締め直前の受注集中など、自社で負荷が高い場面を一度は含めておくと判断材料が増えます。

受注管理システムを入れ替えるとき、WMS側で作り直すものは何ですか。

新しい受注管理システムとWMSの組合せで、標準連携があるか個別接続になるかがまず変わります。
そのうえで、ステータスの対応付け、品目コードと単位の対応、渡す項目と向き、送信の時刻を新しい組合せに合わせて決め直すことになります。
WMS側で設定変更が必要かどうかは、WMSのベンダーや倉庫事業者に確かめます。

出荷指示を送る条件（入金・与信確認後など）は、取引先ごとに変えられますか。

受注管理システム側の機能によります。
前払いの得意先は入金確認後、掛け取引の得意先は与信枠の確認後というように条件を分けたい場合は、取引先単位で出荷指示の送信条件を設定できるかを要件として挙げ、導入前に確かめておく必要があります。

出荷実績や送り状番号が戻らなかったとき、どこで検知し、誰が再送しますか。

WMSの在庫レポートや出荷一覧と受注管理システムを日次で突き合わせると、出荷実績が戻っていない注文を見つけられます。
再送を倉庫に依頼するのか、受注側で取り込み直すのかは、製品の再送機能の有無によって変わるため、稼働前に担当を決めておきます。
送り状番号が出荷実績に含まれるかどうか自体も、連携先ごとに確認が必要です。

商品マスタ（品目コード）の不一致は、連携前にどう洗い出しますか。

受注管理システムとWMSの商品マスタをそれぞれ書き出し、品目コードと単位（ケース、ボール、バラなど）を並べて突き合わせます。
色やサイズの持ち方が両者で違う品目、片方にしかない品目を抜き出しておくと、出荷指示の取り込みエラーや誤った引当の原因を事前に洗い出せます。

1. 1　出典：ロジザード（ecnomikata掲載）「ネクストエンジン×ロジザードZERO 完全自動連携の発表記事」（2020年）
2. 2　出典：ロジザード（commercepick掲載）「ロジザードZEROとApaRevoのAPI連携の発表記事」（2021年）
3. 3　出典：STOCKCREW Inc.「OMSと発送代行WMSの連携に関する解説記事」（公開年不明、2026年閲覧）
4. 4　出典：株式会社フライトソリューションズ「EC-Rider B2B Ⅱ 料金プラン・費用ページ」（2026年）