在庫連携システム開発の進め方/やり方/流れや方法/手法/工程/手順

在庫連携システム開発は、要件整理から定着までの六つのフェーズを順に進めるのが基本です。

Amazonや楽天、自社ECの在庫が、実店舗や倉庫、販売管理システムと一致せず、売り越しや二重入力に悩む企業は少なくありません。在庫数のずれを防ぐには、連携する業務イベントを先に決める必要があります。

• 在庫の正：どのシステムを在庫の正とするかを決める
• 数量を変える時点：受注・引当・出荷・返品・棚卸しのどこで在庫数を更新するかを定義する
• 再送と重複防止：連携失敗時の再送と重複防止を設計する

▼全体ガイドの記事
・在庫連携システム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

在庫連携システムの全体像

在庫連携システムとは、複数の販売チャネルや倉庫、基幹システムに分散した商品・在庫情報を、共通のルールで受け渡す仕組みです。

在庫連携では、どのシステムを在庫の正とするか、受注・引当・出荷・返品・棚卸しのどの時点で数量を変えるかまで、あわせて設計します。

在庫の正と在庫区分の決め方

複数のシステムが在庫数を書き換える状態では、連携を増やすほど数量差異の原因が見えにくくなります。そのため、在庫管理システムやWMS、OMS、ERPのうち、どこを在庫の正とするかを最初に決めます。

そのうえで、物理在庫、販売可能在庫、引当済み在庫を分けます。さらに、不良在庫、輸送中在庫、棚卸し中在庫も区分に加えます。たとえば、ECに表示する数量を「物理在庫」から返品予定分まで差し引いた「販売可能在庫」と定義すれば、表示値の根拠を現場とEC担当者で共有できます。

設計書には、受注を取り込んだ時点、引当が確定した時点、出荷を確定した時点、返品を検品した時点で、どの区分を何個増減させるかを書きます。例外のうち、キャンセル、分納、欠品の扱いは、特に先に決めておく必要があります。ほかにも、在庫の数え方が通常と異なる商品は、扱いを個別に決めておきます。

• セット商品：セットの在庫数を、構成品からどう数えるかを決める
• 予約商品：予約分を販売可能な在庫数にどう含めるかを決める
• ロット・賞味期限品：ロットや期限ごとに在庫を分けて扱うかを決める

ここが曖昧なまま開発を始めると、「在庫は合っているのにECの表示が違う」という運用事故につながります。

連携対象は商品マスタからエラー復旧まで含む範囲

連携対象は、在庫数のほかに商品コードやSKU、JAN・GTIN、色・サイズなどのマスタも含みます。倉庫、ロケーション、取引先のマスタも先にそろえ、受注から出庫まで、出荷実績から在庫調整までのデータフローを整理します。

連携方式は、API、Webhook、CSV、SFTP、EDIのどれにするかを、相手側の仕様や送信上限、障害時の再送方法まで含めて判断します。ただし、「API連携対応」と書かれていても、受注取込だけなのか、在庫送信や返品まで双方向に連携できるのかは、表示からは読み取れません。「リアルタイム」という言葉にも注意が必要です。

LOGILESSの公式説明では、倉庫での作業を在庫数へ反映し、各モール・カートへ在庫を送信する一方、モールやカートへの在庫反映は10〜20分に1度とされています（出典: 株式会社ロジレス「在庫連携機能」、2026年確認）。したがって、要件書には「即時」とだけ書かず、許容遅延、ピーク時の処理量、連携停止時の表示、再送完了までの目標時間を数値で記載します。

在庫連携システムの進め方

在庫連携システムは、(1)要件整理、(2)製品・開発会社の選定、(3)設計・開発、(4)テスト、(5)稼働、(6)定着の順で進めます。

SaaSを導入する場合も、商品マスタの整理や連携マップの作成、テスト、現場教育は欠かせません。そのため、契約しただけでは終わらないと考えておくことが大切です。

