プロキシを通じた自動的な公共調達と入札の監視：ブロックなしの設定

EIS（Zakupki.gov.ru）、Sberbank-AST、RTS-tenderのプラットフォームでの入札の手動監視は、毎日3〜5時間を要します。パーサーを通じた自動化はこの問題を解決しますが、政府のプラットフォームは自動リクエストを積極的にブロックしています — IPは50〜100のリクエストの後に禁止されます。プロキシは制限を回避し、企業の主要IPがブロックされるリスクなしに、新しい入札に関するデータを24時間収集することを可能にします。

このガイドでは、さまざまな入札プラットフォームに適したプロキシ、ブロックなしでの自動パースの設定方法、使用する準備されたツール、ブロックにつながる一般的なエラーを回避する方法について説明します。

なぜ入札プラットフォームは自動リクエストをブロックするのか

政府および商業の入札プラットフォームは、自動データ収集に対する多層的な保護を使用しています。これは、パーサーによるサーバーへの負荷が全トラフィックの60〜70％に達する可能性があるため、競争相手が収集したデータをダンピングに使用するため、また、調達参加者の個人データ保護に関する要件があるためです。

統一情報システム（EIS）は、最も保護されたプラットフォームです。このシステムは、各リクエストの次のパラメータを記録します：IPアドレス、ブラウザのUser-Agent、リクエストの頻度、サイト上の行動の順序。1つのIPから1時間に100を超えるリクエストがある場合、またはリクエストが非常に均等に行われる場合（例えば、毎5秒）、IPは24〜72時間ブロックされます。ブロックはサブネット全体に適用されるため、企業全体が影響を受ける可能性があります。

商業プラットフォーム（Sberbank-AST、RTS-tender、Fabrykant）は、より緩やかな保護を使用していますが、疑わしい活動を監視しています。ブロックの主なトリガーは、クッキーの不在、JavaScriptの無効化、ページ間のナビゲーションが速すぎる（ページあたり2秒未満）、リクエスト間の同じ時間間隔です。

入札監視に適したプロキシの種類

入札プラットフォームの監視には、用途に応じた3種類のプロキシが適しています。選択は、パースの量、予算、信頼性の要件によって異なります。

レジデンシャルプロキシは、ほとんどの入札監視タスクに最適な選択です。これらは実際の家庭ユーザーのIPアドレスを使用するため、プラットフォームはリクエストを一般の人々の行動として認識します。EISには、10〜15分ごとにローテーションするロシアのレジデンシャルプロキシを使用することをお勧めします。これにより、1日あたり500〜1000件の入札データをブロックなしで収集できます。

データセンターのプロキシは、より保護されていない商業プラットフォーム（RTS-tender、Fabrykant、B2B-Center）に適しています。これらはレジデンシャルプロキシの3〜5倍安価で、より高速に動作しますが、EISはしばしばこれらのIPを認識してブロックします。これらは、パーサーの初期テストや小規模な地域プラットフォームの監視に使用してください。

モバイルプロキシは、キャリアのIPを使用するため、最大の信頼性を持っています（MTS、Beeline、Megafon）。プラットフォームは、通常、これらのアドレスをブロックすることはありません。なぜなら、1つのキャリアのIPの背後には何千人もの実際のユーザーがいるからです。欠点は、より高いコストです。特に貴重な入札に関与する場合や、レジデンシャルプロキシを使用している際にブロックを受けた場合は、モバイルプロキシを使用してください。

さまざまなプラットフォームの保護の特徴：EIS、Sberbank-AST、RTS-tender

各入札プラットフォームには、パースに対する独自の保護の特徴があります。これらのメカニズムを理解することで、ブロックのリスクを最小限に抑えるようにパーサーを設定できます。

EIS（Zakupki.gov.ru） — 最大の保護

統一情報システムは、すべてのプラットフォームの中で最も厳しい保護を使用しています。主なメカニズムは、1つのIPからのリクエストの制限が100件/時間であり、クッキーとJavaScriptのサポートが必須であり、リファラーのチェック（ユーザーがどこから来たか）、行動要因の分析（ページ上の滞在時間、マウスの動き、スクロール）です。

EISのパースに関する推奨事項：ロシアのIPを持つレジデンシャルまたはモバイルプロキシを使用し、80〜90リクエストごとに自動ローテーションを有効にしてください（制限に達しないように）、リクエスト間に3〜8秒のランダムな遅延を追加し、単純なHTTPリクエストの代わりにヘッドレスブラウザ（Puppeteer、Selenium）を使用してください — これにより、実際のブラウザの動作を完全にエミュレートします。

Sberbank-AST — 中程度の保護レベル

Sberbankのプラットフォームは、より緩やかな制限を使用しています：1時間あたり約200〜300のリクエストの制限、クッキーが必須ですが、JavaScriptは常にチェックされるわけではなく、明らかにロボットのような行動（リクエスト間の同じ間隔、リファラーの不在）でブロックされます。

