マーケットプレイスでの商品の在庫監視をプロキシ経由で設定する方法：セラー向けガイド

在庫の自動監視(stock availability)は、セラーや小売業者にとって極めて重要な課題です。Wildberries、Ozon、Amazonでの競合他社の在庫を追跡することで、価格や仕入れを迅速に調整できます。しかし、マーケットプレイスは1つのIPからの大量リクエストを厳しくブロックします。プロキシなしでは、パーサーは10〜50リクエストでブロックされます。

本ガイドでは、プロキシを使用した安定的な在庫監視の設定方法を解説します:どのタイプのプロキシを選ぶか、IPローテーションの設定方法、使用すべきリクエストパラメータ、人気マーケットプレイスでのブロック回避方法について説明します。

マーケットプレイスが在庫監視をブロックする理由

マーケットプレイスは、複数レベルの保護でインフラをパースから守っています。在庫の自動監視を開始すると、スクリプトはマーケットプレイスのAPIやWebページに数百または数千のリクエストを送信します。プラットフォームにとって、これは攻撃または不正なデータ収集のように見えます。

パーサー検出の主な方法:

• 1つのIPからのリクエスト頻度 — 1つのアドレスから1分間に100以上のリクエストが来る場合、これは明らかなボットの兆候です。通常のユーザーは物理的に1秒間に2〜3個の商品ページを開くことはできません。
• Cookieとセッション履歴の欠如 — パーサーはトップページへの事前アクセスなしにリクエストを送ることが多く、これが自動化を示します。
• 同一のUser-Agent — すべてのリクエストが同じブラウザヘッダーで送信される場合、疑わしいです。
• 行動パターン — IDによる商品の順次列挙、ランダムな休止の欠如、完璧な規則性のリクエスト。

ブロックはIPアドレスレベルで発生します。最初にマーケットプレイスはキャプチャを表示し、次にアクセスを一時的に制限し(レート制限)、組織的な違反の場合は数時間または数日間IPを完全にブロックします。

在庫パースに適したプロキシタイプの選択

プロキシタイプの選択は、監視の安定性とブロックの可能性に直接影響します。マーケットプレイスごとに異なるタイプのIPアドレスへの反応が異なります。3つの主要オプションと在庫パースへの適用を検討しましょう。

レジデンシャルプロキシ — ほとんどの在庫監視タスクに最適な選択です。実際の家庭ユーザーのIPアドレスを使用するため、マーケットプレイスはリクエストを正当なものと認識します。WildberriesとOzonでは、これはほぼ必須要件です。これらのプラットフォームはデータセンターを積極的にブロックします。

データセンタープロキシは、保護が弱いサイトや最大速度のパースが必要な場合に適しています。例えば、地域マーケットプレイスや小規模オンラインストアの監視などです。主な利点は高速で安定した接続です。しかし、大手プラットフォームではより頻繁にブロックされます。

モバイルプロキシ — 最も信頼性が高いが、最も高価なオプションです。重要商品や、レジデンシャルプロキシがブロックされ始めた場合に使用してください。モバイルIPは1つのアドレスの背後に通信事業者の数千の実ユーザーがいる可能性があるため、ブロックがほぼ不可能です。

IPローテーションの設定:アドレス変更の頻度

IPローテーションは、ブロック防止の鍵となるパラメータです。アドレス変更頻度の適切な設定により、各IPから最小限のリクエスト数になるように負荷を分散し、通常のユーザーの行動を模倣できます。

ローテーションの2つの主要アプローチ:

1. 時間ベースのローテーション(Time-based rotation)
IPアドレスは、リクエスト数に関係なく、設定された時間間隔で変更されます。これは、一定頻度の定期監視に適したシンプルで予測可能な方法です。

• 5〜10分ごと — 重要商品の頻繁な監視用(トップポジション、競争の激しい商品)
• 15〜30分ごと — ほとんどの在庫監視タスクの標準モード
• 1時間ごと — 高頻度の更新が不要な大規模品揃えのバックグラウンド監視用

2. リクエストベースのローテーション(Request-based rotation)
IPは一定数のリクエスト実行後に変更されます。この方法は各アドレスへの負荷をより正確に制御できます。

• 10〜20リクエストごと — WildberriesとOzon用(厳格な保護)
• 50〜100リクエストごと — Amazon、eBay用(中程度の保護)
• 200〜500リクエストごと — 保護が弱いプラットフォーム用

組み合わせアプローチ(推奨):
時間ベースのローテーションを主要方法として設定し、リクエスト制限を追加保護として追加します。例:IPは10分ごとまたは50リクエスト後に変更 — 先に到達した方。これにより、偶発的なアクティビティの急増から保護されます。

各マーケットプレイスでの監視の特徴

