> ## 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.

# Webスクレイパーの構造

> あらゆるWebスクレイパーは同じパイプラインで動きます — 取得・描画・特定・抽出・遷移・保存。各段階とそのつながりを地図にして解説します。

Webスクレイパーは単一のものではなく、パイプラインです。Pythonで書いても、ヘッドレスブラウザを自分で制御しても、[ノーコードツール](/docs/jp/academy/what-is-no-code-web-scraping)でビジュアルに組み立てても、同じ段階が同じ順序で実行されます。この段階を理解しておくと、スクレイパーがどこで壊れるのか、どこで遅くなるのか、どの手法が何を解決するのかが、ずっと見通しやすくなります。

<Steps>
  <Step title="ページを取得する">
    HTTPリクエストを送り、HTMLを受け取る。
  </Step>

  <Step title="ページを描画する">
    ページのJavaScriptを実際のブラウザで実行する。
  </Step>

  <Step title="データを特定する">
    XPathやCSSセレクタで要素を指し示す。
  </Step>

  <Step title="抽出して整える">
    値を取り出し、正規表現で整形する。
  </Step>

  <Step title="サイトを遷移する">
    ページネーションやログインの壁を通過する。
  </Step>

  <Step title="出力を保存する">
    CSV・JSON・データベース・下流のAPI。
  </Step>
</Steps>

最初の5段階はどのページでも順に実行されます。**遷移**は次のページのために**取得**へ戻り、このループ全体が規模を持って実行されます — クラウドで、ローテーティングプロキシの背後で、CAPTCHAを越えて。

## ページを取得する

すべてはリクエストから始まります。スクレイパーはURLにHTTPリクエストを送り、レスポンス — 多くはHTML、ときにJSON — を受け取ります。サーバー側で描画されるシンプルなページなら、この1ステップで必要なものがすべて手に入ります。問題は、このレスポンスがサーバーの送る*初期*ペイロードにすぎないことです。最近の多くのサイトでは、それはほぼ空の入れ物です。

## ページを描画する

サイトがJavaScriptでコンテンツを構築している場合、欲しいデータは初期HTMLには含まれず、ページのスクリプトが実行された後にはじめて現れます。描画とは、そのスクリプトを実際のブラウザで実行し、完全なコンテンツを実体化させる段階です。ここで使う[ブラウザ実行環境](/docs/jp/academy/browser-runtime-landscape)が、ページの読み込みの忠実さと、メモリ・速度のコストを左右し、[JavaScriptで描画されるページのスクレイピング](/docs/jp/academy/scrape-javascript-pages)の中核となります。

## データを特定する

ページが完全に読み込まれたら、スクレイパーは欲しい要素 — 価格、タイトル、テーブルの一行 — を正確に指し示さなければなりません。これは[XPathやCSSセレクタ](/docs/jp/academy/xpath-css-selectors)で行い、要素がページ構造の*どこ*にあるかを記述します。良いセレクタは、わずかなレイアウト変更に耐えるスクレイパーと、サイト更新のたびに壊れるスクレイパーの分かれ目です。

## 抽出して整える

要素を特定すると、その生のコンテンツが得られます。抽出はそこから値を取り出し、整形はそれをきれいにします。スクレイピングした価格が、数値だけが欲しいのに `"$1,299.00 USD"` という形で得られることもあります。[正規表現と後処理ルール](/docs/jp/academy/refining-data-with-regex)で生のテキストを削り、分割し、再整形して、実際に保存したい構造化フィールドにします。

## サイトを遷移する

ほとんどのデータセットは複数ページにまたがります。スクレイパーはすべてのレコードに到達するため、[ページネーション](/docs/jp/academy/handle-pagination) — 次ページのリンク、「もっと見る」ボタン、無限スクロール — をたどる必要があります。また一部のコンテンツは[ログインの壁](/docs/jp/academy/scraping-login-walls)の向こうにあり、それ以前の段階を実行する前に、スクレイパーが認証を通過しなければなりません。

## 規模を持って実行する

ノートPCで一度だけ動くスクレイパーも、何千回もの実行を生き延びなければなりません。[クラウドで実行する](/docs/jp/academy/cloud-web-scraping)ことで、自分のマシンを占有せずにタスクを動かし続けられます。[ローテーティングプロキシ](/docs/jp/academy/rotating-proxies)はリクエストを多数のIPアドレスに分散させ、サイトからのレート制限やブロックを避けます。そして[CAPTCHAやCloudflareのようなBot対策サービス](/docs/jp/academy/captcha-and-cloudflare)は、この段階が対処するために存在する障害そのものです。

## 出力を保存する

最後に、抽出したデータは使える形のどこか — CSVやExcelファイル、JSONエクスポート、データベース、下流のAPI — に着地します。これが、スクレイピングの実行をデータセットに変える段階です。

## Octoparseの位置づけ

手書きのスクレイパーでは、これらの段階を自分で配線します — リクエストライブラリ、ブラウザドライバ、セレクタエンジン、整形コード、ページネーションのロジック、プロキシ管理、そしてエクスポート処理です。Octoparseはこのパイプライン全体を1つのビジュアルワークフローにまとめます。ポイント＆クリックでセレクタを設定すれば、描画・ページネーション・プロキシのローテーション・クラウド実行・エクスポートは組み込み済みで、コードを書くのではなく設定するだけです。段階そのものは同じで、変わるのは、各段階を*どう*動かすかをエンジニアリングする代わりに、*何を*収集するかを記述すればよいという点です。