> ## Documentation Index
> Fetch the complete documentation index at: https://www.octoparse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# JavaScriptで描画されるページのスクレイピング

> 最近のサイトはReactやVue、素のJSでクライアント側で描画されます。基本的なHTTPスクレイパーが通用しない理由と、実ブラウザでの描画・APIの傍受・SSR検知という3つの解法。

最近のWebサイトの大半は、もはやコンテンツを静的なHTMLとして配信していません。React・Vue・Angularのようなフレームワークは、ブラウザの中でページを動的に組み立てます — サーバーは最小限のHTMLシェルとJavaScriptバンドルを送るだけで、実際のコンテンツはクライアント側でそのJavaScriptが実行された後にはじめて現れます。Pythonの`requests`のような基本的なHTTPスクレイパーが、ほぼ空のページを返してくることが多いのはこのためです — 生のHTMLは取得しますが、それを欲しいデータで埋めるJavaScriptは実行しません。

解決策は3つあり、サイトの作り方によってどれが正解かが変わります。**当てはまる中で最も安いものが勝つ**ので、順番に確認していきましょう。

## アプローチ1:実際のブラウザでページを描画する

汎用の解は、ユーザーのブラウザとまったく同じようにJavaScriptを実行する実ブラウザエンジンを動かすことです。ページが読み込まれ、スクリプトが走り、API呼び出しが飛び、コンテンツが描画される — そこから初めて、スクレイパーは完全に埋まったDOMからデータを抽出します。これはJavaScript描画のどんなサイトにも効きますが、コストが上がります — ページごとにブラウザインスタンスを立ち上げるため、実際のメモリとCPUを消費します。

*どの*ブラウザエンジンを動かすかは、また別の選択です — ライブラリ(Puppeteer・Playwright・Selenium)、クラウドAPI、ヘッド付き / ヘッドレスのトレードオフ。フルメニューは[ブラウザ実行環境の全景](/docs/jp/academy/browser-runtime-landscape)、そしてスクレイピングで最も効くヘッド付き / ヘッドレスの判断は[ヘッド付き vs ヘッドレスブラウザ](/docs/jp/academy/headed-vs-headless-browsers)を参照してください。実行環境のオーバーヘッドは規模が大きくなるほど効いてくるため、専用設計のエンジンは素のブラウザよりページあたりの消費が大幅に少なくなります。

## アプローチ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`イベントを監視するロジックはこの遷移を見逃します — 代わりにコンテンツの変化を待ちましょう。
* **無限スクロールや「もっと見る」は、観察ではなく操作が必要**。これらのパターンの深い扱いは[ページネーションの扱い方](/docs/jp/academy/handle-pagination)を参照してください。

## 最も安い解法を先に試す

確実な戦略はこの順序で確認することです:

1. **ソースを見る**。コンテンツが生のHTMLに入っていれば、それで終わり — HTTPリクエスト1つで済みます。
2. **ネットワーク呼び出しを覗く**。ページがAPIからコンテンツを取得しているなら、そのAPIを直接呼びましょう。速く、軽く、信頼性が高い。
3. **実ブラウザで描画する**。上のどちらでもないとき、ページを実際に動かします。操作者プロファイルと対象サイトの防御に合った実行環境を選びます。

この順序が重要な理由:各ステップが上がるごとに、レイテンシ・インフラ・壊れやすさのコストが上がります。本当にブラウザ描画が必要なサイトをスクレイピングするコストは、APIを直接叩けるサイトと比べて桁違いに高く、何千ページにもなれば差は積み上がります。

1つのワークフローの中で、ページタイプごとに異なるアプローチが必要なとき — あるページはSSR、あるページはAPI取得、あるページは完全クライアント描画 — 同じタスクの中で戦略を切り替えられるプラットフォーム(描画済みページでの視覚的選択、API向けのネットワーク検査、描画が必要なときの実行環境選択)は、3種類のツールチェーンを継ぎ合わせる手間を省きます。