はじめに
楽天、Amazon、Yahoo!ショッピング、自社ECを並行して運営していると、「在庫は残っているはずなのに、注文が入ってしまった」という場面が出てきます。そのたびに在庫連携ツールの設定を疑い、設定を直し、また別の日にずれる。この繰り返しに心当たりのある経営者の方は多いと思います。
ただ、在庫のずれをゼロにする前提で考えると、判断を誤りやすくなります。ずれの一部は、連携の仕組み上どうしても起きるものだからです。仕組みで起きるずれと、運用で防げるずれを分けないまま対策を打つと、ツールを入れ替えても同じことが起きます。
この記事では、ずれの原因を2つに分けたうえで、「売り越しをどこまで許すか」という許容ラインの決め方を整理します。なお、ここで扱う仕様はベンダーや各社の公開ページの記述を読んで整理したもので、自社の環境での動作確認はしていません。そのため、実挙動は自社で確かめてください。
原因1: 連携に時間差がある（仕組みの問題）
1つ目は、在庫の反映に時間差があることです。ある在庫連携ツールの紹介ページ（楽天のサービス紹介に掲載されている助ネコ）には、複数ECの在庫を5分おきに自動連動し、実在庫とは別にモールへ出す在庫数を設定できる、と書かれています（紹介ページ）。ベンダーが掲載した紹介ページの記述で、あくまで一例です。特定のツールをすすめる意図はありませんし、料金には触れません。
ここで注目したいのは、特定の製品の良し悪しではなく、間隔を置いて同期する方式であれば、同期の合間に入った注文は構造的に売り越しうるという点です。残り1点の商品に、楽天とAmazonでほぼ同時に注文が入れば、どちらの連携も追いつく前に2件が成立します。これは設定ミスではなく、仕組みの性質です。
この種のずれは、間隔を短くすれば減りますが、ゼロにはなりません。逆に言えば、人気商品や在庫の少ない商品ほど起きやすく、在庫が潤沢な商品ではほとんど起きません。どの商品で起きているかを見るだけでも、原因の見当はつきます。
実在庫とは別にモールへ出す在庫数を設定できる機能は、この構造への対処としてよく使われる考え方です。たとえば実在庫が5点なら、モールには3点だけ見せる、といった持ち方です。残りは売り越し防止の余白になりますが、その分、機会損失（買えるのに売り切れ表示になる）も生まれます。余白をいくつにするかは、次の節の許容ラインで決めることになります。
原因2: 上書きで、他モールの販売分が巻き戻る（連携の作りの問題）
2つ目は、在庫の更新方法に由来するずれです。Yahoo!ショッピングの在庫更新API（setStock）の仕様書には、数値だけを渡すと在庫をその値に置き換え、先頭に+または-を付けると加減算になる、と書かれています。1リクエストで更新できるのは最大1000コードです（setStock）。ただし、仕様書の中には読み取りにくい記述もあるため、実際の挙動は確認が必要です。
この仕様から導ける考え方は次のとおりです。連携が「置き換え」で在庫を送る作りだと、連携が在庫を読んでから書くまでの間に他モールで売れた分を、後から書き込んだ値が巻き戻してしまう可能性があります。加減算で送る作りなら、そのリスクは小さくなります。どちらで更新しているかは、使っているツールや自作の連携の中身によって違います。
仕組みとして上書きを防ぐ手段が、プラットフォーム側に用意されていることもあります。Shopify の Admin GraphQL API（2026-01）では、在庫更新に changeFromQuantity が追加されました。更新する側が「現在数はこうなっているはず」と指定し、実際と違えばエラーにして、同時更新による上書きを防ぐ仕組みです（Shopify開発者向け変更履歴、2025-12-12）。
ただし、手段が存在することと、自社の連携がそれを使っていることは別の話です。使っている連携ツールや自作の仕組みが、置き換えで送っているのか、加減算なのか、こうした保護を使っているのか。これは仕様書だけでは分からず、ベンダーか実装した人に確認するしかありません。
どこまでが仕組みで、どこからが運用ミスか
2つの原因を踏まえると、ずれは次のように切り分けられます。
- 原因1にあたるもの: 在庫が少ない商品で、短い間隔のうちに複数モールから注文が入った。連携間隔の範囲内で起きており、仕組みの限界に近い
- 原因2にあたるもの: 売れた分が在庫に反映されたあと、元に戻っている。同期のたびに在庫数が増える方向にずれる。連携の更新方法を疑う
- 運用ミスにあたるもの: 入荷・返品・棚卸しの数字が連携側に入っていない、手で在庫を直したが連携に反映されていない、セット商品や商品コードの対応が崩れている
運用ミスは、連携の間隔を詰めても直りません。商品コードの対応表や入荷時の入力手順といった、社内のルールの話になります。まず「いつ、どの商品で、どの向きにずれたか」を記録することが、切り分けの出発点です。数か月分の売り越し発生日と商品、モールを並べるだけで、原因1に偏っているのか、原因2や運用ミスが混ざっているのかが見えてきます。モール間で売上の数字が合わないという別の悩みも、同じ手順で整理できます（楽天とAmazonで売上の数字が合わないとき）。
許容ラインの決め方
ずれがゼロにならないなら、決めるべきは「どこまで許すか」です。考え方は次の掛け算です。
1日あたりの売り越し件数 × 1件あたりの対応コスト
1件あたりの対応コストには、お客様への連絡とお詫びにかかる時間、キャンセル処理の手間、モールの評価への影響、場合によっては代替品の手配や送料の負担が含まれます。金額は店舗ごとに違うので、この記事では数字を挙げません。自社で直近の売り越しを数件取り上げ、実際にどれだけ時間と費用がかかったかを書き出すと、おおよその単価が出ます。
一方で、売り越しを減らす手段にも費用があります。モールに出す在庫を絞る（余白を持つ）と、売れたはずの機会を失います。連携間隔を短くする、ツールを入れ替える、連携を作り直すといった対策には、導入や開発の費用がかかります。
判断は、2つの比較になります。
- 売り越しの対応コスト（件数 × 単価）が、対策の費用や機会損失より小さいなら、許容して運用で吸収するほうが合理的なことがあります
- 対応コストが大きいなら、対策に費用をかける理由があります。そのときも、まず費用の小さい順（余白の設定、運用ルール、連携設定の見直し、仕組みの作り直し）に試すほうが、無駄が出にくくなります
許容ラインは「月に何件まで」「この商品群では1件も許さない」といった形で、商品群ごとに分けて決めるのが現実的です。単価の高い商品や限定品は厳しく、在庫が潤沢な定番品は緩く、と差をつけられます。
やらなくてよい場合
在庫のずれ対策に、手や費用をかけなくてよい場合もあります。
- 1つのモールだけで売っている場合。複数モール間の同期という問題が、そもそも生じません。
- 1日の注文が少なく、手作業で足りている場合。注文のたびに在庫を見られる規模なら、連携の仕組みに費用をかけるより、手で確認するほうが安くつくことがあります。
- 取り扱いが受注生産や取り寄せ中心で、在庫を持たない場合。売り越しではなく納期の問題になります。
- 売り越しがほとんど起きていない場合。直近の数か月で数えて、対応コストが気にならない水準なら、優先度は下がります。
逆に、複数モールで同じ在庫を売っていて、人気商品の在庫が薄く、売り越しの対応に毎週時間を取られているなら、見直しを検討する目安になります。
外注・ツール導入前に確認する質問
連携ツールの導入や作り直しを頼む前に、次の質問に答えられる状態にしておくと、見積もりの話がずれにくくなります。ベンダーや開発会社にも、同じ内容を聞いてみてください。
- 在庫の反映は何分おきか。その間に入った注文は、どう扱われるのか
- 在庫は「置き換え」で送るのか、「加減算」で送るのか。他モールで売れた分を巻き戻さない作りになっているか
- 実在庫とは別に、モールごとに出す在庫数を設定できるか
- 入荷、返品、棚卸し、手での在庫修正は、どこから入力して、どう連携に反映されるか
- 商品コード（SKU）の対応表は誰が管理するか。セット商品や新商品の追加時の手順はあるか
回答が曖昧だったり、「実際に動かしてみないと分からない」と言われたりした場合は、それ自体が判断材料です。期間や費用は、連携するモールの数、商品数、既存システムの状況といった前提で変わるので、一律には言えません。外注するか自社でやるかの全般的な考え方は、別の記事にまとめています（ECのデータ整備、外注か内製かの判断）。
自社で進めるか、任せるか
最初の一歩は、仕組みを変える前の記録です。直近の売り越しについて、日付、商品、関係したモール、対応にかかった時間を書き出してください。それだけで、原因1が多いのか、それ以外が混ざっているのか、許容ラインをどこに置けるかの見当がつきます。
ここまでを自社でやるのが難しければ、記録の取り方の整理や、連携の作りを確認する部分だけを単発で手伝うことができます。単発のご相談はこちら、お問い合わせはこちらのフォームから受け付けています。