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

在庫連携システム開発は、各チャネルの在庫をただ同期するのではなく、在庫の正と業務イベントを決め、要件整理から定着まで六つのフェーズで進めることが成功の近道です。

Amazonや楽天、自社EC、実店舗、倉庫、販売管理システムの在庫が一致せず、売り越しや二重入力に悩んでいる企業は少なくありません。一方で、サービスの「API連携対応」という表示だけでは、受注取込だけなのか、在庫送信・出荷実績・返品まで双方向に連携できるのか判断できません。本記事では、在庫連携システムの全体像、要件整理から稼働後の定着までの進め方、費用相場、見積書の見方を、実務で使えるチェック項目とともに解説します。

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

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

在庫連携システムとは、複数の販売チャネルや倉庫、基幹システムに分散した商品・在庫情報を、共通のルールで受け渡す仕組みです。数量をコピーするだけではなく、どのシステムを在庫の正とするか、受注・引当・出荷・返品・棚卸しのどの時点で数量を変えるかまで含めて設計する必要があります。

複数のシステムが在庫数を書き換える状態では、連携を増やすほど数量差異の原因が見えにくくなります。まずは、在庫管理システムやWMS、OMS、ERPのうち、どこを在庫の正とするかを決めます。そのうえで、物理在庫、販売可能在庫、引当済み在庫、不良在庫、輸送中在庫、棚卸し中在庫を分けます。例えば、ECに表示する数量を「物理在庫」から返品予定分まで差し引いた「販売可能在庫」と定義すれば、表示値の根拠を現場とEC担当者で共有できます。

設計書には、受注を取り込んだ時点、引当が確定した時点、出荷を確定した時点、返品を検品した時点で、どの区分を何個増減させるかを書きます。キャンセル、分納、欠品、セット商品、予約商品、ロット・賞味期限品も例外として先に決めます。ここが曖昧なまま開発を始めると、「在庫は合っているのにECの表示が違う」という運用事故につながります。

連携対象は在庫数だけではありません。商品コード、SKU、JAN・GTIN、色・サイズ、セット構成、倉庫、ロケーション、取引先などのマスタを先にそろえ、受注、入荷、入庫、出庫、出荷実績、返品、棚卸し、在庫調整のデータフローを整理します。API、Webhook、CSV、SFTP、EDIのどれを使うかは、相手側の仕様、送信上限、障害時の再送方法まで含めて判断します。

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

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

在庫連携システムは、(1)要件整理、(2)製品・開発会社の選定、(3)設計・開発、(4)テスト、(5)稼働、(6)定着の順で進めます。SaaSを導入する場合でも、商品マスタの整理、連携マップ、テスト、現場教育が必要なため、契約すれば終わりとは考えないことが大切です。

最初に、販売チャネル、倉庫・店舗、基幹システム、現在の在庫台帳、受注件数、SKU数、拠点数、棚卸し頻度を一覧にします。Excelや電話で行っている作業も省略せず、誰が、いつ、どの画面やファイルを使い、どの判断をしているかを記録します。特に、通常処理よりもキャンセル、分納、返品、欠品、セット品、店舗間移動などの例外処理に時間がかかっている場合は、要件の中心に置きます。

実務では、システム名だけを書いた連携図では不十分です。「商品コード」「数量」「在庫区分」「更新日時」「送受信方向」「連携頻度」「エラー時の責任者」「再送方法」を1行ずつ記載した連携マップを作ります。要件整理の完了条件は、主要な業務イベントを一巡させたときに、どのシステムにどの値が残るかを説明できることです。

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

選定時のデモでは、正常な在庫減算だけで判断しないことが重要です。商品コードが異なる場合の紐づけ、複数倉庫の引当、在庫割当率、API停止、CSVの重複、返品、棚卸し差異、再送、監査ログを実際のデータで確認します。候補会社には、同業・同じ在庫単位の実績、移行支援の範囲、API仕様書の開示、ソースコードや設計書の扱い、保守会社を変更するときの引き継ぎ条件まで質問します。

導入事例を見るときは、効果の数字だけでなく、どのシステム同士をつなぎ、どの業務イベントを変えたかを読み取ります。例えばロジザードの2025年2月の発表では、SODAが倉庫向けWMSと店舗向け在庫管理システムを連携し、倉庫・店舗間の商品移動や在庫照会を円滑にした事例が紹介されています（出典: ロジザード株式会社「店舗とECの在庫を一元管理」、2025年）。自社と似た構成で、導入後の運用まで説明できる事例を優先します。

