ECサイトの在庫連携｜倉庫・基幹とつなぐ方法

01はじめに｜この記事でわかること

要点： ECサイトの在庫連携をこれから検討する方に向けた記事です。何とつなぐのか、方式ごとに費用と期間はどのくらいか、ズレはどこで生まれるのか、依頼前に何を決めておくのか。ご相談いただいた案件の集計とあわせてご説明します。

「モールと自社ECと倉庫、在庫がバラバラで毎朝そろえています」。ECの在庫連携でいちばん多いご相談です。在庫の数字は、置き場所が増えるほど食い違います。ECカート、モールの管理画面、倉庫の払い出し表、基幹システムの帳簿在庫。4か所に数字があれば、どれかは必ず古くなります。

連携とは、この食い違いをゼロにする作業ではありません。どこまでのズレなら業務が回るかを決める作業です。

2000年創業のWeb制作会社であるZenWeb Japanでは、ECサイトの制作とWebシステム開発を手がけています。うまくいく案件の共通点は、つなぐ前に「正の在庫はどこか」を決めていたことでした。

在庫と受注の一元管理という考え方の全体像は、以下の動画がわかりやすくまとまっています。

02在庫連携でつまずくのは「つなぎ方」ではない

要点： 在庫連携で失敗する原因の多くは、技術ではなく決めごとの不足です。正の在庫がどこにあるのか、誰が数を直せるのか、ズレたときどちらを優先するのか。この3つが決まっていないと、どんな仕組みを入れても人が毎日そろえることになります。

実際の案件でつまずくのは、連携方法の選択ではありません。数字の持ち主が決まっていないことです。

たとえば、ECの管理画面で在庫を10に直した人と、倉庫システムで12に直した人がいたとします。どちらが正しいかを決めるルールがなければ、システムは後から届いた数字で上書きします。翌朝には、誰も意図しない数が並びます。

• 正の在庫を1か所に決める。 倉庫の実在庫か、基幹の帳簿在庫か、ECカートの引当後在庫か。1つだけ選びます。
• 直せる場所を絞る。 正の在庫を持つ場所以外では、原則として数を手で直さない運用にします。
• 流れる向きを決める。 正の場所から各販売チャネルへ一方通行にすると、上書き事故がほぼ起きなくなります。

この3つは、開発が始まる前に決められます。在庫管理システムの開発を単体で検討している場合も、考え方は同じです。

03つなぐ相手は3つ｜販売チャネル・倉庫・基幹

要点： ECの在庫連携でつなぐ相手は、販売チャネル、倉庫、基幹システムの3つに分かれます。それぞれ持っている数字の意味が違うため、同じ「在庫100」でも中身が一致しません。まず、どの数字を扱っているのかを区別することが出発点です。

3つの相手は、役割がこう分かれます。

ここでよく起きるのが、倉庫の実在庫を、そのまま売れる数として流してしまうことです。棚に10個あっても、2個が出荷待ちで引き当てられているなら、売っていいのは8個。この8個を有効在庫と呼びます。モールへ渡すべきなのは有効在庫のほうで、実在庫を渡すと引当ぶんが売り越しになります。

倉庫側の仕組みまで含めて設計する場合は、物流システム開発の考え方もあわせてご覧ください。扱うデータの範囲が一段広くなります。

04ご相談で「つなぎたい」と挙がった相手

要点： ご相談時にうかがうと、つなぎたい相手として最も多く挙がるのはモールの在庫でした。一方、実際に自動でつながっていた割合が最も低いのは倉庫の実在庫です。希望と現状の差が大きいところに、手作業が残っています。

目立つのは、倉庫と店舗の数字だけ自動化が遅れている点です。モールはAPIが公開されているためつなぎやすく、倉庫や店舗は相手先の都合に左右されます。いちばん実物に近い数字が、いちばん遅く届いています。

05連携方式は4つ｜API・ファイル・一元管理・個別開発