Sberbank-ASTには、200リクエストごとにローテーションするレジデンシャルプロキシが十分です。ブラウザの完全なエミュレーションなしで使用できるよりシンプルなパースツールを使用できますが、必ず2〜5秒のランダムな遅延と正しいUser-Agentヘッダーを追加してください。

RTS-tender、Fabrykant、B2B-Center — 基本的な保護

商業プラットフォームは最小限の保護を持っています：1時間あたり500以上のリクエストの制限、主なチェックはクッキーと適切なUser-Agentの存在であり、データセンターのプロキシはめったにブロックされません。

これらのプラットフォームには、基本的なローテーションを持つデータセンターのプロキシさえ適しています。ブラウザのエミュレーションなしでシンプルなHTTPパーサーを使用できます。重要なのは、リクエストをあまり頻繁に送信しないこと（リクエスト間に最低1〜2秒）と、定期的にIPを変更することです。

プログラミングなしで入札をパースするための準備されたツール

入札の監視には、ゼロからコードを書く必要はありません。プロキシを通じての作業をサポートするグラフィカルインターフェースを持つ準備されたソリューションがあります。

Octoparse — プロキシとタスクスケジューラをサポートするビジュアルパーサーです。グラフィカルインターフェースを通じて、任意の入札プラットフォームのパーサーを作成できます：収集する必要があるページの要素（入札番号、発注者、金額、締切日）をクリックするだけで、プログラムが自動的にパースアルゴリズムを作成します。設定でプロキシのリストを指定でき、Octoparseは自動的にそれらをローテーションします。料金は月額75ドルからで、制限付きの無料版もあります。

ParseHub — よりシンプルなインターフェースを持つOctoparseの類似品です。初心者に適しています。JavaScriptサイトをサポートしており（EISにとって重要）、プロキシを通じての作業、Excel/Google Sheetsへのデータエクスポートが可能です。無料版では最大5つのパースプロジェクトを作成できます。有料版は月額149ドルからで、スケジュールに従ってパースを実行する機能があります（例えば、2時間ごとに新しい入札をチェック）。

Screaming Frog SEO Spider — 元々はSEOツールですが、構造化データのパースに非常に適しています。プロキシをサポートし、指定されたCSSセレクターに基づいてページからデータを収集できます。欠点は、ページのHTML構造を少し理解する必要があることです。料金は年額149ポンド（約15,000ルーブル）で、類似品よりも安価です。

入札監視の専門サービス — Контур.Закупки、Тендер.Про、B2B-Centerは、すでにフィルターと通知を備えた監視システムを持っています。これらはプロキシの設定を必要とせず、サービスの名義で動作します。料金は、追跡するカテゴリの数に応じて月額5,000〜30,000ルーブルです。欠点は、サービスの機能に依存し、追加データを収集したり、自分のCRMに統合したりできないことです。

プロキシを通じた監視の20分間のステップバイステップ設定

Octoparseを例に、入札の自動監視の設定を見ていきましょう — グラフィカルインターフェースを持つ最も人気のあるツールの1つです。この例は、EIS、Sberbank-AST、その他のプラットフォームの監視に適しています。

ステップ1：プロキシの取得。 プロキシプロバイダーに登録し、IPアドレス、ポート、認証データのリストを取得します。EISの監視には、最低10のロシアのレジデンシャルプロキシが自動ローテーションで推奨されます。プロバイダーは、次の形式でデータを提供します：IP:PORT:USERNAME:PASSWORD（例：185.123.45.67:8000:user123:pass456）。

ステップ2：Octoparseのインストールと設定。 公式サイトからOctoparseをダウンロードし、コンピュータにインストールします。起動後、EISの入札検索結果ページのURLを入力して新しいパースプロジェクトを作成します（例：地域での「機器」というキーワードによる検索）。

ステップ3：Octoparseでのプロキシの設定。 設定 → プロキシ設定を開きます。「カスタムプロキシを使用」を選択します。IP、ポート、タイプ（HTTPまたはSOCKS5）、ログイン、パスワードを指定して、プロキシをリストに追加します。「各リクエストのためにプロキシをローテーションする」オプションを有効にします — これにより、プログラムは各リクエストの後にプロキシを変更し、負荷を分散させ、ブロックを回避します。

ステップ4：パースアルゴリズムの作成。 ビジュアルコンストラクターモードで、収集する必要があるページの要素をクリックします：入札番号、名称、発注者、開始価格、申請締切日、地域。Octoparseは自動的にデータ構造を特定し、収集アルゴリズムを作成します。最初の5〜10件の結果を確認してください — プログラムはパースの予備結果を表示します。

