EC運営の受注・在庫・出荷を連携させるバックオフィスの設計

EC運営の受注・在庫・出荷を連携させるうえで最初に決めるべきなのは、ツールの選定ではなく「どのデータをどのシステムが正として持つか」と「いつ、どの方向に同期するか」です。受注は各モールや自社ECで発生しますが、在庫の正しい数は一か所でしか管理できません。この「正」の置き場所を決めずにつなぎ始めると、在庫数が食い違い、売り越しや二重出荷が起きます。

この記事は、楽天市場・Amazon・Yahoo!ショッピングなど複数のモールと自社ECを並行して運営しており、受注の取り込みや在庫の更新、出荷連絡を手作業やCSVの手渡しで回している事業者の方に向けて書いています。受注一元化の考え方、在庫引当と出荷指示の流れ、連携方式の選び方、段階的に自動化する手順、よくある失敗とその避け方まで、バックオフィス設計の全体像が分かるようにまとめました。

結論を先に言えば、最初から全部を自動化しようとせず、「受注の取り込み」「在庫の一元化」「出荷実績の戻し」の順に、データの流れを一本ずつ確定させていくのが現実的です。

EC受注管理の連携が必要になる典型的な状況

販売チャネルが一つのうちは、ECカートの管理画面だけで受注から出荷まで回せます。連携の必要性が高まるのは、次のような状況が重なったときです。

• 販売チャネルが複数になり、各管理画面を開いて受注を確認する作業が毎朝発生している
• 同じ商品を複数のモールで売っており、在庫数を手で調整している
• 倉庫や物流代行会社に出荷指示をCSVで送り、送り状番号を手で各モールに戻している
• セール時に受注が集中すると、在庫更新が追いつかず売り越しが発生する
• 担当者が休むと受注処理が止まる、または処理手順が人によって違う

こうした状態では、作業時間そのものより「ミスが起きたときに原因を追えない」ことが問題になります。どの時点の在庫数でどの注文を受けたのか、どのCSVをいつ送ったのかが記録に残っていないためです。連携の目的は手作業を減らすことに加えて、受注から出荷までの事実を一つの流れとして追えるようにすることにあります。

架空の例：3チャネル運営の雑貨ショップ

たとえば、自社EC・楽天市場・Amazonで生活雑貨を販売している小規模な事業者を想定します。受注は各管理画面からCSVで落とし、表計算ソフトで結合して倉庫に送っています。在庫は倉庫から毎晩届く在庫表を見て、各モールの在庫数を手入力で更新しています。日中に売れた分は翌日まで反映されないため、人気商品はセールのたびに数件の売り越しが出て、お詫びとキャンセル対応に追われています。この事業者にとっての課題は、在庫の「正」が倉庫の在庫表にしかなく、しかも一日一回しか更新されないことです。

受注・在庫・出荷のデータの流れを整理する

設計に入る前に、データの流れを紙に書き出します。EC運営のバックオフィスでは、おおむね次の四つの情報が行き来します。

1. 受注情報：注文番号、注文日時、商品、数量、金額、配送先、支払い方法、チャネル
2. 在庫情報：商品（SKU）ごとの実在庫数、引当済み数、販売可能数、保管場所
3. 出荷指示：どの注文をどの倉庫からいつ出すか、梱包・同梱物の指定
4. 出荷実績：出荷日、配送会社、送り状番号、欠品や分割出荷の有無

このうち、受注情報は各チャネルで発生し、出荷実績は倉庫で発生します。在庫情報は倉庫の実数と、受注による引当の両方から変化します。それぞれについて「発生源」「正として保持する場所」「誰が参照するか」を表にすると、どこをつなぐべきかが見えてきます。

ポイントは、在庫の正を一か所に決めることです。倉庫管理システムの実在庫を正にする場合もあれば、受注管理システム側で「実在庫から引当済みを引いた販売可能数」を正にする場合もあります。どちらにしても、各モールの在庫数は「正から配る写し」と位置づけ、モール側で直接在庫数を編集しない運用にそろえます。

受注管理の役割を担う仕組みは一般にOMS（受注管理システム）、倉庫内の入出庫やロケーションを管理する仕組みはWMS（倉庫管理システム）と呼ばれます。自社の規模によっては、両者を一つのシステムで兼ねることもあります。