要点： 在庫連携のつなぎ方は、API連携、ファイル（CSV）連携、一元管理サービス経由、個別開発の4つです。速さと費用が反対の関係にあるため、扱う商品の回転の速さと販売チャネルの数から選びます。

1. API連携。 システム同士が直接やり取りします。在庫が動いた直後に反映できますが、相手先ごとに仕様が違うため作り込みが必要です。仕組みの基本はAPI連携とは何かを整理した記事でご説明しています。
2. ファイル（CSV）連携。 決まった時刻にファイルを書き出し、相手側で取り込みます。古い基幹システムでも使えるのが強みで、費用も抑えられます。ただし更新は1日数回が現実的です。
3. 一元管理サービス経由。 モール対応済みのサービスを間に置き、そこを正の在庫にします。導入は速い一方、独自の商品構成や倉庫ルールには合わせにくいことがあります。
4. 個別開発。 中継の仕組みを作り、各システムの差を吸収します。自由度は高く、費用と期間も最も大きくなります。

選び方の目安は単純です。1日に同じ商品が何度も動くなら速い方式、動きがゆるやかなら安い方式で足ります。1日20件の受注で秒単位の同期を作っても、投資は回収しにくくなります。

06方式別｜費用と期間、更新の間隔

要点： ファイル連携なら30万円前後から、API連携は100万円台から、個別開発は300万円を超えることが多くなります。期間も方式で大きく変わるため、公開日から逆算して選ぶ必要があります。

金額の幅が広く見えますが、差を生むのはつなぐ相手の数です。モール2つと倉庫1つなら下限、モール4つと基幹と店舗まで含めるなら上限側になります。ECサイト全体の費用感はECサイト構築費用の内訳にまとめています。

07在庫のズレはどこで生まれるのか

要点： 在庫のズレは、注文が入ってから倉庫が引き当てるまでの時間、返品と交換、セット商品の計算、複数拠点の配分。この4か所で生まれます。連携を速くしても、後半の3つは設計しないと残ります。

ズレの発生源は、おおよそ4つです。

• 反映までの待ち時間。 新しい数が各チャネルへ届くまでの間に、別のチャネルで同じ商品が売れます。連携間隔を短くすると減ります。
• 返品・交換・キャンセル。 戻ってきた商品を再び売れる状態にするかどうか、検品の前か後か。ここを決めないと、数だけ増えて実物がない状態になります。
• セット商品と同梱。 単品とセットで同じ在庫を共有する場合、片方が売れたときの引き算をシステムが理解している必要があります。
• 複数拠点への配分。 倉庫が2か所あるとき、有効在庫を合算するのか、拠点ごとに分けるのか。合算すると、出荷できない拠点の在庫まで売れてしまいます。

連携の速さで解決するのは1つ目だけです。残りの3つは業務ルールの話なので、システムを速くしても消えません。ここを先に切り分けておくと、必要以上に高い方式を選ばずに済みます。

なお、定期購入・サブスクECの構築を併用している場合は、次回配送ぶんをいつ引き当てるかという論点が加わります。

08連携間隔別｜売り越しの起きやすさ

要点： 連携間隔を短くするほど売り越しは減りますが、効果は一定のところで頭打ちになります。集計では、1日1回から30分ごとに変えた効果が最も大きく、5分から1分へ縮めた効果はわずかでした。

読み取れることは1つです。費用対効果がいちばん大きいのは、手動から30分ごとへ変える区間です。そこから先は、金額の増え方に対して減り方がゆるやかになります。セール期だけ間隔を詰める設計にすると、費用を抑えたまま実害を減らせます。

09安全在庫と引当のルールを先に決める

要点： 安全在庫とは、実在庫のうち販売に出さずに残しておく数のことです。連携の遅れを吸収する余白として使います。引当のタイミングとあわせて決めると、売り越しは仕組みだけでかなり抑えられます。

考え方は単純です。連携が遅れている間に売れてしまう数を、あらかじめ差し引いておくだけです。30分ごとの連携で、その30分に平均2個売れる商品なら、2〜3個を残しておけば足ります。

