OMSの必要機能や標準機能の一覧について

OMS（Order Management System／注文管理システム）の導入を検討するとき、最初の関門になるのが「自社の受注業務に、どんな機能が必要なのか」という機能要件の整理です。OMSは、自社ECや複数モールからの注文を一元的に受け、在庫を引き当て、出荷指示を出し、配送・請求までの注文ライフサイクル全体を管理する「受注の司令塔」です。倉庫の中のモノを管理するWMS（倉庫管理システム）とは役割が異なり、OMSは「注文という情報」を管理します。この役割の違いを理解せずに機能を選ぶと、リリース後に「肝心の受注機能が足りない」「在庫が二重になる」という事態になりかねません。

本記事は、OMSが備えるべき必要機能・標準機能を、受注管理機能・在庫引当機能・出荷連携機能・外部連携機能の4つの軸で体系的に解説する「機能特化」の記事です。複数チャネルの受注一元化、在庫の引当・配分、WMSへの出荷指示、ECモールやERPとのAPI連携まで、OMS本来の役割に即して具体的に整理します。OMSの機能はWMSやERPの機能と重なって見える部分があるため、役割分担を含めた全体像をまだ把握していない方は、まずOMSの完全ガイドから読むことをおすすめします。読み終えるころには、自社の要件定義に直結する「機能チェックリスト」が頭の中に描けるはずです。

▼全体ガイドの記事
・OMSの完全ガイド

受注の一元管理機能（OMSの中核）

OMSの心臓部にあたるのが、受注の一元管理機能です。自社EC、楽天、Amazon、Yahoo!ショッピング、電話・FAXといった複数チャネルからの注文を、一つの受注一覧に集約し、統一されたステータスで管理します。チャネルごとに注文フォーマットも項目もバラバラなため、それを正規化して一つのデータに整える機能こそ、OMSがWMSやECカートと決定的に異なる本質的な役割です。受注の入り口を一本化できるかどうかが、OMS選定の最重要ポイントになります。

受注一元管理の起点が、各チャネルからの注文を自動で取り込む機能です。各モールのAPIやCSVから注文データを定期的に取得し、OMSの受注データに変換します。ここで重要なのが「名寄せ」で、同じ顧客が複数チャネルや複数回に分けて注文した場合に、それらを正しく束ねて重複や取りこぼしを防ぎます。取込頻度がリアルタイムに近いほど在庫の同期精度が上がるため、注文取込のスピードと正確さは、OMSの基本性能として必ず確認すべき機能です。

取り込んだ注文は、配送方法・同梱物・ギフト指定・決済状況といった条件で自動的に振り分けられる必要があります。OMSのルールエンジンが、定型注文を自動で出荷準備に進め、例外注文だけを担当者に回す。この自動判定の柔軟さが、受注処理の自動化率を直接左右します。前述の取込機能とこの自動判定機能がそろって初めて、複数チャネルの受注を人手をかけずに捌けるようになります。注文取込は単なる入り口ではなく、その後の自動化の前提条件です。

OMSは、注文が生まれてから配送・請求が完了するまでの一連のライフサイクルを管理します。受注・与信確認・在庫引当・出荷準備・出荷済み・配送中・配送完了・請求済みといったステータスを、注文ごとに正確に追跡できる機能が必須です。このステータス管理があるからこそ、顧客からの問い合わせに即座に正確な状況を返せ、社内でも「どの注文が今どこで止まっているか」が一目で分かります。受注一覧の見やすさと検索性は、現場の処理速度に直結します。

あわせて重要なのが、キャンセル・返品・交換・分納といった例外フローの管理機能です。通販・ECの受注は、必ず一定割合でキャンセルや返品が発生します。これらを正しくステータス管理し、在庫を戻したり再出荷したりする処理を、OMS上で完結できるかが運用の質を決めます。正常な注文だけでなく例外フローまでカバーできるステータス管理こそ、OMSの受注管理機能の成熟度を測る指標です。例外への対応力が弱いOMSは、リリース後に手作業の温床を生んでしまいます。

