在庫・注文連携

次のような状態に心当たりがあれば、このワークフローが効きます。

• 在庫数の更新が手作業で、タイムラグにより売り越しが起きる
• 受注データを CSV で何度も往復させている
• 在庫切れの商品が、販売され続けてしまう
• 異常値（マイナス在庫・急な変動）への気づきが遅れる

処理は大きく 5 つの工程に分かれます。最初はすべてを自動化せず、1 と 2 の工程だけをつなぐところから始めるのがおすすめです。

各工程を担うツールの例と、選ぶときのポイントです。同じ役割は、無料ツールや既存の業務システムで置き換えられます。

※ ツール名は一般的な選択肢の例です。特定製品の推奨ではありません。

1 つの業務・1 つのチームを対象に、この順で進めます。各ステップの「完了条件」を満たしてから次へ進むと、手戻りが減ります。

1. 商品コードの対応表を作る

   EC と在庫システムで商品コードの体系が違うことが、最大の障害です。まず対応表（マッピング）を作り、名寄せできない商品を洗い出します。

   完了条件：すべての商品に、両システムのコードが対応づいている

2. 同期の方向と頻度を決める

   「在庫数は在庫システムが正」「価格は EC が正」のように、項目ごとに正となるシステムを決めます。頻度は、在庫の回転速度に合わせます。

   完了条件：項目ごとの「正」のシステムが決まっている

3. 冪等な更新を組む

   同じイベントを二重に処理しても、結果が変わらないようにします。注文 ID や更新日時で、処理済みかどうかを判定します。

   完了条件：同じイベントを 2 回流しても、在庫数が変わらない

4. 異常検知のルールを入れる

   マイナス在庫、1 日の変動が平均の 5 倍以上、更新が止まっている、といった条件でアラートを出します。

   完了条件：テスト用の異常データで、アラートが出た

5. 通知と対応フローを決める

   アラートの通知先と、一次対応（販売停止・手動修正）を決めておきます。

   完了条件：通知先と対応手順が、明文化されている

導入時に実際に起きやすいつまずきと、その対処です。先に知っておくと回避できます。

運用に乗せたあと、月に一度はこの項目を確認してください。1 つでも外れていると、自動化が「使われない仕組み」になっていきます。

• 商品コードの対応表が最新で、突合済みである
• 項目ごとに「正」となるシステムが決まっている
• 同期処理が冪等になっている
• API 制限と再試行の方針が決まっている
• マイナス在庫などの異常で、アラートが飛ぶ
• アラートの一次対応手順が決まっている
• 同期の実行ログが残っている

そのままコピーして、[ ] の中を自社の情報に置き換えてください。いずれも「推測させない」「根拠を明示させる」制約を入れています。

次の在庫同期ログから、異常と思われる箇所を特定し、担当者が 5 秒で判断できるように要約してください。

【出力形式】
- 深刻度：高／中／低
- 対象：商品コードと商品名
- 何が起きたか：1 文
- 推奨アクション：1 文

推測で原因を断定せず、ログに基づく事実のみを書いてください。

【同期ログ】
[ここにログを貼り付け]

次の 2 つの商品リストは、同じ商品を別のコード体系で管理しています。表記の類似から、同一商品と考えられる組み合わせを候補として挙げてください。

出力は表形式で、列は「EC 側コード」「在庫側コード」「確信度（高／中／低）」「判断理由」としてください。確信度が低いものは、必ず「低」と明記してください。

【EC 側】
[ここにリスト]

【在庫側】
[ここにリスト]

※ 出力は必ず人が確認してください。数値・固有名詞の誤りは、自動では検出できません。

理解を深めたい用語は、AI 用語辞典の詳細ページへ。定義・仕組み・出典をまとめています。

• AI OCR
• トークン化
• データ前処理
• AI推論
• レイテンシ
• AIシステム
• クラウドAI
• AIエージェント