マーケットプレイスのパース、競合の価格監視、ソーシャルメディアの自動化を行っている場合、エラー429 Too Many Requestsに直面したことがあるでしょう。サイトはあなたのリクエストを疑わしいと見なし、すべての自動化が停止します。この記事では、この問題がなぜ発生するのか、正しいプロキシ設定、IPのローテーション、負荷の適切な分散を通じてどのように解決するかを解説します。
WildberriesやOzonのパース、競合の監視、ソーシャルメディアのAPIとの連携、大量データの収集など、さまざまなタスクに対する具体的な解決策を示します。すべての推奨事項は実践的な経験に基づいており、実際のプロジェクトで機能します。
エラー429 Too Many Requestsとは何か、なぜ発生するのか
エラー429 Too Many Requestsは、特定の時間内に許可されたリクエスト数を超えたときにサーバーが返すHTTPレスポンスコードです。これは、サイトが過負荷や自動データ収集から保護するためのメカニズムです。
429が発生する典型的な状況は次のとおりです：
- マーケットプレイスのパース — Wildberries、Ozon、またはAvitoから価格を収集する際、1分間に何百ものリクエストを行います。サイトは1つのIPからの異常な活動を検知し、ブロックします。
- 競合の監視 — 商品、価格、在庫に関するデータを自動的に収集します。頻繁なチェックで制限が発動します。
- APIとの連携 — 多くのAPIには厳しい制限があります。たとえば、Instagram APIは1時間に200リクエスト、Twitterは15分間に300リクエストを許可しています。
- 大量登録やアクション — アカウントの作成、メッセージの送信、いいね。プラットフォームは自動化をすぐに検知し、IPをブロックします。
重要なのは、エラー429は単なる技術的制限ではないということです。これは、サイトがあなたの活動を疑わしいと認識したことを示す信号です。同じIPから攻撃を続けると、永久的なバンを受ける可能性があります。
重要： 一部のサイトは429の代わりに403 Forbiddenを返すか、単にキャプチャを表示します。要点は同じです — 制限を超え、ブロックされました。
サイトはどのように疑わしい活動を特定するのか
効果的にブロックを回避するためには、サイトがどのようにあなたを特定するかを理解する必要があります。現代の保護システムは多くのパラメータを分析します：
1. IPアドレスとリクエストの頻度
最も明白なパラメータです。1つのIPから1分間に100リクエストが来る一方で、通常のユーザーは5〜10リクエストを行う場合、これは明らかな自動化です。サイトは制限を設定します：
- Wildberries: 1つのIPから約60リクエスト/分
- Ozon: 約30〜40リクエスト/分
- Avito: 特に検索リクエストに対して厳しい制限
- Instagram API: アプリケーションごとに1時間に200リクエスト
2. User-Agentとブラウザのヘッダー
スクリプトを介して正しいUser-Agentなしでリクエストを送信すると、サイトはすぐにそれが実際のブラウザではないことを理解します。また、Accept、Accept-Language、Refererなどのヘッダーも分析されます。これらのヘッダーが欠落しているか、非典型的な値がある場合は、赤信号です。
3. 行動パターン
実際のユーザーは、2秒ごとに完璧な間隔でリクエストを行うことはありません。スクロール、クリック、間隔を置きます。あなたのパーサーがメトロノームのように動作している場合、それは疑わしいです。
4. IPアドレスのタイプ
多くのプラットフォームはデータセンターのIPをブラックリストに登録しています。AWSやGoogle Cloudの安価なプロキシを使用している場合、ブロックされる可能性が高くなります。実際のプロバイダーからのレジデンシャルIPは、疑いを少なくします。
プロキシのローテーション：制限を回避するための主な方法
エラー429の主な解決策はIPアドレスのローテーションです。すべてのリクエストを1つのIPから行うのではなく、多くのアドレスに負荷を分散させます。各IPは少数のリクエストを行い、制限を超えません。
プロキシのローテーションの種類
| ローテーションのタイプ | 動作方法 | 使用するタイミング |
|---|---|---|
| リクエストごとのローテーション | 各リクエストは新しいIPから行われます。プロキシプロバイダーが自動的にアドレスを変更します。 | 大量のデータを迅速に収集する必要がある場合 |
| タイマーによるローテーション | IPは5〜30分ごとに変更されます。リクエストのシリーズには1つのアドレスを使用します。 | セッションを必要とするサイト（カート、認証）での作業 |
| 静的プロキシのプール | 100〜1000のIPのリストがあります。スクリプトが各リクエストのためにランダムなアドレスを選択します。 | ローテーションと負荷分散を完全に制御する必要がある場合 |
実践的な例：Wildberriesのパース
例えば、10,000商品の価格をパースする必要があるとします。Wildberriesは1つのIPからの60リクエスト/分でブロックします。解決策は：
- リクエストごとのローテーションを使用する — 各リクエストは新しいIPから行われます。約167の異なるIPが必要です（10,000リクエスト / 60リクエスト/分 = 167分が1つのIPでかかりますが、ローテーションを使用すれば10〜15分で行えます）。
- 遅延を設定する — ローテーションがあっても、1秒間に1,000リクエストを行うべきではありません。最適な数は、異なるIPからの5〜10リクエスト/秒です。
- ランダム化を追加する — 遅延はランダムであるべきです：リクエスト間で0.5〜2秒の間隔を設けます。
このようなタスクには、レジデンシャルプロキシが最適です。自動ローテーションを備えたもので、何百万ものIPのプールを持ち、リクエストごとにアドレスを変更します。
リクエスト間の遅延設定
プロキシをローテーションしても、サイトに対して最大速度でリクエストを送信してはいけません。現代の保護システムはサーバーへの全体的な負荷を分析し、DDoSのような活動を見てIPの範囲全体をブロックする可能性があります。
遅延設定のルール
基本ルール：実際のユーザーを模倣する
- 最小遅延：リクエスト間で0.5〜1秒
- 推奨：1〜3秒のランダムなばらつき
- 複雑なサイト（マーケットプレイス、ソーシャルメディア）では：2〜5秒
- エラー時には指数的な遅延を使用する
指数的遅延（exponential backoff）
もしエラー429が発生した場合は、サイトへの攻撃を続けないでください。指数的遅延の戦略を使用します：
- 最初の試みが失敗 → 1秒待つ
- 2回目の試みが失敗 → 2秒待つ
- 3回目の試みが失敗 → 4秒待つ
- 4回目の試みが失敗 → 8秒待つ
- このように続け、最大（たとえば60秒）まで待つ
この戦略はサーバーに「冷却」する時間を与え、永久的なバンの可能性を減少させます。多くのAPI（Google、Twitter）は、このアプローチをドキュメントで推奨しています。
さまざまなタスクに対する設定例
| タスク | リクエスト間の遅延 | コメント |
|---|---|---|
| Wildberriesのパース | 1〜3秒 | プロキシのローテーションを使用すれば0.5〜1秒に加速可能 |
| Ozonのパース | 2〜4秒 | Ozonは自動化に対してより敏感です |
| Instagram API | 18秒 | 制限200リクエスト/時 = 18秒ごとに1リクエスト |
| Google検索のパース | 5〜10秒 | Googleはすぐにバンするため、長い間隔が必要です |
| Avitoの監視 | 3〜6秒 | 厳しい保護、特に検索に対して |
User-Agentとヘッダー：実際のブラウザの模倣
プロキシのローテーションと遅延はリクエストの頻度の問題を解決しますが、それだけでは不十分です。サイトはリクエストをどのように送信しているかを分析します。ヘッダーが疑わしい場合、ブロックは避けられません。
ブラウザを模倣するための必須ヘッダー
各リクエストに必要な最小限のヘッダーセット：
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Cache-Control: max-age=0User-Agentのローテーション
すべてのリクエストに同じUser-Agentを使用しないでください。10〜20の最新のブラウザバージョンのリストを作成し、ランダムに変更します：
- Chrome（Windows、macOS、Linux）
- Firefox（さまざまなバージョン）
- Safari（macOS、iOS）
- Edge（Windows）
よくある間違い： 古いUser-Agent（たとえば、2024年にChrome 90を使用）や、デスクトップサイトに対してモバイルUser-Agentを使用すること。これは自動化を即座に示します。
RefererとOrigin
多くのサイトはリクエストがどこから来たのかを確認します。商品ページをパースする場合、Refererヘッダーにはカタログまたは検索へのリンクが必要です。APIをパースする場合は、正しいOriginが必要です。
Wildberriesのパースの例：
Referer: https://www.wildberries.ru/catalog/0/search.aspx?search=ノートパソコン
Origin: https://www.wildberries.ruエラー429を回避するために選ぶべきプロキシ
プロキシのタイプの選択は非常に重要です。安価なデータセンターのプロキシは、すでにブラックリストに載っていることが多く、リクエストの頻度が低くても429を受け取ることになります。
制限を回避するためのプロキシの種類の比較
| プロキシのタイプ | 利点 | 欠点 | どのタスクに適しているか |
|---|---|---|---|
| データセンター | 高速、低価格 | しばしばブロックされ、簡単に特定される | 保護のない簡単なサイト |
| レジデンシャル | 実際のプロバイダーのIP、特定が難しく、大きなアドレスプール | 高価で、時には遅い | マーケットプレイス、ソーシャルメディア、複雑なサイト |
| モバイル | モバイルオペレーターのIP、最大の信頼性 | 高価で、プールが制限されている | Instagram、TikTok、Facebook Ads |
選択に関する推奨事項
マーケットプレイスのパース（Wildberries、Ozon、Avito）の場合： リクエストごとのローテーションを備えたレジデンシャルプロキシを使用してください。プールは大きい必要があります — 最低でも10,000 IPです。これにより、各IPが少数のリクエストを行い、制限を超えないことが保証されます。
ソーシャルメディアのAPIとの連携の場合： モバイルプロキシが最適な選択です。InstagramやTikTokは、レジデンシャルよりもモバイルオペレーターのIPを信頼します。1つのモバイルIPは、問題なく5〜10のアカウントを処理できます。
競合の価格監視の場合： タイマーによるローテーションを備えたレジデンシャルプロキシ（10〜15分ごと）を使用します。これにより、1つのIPからのリクエストのシリーズを行いながら、セッションを保持しつつ制限を超えません。
簡単なタスク（ニュースやブログのパース）の場合： サイトに重大な保護がない場合、データセンターのプロキシが適している可能性があります。しかし、定期的なブロックに備えてください。
実際のケース：マーケットプレイスとAPIのパース
ケース1：Wildberriesの価格監視（10,000商品の毎日）
タスク： マーケットプレイスのセラーが10,000の競合商品の価格を追跡します。データを1日に2回収集する必要があります。
問題： 1つのIPを使用すると、50〜60リクエストの後にバンされていました。10,000商品のパースは、常にブロックされながら数時間かかっていました。
解決策：
- 50,000 IPのプールを持つレジデンシャルプロキシを接続し、リクエストごとのローテーションを設定しました。
- リクエスト間の遅延を0.5〜2秒のランダムな間隔に設定しました。
- User-Agentのローテーションを追加しました（ChromeとFirefoxの20のバリエーション）。
- RefererとAcceptの正しいヘッダーを設定しました。
結果： 10,000商品のパースが15〜20分で行われ、ブロックは一切ありません。各IPは最大1〜2リクエストを行い、自動化として特定されることはありません。
ケース2：Instagramの自動化（50のクライアントアカウント）
タスク： SMMエージェンシーがInstagramで50のクライアントアカウントを管理します。コンテンツを投稿し、コメントに返信し、統計を収集する必要があります。
問題： Instagram APIはアプリケーションごとに1時間に200リクエストの制限があります。50のアカウントで作業すると、制限は10分で消耗されます。
解決策：
- 10の異なるInstagram APIアプリケーションを作成しました（アプリケーションごとに5アカウント）。
- 各アプリケーションは別々のモバイルプロキシを使用します。
- リクエスト間に18秒の遅延を設定しました（200リクエスト/時 = 18秒ごとに1リクエスト）。
- 429を受け取った場合に指数的遅延を追加しました。
結果： すべての50のアカウントが安定して動作しています。エラー429は非常に稀に発生し（週に1〜2回）、自動的に再試行されます。
ケース3：Avitoのパース（ロシア全土の広告）
タスク： 不動産アグリゲーターがAvitoからロシア全土の広告を収集し、データベースを構築します。
問題： Avitoはロシアのサイトの中で最も厳しい保護を持っています。データセンターの異なるIPからでも10〜15リクエストの後にブロックが始まります。
解決策：
- 地理的に関連するレジデンシャルプロキシに切り替え（パースする都市と同じ都市のIP）。
- リクエスト間の遅延を3〜5秒に増加させました。
- 単純なHTTPリクエストの代わりにヘッドレスブラウザ（Puppeteer）を使用しました。
- ユーザーの行動を模倣：スクロール、クリック、マウスの動き。
結果： 1日で50,000件以上の広告を成功裏にパース。ブロックは95％減少しました。残りの5％は新しいIPでの再試行を通じて処理されます。
ケース4：競合のAPI監視（eコマース）
タスク： オンラインストアが20の競合のAPIを通じて商品の在庫と価格を監視します。
問題： 競合のほとんどのAPIには公開制限（1時間に100〜500リクエスト）があります。これを超えると429が返されます。
解決策：
- 優先順位をつけたリクエストキューを作成（最も重要な商品はより頻繁にチェック）。
- レスポンスヘッダー（X-RateLimit-Remaining）を通じて制限を監視。
- 制限の80％に達した場合に自動的に一時停止。
- 可能な限り各競合に対して複数のAPIキーを使用。
結果： システムは自動的にリクエストを分配し、制限を超えないようにします。データはブロックなしで最大限の頻度で更新されます。
すべてのケースからの一般的な教訓：
エラー429は包括的に解決されます：プロキシのローテーション + 適切な遅延 + 実際の行動の模倣。単一の方法に頼ることはできません。たとえ1,000,000のIPがあっても、疑わしいヘッダーで1秒間に1,000リクエストを行えばブロックされます。
結論
エラー429 Too Many Requestsは、正しいアプローチで回避できるサイトの保護メカニズムです。問題解決の主な原則は次のとおりです：
- IPアドレスのローテーション — 多くのプロキシに負荷を分散させ、各アドレスが最小限のリクエストを行うようにします。
- 適切な遅延 — 1〜5秒のランダムな間隔で実際のユーザーを模倣します。
- 正しいヘッダー — 現在のUser-Agentとブラウザの完全なヘッダーセットを使用します。
- プロキシのタイプの選択 — 複雑なサイト（マーケットプレイス、ソーシャルメディア）にはレジデンシャルまたはモバイルプロキシを使用します。
- エラー処理 — 429を受け取った場合には指数的な遅延を適用し、サイトを再度攻撃しないでください。
目標は、どんな手段を使ってでも保護を欺くことではなく、あなたの自動化ができるだけ自然に見えるようにすることです。現代の保護システムはますます賢くなり、粗暴な力は通用しなくなっています。
マーケットプレイスのパース、競合の監視、ソーシャルメディアの自動化を行う予定がある場合は、レジデンシャルプロキシを試してみることをお勧めします。これにより、大きなIPアドレスプール、自動ローテーション、ブロックのリスクを最小限に抑えることができます。Instagram、TikTok、その他のモバイルプラットフォームで作業するには、実際の通信事業者のIPを持つモバイルプロキシが最適です。