ステータス管理の機能を評価するときは、ステータスの定義をどこまで自社の業務に合わせてカスタマイズできるかも確認すべきです。事業者によっては「与信審査中」「ギフト確認待ち」「再送手配中」といった独自のステータスが必要になります。標準のステータスしか持てないOMSだと、現場が無理に既存のステータスを流用して運用が混乱します。自社の受注フローに沿ったステータスを柔軟に定義でき、各ステータスでの自動・手動の処理を設定できることが、現場が混乱なく使い続けられるOMSの条件です。ステータス設計の自由度は、地味ながら運用品質を大きく左右します。

在庫引当・在庫配分機能

OMSがWMSと役割を分担しながら担うのが、在庫の引当と配分の機能です。ここで言う在庫は、倉庫の棚の中の物理在庫（WMSが管理）ではなく、「販売してよい在庫＝引当可能在庫」という販売側の概念です。注文が入った瞬間に在庫を引き当て、各チャネルに見せる在庫数を更新する。この引当機能こそ、複数チャネルでの二重販売（売り越し）を防ぐOMSの中核機能です。WMSが「モノの在庫」を、OMSが「販売可能な在庫」を管理するという役割分担を理解することが、機能設計の出発点になります。

在庫引当機能の要点は、注文発生からチャネルへの在庫反映までのタイムラグをいかに小さくするかにあります。1点の実在庫を全チャネルで共有し、どこかで売れた瞬間に全チャネルの在庫数を減らす。この同期が遅れると、複数チャネルで同じ1点を売ってしまう売り越しが起きます。逆に各チャネルに在庫を固定配分すると、片方で在庫が余って機会損失になります。リアルタイムに近い引当と同期ができるOMSであれば、最後の1点まで全チャネルで売り切れ、かつ売り越しもしないという理想に近づけます。

引当のロジックには、優先チャネルの設定、取り置き在庫の確保、予約販売やバックオーダーへの対応など、自社の販売戦略を反映する柔軟さが求められます。たとえば自社ECを優先して在庫を厚く配分する、人気商品はモールに在庫を見せすぎないといった調整を、OMS側で設定できる必要があります。在庫引当は単純な引き算ではなく、販売戦略を実装する機能だと捉えることが重要です。ここの設計が甘いと、在庫はあるのに売れない、あるいは売りすぎるという両方の失敗を招きます。

予約販売や入荷待ちの注文をどう扱うかも、引当機能の重要な評価ポイントです。発売前の商品を予約注文として受け、入荷時に自動で引き当てて出荷する流れを組めれば、機会損失を防ぎつつ販売を前倒しできます。逆にこの機能がないと、入荷待ちの注文を手作業で管理することになり、引き当て漏れや二重引き当てが起きます。通常在庫の引当だけでなく、未来の在庫に対する引当（予約・取り寄せ）まで扱えるかが、引当機能の成熟度を測る指標になります。販売の機会を最大化したい事業者ほど、この点を要件として重視すべきです。

OMSの引当在庫は、WMSが管理する倉庫の実在庫と常に突合される必要があります。OMS上では在庫ありなのに倉庫には実物がない、という不整合が起きると、出荷できない注文を受けてしまいます。入荷・出荷・棚卸のたびにWMSの実在庫をOMSへ反映し、情物一致（情報上の在庫と物理在庫の一致）を保つ機能が欠かせません。OMSとWMSのどちらを在庫のマスタにするかを明確に決め、同期の方向とタイミングを設計することが、機能要件の最重要事項の一つになります。

この突合機能は、OMSとWMSが一体型か、API連携型かで実装が変わります。一体型なら在庫データが一つなので情物一致は保ちやすい反面、自社の倉庫運用に合わせた細かなカスタマイズがしにくい場合があります。別々のシステムをAPI連携する場合は柔軟性が高い一方、同期のタイムラグやエラー処理を丁寧に設計しないと不整合のリスクが残ります。どちらを選ぶにせよ、在庫の整合性を担保する機能はOMS選定の核心であり、要件定義で必ず詰めるべき論点です。

