Shopee 価格トラッカーの作り方｜価格履歴と競合を正確に監視する方法

Shopee 価格トラッカーは、商品価格を時系列で保存し、値下げ、競合ショップの動き、キャンペーンの影響を確認する仕組みです。重要なのは単に数字を集めることではありません。同じマーケット、同じ商品ページ、同じバリアント、同じ送料・クーポン条件を、決まった時刻に比較することです。条件が揃っていなければ、値下げに見える差が実は別サイズや別セットの価格ということが起こります。

この記事では、Shopee 価格監視ツールの自作を検討する担当者向けに、設計、データ検証、履歴保存、アラート、障害対応を順番に説明します。掲載するPython例は合成データを使ったローカルの監視コアです。ライブのShopeeスクレイピングや非公開APIへの接続を保証するものではなく、許可されたデータソースを接続する部分は別途実装します。

先に結論

信頼できるトラッカーは、許可されたデータソースと「何の価格を測るか」という定義から始まります。各観測に時刻、通貨、ショップ・商品・バリアントID、在庫、送料、バウチャー条件を保存し、同じ比較キーのレコードだけを比較してください。取得失敗を価格0として履歴に入れず、失敗ログと価格履歴を分離します。プロキシは許可されたワークフローで地域出口や接続継続性が必要な場合に役立ちますが、アクセス権限、正しいパーサー、チェックアウト最終価格を与えるものではありません。少数の商品で検証してから拡張するのが安全です。

Shopee 価格トラッカーとは

トラッカーの役割は、価格を観測し、観測時点の条件を保存し、意味のある変化を通知することです。消費者向けの「この商品は以前より安いか」という機能と、競合分析用の「競合ショップが同一オファーの価格を変えたか」は異なります。後者には、安定した商品照合、在庫確認、プロモーションの扱いが欠かせません。

既製サービスは収集や過去データを提供します。自作のShopee 競合分析 ツールなら、比較ルール、保存形式、通知のしきい値を自社の業務に合わせられます。その代わり、データソースへの権限、保守、品質管理は自社の責任です。Rola IPはネットワーク接続を提供しますが、価格トラッカーや過去データベースそのものを含むとは限りません。

表示価格以外に保存すべき項目

スクレイピングやAPI選定の前に、短いデータ契約を作成します。最低限、次の項目を1観測ごとに保存してください。

• マーケットと通貨：シンガポールドル（SGD）とマレーシアリンギット（MYR）を、商品名が同じでも混在させない。
• ショップIDと商品ID：検索順位や編集可能な商品名ではなく、対象リスティングに紐付ける。
• バリアントID：サイズ、色、セット数を区別する。「〜から」の価格を選択済みバリアントの価格として扱わない。
• 価格と価格種別：販売価格、取り消し線の参考価格など、どの金額を取得したかを明示する。
• 在庫状態：欠品は診断用に残しても、購入可能なオファーとして比較しない。
• 観測時刻とタイムゾーン：ソースが示した時刻と、システムに取り込んだ時刻を分け、並び替えはUTCに統一する。
• 送料・バウチャー条件：含む、含まない、不明を記録する。不明なら比較前に確認する。
• 取得ステータスと出典：失敗理由、試行ID、参照元を保存する。

配送先地域、数量、購入資格も可能な範囲で固定します。氏名や住所などの個人情報を収集する必要はありません。例えば通知は「表示価格が送料・バウチャーを除いて10％下落」と書くと、すべての購入者が10％安く買えるという誤解を避けられます。公開表示価格とチェックアウト最終額は同じではありません。

Shopee 価格トラッカーを構築する6ステップ

1. 市場、商品、頻度を決める

最初は1マーケットと少数のウォッチリストに絞ります。ショップ、商品ページ、バリアント、通貨、価格条件、観測が支える業務判断を定義してください。頻度は、チームが対応できる速度とデータソースが許すアクセス頻度で決めます。Shopeeの全エンドポイントに共通する安全なリクエスト回数はありません。

2. 許可されたデータソースを選ぶ

