受注管理システム（OMS）の選び方｜導入時期・比較項目・費用対効果

自社ECに加えてショッピングモールへ出店し、受注処理や在庫管理の負担が重くなってくると、受注管理システム（OMS）の導入が検討に上がります。しかし、注文数や店舗数だけを理由にシステム導入を決めてしまうと、現場の運用と噛み合わず混乱を招くことがあります。

この記事では、国内向け生活雑貨250SKU（色やサイズごとの商品管理単位）を自社ECと2つのモール（計3店舗）で販売し、月1,000件の注文を専任の運営担当2人で処理している架空の店舗を例に進めます。業務改善の選定作業に充てる時間は週2時間、OMS本体や初期設定、導入教育に使える初年度の外部費用予算は税抜60万円という設定です（検討の手順を整理するための説明用モデルであり、業界の導入基準や実際の料金を示すものではありません）。倉庫は1拠点で、既存のカート管理画面、配送会社の送り状発行ソフト、表計算ソフトの在庫表を使って日々の出荷を行っています。

多店舗化で日々の処理が追いつかなくなったとき、まず行うべきなのは、直近の作業でどの工程にどれだけの時間や負荷、実費が生じているかを把握することです。OMSを導入しても、決済処理や倉庫での実作業、物理的な在庫差が自動的にすべて解消するわけではありません。システムに任せる範囲と手元に残る作業を見極めたうえで、導入か保留かを判断する手順を整理します。

最初に、OMSを検討する負荷はどこにある？

何件になったら導入すべきかという一律の基準を探すのではなく、まずは直近4週間で受注取込、確認、在庫調整、送り状、例外対応にかかった時間と、未処理や再入力、再送にかかった件数と実費を工程別に測ることが出発点です。

受注管理システム（OMS）は、複数の販売チャネルから注文情報を集め、確認や処理状況の変更、出荷指示などを一括して管理する仕組みです。一方、倉庫内の棚入れ、保管位置、ピッキング、梱包といった実作業を管理する仕組みは倉庫管理システム（WMS）と呼ばれ、目的が分かれています。

検討を始める際は、注文数だけでなく、店舗数（3店舗）、取扱商品数（250SKU）、倉庫拠点（1拠点）、セールなどのピーク日の偏り、担当者数（2人）といった自店の前提条件を固定します。そのうえで、直近4週間の業務を次の5つの工程に分けて記録します。

架空店では、担当者2人の日常業務の中から上記の工程別時間を記録します。なお、ここで設けている「週2時間の選定作業」は、あくまで検討のための時間枠であり、日々の受注処理にかかる作業時間とは分けて管理します。まずは4週間の記録をもとに、自店のどこに作業の滞留や負担が生じているかを明確にしましょう。

カート・OMS・倉庫は、どこまで担当する？

「一元管理」と案内されていても、受注から出荷、返金までの全作業が同じ範囲で自動処理されるわけではありません。注文受付、決済状態、在庫連携、出荷指示、倉庫作業、追跡番号の返却、返品・返金の担当を切り分け、候補となるOMSが受け取るデータと返すデータを整理します。

各システムの機能範囲は提供元によって明確に分かれています。たとえばネクストエンジン公式機能ページ（確認日：2026年10月9日）では、受注、在庫、商品、送り状、倉庫、決済、基幹連携などが独立した機能として案内されており、標準外の連携にはアプリやAPI（システム間で直接データを連携する接続方式）が必要です。また、CROSS MALL公式機能ページでも、在庫、商品、受注、受注自動化、発注仕入、セット品、分析、実店舗連動がそれぞれ分かれています。さらに、LOGILESS公式サイトでは、自社をOMSとWMSの一体型システムを提供する会社と位置づけており、倉庫事業者ではなく出荷作業は自社倉庫または委託先倉庫が行うと明記されています。また、GoQSystem公式料金プランのように、プランごとに含まれる機能が異なり、注文情報や出荷実績の自動反映にAPI利用の追加契約が必要となる場合もあります。

業務の境界を明確にするため、各工程を担当するシステムと役割を整理します。