突合の実務では、定期的な棚卸の結果をどうOMSへ反映するかも機能として設計しておく必要があります。倉庫で棚卸を行うと、帳簿上の在庫と実在庫の差異が必ず見つかります。この差異を補正してOMSの引当在庫へ反映する機能がないと、ズレが放置されて売り越しや欠品が再発します。入出庫のリアルタイム同期に加えて、棚卸差異の補正までカバーできるかが、情物一致を継続的に保つ機能の完成度を決めます。在庫の正確さは一度合わせて終わりではなく、運用のなかで保ち続けるものだという視点が、機能評価には欠かせません。

出荷指示・WMS連携と配送管理機能

受注と在庫引当の次に来るのが、出荷指示を出してWMSや3PLへ作業を渡す機能です。OMSは「何を、いくつ、どこへ、どの配送方法で送るか」という出荷指示を生成し、倉庫側のWMSへ連携します。ここでOMSとWMSの責任分界がはっきりします。OMSが出荷指示という「指令」を出し、WMSがピッキング・梱包・出荷という「現場作業」を担う。この受け渡しがスムーズかどうかが、受注から出荷までのリードタイムを決めます。

出荷指示機能の基本は、注文情報を倉庫が作業できる形の指示データに変換することです。配送伝票の発行、送り状番号の取得、同梱物の指定、ギフトラッピングの有無といった情報を、OMSが出荷指示にまとめてWMSへ渡します。複数倉庫や3PLを使う場合は、顧客の住所や在庫の所在地に応じて、どの拠点から出荷するかを自動で振り分ける機能が加わります。これにより配送リードタイムと送料を最適化できます。出荷指示は、受注情報を物流の実行情報へ翻訳する重要な接続点です。

出荷後は、配送状況をOMSに戻して注文ステータスを更新する逆方向の連携も必要です。WMSや配送会社から出荷実績・追跡番号を受け取り、注文を出荷済み・配送中・配送完了へと進める。この双方向の情報の流れがあって初めて、OMSは注文ライフサイクルの全体を管理できます。出荷指示を出して終わりではなく、実績を回収してステータスを閉じるところまでが、出荷連携機能の範囲だと理解しておくことが重要です。

配送方法ごとの送り状発行やラベル印刷の連携も、出荷機能の実務的な要素です。複数の配送会社を使い分ける事業者では、注文ごとに最適な配送会社を選び、それぞれのフォーマットで送り状を発行する必要があります。この連携が自動化されていないと、出荷の現場で配送会社ごとに手作業が発生し、せっかくの自動化が最後の工程で詰まります。受注から出荷指示、送り状発行、配送追跡までが一気通貫でつながって初めて、出荷連携機能は本来の効果を発揮します。出口の細部までカバーできるかを、機能評価で確認することが大切です。

OMSの機能を検討するうえで避けて通れないのが、WMSとの機能の線引きです。OMSは「注文＝情報」を管理し、WMSは「倉庫の中のモノ＝物理」を管理します。ロケーション管理、ピッキングルートの最適化、検品、棚卸といった倉庫内作業はWMSの領域であり、OMSが持つべき機能ではありません。逆に、複数チャネルの受注一元化や販売可能在庫の引当は、WMSではなくOMSの領域です。この線引きを曖昧にしたまま機能を盛り込むと、両システムで機能が重複し、在庫データが二重管理になって不整合を生みます。

実務では、OMSとWMSの間に「どちらが在庫のマスタか」「在庫更新の責任はどちらか」という責任分界点を明確に定めることが不可欠です。さらに自動倉庫やマテハン機器を使う現場では、WMSとWCS（倉庫制御システム）、WES（倉庫実行システム）の役割も絡んできます。OMSはこれらの上流に位置し、受注の司令塔として全体を起動します。機能境界を正しく設計することが、システム間の不整合トラブルを防ぐ最大の鍵であり、要件定義で最優先に詰めるべき論点です。

