プロキシを通じた並列および逐次リクエスト：ブロックなしでメソッドを選ぶ方法

マーケットプレイスのパース、ソーシャルメディアの自動化、またはAPIを介したデータ収集において、リクエストの送信戦略を正しく選択することが極めて重要です。誤った設定はIPのブロック、CAPTCHA、そして時間の浪費を引き起こします。このガイドでは、最大速度のために並列リクエストを使用すべき時と、安全性のために順次リクエストを使用すべき時を解説します。

並列リクエストと順次リクエストの違い

順次リクエストとは、スクリプトやプログラムがリクエストを一つずつ送信することです：最初のリクエストの応答を待ってから、次のリクエストを送信します。これは遅いですが、安全で、ターゲットサイトにとって自然に見えます。

並列リクエストとは、以前のリクエストの応答を待たずに、同時に複数のリクエスト（5、10、50、または数百）を送信することです。これは何倍も速いですが、サーバーに負荷をかけ、アンチフロードシステムの疑念を引き起こす可能性があります。

例えば、Wildberriesで10,000商品の価格をパースすることを想像してみてください。リクエスト間に2秒の遅延を設けて順次に行うと、20,000秒、つまり5.5時間かかります。20の並列スレッドを起動すれば、わずか16分です。違いは明らかですが、いくつかの注意点があります。

メソッドの比較

並列リクエストを使用するタイミング

並列リクエストは、速度が重要で、大量のデータがある場合に選択されます。しかし、正しいプロキシ設定と負荷管理が必要です。

並列リクエストの理想的なシナリオ

1. 大規模なカタログを持つマーケットプレイスのパース
WildberriesやOzonから50,000商品の価格を収集する必要がある場合、順次パースは数日かかります。20-30の並列スレッドとデータセンターのプロキシを使用すれば、数時間で完了します。

設定：20-30のスレッドを使用し、それぞれに別々のIPを割り当て、スレッド内のリクエスト間に1-3秒の遅延を設けます。100-200リクエストごとにIPをローテーションします。

2. 公開APIからのデータ収集
多くのAPI（例えば、天気サービス、企業データベース、ジオロケーションサービス）は、1つのIPからのリクエストに制限を設けています：1日あたり100-1000リクエスト。プロキシプールを介した並列リクエストにより、制限を回避できます。

例：10,000社のデータをAPIを介して収集する必要があります。制限はIPごとに500リクエスト/日です。20のプロキシを並列で使用すれば、20日ではなく1日で10,000リクエストを達成できます。

3. リソースの可用性チェック
サイトの可用性をチェックしたり、ミラーの動作を確認したり、サーバーのステータスを監視したりする場合、並列リクエストは数時間を節約します。ここでは人間の行動を模倣する必要はなく、速度が重要です。

4. 大規模なプロキシのチェック
大量のプロキシプール（1,000以上のIP）を購入する場合、迅速にその機能性、速度、ジオロケーションを確認する必要があります。順次チェックは数時間かかりますが、並列チェックは数分で済みます。

並列リクエストのための重要な要件

• 大規模なプロキシプール（最低10-20 IP、できれば50-100以上）
• エラー時の自動IPローテーション
• 同時スレッド数の管理（50-100を超えない）
• スレッド内のリクエスト間の遅延（0.5-2秒）
• ブロックの原因を分析するためのエラーロギング
• タイムアウト時の再試行システム

順次リクエストを使用するタイミング

順次リクエストは、安全性と信頼性を速度よりも重視する選択です。これは実際のユーザーの行動を模倣し、保護されたプラットフォームでのブロックリスクを最小限に抑えます。

順次リクエストの必須シナリオ

1. 広告管理システムでの作業
Facebook Ads、TikTok Ads、Google Adsは、IPだけでなく行動パターンも追跡します。1つのアカウントからの並列リクエストはすぐに疑念を引き起こします。1アカウント＝1スレッド＝5-15秒の遅延を持つ順次のアクションです。

例：あなたはDolphin Antyのアンチデテクトブラウザを介して20のFacebook広告アカウントを管理しています。各アカウントはモバイルプロキシを使用して、個別のプロファイルで動作し、アクションは厳密に順次です：ログイン→統計の確認→入札の調整→ログアウト。アクション間の遅延は7-12秒です。

