Pythonでウェブスクレイピングの道具をどう組み合わせるか
この話題の全体像は ウェブのデータ取得に使う道具を整理し、用途で選び分ける にまとめている。
用途の境界を先に決めておく
スクレイピングという語には、取得、解析、巡回、自動操作という異なる作業が含まれる。 取得はHTTPでページやAPIから応答を受け取り、解析はHTMLやXMLの構造から必要な要素を抜き出す。 巡回は次のURLを見つけて辿る規則を管理し、自動操作はブラウザを動かしてアプリの画面遷移を起こす。 この層を分けて考えると、Pythonの主要な道具がどこを担うかを誤解しにくくなる。
公式ドキュメントから位置づけを拾う
ここでは一次資料の記述を、製品ごとに要点として並べる。 資料はScrapyを「高速な高水準のクローリングとスクレイピングのフレームワーク」としており、SpidersやSelectors、Items、Item Pipeline、Feed exportsといった構成要素を示している。 Beautiful Soupの資料は、HTMLとXMLからデータを取り出すためのライブラリと説明し、構文木の走査や検索や変更の方法を挙げ、最新版系として4.15.0の文書であることを示す一方で、Beautiful Soup 3の開発終了日を2020年12月31日と明記している。 Requestsの資料は、人間に優しいHTTPクライアントであるとし、接続の再利用、セッションによるCookieの保持、SSL検証、プロキシ、タイムアウト、ストリーミングダウンロードなどの機能を列挙している。 Playwrightの資料は、本来はエンドツーエンドテスト用に作られたが一般的なブラウザ自動化にも使えるとし、ChromiumとWebKitとFirefoxを対象に、WindowsとLinuxとmacOSでヘッドレスまたはGUIで動作できると述べている。
| 製品 | 位置づけ | 資料にある要素 |
|---|---|---|
| Scrapy | クローリングとスクレイピングのフレームワーク | Spiders、Selectors（XPath）、Items、Item Pipeline、Feed exports、CLI、統計、ログ |
| Beautiful Soup | HTMLとXMLの解析ライブラリ | 構文木の走査、検索、変更、複数パーサの利用、BS3の終了告知 |
| Requests | HTTPクライアント | セッションとCookie、SSL検証、自動デコード、プロキシ、タイムアウト、ストリーミング |
| Playwright | ブラウザ自動化ライブラリ | Chromium・WebKit・Firefox、Windows・Linux・macOS、ヘッドレス、モバイルエミュレーション |
同じ作業でも道具が違えば書き方が変わる
資料の語り口から見ても、四つの道具は層が異なり、重なりは部分的である。 RequestsとBeautiful Soupは取得と解析の部品にとどまり、Scrapyは巡回の規則や保存の経路まで含む型を提供する。 PlaywrightはHTTP経由の取得ではなく、ブラウザの操作そのものを扱うため、ページ遷移の前提やレンダリングの有無に関する扱いが根本から違う。 この差は、プロジェクトの単位、依存先、テストの方法にそのまま跳ね返る。
用語の食い違いが実務に及ぼす影響
各資料は自分の守備範囲を前提として「スクレイピング」や「自動化」を語るため、同じ単語でも含みが変わる。 この食い違いを意識しないと、想定していない責務を道具に背負わせてしまい、設定や拡張で迷走しやすい。 たとえば保存形式の話をScrapyはFeed exportsとして組み込み機能で扱うが、RequestsとBeautiful Soupだけでは自前の保存処理を書く前提になる。 Playwrightはテストの実行基盤と親和性が高く、資料がpytestプラグインを前提に流れを示すため、既存のテスト運用と接続する設計が取りやすい。
どの組み合わせを選ぶかの基準を置く
設計の基準は、対象の振る舞いと運用の制約に合わせて定義すると判断が早い。 日次で定形の巡回と保存までを一括で走らせたいなら、規則と出力の型が揃うScrapyが候補に上がる。 断片的な取得と解析を既存のPythonコードに差し込みたいなら、RequestsとBeautiful Soupの最小構成が作業時間に見合いやすい。 画面依存のワークフローや複数エンジンでの挙動確認を兼ねたいなら、Playwrightでブラウザを自動操作する前提に切り替える。
実務での導入手順のヒント
まず対象サイトの応答がAPI型かHTML型かを調べ、ログインやCookieの扱いが必要かを洗い出す。 API型であればRequestsで十分に扱え、HTML型ならBeautiful Soupの構文木操作を試す価値がある。 複数ページを規則で辿る必要が明確なら、その規則をScrapyのSpiderの形に落とせるかを検討する。 クライアント側レンダリングや複雑な対話が不可避なときだけ、Playwrightでの操作記述に進む。
一次資料の読み方を決めておく
不具合の切り分けでは、まず資料が想定する使い方に沿っているかを確認する。 ScrapyはCLIや統計の仕組みで走行中の状態を観察でき、資料はその存在を明確に記している。 Beautiful Soupは使用するパーサに依存する挙動があり、資料は診断関数の利用を促している。 Requestsはセッションやタイムアウトを明示的に指定でき、資料はそれらのAPIを例示している。 Playwrightは公式のpytestプラグインを推奨し、資料はその導入と実行の流れを段階的に示す。
まとめに代えて前提を固定する
四つの道具は競合ではなく、層を分担するための選択肢である。 取得と解析はRequestsとBeautiful Soup、巡回と出力整形はScrapy、画面操作はPlaywrightという役割分担を出発点に置く。 そのうえで、対象と運用の制約に合わせて境界を動かす。 一次資料の前提に立ち返れば、議論の行き違いは減り、実装は安定する。