公式連携、セラー向けエクスポート、ライセンス済みフィードを先に確認します。マーケット、バリアント別価格、時刻、照会可能なリスティングが現行ドキュメントに明記されているか確認してください。自社ショップへのアクセス権は、競合カタログへのアクセス権を意味しません。

Webベースの取得では、利用規約とアクセス制限を確認します。403などの拒否は権限を再確認し、別の許可されたソースを選ぶ理由です。接続先を変えても権限は発生しません。以下のローカル例は、1行1観測の正規化JSON Linesを受け取るため、許可されたアダプターと検証・保存コアの境界が明確です。

3. 価格を取得し、内容を検証する

価格より先に商品同一性を検証します。対象の商品・バリアントか、通貨は正しいか、選択した価格種別の金額が有限で正数かを確認してください。ログイン画面、空の本文、エラーページをHTTP 200だけで成功と判定してはいけません。不明な価格を0に変換せず、失敗理由を残します。

ローカル例は欠品オファーとタイムゾーンなしの時刻も拒否します。本番アダプターでは、通貨の小数桁、データの鮮度、ウォッチリストID、ソース固有の必須フィールドも検証します。

4. Shopee 価格履歴を時刻付きで保存する

成功した観測と失敗した試行を別レコードにします。障害による空白を価格0の急落に見せてはいけません。価格はDecimal互換で保存し、ソース観測時刻と取り込み時刻を両方保持します。

SQLiteなどでは、マーケット、通貨、ショップ、商品、バリアント、価格種別、送料・バウチャー処理、コンテキスト、ソースの組み合わせごとに系列を分けます。これにより、異なるオファーの誤比較を防げます。ソースの項目定義が変わった場合はアダプターをバージョン管理し、旧履歴との連続性を確認してから統合します。

サンプルでは、同じSGD建てバリアントについて29.90、26.90、25.90の3観測が保存されます。途中の取得失敗は価格0として挿入されません。検証プログラムは、保存した価格と件数に加え、DBを開き直した後もデータが残ることを確認します。

テスト済みPython例を実行する

展開したフォルダーをターミナルで開き、次のコマンドを順番に実行します。

python --version
python run_demo.py
python tracker.py sample.jsonl --db prices.sqlite --threshold 5

run_demo.py は一時DBとインメモリDBで検証し、実行環境と結果を test-output.txt に保存します。正常終了時の終了コードは0です。tracker.py は指定したSQLiteファイルへ価格と失敗を保存します。サンプルには意図的な失敗が含まれるため、初回の取り込みは受理5件・拒否5件、終了コード2が正常な検証結果です。終了コード0は全件受理、1はファイル・DB・設定などの実行エラーを表します。

最初から取り込む場合は新しいDBファイル名を指定してください。同じDBを再利用すると、既存系列の重複・古い観測を拒否します。比較にはDecimalを使い、同じ系列の直近の受理済み観測だけを参照します。

previous = db.execute(
    'SELECT price, observed FROM prices WHERE series=? '
    'ORDER BY observed DESC LIMIT 1', (key,)
).fetchone()
change = None if not previous else (price / Decimal(previous[0]) - 1) * 100
alert = change is not None and abs(change) >= threshold

上記は比較処理の抜粋です。実行にはダウンロードした tracker.py を使用してください。入力はUTF-8のJSON Lines形式で、1行につき1観測です。価格は "29.90" のような文字列、観測時刻はタイムゾーン付きISO 8601形式、在庫ありは in_stock: true、取得成功は status: "ok" として渡します。送料とクーポンの扱いは included または excluded を指定し、不明な条件は比較対象から除外します。

検証時に得られた10件の処理結果は次のとおりです。環境情報を含む記録は 実行ログで確認できます。

BASELINE
CHANGE -10.03% ALERT
REJECT collection_failure
BASELINE
BASELINE
REJECT invalid_price
CHANGE -3.72%
REJECT invalid_price
REJECT no_comparable_available_offer
REJECT duplicate_or_out_of_order
PASS: 10 scenarios; 5 observations; 5 failures; 1 alert

このほか、DBの再接続後の永続化、再取り込み時の重複拒否、不正JSONからの処理継続、無効な価格や時刻の拒否、UTCへの時刻正規化、5％ちょうどの通知判定、送料条件が異なる系列の分離を検証しています。

