ネット上の「Scrapy と Selenium の比較」記事は、だいたい同じことを言っています。Scrapy のほうが速い、Selenium は JavaScript に対応している、あとは好みで選べ、と。方向性としては間違っていませんが、どこでも通用する「1分あたり何ページ」という話は当てになりません。実際のスループットは、対象サイト、ネットワーク、並列処理、ブラウザのライフサイクル、待機条件、そしてボット対策の強さで大きく変わります。
この記事では、プロジェクトが変わっても通用するアーキテクチャと運用面のトレードオフを比較します。また、他の記事ではあまり触れられない点、つまりブラウザ自動化がリソースモデルをどう変えるのか、なぜ全ページをブラウザで開くより選択的レンダリングのほうが優れていることが多いのか、そしてどんな場面でどちらのフレームワークよりもマネージドな抽出 API のほうが適しているのかも解説します。
2026年時点の結論：Scrapy と Selenium どちらを選ぶべきか
まず結論だけ言うと、サーバーサイドでレンダリングされるページなら、速度・拡張性・リソース効率の面で Scrapy が有利です。Selenium は、クリック、入力、モーダルの表示待ちなど、実際のブラウザとしての動作が必要なときに強みを発揮します。とはいえ、どちらも最新のボット対策にそのまま勝てるわけではありませんし、今では Playwright が、以前 Selenium を選んでいた多くの用途を静かに置き換えています。
私が実際に使っている判断表はこちらです。
| あなたの状況 | 選ぶべきもの |
|---|---|
| 静的ページまたはサーバーレンダリングページで、大量取得したい | Scrapy |
| JS の多い SPA、ログイン、クリック、多段階フローが必要 | Selenium または Playwright |
| 混在サイトで、ほとんどは静的だが一部だけ JS が必要 | Scrapy + Playwright のハイブリッド |
| URL は分かっていて、構造化データだけ欲しい。保守は最小限にしたい | AI 抽出 API（Thunderbit など） |
2026年半ば時点では、Scrapy 2.17.0 が利用可能で、Selenium 4 は WebDriver BiDi のサポートを拡張し続けています。また scrapy-playwright により、Scrapy の一部リクエストだけをブラウザ経由で処理する、保守された手段も用意されています。この判断表を頭に入れたまま読み進めてください。以降で、その理由を説明します。
Scrapy と Selenium とは何か、そしてなぜ今でも議論されるのか
Scrapy と Selenium を比べるのは、配送トラックと乗用車を比べるようなものです。どちらも A から B に物を運べますが、片方は大量輸送を効率よくこなすために作られ、もう片方は人が実際に運転して操作するために作られています。この議論が続くのは、どちらのツールも スクレイピング自体はできる ものの、得意分野が違うからです。そして、違いを理解しないまま選んでしまうチームが少なくありません。
Scrapy：非同期クロールエンジン
Scrapy は Python 専用のフレームワークで、Twisted のイベント駆動・ノンブロッキング I/O モデルの上に成り立っています。ブラウザではありませんし、そもそもそうではありません。HTTP リクエストを飛ばし、返ってきた HTML を解析するだけです。仕組みはとてもシンプルです。ブラウザの描画を待つ必要がないため、複数のリクエストを同時に処理してもブロックされません。
Scrapy には最初から、spider、item pipeline、feed exporter、retry middleware、レート制限機能が揃っています。「全部自分で作らないといけない」タイプのフレームワークではありません。実運用で必要になる多くの機能が最初から用意されています。Scrapy のアーキテクチャ資料では、Engine、Scheduler、Downloader、Item Pipeline が分離された差し替え可能なコンポーネントとして整理されています。これが長く使われ続けている理由でもあります。中核を書き直さなくても、必要な機能を後から足せるからです。
弱点は、ブラウザがない以上、JavaScript は実行されないことです。ページ読み込み後にクライアント側の fetch でデータを取ってくるサイトでは、Scrapy はそのデータを見られません。初期 HTML だけを読む、それが限界です。
Selenium：プログラムできるブラウザ
Selenium は、W3C WebDriver プロトコルを通じて Chrome、Firefox、Edge といった実ブラウザを操作します。これにより Selenium は、Chrome 専用の裏技ではなく、言語やブラウザに依存しない標準的な仕組みになっています。JavaScript をレンダリングし、AJAX を実行し、人間と同じようにクリック、スクロール、入力ができます。
そのため、Selenium は操作を伴う処理に向いています。多段階ログイン、ウィザード形式のフォーム、無限スクロール、API 呼び出しを発火させるドロップダウンなどです。ただし、そのたびに立ち上がるブラウザセッションは重いです。Selenium 自身の Grid のサイジングガイド では、計画上の目安としてブラウザ 1 セッションあたり約 1GB の RAM を見込むよう案内しています。しかもそれは、実際にページを描画する CPU 負荷を含む前の話です。
よくある落とし穴もあります。ページの読み込み完了＝UI が使える状態ではないという点です。Selenium の公式ドキュメントでも、暗黙的待機と明示的待機を混ぜるのは避けるよう警告されています。そうしないとタイムアウトが急に読めなくなるからです。Selenium のスクリプトが不安定なら、たいていこれが原因です。
Scrapy と Selenium の性能比較：雑な万能数値に頼らないために
信頼できるベンチマークには、対象ページ、キャッシュ状態、ネットワーク条件、並列数、ブラウザ再利用の方法、待機条件、そして完全なコードが必要です。そうした前提がなければ、1分あたり何ページという数字は証拠ではなく宣伝です。それでも、アーキテクチャ比較としては十分意味があります。
| ワークロードの特徴 | Scrapy | Selenium | Scrapy-Playwright |
|---|---|---|---|
| サーバーサイドでレンダリングされた HTML | 直接 HTTP で取得 | フルブラウザ経由 | Scrapy の直接ルートを使用 |
| JavaScript で描画されるコンテンツ | 追加レンダラーが必要 | ブラウザがネイティブ実行 | 必要なときだけブラウザ描画 |
| 並列処理モデル | 非同期リクエストスケジューラ | コードまたは Grid でブラウザセッションを管理 | Scrapy のスケジューラ + ブラウザコンテキスト |
| リソース特性 | ブラウザ描画のオーバーヘッドなし | ブラウザ由来の CPU / メモリ負荷あり | ブラウザ負荷は必要なリクエストだけ |
| 適切な指標 | 安全なエラー率での 1 分あたりアイテム数 | 安全なエラー率での 1 分あたり完了フロー数 | 静的リクエストと描画リクエストを別々に測定 |
Scrapy のデフォルトの同時リクエスト数は、上限値であって、保証されたスループットではありません。実際の速度は、レイテンシ、ドメインごとの制限、スロットリング、リトライ、レスポンスサイズ、解析処理、そして対象サイトが許容するリクエストレートによって決まります。Selenium はブラウザセッションを再利用できるので、1 ページごとに新しいブラウザを必ず起動するわけではありません。ただし、アクティブな各セッションは、依然としてブラウザ環境を実行・描画します。
ハイブリッド構成が魅力的なのは、通常のリクエストは Scrapy の HTTP 経路に乗せたまま、レンダリングが必要なページだけブラウザに流せるからです。結果としてブラウザ作業は減ることが多いですが、自動的に高速になるわけではありません。静的経路と描画経路を別々に計測し、失敗率とリトライ率を含めて、対象サイトへの負荷と利用可能メモリの両方に合わせて並列数を調整する必要があります。
意思決定に効く、重要な違い
速度だけが唯一の指標ではありません。運用に入ったあとには、いくつかの実務上の要素が同じくらい重要になります。
JavaScript レンダリングと動的コンテンツ
Scrapy 単体では、クライアント側で描画される要素は見えません。Selenium は実ブラウザなので、すべて見えます。中間案としては、Scrapy-Splash（古めで Lua スクリプト対応）や scrapy-playwright（現代的で推奨）があり、すべてのリクエストをフルブラウザで処理するのではなく、Scrapy のクロールループ内で必要なページだけ選択的にレンダリングできます。対象ページの 80〜90% が静的 HTML で、JS が必要なのは一部だけなら、選択的レンダリングが明らかに正解です。少数のページのために全件をブラウザ経由にするのは、計算資源の無駄です。
拡張性と並列処理
Scrapy を 1,000 ページから 100 万ページへスケールさせるのは、ほとんどがインフラの話です。同時リクエスト数を増やし、必要なら Redis を使ってワーカーを分散すればよい。Selenium をスケールさせる場合は、ブラウザインスタンスを線形に増やすことになり、RAM と CPU も同時に線形増加します。つまり、Selenium Grid を使ってブラウザファームを管理し、クラッシュ復旧にも対応する必要が出てきます。Selenium がスケールできないのではありません。スケールさせること自体が、設定変更ではなくインフラ案件になるということです。
データパイプラインと出力
Scrapy の item pipeline は、検証、重複排除、JSON / CSV / データベースへの出力を標準機能として扱えます。Selenium にはそれがありません。シリアライズも保存も自分で書く必要があります。データ品質や後続システムとの連携が重要なら、Scrapy が最初から持っているこの土台はかなり大きいです。
保守性と長期安定性
経験上よくあるのは、Scrapy の spider は middleware ベースの構造のおかげで比較的長持ちする一方、Selenium スクリプトは壊れやすいということです。ブラウザ更新でドライバが壊れ、タイミングのズレでテストが不安定になり、DOM が少し変わるたびにセレクタ修正が必要になります。フォーラムでは「クライアントに売るものとしては Selenium ベースのスクレイパーはあまり良い選択じゃなさそう」といった声もよく見ますが、長期間ほぼ手を入れずに運用する必要があるなら、その感覚は正しいです。
ボット対策の現実：2026年の防御にそれぞれどう対応するか
ここは他の比較記事がほぼ触れない部分ですが、実際にはスクレイパーが動くかどうかを決めるのはここです。Scrapy も Selenium も、現代的なボット対策基盤を前提には作られていません。そこを無視すると、本番で痛い目を見ます。
| 防御レイヤー | Scrapy | Selenium | Scrapy-Playwright | Thunderbit API |
|---|---|---|---|---|
| JS レンダリング | ❌ ミドルウェアが必要 | ✅ | ✅ | ✅ 標準対応 |
| TLS フィンガープリント | ⚠️ 検知されやすい | ⚠️ 検知されやすい | ⚠️ 改善するが未解決 | ✅ 対応済み |
| CAPTCHA 解決 | ❌ 手動対応 | ❌ 手動対応 | ❌ 手動対応 | ✅ 標準搭載 |
| レート制限の回避 | ⚠️ プロキシを自作 | ⚠️ プロキシを自作 | ⚠️ プロキシを自作 | ✅ 管理済み |
Scrapy はそもそもブラウザではないため、ブラウザフィンガープリント検査に引っかかります。単なる HTTP クライアントなので、リアルブラウザに見えない通信をボット対策ベンダーが弾くことは珍しくありません。Selenium は実ブラウザなので基本的な JS チェックには通りますが、navigator.webdriver のような信号で検知されます。これは自動化時に true になる標準フラグです。undetected-chromedriver のような修正はこれを隠そうとしますが、検知側も定期的にシグネチャを更新するため、いたちごっこです。
ステルスのいたちごっこと、自前対応が脆い理由
アンチ検知パッチについての不都合な真実は、解決策というより保守のループだということです。undetected-chromedriver や playwright-stealth は、Cloudflare Turnstile や DataDome が新しい検知ロジックを出すまでの間は機能します。するとまた修正が必要になります。実際、スクレイパー本体を作る時間より、ステルス層を維持する時間のほうが長くなってしまうチームを何度も見てきました。
レート制限も同様です。サーバーが 429 Too Many Requests を返したとき、Retry-After ヘッダーはお願いであって義務ではありません。そもそも送ってこないサイトも多く、別のシグナルで絞ってくる場合もあります。Scrapy の AutoThrottle は、観測したレイテンシに応じて遅延を調整してくれるので役立ちますが、予防ではなく反応です。
ここでマネージドな抽出 API が真価を発揮します。ボット対策の面倒を見るのは自分ではなくサービス側になるからです。これについては後ほど触れます。
Playwright の存在感：なぜ「Scrapy 対 Selenium」だけでは足りなくなったのか
これを 2 つのツールの対立として語ると、この数年でスクレイピング界隈に起きたことを見落とします。開発者フォーラムには「Selenium から Playwright に移って満足している」といった投稿があふれています。それなのに、多くの比較記事では Playwright にほとんど触れていません。
Microsoft が開発した Playwright は、Chromium、Firefox、WebKit をひとつの API で操作できます。actionability model により、要素が表示され、安定し、実際に操作可能になるまで待ってからアクションを実行するので、Selenium スクリプトを悩ませるタイミング由来の不安定さがかなり減ります。browser context の扱いも効率的で、完全な新規ブラウザを毎回立ち上げるより軽く、分離されたセッションを作れます。
Selenium を完全に置き換えるケース
スクレイピング用途だけを見るなら、既存の Selenium テスト基盤がない限り、2026年時点では Playwright のほうがたいてい優れています。コンテキスト作成が速く、ページあたりのリソース消費が少なく、ネイティブの async 対応があり、ネットワーク介入も標準搭載です。ゼロからスクレイピングを始めるなら、最初に Selenium を選ぶ理由はあまりありません。
例外は、すでに Selenium ベースのテスト基盤を持っている場合や、Playwright では同じようにきれいに扱えないブラウザプロファイルの細かなカスタマイズが必要な場合です。そのときは Selenium にも十分な存在理由があります。
scrapy-playwright の仕組み
scrapy-playwright は Scrapy 用の download handler で、meta={"playwright": True} が付いたリクエストだけを実ブラウザ経由に流します。それ以外は、Scrapy の高速な非同期 HTTP 経路のままです。以下は、商品カードがクライアント側 JS で描画されるページネーション付きカタログをクロールする簡略版 spider です。
import scrapy
class CatalogSpider(scrapy.Spider):
name = "catalog"
def start_requests(self):
yield scrapy.Request(
"https://example.com/products?page=1",
meta={"playwright": True, "playwright_include_page": True},
)
async def parse(self, response):
page = response.meta["playwright_page"]
products = response.css("div.product-card")
for product in products:
yield {
"title": product.css("h3::text").get(),
"price": product.css(".price::text").get(),
}
next_page = response.css("a.next::attr(href)").get()
if next_page:
yield scrapy.Request(
response.urljoin(next_page),
meta={"playwright": True, "playwright_include_page": True},
)
await page.close()
本当にレンダリングが必要なページだけをブラウザに通しています。これこそがハイブリッド構成の要点です。すべてのリクエストにブラウザ税を払うのではなく、必要なものだけにコストを払うわけです。
Scrapy-Splash と Scrapy-Playwright：どちらのミドルウェアを使うべきか
Scrapy-Splash は別途 Splash の Docker サービスを立て、操作のために Lua スクリプトを書く必要があります。動作はしますが、構成は重く、古めです。scrapy-playwright は Scrapy の async イベントループに直接統合され、主要 3 ブラウザエンジンをサポートし、別言語のスクリプトを足す必要もありません。2026年に新規で始めるなら、Splash を選ぶ理由はほぼありません。
本番向けのハイブリッド構成
多くの記事は「Scrapy と Selenium を組み合わせられる」とだけ書いて終わります。でも、それはアーキテクチャではありません。単なる提案です。実際の本番構成はこうなります。
流れとしては、Scrapy の scheduler が URL ルーターにリクエストを渡し、そのページが静的か動的かを判定します。静的リクエストは Scrapy 標準の downloader にそのまま流れます。動的リクエストはタグ付けされ、Playwright middleware に送られます。そこでブラウザコンテキストのプールが管理されます。どちらの経路でも、最終的には同じ item pipeline に戻り、検証、重複排除、出力処理が行われます。元データが生 HTML でも描画済み DOM でも、JSON、CSV、データベースのどれかに着地するのは同じです。
本番投入するなら、いくつかの注意点があります。Docker でコンテナ化して、Playwright のブラウザバイナリが環境間で安定して配布されるようにすること。利用可能 RAM に応じて Playwright コンテキストの同時数を上限設定すること（標準的な 4GB マシンなら 8〜10 コンテキストを超えないほうが無難です）。そして、無期限にプロセスを動かしっぱなしにするのではなく、cron や CI/CD パイプラインで定期実行することです。
この構成なら、最大限の制御ができます。その代わり、ブラウザバイナリの更新、コンテキストのライフサイクル不具合（閉じ忘れのページはクロール停止の原因になります）、プロキシローテーション、必要なボット対策パッチなど、すべて自分で面倒を見る必要があります。それは本物のエンジニアリング投資です。契約前に正直に認識しておく価値があります。
このインフラを自分で持ちたくないチーム向けに、Thunderbit の CLI は別のアプローチを取っています。
thunderbit batch extract --schema schema.json --file urls.txt
同じ構造化 JSON 出力です。spider コードも、ブラウザプールも、ボット対策の維持管理も不要です。自由度を少し譲る代わりに、本番化までの速さを得る形です。これは万能の上位互換ではなく、正当なトレードオフです。プロジェクトが本当にどれだけ制御を必要とするか次第です。
「フレームワークを使わない」選択：AI スクレイピング API が両者に勝つ場面
ある時点で、開発者は「実はクロールフレームワーク自体が不要だった」と気づきます。必要なのは、既知の URL 500 件から構造化データを取ることだけ。そこに spider、ブラウザプール、ボット対策を全部用意するのは大げさに感じます。実際、そのとおりなことが多いです。
Thunderbit はまさにその隙間を埋めるために作られています。とはいえ、複雑で再帰的な独自ロジックのクロールを Scrapy の代わりに置き換えるものではありません。別の、もっと狭い問題に対する別の道具です。
Open API: POST /extract は JSON Schema を受け取り、それに一致する構造化データを返します。生 HTML でも、自分で解析しないといけない Markdown の塊でもありません。POST /distill は逆に、RAG パイプラインや LLM にそのまま渡せるきれいな Markdown を返します。マネージドサービスなので、JavaScript レンダリングやボット対策も含めて任せられます。現在のDistill と Extract のガイドでは、Distill は 1 ページ 1 クレジット、Extract は 1 ページ 20 クレジットと案内されていますが、料金や条件は変わることがあるので、予算化の前に最新ドキュメントを確認してください。
MCP Server: Claude や Cursor のような AI エージェント向けに、Thunderbit の MCP サーバー は、distill、構造化抽出、項目提案、バッチ処理をツールとして公開します。これにより、エージェントは作業中に環境から離れず、新しい Web データを取得できます。
CLI: 公式の Thunderbit CLI は thunderbit extract <url> --schema schema.json のようなコマンドをサポートしており、ターミナル作業や定期ジョブに自然に組み込めます。抽出した Markdown を他ツールに流して、一度きりの調査にも使えます。
コードを書きたくないなら、Thunderbit Chrome Extension でも同じことができます。ターミナルを使わずにデータが欲しい非エンジニアがチームにいるなら、かなり有力な選択肢です。より広い視点が欲しいなら、AI web scraping や コード不要の web scraping についても書いています。
自分がどちらの陣営にいるのか、正直に考えてください。複数サイトをまたぐ複雑なクロールや、独自ロジック、再帰的なリンク追跡が必要なら、今でも Scrapy が正解です。操作が多いフローなら Selenium か Playwright です。ただし「既知の URL から構造化データを取りたい」だけなら、それはどちらのツールも本来そこまでを想定していない、より狭い問題です。API を使えば、spider コード、ボット対策の配管、そしてそれらを自前で持つことに伴う継続保守を本当にゼロにできます。
Scrapy vs. Selenium vs. Playwright vs. AI API：横並び比較
| 機能 | Scrapy | Selenium | Scrapy-Playwright | Thunderbit API |
|---|---|---|---|---|
| 対応言語 | Python のみ | Python, Java, C#, JS, Ruby | Python | REST（任意言語） |
| JS レンダリング | なし（ミドルウェアが必要） | あり | あり | あり、標準搭載 |
| 非同期 / 並列処理 | ネイティブ、高速 | インスタンスごとに限定的 | Scrapy 経由でネイティブ | サーバー側で管理 |
| ボット対策 | 自前対応 | 自前対応 | 一部対応 | 標準搭載 |
| データパイプライン / 出力 | 標準搭載 | 自前対応 | 標準搭載 | 構造化 JSON で出力 |
| 初期設定の複雑さ | 中程度 | 始めやすいが大規模化で難化 | 中〜高 | 最小限 |
| 保守負荷 | 低〜中 | 高 | 中 | ほぼゼロ |
| 最適用途 | 大量の静的クロール | 操作が多いフロー | 静的 / 動的が混在するサイト | 既知 URL、構造化出力 |
この 4 つ以外のスクレイパー候補も含めて検討しているなら、Instant Data Scraper の代替案 や おすすめの AI web scraper との比較も見ておくとよいでしょう。今は選択肢がかなり増えていて、どのツールも同じ問題を解くわけではありません。
2026年の Web スクレイピングに関する法的・倫理的な注意点
本題ではないので簡潔にしますが、これは重要です。Scrapy の ROBOTSTXT_OBEY を有効にすると、spider は robots.txt のルールに従います。これは良い習慣ですが、Robots Exclusion Protocol 自体は、そのルールが法的なアクセス許可ではないと明記しています。Selenium と Playwright には robots.txt の遵守機能はありません。そこは完全に自分で実装する必要があります。ツールに関係なく、スクレイピングして再利用する前に、サイトの利用規約と自分の管轄地域で適用される法律を確認してください。「公開されて見える」からといって、どこでも自動的に合法とは限りません。
2026年のスクレイピング案件で、どのツールを選ぶべきか
結局のところ、判断軸は 4 つです。コンテンツの種類、規模、必要な操作量、そしてどれだけの保守負担を引き受けるつもりか。静的ページを大規模に扱うなら Scrapy。実際の操作が必要な JS 多用ページなら Selenium か Playwright。両方が混ざるならハイブリッド。既知 URL から構造化データを取りたいだけで、保守を最小化したいなら、Thunderbit のような API のほうが、かかる時間以上の価値を返してくれるはずです。
「Scrapy か Selenium か」は、実は最初から本質的な問いではありませんでした。ただ、以前はそれ以外に選択肢が少なかっただけです。Playwright が中間領域を変え、AI 抽出 API は「ビジネス課題を解く」代わりに「インフラを作ってしまっていた」人たちに、まったく新しい道を開きました。どちらかに決める前に、無料枠を試してみる価値はあります。suggest-fields は無料で使えますし、distill は 1 クレジットで試せるので、コードを書く前に API 方式が合うかどうかを確認できます。
FAQ
Scrapy は web scraping で Selenium より速いですか？ 私のテストでは、はい。特に静的ページでは、Scrapy の非同期アーキテクチャがブラウザのオーバーヘッドを完全に省くため、桁違いに速いことがよくあります。JS 多用ページで Scrapy に Playwright ミドルウェアを使うと差は縮まりますが、混在ワークロードでは、JS 不要ページを高速経路に乗せたままにできるので、全体のスループットでは今でも Scrapy が有利です。
Scrapy で JavaScript レンダリングページは扱えますか？
単体では無理です。Scrapy が見られるのは初期 HTML だけです。scrapy-playwright や旧来の Scrapy-Splash をミドルウェアとして追加すれば、必要なリクエストだけを実ブラウザで描画し、それ以外は Scrapy のネイティブな高速経路に残せます。
Scrapy ではなく Selenium を使うべきなのはどんなときですか？ 多段階ログイン、ウィザードのクリック操作、フォーム入力など、フルブラウザの操作が必要で、ページ数が巨大ではない場合です。また、すでに Selenium ベースのテスト基盤があり、それをスクレイピングに再利用したいなら、Selenium を選ぶのが自然です。
2026年のスクレイピングでは Selenium より Playwright のほうが良いですか？ スクレイピング用途に限れば、一般的にははいです。Playwright はパフォーマンスが良く、自動待機が標準で、ブラウザコンテキストあたりのリソース消費も軽い傾向があります。一方で、Playwright は既存のクロスブラウザテスト基盤を置き換えるために作られたわけではないので、そこでは Selenium に強みが残ります。
AI スクレイピング API とは何ですか？ また、いつ Scrapy や Selenium の代わりになりますか？ Thunderbit の Open API のような AI スクレイピング API は、JavaScript の描画、ボット対策、データ抽出をサーバー側で処理し、あなたが定義したスキーマに一致する構造化 JSON を返します。既知の URL があり、クロール基盤を自分で作成・保守せずに構造化出力が欲しいときに向いています。複雑で再帰的な独自ロジックのクロールにおける Scrapy の代替ではありません。
さらに詳しく知る