各マーケットプレイスには独自のパース保護の特徴があり、在庫監視の設定に個別のアプローチが必要です。人気のあるロシアおよび国際プラットフォームでの作業の特性を検討しましょう。

Wildberries

Wildberriesは、ロシアのマーケットプレイスの中で最も積極的なパース保護システムの1つを持っています。プラットフォームは、ヘッダー、Cookie、アクセス頻度、行動パターンの分析を含む多層チェックを使用しています。

主な特徴:

• レジデンシャルプロキシの使用が必須 — データセンターはほぼ即座にブロックされます
• RefererやAccept-Languageを含む完全なブラウザヘッダーセットの送信が必要
• Wildberries APIは一部のリクエストに特別なトークンが必要
• 頻繁なIP変更(5〜10分ごと)が極めて重要
• リクエスト間にランダムな遅延を追加:2〜5秒

Wildberriesでの在庫監視には、パブリックAPIまたは商品ページのパースを使用します。APIはより安定していますが、厳格な制限があります。HTMLをパースする場合は、実際のブラウザの動作を模倣する必要があります:画像の読み込み、JavaScriptの実行、リクエスト間でのCookieの保存。

Ozon

OzonはWildberriesと比較して積極性の低い保護を使用していますが、注意深いアプローチが必要です。プラットフォームはボット保護にCloudflareを積極的に使用しており、これが複雑さの追加レベルとなります。

• レジデンシャルプロキシが推奨されますが、低頻度リクエストでは高品質データセンターも機能する可能性があります
• Cloudflareチャレンジにはjavascriptの実行が必要 — ヘッドレスブラウザまたは特別なライブラリを使用
• 10〜15分ごとのIPローテーションで通常十分
• リクエスト間の遅延:3〜7秒
• Cloudflare通過後のCookie保存が必須

Amazon

Amazonは多くのリクエストパラメータを分析する複雑な保護システムを持っています。プラットフォームはアクセス頻度とIPアドレスの地理的位置に特に敏感です。

• ターゲットマーケットプレイスと同じ国のレジデンシャルプロキシを使用(amazon.com — 米国、amazon.de — ドイツ)
• Amazonは疑わしいアクティビティ時に頻繁にキャプチャを表示 — 解決システムを準備
• 15〜20分ごとまたは50〜100リクエストごとのIPローテーション
• リクエスト間の遅延:5〜10秒(Amazonは速度に非常に敏感)
• 人気ブラウザの最新User-Agentの使用が必須

Avito

Avitoには特定の特徴があります — 広告の地理的紐付けです。特定の都市での商品在庫を正しく監視するには、その地域のプロキシが必要です。

• 必要な都市のジオロケーション付きレジデンシャルプロキシを使用
• Avitoは地域ごとに異なる結果を表示 — 1つのIPは広告の一部のみを見ることができます
• 10〜15分ごとのローテーションで十分
• リクエスト間の遅延:3〜5秒
• プラットフォームはセッション追跡にCookieを使用 — 必ず保存してください

リクエスト制限とチェック間の遅延

リクエスト頻度の適切な設定は、データの鮮度とブロックリスクのバランスです。頻繁すぎるチェックはBANにつながり、まれすぎると競争上の優位性を失います。異なるシナリオの最適頻度を見つける方法を解説します。

1つの商品への推奨リクエスト間隔:

連続リクエスト間の遅延(複数商品を連続してパースする場合):

• 最小遅延:2〜3秒 — 人間の行動を模倣するための絶対最小値。実際のユーザーはこれより速く商品ページを開くことはできません。
• 最適遅延:4〜7秒 — ほとんどのタスクに推奨。ランダム性を追加:random(4000, 7000)ミリ秒。
• 安全な遅延:8〜15秒 — 特に保護されたプラットフォームまたは制限超過警告後に使用。

重要な原則 — ランダム性: 固定間隔を決して使用しないでください。正確に5秒の遅延の代わりに、4〜6秒のランダムを使用します。これは人間の行動を模倣するために極めて重要です。実際のユーザーは完璧な規則性でクリックしません。

時間帯別の負荷分散:
マーケットプレイスにはピーク負荷時間(通常18:00〜22:00の夕方)があり、この時間帯は保護システムが特に敏感です。この期間はリクエスト頻度を下げるか、データが重要でない場合は監視を一時停止することをお勧めします。

プロキシ経由監視用の既製ツール

在庫監視のために、ゼロからパーサーを書く必要はありません。プロキシ経由での動作をサポートし、ブロック保護メカニズムが組み込まれた既製ソリューションが多数存在します。技術的準備レベルごとの人気ツールを検討しましょう。

既製SaaSサービス(プログラミング不要)

