OMSに必要な機能は、受注の一元管理から始まり、在庫の引当と配分、出荷指示とWMS連携、外部連携へと続く分野に分けると、全体像をつかめます。
- 要件整理：必要な機能と運用条件を書き出す作業
- 導入設計：連携や権限の条件を整理する段階
- 定着支援：利用状況を見ながら改善する支援
OMSの機能はWMSやERPと重なって見える部分があるため、まずOMSの完全ガイドで役割分担を押さえておくと読みやすくなります。
▼全体ガイドの記事
・OMSの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
受注の一元管理機能（OMSの中核）
OMSの心臓部にあたるのが、受注の一元管理機能です。注文は、自社ECや楽天、Amazonのほか、Yahoo!ショッピングや電話・FAXからも入ってきます。これらを一つの受注一覧にまとめ、統一されたステータスで管理します。
チャネルごとに注文の形式も項目も異なるため、それを正規化して一つのデータに整える機能こそ、OMSがWMSやECカートと大きく異なる役割です。受注の入り口を一本化できるかは、OMS選定で特に重く見たい点になります。
複数チャネルの注文取込と名寄せ機能
受注一元管理の起点になるのが、各チャネルの注文を自動で取り込む機能です。各モールのAPIやCSVから注文データを定期的に取得し、OMSの受注データに変換します。注文取込は、その後の自動化を成り立たせる前提条件です。取込の頻度がリアルタイムに近いほど在庫の同期精度も上がるため、取込のスピードと正確さは必ず確認しておきたい機能です。
取り込みで重要になるのが「名寄せ」です。同じ顧客が複数のチャネルや複数回に分けて注文した場合に、それらを正しく束ねて、重複や取りこぼしを防ぎます。
取り込んだ注文は、配送方法・同梱物・ギフト指定・決済状況といった条件で自動的に振り分けられる必要があります。定型の注文はOMSのルールエンジンが出荷準備へ自動で進め、例外の注文だけを担当者に回します。この自動判定の柔軟さが受注処理の自動化率を直接左右し、取込の精度と合わせて、複数チャネルの受注を人手をかけずに捌けるようになります。
注文ステータス・ライフサイクル管理機能
OMSは、注文が生まれてから請求が完了するまでを一連のライフサイクルとして管理します。受注・与信確認・在庫引当・出荷準備・出荷済み・配送中・配送完了・請求済みといったステータスを注文ごとに正確に追跡できる機能が欠かせず、顧客の問い合わせにも即座に正確な状況を返せます。社内でも「どの注文が今どこで止まっているか」が一目で分かり、受注一覧の見やすさと検索性は現場の処理速度に直結します。
通販・ECの受注では、必ず一定割合でキャンセルや返品が発生します。そのため、キャンセル・返品・交換・分納といった例外フローを正しくステータス管理し、在庫を戻す処理や再出荷までOMS上で完結できるかが、運用の質を決めます。例外への対応が弱いOMSは、リリース後に手作業の温床を生んでしまい、例外まで扱えるかがステータス管理の成熟度を測る目安にもなります。
ステータス設計の自由度は、地味ながら運用品質を左右します。事業者によっては「与信審査中」「ギフト確認待ち」「再送手配中」といった独自のステータスが必要になります。標準のステータスしか持てないOMSでは、現場が既存のステータスを無理に流用して運用が混乱します。そこで、自社の受注フローに沿ってステータスを定義し、各ステータスに自動・手動の処理を設定できることが、現場が混乱なく使い続けられる条件です。
在庫引当・在庫配分機能
OMSがWMSと役割を分担しながら担うのが、在庫の引当と配分の機能です。ここでいう在庫は、「販売してよい在庫（引当可能在庫）」という販売側の概念を指し、倉庫の棚にある物理在庫（WMSが管理）とは別のものです。
注文が入った瞬間に在庫を引き当て、各チャネルに見せる在庫数を更新します。この引当機能こそ、複数チャネルでの二重販売（売り越し）を防ぐOMSの中核です。
WMSが「モノの在庫」を、OMSが「販売可能な在庫」を管理するという役割分担を押さえることが、機能設計の出発点になります。
リアルタイム引当と全チャネル在庫同期機能
在庫引当機能の要点は、注文の発生からチャネルへの在庫反映までのタイムラグを、いかに小さくするかにあります。1点の実在庫を全チャネルで共有し、どこかで売れた瞬間に全チャネルの在庫数を減らせば、最後の1点まで売り切れ、売り越しも防げます。同期が遅れると売り越しが起き、逆に各チャネルへ在庫を固定配分すると、片方で在庫が余って機会損失になります。
引当のロジックには、優先チャネルや取り置き在庫、予約販売への対応など、自社の販売戦略に反映できる柔軟さが求められます。たとえば、自社ECを優先して在庫を厚く配分したり、人気商品をモールに見せすぎないよう調整したりする設定を、OMS側で行う必要があります。在庫引当は販売戦略を実装する機能で、設計が甘いと在庫はあるのに売れない、あるいは売りすぎる失敗を招きます。
発売前の商品を予約注文として受け、入荷時に自動で引き当てて出荷すれば、機会損失を防ぎつつ販売を前倒しできます。この機能がないと、入荷待ちの注文を手作業で管理することになり、引き当ての漏れや二重引き当てが起きます。さらに、未来の在庫への引当（予約・取り寄せ）まで扱えるかが、引当機能の成熟度を測る指標であり、販売機会を広げたい事業者ほど重視したい点です。
WMS実在庫との突合・情物一致を保つ機能
OMSの引当在庫は、WMSが管理する倉庫の実在庫と常に突合される必要があります。OMS上では在庫ありなのに倉庫に実物がないという不整合が起きると、出荷できない注文を受けてしまいます。そのため、入荷・出荷・棚卸のたびにWMSの実在庫をOMSに反映し、情物一致（情報上の在庫と物理在庫の一致）を保つ機能が欠かせません。
まず、OMSとWMSのどちらを在庫のマスタにするかを決め、同期の方向とタイミングを設計することが、機能要件の最重要事項の一つになります。情物一致を保つ機能は、OMS選定の核心です。この突合機能は、OMSとWMSが一体型かAPI連携型かで実装が変わります。一体型なら在庫データが一つなので情物一致は保ちやすい反面、倉庫運用に合わせた細かなカスタマイズがしにくい場合があります。
別々のシステムをAPI連携する場合は柔軟性が高い一方、同期のタイムラグやエラー処理を丁寧に設計しないと、不整合のリスクが残ります。棚卸で差異が必ず見つかるため、その差異を引当在庫に反映する機能がないと、ズレが放置されて売り越しや欠品が再発します。入出庫の同期に加えて棚卸差異の補正まで扱えるかが、在庫の情物一致を保ち続ける機能の完成度を決めます。
出荷指示・WMS連携と配送管理機能
受注と在庫引当の次に来るのが、出荷指示を出してWMSや3PLへ作業を渡す機能です。OMSは「何を、いくつ、どこへ、どの配送方法で送るか」という出荷指示を生成し、倉庫側のWMSへ連携します。
ここで、どこまでをOMSが受け持ち、どこからをWMSが受け持つかがはっきりします。OMSが出荷指示という「指令」を出し、WMSがピッキング・梱包・出荷という「現場作業」を担います。
この受け渡しがスムーズかどうかで、受注から出荷までのリードタイムが決まります。
出荷指示の生成と最適拠点への振り分け機能
出荷指示機能の基本は、注文情報を倉庫が作業できる形の指示データに変換することです。配送伝票の発行、送り状番号の取得、同梱物やギフトラッピングの有無といった情報を、OMSが出荷指示にまとめてWMSへ渡します。出荷指示は、受注情報を物流の実行情報へ翻訳する重要な接続点です。
複数倉庫や3PLでは、顧客の住所や在庫の所在地に応じて拠点を自動で振り分け、配送リードタイムと送料を最適化できます。また、複数の配送会社を使い分けるなら、注文ごとに最適な会社を選び、それぞれのフォーマットで送り状やラベルを発行する必要があります。この連携が自動化されていないと、出荷の現場で配送会社ごとに手作業が発生し、せっかくの自動化が最後の工程で詰まります。
出荷後は、WMSや配送会社から出荷実績と追跡番号を受け取り、注文を出荷済み・配送中・配送完了へ進める逆方向の連携も必要です。この双方向の流れがあって、OMSは注文ライフサイクルの全体を管理できます。受注から出荷指示、送り状発行、配送追跡までが一気通貫でつながって初めて、出荷連携機能は本来の効果を発揮します。
OMSとWMSの役割分担を踏まえた機能境界
OMSは「注文＝情報」を、WMSは「倉庫の中のモノ＝物理」を管理するため、両者の機能の線引きが欠かせません。ロケーション管理やピッキングルートの最適化、検品や棚卸などの倉庫内作業はWMSの領域で、OMSが持つべき機能ではありません。一方で、複数チャネルの受注一元化や販売可能在庫の引当は、OMSの領域です。
この線引きを曖昧にしたまま機能を盛り込むと、両システムで機能が重なり、在庫データが二重管理になって不整合を生みます。そのため実務では、どちらが在庫のマスタか、在庫更新の責任はどちらかを、OMSとWMSの間で明確に決めておくことが欠かせません。
自動倉庫やマテハン機器を使う現場では、WMSのほかにWCS（倉庫制御システム）とWES（倉庫実行システム）の役割も絡みます。OMSはこれらの上流に位置し、受注の司令塔として全体を起動します。機能境界は要件定義で最優先に詰めるべき論点で、正しく設計することが、システム間の不整合を防ぐ要になります。
ECモール・ERP・決済との外部連携機能
OMSは、ECモールやERP、決済などの外部システム（WMSを含む）と連携して初めて、受注の司令塔として効果を発揮します。連携機能の設計は、OMSの費用と効果を大きく左右します。
どのモールに標準対応しているか、ERPとどう同期するか、APIの仕様はどうかを見極めることが、OMS選定の実務的な決め手になります。
モール・ERPとのAPI連携と請求機能
モール連携は、OMSが各ECモールのAPIを通じて注文・在庫・出荷情報をやり取りする機能です。対応モールが多いほど運用は楽になりますが、連携費用は1モールあたり20〜100万円が相場とされ、対象が増えるほど構築費もかさみます。標準対応していないモールや独自カートは個別開発になるため、自社が使う販売チャネルへの対応範囲を最初に確認する必要があります。
連携の作り込みを誤ると、せっかくの一元管理が一部チャネルで分断されてしまいます。ERP（基幹システム）連携では、受注・売上・請求のデータをOMSから基幹へ流し、受発注から請求・会計までを自動化します。基幹システムとの連携費用は100〜500万円が目安で、二重入力やデータ不整合をなくせる効果が、その投資に見合います。
さらに、決済サービスとの連携で与信確認や入金消込を自動化すれば、受注から入金までの流れが途切れずつながります。これらの連携を含めて、OMSは受注情報を全社のシステムへ橋渡しする役割を果たします。連携範囲が広いほど効果は大きい一方で費用も増えるため、優先順位を付けて進めることが大切です。
必須機能と「あれば便利」を切り分ける考え方
機能を網羅的に把握したあとは、「必須機能」と「あれば便利な機能」を切り分ける作業が欠かせません。OMSは機能を盛り込むほど費用が膨らむため、すべてを最初から作ろうとすると予算が破綻します。複数チャネルの受注一元化や在庫引当、出荷指示、WMS連携など、これがないと受注業務が回らない機能は必須です。
一方で、高度な需要予測や分析ダッシュボード、顧客分析（CRM寄りの機能）は、効果を見ながら後から追加できる「あれば便利」に分類できます。ただし、この切り分けには、受注量やチャネル数、在庫の持ち方、倉庫運用に照らして、「これがないと受注が止まる」機能を見極める作業が必要です。そのため、機能の検討は要件定義のプロセスと一体で進めるべきです。
riplaは、フルスクラッチ受託と国内開発の立場から、OMSとWMSの役割分担を踏まえた機能の網羅的な洗い出しと、必須・優先・将来追加の三段階での取捨選択を支援しています。機能要件をRFPや要件定義書にどう落とし込むかも、要件定義の段階で深く検討しておきたいテーマです。
まとめ
ここまでの機能は、注文の一元管理と在庫の引当から出荷の連携、外部との連携へと流れを追うと、漏れを防ぎやすくなります。とりわけ中核になるのは、注文の取込と名寄せ、リアルタイムな在庫引当による売り越し防止です。
また、WMSとの役割の境目を踏まえた出荷指示や、モール・ERPとのAPI連携も、OMSを受注の司令塔にする機能です。OMSは「注文＝情報」を、WMSは「倉庫のモノ＝物理」を管理するという役割分担を意識し、機能境界を明確にすることが、システム間の不整合を防ぐ要になります。
機能の検討は、一覧を眺める段階で終わらせず、自社の受注量やチャネル数、在庫の持ち方、倉庫運用に照らして「受注が止まる機能」を見極め、要件定義へ落とし込むことが大切です。
riplaはフルスクラッチ受託と国内開発を組み合わせ、OMSとWMSの役割分担を踏まえた機能の洗い出しと、自社の受注フローに合わせた機能設計を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。