2. ソーシャルメディアでのアクションの自動化
Instagram、TikTok、VKは、いいね、フォロー、コメントに厳しい制限を設けています。制限を超えたり、あまりにも速いアクションを行うと、シャドウバンや完全なブロックが発生します。ランダムな遅延20-60秒の順次リクエストのみが必要です。

Instagramの設定：1アカウントは最大60いいね/時を行います。これは1分間に1いいねで、45-75秒の遅延を設けます（ランダム化が重要です！）。各アカウントには別々のプロキシを使用します。

3. アカウントへのログインと個人アカウントでの作業
アカウントへのログインを必要とするすべてのアクション（メールサービス、銀行、マーケットプレイスとしての販売者）は、順次に実行する必要があります。異なるIPからの並列ログイン試行は、ブロックの直接的な原因となります。

4. 厳しいアンチボット保護を持つサイト
Cloudflare、Akamai、PerimeterXを使用しているプラットフォームは、リクエストの頻度だけでなく、そのパターンも分析します。1つのIPまたはUser-Agentから同時に10のリクエストが送信されると、これは明らかにボットの兆候です。3-10秒の遅延を持つ順次リクエストは自然に見えます。

5. 小規模なデータ量
もし50-100ページをパースする必要がある場合、順次パースと並列パースの時間差は重要ではありません（5分対1分）。しかし、順次メソッドは問題が発生しないことを保証します。

順次リクエストのための正しい遅延

異なる方法によるブロックリスク

リスクを理解することで、正しい戦略を選択し、保護を設定することができます。ブロックは、リクエストの頻度だけでなく、そのパターンによっても発生します。

アンチフロードシステムが追跡するもの

1. 1つのIPからのリクエストの頻度
1つのIPから1分間に100リクエストが送信されると、これは明らかにボットです。制限は異なります：通常のサイトは10-30リクエスト/分に耐えますが、保護されたプラットフォームは2-5リクエスト/分です。

並列リクエストの解決策：リクエストを大規模なIPプールに分散させます。例えば、1分間に1,000リクエスト＝50 IPで20リクエストずつ行います。これは50人の通常のユーザーのように見えます。

2. リクエスト間の同じ間隔
リクエストが正確に2.00秒ごとに行われると、自動化の兆候です。人間は異なる間隔でクリックします：1.8秒、3.2秒、2.1秒。

解決策：基本的な遅延から±30-50%のランダム化を追加します。固定の5秒ではなく、random(3.5, 7.5)を使用します。

3. ユーザーの典型的な行動がないこと
実際のユーザーは商品ページに直接移動することはありません。最初にホームページにアクセスし、カテゴリを探し、商品をクリックします。ボットはすぐに特定のURLをリクエストします。

重要なプラットフォームの解決策：ユーザーの完全な経路を模倣します。商品をパースする前に、2-3のリクエストを行います：ホーム→カテゴリ→商品。これにより作業が遅くなりますが、ブロックリスクを70-80%低下させます。

4. 疑わしいUser-Agentとヘッダー
古いUser-Agent（例えば、2024年のChrome 95）、Accept-LanguageやRefererヘッダーが欠如していることはボットの兆候です。

解決策：最新のUser-Agent（Chrome 120+、Firefox 120+）を使用し、実際のブラウザのように完全なヘッダーセットを追加します。IPとともにUser-Agentをローテーションします。

ブロックリスクの比較

各メソッドに適したプロキシ

プロキシの種類は、並列リクエストまたは順次リクエストの使用可能性に直接影響します。誤った選択はブロックや過剰な支出につながります。

並列リクエスト用のプロキシ

データセンターのプロキシは、大規模なパースと並列リクエストに最適な選択です。安価（IP/月あたり1-3ドル）、高速（ping 20-50 ms）、大量に利用可能です。欠点は、プロキシとして簡単に特定されるため、保護されたプラットフォームには適さないことです。

使用するタイミング：マーケットプレイスのパース、公開ソースからのデータ収集、リソースの可用性チェック、厳しい保護がないサービスへの大規模APIリクエスト。

設定：50-100のIPプールを購入し、20-30の並列スレッドを設定します。各スレッドは独自のIPを使用します。100-200リクエストごとにローテーションまたはエラー時にローテーションします。

