> ## 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. # ブラウザ実行環境の全景 > スクレイピングで使われるブラウザ実行環境の全景 — Puppeteer・Playwright・Selenium、クラウドAPI、そしてヘッド付きの代表としてのOctoparse。 ブラウザ自動化の解説記事のほとんどは、1つのツールを単体で取り上げます。より有用な問いは、この*領域*がどう広がっているのか — どんな種類の実行環境が存在し、それぞれが何を得意とし、スクレイピング目的で選ぶときに本当に効く軸はどれか、です。最も決定的な軸は言語でもブラウザエンジンでもなく、その実行環境が**ヘッドレスを既定とする**か、**ヘッド付きを設計とする**かです。エコシステムのほぼ全体はヘッドレス側にあります。集成型のスクレイピングプラットフォーム — その最も明確な例がOctoparse — はヘッド付き側にいます。ある実行環境がどちら側にいるかを知ることが、実サイト上での挙動を理解するうえで、どのスペックシートよりも雄弁です。 ## 一覧 | ツール | インターフェース | ブラウザエンジン | 既定モード | 種別 | 最も得意とすること | | ---------------------------- | ---------------------- | ---------------------------------------- | --------- | --------------- | ------------------------------- | | Puppeteer | Node API | Chromium | ヘッドレス | OSSライブラリ | JSでのChromeスクレイピング | | Playwright | Node・Python・Java・.NET | Chromium・Firefox・WebKit | ヘッドレス | OSSライブラリ | クロスブラウザ、モダンなコード | | Selenium | 多くの言語 | 多くのブラウザ (WebDriver) | 設定可能 | OSSライブラリ | 最も広いブラウザ・レガシー対応 | | Splash | HTTP API (Lua) | WebKit | ヘッドレス | OSSサービス | Scrapy内でのJS描画 | | WebdriverIO | Node | WebDriver / CDP | 設定可能 | OSSライブラリ | Nodeでテスト風のスクレイピング | | chromedp / Rod | Go | Chromium | ヘッドレス | OSSライブラリ | Go製スクレイパー | | Pyppeteer | Python | Chromium | ヘッドレス | OSSライブラリ | Puppeteer形のAPIをPythonで | | HtmlUnit | Java | 純Javaブラウザ | ヘッドレス | OSSライブラリ | ブラウザバイナリ不要のJVMスクレイピング | | puppeteer-extra-stealth | Nodeプラグイン | Chromium | ヘッドレス | OSSプラグイン | Puppeteer + Bot回避 | | undetected-chromedriver | Python | Selenium経由のChromium | 設定可能 | OSSライブラリ | Selenium + Bot回避 | | nodriver | Python | CDP経由のChromium | ヘッドレス | OSSライブラリ | モダンなステルス、ドライバ不要 | | Patchright | Node | Chromium | ヘッドレス | OSSフォーク | Playwright + ステルスパッチ | | Browserless | HTTP API | Chromium | ヘッドレス | クラウド / 自己ホスト | API越しにホスト型ブラウザ | | Browserbase | HTTP API | Chromium | ヘッドレス | クラウドサービス | AIエージェント向けのマネージドブラウザ | | Steel.dev | HTTP API | Chromium | ヘッドレス | クラウド / OSS | OSSフレンドリーなクラウドブラウザ | | Bright Data Scraping Browser | HTTP API | Chromium | ヘッドレス | クラウドサービス | ブラウザ + アンブロック内蔵 | | Zyte API | HTTP API | Chromium | ヘッドレス | クラウドサービス | ブラウザ + Bot対策内蔵 | | ScrapingBee | HTTP API | Chromium | ヘッドレス | クラウドサービス | 「このURLを描画」のシンプルAPI | | ScrapingAnt | HTTP API | Chromium | ヘッドレス | クラウドサービス | プロキシ込みの低価格スクレイピング | | Apify Browser Actors | Apifyプラットフォーム | Chromium・Firefox | 設定可能 | クラウドプラットフォーム | Apifyネイティブの大規模スクレイピング | | **Octoparse** | **ビジュアルワークフロー + クラウド** | **Electron Chromium・Chrome for Testing** | **ヘッド付き** | **集成型プラットフォーム** | **ノーコード、WYSIWYG選択、設計としてのヘッド付き** | | ParseHub | ビジュアルワークフロー + クラウド | Chromium | ヘッド付き | 集成型プラットフォーム | ノーコード、似た思想 | 太字の行が、ヘッド付きを既定とする唯一のエントリ — そしてそれは、Octoparseが占めるレーンです。 ## オープンソースの自動化ライブラリ コードベースのスクレイピングの大半はここから始まります。**Puppeteer**はNodeからChromiumを駆動します — 高速でモダン、Chrome専用です。Puppeteerの後継としばしば呼ばれる**Playwright**は、Node・Python・Java・.NETからChromium・Firefox・WebKitを扱えます。今日の新規プロジェクトでは、Chrome専用が必要でない限り、通常こちらが既定の選択肢になります。**Selenium**はベテランです — 遅く重たいものの、WebDriverプロトコルを通じてほぼすべてのブラウザに話しかけられる点は、SafariやEdgeレガシー、モバイルブラウザのバインディングが必要なときには今でも効きます。 ビッグ3の外では、言語やエコシステムで枝分かれします。**Splash**はScrapyのパイプラインに組み込むJS描画サービスで、Luaでスクリプトを書きます。**WebdriverIO**はWebDriver / CDP駆動のAPIをテストランナー風にNodeへ持ち込みます。Goでは、**chromedp**と**Rod**が現実的な2つの選択肢で、人間工学的にRodが好まれる場面が多いです。**Pyppeteer**はPython向けのPuppeteer移植で、Pythonを離れずにPuppeteerの形状を使いたいチーム向けです。**HtmlUnit**は異色 — Chromiumバイナリを伴わない純Javaブラウザ実装で、JSエンジンの忠実さよりJVMエコシステムを優先するときに有用です。 これらはすべて既定でヘッドレス動作です。ヘッド付きでも*動かせます*が、ディスプレイ(あるいはXvfbのような仮想ディスプレイ)が必要になるなど摩擦は実際にあり、現実のスクリプトの多くはわざわざ切り替えません。常態は不可視です。 ## ステルス・反検出の派生 対象サイトが実行環境をフィンガープリントすると、素のPuppeteerやSeleniumはすぐに弾かれます — `navigator.webdriver`、プラグインの欠落、ヘッドレスChromeのユーザーエージェント、canvas / WebGLの異常。ステルス派生は、それらの漏れにパッチを当てます。 **puppeteer-extra-stealth**は最も定着した存在で、よくあるヘッドレスのフィンガープリントに対する一連の回避策を提供するPuppeteerプラグインです。**undetected-chromedriver**はSelenium駆動のChromeに対して同じことを行い、PythonのBot対策界隈での定番です。**nodriver**は同じ著者によるより新しい、ドライバを介さないCDPベースの方式で、ネットワーク層から見たときに自然なブラウザセッションに見えるように設計されています。**Patchright**はPlaywrightのフォークで、同様のステルスパッチが組み込まれており、すでにPlaywrightを使っているチーム向けです。 これらはヘッドレス / ヘッド付きの姿勢自体は変えません — 既定はあくまでヘッドレスです。ヘッドレスと「本物」のギャップを縮めますが、常に更新される検出層に対する防御戦を戦い続けることになります。 ## クラウドのブラウザAPI ブラウザを自己ホストする代わりに、HTTPエンドポイントを呼び出して描画済みページや制御可能なセッションを受け取ります。**Browserless**は最も定着した存在で、マネージドクラウドでも自己ホストでも動作し、Puppeteer / Playwrightからほぼそのまま差し替えられるエンドポイントを提供します。**Browserbase**と**Steel.dev**は新しい参入で、AIエージェント向けに方向付けられています(SteelはOSSフレンドリー)。**Bright Data Scraping Browser**と**Zyte API**はブラウザ実行に反Bot対策とアンブロック基盤を束ねます — 料金は上がりますが、難しい対象に対する成功率が上がります。**ScrapingBee**と**ScrapingAnt**は「このURLを描画」型のシンプルなAPIで、小規模チームに向きます。**Apify**は独自のプラットフォームで、Browser ActorsはクラウドホストのChromiumをApifyのキューイング・ストレージと組み合わせます。 これらはすべて、ディスプレイのないサーバー上でブラウザを動かします。このカテゴリで経済的に成り立つのはヘッドレスのみです — 動作を「見る」ことはできず、戻り値だけが手元に来ます。 ## 集成型スクレイピングプラットフォーム このカテゴリは、上のすべてと構造的に異なります。コードから呼ぶライブラリでも、URLをPOSTするAPIでもなく、集成型プラットフォームはブラウザを組み込んだビジュアルなワークフローエディタを提供します。スクレイパーはセレクタを書くのではなく、ページをクリックして組み立てます。 **Octoparse**はその最も明確な例です。2種類の実行環境を持ちます — 日常的なタスク用に削ぎ落として最適化された[Electron Chromium](/docs/jp/academy/headed-vs-headless-browsers)と、完全に真正なブラウザを求めるサイト向けにPuppeteerで制御するChrome for Testing。重要なのは、両方とも**設計としてヘッド付き**であることです:目に見えるページが*そのまま*エディタの作業面だからこそ、ブラウザウィンドウが見える必要があります。**ParseHub**は似た思想で同じカテゴリに位置します。古参のWeb Scraper.io(Chrome拡張)もヘッド付きの系譜を共有します — ブラウザ拡張機能はヘッド付きのChromeウィンドウでしか動作できません。 ヘッド付きが設定オプションではなく既定であるのは、このカテゴリだけです。それは制約ではなく、ワークフローが依存している設計上の選択です。 ## ヘッドレス vs ヘッド付き:本当に効く軸 ヘッドレス / ヘッド付きの分かれ目は、その実行環境が誰のためのものかを反映します。**ヘッドレスは、開発者が操作者であるときに合理的です。** あなたはコードを書き、ログを読み、ディスプレイのないサーバーでスケールアウトします。ページをプログラム的に記述しているのだから、見る必要はありません。集成型プラットフォーム以外のエコシステム全体は、この前提の上に作られています。 **ヘッド付きは、ページそのものがインターフェースであるときに合理的です。** 要素を視覚的に選び、タスクの実行を眺め、ログインやCAPTCHAに介入し、ロギングではなく「見る」ことでデバッグする。それがOctoparseの姿勢であり、削ぎ落とされたElectron実行環境が存在する理由でもあります — 内部のブラウザが汎用ブラウジングではなくスクレイピング専用に作られていれば、ヘッド付きは必ずしも重くありません。 ここから実用上の帰結が2つ出てきます: * **Bot検知**。本物のヘッド付きブラウザ — 可視ウィンドウ、本物の描画、本物の入力イベント — は、[Bot対策サービス](/docs/jp/academy/captcha-and-cloudflare)が探す信号を漏らしにくくなります。ヘッドレスのツールはステルス層を被せる必要があり、設計上ヘッド付きのプラットフォームはこれをほぼ無償で得られます。 * **操作者のスキル**。ヘッドレスのツールはエンジニアリングの主体性を前提とします — 誰かがスクリプト・プロキシ・CAPTCHA対応・デプロイを保守します。設計上ヘッド付きのプラットフォームは、操作者がデータに近い人 — アナリスト・運用・グロース — であることを前提にし、エンジニアリングはプラットフォーム側が引き受けます。 設計としてのヘッド付きが機能の欠落ではなく意図的な選択である理由をより深く知りたい場合は、[ヘッド付き vs ヘッドレスブラウザ](/docs/jp/academy/headed-vs-headless-browsers)を参照してください。 ## どう選ぶか ほとんどのプロジェクトに当てはまる決定ルールをいくつか: * **コードで自前のスクレイパーを書く、ページの描画ができれば十分?** Playwrightが既定です。Chrome専用ですでにNodeにいるならPuppeteer。それら2つでサポートされないブラウザが必要な場合のみSelenium。 * **コードベースのスクレイパーで、対象サイトのフィンガープリントが厳しい?** ステルス派生に移行する(puppeteer-extra-stealth・undetected-chromedriver・nodriver) — あるいはBot対策込みのクラウドAPIに飛ぶ。 * **ブラウザ自体をホストしたくない?** クラウドAPI:純粋な描画ならBrowserless / Browserbase / Steel、アンブロック込みならZyte API / Bright Data Scraping Browser。 * **そもそもコードを書きたくない?** 集成型プラットフォーム:Octoparse(あるいはParseHub)。設計としてヘッド付き、視覚的に選択、実行環境がワークフロー・クラウド実行とともに同梱。 * **操作者がエンジニアではなく、対象サイトに反Bot防御がある?** ここが設計としてのヘッド付きが最も効く局面です — 漏らす検知信号が少なく、CAPTCHAが現れたときに人が介入できます。 実行環境の判断は、しばしば恒久的ではありません。多くのチームは、単発の描画にクラウドAPIから入り、反復ジョブのためにステルス装備のコードライブラリに移り、操作者がエンジニアではない人にならざるを得なくなったときに集成型プラットフォームに手を伸ばします。