在庫の一元管理｜楽天・Amazonと自社ECを連携

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

要点： 楽天市場・Amazon・自社ECを並行して運営し、売り越しに悩んでいる方に向けた記事です。ズレが生まれる仕組み、商品コードの決め方、連携方式ごとの費用と反映時間、自社EC側で作り込む範囲を、担当案件の集計とあわせて解説します。

店舗を増やした直後は、だいたいうまくいきます。問題が出るのは3店舗目あたりからです。「楽天で売れた分の反映を忘れ、在庫がないのにAmazonで注文が入った」。ご相談の入口は、ほぼこの形です。

経済産業省の令和6年度 電子商取引に関する市場調査によると、2024年のBtoC-EC市場は26.1兆円、EC化率は9.8%まで上がりました。売り先が増えれば売上も伸びますが、在庫を数える場所も同じだけ増えます。人手でつないでいると、どこかで必ず食い違います。

2000年創業のWeb制作会社ZenWeb Japanでは、ECサイトの制作と改修、モール連携の開発を手がけています。この記事では在庫の一元管理を、ツール比較ではなくデータの設計問題として扱います。

まずは複数店舗の在庫と受注を1画面にまとめる形を、動画で押さえておくと読み進めやすくなります。

02在庫がズレる理由は3つしかない

要点： 在庫がズレる理由は、伝わるまでの時間差、商品コードの不一致、引当タイミングの違いの3つです。ツールを入れて消えるのは1つ目だけで、残る2つは決めごとの問題です。

売り越しは「反映が遅いから」と思われがちです。半分は当たっていますが、時間差だけが原因だった案件は半分もありません。

• 伝わるまでの時間差。 楽天で1個売れてから、Amazonと自社ECの在庫が書き換わるまでの空白です。この間に注文が入ると売り越します。
• 商品コードの不一致。 同じ商品が楽天では「A-100-BK-M」、Amazonでは「A100BKM」、自社ECでは「a100-bk-m」で登録されている状態です。機械はこれを別物として扱います。
• 引当タイミングの違い。 カート投入時に確保するチャネルと、注文確定後に引くチャネルが混ざると、同じ在庫を二重に数えます。

1つ目は一元管理システムで大きく縮みます。ところが2つ目と3つ目は、どのシステムを買っても自動では解決しません。決めるのは人の側だからです。自社ECとモールの役割分担から整理したい方は、自社ECとモール出店の違いもご覧ください。

03チャネル数別｜売り越しの発生率と訂正対応の工数

要点： 担当案件の集計では、売り越し率はチャネル1つで0.3%、3つで2.4%、5つ以上で4.9%でした。訂正と謝罪にかかる時間は、チャネル数より速いペースで増えます。

出典：ZenWeb Japanが制作・改修を担当したECサイトの集計（日本国内、2024〜2026年）。数値は各群の中央値。

注目したいのは訂正対応の伸び方です。チャネルが1つから3つで受注件数は約4倍ですが、訂正の時間は約9倍になります。謝罪、代替品の提案、返金、モールへの報告と、1件あたりの後始末が重いからです。

売り越し1件の後始末は、通常の受注処理およそ20件分の時間を奪います。

04最初に決めるのはツールではなく商品コードの対応表

要点： 在庫の一元管理の土台は、社内で1つに決めた商品コード（親SKU）と各チャネルのコード（子SKU）をつなぐ対応表です。ここが曖昧なままだと、システムは正しく動いたうえで間違った数を配ります。

うまくいかない案件には共通点があります。商品コードの決め方が担当者ごとに違うのです。楽天はセール名を入れ、Amazonは型番のまま、自社ECは自動採番に任せている。この状態でつなぐと、同じ商品が3つの別商品として登録されます。先に決めたいのは次の4点です。

1. 親SKUの採番ルールを1本にする。 商品分類・型番・色・サイズのように意味の順番を固定し、あとから枝番を足せる余白を残します。
2. 子SKUとの対応表を1か所で持つ。 表計算ソフトで始めて構いませんが、更新する人と場所を1つに決めます。二重管理が始まると必ず崩れます。
3. セット商品の数え方を決める。 単品と3個セットを同時に売るなら、どちらを正とし、もう一方をどう計算するかを決めます。
4. 項目選択肢別の在庫を使うか決める。 楽天市場では色やサイズを項目選択肢で持てますが、他チャネルと持ち方が揃っていないと対応表が破綻します。