フェーズ1：要件整理による現状把握

最初に、販売チャネル、倉庫・店舗、基幹システム、現在の在庫台帳を一覧にし、受注件数、SKU数、拠点数、棚卸し頻度も書き添えます。Excelや電話で行っている作業も省略せず、誰が、いつ、どの画面やファイルを使い、どの判断をしているかを記録します。

特に、通常処理よりもキャンセル、分納、返品、欠品、セット品、店舗間移動などの例外処理に時間がかかっている場合は、要件の中心に置きます。要件整理の完了は、主要な業務イベントを一巡させたときに、どのシステムにどの値が残るかを説明できる状態です。

システム名だけの連携図では不十分なため、連携マップを作ります。商品コード、数量、在庫区分、更新日時、送受信方向を1行ずつ書き、さらに連携頻度、エラー時の責任者、再送方法も記載します。

フェーズ2：選定と標準機能・個別開発の境界

選択肢は、SaaS、パッケージ拡張、連携基盤の導入、受託開発、スクラッチ開発の5つで、標準機能と個別開発のどちらにどれだけ寄せるかが異なります。

• SaaS：導入が早く初期費用を抑えやすい一方、業務を標準機能へ合わせる必要があります。
• パッケージ拡張：標準機能と拡張性のバランスを取りやすいです。
• スクラッチ開発：特殊な在庫単位や既存基幹との複雑な連携に対応しやすいものの、設計・保守・将来の改修を自社が長く負担します。

選定時のデモは、正常な在庫減算だけで判断せず、異常系も含めて実データで確かめます。商品コードの紐づけや複数倉庫の引当、在庫割当率、API停止を確認します。CSVの重複、返品、棚卸し差異、再送、監査ログも対象に含めます。

候補会社には、同業・同じ在庫単位の実績、移行支援の範囲、API仕様書の開示、ソースコードや設計書の扱い、保守会社を変えるときの引き継ぎ条件まで質問します。導入事例は、効果の数字だけでなく、どのシステム同士をつなぎ、どの業務イベントを変えたかを読み取り、自社と似た構成で運用まで説明できるものを優先します。

ロジザードの2025年2月の発表では、SODAが倉庫向けWMSと店舗向け在庫管理システムを連携し、倉庫・店舗間の商品移動や在庫照会を円滑にした事例が紹介されています（出典: ロジザード株式会社「店舗とECの在庫を一元管理」、2025年）。

フェーズ3：連携失敗を前提にした設計・開発

設計では、商品・在庫・受注・出荷のデータモデルと画面、権限を決め、API、CSV変換、バッチ、キュー、ログ、通知の仕組みも定めます。開発会社に依頼する場合は、要件定義書に加えて、項目定義書、連携マップ、エラーコード一覧、テスト仕様書、移行手順書、運用手順書の納品条件を契約へ入れます。

大量のSKUや基幹連携では、即時処理と一括処理を分け、差分同期と日次の全件照合を併用します。さらに、同じデータを再送しても数量が二重に減らない冪等性、途中で失敗しても再開できる仕組み、連携先が一時停止しても注文を失わないキューを設計に含めます。

AI需要予測や自動補充を追加する場合も、先にSKU表記揺れ、欠損、返品データの扱いを整えます。データ品質が低いままAI機能を足しても、予測結果の説明や現場の信頼を得にくいためです。

フェーズ4・5：小さく試すテストと切り戻し条件

テストでは、画面の表示確認だけでなく、1倉庫、主要チャネル、代表的なSKUで入荷、入庫、受注、引当、出荷を一巡させます。キャンセル、返品、棚卸し、在庫調整も、この範囲で確かめます。

そのうえで、複数倉庫、セット品、ロット・期限、同時注文を加え、API停止、数量不一致、同一データの再送も試します。合格基準には、許容遅延、在庫差異ゼロの条件、エラー通知時間、再送完了時間、担当者の操作時間を記載します。