受注一元管理の設計で決めること

受注を一か所に集めるとき、単に注文データを取り込むだけでは足りません。後工程で困らないよう、次の点を設計段階で決めておきます。

取り込みのタイミングと方式

各チャネルから受注を取り込む方法は、APIで定期的に取得する、Webhookなどで通知を受ける、CSVを取り込むのいずれかです。モールによって提供される手段が異なるため、チャネルごとに方式が混在するのは普通です。重要なのは取り込み間隔の考え方で、在庫引当まで含めて何分以内に反映されれば売り越しが許容範囲に収まるかから逆算します。

注文データの正規化

モールごとに項目名や形式が違うため、取り込み時に共通の形に変換します。商品はモール側の商品番号ではなく自社のSKUに紐づけ、配送先の住所や電話番号の形式もそろえます。モールの商品番号と自社SKUの対応表は、連携の中で最も壊れやすい部分です。商品を追加したのに対応表を更新し忘れると、その注文だけが取り込みエラーになります。対応表の更新を誰がいつ行うかまで運用として決めておきます。

ステータスの定義

受注には「新規」「確認待ち」「引当済み」「出荷指示済み」「出荷済み」「キャンセル」などの状態があります。チャネルごとに状態の呼び方が違うため、自社の共通ステータスを定義し、各チャネルの状態との対応を決めます。保留が必要な注文（住所不備、支払い確認待ち、ギフト指定など）をどのステータスで止めるかも、この段階で決めておくと現場の混乱が減ります。

在庫連携の設計：引当と販売可能数の考え方

在庫連携で最も多いトラブルは売り越しです。これを防ぐには、在庫を「実在庫」「引当済み」「販売可能数」に分けて扱います。

• 実在庫：倉庫に物理的にある数
• 引当済み：受注を受けたが、まだ出荷していない数
• 販売可能数：実在庫から引当済みと安全在庫を引いた数

各モールに配るのは販売可能数です。受注を取り込んだ時点で引当を行い、販売可能数を減らして各チャネルに反映します。出荷が完了したら実在庫と引当済みの両方を減らします。この流れを守れば、出荷前の注文分が二重に売られることはありません。

安全在庫とチャネル配分

取り込み間隔があるかぎり、同時に複数チャネルで売れるタイミングのずれは避けられません。そこで、販売可能数から少し余裕を引いて各チャネルに配る「安全在庫」を設けます。人気商品やセール対象商品は余裕を大きく、動きの少ない商品は小さくするなど、商品ごとに設定できるようにしておきます。チャネルごとに在庫の割り当てを分ける方法もありますが、売れ残りが偏りやすいため、まずは共通在庫から配る形で始め、必要な商品だけ配分する方が扱いやすいです。

複数の倉庫を使う場合や、実店舗と在庫を共有する場合の設計は、複数倉庫・複数チャネルの在庫を一元管理するシステムの設計で詳しく扱っています。

出荷連携の設計：指示と実績の往復

出荷連携は、出荷指示を倉庫に送る流れと、出荷実績を受け取って各モールに戻す流れの往復です。

出荷指示で決めておくこと

出荷指示は、引当済みの注文をまとめて倉庫に渡すものです。決めておくべきなのは、締め時刻（何時までの注文を当日出荷にするか）、まとめ方（同一顧客の複数注文を同梱するか）、分割出荷の扱い（一部欠品時に先に出すか待つか）、同梱物（チラシ、納品書、ギフトカード）です。物流代行会社を使う場合は、相手のシステムが受け付ける形式や送信方法に合わせる必要があるため、早い段階で仕様を確認します。

出荷実績の戻し

倉庫から送り状番号と出荷日が返ってきたら、受注管理システムでステータスを「出荷済み」に更新し、各モールに出荷通知を送ります。モールによっては一定期間内に出荷通知を登録しないと評価に影響することがあるため、この戻しの自動化は優先度が高い部分です。顧客への出荷完了メールも、この実績をきっかけに送るように設計します。

会計・顧客対応へのつなぎ