ステップ5：ページネーションの設定。 入札プラットフォームは通常、ページごとに結果を表示します（通常、ページあたり10〜50の入札）。Octoparseに「ページネーションボタンをクリックする」アクションを追加し、「次のページ」ボタンを指定します。プログラムは自動的にページを移動し、すべての結果を収集します。

ステップ6：遅延の追加。 パーサーの設定で、リクエスト間にランダムな遅延を設定します：最低3秒、最大8秒。これは、実際のユーザーの行動を模倣し、ブロックのリスクを低減します。また、各ページの読み込み後に5〜10秒の遅延を追加してください — これはJavaScript要素が完全に読み込まれる時間を提供します。

ステップ7：スケジュールの設定。 「タスクスケジュール」セクションで、自動的にパースを開始するように設定します。新しい入札を監視するためには、労働時間中に2〜4時間ごとにチェックを実行するのが最適です。例えば：9:00、13:00、17:00、21:00。これにより、過度な負荷をかけることなく、1日の新しい公開を追跡できます。

ステップ8：データのエクスポート。 収集したデータを便利な形式（Excel、Google Sheets、MySQLデータベース、またはAPIを介してCRMシステムに送信）で自動的にエクスポートするように設定します。Octoparseは、各パースの実行後に新しいデータを自動的に送信できるため、新しい入札に関するリアルタイムの通知を受け取ることができます。

プロキシのローテーションとリクエスト間の遅延の設定

プロキシのローテーションと遅延の正しい設定は、ブロックなしでの成功したパースのための重要な要素です。質の高いプロキシを使用していても、不適切な構成はブロックにつながります。

プロキシのローテーション戦略： パース中にIPアドレスを変更するための3つの主要なアプローチがあります。

各リクエスト後のローテーション — 最も安全ですが、遅い方法です。各プラットフォームへのリクエストは新しいIPから行われます。大量のデータ（1000件以上の入札）をパースする際のEISに適しています。欠点は、プロキシを介して新しい接続を確立するのに200〜500ミリ秒かかるため、パース時間が増加することです。

リクエスト数によるローテーション — 速度と安全性の最適なバランスです。1つのプロキシは50〜100リクエストに使用され、その後次のプロキシに変更されます。EISには、80リクエストごとにプロキシを変更することをお勧めします（100の制限の少し下）。商業プラットフォームの場合は、1つのIPで200〜300リクエストまで増やすことができます。

時間によるローテーション — リクエスト数に関係なく、10〜15分ごとにIPを変更します。これは、少ない強度での長時間のパース（例えば、1日の更新を監視する）に適しています。一部のプロキシプロバイダーは、時間による自動ローテーションを提供します — 1つのプロキシURLを受け取りますが、IPは自動的にN分ごとに変更されます。

リクエスト間の遅延の設定： 人間はページ間を瞬時に移動することはできません — 読む、スクロールする、クリックするための時間が必要です。パーサーはこの行動を模倣する必要があります。

指定された範囲内でのランダムな遅延を使用することが重要です。パーサーがちょうど5秒ごとにリクエストを行うと、保護システムはロボットを簡単に特定できます。ランダムな遅延機能は、すべての人気のあるパースツールにあります。

ブロックにつながる一般的なエラー

質の高いプロキシを使用していても、パーサーは設定の技術的なエラーによりブロックされる可能性があります。以下は最も一般的な問題とその解決策です。

エラー1：同じUser-Agentの使用。 User-Agentは、サイトにどのブラウザとオペレーティングシステムが使用されているかを通知する文字列です。すべてのリクエストが同じUser-Agent（例えば、Pythonライブラリrequestsの標準）から行われると、これは明らかなボットの兆候です。解決策：異なるブラウザ（Chrome、Firefox、Safari）やオペレーティングシステム（Windows、macOS、Linux）のための10〜20の人気のあるUser-Agentのリストを使用し、各リクエストごとにランダムにローテーションします。

エラー2：クッキーが無効。 ほとんどのサイトは、最初の訪問時にクッキーを設定し、以降のリクエストでその存在を確認します。パーサーがクッキーを保存しない場合、各リクエストは新しいデバイスからの最初の訪問のように見え、これは疑わしいです。解決策：パーサーの設定でクッキーのサポートを有効にします。OctoparseやParseHubでは、これが自動的に行われます。Pythonで独自のパーサーを書く場合は、requests.Session()ライブラリを使用してください — これはリクエスト間でクッキーを自動的に保存します。

エラー3：JavaScriptを実行せずにパース。 現代のサイト、特にEISは、コンテンツの読み込みにJavaScriptを積極的に使用しています。パーサーが単にページのHTMLコードをダウンロードするだけでJavaScriptを実行しない場合、不完全なデータを取得し、サーバーは疑わしい行動を記録します。解決策：ページを完全に読み込み、JavaScriptを実行し、動的コンテンツを読み込むためにページをスクロールできるヘッドレスブラウザ（Puppeteer、Selenium、Playwright）を使用します。