本番移行では、マスタ凍結日、初期在庫を確定する方法、在庫を止める時間、旧システムとの並行稼働期間、切り戻し条件を決めます。たとえば、切替当日の出荷を旧システムで処理するのか新システムで処理するのかを曖昧にすると、同じ出荷が二重計上されます。切り戻しは「不具合があれば戻す」ではなく、在庫差異が何件発生した場合、何分以上連携が停止した場合など、観測できる条件にします。

フェーズ6：KPIと例外対応の現場定着

稼働後は、在庫差異率、売り越し件数、欠品率、在庫確認にかかる時間を月次で確認します。加えて、棚卸し工数、出荷リードタイム、連携エラーの復旧時間も見ます。エラーは件数を減らすだけでなく、SKU未紐づけ、数量不一致、認証切れ、API制限、現場の手入力など、原因別に分類します。

1か月目は毎日、運用が落ち着いた後は週次や月次で責任者が確認し、改善の優先順位を決めます。現場教育では、通常操作よりも、エラーが出たときに何をしてはいけないかを伝えます。たとえば、同じ注文を手動登録する前にキューと受注番号を確認し、在庫を直接上書きする前に棚卸し差異の理由を記録する、といった手順を決めます。

担当者が変わっても運用できるよう、画面キャプチャ付きの手順書、問い合わせ窓口、月次の改善会議を用意します。

費用相場とコストの内訳

在庫連携システムの費用は、SKU数、チャネル数、拠点数、APIの有無、既存基幹との接続で大きく変わります。さらに、ロット・期限・セット品の扱い、移行データの汚れ、現場端末の台数も影響します。ここから示す金額は、いずれも税別の目安です。

公開料金と、類似する在庫・物流システム開発の相場は分けて考え、いずれも自社の連携範囲に合わせて見積もることが前提です。

SaaS・クラウド導入の月額と初期支援

小規模なEC在庫連携は、初期費用0〜数十万円、月額3,000円〜5万円程度が入口になりやすいです。ただし、受注従量課金や外部アプリ、追加拠点が別になる場合があります。初期設定や商品コード変換、端末費用も別になることがあります。

例えばHameeのネクストエンジン公式料金ページでは、初期費用0円、月額3,000円からで、受注件数に応じて1件35円から5円の従量課金、契約1年経過後の年間保守15,000円が示されています。出典はHamee株式会社「料金」（2026年8月確認）です。

ロジクラの公式案内では、Premiumが年契約で月額4万円、月契約で月額4万9,000円とされ、ロット管理やロケーション管理、拠点間入出荷などを含みます（出典: 株式会社ロジクラ「料金プラン」、2026年8月確認）。月額だけでは比べられないため、料金を左右する条件を別に確認します。

• 拠点数：追加拠点ごとに料金が増えるかを確認する
• 出荷件数：件数に応じて料金が変わるかを確認する
• 連携先：外部アプリや連携先が増えたときの費用を確認する
• 初期サポート：回数と、マスタ整備や初期設定の支援範囲を確認する

クラウド製品をベースにマスタ整備やAPI・CSV接続を外注する場合、初期導入支援は50万〜300万円程度を予算枠に置くと比較しやすいです。

パッケージ拡張・受託開発の費用目安

小規模な在庫・物流システムや連携部分の開発は200万〜500万円、中規模で複数倉庫・WMS・端末連携を含む場合は500万〜1,500万円、大規模で複雑なものは1,500万〜5,000万円以上が一つの目安です。これは在庫連携専用の公的統計ではなく、2025〜2026年に公開されている在庫管理・物流システム開発の相場を、本テーマに当てはめた推定レンジです。

基幹刷新やフルスクラッチまで含める場合は、5,000万〜3億円以上、期間1〜3年規模になることもあります。費用内訳は、要件定義・企画10〜15%、設計25〜35%、実装・テスト45〜60%、移行・教育5〜10%程度を目安に確認します。

