requestsのような基本的なHTTPスクレイパーが、ほぼ空のページを返してくることが多いのはこのためです — 生のHTMLは取得しますが、それを欲しいデータで埋めるJavaScriptは実行しません。
解決策は3つあり、サイトの作り方によってどれが正解かが変わります。当てはまる中で最も安いものが勝つので、順番に確認していきましょう。
アプローチ1:実際のブラウザでページを描画する
汎用の解は、ユーザーのブラウザとまったく同じようにJavaScriptを実行する実ブラウザエンジンを動かすことです。ページが読み込まれ、スクリプトが走り、API呼び出しが飛び、コンテンツが描画される — そこから初めて、スクレイパーは完全に埋まったDOMからデータを抽出します。これはJavaScript描画のどんなサイトにも効きますが、コストが上がります — ページごとにブラウザインスタンスを立ち上げるため、実際のメモリとCPUを消費します。 どのブラウザエンジンを動かすかは、また別の選択です — ライブラリ(Puppeteer・Playwright・Selenium)、クラウドAPI、ヘッド付き / ヘッドレスのトレードオフ。フルメニューはブラウザ実行環境の全景、そしてスクレイピングで最も効くヘッド付き / ヘッドレスの判断はヘッド付き vs ヘッドレスブラウザを参照してください。実行環境のオーバーヘッドは規模が大きくなるほど効いてくるため、専用設計のエンジンは素のブラウザよりページあたりの消費が大幅に少なくなります。アプローチ2:背後のAPIを傍受する
JavaScriptで描画されるページはコンテンツを無から作り出しているわけではなく、バックエンドAPIにXHRやfetchでデータを取りに行っています。そのエンドポイントを特定できれば、ブラウザを描画しなくても直接呼び出して、整った構造化JSONを得られます。これはフルページ描画より速く、軽く、信頼性も高い方法です — 待つDOMもなく、レイアウト変更で壊れるセレクタもなく、データはすでにパース済みで届きます。
注意点は、これらのAPIがドキュメント化されていなかったり、認証が必要だったり、レート制限がかかっていたりすることがあり、予告なく変わる可能性もあることです。手順としては、DevToolsのNetworkパネルを開いた実ブラウザでページを開き、コンテンツが読み込まれるときのリクエストを眺め、欲しいデータをレスポンスに含むXHR / fetch呼び出しを探します。見つかれば、それをブラウザの外でそのまま再現できることが多いです — curlコマンド1つで済むこともあります。
Octoparseはこの仕組みをビジュアルエディタに直接組み込んでいます。内蔵ブラウザはDevToolsと同じネットワークパネルを露出させますが、DOM要素を選ぶのと同じ手つきで背後のAPIレスポンスを選択できます — ポイント&クリックすると、タスクはページを描画する代わりにそのエンドポイントを使うようになります。これにより、典型的な「DevToolsを開いて、呼び出しを探して、ヘッダをコピーして、リクエストを組み直す」というループが、1つの視覚的なステップにまとまります。
このアプローチは、適用できるときはJavaScript描画ページに対する最強の答えです — そして、人々が思っているよりずっと頻繁に適用できます。ブラウザに手を伸ばす前に確認する価値があります。
アプローチ3:サーバーサイドレンダリングを検知する
クライアントサイドフレームワークを使うサイトの中にも、パフォーマンスやSEOのためにサーバーサイドレンダリング(SSR)や静的サイト生成を併用しているものがあります。その場合、最初のHTMLレスポンスにフルコンテンツが含まれている — つまり軽量なHTTPリクエストで足りる可能性があります。ページのソースを表示する(Cmd+U / Ctrl+U、ライブDOMを見せる「検証」ではなく)、生のHTMLにデータがすでにあれば、ブラウザのオーバーヘッドを完全にスキップできます。 さらに踏み込んで、user-agentによって異なるコンテンツを返すサイトもあります — 検索エンジン向けにプリレンダリングしている場合などです。リクエストのuser-agentを既知の検索ボットに設定すると、本来ならJavaScriptが必要なページのサーバー描画版が手に入ることが時々あります。サイトの利用規約を尊重するという通常の留意のもとで、効くときに使う手です。実ブラウザが必要なときの実用的なヒント
実際にブラウザで描画することになったら、失敗パターンは予測可能です:- 「load」ではなく、必要なものが現れるのを待つ。ブラウザのloadイベントはHTMLとアセットが揃ったときに発火しますが、クライアント描画コンテンツはまだ途中かもしれません。ページが「完了する」のではなく、必要な特定のセレクタやテキストが現れるのを待ちましょう。
- 遅延読み込みに注意する。スクロールしないと描画されないコンテンツは、スクレイパーがスクロールするまで存在しません。ほとんどのブラウザ自動化ライブラリはスクロールを模倣できます — コツは、それが必要だと気づくことです。
- クライアントサイドルーティングは伝統的なスクレイパーを混乱させる。SPAでは
/productsから/products/42への遷移はURLを変えるだけで新しいHTTPリクエストを発生させないことがあります。pageloadイベントを監視するロジックはこの遷移を見逃します — 代わりにコンテンツの変化を待ちましょう。 - 無限スクロールや「もっと見る」は、観察ではなく操作が必要。これらのパターンの深い扱いはページネーションの扱い方を参照してください。
最も安い解法を先に試す
確実な戦略はこの順序で確認することです:- ソースを見る。コンテンツが生のHTMLに入っていれば、それで終わり — HTTPリクエスト1つで済みます。
- ネットワーク呼び出しを覗く。ページがAPIからコンテンツを取得しているなら、そのAPIを直接呼びましょう。速く、軽く、信頼性が高い。
- 実ブラウザで描画する。上のどちらでもないとき、ページを実際に動かします。操作者プロファイルと対象サイトの防御に合った実行環境を選びます。