検証範囲は、合成データによる保存・比較・拒否処理です。 Shopeeへのライブ接続、プロキシ性能、定期実行、通知配信は対象に含みません。アラートはローカルで判定するだけで、メッセージを送信しません。ネットワーク通信を行わないため、HTTPタイムアウトや通信再試行の設定もありません。

不正なJSONは理由と入力行番号を失敗テーブルに記録し、次の行へ進みます。DBエラーが発生した場合は処理中の1行をロールバックして停止し、すでに保存した行は保持します。SQLiteのロック待ちは5秒です。実運用では、ソース用アダプターに通信タイムアウト、回数を制限した再試行、Retry-Afterへの対応を追加し、対象ID、データの鮮度、通貨の小数桁も検証してください。

実ソース用アダプターの認証情報は環境変数（例：PRICE_SOURCE_TOKEN、必要な場合のみROLA_PROXY_URL）で管理し、ソースコードや画像に書き込まないでください。これらは推奨する変数名であり、オフラインコアが読み取る設定ではありません。実際のエンドポイントと認証情報は、利用を許可されたプロバイダーから取得します。

5. 価格変動アラートを設定する

一致する比較キーの有効な前回観測を見つけてから、次式で変化率を計算します。

変化率（％）＝（新価格 − 前回価格）÷ 前回価格 × 100

前回価格は正数でなければなりません。SGD 29.90から26.90への変化は約-10.03％で、例の5％しきい値を超えます。MYRや別の色は新しい系列になるため、通貨またはバリアントをまたぐアラートは発生しません。

通知には旧価格、新価格、ID、時刻、送料・バウチャー条件、出典URLを含め、再送による重複を排除します。自動値付けを行う場合も、単一観測で販売価格を変更せず、承認や粗利ルールを別に設けます。

検証では、受理された5観測のうち1件がアラートの対象となりました。5％は業務上の設定例であり、Shopeeのルールではありません。

6. 失敗を価格変動と分けて記録する

接続、プロキシ認証、対象レスポンス、セッション、パース、業務検証を別カテゴリーにします。試行時刻と内部ターゲット参照を記録し、トークンや不要な個人情報はログに残しません。タイムアウトを設定し、一時的な失敗だけを少ない回数でバックオフ付き再試行します。Retry-Afterが返れば従い、連続失敗や予算上限では一時停止します。

Retry-Afterの待機時間がジョブの実行枠を超える場合は、ジョブを再スケジュールします。ヘッダーがない場合も、即時の連続再試行が許可されるとは限りません。

サンプルの失敗テーブルには、失敗の記録時刻、入力行番号、拒否理由を保存します。生の入力や認証情報は保存しません。取得失敗、不正価格、欠品、重複時刻が価格履歴に混入しないことを検証しています。

Shopee 価格を自動取得する方法：定期実行と鮮度監視

許可されたアダプターとインポーターをスケジュール実行し、同一ターゲットの重複実行を防ぎます。最終成功観測の経過時間を監視し、取得失敗と価格アラートを別の通知経路に送ります。通知がない状態は、必ずしも価格が安定していることを意味しません。

Shopee 価格スクレイピングの方法と障害の切り分け

まず失敗した層を特定してから、プロキシを変更します。

• 407 Proxy Authentication Required：ホスト、ポート、プロトコル、認証方式を確認します。SOCKSは独自のネゴシエーションを使い、HTTPステータスが返らない場合もあります。
• DNS・接続タイムアウト：エンドポイントの綴り、DNS、経路、タイムアウト、アプリの接続ログを確認します。ブラウザーで成功してもPythonクライアントが同じ経路とは限りません。
• 403 Forbidden：対象サーバーまたは中間サービスが拒否しています。IP不良と決めつけず、許可されたアクセス方法を確認します。
• 429 Too Many Requests：レート制限です。頻度、同時実行、再試行を減らし、Retry-Afterがあれば従います。
• ログイン・セッション消失：正規のセッション期限、Cookie、アプリ状態を確認します。固定出口IPだけではログイン状態は維持されません。
• HTTP 200なのに価格が空：ログインページ、欠品バリアント、HTML構造変更、パーサーエラーを調べます。
• 不自然な割引：通貨、入数、バリアント、在庫、価格種別、古い観測を再確認します。

