【ITニュース解説】Retail pricing data is messier than a price field

小売業界における商品の価格データは、見た目以上に複雑で扱いにくい性質を持っている。システムエンジニアとして価格に関わるシステムを構築する際、多くの場合「一つの商品には一つの価格」という単純な前提からスタートしがちだが、この前提はすぐに崩れる。実際には、商品の色やサイズなどのバリアント、クーポン、会員価格、地域ごとの価格差、マーケットプレイスの複数の販売者、さらにはWebページのJavaScriptによる動的な価格表示など、さまざまな要因が絡み合い、価格は常に変動する。商品の在庫状況も価格に影響を与え、Webサイトが一時的に利用できないだけでもデータ収集が難しくなる。このような複雑さを理解し、適切にシステムに反映させることが、正確な価格戦略を支える上で極めて重要となる。

このような複雑な価格データを扱うためには、データの保存方法から見直す必要がある。最初の素朴なデータモデルでは、競合商品の価格を商品ごとに一つのレコードとして保存し、更新のたびに上書きしてしまうことが多い。例えば、competitor_products のようなテーブルで、商品のSKU（在庫管理単位）とURL、価格、通貨、更新日時だけを記録する方法である。しかし、この方法では、同じURLでもサイズやプロモーション、ログイン状態によって価格が異なる場合に対応できない。また、過去の価格変動の履歴が失われ、いつ、どのような条件で価格がいくらだったのかを追跡することが不可能になる。

より堅牢なデータモデルは、価格を「商品の属性」としてではなく「観測結果」として扱うことである。つまり、価格が変化するたびに、あるいは新しい価格情報を取得するたびに、その時点での詳細な情報を新たなレコードとして記録するのだ。price_observations のようなテーブルに、観測日時、内部SKU、競合他社名、URL、バリアントキー、販売者名、価格、定価、通貨、在庫状況、プロモーションテキストといった情報を保存する。さらに、データ収集が成功したかどうかのステータス（HTTPステータスコード、抽出ステータス、エラーメッセージなど）も記録しておく。このアプローチにより、「今日の最低価格はいくらだったか？」「競合は値引きしたのか、それとも基本価格を変えたのか？」「この商品は実際に購入可能だったのか？」「データ収集システムは正しく機能したか？」といった、より複雑なビジネス上の問いに答えられるようになる。例えば、単に価格が記録されていないことと、商品が在庫切れであることは全く異なる意味を持つため、これらを区別して記録することは非常に重要である。

Webページから価格を抽出する際にも、細心の注意が必要だ。小売サイトでは、定価、セール価格、クーポン適用価格、会員限定価格、セット価格など、複数の数字が同時に表示されていることがよくある。単純に数字だけを抽出すると、取り消し線の引かれた定価を誤って拾ってしまったり、実際には適用可能なクーポンを見落としてしまったりするリスクがある。正確な「有効価格」を特定するためには、HTMLの構造を理解し、特定の属性（例えば data-testid="sale-price" のようなカスタムデータ属性）を利用して、どの価格が現在の購入可能な価格であるかを明示的に抽出する手法を用いるのが良い。同時に、定価、在庫状況、プロモーションテキストなども合わせて取得することで、価格決定に必要なコンテキストを全て揃えることができる。また、データ抽出処理が失敗した場合（例えば、期待する価格情報が見つからなかった場合）には、ValueError のような明確なエラーを発生させ、下流のシステムが誤ったデータで処理を進めないようにすることも肝要である。

競合他社の価格を比較する場合、最も難しい課題の一つは「同じ商品」を正確に識別することである。一見単純に思えるこの作業は、商品の単位（自社が1個売りに対し、競合が12個パックで販売している場合）、色名の表記揺れ（ネイビー、ミッドナイトブルー、ブルーブラックなど）、商品タイトルに付属品やバンドルが含まれている場合、マーケットプレイスでデフォルトの販売者が頻繁に変わる場合など、さまざまな要因で困難になる。単に商品タイトルの類似性だけでマッチングを行うと、間違いが生じやすい。これを防ぐためには、マッチングの証拠となる情報（ブランド、モデル、色、サイズなど）と、マッチングの信頼度、そして単位数量などをデータとして保存しておくべきだ。もし価格が急激に変動した場合、最初に確認すべきは「価格アルゴリズムが何をしたか」ではなく、「そもそも正しい商品同士を比較していたか」である。

データ収集システムは、予期せぬ理由で失敗することが常にある。Webサイトからのアクセス拒否（403 Forbidden）、リクエスト過多による制限（429 Too Many Requests）、古くなったキャッシュによるHTMLの取得、ボット判定によるブロック、WebサイトのHTML構造の変化、JavaScriptによって後から価格がレンダリングされるページへの対応不足など、スクレイピングの失敗理由は多岐にわたる。これらの失敗は、市場の価格が変動した「ビジネスシグナル」ではなく、あくまで「データ収集の失敗」として明確に区別して扱う必要がある。データパイプラインの中で、データ収集の試行結果を「成功」「タイムアウト」「抽出失敗」といったステータスで記録し、実際の価格決定アルゴリズムでは、ステータスが「成功」で、かつ最近観測されたデータのみを使用するようにルールを設定する。商品のカテゴリによってデータの鮮度要件は異なり、食料品のような商品は毎時間のチェックが必要かもしれないし、家具のような商品は数日前のデータでも十分かもしれない。

動的な価格設定を導入する場合であっても、最初の実装ではシステムが過剰に反応しないよう、保守的なアプローチを取ることが重要だ。自動的な価格変更によって予期せぬ問題が発生するのを防ぐため、「ガードレール」を設けるべきである。例えば、SQLクエリで直近数時間以内に成功裏に観測され、かつ在庫がある競合商品の最低価格を抽出する際にも、いくつかの制限を設ける。具体的には、「新しい観測データが複数の競合から得られない限り価格を変更しない」「在庫切れの競合商品には反応しない」「自社の利益率の最低ラインを下回る価格には設定しない」「一つの異常な観測値にすぐに反応せず、複数の確認が取れるまで待つ」といったルールをSQLの外部で適用する。さらに重要なのは、価格が変更された理由を後から追跡できるように、すべての価格変更に対して、その決定に用いられた入力データ（観測履歴）を詳細にログとして残しておくことである。これにより、「なぜこの商品の価格は変わったのか」という問いに対し、「システムが実行されたから」という曖昧な答えではなく、具体的な根拠をもって説明できるようになる。

このような複雑な価格データシステムの構築に取り組む上での現実的な第一歩として、まずは小規模な実践から始めることを推奨する。例えば、自社の商品の中から10種類のSKUを選び、2つの競合他社の商品を対象に1週間データ追跡を行ってみる。この際、データを上書きするのではなく、すべての観測結果を履歴として保存するデータモデルを採用し、在庫状況、プロモーションテキスト、バリアント情報、販売者、データ抽出のステータス、そして生データのハッシュ値といった詳細情報も合わせて記録する。そして、本格的な価格アルゴリズムを開発する前に、この手元に集まったデータを手動でじっくりと検査し、「奇妙なケース」や予期せぬ状況を発見するのだ。これらの「奇妙なケース」こそが、将来的にシステムが満たすべき真の要件となる。