出荷実績が確定したデータは、売上計上や入金消し込み、問い合わせ対応にも使われます。売上をどの時点で計上するか（受注時か出荷時か）は会計方針によって異なるため、経理担当や税理士と確認したうえで、受注管理システムから会計側へ渡すデータの単位と締めのタイミングを決めます。顧客対応の担当者が「この注文はいまどこにあるか」をすぐに答えられるよう、受注番号から出荷状況と送り状番号までを一画面で確認できるようにしておくと、問い合わせのたびに倉庫へ確認する手間がなくなります。

連携方式の比較と選び方

受注・在庫・出荷をつなぐ方法は、大きく三つに分かれます。

判断の軸は、「自社の業務が一般的な受注処理の型に収まるか」と「モールの仕様変更に追随する体制を持てるか」の二つです。多くの事業者にとっては、既製の一元管理サービスを軸にし、足りない部分だけを個別に作る組み合わせが現実的です。セット商品の在庫を構成品から自動で計算する、取引先ごとの出荷ルールを持つ、といった独自要件が中心にある場合に、個別開発の比重が上がります。

ECサイト本体の構築方法の比較については、ECサイトの構築方法：ASP・Shopify・パッケージ・スクラッチの比較も参考にしてください。

段階的にバックオフィスを連携させる手順

一度にすべてをつなぐと、どこで不具合が起きたのか切り分けられなくなります。次の順番で一本ずつ確定させていく進め方をおすすめします。

1. 現状の作業とデータの流れを書き出す：誰が、いつ、どの画面やファイルを使って、何を転記しているかを洗い出します。CSVのファイル名や列まで記録しておくと、後の設計がぶれません。
2. 在庫の正と商品マスタを決める：自社SKUの体系を整え、各モールの商品番号との対応表を作ります。セット品や色・サイズ違いの扱いもここで決めます。
3. 受注の取り込みを一元化する：まずは取り込みだけを自動化し、処理は従来どおり人が行います。取り込み漏れや重複がないことを一定期間確認します。
4. 在庫の引当と配信を自動化する：受注の取り込みに合わせて引当を行い、販売可能数を各モールに反映します。最初は在庫数を目視で突き合わせる期間を設けます。
5. 出荷指示と実績の戻しを自動化する：倉庫への指示データ作成と、送り状番号の各モールへの登録を自動化します。
6. 例外処理の手順を整える：キャンセル、返品、住所変更、欠品、分割出荷など、自動処理から外れるケースの扱いを決め、担当者が対応できる画面と手順を用意します。
7. 監視と振り返りの仕組みを作る：連携エラーの通知先、在庫差異の定期チェック、月次の振り返りを運用に組み込みます。

手順3から5のそれぞれで、「旧手順と新手順を並行して結果を比べる期間」を数日から数週間とると、本番切り替え後の事故を減らせます。

例外処理を設計から外さない

自動化の効果を左右するのは、例外の扱いです。たとえば、出荷指示を送ったあとにキャンセルが入った場合、倉庫側で出荷を止められるのか、止められなかった場合は返品として扱うのかを決めておかないと、毎回担当者が倉庫に電話で確認することになります。例外はゼロにはできないため、「自動で止まって人に知らせる」仕組みにしておくのが基本です。業務自動化で残る例外の扱い方は、EC運営業務の自動化：受注処理・在庫更新・出荷連絡の効率化でも触れています。

よくある失敗とその避け方

EC受注管理の連携では、似た失敗が繰り返し起きます。代表的なものと対策をまとめます。

• モール側で在庫数を直接編集してしまう：担当者がセール準備のために管理画面で在庫を変更すると、次の同期で上書きされるか、逆に正のデータとずれます。在庫数の変更は一元管理側でのみ行うルールを決め、モール側の権限も見直します。
• 商品マスタの対応表が更新されない：新商品やバリエーション追加のたびに対応表の更新が必要です。商品登録の手順に組み込み、未対応の商品が取り込まれたら通知が届くようにします。
• 同期エラーに誰も気づかない：APIの一時的な障害や認証期限切れで連携が止まっても、画面上は普段どおりに見えます。エラー時の通知先を決め、最後に同期が成功した時刻を見える場所に表示します。障害時の再送やデータ不整合への備えはAPI連携の障害対策：リトライ設計とデータ不整合への備え方で詳しく扱っています。
• 返品・交換の在庫戻しが漏れる：返品された商品を検品後に販売可能在庫へ戻す流れが手作業のままだと、在庫が実数より少なくなり、売り逃しにつながります。返品の受付から検品、在庫戻しまでをステータスで管理します。
• 繁忙期に初めて負荷がかかる：普段は問題なくても、セールで受注が急増すると取り込みや配信が追いつかないことがあります。切り替え前に、繁忙期を想定した件数で処理時間を確認しておきます。