エラー4：キャプチャを無視。 一部のプラットフォームは、疑わしい活動があるとキャプチャを表示します。パーサーがキャプチャを解決できない場合、ハングし、再リクエストを送信し始め、これがIPのブロックにつながります。解決策：キャプチャを自動的に解決するサービス（2Captcha、Anti-Captcha）を使用します — これらは1000件の解決されたキャプチャあたり約1〜3ドルです。ほとんどのパースツールには、これらのサービスとの統合が組み込まれています。

エラー5：ピーク時のパース。 平日10:00から16:00の間は、入札プラットフォームでユーザーの活動が最大であり、保護システムは最も厳しく動作します。この時間帯に集中的にパースすると、ブロックされる可能性が高くなります。解決策：主要なパースのボリュームは、夕方（18:00〜23:00）または夜間に実行します。労働時間中は、最小限の強度で新しい入札をチェックするだけにします。

エラー6：不正なプロキシの使用。 一部の安価なプロキシプロバイダーは、スパムやその他の疑わしい活動にすでに使用されたIPを販売し、ブラックリストに載っています。解決策：大量使用の前にプロキシをテストします。新しいプロキシから各プラットフォームに20〜30のテストリクエストを送信し、キャプチャやブロックが発生しないか確認します。プロキシが「不正」であれば、プロバイダーに交換を依頼します。

10以上のプラットフォームの同時監視

1〜2のプラットフォームの基本的な監視が設定され、安定して動作していると、スケーリングの課題が生じます — 市場の最大のカバレッジを得るために、数十の入札プラットフォームを同時にパースすることです。

プラットフォーム間のプロキシの分配。 同じプロキシを異なるプラットフォームで同時に使用しないでください。プロキシプールを作成します：例えば、EIS用に10のプロキシ、Sberbank-AST用に5、RTS-tender用に5などです。これにより、1つのプラットフォームでのブロックが他のプラットフォームのパーサーの動作に影響を与えることを防ぎます。

プラットフォームの優先順位付け。 すべての入札プラットフォームがあなたのビジネスにとって同じ重要性を持っているわけではありません。最も関連性の高い入札が発表される3〜5の主要なプラットフォームを特定し、それにより多くのリソースを割り当てます：最良のプロキシ、より頻繁なチェック、より詳細なパース（ドキュメントの収集を含む）。他のプラットフォームには、入札の基本的なパラメータの監視だけを行います。

データ処理の自動化。 10以上のプラットフォームをパースする際には、毎日何百もの新しい入札を受け取ります。手動処理は不可能です。自動フィルタリングを設定します：入札名のキーワード、発注者の地域、開始価格の範囲、申請締切日のフィルタリング。すべてのフィルターを通過した入札のみが手動確認のリストに入ります。

CRMおよび通知システムとの統合。 フィルタリングされた入札を自動的にあなたのCRMシステムまたは企業メッセンジャー（Slack、Telegram、Microsoft Teams）に送信するように設定します。マネージャーは、新しい適切な入札に関するリアルタイムの通知を受け取り、参加の決定を迅速に下すことができます。

パーサーの動作の監視。 多くのプラットフォームで作業する際には、各パーサーのステータスを追跡することが重要です。各パーサーが最後にいつ実行されたか、いくつの入札を収集したか、エラーやブロックがあったかを表示するダッシュボードを設定します。Octoparseのようなツールには、組み込みのダッシュボードがあります。独自のスクリプトを使用している場合は、Google SheetsやGrafanaのような専門の監視システムにログ記録を設定できます。

結論

プロキシを通じた政府および商業入札の監視の自動化は、新しい調達に関する情報をリアルタイムで取得し、手動検索で毎日最大4時間を節約し、提出された申請の数を30〜50％増加させることを可能にします。成功の鍵となる要因は、プラットフォームに応じたプロキシの種類の正しい選択、IPのローテーションとリクエスト間の遅延の正しい設定、JavaScriptとクッキーをサポートするツールの使用です。

EISのような保護されたプラットフォームの監視には、ロシアのIPアドレスを持つレジデンシャルまたはモバイルプロキシを使用してください — これにより、最大の信頼性と最小のブロックリスクが確保されます。基本的な保護を持つ商業プラットフォームには、より手頃なデータセンターのプロキシが適しています。2〜3の主要なプラットフォームの自動化から始めて、設定を調整し、その後、業界全体の入札市場にシステムをスケールアップしてください。

24時間体制で入札プラットフォームの監視を設定する予定がある場合は、レジデンシャルプロキシの使用をお勧めします — これにより、保護された政府プラットフォームへのリクエストの高い強度でも、ブロックなしでパーサーが安定して動作します。