ウェブのデータ取得に使う道具を整理し、用途で選び分ける

2026年9月17日 ・ 朝倉 凛

• ブラウザ自動化
• オープンソース
• CLI

役割ごとに層を分けて考える

ウェブからデータを得る道具は、対象とする層が違うため、同列に比べると判断を誤りやすい。 クローリングの骨格を備える基盤と、HTMLを解析するパーサと、実際のブラウザを動かす自動化と、ブラウザ自体を拡張する仕組みは、担う責務が異なる。 画面描画前のHTMLが十分に得られる場面と、クライアント側レンダリングで生成される場面でも選択肢は変わる。 まずは層を区切り、どの層に手を入れる必要があるかを見極める。

一次資料から読み取れる立ち位置の違い

ここでは各プロジェクトの公式ドキュメントに書かれた説明を基に、機能の重心を並べる。 記述は一次資料に依拠し、推測で補わない。 用語や機能名は資料の語をそのまま示し、同じ観点で表に置く。 重複する細部は省き、役割が見える最小限に絞る。

パーサはクローラではないので、HTMLの取得や巡回、保存の設計は別に要る。 逆にクローラ基盤は抽出の骨格まで持つが、実ブラウザの操作は含まない。 ブラウザ自動化はユーザー操作の再現を前提とし、取得対象の描画条件に合わせて選ぶ。 拡張機能はブラウザ内での常駐や権限設計が中心になる。

記述の差が設計と運用に与える影響

ScrapyはSpidersやItem PipelineやFeed exportsなど、巡回と抽出と出力の流れが部品として揃う。 この構成を前提にすると、巡回規則と後処理と保管先を分離しやすく、長期運用でも責務の境界が崩れにくい。 一方でBeautiful Soupは解析木の操作に特化しており、取得や巡回や永続化は別の層で補う設計になる。 解析の柔軟さは高いが、ジョブ全体の制御は自前で決めることになる。

SeleniumとPlaywrightとPuppeteerは実ブラウザを動かす。 この層を選ぶと、ブラウザバイナリの用意やプロセス管理が前提になり、ページ内の動的生成やイベント駆動の要件に対応できる。 資料ではPlaywrightがブラウザの取得を対話的に案内し、設定をプロジェクトに集約する構成を示している。 Puppeteerはインストール時のブラウザ取得と、パッケージマネージャのスクリプト抑止時に手動で取得する手順を明示している。

Chrome拡張はブラウザそのものの機能を拡張する。 content scriptsやtabsやdownloadsやcookiesなどのAPIを使い、ユーザーのChrome内でページの変更や監視を行う設計が中心になる。 資料には権限をどう考えるかの指針や、クロスブラウザ化に触れる説明が含まれている。 常駐や配布の形が前提として組み込まれるため、他の実行形態とは要件の置き方が変わる。

規模と前提ごとの選び方を具体化する

巡回が主で、同じサイト構造から項目を安定して抜き、後処理や出力形式を固定したい場面では、Scrapyの部品化が効く。 Spidersで巡回規則を、Item Pipelineで整形と保存を分ければ、仕様変更の衝撃範囲を絞りやすい。 ログや統計の収集も資料に含まれるため、長く回すジョブの監視設計に踏み込みやすい。 一方でブラウザ操作が不要な限り、基盤だけで十分に回る。

単発の解析や、構文が崩れがちなHTMLを手当てしながら抜く作業には、Beautiful Soupが向く。 解析木を直接たどる記法は、細かな例外処理をコードに落とし込みやすい。 ただし取得の再試行や並列化や保存先の管理は別に設ける必要がある。 取得から保存までの流れを自作する意思があるときに選ぶと噛み合う。

クライアント側で生成される要素を扱う、ログイン後の状態や複雑なナビゲーションが前提など、ユーザー操作の再現が避けられない場面は、SeleniumかPlaywrightかPuppeteerになる。 言語や既存の自動テストとの親和性、ブラウザの取得や更新の扱いを一次資料の流儀に合わせて選ぶ。 テストランナーや並列実行が要件に入るならPlaywrightの構成が導入を速める可能性がある。 ブラウザの制御APIを軽く握りたいだけならPuppeteerの最小例から始めやすい。

配布して手元のブラウザ上で動かす前提が固いなら、Chrome拡張での常駐と権限設計を核に据える。 tabsやwebNavigationやcookiesのAPIで、ユーザー操作の流れに沿って状態を観察したり保存したりできる。 ただし常にChrome上で動く設計になるため、無人のサーバプロセスとして回す前提とは切り分ける。 権限は必要最小限で設計し、資料の指針に沿って公開や配布の手順を決める。

一次資料の読み筋を実務に落とす

資料の語は、どこまでを道具が担い、どこを設計者が担うかを明確に分けている。 巡回と抽出と出力の責務、解析木の扱い、ブラウザの取得とプロセスの寿命、権限と実行環境の境界が、そのまま実務の分岐点になる。 したがって選定の順序は、描画要件と配布形態と保守期間を先に固定し、それに合う層の道具を当てはめるのが無駄が少ない。 計画段階で一次資料の用語と前提に合わせて要件を書き下ろせば、導入後の解釈違いによる作り直しを避けやすい。