クロスモール在庫連携チェック

概要

クロスモール（および類似の多モール在庫連携SaaS）で発生する在庫ズレを、SKU紐付け表・基準在庫・各モール在庫・受注ログ・倉庫実在庫の突合で検出する。連携間隔（30〜60分）の隙間に起きるダブル販売（オーバーセール）、SKU紐付けの重複／表記ゆれ／未紐付け、セット商品の構成情報設定漏れ、バリエーション親子の二重カウント、マイナス在庫の継続出力、棚卸との乖離など、典型10パターンを優先度別に分類する。

修正案は「即時対応・24h以内・週次・月次」で出し、安全在庫設定・1モール集約・リアルタイム連携への移行など再発防止策まで提示する。

★最重要原則

「連携間隔の隙間」と「SKU紐付けの破綻」が2大事故源。 連携間隔30〜60分の中で同時受注が起きるとダブル販売、紐付け表が壊れていればどれだけ綿密に連携設定を組んでも在庫は合わない。最初に「紐付け表の健全性」を検査し、次に「基準在庫と各モール在庫の差分」を見る。在庫を商品マスタCSVで直接編集する運用は事故源なので絶対に推奨しない。

知識ベース

詳細は references/ を参照：

• 在庫ズレ10パターン（タイミング差ダブル販売／SKU紐付けミス／手動上書き／セット連動失敗／受注取込遅延／バリエーション親子不整合／マイナス在庫／仕入入荷遅延／返品戻し漏れ／棚卸乖離）：references/inventory-discrepancy-types.md
• SKU紐付けマトリクスの構築・重複検出・表記ゆれ正規化：references/sku-mapping-matrix.md
• ダブル販売（オーバーセール）のメカニズムと安全在庫設計・1モール集約・リアルタイム連携：references/oversell-prevention.md
• セット商品（組商品）の在庫整合・構成情報の検査：references/set-product-inventory.md
• 連携タイミング・棚卸・業務フロー・緊急時対応：references/sync-timing-operations.md
• 実例集（紐付け重複／ダブル販売事故／セット計算ミス）：references/examples.md

要点（本ファイルに残す）：

在庫ズレの優先度

優先度	種類
即時	ダブル販売（売り越し）、紐付け重複
24h以内	マイナス在庫継続、手動上書き事故、受注取込連続失敗
週次	バリエーション親子不整合、セット連動失敗
月次	倉庫実在庫との乖離（棚卸）

安全在庫の目安

商品特性	安全在庫
日次10個以上売れる高速回転	2〜5
週次10〜30個の中速	1〜2
月次1〜10個の低速	0〜1
在庫1個の希少品	0または1モールに集約
高単価商品	1〜2
受注後発注（予約）	設定不要

連携間隔の現状

• クロスモール在庫連携：30〜60分（上位プランで5〜15分、リアルタイムプランあり）
• 受注取込：楽天数分〜10分、Amazon SP-API数分、Yahoo!数分、Shopify即時〜数分
• ネクストエンジン在庫連携：約10分間隔（参考）

処理フロー

Step 1：入力データの確認

ユーザーから受け取るべきデータ：

• クロスモール基準在庫CSV（マッピング表含む）
• 各モールの在庫CSV（楽天 normal-item.csv／Amazon在庫レポート／Yahoo!商品CSV／Shopify products.csv）
• 直近30日のダブル販売・キャンセル件数（あれば）
• セット商品の構成情報（あれば）

不足している場合は「仮定」「不足情報」「確認したいこと」を分けて、急ぎなら仮定ベースで暫定判定を出す。

Step 2：SKU紐付け表の健全性検査

references/sku-mapping-matrix.md を使い：

• 重複紐付け（1モールSKUが複数基準SKUに紐付き）= 事故源、即修正
• 未紐付け（基準のみ／モールのみ）= 未出品 or 取込忘れ、要確認
• 表記ゆれ（大文字小文字／全半角／ハイフン種／末尾空白）= 正規化候補

Step 3：基準在庫 vs モール在庫の差分

各モールについて：

差分パターン	推定
モール在庫 = 基準在庫	正常
モール在庫 < 基準在庫	連携遅延 or 紐付けミスで減算先間違い
モール在庫 > 基準在庫	連携遅延 or モール側手動上書き
基準 < 0（マイナス）	ダブル販売事故
モール側だけ大きく違う	紐付け不一致／別商品連動

Step 4：セット商品の整合検査

references/set-product-inventory.md を使い、セット親（set_flg=1）の販売可能数を再計算：

セット親の販売可能数 = min(子在庫 / 構成数量)

• 構成情報が設定されているか
• 構成元SKUが基準マスタに存在するか
• セット親が独立在庫を持ってしまっていないか
• 計算値とモール表示値が一致するか

Step 5：バリエーション親子の検査

• バリエーション親に在庫が入っていないか（二重カウント源）
• 子の合計または min(子) が親の表示値と整合するか
• 子1つでも在庫切れがあれば自動非公開設定があるか

Step 6：ダブル販売リスク評価

references/oversell-prevention.md で：

• 日次販売数 × 連携間隔 から動的安全在庫を試算
• 在庫1個の高単価／希少商品は1モール集約 or リアルタイム連携を提案
• マイナス在庫の継続発生有無

Step 7：修正方針と再発防止策

• 即時：ダブル販売の顧客対応／マイナス在庫の手動修正／紐付け重複の解消
• 24h以内：紐付け表の正規化／手動上書き事故の整理
• 週次：セット構成情報の総点検／バリエーション親子の設計見直し
• 月次：物理棚卸 vs システム在庫の照合／連携プラン見直し

実例