プロトコルの定義は、RFC 9110：HTTPステータスコードと、RFC 6585：429 Too Many Requestsを参照してください。

Shopee価格監視にプロキシは必要か

必須ではありません。公式API、セラーエクスポート、ライセンス済みフィードで要件を満たせるなら、追加のプロキシは複雑さを増やすだけかもしれません。許可された処理で特定地域の出口、指定IP、接続の継続性が必要な場合に検討します。

Shopee スクレイピング プロキシは設定した通信の経路を変えるだけです。API権限、バリアント判定、クーポン資格、正しい価格抽出を保証しません。マーケット、アカウント、配送条件、選択オファーは別々に管理し、ログにはジョブとネットワーク設定の対応を残します。アクセス制限やリクエスト上限を回避する目的で出口を増やしてはいけません。

ローテーション・スティッキー・固定IPの違いと選び方

Shopee 価格トラッカーに使うプロキシは、処理中に同じ出口IPをどれだけ長く維持する必要があるかを基準に選びます。ローテーション、スティッキー、固定IPは、出口の切り替え方や維持条件を表す言葉です。それぞれの性質を理解したうえで、利用が許可されたデータ取得の手順に合わせて選択してください。

ローテーション：独立したリクエストで切り替えの必要性を判断する

ローテーション接続では、サービスの設定に応じたタイミングで出口IPが切り替わります。リクエスト単位など、実際の切り替え条件は利用するサービスと設定によって異なります。

前のアクセス状態を引き継がずに完了する独立した観測であれば、選択肢になります。ただし、IPを頻繁に切り替えるほど価格データの品質が上がるわけではありません。取得元のアクセス条件に適合しているか、切り替えが観測条件や処理の成否に影響しないかを確認し、運用上の必要性がある場合に採用します。

スティッキー：一連の処理で出口IPを一時的に維持する

スティッキーセッションは、一定期間、同じ出口IPを使い続けるための仕組みです。複数の操作をひと続きのセッションとして実行する場合に検討します。

確認すべき点は、セッションの有効期間、通信しない時間が続いた場合の扱い、割り当てられた出口が利用できなくなった場合の動作です。処理が終わるまで同じIPを維持できるかは、仕様と実際の動作の両方で確認してください。Cookieの保存やログイン状態の管理は、引き続き収集プログラム側で行う必要があります。

固定IP：長期間の継続利用や接続元の許可リストに対応する

固定IPは、サービスの契約条件に従って同じアドレスを継続利用する方式です。より長い期間にわたって接続元を揃えたい場合や、許可されたデータソースへの接続で送信元IPの事前登録が必要な場合に検討します。

契約前には、IPの割り当て期間、交換が行われる条件、専用IPかどうかを確認します。「固定」という名称だけで、永久に同じアドレスを使える、または他の利用者と共有しないと判断しないことが大切です。

これらは互いに関連する性質であり、完全に別々の商品分類とは限りません。例えば、ローテーション型の住宅用プロキシでも、スティッキーセッションを指定できる場合があります。スティッキーは一時的なIPの維持を意味し、永久固定や専有を意味しません。 詳しい使い分けは、Rola IPのスティッキーとローテーションの解説を参照してください。

Rola IPをShopeeの価格監視に組み込む方法

Rola IPは、Shopee 価格トラッカーの通信経路を担うサービスとして組み込みます。価格の取得、バリアントの検証、履歴保存、アラート判定はトラッカー側で行い、プロキシについては地域、接続設定、セッション、通信量の順に確認すると、導入時の問題を切り分けやすくなります。

対象地域の提供状況とプロトコルの互換性を確認する

Rola IPの公開サイトでは、住宅用プロキシの対応範囲として190以上の国・地域を案内しています。ただし、この数値が、希望する国・都市や選択したプロキシ商品でのIP在庫を保証するわけではありません。運用設計を固める前に、現在の管理画面で対象地域が利用できるかを確認してください。

