EC・通販業向けの在庫連携システム開発は、6段階で進めるのが基本です。最初に要件整理を行い、製品や開発会社を選びます。そのあと設計・開発に進み、テストと稼働を経て、定着へと続きます。各段階で次の工程へ移る条件を決めておくと、在庫差異と確認作業を減らせます。
▼全体ガイドの記事
・EC・通販業向け在庫連携システム開発の完全ガイド
Webサービス開発の工程ごとの進め方と注意点については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
EC・通販業向け在庫連携システムの全体像
在庫連携は、各販売チャネルに表示する在庫数をそろえる作業にとどまらず、受注取込から販売可能在庫の計算、拠点への引当、出荷や返品の結果反映までを支えます。
連携するデータの種類に加えて、どの業務判断を一貫させるかも、先に整理しておきます。主な連携先は、自社ECや楽天市場・Amazonなどのモールといった販売の場と、実店舗、WMS、OMS、基幹システムです。
在庫連携でそろえるデータ
連携対象は、商品・SKUマスタと在庫、受注から出荷までの流れです。配送状況、キャンセル、返品・交換も含みます。マスタでは、SKUコードやJANに加えて、色・サイズのバリエーションとセット商品の構成を共通にします。
- 在庫状態：引当済み、取り置き、検品中、返品待ち、破損、入荷予定に分けて扱う
- 更新方式：API、Webhook、CSV、SFTP、定期バッチの中から選ぶ
- 反映時間：販売可能在庫は数分以内、分析用データは日次などと決めておく
倉庫内の総数だけを連携して状態を分けないと、返品検品中の商品を販売してしまうおそれがあります。実在庫とECの販売可能在庫がずれる原因にもなります。そのため、状態ごとの定義を先に決めておく必要があります。
APIやWebhookは、変化を短い遅延で反映できますが、利用制限や障害時の再送を設計しておく必要があります。CSVやSFTPは、APIのないシステムにも使えます。ただし、更新間隔と重複ファイルの管理が欠かせません。
販売可能在庫とシステムの境界
販売可能在庫の計算式と各システムの役割を書き出しておくと、公開する数と更新の責任を決めやすくなります。
- 公開数の計算：実在庫から引当済み、取り置き、安全在庫などを差し引き、チャネル別のルールを適用する
- 計算例：実在庫100個から出荷確定10個、安全在庫5個、検品待ち3個を除いて、82個を公開する設計例
- システムの役割：在庫連携は同期、OMSは注文と引当、WMSは倉庫作業、ERPは会計・仕入・売上の管理
店舗在庫をECに公開する場合は、販売中の商品を確保できる時間や、在庫を数え直す頻度も考慮します。
実際の業務では機能が重なりやすいため、データごとに正となるシステムと更新権限を文書にまとめます。そのうえで、製品の導入か個別開発かを選びます。
EC・通販業向け在庫連携システム開発の進め方
開発は6段階で進みます。まず要件整理を行ってから、製品や開発会社を選びます。そのあと設計・開発に入り、テストと稼働を経て、定着へ進みます。各段階で、次の工程へ移る条件を決めておきます。
API接続が通るだけでなく、同じSKUで注文から返品までを処理でき、障害から復旧できることを受入条件にします。
フェーズ1：要件整理による業務とデータの正の決定
まず、販売チャネルや店舗、倉庫の数を洗い出し、3PLを使っているかどうかも確認します。SKU数や月間受注数、繁忙期の最大受注数は、数字で押さえておきます。現行業務も、時系列で書き出しておきます。
- 受注取込から在庫引当、在庫減算を経て、出荷指示へ進む
- 出荷完了後に配送番号を反映し、キャンセルや返品を処理する
業務ごとに、担当者、操作する画面やファイル、失敗したときの確認方法を記録しておきます。見落としやすい手作業も、要件として扱います。
要件整理で作るものは、連携先一覧や構成図、データ項目一覧です。ほかにも、在庫状態の定義や引当ルール、例外処理一覧を用意します。非機能要件と移行方針も、この段階で文書にします。
また、「リアルタイム」が30秒か5分か、停止を何分以内に検知するかまで、数値で決めておきます。
受注件数に加えて、同時更新やセール時の集中を確認します。さらに、APIレート制限、個人情報の扱い、ログ保管期間も押さえます。受注や在庫など、データごとに正となるシステムを一つ決めます。
複数のシステムが同じ項目を更新する場合は、更新時刻の新しい値、倉庫側の値、担当者の承認のどれを優先するかを定めます。ここが曖昧なまま選定に進むと、前提の違う見積もりが出て、追加費用を招きます。
フェーズ2：SaaS・パッケージ・個別開発の選定
選定では、運用の標準性と独自要件のどちらに寄せるかで、方式を比べます。各方式について、適合する条件と、どこまでを誰が受け持つかを確認しておきます。
- SaaS・一元管理ASP：標準的な多モール運用で、店舗在庫や複雑な引当が不要な場合
- パッケージ：標準機能を使いつつ、個別設定も組み合わせたい場合
- スクラッチ：独自ロジックや将来の事業モデルに合わせる必要がある場合
- EAI・iPaaS：EC・WMS・基幹間の変換や監視を共通化したい場合
SaaSは短期間で始められ、初期費用も抑えやすい一方、独自の在庫状態や特殊なセット商品、基幹との深い連携が制約になる場合があります。
パッケージは、複数倉庫の引当や店舗受取に関する業務知識を取り込みやすい選択肢です。店舗間移動と返品検品も、業務知識として取り込めます。
スクラッチは既存資産や独自モデルに対応できます。ただし、保守の負担が長く続きます。要件変更や障害対応、セキュリティ更新も、その中に含まれます。
確認は、実データに近いシナリオで行います。SKU名寄せやセット商品の在庫減算、同時注文の二重引当を実演してもらいます。また、予約販売とキャンセル後の在庫戻しも、見せてもらいます。
返品検品の前後の状態変更と、API停止後の再送も確認します。料金は月額だけでなく、初期設定、コネクタ追加、移行まで含めて比べます。
テストや教育、保守の費用に加え、従量課金と契約終了時のデータ返却も、同じ表で比べます。
フェーズ3：データ連携と例外処理の設計・開発
設計では、システム構成や項目変換、連携方向を決めます。処理の順序や再送、重複排除のほか、権限や監査ログも定めます。特に、同じ注文が二重に登録されないよう、仕組みを設けます。
たとえば、受注番号を冪等性キーとして保持します。在庫更新では、イベントの発生時刻と処理時刻を記録し、遅れて届いたデータで新しい在庫が上書きされないようにします。
- 引当条件：出荷拠点、配送費、納期、在庫の鮮度、温度帯を考慮する
- 例外時の運用：手動処理の責任者と対応期限を決めておく
- ファイル連携：ファイル名、文字コード、改行、重複取込、欠損行の扱いを定めておく
- 共通フォーマット：中間層で管理し、連携先追加の影響を抑える
引当ルールは、業務部門が説明できるものから始めます。たとえば、同一拠点優先や欠品時の別倉庫振替、店舗在庫の非公開数などです。複雑な最適化は後回しにし、KPIを見ながら自動化の範囲を広げます。
設計書には、正常系に加えて、タイムアウトや認証切れ、在庫マイナスを記載します。さらに、SKU未登録や配送番号欠落、処理途中の停止も対象に含めます。また、連携先が多い場合は、変換処理を個々のシステムに埋め込まない構成も検討します。
フェーズ4：業務シナリオによるテスト
テストでは、画面表示だけでなく、業務の始点から終点までデータが流れることを確認します。各シナリオには、入力データと期待在庫数、注文状態を設定します。確認者と合否基準も、あらかじめ決めておきます。
- 注文：通常注文、同時注文、在庫ゼロ、予約注文、セット商品
- 出荷：部分出荷、店舗受取、複数倉庫引当
- 変更：キャンセル、返品、交換
- 障害：API停止、CSVの重複取込
在庫差異を検証するときは、開始時に各システムの在庫をそろえてから、注文や出荷、返品を発生させます。処理が終わったら、SKU別・拠点別に数量を突き合わせます。
差異が出たら、計算式、連携順序、丸めを追跡します。キャンセル時の戻し処理や手動補正ログも、あわせて追います。Excelで数字を直して終わらせず、原因と再発防止策を課題管理表に残しておきます。
受入テストは、現場の担当者が実際の時間帯と手順で行います。倉庫の出荷指示や店舗での在庫確保、管理者のエラー判断を確かめます。
在庫不整合、二重引当、注文消失などの重大な問題や、個人情報の誤表示が残る場合は、稼働へ進みません。軽微な表示変更は、回避策と修正期限を合意したうえで解消します。
フェーズ5：段階的な稼働と切替の管理
本番は、全チャネルを一度に切り替えず、1モール、1倉庫、限定SKUなど小さな範囲から始めます。切替の条件と担当は、事前に決めておきます。
- 切替前：棚卸し時刻、既存注文、在庫更新の停止時間を決める
- 担当体制：切替担当者、問い合わせ窓口、切り戻し条件を定める
- 並行稼働：時間帯ごとに正となるシステム
並行稼働の期間でも、二つのシステムから同時に在庫を更新しないようにします。切替当日には、バックアップと在庫スナップショットを取得しておきます。
商品マスタ、在庫、未出荷注文を移行します。移行後は、受注数や在庫更新数、連携遅延を一定間隔で確認します。エラー数と在庫差異も、同じ間隔で見ます。
障害時の連絡先と一次切り分け、再送の方法を、手順書にまとめます。手動出荷や販売停止、顧客案内も、同じ手順書に入れておきます。
フェーズ6：運用の定着と継続的な改善
稼働後1〜3か月を安定化期間とし、日次または週次でKPIを確認します。導入前の値を測っておかないと効果を比べられないため、要件整理の段階で基準値を記録しておきます。
- 在庫品質：在庫差異率、売り越し件数
- 連携状況：エラー件数、復旧時間
- 業務効率：受注から出荷までの時間、手作業時間
- 店舗受取：欠品率
運用責任者は、業務と情報システム、倉庫・店舗、ベンダーの役割を分けます。たとえば、SKU登録は商品部門、定義変更は業務責任者、API障害の復旧はベンダー、販売停止は運用責任者などと明記します。
データの定義と品質、利用目的、責任者を整える考え方は、デジタル庁が2025年6月20日に公開したデータガバナンス・ガイドラインの趣旨とも一致します（出典: デジタル庁「データガバナンス・ガイドライン」、2025年）。
改善はエラー削減から始め、店舗在庫のEC公開や店舗受取、複数倉庫の自動引当へ、さらに需要予測へと広げます。
AIや新しい連携技術は、データの定義と品質、現場が復旧できる状態を整えてから取り入れます。また、投資効果も説明しやすくなります。
EC・通販業向け在庫連携システムの費用相場
費用は既製SaaSの利用料と、個別連携を含む開発費に分けて考えます。金額は、連携先の数やSKU数、受注量で変わります。在庫状態や引当ルール、API有無、移行、テスト範囲も、費用を動かす要素です。
ここで示す金額は、予算を組むための目安で、全国一律の定価ではありません。要件が固まるまでは、幅のあるレンジで比べます。
方式別の初期費用と期間の目安
方式別の予算を比べるときは、初期費用と月額、期間、別料金の条件をそろえます。公開料金と個別費用は、分けて見ます。
- 既製SaaS：初期費用0円から30万円程度、月額3,000円から15万円程度のサービスがあります
- 連携サービス：公開料金に複数の初期費用・月額プランがある
- 個別設定・連携：個別設定や基幹連携の場合、初期100万円から500万円程度
- 複雑なスクラッチ：API連携や複雑なOMS・WMS機能では500万円から3,000万円以上
既製サービスは、標準連携であれば数日から1か月程度で始めやすい方法です。一方で、商品マスタの移行や初期在庫の棚卸し、研修、追加アプリは、別費用になる場合があります。
たとえば、ネクストエンジンの公式料金ページでは、初期費用0円、基本料金は月額3,000円からです。月間受注数に応じた従量課金も示されています（出典: Hamee株式会社「ネクストエンジン料金」、2026年確認）。
同ページの例は、受注200件で月額3,000円、400件で1万円、1,000件で2万8,000円、3,000件で7万8,000円です。
EC特化のデータ変換・連携サービスでは、初期10万円・月額1万円から、初期10万円・月額3万円、月額5万円などの例があります。エンタープライズでは、初期30万円以上、月額15万円以上の例もあります（出典: ECコネクター「料金について」、2026年確認）。
レコード超過や追加コネクタ、カスタマイズは、別料金になり得ます。そのため、月間受注だけでなく、在庫更新数と商品マスタ更新数も確認します。
個別開発費とランニングコスト
個別費用は、連携の複雑さと例外処理によって幅が出ます。類似事例からの推定と、確定した個別見積もりは、区別して扱います。
- パッケージ導入：個別設定や基幹連携を加える場合、初期費用は100万円から500万円程度
- スクラッチ開発：API連携や複雑なOMS・WMS機能を含む場合、500万円から3,000万円以上
パッケージは3か月から8か月程度、スクラッチは6か月から18か月程度になることがあります。
上記は、公開された類似システム連携の費用と期間から整理した推定レンジです。EC在庫連携に限って当てはまる確定相場ではありません。
連携先や例外処理が多いほど、上限側を見込みます。加えて、クラウドやAPI・コネクタ、データ転送の費用もかかります。監視やバックアップ、保守や診断、更新、問い合わせも、運用の費用として見込みます。
3年総額で比べると、月額が安いサービスでも、追加連携や移行費が高くなる場合があります。製品と設定、開発、移行の費用は別々に出してもらい、テストや教育、保守、解約時のデータ返却も含めて、対象外となる作業を明記します。
見積もりを取る際のポイント
見積もりの差は、単価より前提条件から生まれます。そのため、現状と目標を同じ資料にまとめ、複数社に同じ業務シナリオで提案を依頼します。
「ECと倉庫を連携したい」という依頼のままでは、標準機能のみの見積もりと例外処理込みの見積もりが並びます。そうなると、金額を並べても比較になりません。
見積もり前に準備する情報
見積もりの前提をそろえるため、システム構成や規模、在庫ルール、現在の作業を整理します。資料には、次の情報も入れておきます。
- 連携先と規模：EC、モール、POS、WMS、OMS、ERP、配送会社、店舗・倉庫・3PLの数
- 契約とデータ量：契約プラン、API有無、SKU数、平均・繁忙期の受注数
- 在庫と業務：更新頻度、計算式、予約・取り置き・返品・不良品、店舗受取、Excelや電話確認
- 要件：機能、許容遅延、稼働時間、同時処理数、復旧目標、ログ、暗号化
機能要件は、受注取込から出荷指示までの流れを軸に整理します。配送番号、キャンセル、返品の処理も、機能として挙げます。棚卸しや権限、レポートは、別の項目として並べておきます。
非機能要件には、障害検知時間やバックアップ、ログ保管のほか、個人情報の暗号化や脆弱性対応も含めます。「リアルタイム」「高可用性」「セキュリティ対策」といった言葉は、数値や確認方法に置き換えます。
開発会社・サービスを比較する基準
導入実績は、自社に近い業種や、SKU数・チャネル数、店舗・倉庫の構成で確認します。似た課題を解決した事例と、導入前後の測定方法も聞きます。
- 業務適合：在庫差異、店舗受取、複数倉庫、基幹連携、繁忙期の実績
- 作業分担：標準機能と追加開発、移行、テスト、切替、稼働後の窓口
- 運用責任：障害時の再送、手動補正、保守、契約終了時の対応
- 安全管理：診断、権限、操作ログ、委託先、退職者アカウントの管理
判断材料には、導入社数に加えて、似た課題の解決事例を使います。効果の数値が公開されていない場合は、推測で補わず、導入前後の指標と測定方法を尋ねます。
CMMI、ISO 27001、プライバシーマークなどは参考情報です。認証の有無だけでなく、脆弱性診断やアクセス権、操作ログも確認します。さらに、委託先管理と退職者の権限削除も見ておきます。
ECで決済や顧客情報を扱う場合は、周辺システムも確認します。なお、経済産業省は2025年3月、クレジットカード・セキュリティガイドライン6.0版の改訂を公表しました。同ガイドラインは、EC加盟店の脆弱性対策、EMV 3-Dセキュア、不正ログイン対策を示しています（出典: 経済産業省「クレジットカード・セキュリティガイドライン改訂」、2025年）。
在庫連携が決済機能を持たなくても、注文データの経路として、権限とログの保護を見積もりに含めます。
安い見積もりに潜む追加費用の確認
追加費用が発生する条件をRFPに書き、標準範囲と別料金の境界をはっきりさせます。平均値と繁忙期の最大値は、両方を示します。
- 従量条件：追加チャネル、SKU、受注数、API利用量、データ保持量
- 連携対象外：特殊商品、セット品、返品・交換、店舗受取、マスタ名寄せ
- 開発工数：設計、実装、各種テスト、移行、教育、切替、安定化支援
- 契約条件：変更管理、追加開発単価、遅延時の扱い、成果物の帰属
連携エラーやAPI利用量で月額が上がる条件も確認します。「別途見積」となる項目がないか、個別に説明してもらいます。
開発費は、工程ごとの内訳を出してもらいます。要件定義、基本・詳細設計、実装には、それぞれ費用を付けてもらいます。テストは、単体・結合・総合・受入テストの段階ごとに分けてもらいます。移行、教育、切替、安定化支援は、開発作業とは別の費用として示してもらいます。
予備費を一律で上乗せするより、SKU未登録やAPI停止など、各リスクへの対応を確認します。ソースコードや設定情報の帰属も、長期運用を見据えて決めます。
よくある質問（FAQ）
導入前の要件整理では、質問への回答に加えて、対象となるデータと業務も確認しておくと、ベンダーとの認識をそろえられます。
在庫連携システムの開発期間はどのくらいですか？
標準的なSaaSを設定して、1モール・1倉庫から始める場合は、数日から1か月程度が目安です。パッケージに個別設定と基幹連携を加えると、3か月から8か月程度になります。
複数倉庫や店舗受取、独自引当を含むスクラッチ開発では、6か月から18か月程度になる場合があります。期間は、連携先の数だけでなく、マスタ整理や受入テスト、現場教育、切替方式でも変わります。
SaaSとスクラッチ開発はどちらを選ぶべきですか？
標準的な多モール運用を早く始めたいなら、SaaSが合っています。独自の販売可能在庫や複雑な複数倉庫の引当、店舗受取、基幹統合が必要な場合は、個別開発も検討します。
まず1チャネル・1拠点でSaaSや小規模連携を試し、標準機能で足りない部分を確認してから投資を広げる方法もあります。
連携先にAPIがない場合はどうすればよいですか？
CSVやSFTP、定期バッチを使い、ファイルの作成から受取、検証、再送までを仕組みにします。更新間隔や文字コード、必須項目を決めます。重複取込や欠損時の扱い、結果通知も定めます。
手作業で加工する場合は、担当者と承認手順を固定します。将来APIへ切り替える条件も、決めておきます。
在庫連携システムでセキュリティ上の注意点は何ですか？
まず、注文・顧客・配送データの範囲を定めます。そのうえで、最小権限や通信・保存データの保護、操作ログを確認します。バックアップや脆弱性対応、委託先管理も、あわせて見ます。
管理画面の多要素認証や、APIキーの保管、退職者の権限削除が必要です。障害時にログを追える状態も欠かせません。決済周辺に関わる場合は、EC側の対策も含めて、どこまでを誰が受け持つかという責任分界を確認します。
経済産業省のガイドラインを踏まえ、EC側の脆弱性対策や不正ログイン対策も確認します。
まとめ
導入前に決めることと、導入後に測ることを押さえておきます。
機能を比べるだけでなく、業務・データ・運用の3点を一つの計画にまとめることが、成功への近道です。
進め方の要点
連携先を増やすことより、販売可能在庫とデータの正を決め、業務を止めずに運用できる状態をつくることが大切です。
要件整理では、チャネルやSKU、拠点、受注量を明確にします。在庫状態と許容遅延も、ここで決めておきます。選定では、SaaSやパッケージ、EAI、スクラッチを、適合性と3年総額で比べます。
次に行うべきアクション
導入を安定させるには、開発工程に加えて、業務テストと段階稼働、運用後の確認まで計画に入れます。
- 要件整理、選定、設計開発、テスト、稼働、定着の6段階で進める
- 通常・同時注文、キャンセル、返品、店舗受取、複数倉庫、API停止を検証する
- 本番前にエラー検知・再送・手動補正と責任者を決める
- 1チャネル・1拠点で在庫精度と復旧運用を確立し、在庫差異率や売り越し件数を見て拡張する
費用は、標準SaaSの初期0円から30万円程度、月額3,000円から15万円程度の例があります。個別連携は初期100万円から500万円程度、複雑なスクラッチは500万円から3,000万円以上の幅があります。
公開料金、類似連携からの推定、個別見積を区別します。移行やテスト、教育、保守、追加コネクタを含めた総額で判断してください。
事業と現場に合う設計を先に行うことで、在庫連携をデータ同期にとどめず、売り越しと手作業を減らす業務基盤へ育てられます。
▼全体ガイドの記事
・EC・通販業向け在庫連携システム開発の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。