設計では、商品・在庫・受注・出荷のデータモデル、画面、権限、API、CSV変換、バッチ、キュー、ログ、通知を決めます。大量のSKUや基幹連携では、即時処理と一括処理を分け、差分同期と日次の全件照合を併用します。同じデータを再送しても数量が二重に減らない冪等性、途中で失敗しても再開できる仕組み、連携先が一時停止しても注文を失わないキューを設計に含めます。

開発会社に依頼する場合は、要件定義書だけでなく、項目定義書、連携マップ、エラーコード一覧、テスト仕様書、移行手順書、運用手順書の納品条件を契約へ入れます。AI需要予測や自動補充を追加する場合も、先にSKU表記揺れ、欠損、返品データの扱いを整えます。データ品質が低いままAI機能を足しても、予測結果の説明や現場の信頼を得にくいためです。

テストは、画面が表示されるかを確認するだけでは足りません。1倉庫、主要チャネル、代表的なSKUを対象に、入荷、入庫、受注、引当、出荷、キャンセル、返品、棚卸し、在庫調整を一巡させます。その後、複数倉庫、セット品、ロット・期限、同時注文、API停止、数量不一致、同一データの再送を加えます。合格基準には、許容遅延、在庫差異ゼロの条件、エラー通知時間、再送完了時間、担当者の操作時間を記載します。

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

稼働後は、在庫差異率、売り越し件数、欠品率、在庫確認にかかる時間、棚卸し工数、出荷リードタイム、連携エラーの復旧時間を月次で確認します。単にエラー件数を減らすのではなく、SKU未紐づけ、数量不一致、認証切れ、API制限、現場の手入力など、原因別に分類します。1か月目は毎日、運用が落ち着いた後は週次や月次で責任者が確認し、改善の優先順位を決めます。

現場教育では、通常操作よりも「エラーが出たときに何をしてはいけないか」を伝えます。例えば、連携エラーを見て同じ注文を手動登録する前に、キューと受注番号を確認する、在庫を直接上書きする前に棚卸し差異の理由を記録する、といった手順を決めます。担当者が変わっても運用できるよう、画面キャプチャ付きの手順書、問い合わせ窓口、月次の改善会議を用意します。

費用相場とコストの内訳

在庫連携システムの費用は、SKU数、チャネル数、拠点数、APIの有無、ロット・期限・セット品、既存基幹との接続、データ移行の汚れ、現場端末の台数で大きく変わります。以下は税別の目安です。公開料金と類似する在庫・物流システム開発の相場を分けて考え、必ず自社の連携範囲に合わせて見積もります。

小規模な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万円程度を保守枠として見る考え方ですが、契約内容に基づく試算であり、特定金額を保証するものではありません。

比較表を作るときは、初期開発費や初期設定費だけでなく、月額・従量課金、外部アプリ、API利用料、追加拠点、ハンディ端末、バーコード機器、データ移行、教育、保守、監視、バックアップ、改修費を3年間で合算します。月額が安い製品でも、受注件数やチャネル数が増えたときの従量課金、連携先追加の個別見積もり、サポート範囲によって総額が逆転することがあります。

また、金額だけでなく、売り越し件数、在庫確認時間、棚卸し工数、手入力の人数を現状と導入後で比較します。費用対効果は「削減できる人件費」だけでなく、欠品による機会損失、誤出荷、緊急出荷、顧客対応の削減も含めます。AI需要予測など将来機能は、最初から全額を投じるのではなく、データ品質を整えた後に追加できる構成にすると、初期投資の膨張を抑えやすくなります。

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

良い見積もりは、合計金額だけでなく、どの業務とデータを、どの方法で、誰が、いつまでに実現するかを説明します。相見積もりを取る前に、対象範囲と評価基準をそろえます。候補会社ごとに前提条件が違うまま価格だけを比べると、安い見積もりに必要な移行・テスト・教育が抜けていることがあります。

RFPや要件メモには、チャネル・拠点・SKU数・月間受注件数・ピーク時件数・在庫区分・連携方向・連携頻度・許容遅延・保持期間を記載します。さらに、セット商品の構成変更、予約、欠品、キャンセル、分納、返品、棚卸し差異、店舗間移動を例として添えます。APIがない相手にはCSVやSFTPを使うのか、ファイルの作成者と承認者は誰か、取込失敗時に何を通知するかも書きます。

チェックリストとして、(1)在庫の正が一つに決まっているか、(2)販売可能在庫の計算式があるか、(3)商品コード変換表の責任者がいるか、(4)同期遅延の許容値があるか、(5)重複取込を防げるか、(6)エラーを再送できるか、(7)全件照合ができるか、(8)監査ログを誰が見られるか、(9)切り戻し条件があるか、(10)現場教育と保守窓口が見積に含まれるかを確認します。