レジデンシャルプロキシは、より高価（1GBのトラフィックあたり3-7ドル）ですが、実際のユーザーのように見えます。速度が必要な保護されたプラットフォームへの並列リクエストに適していますが、注意が必要です。

使用するタイミング：ソーシャルメディアのパース（認証なし）、Cloudflareを使用しているサイトからのデータ収集、データセンターをブロックするプラットフォームでの作業。並列リクエストには、自動IPローテーションを持つ大規模なIPプールが必要です。

重要：レジデンシャルプロキシを介した並列リクエストでは、トラフィックの消費を監視してください。10,000リクエストは5-10GBを消費し、20-50ドルの費用がかかる可能性があります。データセンターは安価で、100 IPあたり100-200ドル/月で無制限のトラフィックを提供します。

順次リクエスト用のプロキシ

モバイルプロキシは、保護されたプラットフォームでの作業に最も信頼性の高いタイプです。IPは実際のモバイルデバイス（4G/5Gオペレーター）のように見え、ブロックリスクを最小限に抑えます。欠点は、高価（IP/月あたり50-150ドル）であることです。

使用するタイミング：Facebook Ads、Instagram、TikTok、Google Adsなど、実際のユーザーの模倣と最大の安全性が必要なすべての場所。1アカウント＝1モバイルプロキシ＝順次のアクションです。

設定：各広告アカウントまたはソーシャルメディアアカウントは、個別のモバイルIPに結びつけられます。アクションは厳密に順次で、10-60秒の遅延があります。IPはローテーションしません（1つのアカウントは常に1つのIPで動作します）。

レジデンシャルプロキシは、予算が限られている場合のモバイルプロキシの良い代替手段です。認証が必要なパース、自動化SMM、販売者としてのマーケットプレイスでの作業に適しています。

使用するタイミング：マーケットプレイスアカウントの管理（Wildberries、Ozonとしての販売者）、ソーシャルメディアでの投稿の自動化（大量ではない）、認証が必要なデータのパース。

プロキシ選択の推奨事項

最適な設定：遅延、スレッド、タイムアウト

パラメータの正しい設定は、速度と安全性のバランスを取るために重要です。あまりにも攻撃的な設定はブロックを引き起こし、あまりにも慎重な設定は時間の浪費につながります。

並列リクエストの設定

同時スレッド数（concurrency）
これは重要なパラメータです。スレッドが多すぎると、プロキシとターゲットサーバーに過負荷がかかります。スレッドが少なすぎると、速度が低下します。

推奨事項：

• マーケットプレイスのパース：50以上のプロキシプールで20-50スレッド
• 公開API：10-30スレッド、APIの制限に基づいて調整
• 保護されたサイト：5-15スレッド、それ以上はブロックリスクが高まります
• プロキシのチェック：50-100スレッド（ここでは速度が重要）

スレッド内の遅延
並列作業を行っても、各スレッドはリクエスト間に休止を設ける必要があります。これにより、1つのIPへの負荷が軽減され、ブロックリスクが減少します。

推奨事項：

• 簡単なサイト：1スレッド内のリクエスト間に0.5-2秒
• マーケットプレイス：1-3秒、±30%のランダム化を含む
• Cloudflareを使用したサイト：2-5秒、±40%のランダム化を含む
• 制限のあるAPI：制限に基づいて計算（例えば、1分間に100リクエスト＝0.6秒/リクエスト、余裕を持って1秒に設定）

タイムアウト（timeout）
サーバーからの応答を待つ時間です。タイムアウトが短すぎると、遅い応答のためにデータが失われます。長すぎると、スレッドがハングします。

推奨事項：

• 速いサイト：10-15秒
• 遅いサイト/API：20-30秒
• レジデンシャルプロキシを介して：+5-10秒（データセンターより遅い）
• 接続タイムアウト：5-10秒（接続の確立時間）

再試行（retry）
エラー（タイムアウト、503、プロキシのブロック）の場合、別のIPでリクエストを再試行する必要があります。再試行なしでは、データの一部を失うことになります。

設定：リクエストごとに2-3回の試行、各失敗した試行後にプロキシを変更し、再試行前に3-5秒の休止を設けます。

順次リクエストの設定

リクエスト間の基本的な遅延
プラットフォームとアクションのタイプによって異なります。主なルールは、実際のユーザーを模倣することです。