あわせて、選択する接続プロトコルが収集プログラムと使用ライブラリでサポートされているかを確認します。プロキシサービス側の対応だけでなく、実際に通信するクライアント側の互換性まで確認する必要があります。

出口IPの地域と、価格を調べるShopeeのマーケットは別の設定です。シンガポールの出口IPを選んでも、すべての観測がSGD建てになるわけではなく、購入者の配送条件が自動的に満たされるわけでもありません。対象マーケット、通貨、配送地域、選択バリアントは、価格データの比較条件として別途管理します。

実際の接続情報を設定し、収集プログラムから検証する

アカウント用に生成されたホスト、ポート、認証設定を使用し、Rola IPの住宅用プロキシ設定ガイドに沿って接続を設定します。通信経路の確認は、本番で価格を収集するプログラムから行ってください。

検証は次の2段階に分けます。

1. 通信経路の確認：適切なIP確認用エンドポイントを利用し、接続できることと、実際に使われている出口IPを確かめます。
2. 価格データの確認：利用が許可されたデータソースへリクエストし、商品ID、バリアント、通貨、価格などの項目が期待どおりかを検証します。

IP確認サービスに接続できても、Shopeeへのアクセス権限や価格抽出の正しさは確認できません。接続テストとデータ検証を分けることで、問題が通信経路にあるのか、データソースや解析処理にあるのかを判断できます。

取得手順に合ったセッション設定を選ぶ

各観測が独立して完了する場合は、出口IPの切り替えに実際の利点があるかを検討します。一方、連続した操作を必要とする正規の取得手順では、選択したセッション設定が処理全体を通じて期待どおりに動くかを確認してください。

設定名に「スティッキー」と表示されているだけで、必要な時間の接続継続性が確保されるとは判断できません。実際の処理を最初から最後まで実行し、出口IPの維持状況と取得結果を確かめます。

この記事で紹介したオフラインのPythonテストは、価格の比較・保存処理を検証するものです。Rola IPの地域別の利用可否や接続性能を検証したものではありません。本格運用の前に、利用が許可されたデータソース、対象地域、実際の収集アプリを組み合わせて小規模な試験運用を行ってください。

通信量を実測し、継続運用の費用を見積もる

試験運用では、リクエスト数、レスポンスのデータ量、失敗件数、再試行回数を記録します。ブラウザーを使って取得する場合は、商品ページの本文だけでなく、画像やスクリプトなど、ページ表示に伴う通信も含めて測定します。

料金プランについては、現在の課金単位、購入した通信量の有効期限、同時接続の条件、失敗した通信の課金上の扱いを確認してください。IP単位で契約するプランでは、通信量ベースの見積もりとは別に、IPの割り当て費用とサービス条件を評価します。

月間通信量は、完了したジョブ1件あたりの実測通信量に、月間の予定実行回数を掛けて見積もります。さらに、実測した再試行による増加分を反映します。ただし、1ジョブあたりの測定値に再試行分が含まれている場合は、重ねて加算しないでください。

費用対効果を見る際は、検証を通過した価格観測1件あたりのコストが役立ちます。リクエスト単価が低くても、有効な価格が取得できなければ監視には使えません。この指標をデータの鮮度や検証エラーと併せて確認し、監視対象を増やす前に支出アラートと処理を停止する上限額を設定します。

通信量の計算例として、Rola IPの帯域幅計算ツールに10,000リクエスト、1リクエストあたり100KBを入力すると、10進法で合計1GBになります。20％の安全余裕を加えた場合は1.2GBです。

この結果は通信量の目安であり、料金の見積額ではありません。予算を組む際は、例の100KBを自社の取得処理で測った値に置き換え、適用されるプランの料金・契約条件に照らして計算してください。

比較可能なデータと検証可能な接続から始める

まずは定義が明確な少数オファーで、実際の値下げとバリアント違い・取得失敗を区別できることを確認します。その後、許可されたソースを接続し、ネットワーク経路、鮮度、検証失敗、受理1件あたりのコストを測定してからウォッチリストを広げます。

対象市場の出口や一貫したプロキシセッションが必要な場合は、Rola IPの価格監視向けプロキシを確認し、利用可能地域、アプリ、通信量、契約条件を自社の許可された運用と照合してください。