EC在庫連携システムの発注は、在庫ルールと要件の定義、方式と委託先の比較、小規模な導入と検証の順に進みます。
発注方式の選び方、進め方、費用相場、契約と委託先の選び方を順に説明します。全体像をまとめた完全ガイドも、あわせてご覧ください。
▼全体ガイドの記事
・EC在庫連携システム開発の完全ガイド
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
EC在庫連携システムを発注・外注する前の全体像
EC在庫連携システムは、在庫数を各チャネルへ配る仕組みです。その際、実在庫と引当済みの数、予約と入荷予定、安全在庫を区別して扱います。
どの拠点の商品を、どの販売先へ、いくつ販売可能として表示するかも計算します。そこで、発注前に在庫の定義を固めておくと、異なる提案も同じ条件で比べられます。
在庫の定義と「正」のシステムの決定
在庫の基準と販売可能数の定義がそろうと、連携の向きや更新のルールも決めやすくなります。
- 在庫の正：WMS、ERP・販売管理システム、OMSのどれを基準にするか
- 連携の流れ：OMSで引当てた後に各モールへ配信するか、WMSの出荷可能数をECへ配信するか
- 在庫データ：販売可能数の計算と、SKU・JAN・商品・拠点・モールコードの名寄せ
- 更新担当：どの担当者がどのデータを更新するかの取り決め
販売可能数は、たとえば「実在庫−引当済み−安全在庫」で求めても、予約商品や店舗取り置きの扱いで結果が変わります。
発注形態の分類（既製サービス、拡張、個別開発）
標準機能で足りるか、独自ルールを補う必要があるか、個別開発が要るかを、要件に照らして比べます。
- 既製SaaS：標準的なモールや自社ECとの連携に導入し、初期設定や移行の支援を外部に頼む
- 拡張：独自の引当ルールがある既存ERP・WMS・POSに、APIやCSVの連携を加える
- 個別開発：店舗受取、店舗発送、倉庫の優先順位、BtoBの掛率、予約・分納に対応する仕組みを作る
既製SaaSには、ネクストエンジンやTEMPOSTARがあります。また、拡張は、SaaSやパッケージにAPI・CSVコネクターを追加する方法です。
店舗受取や店舗発送、複数倉庫の優先順位が差別化の要件になるなら、パッケージのカスタマイズやSIerによる個別開発を検討します。BtoBの掛率や予約・分納についても、標準機能で対応できるかを先に確かめます。
フルスクラッチは自由度が高い反面、保守や障害対応で自社の責任範囲も広がります。そのため、標準機能で不足する要件を整理してから選ぶことが大切です。
EC在庫連携システムの発注・外注方式の選び方
方式は業務要件と運用体制で選びます。初期費用に加え、3年間の利用料、保守、連携先の追加、データ移行を含む総保有コストで判断してください。
既製SaaS導入が向いている企業の特徴
標準機能で始めやすい一方、初期設定や追加費用を含めて、導入支援がどこまで対象かを確認しておく必要があります。
- 標準連携：モール・カート、受注、在庫、出荷の機能を利用できる
- 導入対象：複数の画面を手作業で更新している企業や、1モール・1倉庫から改善したい企業
- 追加確認：設定、SKU名寄せ、既存接続、権限、研修の範囲
API利用料や連携アプリ、商品コード変換、個別帳票、サポート範囲が、別料金になる場合もあります。
ゼロから開発するより短期間で稼働しやすく、業務を標準機能に合わせれば投資も抑えられます。また、月額だけでなく、導入支援の委託範囲も確かめておきます。
パッケージ拡張での既存業務と標準機能の折り合い
既存業務を活かしながら、必要な機能だけを補えるかを、まず確かめます。
- 製品選択：EC一元管理やOMS、WMSなどから選び、不足部分をカスタマイズする
- 在庫ルール：店舗在庫は公開しつつ、店舗販売用の安全在庫を残す
- 出荷・商品：優先倉庫の指定と、セット商品の構成数変換の追加
契約前に、標準アップデートの影響を受けない拡張方法になっているかと、将来の改修担当を確かめておきます。標準画面を直接変更すると、更新や障害時の切り分けが難しくなります。
発注側は、設定、追加開発、運用手順を分けて見積書に書いてもらうと、費用の境界がはっきりします。
個別開発での責任分界と運用体制
独自の在庫業務と複数のシステムを一体で扱うなら、開発体制と運用の責任も、あわせて決めておく必要があります。
- 対象業務：自社EC、複数モール、POS、WMS、ERP、3PLを一つのルールで動かす
- 個別要件：旧システムのCSV・EAI連携、同時引当制御、複数倉庫の在庫配分
- 発注者体制：業務責任者、商品マスター管理者、現場テスト担当者の配置
- 障害時の備え：販売停止、縮退運転、手動再送の方針と、運用上の責任の取り決め
監査ログやバックアップ、データ出力の扱いは、契約と運用設計に反映します。再委託先や個人情報の扱いも、契約の条件として定めます。
EC在庫連携システムを外注する進め方
外注は現状把握から始まり、要件定義と方式選定を経て、設計・開発に進みます。その後、移行やテスト、本番稼働を経て保守へ移ります。
そのとき発注側は、業務シナリオを示し、データと更新のタイミングを伝えます。更新元と、失敗時の復旧方法も併せて伝えます。
要件定義とRFPによる発注条件の統一
RFPには、規模と現状、連携条件、受入条件を書きます。そのため、各社の提案を同じ前提で比べられます。
- 規模と現状：対象チャネル、拠点・SKU数、月間平均受注数、繁忙期ピーク、在庫管理方法
- 運用条件：連携するシステム、許容できる遅延、必要な権限、希望時期
- 受入条件：通常時5分以内の反映や、注文集中時の二重引当防止の条件
- 代表データ：商品マスターや在庫履歴、受注・キャンセル・返品・出荷の例を添える
API障害時に直近在庫を表示して新規注文を保留することや、返品承認後に販売可能在庫へ戻すことも、条件にできます。
データの粒度や例外処理は、システム名からは読み取れません。RFPが未完成なら、要件整理を先に発注し、その整理結果を本開発の提案依頼に使えます。
設計・開発での同期方式とエラー復旧の決定
連携方式と障害復旧の条件を先に決め、見積と仕様に反映します。
- 方式選択：API、Webhook、定期ポーリング、CSV、EAIを業務の重要度で使い分ける
- 見積範囲：データ変換、API制限、認証更新、冪等性キー、リトライまでを含める
- 復旧設計：重複防止、デッドレター、差分再同期、通知、追跡、再送の方針
数秒から数分の反映にはAPIやWebhookが候補になります。一方、APIのないレガシーシステムでは、CSVバッチを使う方法があります。
目標を「エラーが起きない」に置くと、実現性と費用の判断を誤るおそれがあります。そこで、エラーを検知して担当者へ通知し、失敗した注文・SKU・在庫更新を追跡できる設計にしておきます。
再送や手動承認で復旧できるようにし、その手順は画面案や仕様書に示してもらいます。障害画面や通知先、監査ログの保存期間も、同じ仕様書に含めてもらいます。
移行・テスト・リリースと繁忙期の失敗への備え
移行・テスト・稼働を段階化し、切替後の差分や繁忙期の障害に備えます。
- 移行確認：商品コード、セット構成、初期在庫、引当済み数、入荷予定、予約の照合
- 試行切替：主要SKUと1倉庫で試し、旧システムとの差分を一定期間突き合わせる
- 障害テスト：同時注文やキャンセル後の再注文、返品、API制限、通信断、棚卸差異を想定したテスト
- 稼働後の監視：ピーク件数での性能確認と、売り越し率、反映遅延、再送件数、手作業時間のKPI化
移行対象から外れた履歴も、問い合わせや監査に備えて、保管方法を決めておきます。
EC在庫連携システムの費用相場とコストの内訳
費用は、連携先数やSKU・拠点数、既存APIの有無によって変わります。データ移行やテスト、保守の範囲でも増減します。
そのため、以下の金額は公開情報をもとにした見積前の目安で、個別案件の確約価格ではありません。自社の受注量や業務ルールを当てはめ、3年間の総額で比較してください。
開発方式ごとの初期費用と期間の目安
公開されている方式別の費用と期間には、次の目安があります（出典: GXO株式会社「在庫管理×受発注システム連携開発の費用相場」、2026年確認）。
- SaaS間API連携：初期費用50万〜200万円程度、期間1〜3か月程度
- 既存システム改修・連携：初期費用100万〜400万円程度、期間2〜5か月程度
- 在庫統合ハブ新規構築：初期費用300万〜1,000万円程度、期間4〜10か月程度
なお、EC全体をフルスクラッチで再構築する場合は、在庫連携だけとは別の規模になります。数千万円から億円単位になるケースもあります。
チャネルを増やすほか、SKU名寄せや複数倉庫の配分でも費用は増えます。さらに、店舗受取や予約・返品、リアルタイム性も、費用を押し上げる要因になります。
外部APIのレート制限への対応や旧システムの改修も、工数として見込む必要があります。性能試験や監視、移行リハーサルの工数も、見積に含まれるかを確かめます。たとえば、標準APIの5先とCSVのみの5先では、見積が異なる可能性があります。
既製サービスの月額と従量課金の比較
月額は、受注数や商品点数、連携アプリの有無で変わります。出荷数やサポート、追加倉庫の数でも変わるため、各社の基本料金と従量課金を比べます。
- ネクストエンジン：初期費用0円、基本月額3,000円で受注200件まで。月間受注1,000件は月額28,000円、3,000件は月額78,000円
- TEMPOSTAR：スターター月額1,650円、スタンダード月額11,000円から（税込）
- LOGILESS：ライト月額20,000円、スタンダード月額25,000円に従量料金。無料枠は月間出荷300件または500件
ネクストエンジンは受注200件を超えると従量課金です。また、契約1年後は年間保守費15,000円（税抜）がかかります（出典: NE株式会社「ネクストエンジン料金」、2026年8月確認）。
TEMPOSTARの料金はいずれも税込です（出典: SAVAWAY株式会社「TEMPOSTAR料金プラン」、2026年8月確認）。
たとえば、商品課金と受注課金を合計すると、商品1,000点・月間受注1,500件の場合は月額38,500円（税込）です。
LOGILESS料金は2025年7月改定です。ライトは税込22,000円、スタンダードは税込27,500円で、従量料金が加わります。この料金の出典は、株式会社ロジレス「新料金プランおよび機能拡充のお知らせ」（2025年）です。
3年間のTCOでみる初期費用以外のコスト
初期費用以外も含めて3年間の総額を算出し、効果と前提を分けて判断します。
- 継続費：月額、従量課金、クラウド、監視・保守、API・アプリ追加料金
- 導入・運用費：移行、マスター整備、研修、問い合わせ、障害対応、契約更新
- 拡張費：受注増加後の従量課金と追加チャネルの開発単価
たとえば、初期300万円、月額5万円なら、3年間の単純合計は480万円です。これは計算例であり、削減効果や売上増を保証しません。
在庫差異や二重入力、棚卸時間を金額にします。欠品による機会損失や出荷リードタイムも金額に換算し、投資判断の前提を明記します。
契約形態とRFPによる発注条件の明確化
契約は、成果物がどこまで明確か、要件がどのくらい変わりそうか、発注者がどこまで決められるかで選びます。要件整理、開発、保守を分けて契約すると、費用と成果物の関係を確かめやすい場合があります。
契約書に加えて、提案書や要件定義書、仕様書を契約上の成果物として結び付けます。受入条件と体制表も、同じ契約に含めます。
請負契約の成果物と変更手続き
請負では、完成条件と納品物、要件変更時の手続きを、契約前にそろえます。
- 適用範囲：要件や納品物、完成条件が比較的明確な開発
- 納品物：画面に加えて、仕様書、エラー一覧、運用・移行手順、テスト結果を定める
- 変更手続き：追加開発の承認者と見積方法、納期や再テストへの影響
発注者は完成したシステムを受け入れ、開発会社は合意した成果物を納期までに納めます。そのうえで、ソースコードや設定情報をどこまで引き渡すかも決めておきます。
要件や外部APIの変更は追加費用になりやすいため、SKU追加・新モール対応と瑕疵修補の区別を、見積条件に記載します。
準委任契約の使いどころ（要件整理と継続改善）
準委任は、作業は定められても成果が変わりうる業務に使い、期待する活動を合意します。
- 対象業務：現状分析やRFP支援、構成検討、PMO、運用改善、段階的な追加開発
- 体制と報告：月間稼働時間や担当者、報告書、会議体、相談窓口
- 工程別契約：要件定義や稼働後の改善は準委任、確定した開発は請負とする方法
準委任であっても、成果への責任は残ります。そのため、障害の一次対応と納期の見通しを契約前に合意します。課題管理やレビュー、設計書の更新についても、取り決めておきます。
個人情報・再委託・データ返却の取り決め
個人情報の扱いと契約終了後の返却・削除を含め、委託先の管理条件を決めます。
- 情報管理：利用目的やアクセス権、ログ、暗号化、バックアップ、脆弱性対応の確認
- 事故・再委託：事故報告の手順、再委託先と承認方法、責任分界
- データ返却：マスターや各履歴の形式、移行支援費、削除時期
- 決済情報：カード情報を保持しない設計と、その適用基準を専門家と確認する
注文情報には、氏名や住所、連絡先のほか、購買履歴が含まれることがあります。また、委託先が他社クラウドや海外拠点を使う場合も、再委託の承認方法を確かめます。
委託先選定と見積比較で確認すべきポイント
知名度よりも、自社に近いチャネルや業務ルールを扱った経験で、委託先を評価します。会社ごとに得意領域と責任範囲が異なるため、経験の中身を見て比べます。
比較の対象には、既製SaaSの導入支援会社やOMS・WMSベンダーのほか、基幹統合に強いSIerや物流も請け負う会社があります。そこで、3社程度へ同じRFPを渡し、同じ業務シナリオで提案と見積を受けると比較しやすくなります。
類似業務による実績の確認
導入社数の多さより、自社の連携先や業務、繁忙期に近い案件があるかを見ます。
- 連携経験：自社ECと楽天・Amazon・Yahoo!、POS・WMSを同時に扱った経験
- 業務経験：店舗受取、複数倉庫、繁忙期への対応経験
- 案件の中身：導入課題や担当範囲、方式、移行件数、稼働後保守の内容
事例の説明は、守秘義務に配慮した範囲で依頼します。
2025年、アークランズとSCSKはEC基盤を再構築したと発表しました。店舗と自社EC、楽天・Yahoo!・Amazonの商品と在庫を一元管理し、リアルタイムで引当可能な仕組みを整えました。この事例には、店舗受取や商品マスターの分散の解消も含まれます。
単純な連携と大規模な統合とでは、必要な提案体制が異なり、その違いは委託先を比べる際の判断材料になります（出典: アークランズ株式会社・SCSK株式会社、2025年）。
見積書の費目と前提条件の比較
費目、作業範囲、前提条件を分けて記載してもらい、見積を同じ条件にそろえます。
- 費目：要件定義、基本設計、詳細設計、開発、外部連携、移行、テスト、教育、リリース、保守
- 内訳：機能、工数、単価、担当会社、納品物、前提、対象外作業
- 追加費用：移行・テストの発注者負担や監視、追加モールの費用、権利、データ返却
「API連携一式」とだけ書かれていると、認証や変換の範囲が分かりません。エラー処理や再送、監視まで含むかも見えません。
安い見積が、そのまま有利とは限りません。初期費用が抑えられていても、移行やテストを発注者が担う場合があります。また、障害監視が別料金であったり、追加モールが都度見積になったりすることもあります。さらに、ソースコードの権利やデータ返却に制限がある場合もあります。
3年間のTCO、繁忙期の追加費用、契約終了時の移行費用を試算し、同じ条件にそろえて比較します。
保守・SLA・障害時の責任分界
保守の対応水準と、障害の原因ごとの連絡・切り分け手順を、契約で確かめます。
- 対応水準：受付時間や一次回答、復旧目標、重大度、休日・繁忙期の対応
- 保守作業：監視やバックアップ、API変更への対応、セキュリティパッチ、月次報告
- 原因切り分け：モール、WMS、ネットワーク、商品マスターに起因する場合の連絡手順
- 費用比較：システム、物流、倉庫、配送、倉庫移管の費用を分けた内訳
在庫連携に加えて、OMS・WMSや物流フルフィルメントまで一体で提供する動きもあります。たとえば、オープンロジは2025年4月に、受注一元管理システムを開発したと公式発表しました。
その対象は、Amazon・Yahoo!ショッピング・楽天市場と、Shopify・ecforce・STORES・BASEです。また、独自WMSと連携し、受注から入出荷・在庫を管理すると説明しています（出典: 株式会社オープンロジ、2025年）。
よくある質問（FAQ）
発注では、既製サービスで足りるか、開発会社へ依頼すべきか、費用がどこまで増えるかが、よく問われます。判断では、チャネル数や受注量、在庫ルールを基準にします。反映時間やSKU、拠点も、合わせて考えます。
EC在庫連携システムはSaaSと開発のどちらを選ぶべきですか？
標準的なモール・カート連携で業務を既製運用に合わせられるなら、SaaSが候補です。店舗受取や複雑な引当、複数倉庫の運用が重要なら、パッケージ拡張や個別開発を検討します。旧基幹システムとの接続が必要な場合も、パッケージ拡張や個別開発が候補になります。
SaaSの標準機能と不足する機能を並べ、不足部分だけを外注できるかを確かめます。そうすると、過剰なスクラッチ開発を避けやすくなります。
在庫は本当にリアルタイムで反映されますか？
反映時間は、Webhook、数分ごとのAPIポーリング、1日数回のCSV取込など、方式によって異なります。そのため、「リアルタイム」という言葉だけでは、実際の反映時間は判断できません。
RFPには、通常時の許容遅延に加えて、注文集中時、API障害時、再送時の動作を記載します。実際のテスト結果で確認してください。
EC在庫連携システムの発注費用はいくらですか？
目安は既存SaaS同士のAPI連携が50万〜200万円、既存システム改修が100万〜400万円、統合ハブ新規構築が300万〜1,000万円程度です。
相場は、連携先数やSKU、拠点の数で上下します。移行やテスト、保守の条件によっても違いが出ます。SaaSの月額も受注数や商品点数、追加アプリで変わるため、初期費用と3年間の運用費を含めて見積もります。
RFPには何を書けば委託先が比較しやすくなりますか？
対象チャネルとSKU数、倉庫・店舗数を書き、月間受注数と繁忙期のピークも添えます。在庫の正と販売可能数の計算式も記載します。
同期方式や許容遅延、返品・予約・店舗受取の扱いも含めます。現行システムがAPIやCSVに対応しているかや、希望納期、予算の考え方も書いておきます。
代表シナリオは、受注やキャンセル、返品のほか、同時注文と連携障害の場面を含めます。受入テストの合格条件も添えると、見積の前提がそろいます。
まとめ：EC在庫連携システムの発注・外注を成功させる要点
機能の多さや初期費用の安さで委託先を選ぶ前に、在庫の正と、実在庫・引当・販売可能数の定義を決めておくことが大切です。SKUと拠点の名寄せも早い段階で決めると、進めやすくなります。
発注側は、同期遅延や障害時の復旧、返品・予約・店舗受取の扱いを決め、その条件をRFPと受入テストに反映します。
発注形態と責任分界の初期決定
標準チャネル中心なら既製SaaS、既存システムを活かすならパッケージ拡張やAPI連携を選びます。複雑な業務ルールが競争力に直結する場合は、個別開発が候補です。
要件定義を準委任で依頼し、確定した開発を請負にするなど、工程ごとに契約を分ける方法もあります。開発費や月額、従量課金は、移行や保守、追加連携と分けて見ます。そのうえで、3年間のTCOで比較します。
同じRFPによる複数社への相談と小規模な開始
主要SKUと1拠点で試す範囲を決め、同じRFPを複数社へ渡して提案条件をそろえます。
- 試行範囲：主要SKUと1拠点で、在庫更新や受注、キャンセル、返品を試す
- 比較項目：類似実績、技術、エラー復旧、移行支援、保守、データ返却、見積前提
- 相談先：業務を理解し、標準機能と個別開発の境界を整理できるパートナー
現場で使える運用まで設計すれば、売り越し防止だけでなく、出荷と販売機会の改善にもつながります。
費用相場は目安とし、自社のデータや業務ルール、運用体制に基づく見積で判断してください。
▼全体ガイドの記事
・EC在庫連携システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・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を創業。