開発会社やベンダーを比較するときは、企業規模や知名度だけで決めません。EC中心、店舗・オムニチャネル中心、製造・部品中心、3PL中心では、必要な在庫単位も現場端末も異なります。同じ業態、近いSKU数、同じ連携方式の事例を確認し、導入前の課題、採用した構成、移行方法、稼働後の運用まで説明できる会社を候補にします。

提案書では、標準機能で対応する部分、設定で対応する部分、追加開発する部分、運用で吸収する部分を色分けしてもらいます。過剰なカスタマイズで、当初2,000万円だった計画が4,200万円に膨らんだ失敗例は、標準機能と業務変更の境界を先に決める重要性を示しています。デモでは、実データに近いSKUと異常系を使い、説明の分かりやすさや質問への対応姿勢も評価します。

在庫連携は、商品情報や取引情報を複数のサービスへ渡すため、障害だけでなく権限設定、認証情報、バックアップ、委託先管理も確認します。IPAは2026年3月公開の「中小企業の情報セキュリティ対策ガイドライン」第4.0版で、情報セキュリティ6か条にバックアップを追加し、サプライチェーン強化に向けた評価制度の考え方も取り込んでいます（出典: IPA「中小企業の情報セキュリティ対策ガイドライン」、2026年）。連携先が増えるほど、契約終了時のデータ返却や認証情報の廃棄も要件に含めます。

見積書には、監視時間、障害時の一次対応、復旧目標、バックアップ頻度、ログ保持期間、脆弱性対応、API仕様変更への対応、災害時の代替手段を明記します。特に、夜間や繁忙期に連携が止まった場合に、誰が判断し、どの順で再送し、在庫数を照合するかが重要です。安価な構成でも、この運用設計がなければ、障害のたびに手作業が戻り、導入効果が失われます。

よくある質問（FAQ）

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

リアルタイム連携とは、在庫変動を検知して短い遅延で連携先へ反映する方式ですが、常にゼロ秒で一致する意味ではありません。APIの制限、送信キュー、相手サービスの反映間隔、障害時の再送を含めて、何分以内に反映するかを確認します。売り越しを許容できない商品は、予備在庫や販売停止閾値も合わせて設計します。

連携できますが、Excelファイルをそのまま取り込めるかではなく、CSVやSFTPなどの形式、項目名、文字コード、ファイル名、受け渡し時刻、重複防止キーを決めます。APIがない相手には定時バッチを使い、取込結果とエラーを担当者へ通知します。手作業でファイルを加工する場合は、加工前後の件数と在庫合計を照合し、担当者の属人化を防ぐ手順書を用意します。

倉庫ごとの在庫を合算して販売するのか、チャネルごとに利用する倉庫を固定するのかを先に決めます。出荷可能な倉庫、在庫割当率、取り寄せ、店舗間移動、輸送中在庫を同じルールで扱う必要があります。倉庫コードとロケーションをマスタで統一し、移動・出庫の実績を正のシステムへ戻せる構成にすると、合算値だけでは見えない差異を追跡できます。

原則として、最初は在庫と受注のデータ品質を整え、安定した実績が蓄積してからAI需要予測を追加します。SKUの統廃合、欠損、返品、販促による急増、季節性が整理されていなければ、予測結果を現場が検証できません。まずは在庫差異率や欠品率を測れる状態にし、限定した商品群で予測精度と補充判断を試してから対象を広げます。

まとめ

在庫連携システム開発の成否は、製品の機能数や月額料金だけで決まりません。在庫の正、販売可能在庫の計算、SKUマスタ、業務イベント、連携遅延、エラー復旧、移行と教育を一つの業務設計として扱うことが重要です。

最初に、在庫の正と在庫区分を決めます。次に、チャネル・倉庫・基幹システム間のデータ項目、方向、頻度、エラー時の責任者を連携マップにします。最後に、SaaS、パッケージ、受託開発のどこまでを標準機能で実現するかを決め、初期費用だけでなく3年間の総保有コストと導入効果を比較します。

いきなり全チャネル・全倉庫を切り替えるのではなく、1倉庫と主要チャネル、代表SKUで入荷から返品までを試します。テストで在庫差異、同期遅延、現場操作、障害復旧を確認し、切り戻し条件と運用手順を整えてから対象を広げます。稼働後も在庫差異率、売り越し件数、欠品率、エラー復旧時間を追い、業務とシステムを継続的に改善します。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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