楽天市場・Yahoo!ショッピング・Amazon・自社ECの4チャネルに出店しているが、在庫数が合わない、売り違いが頻発する、深夜まで在庫調整に追われる——複数モール出店の事業者から、こうした悩みを聞く機会が増えています。本記事では、市販の在庫管理SaaSで足りなくなった時に検討するオリジナル在庫連携システムの構成と費用感を、設計の3軸（在庫引当・売上集約・出荷指示）と経営判断の軸で整理します。
この記事の結論（3行）
- 3モール以上 × SKU数3,000超 × 日次注文100件超で市販SaaSの限界が見えてくる
- オリジナル在庫連携は500〜1,200万円帯、設計は「在庫引当・売上集約・出荷指示」の3軸が要
- リアルタイム引当ロジックを自社制御できるかが、売り違い防止と機会損失回避の分岐点
複数モール出店で在庫連携が破綻する3つの構造
複数モール出店は売上拡大の有効手段ですが、在庫管理の難易度は出店チャネル数の2乗で増えていきます。「楽天で売れた在庫をAmazonから引く」「自社ECで予約販売した分を後から各モールに反映する」といった処理が、人手では追いきれなくなります。
- 各モールのAPI仕様が異なり、在庫更新の遅延が3〜30分とバラつく
- 在庫引当のタイミングが「受注時」「決済時」「出荷時」とモールごとに違う
- 売り違い（在庫切れ販売）が起きた時の対応コストが積み重なる
この3つの構造的課題が、市販SaaSでカバーしきれないケースを生んでいます。
モールごとのAPI仕様と引当タイミングの違い
楽天RMS API、Yahoo! API、Amazon SP-APIはそれぞれ仕様が異なり、在庫更新の反映速度も違います。「3分に1回全モール更新」のような運用にすると、更新の谷間で売り違いが起きやすくなります。さらに楽天は受注時引当、Amazonは決済確定時引当、自社ECは予約販売を含めるため受注前引当——と引当ロジックも違い、SaaSはこの細かい違いを吸収しきれません。売り違いが月10件発生すると対応工数は月10時間以上、年間ベースで売上の1〜2%が失われている事業者は少なくありません。在庫連携の現状診断は業務改善・システム見積もりAI適正診断で論点整理から始められます。
オリジナル在庫連携システムの3軸設計
オリジナル開発する在庫連携システムは、3つの軸で設計します。
| 軸 | 機能 | 設計のポイント | |---|---|---| | 在庫引当 | 各モール在庫数のリアルタイム計算と更新 | バッファ在庫率の動的設定 | | 売上集約 | 全モール受注データの統合・正規化 | モール手数料計算、決済吸収 | | 出荷指示 | WMS・物流業者への出荷データ送信 | ピッキング順序最適化 |
この3軸を自社制御できるかどうかが、SaaS継続とオリジナル開発の分かれ目です。
在庫引当ロジックの自社制御
「在庫100個のうち、楽天には70個、Amazonには20個、自社ECには10個を割り当てる」という配分を、売れ筋・利益率・モールごとの送料負担に応じて動的に変更できる設計が理想です。市販SaaSはこの配分ロジックが固定で、自社の販売戦略に合わせた最適化ができません。オリジナル開発なら、季節要因・キャンペーン連動・在庫切れリスクなどを織り込んだ動的配分が組めます。
売上集約・出荷指示の連携
各モールの受注データはフォーマットが異なり、項目名・コード体系・金額計算ルールがバラバラです。これを基幹システム用に正規化する処理を、SaaSの汎用ロジックではなく自社業務に合わせて組めるのがオリジナルの強みです。複数の出荷拠点を持つ場合は受注を最適拠点に振り分け、WMSと直接APIで結べば出荷リードタイムを半日以上短縮できます。
オリジナル在庫連携の費用相場
オリジナル在庫連携システムの費用相場を3レンジで整理します。
| レンジ | 金額 | 規模感 | 想定される対象 | |---|---|---|---| | 小規模 | 500〜700万円 | 5〜7人月 | 2〜3モール、SKU 5,000以下 | | 中規模 | 700〜1,000万円 | 7〜10人月 | 3〜5モール、SKU 5,000〜2万 | | 大規模 | 1,000〜1,200万円 | 10〜14人月 | 5モール以上、SKU 2万超、WMS連携 |
レンジ選定はモール数 × SKU数 × 日次注文数のかけ算で見極めます。小規模レンジ（500〜700万円）は楽天・Amazonの2チャネルでSKU 5,000以下の事業者向け。SaaSの月額10〜20万円が3年で360〜720万円になることを考えると、投資回収は十分見えます。中規模・大規模では複数倉庫対応、安全在庫の動的計算、モール別キャンペーン連動、自社WMS連携などを含み、年商3〜10億円帯のECで業務の中核がECにある事業者に適合します。
経営者目線で考える在庫連携オリジナル化の判断軸
ここからは経営判断の話です。在庫連携のオリジナル化は、SaaS月額10〜20万円から初期投資500〜1,200万円+運用保守年間100〜200万円への切り替えです。3つの軸で見極めてください。第一に、現在の売り違い・機会損失額を年間ベースで試算する。月10件 × 客単価5,000円 × 顧客離反生涯価値損失2万円で年間200〜400万円規模の影響が見えてきます。第二に、在庫管理業務に費やしている人件費を月次で把握する。月50時間 × 時給3,000円で月15万円、年間180万円の業務工数が「在庫調整」に消えている事業者は珍しくありません。第三に、今後3年でモール数・SKU数・注文数がどれだけ増える見込みか。現状の規模で投資回収を計算すると割に合わなく見えても、3年後の規模で計算すると十分回収できるケースが多くあります。事業の成長カーブに合わせた投資判断が、機会損失を避ける鍵です。
仮想B社の実例：年商5億円ECの在庫連携オリジナル化
仮想B社（雑貨EC、年商5億円、楽天・Yahoo!・Amazon・自社ECの4チャネル出店、SKU 1万）の事例で整理します。同社では市販在庫管理SaaSを月額18万円で利用していましたが、Amazon FBAと楽天倉庫の在庫を別々に管理する制限、予約販売・受注生産品の在庫ロジックがSaaS想定外でExcel併用、売り違いが月15件発生し対応工数が月20時間超、という3つの問題が顕在化していました。
B社の判断は「中規模レンジ」のオリジナル開発でした。開発費850万円、期間9ヶ月、Next.js + Supabase + 各モールAPI連携の構成。在庫引当の動的配分ロジックを自社開発し、Amazon FBA倉庫と楽天倉庫を統合した拠点最適化を実装、予約販売の在庫先取りロジックを組み込みました。リリース後3ヶ月の効果は、売り違いが月15件 → 月2件、在庫管理業務工数が月60時間 → 月20時間、配送リードタイムが平均1.3日 → 0.8日。SaaS月額18万円の削減と合わせて年間500万円規模の効果が出ています。同様の試算を自社の数字で診断することで、判断材料が具体化します。
オリジナル在庫連携を成功させる5つの実践
実践項目は5つです。現状の売り違い件数とコストを3ヶ月分計測、各モールAPIの仕様変更頻度を把握、並行運用期間（3〜6ヶ月）の予算を確保、障害時の手動運用フローを準備、WMS・基幹連携は最初から設計に含める。在庫連携だけ作って後でWMS連携を追加する設計だと、後付けで設計やり直しになりがちなので、最初から基本設計に含めてください。複数ベンダーの提案を比較を依頼する場合も、連携範囲を統一しておくと比較しやすくなります。
まとめ
オリジナル在庫連携システムは、3モール以上・SKU 3,000超・日次注文100件超で市販SaaSの限界を補う選択肢です。費用相場は小規模500〜700万円、中規模700〜1,000万円、大規模1,000〜1,200万円で、設計は在庫引当・売上集約・出荷指示の3軸で組み立てます。経営判断のポイントは、売り違い・機会損失額の試算、在庫管理人件費の把握、3年後の事業規模見込みの3点です。仮想B社の例のように、現状の数値を計測してから投資判断に進めば、回収期間2〜3年の現実的な投資計画が組めます。在庫連携の現状と将来見込みを項目別に整理してから判断する流れをお勧めします。