ECサイトの在庫・受注連携｜API・CSVの違いと開発費用・導入手順

ECサイト

最終更新日：2026年10月14日

この記事の監修者

齊藤真也

株式会社ファーストネットジャパン代表取締役

1998 年創業時からアプリ開発・Web マーケティング・フルリモート SES・ホームページ制作・翻訳・グラフィックデザインなど幅広い IT／クリエイティブ領域を手がけ、4,000 件超のプロジェクトを統括。セキュリティ対策・SEO・システム開発から中小企業のWeb戦略支援まで、技術とデザインの両面でクライアントの課題解決を27年以上にわたり支援してきた。
大阪本社・東京オフィスの2拠点体制で、全国の企業のデジタル化をサポート。
高松市出身。座右の銘は「圧倒的努力」。

ECサイトの在庫・受注連携は、ECと販売管理・倉庫等の間で情報を交換する仕組みです。導入前に、商品・在庫・注文の管理元、更新するタイミング、連携が失敗した時の担当を決めると、転記や売り越しへの対策を設計しやすくなります。

費用は連携先、項目、API・CSVの対応、例外処理、テスト範囲で変わります。既存ECへの追加連携は現行調査後の個別見積もりです。FNJのEC新規制作は150万円〜、独立したWebシステム開発は100万円〜が基準で、要件・規模により変動します。

この記事では、運用中のECに在庫・受注連携を追加する企業向けに、方式の違い、費用、業務の確認と導入・検収の手順を整理します。

ECサイト制作・ネットショップ構築
をご検討されていますか？

ファーストネットジャパンでは、1998年の創業から培ってきた知見・経験をもとに、Shopify・EC-CUBE・独自開発まで、事業内容や必要な機能に合わせたECサイト制作を支援します。構築から公開後の集客・運用改善まで、まずはお気軽にご相談ください。

ECサイト制作サービスを
詳しく見る

まず商品・在庫・受注の管理元を決める

情報	決めること	確認する担当
商品	商品コード・SKU・規格・公開条件	商品担当
在庫	実在庫・引当・販売可能数の管理元	在庫・倉庫担当
受注	EC受付と業務側登録の対応番号	受注担当
出荷	発送状態・伝票番号・通知	出荷担当
変更・取消	在庫と決済・業務状態を戻す順番	運営・経理

同じ在庫をEC側と倉庫側の両方から自由に変更すると、どちらを採用すべきか分からなくなります。店舗や複数モールもある場合は、販売可能数の配分と引当ルールをまとめて確認してください。

API・CSV・定期処理は、更新頻度と運用で選ぶ

方式	特徴	依頼前の確認
API連携	必要な処理や情報をシステム間で交換	利用権限、項目、制限、エラー
CSV連携	ファイルを出力・取り込みして交換	形式、文字コード、担当、重複
定期処理	一定間隔で取得・更新する	間隔、締め時間、停止時の再開

APIを使うことだけで、常にリアルタイムの整合が保証されるわけではありません。通知、取得、更新の各段階で失敗することを想定し、注文の照合と在庫の再確認を設計します。CSVでも日々の転記を減らせる場合があり、必要な頻度から方式を選びます。

連携開発の費用は、接続本数より業務条件で変わる

見積もりでは、仕様調査、項目対応、接続、例外処理、照合・通知、テスト、保守を分けます。片方向の在庫更新と、注文変更・分納・返品まで扱う連携では必要な処理が異なります。

費用項目	増減する条件
調査	連携先の仕様・窓口・試験環境がそろうか
項目変換	商品・注文コード、単位、税・配送情報
例外処理	再送・重複・変更・取消・在庫不足
管理・監視	失敗一覧、担当への通知、再実行
受入テスト	EC・業務・倉庫の担当が一緒に試せるか

第三者サービスの契約やAPI利用料、連携先側の設定変更は別費用になる場合があります。初期開発と継続利用・監視を分け、追加料金になる条件を見積もり時に確認してください。

ECサイト制作・ネットショップ構築
をご検討されていますか？

ECサイト制作サービスを
詳しく見る

連携失敗・同時注文・再送の扱いを決める

次は運用確認の想定例です。単に成功した一件を確認するだけでなく、担当者が例外から戻せるかを試します。

ケース	確認する処理
同じ注文を再送	同一番号で照合し二重登録を防ぐ
在庫更新失敗	通知・再送・在庫確認を行う
同時注文	引当と不足時の受付ルールを適用
注文取消	決済・在庫・業務状態を照合
停止後の再開	未処理と処理済みの境界を確認

Shopifyの在庫設定APIの公式仕様のように、接続先ごとの更新条件を確認する必要があります。他システムの仕様も照合し、在庫を管理する側と更新する側を一致させます。

導入は小さく試し、担当者が運用できる範囲で広げる

現行の転記・在庫・注文業務と、困る例外を一覧にする。
項目の管理元、対応コード、更新の順番を決める。
試験環境で代表商品と注文を処理する。
正常・異常・再送・取消を業務担当が確認する。
対象商品や拠点を限定して運用を開始する。
失敗件数・転記時間・照合結果を見て対象を広げる。

期間には連携先の資料提供、契約・権限、試験データ、業務担当の検収を含めます。制作実務では、失敗通知は届くが誰も修正方法を知らない状態に注意します。未処理一覧、再実行の条件、担当と連絡先を運用手順へ残してください。

現在のCSV運用を整理してから、自動化する範囲を決める

現行のCSVを見せるだけでなく、誰が何時に出力し、どのシステムへ取り込み、エラーをどう直しているかを記録します。手作業には、欠損項目の補完や注文変更の確認等、データ交換だけでは分からない判断が含まれることがあります。その作業を省くと、不正なデータが自動で登録される場合があります。

現在の確認	自動化前に決めること
商品コードの補正	変換表と、未登録コードの停止条件
注文の確認	登録対象の状態と、変更済み注文の扱い
出荷の締め	処理する時刻と、締め後の注文の扱い
失敗の再取込	再送する対象と、処理済み番号の照合
集計	成功・失敗・未処理の件数確認