EC のダイナミック・プライシングを仕組みにするとき：価格の上下限、履歴、表示価格と請求価格の一致

EC の価格を、需要や在庫に応じて動かしたい。この記事で参照した解説記事では、価格変更の理由を FAQ で顧客に説明するといった、顧客への伝え方が取り上げられています。実際に作る段階では、その手前に決めておくことがあります。

この記事では、価格を動かす EC を作るときに、設計の段階で決めておきたい 3 つの論点を整理します。価格の上下限、変更履歴、そして画面に出した価格と請求する価格の一致です。最後に、法的な論点を確認するときの入り口も示します。

価格を動かすのは、表示だけの話ではない

ダイナミック・プライシングとは、需要と供給に応じて価格を動的に変える仕組みです。ネットショップ担当者フォーラムの解説記事は、価格の変更には EC の表示だけでなく、受注システムの変更などバックエンド側の対応も必要だと指摘しています（出典：ネットショップ担当者フォーラム。2018 年 7 月の掲載で、筆者はダイナミック・プライシングのツールを運営する立場です）。

この指摘は、設計の出発点になります。価格は商品ページに出る数字であると同時に、カート、注文、請求、返金、基幹システムの売上計上のすべてに流れていくデータです。価格を動かす仕組みを足すときは、どこで価格が決まり、どこまで同じ値が運ばれるかを先に決めます。

1. 価格の上下限：アルゴリズムの外に置く

最初に決めたいのは、価格がどこまで動いてよいかです。

データ分析の解説書籍サイトの記事は、AI が算出した価格が常に適切とは限らないため、アルゴリズムの精度を定期的に検証し、必要に応じて修正することを挙げています。また、ビックカメラの事例として、価格変更の理由や上限・下限を FAQ で説明していることに触れています（出典：Data Science Handbook）。

私たちは、上下限をアルゴリズムの内側ではなく、外側の設定として持つことを勧めます。算出ロジックが想定外の値を出したときに、最後に止める仕組みになるからです。決めることは次のとおりです。

• 商品ごと、または商品群ごとの下限と上限（原価や最低利益、ブランドとして許容する上限から決める）
• 一度に動かせる幅と、動かせる頻度（短時間に何度も変わると、顧客も社内も追えなくなる）
• 上下限を変更できる人と、変更の記録の残し方
• 上下限に当たったときに、通知を出すか、人が確認するまで止めるか

上下限は、事業側の判断を仕組みに閉じ込める場所です。開発側が決めるものではなく、価格の責任者が決める項目として、要件の段階で担当者を決めておきます。

2. 変更履歴：いつ、誰が、何のルールで変えたか

次に、価格の変更履歴です。解説書籍サイトの同じ記事は、顧客への透明性の手段として、商品の価格履歴を公開するツールの活用に触れています。顧客に見せるかどうかは別にしても、社内では履歴が必要になります。

• 変更した日時と、変更前後の価格
• 変更した主体（アルゴリズムか、人か。人なら誰か）と、適用したルールのバージョン
• 価格を動かした入力（在庫数、アクセス、競合価格など、判断に使った値）

履歴が必要になる場面は、問い合わせへの対応です。「先週見た価格と違う」と言われたときに、その時点の価格を再現できなければ、返金や差額対応の判断ができません。また、アルゴリズムを改善するときも、履歴がなければ効果を比べられません。

履歴は後から足しにくい項目です。価格を動かし始めた日から記録が始まるため、最初の設計に入れておきます。

3. 表示価格と請求価格の一致：どの時点の価格で確定させるか

3 つ目が、画面で見た価格と、請求する価格を一致させる設計です。価格が動く EC では、顧客が商品ページを見てから決済するまでの間に、価格が変わることがあります。このとき、どの価格で請求するかを決めておかないと、顧客も運用者も困ります。

決めておく論点は次のとおりです。

• 価格を確定させる時点：カートに入れた時点か、注文確認画面か、決済の直前か。確定させたら、その価格を一定時間保持するのか
• 確定後に価格が変わったとき：古い価格のまま注文を通すか、画面で再確認を求めるか
• カートに入れたまま時間が経ったとき：価格の有効期限を持つか、期限切れのときに何を表示するか
• 注文後の価格の扱い：注文時の価格を注文データに固定して持ち、後から価格が動いても請求・返金・売上計上が同じ値を参照するようにする

私たちは、注文データに「注文時点の価格」を固定して持つ設計を基本に考えています。商品マスタの現在価格を参照し続ける作りだと、価格が動くたびに過去の注文の金額が変わってしまうためです。

この設計は、基幹システムと連携する EC では特に重要です。EC 側で動かした価格が、基幹システムの請求や売上にそのまま渡るかどうかを、連携の仕様として最初に決めます。

法的な論点の確認先

価格を動かす表示には、法的な論点もあります。価格表示に関する考え方は、消費者庁が景品表示法のガイドライン類として公表しています（出典：消費者庁 景品表示法関連ガイドライン）。自社の表示方法や価格の変え方が実際にどう扱われるかは、消費者庁の資料と、必要に応じて弁護士などの専門家に確認してください。

設計の側でできることは、確認しやすい状態にしておくことです。上限・下限、変更履歴、請求価格の記録があれば、専門家に見せる材料になり、表示を修正するときも影響範囲を絞れます。

始める前に決める 5 つのこと

最後に、要件を固めるときのチェックを挙げます。

1. 価格の責任者は誰か（上下限を決め、変更を承認する人）
2. 価格の上下限と、動かせる幅・頻度
3. 変更履歴に残す項目と、保存期間
4. 価格を確定させる時点と、確定後に価格が変わったときの扱い
5. 注文時の価格を、注文データ・請求・基幹システムに同じ値で渡す方法

価格を動かす仕組みは、アルゴリズムの賢さよりも、これらの決めごとの有無で運用のしやすさが決まると考えています。

Urchin&Company の「ECサイト構築」では、Shopify などで作れない仕組みの EC として、ダイナミック・プライシングを含む EC を、基幹システム連携も含めて構築しています。価格の上下限や、注文時の価格を基幹システムへ渡す方法など、上の 5 つのうち決めきれていない項目があれば、お問い合わせの際にお知らせください。