一体型ソフトウエアと実際の倉庫荷役を混同せず、キャンセル時の返金操作や現物の棚卸など、システムの画面外で発生する手作業の境界を確認することが重要です。

比較表には、どの受注と例外を入れる？

機能の多さだけで比べるのではなく、直近4週間の実注文から通常注文と実際に起きた例外を洗い出し、「必須」「自動化候補」「人が確認」「対象外」の4つに仕分けて比較表を作ります。

特殊な注文パターンまで最初からすべて自動化しようとすると、設定が複雑になり追加費用や開発工数が膨らむ要因になります。自店で実際に発生している注文パターンをもとに、どこまでをシステムで扱い、どこを手作業の確認として残すかを線引きします。

架空店では、直近4週間の記録から通常注文1件と、実際に発生した例外4種類（出荷前キャンセル、住所変更、ギフト、予約商品）の計5ケースを選定しました。この組み合わせは検討手順を整理するための例であり、どの店舗でも共通する合格基準ではありません。

高度な自動化機能を備えていなくても、条件に該当する注文を保留ステータスへ振り分け、担当者が目視で確認・修正する手順を組むことで運用できる場合があります。自店が期待する処理結果と日々の作業負荷が許容範囲に収まるかどうかを判断基準にしてください。

『連携対応』は、どこまで確かめればいい？

サービス案内にお使いのカートやモールのロゴが掲載されていても、自店の処理がそのまま動くとは限りません。出店している店舗ごとに、受注、在庫、商品、決済、出荷実績について、連携の向き、対象項目、更新の契機や頻度、必要な手動操作、追加費用、問い合わせ窓口を確認します。

システム間の接続にはAPIを利用する方法やCSVファイルを手動で取り込む方法があり、連携方法によって日常の手間が異なります。架空店の3店舗（自社EC、モールA、モールB）について、候補システムへ事前に確認すべき項目を整理します。

確認にあたっては、自店で必要なデータ項目（配送日時指定、備考欄、ポイント・クーポン利用額など）が正しく送受信できるかを確かめます。

追加費用にも注意が必要です。前述の通り、GoQSystem公式料金プランではプランや接続先によってAPI利用の追加契約が必要になる場合があります。また、CROSS MALL公式料金ページでも、標準対応外の自社サイトとの連携、商品数が15,000点を超える場合、実店舗の在庫システムとの接続などには個別確認や別見積が必要と案内されています。開発中や予定とされている機能は前提に含めず、現在提供されている仕様と見積書の内容をもとに確認を進めましょう。

初年度12か月の費用を、どう同条件で比べる？

月額基本料の安さだけで判断せず、初期費用、月額、従量課金、オプション、設定教育、保守費を12か月分そろえ、さらに導入後に残る手作業やミスの管理評価額を合算して比較します。

料金の仕組みは製品ごとに特色があります。ネクストエンジン公式料金ページ（料金体系は2026年10月時点のもの）では、税抜の基本料金に加え、受注件数に応じた従量課金、有料アプリの月額、契約1年経過後に発生する年間保守費用が設定されています。また、一度取り込んだ注文データは、その後にキャンセルとなった場合でも従量課金の対象件数に含まれます。一方、CROSS MALL公式料金ページでは月額固定制（全料金税抜）をとっており、注文数による従量課金はありませんが、商品点数や標準外サイトの条件によって追加費用が生じます。

架空店（月1,000件、担当2人、OMS外部費用枠は初年度税抜60万円）での12か月間の比較例を整理します。社内の作業時間評価と外部への税抜費用を分けて並べます。

※この試算は費用の構造を理解するための架空モデルであり、実際の料金や改善効果を保証するものではありません。倉庫の保管料、ECカート月額、決済手数料、仕入原価などは含まず、受注管理に関連する費目のみを対象にしています。

このモデルを判断する際は、次の3点を確認します。

1. 初年度の外部費用予算（税抜60万円）に対し、外部費用小計（税抜55万円）は枠内に収まっているか。
2. 実際の支払時には消費税が加算されるため、手元の資金計画にあわせて税込の支払総額を別途確認できているか。
3. 年間評価差の110,000円は社内作業の時給換算を含む管理上の比較であり、手元の現金がそのまま110,000円節約できるわけではないことを把握しているか。