この対応表はシステムを乗り換えても残ります。ECサイトのリニューアルでも引き継げる資産です。逆に、対応表がないまま入れ替えても問題はそのまま残ります。

05在庫ズレの原因別｜発生率と気づくまでの時間

要点： 在庫ズレの3件に1件は反映の時間差ですが、気づくまでの時間で見ると商品コードの不一致が深刻です。時間差は平均22分で解消し、コードの不一致は平均3.5日そのままになります。

出典：ZenWeb Japanが対応した在庫ズレ事例の分類集計（日本国内、2024〜2026年）。発生率は全事例に占める割合。

「防げる」に分類した5つの合計は57%です。半分以上は決めごとを整えるだけで消えます。ここを飛ばすと、下がるのは34%だけです。コードとルールの整備は、ECサイトの制作の初期に済ませるのが理想です。

06引当のタイミングを全チャネルで揃える

要点： 在庫を引くタイミングはカート投入時・注文確定時・入金確認時の3通りです。チャネルごとにバラバラだと同じ在庫を二重に見せます。注文確定時に揃えるのが、多くの店舗で扱いやすい形です。

引当とは、注文の分の在庫を確保して販売可能数から差し引く処理です。どの時点で引くかで、売り越しの起きやすさと機会損失の大きさが変わります。

モール側は注文確定時に引く仕様が基本です。自社ECだけ入金確認時にすると、振込を待つ間の在庫が全チャネルに公開されたままになります。ここで売り越しが集中します。

引当は自動化の出発点にあたります。受注後の流れまで整えたい方は、ECの受注から出荷までを自動化する仕組みもご覧ください。

07連携方式は4つ｜手動・CSV・一元管理・API直結

要点： つなぎ方は4通りです。月100件までは手動、400件まではCSVの定期取り込み、3,000件までは一元管理システム、それ以上や特殊な商材ではAPI直結の開発が合います。

向き不向きを、ご相談の多い順に整理します。

• 手動更新。 各モールの管理画面を開いて数を直します。2店舗までで動きの遅い商材なら成立しますが、セールが始まると破綻します。
• CSVの定期取り込み。 在庫一覧を出力し、決まった時間に各チャネルへ取り込みます。安く始められますが、間隔のぶんだけ売り越しが残ります。
• 一元管理システム。 受注・在庫・商品情報をまとめて扱う既製サービスです。多くの店舗で費用と効果の釣り合いが最もよい選択肢になります。
• API直結・自社開発。 各チャネルのAPIと基幹システムを直接つなぎます。反映は最速ですが、仕様変更への追随を自分たちで抱えます。

カートの種類でも選べる範囲が変わります。Shopifyはアプリで足りることが多く、費用感はShopify構築の費用と制作会社に頼める範囲にまとめました。EC-CUBEならEC-CUBEのカスタマイズで連携そのものを作り込めます。倉庫や基幹システムとのつなぎ方はECサイトの在庫連携で扱っています。

08連携方式別｜反映時間・費用・向く規模の比較

要点： 担当案件では、在庫の反映時間は手動更新で数時間、CSV定期で1〜6時間、一元管理システムで5〜30分、API直結で1〜5分でした。売り越し率は方式を上げるごとに半分近くまで下がります。

出典：ZenWeb Japanが導入・開発を担当した在庫連携案件の集計（日本国内、2024〜2026年）。費用は税別の目安。

費用差は大きく見えますが、判断材料は月額だけではありません。チャネル4つの店舗では訂正対応に月24時間、人件費なら月5万円前後かかっていました。一元管理システムの月額は、多くの場合この範囲に収まります。

09反映の遅れはゼロにできない｜バッファで吸収する

要点： どの方式でも、在庫が全チャネルに行き渡るまでの遅れは残ります。最後の数個を売り切ろうとせず、残りが少なくなった時点で販売を止める設計にしておきます。