年間保守は初期開発費の10〜20%程度が相場の目安で、監視、障害対応、OSやAPIの変更、小改修のどこまで含むかで変動します。例えば開発費1,000万円なら年100万〜200万円程度を保守枠として見る考え方ですが、契約内容に基づく試算であり、特定金額を保証するものではありません。

3年間の総保有コストによる比較

比較表では、初期開発費や初期設定費に加え、月額・従量課金、外部アプリ、API利用料を3年間で合算します。さらに、追加拠点、ハンディ端末、バーコード機器、データ移行の費用も含めます。月額が安い製品でも、従量課金や個別見積もり、サポート範囲によって総額が逆転することがあります。

教育、保守、監視、バックアップ、改修費も、合算の対象に入れます。また、金額だけでなく、売り越し件数、在庫確認時間、棚卸し工数、手入力の人数を現状と導入後で比べます。費用対効果は、「削減できる人件費」だけでなく、欠品による機会損失、誤出荷、緊急出荷、顧客対応の削減も含めて考えます。

AI需要予測などの将来機能は、最初から全額を投じず、データ品質を整えた後に追加できる構成にすると、初期投資の膨張を抑えられます。

見積もりを取る際のポイント

よい見積もりは、合計金額だけでなく、どの業務とデータを、どの方法で、誰が、いつまでに実現するかを説明します。そのため、相見積もりを取る前に、対象範囲と評価基準をそろえておきます。

前提条件が会社ごとに違うまま価格だけを比べると、安く見えた見積もりに、移行・テスト・教育が含まれていないことがあります。

要件書に書くデータ項目と例外処理

RFPや要件メモには、チャネル、拠点、SKU数、月間受注件数、ピーク時件数を記載します。さらに、在庫区分、連携方向、連携頻度、許容遅延、保持期間も書き込みます。

例外処理は、セット商品の構成変更や予約、欠品、キャンセルを例として添えます。分納、返品、棚卸し差異、店舗間移動も、同じように添えます。APIがない相手には、CSVやSFTPを使うのか、ファイルの作成者と承認者は誰か、取込失敗時に何を通知するかも書きます。

確認したいのは、在庫の正が一つに決まっているか、販売可能在庫の計算式があるか、商品コード変換表の責任者がいるかです。さらに、同期遅延の許容値があるか、重複取込を防げるか、エラーを再送できるかを見ます。加えて、全件照合ができるか、監査ログを誰が見られるか、切り戻し条件があるか、現場教育と保守窓口が見積に含まれるかも確かめます。

会社比較での実績と提案の具体性

開発会社やベンダーを比べるときは、企業規模や知名度だけで決めず、EC中心、店舗・オムニチャネル中心、製造・部品中心、3PL中心といった業態の違いを見ます。業態によって、必要な在庫単位も現場端末も異なるためです。

同じ業態や近いSKU数、同じ連携方式の事例を確認し、導入前の課題、採用した構成、移行方法、稼働後の運用まで説明できる会社を候補にします。また、過剰なカスタマイズで当初2,000万円だった計画が4,200万円に膨らんだ失敗例もあり、標準機能と業務変更の境界を先に決める重要性を示しています。

提案書では、標準機能で対応する部分、設定で対応する部分、追加開発する部分、運用で吸収する部分を色分けしてもらいます。デモでは、実データに近いSKUと異常系を使い、説明の分かりやすさや質問への対応姿勢も評価します。

見積もりに含めるリスクとセキュリティ

在庫連携は、商品情報や取引情報を複数のサービスへ渡すため、障害だけでなく、権限設定、認証情報、バックアップ、委託先管理も確認します。連携先が増えるほど、契約終了時のデータ返却や認証情報の廃棄も要件に含めます。

IPAは2026年3月公開の「中小企業の情報セキュリティ対策ガイドライン」第4.0版で、情報セキュリティ6か条にバックアップを追加し、サプライチェーン強化に向けた評価制度の考え方も取り込んでいます（出典: IPA「中小企業の情報セキュリティ対策ガイドライン」、2026年）。見積書には、障害、データ保護、保守、災害時への備えの条件を具体的に書き込みます。