浮いた時間を他の業務へ充てる価値をどう評価するかを含め、自店の基準で費用対効果を検討してください。

試用では、通常注文だけ通れば十分？

用意されたテストデータで通常注文が通るだけでなく、出荷前キャンセルや住所変更などの例外が期待通りに止まるか、修正できるかを確認します。

候補サービスごとに試用環境の条件を確認します。GoQSystem公式料金プランでは、「受注管理」「受注・在庫連携管理」「受注・商品・在庫連携管理」の各プランで20日間の無料お試しが案内されています。ただし、すべての製品に無料の試用期間が用意されているとは限りません。担当者によるデモ案内のみの場合や、本番環境とは切り離された制限付きテスト環境の場合もあるため、自社の手で操作できる範囲を事前に問い合わせます。

試用では、直近4週間の記録から抽出した5ケース（各1件）を実際に流し、期待した結果と実際の挙動を突き合わせます。

この5ケースは検証の手順を示すための架空の例であり、各1件の確認だけで十分な安全性を保証するものではありません。画面上で意図通りに動いたか、手動での確認や修正が無理なく行えるかを記録します。

試用にあたって重要なのは、テストデータが本番の顧客通知、実決済、実際の在庫数、倉庫の出荷作業へ影響を与えないよう事前に手当てすることです。誤って購入者へ自動メールが飛んだり、実際のカード決済が売上確定されたり、倉庫で実出荷が始まったりしないよう、テスト注文を安全に流す手順を提供元や連携先に必ず確認してください。

導入・保留・切戻しを、何で決める？

試算上の費用差や機能の豊富さだけで慌てて決めず、必須機能の動作、例外への対処、初年度費用、残る作業、データ出力、そして不具合時の切戻し手順がそろっているかで判断します。

本番へ移行するか、現在の運用を維持して見送る（保留する）かを決める際は、社内で次の条件を確認します。

• 必須要件が動いたか：自店の3店舗・250SKUに必要な基本処理が確認できたか
• 例外時の手順が定まったか：キャンセルや住所変更を安全に止め、修正する手順があるか
• 初年度の総費用が収まるか：初期費用や月額、従量、オプションを含めた年間費用が予算枠内か
• 残る手作業を受け入れられるか：導入後も社内に残る目視確認や修正の作業分担が決まっているか
• データを手元に戻せるか：万一の解約や乗り換え時に、自店の顧客や注文データを出力できるか
• 切戻し手順が決まっているか：新システムで異常が起きた際、安全に元の旧手順へ戻せるか

特に備えておくべきなのが「切戻し」です。切戻しとは、新しいシステムでの処理を停止し、以前の使い慣れた手順（各店舗の管理画面、配送会社の送り状ソフト、表計算ソフトの在庫表）へ戻す判断を指します。

架空店では、注文データが一定時間取り込まれない、同一注文の出荷指示が複数回作られてしまう、他店舗への在庫引き去りが動かず売り越しが発生する、キャンセルの荷止めができないといった異常が起きた場合を停止の検討基準として定めます。

トラブル時に旧手順へ戻す際は、慌てて旧作業を再開してはなりません。新旧双方のシステムで「どの注文まで出荷手配が済み、どの注文が未処理か」「キャンセルや返金の状態はどうなっているか」「直前の在庫差分はどうなっているか」を突き合わせます。出荷済みと未処理の注文を明確に識別し、二重処理を防止するために担当者が確認を完了してから旧手順を再開します。

まずは自店で試す範囲を決め、確認表を作成したうえで候補システムの試用へ進んでみてください。自店の業務の境界線を確かめながら進めることが、無理のない導入への着実なステップになります。

関連記事

• ネクストエンジン vs CROSS MALL：従量課金と固定料金を比較
• ECカート・受注管理・物流システム移行チェックリスト
• EC受注作業の自動化｜任せる処理・止める条件・再実行を決める