反映を速くする話が多いのですが、遅れはゼロにできません。モール側の受付制限もあり、通信が失敗することもあります。現実的なのは遅れても事故にならない設計です。効果が大きかったのは次の3つでした。

1. 販売停止のしきい値を決める。 残り2個を切ったら全チャネルで止めます。売り越しの多くは最後の1〜2個の取り合いで起きています。
2. 回転の速い商品だけ間隔を詰める。 全商品を等しく速く更新する必要はありません。上位2割に絞れば負荷も費用も抑えられます。
3. 失敗を必ず知らせる。 静かに失敗する仕組みが一番危険です。通知と、手で再実行できる導線を用意します。

倉庫の在庫と突き合わせる仕組みまで作るなら、物流システム開発の事例の入出庫管理とあわせて考えると設計が定まります。

10在庫は分ける？共有する？｜配分の考え方

要点： チャネルごとに割り振る配分型は安全ですが在庫が余ります。共有型は使い切れますが、反映の遅れがそのまま売り越しになります。分け目は商品の回転の速さです。

在庫100個を楽天に40個・Amazonに40個・自社ECに20個と分けるのが配分型、100個をそのまま3チャネルに見せるのが共有型です。「主力だけ配分型に」とよく言われますが、主力かどうかを感覚で決めると外れます。

判断は掛け算で足ります。反映にかかる時間 × 1時間あたりの販売数が1個を超えたら配分型です。反映30分で1時間に3個売れるなら1.5個。この間に他チャネルで注文が入れば売り越します。

• 配分型。 掛け算が1を超える商品、セール中、発売直後。売り越しが起きにくく、チャネル別の売れ行きも読めます。
• 共有型。 1に届かない定番商品。在庫を寝かせずに済みます。

配分型にした商品は週1回、割り振りを見直してください。放っておくと片方だけ欠品し、片方が余ります。毎月決まった数が出る定期購入・サブスクECなら、配分型でも在庫が余りにくくなります。

11導入前後の12か月｜売り越し率と工数の推移

要点： 4チャネルの店舗で在庫の一元管理を導入したところ、売り越し率は3.2%から12か月で0.5%になりました。ただし最初の1か月はほぼ変わらず、効果が出たのは商品コードを整理した2か月目からです。

出典：ZenWeb Japanが在庫連携を担当したECサイト1件の推移（日本国内、2025年4月〜2026年3月）。

受注件数は12か月で2.2倍、訂正と棚卸しの工数は21時間から5.5時間に減りました。件数が増えても後始末は増えない状態を作れたのがこの案件の成果です。

12自社EC側で作り込む3か所

要点： モール側の仕様は変えられないので、手を入れられるのは自社ECです。在庫の見せ方、カートでの再確認、注文確定時の押さえ方。この3か所で売り越しは目に見えて減ります。

モールの仕様は変えられません。だからこそ自社EC側で吸収する価値があります。

• 在庫の見せ方。 残数を出さず、「残りわずか」「在庫あり」の2段階にします。数字を出すと、遅れがそのまま誤情報になります。
• カートでの再確認。 購入手続きに進む直前でもう一度在庫を確認し、放置された注文を止めます。
• 注文確定時の押さえ方。 在庫を引いてから決済に進みます。決済してから引くと、失敗したときに戻す処理が要ります。

在庫表示をどの画面のどこに置くかは、作り始める前に固めると手直しがありません。進め方はワイヤーフレームの作り方、必要な機能の全体像はECサイトに必要な機能一覧にまとめました。在庫を絞って売る場面では、ECサイトのレビュー機能のような後押しも効きます。

13入れたのに減らない｜よくある3つの失敗

要点： 効果が出ない原因は、手作業の併用、対応表の放置、例外商品の増殖の3つに集約されます。いずれもシステムではなく、運用のルールの問題です。

「思ったほど減らない」とご相談をいただくとき、たいていは次のどれかです。