連携を設計する前のチェックリスト

開発会社や既製サービスの比較に入る前に、社内で次の項目が答えられるかを確認してください。答えられない項目が多いほど、設計の前に整理が必要です。

• 販売チャネルと、それぞれの受注件数の目安（平常時とセール時）を把握している
• 自社SKUの体系が決まっており、各チャネルの商品番号との対応が整理されている
• 在庫の正をどのシステムで持つかが決まっている
• 当日出荷の締め時刻、同梱・分割出荷のルールが明文化されている
• キャンセル、返品、住所変更、欠品時の対応手順がある
• 倉庫や物流代行会社が受け付けるデータ形式と送受信方法を確認している
• 連携エラー時に誰が対応するか、営業時間外の扱いを決めている
• 会計や顧客管理など、受注データを使う他の業務を洗い出している

よくある質問

Q. 既製の一元管理サービスを入れれば、個別開発は不要ですか？

多くの場合、基本的な受注取り込み、在庫配信、出荷通知は既製サービスで足ります。個別開発が必要になるのは、セット品の在庫計算、取引先ごとの出荷ルール、独自の基幹システムとの接続など、標準機能の外にある要件が業務の中心にある場合です。まず既製サービスで回るか試し、残った差分を見てから判断する方が無駄がありません。

Q. 在庫の同期はリアルタイムでないといけませんか？

必ずしも即時である必要はありません。受注件数と商品ごとの在庫の厚みによって、許容できる遅れは変わります。在庫が少なく動きの速い商品ほど同期間隔の影響を受けやすいため、安全在庫の設定と組み合わせて考えます。数分単位の同期と安全在庫で十分に売り越しを防げる事業者は少なくありません。

Q. 倉庫や物流代行会社を変える予定がある場合は？

出荷指示と実績の戻しは、倉庫ごとにデータ形式が異なる部分です。連携の設計では、受注管理側の共通データと、倉庫ごとの変換部分を分けておくと、倉庫を変えたときの改修範囲を小さくできます。変更の予定が決まっているなら、切り替え時期に合わせて連携の作り直しを計画します。

Q. どこから手を付けるのが効果的ですか？

売り越しやキャンセルが頻発しているなら在庫の一元化から、受注処理の作業時間が重いなら受注取り込みの自動化から始めるのが一般的です。どちらの場合も、先に商品マスタと在庫の正を整えておくことが前提になります。

Otsumuに相談できること

チャネルが二つ程度で、主要モールと一般的な出荷フローの組み合わせであれば、既製の一元管理サービスを導入し、社内で設定と運用ルールを整えるだけで十分に回るケースが多くあります。商品マスタの整理や締め時刻の決定など、この記事のチェックリストを社内で埋められるなら、まずは自社で進めてみてください。

一方で、セット品や取引先別の出荷ルールなど既製サービスの標準に収まらない要件がある、基幹システムや会計との接続が必要、連携エラーの原因が追えず手作業に戻ってしまった、という状況では、データの流れの設計から外部の手を借りた方が早く安定します。どこまでを既製サービスに任せ、どこを作るかの線引きは、業務とシステムの両方を見ないと判断しにくいためです。

Otsumuでは、現状の受注・在庫・出荷の流れを一緒に整理し、既製サービスで足りる部分と個別に作るべき部分を切り分けたうえで、必要な連携だけを開発します。自社でも事業を運営している立場から、作業時間の削減だけでなく、例外処理や運用のしやすさまで含めて設計します。EC関連の開発の範囲はEC・通販システム開発のページにまとめています。費用は範囲に応じて個別にお見積もりします。

「どこから手を付けるべきか分からない」という段階でも構いません。現状の作業の流れをお聞きし、優先順位の付け方を一緒に考えます。30分の無料相談からお気軽にご連絡ください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01