ECモール・ERP・決済との外部連携機能

OMSは単独では効果を出せず、ECモール・ERP・決済・WMSといった外部システムと連携して初めて受注の司令塔として機能します。連携機能の設計こそ、OMSの費用と効果を大きく左右する要素です。どのモールに標準対応しているか、ERPとどう同期するか、APIの仕様はどうかを見極めることが、OMS選定の実務的な決め手になります。

モール連携は、OMSが各ECモールのAPIを通じて注文・在庫・出荷情報をやり取りする機能です。対応モールが多いほど運用が楽になりますが、連携費用は1モールあたり20〜100万円が相場とされ、対象が増えるほど構築費がかさみます。標準対応していないモールや独自カートとの連携は個別開発になるため、自社が使う販売チャネルにどこまで標準対応しているかを最初に確認することが重要です。連携の作り込みを誤ると、せっかくの一元管理が一部チャネルで分断されてしまいます。

ERP（基幹システム）連携では、受注・売上・請求のデータをOMSから基幹へ流し、受発注から請求・会計までを自動化します。基幹システムとの連携費用は100〜500万円が目安で、二重入力やデータ不整合をなくす効果が投資を正当化します。さらに決済サービスとの連携で与信確認や入金消込を自動化すれば、受注から入金までの一連の流れが途切れずつながります。これらの連携を含めて、OMSは受注情報を全社のシステムへ橋渡しするハブの役割を果たします。連携範囲が広いほど効果は大きい一方、費用も比例して増える点を踏まえて優先順位を付けることが大切です。

機能を網羅的に把握したうえで、最後に大切なのが「必須機能」と「あれば便利な機能」を切り分ける作業です。OMSは機能を盛り込むほど費用が膨らむため、すべてを最初から作ろうとすると予算が破綻します。複数チャネルの受注一元化・在庫引当・出荷指示・WMS連携といった、これがないと受注業務が回らない機能は必須です。一方、高度な需要予測や凝った分析ダッシュボード、顧客分析（CRM寄りの機能）などは、効果を見ながら後から追加できる「あれば便利」に分類できます。

この切り分けは、機能一覧を眺めるだけでは決まりません。自社の受注量・チャネル数・在庫の持ち方・倉庫運用に照らして、「これがないと受注が止まる」機能はどれかを見極める必要があります。だからこそ、機能の検討は要件定義のプロセスと一体で進めるべきです。riplaはフルスクラッチ受託と国内開発の立場から、OMSとWMSの役割分担を踏まえた機能の網羅的な洗い出しと、必須・優先・将来追加の三段階での取捨選択を支援しています。機能要件をどうRFPや要件定義書に落とし込むかは、要件定義の段階で深く検討すべきテーマです。

まとめ

OMSに必要な機能は、受注の一元管理・在庫引当と配分・出荷指示とWMS連携・外部連携の4層で整理すると漏れがありません。とりわけ、複数チャネルの注文取込と名寄せ、リアルタイムな在庫引当による売り越し防止、WMSとの責任分界を踏まえた出荷指示、モール・ERPとのAPI連携という機能こそが、OMSを「受注の司令塔」たらしめる中核です。OMSは「注文＝情報」を、WMSは「倉庫のモノ＝物理」を管理するという役割分担を意識し、機能境界を明確にすることが、システム間の不整合を防ぐ最大の鍵になります。

機能の検討は、一覧を眺めるだけでは完結しません。自社の受注量・チャネル数・在庫の持ち方・倉庫運用に照らして「受注が止まる機能はどれか」を見極め、要件定義へと落とし込むことが不可欠です。riplaはフルスクラッチ受託と国内開発を組み合わせ、OMSとWMSの役割分担を踏まえた機能の洗い出しと、自社の受注フローに合わせた機能設計を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。