1. 急ぎのときだけ手で直す。 セール中に管理画面を直接いじると、次の自動更新で上書きされます。そこから在庫が狂い始めます。
2. 対応表を更新せず新商品を足す。 新商品だけ連携から漏れ、そこに注文が集中します。追加時のチェックが工程に入っていないケースです。
3. 例外商品が増えていく。 「この商品だけ手動で」を認めるたびに自動化されない在庫が増え、半年後には半分が例外ということも起こります。

共通するのは、システムではなく決めごとを守れる形にしていない点です。手作業が残り続ける構図は、Excel業務のシステム化で起きることとよく似ています。

14既製サービスと開発の分かれ目

要点： 一般的な物販なら既製の一元管理サービスで足ります。開発が必要になるのは、基幹システムとつなぐ場合、在庫の数え方が独自な場合、卸や実店舗も同じ在庫を使う場合の3つです。

ご相談の8割は既製サービスの設定を詰めれば解決します。開発をご提案するのは次のようなときです。

• 基幹システムが在庫の正を持っている。 販売管理や生産管理が正なら、そこから各チャネルへ配る仕組みが要ります。
• 数え方が特殊。 量り売り、ロット管理、賞味期限別の引当など、既製サービスの前提に当てはまらない場合です。
• 販路がECだけではない。 実店舗や卸も同じ在庫を使うなら、ECの外まで見た設計が必要です。

仕組みそのものを作る場合の費用感は在庫管理システムの開発、サイト構築費用と合わせて考えるならECサイト構築費用の内訳と相場をご覧ください。卸取引まで含めるならBtoB向けECサイトの構築の考え方が近く、依頼先の比較はECサイト制作会社の選び方にまとめています。

15まとめ｜在庫の一元管理を進める5つの手順

要点： 売り越しの記録を集め、商品コードの対応表と引当ルールを決めてから方式を選ぶ。この順番を守ることが、費用をかけずに売り越しを減らす近道です。

最後に、お勧めしている進め方をまとめます。

1. 直近3か月の売り越しを数える。 何件、どのチャネルで、どの商品だったかを一覧にします。原因の見当をつける材料になります。
2. 親SKUと子SKUの対応表を作る。 社内の商品コードを1本に決め、各チャネルとの対応を1か所にまとめます。
3. 引当のタイミングを注文確定時に揃える。 自社ECだけ違う仕様になっていないかを確認し、揃えます。
4. 受注件数に合う連携方式を選ぶ。 月400件まではCSV定期、3,000件までは一元管理システム、それ以上はAPI直結の開発を検討します。
5. 販売停止のしきい値と通知を設定する。 残り2個で止める、更新が失敗したら知らせる。この2つを最後に必ず入れてください。

在庫の一元管理は、一度整えれば店舗を増やすたびに効果的です。ECサイトの制作と改修では、設計から実装まで一貫してお引き受けしています。

16よくある質問

要点： 在庫の一元管理について、よくいただく質問にお答えします。検討を始める規模、費用の目安、反映の速さ、カートを変えずに進められるか、実店舗も含められるかの5点です。

1. 在庫の一元管理は、何店舗くらいから検討すべきですか

3店舗、または月500件を超えたあたりが目安です。担当案件では3チャネル目を開いた月から売り越しの相談が増えました。2店舗でもセールが多いなら早めの検討をおすすめします。

2. 在庫の一元管理にはどのくらいの費用がかかりますか

既製の一元管理サービスなら初期20〜80万円、月額1〜8万円が中心です。基幹システムとのAPI直結まで作るなら150〜500万円です。いずれも税別で、商品数とチャネル数によって変わります。

3. 在庫はどのくらいの速さで反映されますか

既製の一元管理サービスで5〜30分、API直結の開発で1〜5分が目安です。ゼロにはできないので、残りわずかで販売を止める設定も併せて入れておくと安全です。

4. いまのカートを変えずに在庫連携だけできますか

できます。ご依頼の多くは、いまの自社ECとモールはそのままに、在庫の受け渡しだけを整える形です。カートの乗り換えはデータ移行が伴い、費用も期間も大きくなります。

5. 実店舗の在庫も同じ仕組みに含められますか

含められます。ただしレジと在庫がつながっていることが前提です。つながっていなければ、店舗分を取り置き、EC側に見せない形から始めるほうが安全です。