1. Keepa(Amazon用)
Amazon監視専用サービス。価格、在庫、評価を追跡。組み込みプロキシシステムがあり、技術知識不要。欠点 — Amazonのみで動作。

2. Parsehub
グラフィカルインターフェースでデータ収集を設定できるビジュアルパーサー。プロキシ設定、IPローテーション、リクエスト間遅延をサポート。プログラミングスキルのないユーザーに適しています。

3. Octoparse
より高度な自動化機能を持つParsehubの類似品。Amazon、eBayを含む人気マーケットプレイス用の組み込みテンプレートがあります。クラウドタスク実行と自動プロキシローテーションをサポート。

プログラムソリューション(設定が必要)

1. Scrapy(Python)
Pythonの強力なパースフレームワーク。組み込みプロキシサポート、ローテーション用ミドルウェア、エラー処理があります。プログラミングスキルが必要ですが、最大の設定柔軟性を提供します。

Scrapyでのプロキシ設定例はsettings.pyファイルにあります — ローテーション用ミドルウェアとプロキシサーバーリストを追加します。フレームワークは利用可能なIP間でリクエストを自動的に分散します。

2. Puppeteer / Playwright(JavaScript)
Chrome/Firefox自動化用ヘッドレスブラウザ。JavaScriptと複雑な保護を持つサイトのパースに最適。ブラウザレベルでのプロキシ設定、実際のユーザー行動のエミュレーションをサポート。

3. Selenium
クラシックなブラウザ自動化ツール。Puppeteerより遅く動作しますが、より多くの既製ソリューションと例があります。初心者開発者に適しています。

マーケットプレイス専用ソリューション

1. МойСклад(Wildberries、Ozon統合)
ロシアのマーケットプレイスとの組み込み統合を持つ会計システム。在庫を自動同期しますが、公式APIのみで動作 — 競合他社の監視には適していません。

2. Mpstats
WildberriesとOzon用の分析サービス。商品、価格、在庫に関するデータを収集。独自のプロキシインフラストラクチャがあり、追加設定不要。有料ですが安定しています。

3. SellerFox
ロシアのマーケットプレイスのセラー向け包括的ソリューション。競合他社監視、分析、価格自動化を含みます。独自のプロキシで動作します。

パーサー用プロキシの段階的設定

典型的なシナリオの例で在庫監視用プロキシの実践的設定を解説します:Wildberriesで30分ごとに100商品を監視。この手順はほとんどの既製パーサーと自作ソリューションに適用できます。

ステップ1:プロキシの選択と購入

Wildberriesにはレジデンシャルプロキシが必要です。必要数を計算しましょう:
- 100商品 × 1時間あたり2回チェック = 200リクエスト/時
- Wildberriesの安全制限:IP当たり20リクエスト
- 必要数:200 ÷ 20 = 最低10 IPアドレス

余裕を持って取ることをお勧めします:安定動作のために15〜20 IP。プロキシ購入時に、プロバイダーが時間またはリクエストベースのローテーションをサポートしていることを確認してください。

ステップ2:接続データの取得

購入後、次の形式でデータを受け取ります:

ホスト: proxy.example.com
ポート: 8080
ログイン: user123
パスワード: pass456
タイプ: HTTP/HTTPSまたはSOCKS5

一部のプロバイダーは自動ローテーション用URLを提供します:

http://user123:[email protected]:8080

このURLはほとんどのパーサーで直接使用できます — プロキシサーバーが設定に従ってIPを自動的に変更します。

ステップ3:既製ツールでの設定(Octoparse)

1. パースタスク設定を開く
Octoparseで「Advanced Options」→「Proxy Settings」セクションに移動

2. プロキシデータを入力:

• Proxy Type: HTTPまたはSOCKS5を選択(プロキシに応じて)
• Server: proxy.example.com
• Port: 8080
• Username: user123
• Password: pass456

3. ローテーションを設定:
プロバイダーが自動ローテーションをサポートしている場合 — 単に「Use rotating proxy」オプションを有効にします。そうでない場合 — IPリストを手動で追加し、10分間隔で「Rotate IP addresses」を有効にします。

4. 遅延を設定:
「Speed Settings」セクションでリクエスト間遅延を設定:4〜7秒(4000〜7000msのランダム遅延)。

ステップ4:設定のテスト

本格的な監視を開始する前に、必ず設定をテストしてください:

• プロキシへの接続を確認 — ほとんどのツールに「Test connection」ボタンがあります
• 5〜10商品のパースを実行 — データが正しく収集されることを確認
• ログでエラーを確認 — 403、429、503コードはプロキシの問題または頻度が高すぎることを示します
• IPが変更されることを確認 — ログにローテーション設定に従って異なるアドレスが表示されるはずです

