棚札・POS・ECを同時にそろえる、値下げ実行の5点照合

値下げAIが利益率と在庫だけを見て価格を決めると、棚札は980円、POSは880円、ECは旧価格のままという事故が起きます。小売の価格・販促責任者向けに、提案を実行へ渡す前の「5点照合ゲート」を作ります。

値下げ案ではなく、実行可能な変更単位を作る

価格変更の対象は商品名ではなく、販売単位を識別するコード、店舗またはチャネル、適用期間の組み合わせです。GS1 Japanは、GTIN-13（JANコード標準タイプ）を一般消費財の消費者購入単位を識別する13桁のコードと説明しています。[1] 同じ商品名でも容量やセット数が違えば別対象として扱い、AIに曖昧な商品名から更新先を推測させません。

実行前に照合する5点は、①対象、②価格根拠、③適用期間、④反映面、⑤復旧条件です。消費者庁は、同一でない商品の価格や、実際と異なる・曖昧な価格を比較対照価格に使う二重価格表示は、不当表示に該当するおそれがあると示しています。[2] そのため「通常価格から20%引き」という文言だけでなく、比較価格の出所と販売履歴を証跡へ結び付けます。

コピーして使える価格変更要求

AIはproposed_priceと理由を提案できます。ただし、下記の必須項目を価格マスターと販促台帳から埋められない案は、実行キューへ入りません。

price_change:
  change_id: markdown-20261019-031
  item:
    gtin: "04912345678904"
    sku: "store-deli-250g"
  scope:
    stores: ["TKY-014", "TKY-021"]
    channels: ["shelf", "pos", "ec", "product_feed"]
  price:
    current: 980
    proposed: 780
    floor: 720
    currency: "JPY"
  comparison_price:
    value: 980
    evidence_ref: "price-history://store-deli-250g/90d"
    reviewed_by: "pricing-owner"
  window:
    starts_at: "2026-10-19T18:00:00+09:00"
    ends_at: "2026-10-20T21:00:00+09:00"
  preconditions:
    stock_at_least: 12
    margin_at_least: 0.18
    source_version: "price-master-8421"
  rollback:
    restore_price: 980
    deadline: "2026-10-20T21:10:00+09:00"

channelsは公開先の一覧であると同時に完了判定です。Google Merchant Centerは、商品データ、商品ページ、決済画面の金額と通貨を一致させ、価格変更後は最新値を送るよう求めています。[3] また、フィードと商品ページの更新時刻がずれることを価格不一致の原因に挙げています。[4] 外部フィードも「後で同期」ではなく同じ変更要求の一部にします。

5段階で提案を販売価格へ変える

1. 提案を固定する

AIの出力からGTIN、店舗、チャネル、開始・終了、提案価格、理由を抽出します。欠けた値を推測で補わず、担当者へ差し戻します。

2. マスターと履歴で照合する

価格担当者が対象コード、現行価格、下限価格、直近の販売履歴、販促契約を読みます。比較価格を表示する案は、履歴への参照と確認者がなければ停止します。

3. 反映計画を予約する

POS、EC、商品フィードへ同じchange_idを渡し、棚札の交換作業を店舗タスクにします。完全な同時更新が難しい場合は、顧客が購入できるPOSとECを先に合わせ、棚札完了まで対象売場の販売を保留する規則を決めます。

4. 開始直前に再判定する

実行ワーカーは、在庫、粗利下限、価格マスターの版、承認状態を再確認します。一つでも変わっていれば全チャネルを止めます。部分成功は再試行せず、成功面を記録して復旧担当へ渡します。

5. 購入経路で検証して戻す

テスト端末で棚札、POS、EC商品ページ、カート、外部フィードをGTIN単位で読み、金額、通貨、期間を照合します。終了時刻には通常価格へ戻し、同じ経路を再検証します。完了条件は、全反映面が同じ価格と期間を返し、監査ログに担当者、時刻、マスター版、読取値が残ることです。

仮想例：惣菜の当日値下げ

【仮想例】2店舗で250g惣菜の在庫が夕方に残り、AIが980円から780円への値下げを提案しました。担当者はGTINと店舗を固定し、販売履歴と粗利下限を確認します。18時にPOSとECは更新できましたが、店舗TKY-021の棚札タスクだけが未完了でした。

ゲートは全体を成功扱いにせず、TKY-021の売場を保留し、TKY-014だけを販売開始します。棚札を読み取って780円を確認した時点で二店目を開放します。21時の戻し処理でECだけ980円へ戻らなければ、EC販売を停止して復旧します。この例の出力は、店舗別の開始可否と未完了チャネルが入った変更記録です。

価格が一日中変わらず、棚札も外部フィードもなく、一つのレジだけを手動更新するという場合には向きません。照合の運用費が効果を上回るためです。一方、複数店舗、複数チャネル、期間限定、比較価格表示のいずれかがある変更では、部分反映を成功にしない境界として使えます。

明日から使える実装チェックリスト

[ ] 商品名ではなくGTINまたはSKUで対象を固定した
[ ] 店舗、チャネル、開始、終了を列挙した
[ ] 現行価格、下限価格、比較価格の証跡を結び付けた
[ ] AIの提案者と人の承認者を分けた
[ ] 実行直前に在庫、粗利、マスター版を再判定した
[ ] 棚札、POS、EC、カート、商品フィードを実測した
[ ] 部分成功時に販売を止める面と担当者を決めた
[ ] 終了後の復旧価格と検証期限を設定した

明日は1商品・1店舗で、値下げ、部分失敗、通常価格への復旧を通してください。どの面が未完了でも自動的に販売開始せず、担当者へ具体的な復旧先を示せれば、照合ゲートは機能しています。

参考資料

本記事はAIを活用して作成し、公開前に自動レビューを実施しています。情報の確認日：2026-10-19。