投稿者 投稿日: カテゴリー EC×AI活用
このスキルを使うと、多モール在庫連携のズレと売り越しの原因を優先度別に特定できます。
楽天市場、Amazon、Yahoo!ショッピング、Shopifyに同じ商品を並べている店舗では、在庫連携ツールの設定が一度崩れると「楽天では在庫1なのにAmazonでは売れてしまった」という売り越し（ダブル販売）が起きます。原因を探すためにSKUの紐付け表と各モールの在庫CSVを目で突き合わせ、半日つぶれた経験がある店長も多いはずです。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）が解説します。今回紹介する ALSEL Agent Skills の「crossmall-inventory-sync-checker」は、クロスモール などの多モール在庫連携SaaSで起きる在庫ズレを、典型10パターンに分類して検出するスキルです。紐付け表と在庫CSVを渡せば、どこから直すべきかが即時・24時間以内・週次・月次の4段階で整理されて返ってきます。
クロスモール在庫連携チェックスキルでできること
結論として、このスキルは「在庫ズレの原因特定」と「再発防止の運用設計」を一度に出してくれます。在庫連携チェックスキルとは、SKU紐付け表・基準在庫・各モール在庫・受注ログ・倉庫実在庫を突合して、在庫が合わない理由を分類するためのAIスキルのことです。
SKILL.md では、事故源の大半を「連携間隔の隙間」と「SKU紐付けの破綻」の2つと位置づけています。クロスモールの標準的な在庫連携間隔は30〜60分（上位プランで5〜15分、リアルタイムプランあり）とされ、この隙間に複数モールで同時に注文が入ると売り越しが発生します。一方、紐付け表そのものが壊れていると、どれだけ連携設定を詰めても在庫は合いません。そのためスキルは、まず紐付け表の健全性を検査し、次に基準在庫と各モール在庫の差分を見る順番で処理します。
検出対象は、タイミング差によるダブル販売、SKU紐付けミス、モール側の手動上書き、セット商品の連動失敗、受注取込の遅延、バリエーション親子の不整合、マイナス在庫、仕入入荷の登録遅延、返品戻しの漏れ、棚卸との乖離の10パターンです。楽天市場のRMS、AmazonのSP-API、Yahoo!ショッピング、Shopify の在庫API、自社倉庫の間の基準在庫整合に対応しています。
クロスモール在庫連携チェックの実際の使い方
使い方の結論は、「CSVを渡して、在庫がズレている状況を一言で伝える」だけです。Claude Code などスキルを読み込める環境で、「クロスモールの在庫ズレを調べて」「楽天とAmazonで在庫が違う」「売り越しが起きた原因を知りたい」「セット商品の在庫が合わない」といった言い方をすると起動します。
渡すデータは、クロスモールの基準在庫CSV（マッピング表を含む）、各モールの在庫CSV（楽天の商品CSV、Amazonの在庫レポート、Yahoo!ショッピングの商品CSV、Shopifyの商品CSV）、直近30日のダブル販売やキャンセル件数、セット商品の構成情報です。すべてそろっていなくても、スキルは「仮定」「不足情報」「確認したいこと」を分けたうえで、急ぎなら仮定ベースの暫定判定を出します。
処理は7段階です。入力データの確認のあと、紐付け表を検査し、1つのモールSKUが複数の基準SKUにつながっている「重複紐付け」を最優先で洗い出します。大文字小文字、全角半角、ハイフンの種類、末尾の空白といった表記ゆれも、正規化したうえで一致判定します。続いて基準在庫とモール在庫の差分を見て、マイナス在庫ならダブル販売事故、モール側だけ大きく違うなら紐付け不一致、というように原因を推定します。
セット商品については、セット親の販売可能数を「子在庫を構成数量で割った値の最小値」で再計算し、モール表示値と照合します。バリエーション親が独自に在庫を持っていないか（二重カウントの原因）も確認します。最後に、日次販売数と連携間隔から安全在庫を試算し、在庫1個の希少品や高単価品は1モールへの集約やリアルタイム連携を提案します。安全在庫の目安は、日次10個以上売れる高速回転品で2〜5個、週次10〜30個の中速品で1〜2個です。
出力は、検査対象、件数サマリ、即時対応、24時間以内対応、週次対応、安全在庫の見直し提案、再発防止運用、確認チェックリストの順で整理されます。顧客の個人情報や受注番号は出力に含めず、SKU単位で記載する設計です。
導入による業務インパクト
業務インパクトの結論は、在庫ズレの原因調査を「勘と目視」から「決まった順番の検査」に置き換えられることです。手作業で紐付け表と4モール分のCSVを突き合わせると、SKU数が数百を超えた時点で見落としが避けられません。スキルが重複紐付けやマイナス在庫を先に拾うため、担当者は修正と顧客対応に時間を使えます。
たとえば月に2〜3回売り越しが起き、そのたびに原因調査へ2時間ずつかけている店舗なら、調査工数だけで月4〜6時間を圧縮できる計算です（実際の削減幅はSKU数とデータの整い具合で変わります）。売り越しによる販売者都合キャンセルはモールのアカウント健全性にも響くため、再発を減らす価値は工数以上に大きいといえます。
注意点もあります。スキルは在庫の変更をクロスモールまたは倉庫マスタだけで行う原則を前提にしており、商品マスタCSVで在庫を直接書き換える運用は推奨しません。モール側で直接編集しても、次回の同期で上書きされるためです。また、クロスモールや類似SaaSの仕様は変わることがあるので、最終判断の前に公式ヘルプで最新の連携仕様を確認してください。モール間のCSV列の対応づけは別スキルの守備範囲で、うるチカラでは モール間CSVマッピングスキルの解説記事 で紹介しています。JANコードの検証が必要な場合は JANチェックデジット検証スキルの記事 もあわせて参考にしてください。
まとめ
クロスモール在庫連携チェックスキルは、3モール以上に同じ商品を出していて、売り越しや在庫の食い違いに毎月悩まされている事業者に向いています。一歩目として、直近で売り越しが起きたSKUを含む紐付け表と各モールの在庫CSVを用意し、「売り越しの原因を調べて」と依頼するところから始めてみてください。
参考文献
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
