【ITニュース解説】We doubled Mercado Libre's scraper memory and clearance went from 50% to 90% - with zero code changes.

Mercado LibreのWebサイトから情報を収集する際、かつて利用できた簡単なAPIが使えなくなり、新たな技術的な課題に直面した話である。この課題解決のプロセスは、システムエンジニアを目指す初心者にとっても、現代のWebスクレイピングがいかに複雑で、注意深い分析が求められるかを示す良い事例となるだろう。

まず、以前はMercado Libreの検索API（api.mercadolibre.com）に匿名でアクセスし、JSON形式で商品データを直接取得できた。これは非常に効率的な方法であった。しかし、このAPIは完全に廃止され、今ではどのような環境からアクセスしても「403 Forbidden」というエラーが返ってくる状態である。これは単にアクセスが一時的にブロックされているのではなく、API自体が利用できなくなったことを意味し、もはやこの方法でデータを取得することは不可能であると判断された。

そこで、データの取得先をWebサイトのHTML検索ページに切り替える必要があった。しかし、HTMLページもまた、ボットによる不正なアクセスを防ぐための強力な対策が施されている。具体的には「Proof-of-Work（プルーフ・オブ・ワーク）」と呼ばれる計算課題が導入されているのだ。これは、アクセス元が人間かボットかを判別するために、コンピュータに特定の計算処理を要求する仕組みである。

このProof-of-Workチャレンジに到達するためには、アクセス元のIPアドレスが非常に重要となる。データセンターのIPアドレスなど、サーバーからのアクセスと識別されやすいIPアドレスでは、本物のチャレンジページにすら到達できない。代わりに、Mercado Libre独自の「疑わしいトラフィック向けの偽のページ」が返される。これは一見成功を示す「200 OK」のステータスコードを返すが、その中身には実際の検索結果は含まれておらず、実質的なソフトブロック（偽装されたブロック）の状態である。この段階では、ログ上は成功に見えるため、エラーの原因を特定するのが難しい。

本物のProof-of-Workチャレンジを受け取れるのは、一般家庭からインターネットに接続しているように見える「居住用プロキシ」と呼ばれる種類のIPアドレスを使った場合のみである。居住用プロキシを使用すると、ようやく本物のチャレンジページが表示され、ブラウザがJavaScriptを実行して計算課題を解くことができるようになる。これは単なるHTTPリクエストだけでは対応できず、実際にブラウザを動作させる環境が必要であることを示している。

そして、このチャレンジをクリアする過程で、非常に興味深い発見があった。当初、スクレイパーの成功率は約50%で、残りの半分はアンチボット対策によってブロックされていると考えていた。しかし、調査を進めると、失敗の原因はアンチボット対策ではなく、スクレイパーを実行する環境に割り当てられたメモリ（RAM）が不足していたためであることが判明したのだ。

Mercado Libreの検索ページは、ブラウザで完全にレンダリングされるまでに約3.3MBものDOM（Document Object Model：Webページの構造データ）を生成する。スクレイパーに割り当てられたメモリが4GBしかなかった場合、このページのレンダリング処理が完了する前に、メモリ不足によってブラウザのプロセスが強制終了（OOM-killed：Out Of Memoryにより強制終了されること）されていたのである。この際のシステムからのエラーメッセージ「TargetClosedError: Target page, context or browser has been closed」は、まるでWebサイト側から接続が切断されたように見えるため、アンチボット対策によるブロックと誤解されやすかった。

そこで、スクレイパーに割り当てるメモリを4GBから8GBに倍増させてみたところ、驚くべきことに成功率が50%から90%へと大幅に向上した。これにより、多くの失敗がアンチボット対策ではなく、自身の実行環境のメモリ不足が原因であったことが明確になったのである。この経験は、「Webサイトが防御が固すぎる」と結論付ける前に、スクレイパー側のリソース（特にメモリ）が十分であるかを確認する重要性を教えてくれる。ブラウザプロセスが強制終了する現象と、Webサイトにブロックされる現象は、ログ上では同じように見えることがあるため、注意が必要である。

一度Proof-of-Workチャレンジをクリアしてセッションが確立されれば、そのセッション内で複数のページをスクレイピングすることが可能である。今回の検証では、最初のページをクリアした後、同じセッション内で最大9ページ（オフセット385）まで、追加のチャレンジなしで情報を取得できることが確認された。これにより、居住用プロキシを使ったチャレンジクリアのコストは、一度払えば多くのデータを取得できるため、効率的であると言える。

ページネーション（次のページへ進む処理）の実装においても、重要な教訓が得られた。以前のバージョンでは、次のページへのURLを算術的に推測してリクエストを送っていたが、実際にはWebサイト側で1ページ目にリダイレクトされていたケースがあった。この場合、リクエストしたURLと実際にアクセスしたURLが異なるため、スクレイパーが「違うページを取得できた」と誤解してしまう可能性がある。これを防ぐためには、リクエストを送ったURLだけでなく、リダイレクト後の「最終的にアクセスしたURL（finalUrl）」を常に確認することが不可欠である。

これらの知見に基づき、Mercado Libreのスクレイパーは高度な対策を施して構築された。具体的には、メキシコに固定された居住用プロキシ上で、Camoufoxというブラウザエミュレーションを使用し、十分なメモリ（8192MB）を割り当てる。また、一時的な拒否（アカウント認証ページや偽のページなど）があった場合は、セッションやIPアドレスをローテーションしながら指数関数的にリトライを繰り返す。もしリトライが尽きてしまうような永続的な拒否があった場合でも、空のデータセットを返すのではなく、明確なステータスメッセージを報告するように設計されている。

このスクレイパーが提供するデータは、商品ID、タイトル、販売者、価格、割引率、分割払い情報、配送情報、商品URL、通貨、検索クエリ、ソースページ、そしてスクレイピング時刻のタイムスタンプなどである。スポンサー枠やおすすめ商品は除外され、純粋なオーガニック検索結果のみが対象となる。料金体系は、1回実行あたり0.20ドルの固定費用と、取得したオーガニックリストの行数に応じて1行あたり0.005ドルが加算される。例えば、1000件の結果を取得するのに約5.20ドルかかる計算である。

このように、Mercado Libreのような強力なボット対策が施されたWebサイトから情報を収集するためには、単にコードを書くだけでなく、Webサイト側の挙動を深く理解し、適切な実行環境と戦略を構築することが不可欠である。特に、エラーメッセージが常に真の原因を示しているとは限らないこと、そして自身の実行環境のリソース状況が、見かけ上のブロックの原因となっている可能性があることを理解することは、システムエンジニアとして問題解決に取り組む上で非常に重要な学びとなるだろう。最終的に、スクレイパーが成功した鍵は、ターゲットが防御しているという思い込みを捨て、ブラウザがページを最後までレンダリングするのに十分なRAMを与えるという、一見単純な結論にあったのである。