あわせて決めるのが引当のタイミングです。選択肢は3つあります。

迷ったら、注文確定時に引き当てて、一定期間で未入金をキャンセルする形が扱いやすいです。カートや決済まわりの機能は、ECサイトに必要な機能一覧で整理しています。

10倉庫（WMS・3PL）とつなぐときの実務

要点： 倉庫との連携は、出荷指示を送る流れと、出荷実績・在庫報告を受け取る流れの2本立てになります。委託先の3PLが対応できる形式が先に決まっていることが多く、こちらが合わせる前提で設計します。

倉庫側とやり取りするデータは、だいたい次の4種類です。

• 出荷指示。 注文番号、届け先、商品と数量、配送の指定。ECから倉庫へ送ります。
• 出荷実績。 いつ出たか、送り状番号は何番か。倉庫からECへ返ります。お客様への発送通知に使います。
• 入荷予定と入荷実績。 仕入れた商品が棚に入った時点で、売れる数が増えます。
• 在庫報告。 棚卸しの結果を含む実在庫。ズレを直す元データです。

実務で効くのは、商品コードを倉庫側の表記にそろえておくことです。ECのSKUと倉庫の品番が違うと変換表を挟むことになり、商品が増えるたびに手入力が発生します。

Shopifyのように標準で複数ロケーションを扱えるカートなら、倉庫が増えても構成を保ちやすくなります。プラットフォーム選びから検討する場合は、Shopify構築の費用と依頼できる範囲もご覧ください。

11基幹システムとつなぐときの実務

要点： 基幹システムとの連携は、在庫だけでなく売上と原価に影響します。速さより、締めのタイミングに合っているかどうかで決まります。多くの場合、1日1回のバッチで足ります。

基幹システムは、経理と仕入れのために数字を持っています。売れた瞬間に知る必要はなく、締めに間に合えば十分という性質のものです。モールとの連携ほど速さを求めなくても、業務は回ります。

むしろ気をつけたいのは、次の3点です。

1. 締め時刻をそろえる。 ECの日次集計と基幹の締めが1時間ずれていると、売上が翌日に流れる注文が出ます。
2. キャンセル・返品の戻し方を決める。 取り消しのデータを送るのか、マイナスの明細を送るのか。基幹側の仕様で決まります。
3. 連携が止まったときの気づき方を作る。 ファイル連携は、失敗しても静かに止まります。通知は最初から入れてください。

古い基幹システムの場合、外部とつなぐ口そのものがないこともあります。その場合は刷新とセットで考える必要が出てきますので、基幹システムの刷新と販売管理システムの機能と導入の進め方もあわせてご確認ください。

なお、国内のBtoC-EC市場は2024年に26.1兆円、EC化率9.8%（経済産業省・令和6年度電子商取引に関する市場調査）まで拡大しています。ECの比率が上がるほど、基幹側で扱う数字もECが起点になっていきます。

12稼働12か月｜在庫差異はどう変わるか

要点： 在庫差異は稼働直後がいちばん大きく、3か月ほどで落ち着きます。ただし棚卸しのルールを決めていない場合、半年を過ぎたあたりから再び広がる傾向が出ています。

注目していただきたいのは後半です。ルールなしの列だけが、7か月目以降に戻っています。原因は、日々の小さな手修正が積み上がることでした。連携が動いていても、修正を記録する場所がないと、ズレは静かに戻ります。

13公開後によくいただく相談

要点： 稼働後の追加相談で多いのは、連携が止まったことに気づけない、商品追加のたびに手作業が発生する、セール時だけ売り越しが増える、の3つです。いずれも設計時に手当てできます。

いただいた声を、そのまま並べます。

• 「連携が止まっていたのに、翌日まで気づけませんでした」。 成功時だけ記録が残る設計だと、止まった瞬間は無音です。失敗時の通知を必ず入れます。
• 「商品を追加するたびに、両方へ登録しています」。 商品マスタも連携の対象に含めておけば、片方の登録だけで済みます。在庫だけをつないだ案件で起きます。
• 「セールのときだけ売り越しが増えます」。 平常時の間隔のままだからです。期間中だけ間隔を詰めるか、安全在庫を厚くして吸収します。

