競合の価格とクーポンをモニタリングする：1 日 1 回のジョブ

競合の価格を手で追うことの問題は、手間ではありません。思い出したときにしか見ないことです。値下げは火曜の午前 3 時に起きていて、気づいたのは金曜。トラフィックはもう動いています。

1 日 1 回動くジョブでこれは解消できます。エンドポイントは 3 つで足ります。

export ECOMMERCE_DATA_API_KEY="your_api_key"

3 つのエンドポイントは担当する時間軸が違う

エンドポイント	時間軸	用途
Product Details	現在	今日の価格、BSR、評価、レビュー数、出品者数
Coupon Trends	直近	販促のオン／オフの周期
Product History	長期	価格と順位の推移。今日の動きが異常かを判断する

日次で回す必要があるのは 1 つ目だけです。 クーポンは週 1 回で十分、長期推移は「今回の値下げは大きいのか」を判断するときだけ呼びます。この振り分けがコール量を決めます。

日次スナップショット

curl --request POST \
  --url https://ecommercedataapi.com/v1/amazon/asin/detail \
  --header "Content-Type: application/json" \
  --header "X-API-Key: ${ECOMMERCE_DATA_API_KEY}" \
  --data '{
  "marketplace": "JP",
  "asin": "B08CK5Z5Q1"
}'

Product Details API1 つの ASIN の価格、BSR、評価、レビュー数、出品者数、配送形態のスナップショット

毎日のレスポンスは最新値だけを持つのではなく、(asin, 日付) をキーに保存してください。最新値だけを持つのは変化検知を放棄することと同じです。今日何が動いたかを知るには昨日の行が必要です。

クーポンも同時に見たい場合は Product Details with Coupon Trends が 1 回の呼び出しで両方を返すので、課金単位が 2 ではなく 1 で済みます。

クーポンの周期

curl --request POST \
  --url https://ecommercedataapi.com/v1/amazon/asin/coupon-trend \
  --header "Content-Type: application/json" \
  --header "X-API-Key: ${ECOMMERCE_DATA_API_KEY}" \
  --data '{
  "marketplace": "JP",
  "asin": "B08CK5Z5Q1"
}'

クーポンデータの価値は現在の状態ではなく周期にあります。競合が常時クーポンを出しているのか、特定の時期に集中させているのかで、追随するかどうかが決まります。今日オンかオフかだけでは何も結論できません。

長期の推移

curl --request POST \
  --url https://ecommercedataapi.com/v1/amazon/keepa/detail \
  --header "Content-Type: application/json" \
  --header "X-API-Key: ${ECOMMERCE_DATA_API_KEY}" \
  --data '{
  "marketplace": "JP",
  "asin": "B08CK5Z5Q1"
}'

このエンドポイントは「今回の動きは歴史的にどの程度の大きさか」に答えます。これがないと、アラートは通常のノイズと本当の動きを混ぜて通知してきます。

アラート閾値の決め方

固定の百分率は使わないでください。 「5% 超の値下げで通知」は価格帯によって意味がまったく違います。基準線は履歴のレンジで取ります。

価格が直近 N 日の最安値を下回った → 見る価値あり。
BSR が 1 日で桁を跨いだ（5 桁から 4 桁へ）→ 見る価値あり。
出品者数が急増した → 相乗りの可能性。価格変動より優先度が高い。
レビュー数が 1 日で急増した → 記録はするが、必ず動く必要はない。

最初の 2 つには履歴が必要で、そのために 3 つ目のエンドポイントがあります。

スケジュールとコール量

競合 ASIN を 50 件見るとします。

ジョブ	頻度	1 回のコール数	月あたり概算
日次スナップショット	毎日	50	1,500
クーポン周期	毎週	50	200
長期推移	トリガー時	必要分	アラート件数次第

課金対象リクエストの成功は既定で 1 コール消費するため、モニタリングのコストはほぼ「ASIN 数 × 頻度」です。コストを下げるなら ASIN 数か頻度を減らします。フィールドを減らしても意味はありません。エンドポイントは全フィールドを返し、課金は同じです。パックの規模は料金にあります。

実装で必ず扱うべき 3 点

1. 制限はアカウント単位。 50 件を順次実行するのは問題ありませんが、50 並列は避けてください。429 では Retry-After に従って待ちます。エラー一覧はエラーとレート制限にあります。

2. 失敗は課金されないので再試行は安全。 課金対象の結果を返す前に失敗したリクエストは課金されません。再試行は入れつつ回数を上限で抑え、X-Request-Id を記録して追跡できるようにしてください。

3. 「値が変わった」と「照会が失敗した」を分ける。 失敗時に 0 や空値を書き込まないでください。推移グラフ上で偽の急落になります。その日はスキップして印を付けます。

制約

スナップショットは照会時点の値です。1 日 1 回では日中の短期変動は見えません。
BSR と価格はプラットフォームで見える検証可能な値ですが、販売数系は推定値です。
履歴の粒度と対象範囲はエンドポイントの返却内容に依存します。すべての ASIN が同じ長さの履歴を持つとは限りません。
このフローが見るのは公開市場データです。自社の広告費、在庫、注文は含まれません。それらは自社の管理画面から書き出してください。

スケジューラーを書く前に同じ流れを手で回すなら、エージェントに任せてください（Cursor や Codex で競合分析をする）。

競合の価格とクーポンをモニタリングする：1 日 1 回のジョブ

目次