• 障害対応：監視時間、障害時の一次対応、復旧目標
• データ保護：バックアップ頻度、ログ保持期間
• 保守：脆弱性対応、API仕様変更への対応
• 災害時：代替手段

特に、夜間や繁忙期に連携が止まった場合に、誰が判断し、どの順で再送し、在庫数を照合するかが重要です。安価な構成でも、この運用設計がなければ、障害のたびに手作業が戻り、導入効果が失われます。

よくある質問（FAQ）

導入の相談では、リアルタイム性、Excel連携、複数倉庫、AI活用について質問を受けます。自社の判断に使えるよう、導入前に確認したい点を整理します。

在庫連携システムのリアルタイム連携とは何ですか？

リアルタイム連携は、在庫の変動を検知して短い遅延で連携先へ反映する方式です。ただし、常にゼロ秒で一致する意味ではありません。

何分以内に反映するかは、APIの制限、送信キュー、相手サービスの反映間隔、障害時の再送を含めて確かめます。売り越しを許容できない商品には、予備在庫や販売停止閾値も合わせて設計します。

Excelしか使えない取引先や店舗とも連携できますか？

Excelしか使えない取引先や店舗とも連携できます。ただし、Excelファイルをそのまま取り込めるかより先に、CSVやSFTPなどの形式、項目名、文字コード、ファイル名、受け渡し時刻、重複防止キーを決めます。

APIがない相手には定時バッチを使い、取込結果とエラーを担当者へ通知します。手作業でファイルを加工する場合は、加工前後の件数と在庫合計を照合し、担当者によって作業が変わらない手順書を用意します。

複数倉庫の在庫を一元管理するときの注意点は何ですか？

倉庫ごとの在庫を合算して販売するのか、チャネルごとに利用する倉庫を固定するのかを先に決めます。出荷可能な倉庫、在庫割当率、取り寄せ、店舗間移動、輸送中在庫を同じルールで扱う必要があります。

倉庫コードとロケーションをマスタで統一し、移動や出庫の実績を正のシステムへ戻せる構成にしておくと、合算値だけでは見えない差異を追跡できます。

AI需要予測は在庫連携と同時に導入すべきですか？

原則として、最初は在庫と受注のデータ品質を整えます。安定した実績が蓄積してから、AI需要予測を追加します。

SKUの統廃合や欠損、返品、販促による急増、季節性が整理されていないと、現場は予測結果を検証できません。

まずは在庫差異率や欠品率を測れる状態にし、限定した商品群で予測精度と補充判断を試してから対象を広げます。

まとめ

在庫連携システム開発の成否は、製品の機能数や月額料金だけでなく、業務の設計で決まります。

在庫の正、販売可能在庫の計算、SKUマスタ、業務イベントを一つの業務設計として扱うことが重要です。連携遅延、エラー復旧、移行と教育も、同じ設計に含めます。

開始前に確認する三つの事項

まず、在庫の正と在庫区分を決めます。次に、チャネル・倉庫・基幹システム間のデータ項目、方向、頻度、エラー時の責任者を連携マップにまとめます。

最後に、SaaS、パッケージ、受託開発のどこまでを標準機能で実現するかを決め、初期費用だけでなく3年間の総保有コストと導入効果を比較します。

小さな範囲での検証と全社への展開

まずは1倉庫と主要チャネル、代表SKUで、入荷から返品までを試します。全チャネルや全倉庫への切り替えは、その後に進めます。

テストで在庫差異、同期遅延、現場操作、障害復旧を確認し、切り戻し条件と運用手順を整えてから対象を広げます。

稼働後も在庫差異率、売り越し件数、欠品率、エラー復旧時間を追い、業務とシステムを継続的に改善します。

▼全体ガイドの記事
・在庫連携システム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。