例1：紐付け重複によるダブル販売

楽天SKU "TSH-001" → 基準SKU [TSH-001, TSH-001-OLD]

楽天で1個売れたとき、どちらの基準SKUを減らすか不定。クロスモール側のマッピングを見直し、廃番側の TSH-001-OLD のマッピングを解除する。

その他の実例は references/examples.md（紐付け重複／在庫1個多モール販売／セット構成漏れ）参照。

出力フォーマット（必須）

# クロスモール在庫連携 検証結果

## 0. 検査対象
- 連携モール：<楽天／Amazon／Yahoo!／Shopify／他>
- 検査商品数：N件
- データ取得時刻：

## 1. サマリ
| 区分 | 件数 |
|---|---|
| 紐付け重複（即時） |  |
| マイナス在庫（即時） |  |
| ダブル販売疑い（即時） |  |
| 未紐付け（24h） |  |
| 表記ゆれ（週次） |  |
| セット計算不整合（週次） |  |
| 棚卸乖離（月次） |  |

## 2. 即時対応（事故源）
| 種別 | 該当SKU | モール | 詳細 | 対応 |
|---|---|---|---|---|
| 紐付け重複 | (1モールSKU) | 楽天 | 基準[X, Y]が紐付き | 廃番側マッピング解除 |
| マイナス在庫 | (基準SKU) | — | -1継続出力 | 0クランプ＋原因調査 |
| ダブル販売 | (基準SKU) | 楽天/Amazon | T+5min同時受注 | 顧客連絡＋安全在庫設定 |

## 3. 24h以内対応
| 種別 | 該当 | 対応 |
|---|---|---|
| 未紐付け（基準のみ） |  | 未出品確認 or マッピング追加 |
| 未紐付け（モールのみ） |  | 取込設定確認 |
| 手動上書き事故 |  | 連携停止→修正→再開フロー徹底 |

## 4. 週次対応
| 種別 | 該当 | 対応 |
|---|---|---|
| 表記ゆれ |  | 正規化（大文字／半角／ハイフン統一） |
| セット計算不整合 |  | 構成情報の修正 |
| バリエーション親在庫持ち |  | 親在庫0設計に修正 |

## 5. 安全在庫の見直し提案
| SKU | 現安全在庫 | 日次販売 | モール数 | 推奨安全在庫 | 根拠 |
|---|---|---|---|---|---|

## 6. 再発防止運用
- 紐付け検査：月次
- 物理棚卸 vs システム：月次
- 連携失敗ログ：日次
- マイナス在庫アラート：即時通知
- 高単価／希少品の1モール集約 or リアルタイム連携検討

## 7. 確認チェックリスト
- [ ] CSVバックアップ取得済
- [ ] 紐付け重複を全件解消した
- [ ] マイナス在庫を0クランプし原因を記録した
- [ ] セット親が独立在庫を持つ設計になっていない
- [ ] バリエーション親が在庫を持たない設計になっている
- [ ] ダブル販売発生時の顧客対応フローが整備されている

品質ゲート

• 紐付け重複の検出を「同一モールSKU→複数基準SKU」方向で実施している
• 表記ゆれ（大文字小文字／全半角／ハイフン種／末尾空白）の正規化後一致で検出している
• セット親の販売可能数を min(子在庫 / 構成数量) で計算している
• バリエーション親が在庫を持つ設計を「事故源」として警告している
• 安全在庫を「日次販売×連携間隔×モール数」で動的に提案している
• マイナス在庫を「0クランプ＋原因調査」のセットで扱っている
• 商品マスタCSVで在庫を直接編集する運用を推奨していない

エッジケース

• 連携プランで間隔差：標準30〜60分／上位5〜15分／リアルタイム。事故頻度でプラン見直しを提案
• Amazon FBA：在庫がほぼリアルタイム反映、ダブル販売は基本起きないが他モール側の遅延でズレる
• バラ売りとセット売りで子在庫を奪い合う：予約在庫の確保 or stock_goods_id分離
• マイナス在庫をそのままモールに送る設定：クロスモール側で0クランプ設定を確認
• 連休前後の集中受注：通常時の連携間隔では事故率が上がる、安全在庫を一時的に積み増す

注意事項

• 在庫変更は クロスモールまたは倉庫マスタのみ で行うのが原則。モール側で直接編集すると次回同期で上書きされる
• 仕入入荷／返品／キャンセルは登録漏れに注意。日次の整合ログを確認
• ダブル販売事故時はモール側のキャンセル区分（販売者起因／購入者起因）でアカウント健全性が変わる
• クロスモール／類似SaaSの仕様は変更されることがある。最新の公式ヘルプを確認
• 顧客個人情報・受注番号は出力に含めない（SKU単位での記載に留める）

references/ 一覧

• references/inventory-discrepancy-types.md — 在庫ズレ10パターンと原因・対応
• references/sku-mapping-matrix.md — SKU紐付けマトリクスの構築・重複検出・正規化
• references/oversell-prevention.md — ダブル販売メカニズム・安全在庫設計・1モール集約
• references/set-product-inventory.md — セット商品の在庫整合・構成情報検査
• references/sync-timing-operations.md — 連携タイミング・棚卸・業務フロー・緊急時対応
• references/examples.md — 紐付け重複／ダブル販売／セット計算ミスの実例集

参考公式情報源

• クロスモール公式ヘルプ「在庫連携設定」「SKU紐付け」「セット商品」
• 楽天RMS「商品データ一括登録」「在庫管理」
• Amazon Seller Central「在庫レポート」「SP-API 在庫API」
• Yahoo!ショッピング「商品データ仕様」「在庫管理」
• Shopify Admin API「Inventory」