ステップ5:監視と最適化

起動後、定期的に確認してください:

• 成功率 — 成功リクエストの割合は95%以上であるべきです
• レスポンスコード — 429または503が5%以上頻繁に表示される場合 — 負荷を下げてください
• プロキシの速度 — 遅延が2〜3秒を超える場合、プロバイダーを変更する価値があるかもしれません
• データの鮮度 — 取得したデータをマーケットプレイスサイトの実際のデータと比較してください

徐々に設定を最適化してください:1週間安定して動作している場合、チェック頻度を少し増やすか遅延を減らすことができます。しかし、これは段階的に、一歩ずつ行ってください。

よくある間違いと回避方法

プロキシを正しく設定しても、初心者はブロックやパーサーの不安定な動作につながる間違いをよく犯します。最も一般的な問題とその解決方法を解説します。

間違い1:すべてのリクエストで同じUser-Agentを使用

問題: パーサーがIP変更時でも同じUser-Agentヘッダーですべてのリクエストを送信。これは疑わしく見えます — 同じ「ブラウザ」が異なるアドレスから現れます。

解決策: IPアドレスと一緒にUser-Agentをローテーションします。人気ブラウザ(Chrome、Firefox、Safari各バージョン)のリストを作成し、プロキシ変更時にランダムに選択します。ほとんどのパースライブラリにUser-Agentローテーションの組み込みサポートがあります。

間違い2:頻繁すぎるIPローテーション

問題: 一部の人は毎リクエスト後にIP変更を設定し、これが最も安全だと考えます。実際には、これは不自然に見えます — 実際のユーザーは毎秒IPを変更しません。

解決策: 合理的なローテーション間隔を使用:5〜15分または1 IPあたり20〜100リクエスト。これは、1つのデバイスからしばらく滞在し、その後切り替える実際のユーザーの行動を模倣します。

間違い3:Cookieの無視

問題: パーサーがリクエスト間でCookieを保存せずにリクエストを送信。マーケットプレイスはセッション追跡にCookieを使用 — 保存しない場合、各リクエストが新しいセッションのように見えます。

解決策: 常に最初のリクエスト後にCookieを保存し、後続のリクエストで送信します。IP変更時に新しいCookieで新しいセッションを作成 — これは新しいユーザーを模倣します。

間違い4:リクエスト間の固定遅延

問題: すべてのリクエスト間に正確に5秒の遅延を設定。これはアンチボットシステムで簡単に検出される完璧なパターンを作成します。

解決策: 範囲内のランダムな遅延を使用します。5秒の代わりにrandom(4, 7)秒を使用します。時々より長い休止(10〜20秒)を追加し、ユーザーの気晴らしを模倣します。

間違い5:安価な公開プロキシの使用

問題: 無料または非常に安価な公開リストを使用してプロキシを節約しようとする試み。これらのIPは、何千もの他のパーサーによって使用されているため、ほとんどのマーケットプレイスで既にブロックされています。

解決策: 信頼できるプロバイダーからの高品質レジデンシャルプロキシに投資してください。これは安定動作の基盤です。プロキシの節約は、ブロックとの戦いに時間を費やし、データ損失の可能性につながります。

間違い6:エラー処理の欠如

問題: パーサーがエラーを処理せず、429(Too Many Requests)または503(Service Unavailable)を受け取った後もサーバーへのリクエストを続けます。

解決策: スマートなエラー処理を実装:

• 429受信時 — 遅延を2倍にしてIPを変更
• 503受信時 — 5〜10分間休止
• 403受信時 — すぐにIPを変更して設定を確認
• 指数バックオフを使用:繰り返しエラー時に休止を指数関数的に増やす

まとめ

プロキシを使用した在庫監視の設定は、eコマースビジネスの成功に不可欠な投資です。適切に設定されたシステムにより、競合他社の在庫を安定して追跡し、価格を迅速に調整し、市場での競争優位性を維持できます。

重要なポイント:

• WildberriesやOzonなどの主要マーケットプレイスには、レジデンシャルプロキシが必須
• IPローテーションは5〜15分ごとまたは20〜100リクエストごとに設定
• リクエスト間に常にランダムな遅延を追加(4〜7秒)
• User-AgentとCookieを適切に管理
• エラーを監視し、負荷を適応的に調整

保守的な設定から始め、システムの動作を監視しながら徐々に最適化してください。プロキシへの投資とツールの適切な設定は、ブロックとの戦いやデータ損失に費やす時間を節約し、ビジネスの成長に集中できるようにします。

高品質なプロキシが必要な場合は、ProxyCoveをご覧ください。在庫監視タスクに最適化されたレジデンシャルおよびモバイルプロキシを提供しています。