リニューアルで在庫データを移す場合は、移行そのものにも注意が必要です。旧サイトの在庫をそのまま持ち込むと、公開直後の差異が大きくなります。進め方はECサイトのリニューアルの注意点にまとめています。

14依頼前に決めておく5つのこと

要点： 正の在庫の場所、つなぐ相手の一覧、許せる遅れの時間、引当のタイミング、止まったときの連絡先。この5つを書いて渡すと、各社の見積りが比較できる形で返ってきます。

見積りの金額が会社ごとにばらつくのは、前提が違うためです。次の5つを紙1枚にまとめて渡してください。

1. 正の在庫はどこか。 倉庫、基幹、ECカートのどれを正しい数とするかを1つ選びます。
2. つなぐ相手を書き出す。 モール名、倉庫名、基幹システム名まで具体的に書きます。数が費用を決めます。
3. 許せる遅れは何分か。 「1時間ずれても困らない」なら、方式の選択肢が一気に広がります。
4. いつ引き当てるか。 注文確定時か、入金確認時か。未入金の扱いもあわせて決めます。
5. 止まったら誰に伝えるか。 通知の宛先と、復旧までの手作業の手順を決めておきます。

管理画面の見え方まで決めておくと、さらに認識がそろいます。どの画面に何を出すかを図にする方法は、ワイヤーフレームの作り方が参考になります。

15まとめ｜在庫連携を決める3ステップ

要点： 正の在庫を1か所に決め、許せる遅れを分単位で決め、その2つを前提条件として見積りを取る。この順番で進めると、必要以上に高い方式を選ばずに済みます。

最後に、進め方を3つの手順に整理します。

1. 正の在庫を1か所に決める。 倉庫の実在庫を正にする例が最も多く、次いで基幹の帳簿在庫です。決めたら、それ以外の場所では手で直さない運用にします。
2. 許せる遅れを分で決める。 商品が1日に何度動くかを数えます。回転がゆるやかなら1日数回のファイル連携で足り、費用は大きく下がります。
3. 前提を書いて見積りを取る。 正の在庫、つなぐ相手、許せる遅れの3点を書いて依頼します。前提がそろうと、各社の金額が同じ土俵で並びます。

在庫連携は、派手さのない工程です。それでも、ここが整っているECサイトは、注文が増えても人手が増えません。先に決めるほど、後が軽くなる領域です。

16よくある質問

要点： ECサイトの在庫連携について、ご相談時にいただくことの多い質問をまとめました。費用、既存サイトへの後付け、モールや店舗の対応範囲についてお答えします。

今のECサイトに、後から在庫連携を追加できますか

多くの場合、追加できます。カートがAPIを備えていれば、既存のまま連携部分だけを作れます。独自開発のカートで外部との接続口がない場合は、その口を作るところから必要です。

在庫連携の費用はどのくらいかかりますか

ファイル連携で25万〜80万円、一元管理サービス経由で40万〜150万円、API連携で120万〜350万円が目安です。つなぐ相手の数で大きく変わるため、相手先の一覧をお出しいただくと精度が上がります。

モールの在庫は自動で更新できますか

主要なモールはAPIを公開しているため、自動更新に対応できます。ただし更新回数の上限や項目がモールごとに違うため、全モールを同じ間隔でそろえられるとはかぎりません。

実店舗の在庫もECとつなげますか

つなげます。POSレジ側の連携機能を使う方法が一般的です。ただし店舗は実物の動きが速いため、店舗ぶんを有効在庫に含めるかどうかは慎重に決めることをおすすめします。

連携が止まったときは、どうすればよいですか

止まったことに気づける通知を先に用意しておくことが第一です。そのうえで、手動で在庫を止める手順を決めておけば、復旧までの間の売り越しを防げます。