プラットフォームごとの推奨事項：

• Facebook Ads（ダッシュボード間の移動）：7-15秒
• Instagram（いいね）：45-90秒、最大60いいね/時
• Instagram（フォロー）：60-120秒、最大30フォロー/時
• TikTok（視聴）：30-60秒
• 認証が必要なパース：3-7秒
• マーケットプレイス（販売者のダッシュボードでのアクション）：5-10秒

ランダム化
すべての順次リクエストに必須です。基本的な遅延から±30-50%の偏差を使用してください。

例：基本的な遅延が10秒の場合、±40%のランダム化→実際の遅延は6-14秒になります（毎回ランダムな値）。

タイムアウト
順次リクエストでは、すべてのスレッドがブロックされるリスクがないため、より長いタイムアウトを使用できます。

推奨事項：保護されたプラットフォーム（Facebook、Instagram）には30-60秒、通常のサイトには15-30秒を使用します。

両方のメソッドを実現するためのツール

ツールの選択は、あなたのタスクと技術的スキルに依存します。ビジネスのタスク（アービトラージ、SMM、eコマース）には、コードなしで使用できるソリューションを使用してください。技術的なタスクには、ライブラリやフレームワークを使用します。

コードなしのビジネス向けソリューション

マルチアカウント用のアンチデテクトブラウザ
広告管理システムやソーシャルメディアを扱う場合、アンチデテクトブラウザは業界の標準です。これらは自動的にプロキシ、ブラウザのフィンガープリンティングを管理し、アカウントを隔離します。

人気のソリューション：

• Dolphin Anty：Facebook/TikTokのアービトラージャー向けのリーダー、10プロファイルまでの無料プラン、プロキシの設定が簡単
• AdsPower：eコマース（Amazon、eBay）向けに優れた自動化機能を持つRPA（コードなし）
• Multilogin：最も高価（$100+/月）ですが、真剣なアービトラージ用の最大の保護
• GoLogin：予算に優しい代替品（$25/月）、SMMや小規模チームに適しています

プロキシとの連携方法：ブラウザプロファイルを作成→プロキシを関連付け→このプロファイル内のすべてのアクションはこのIPを介します。1プロファイル＝1アカウント＝順次のアクション。並列作業を行うには、複数のプロファイルを同時に開きます（各プロファイルにそれぞれのプロキシを使用）。

パーサーとスクレイパー（既製品）
マーケットプレイスやサイトからデータを収集するためのGUIを持つ既製のツールがあります。

• Octoparse：ビジュアルパーサーコンストラクター、プロキシのサポート、インターフェースを介した並列スレッドの設定が可能
• ParseHub：Octoparseの類似品、200ページまでの無料プラン、GUIを介した遅延の設定
• Scrapy Cloud：Scrapyスパイダーを実行するためのクラウドサービス（Pythonの最小限の知識が必要）

SMMの自動化（コードなし）
ソーシャルメディアを管理するためのインターフェースを介した自動化サービスがあります。

• Jarvee：Instagram、TikTok、Twitterの自動化、プロキシの内蔵サポート、GUIを介した遅延の設定（注意：攻撃的な自動化はブロックを引き起こす）
• Ingramer（Inflact）：Instagramの安全な自動化、彼らのプロキシを介して動作
• Combin：Instagramでのターゲットフォロー/いいね、外部プロキシのサポート

技術的なツール（開発者向け）

自分のパースや自動化のスクリプトを書く場合は、信頼性のあるライブラリを使用してください。

Python（パースに最も人気）：

• Requests + threading/asyncio：簡単な並列リクエスト用、プロキシの設定が簡単
• aiohttp：高並列リクエスト用の非同期ライブラリ（1000以上同時）
• Scrapy：パース用のフレームワーク、プロキシローテーションの内蔵サポート、遅延用のミドルウェア
• Selenium：JavaScriptを使用したサイト用、遅いが多くの保護を回避
• Playwright：Seleniumの現代的な代替、より速く便利

JavaScript/Node.js：

• Axios：HTTPリクエスト用の人気ライブラリ、プロキシの設定が簡単
• Puppeteer：ヘッドレスChromeを使用した自動化ライブラリ、JavaScriptでの操作が可能