スクレイピングは、Webページから必要なデータだけをプログラムで抜き出す処理です。静的サイトならHTTPクライアントとHTML解析ライブラリの2つで組めます。ただし取得してよいかは別問題で、robots.txtと著作権法、サーバー負荷の3点で線を引く必要がある。違いと実装コード、判断条件を順に並べます。
まとめ：スクレイピングは公開Webから必要データだけを自動抽出する仕組み
スクレイピングの核心は、人がブラウザで見て手作業でコピーしている情報の収集を、プログラムに肩代わりさせる点にあります。処理は「対象ページへHTTPリクエストを送る→返ってきたHTMLを受け取る→解析して目的のデータを切り出す→構造化して保存する」の4段階に分解できます。数百ページ分の価格や在庫を毎日集めるような、手作業では現実的でない規模の収集を自動化できるのが導入の動機です。
実装で最初に分かれるのは、対象サイトが静的か動的かの見極めです。HTMLに最初からデータが載る静的サイトなら、HTTPクライアントとHTML解析ライブラリだけで足ります。JavaScriptが実行されて初めて中身が描画される動的サイトでは、ブラウザを自動操作する仕組みが要ります。加えて、技術的に取得できることと、取得してよいことは別問題です。robots.txtや利用規約、サーバー負荷、著作権・個人情報の扱いという線を外すと、便利な自動化が法務リスクに変わります。収集したデータをAIの学習や検索に回す構想があるなら、この線引きを設計の最初に決めておくと後戻りが軽くなります。
スクレイピングの定義とHTTP取得からHTML解析まで抽出する仕組み
まず概念を、実装できる粒度まで分解します。スクレイピングは特定のツール名ではなく、「Webページから必要な情報を機械的に抜き出す」という処理全体の総称です。ブラウザが画面を描くまでの流れを、プログラムで再現・短絡する作業と考えると、仕組みが見通せます。
スクレイピングの基本構造とリクエストから構造化まで4段階の処理
処理は4つの段階を順にたどります。第一段階はリクエスト。対象URLへHTTPのGETリクエストを送り、サーバーからHTMLを受け取ります。第二段階が解析（パース）で、受け取ったHTML文字列を、タグの入れ子構造を持つツリーとして読み解く工程です。第三段階が抽出で、そのツリーから目的の要素を、タグ名・class属性・id・CSSセレクタ・XPathといった目印で指定して値を取り出します。第四段階が構造化で、取り出した値をCSV・JSON・データベースの行として整えます。
この4段階のうち、サイトごとに作り込みが要るのは第三段階です。取得先のHTML構造は各サイトで異なり、目的のデータがどのタグのどの属性に入っているかを、実物を見て指定する必要があります。裏を返せば、サイト側がHTML構造を変えると抽出が壊れるということでもある。第一・第二・第四段階はライブラリの定型処理で済むため、実装コストの大半は「目印の設計と保守」に集中します。
静的サイトと動的サイトで変わる取得方法とJavaScript描画の壁
取得方法を分ける最大の要因が、データがHTMLに載るタイミングです。静的サイトは、サーバーが返すHTMLの中に目的のデータが最初から埋まっています。この場合はHTTPクライアントでHTMLを取得し、HTML解析ライブラリで抜き出せば完結する。処理が軽く、1ページあたりの取得時間も短く済みます。
動的サイトはそうはいきません。サーバーは骨組みのHTMLと空の器だけを返し、ブラウザ上でJavaScriptが実行されて初めて、APIから受け取ったデータが画面に描画されます。HTTPクライアントで取得したHTMLには、目的のデータがまだ入っていない。この壁を越えるには、実際のブラウザ（Chromiumなど）をプログラムから起動し、JavaScriptの実行と描画を待ってからHTMLを読む方式を使います。ブラウザ自動操作の基本はPlaywright MCPで始めるブラウザ自動化の仕組みで扱っており、動的サイトの取得を組む土台になる一本です。まず対象ページの「ソースを表示」で目的の値が生HTMLに含まれるかを確認し、含まれなければ動的サイト向けの手段に切り替える、という順で判断します。ブラウザをクラウド側で動かす構成なら、Cloudflare Kitesurfの実測値と使えない場面を整理した記事が、CPUとメモリを抑える選択肢として参考になります。
RequestsとBeautifulSoupを入れて1ページ分の値を取り出す
静的サイトなら要るのはライブラリ2つだけです。まず導入します。
pip install requests beautifulsoup4次が取得と抽出です。Requestsの公式クイックスタートはタイムアウトの明示を促しており、省くと処理が止まり続ける。ステータス確認は raise_for_status に任せます。要素の指定はBeautifulSoupの公式ドキュメントが示す select・select_one にCSSセレクタを渡す形が読みやすい。
import requests
from bs4 import BeautifulSoup
HEADERS = {"User-Agent": "sample-crawler/1.0 (+https://example.com/bot)"}
res = requests.get("https://example.com/news/", headers=HEADERS, timeout=10)
res.raise_for_status()
res.encoding = res.apparent_encoding
soup = BeautifulSoup(res.text, "html.parser")
for card in soup.select("li.news-item"):
link = card.select_one("a")
print(link.get_text(strip=True), link["href"])この十数行が、4段階のうち第一から第三までにそのまま対応します。apparent_encoding を入れているのは、日本語サイトの文字化けを先に潰すためです。User-Agentに連絡先を置くと、相手のログから誰の取得か分かる。メソッドの詳細はBeautifulSoupの解析の基本手順で追えます。
スクレイピングとクローリング・APIの違いとPythonライブラリの選択
スクレイピングは、クローリングやAPI利用としばしば混同されます。三者は目的も向く場面も異なる技術です。違いを押さえると、そもそもスクレイピングを選ぶべきかの判断が付きます。あわせて、実装に使うPythonライブラリの選び分けも整理します。
クローリングとスクレイピングの違いは巡回と抽出という目的の差
クローリングは、リンクをたどってWebサイトを巡回し、ページのURLや全体を収集する処理を指します。検索エンジンのロボットがサイト内を回ってページを見つけ、索引に登録していく動きが典型です。目的は「どのページが存在するかを網羅的に集めること」にあります。
スクレイピングは、個々のページから必要なデータだけを抜き出す処理です。目的は「特定の値を構造化して取り出すこと」に絞られます。両者は対立概念ではなく、実務では組み合わせて使います。まずクローラーで対象ページのURL一覧を集め、次に各URLへスクレイパーが入って価格や本文を抽出する、という二段構えが一般的です。
| 観点 | クローリング | スクレイピング |
|---|---|---|
| 主な目的 | ページの巡回・URLの収集 | ページからのデータ抽出 |
| 処理の単位 | サイト全体・リンク構造 | 個別ページの要素 |
| 出力 | URL一覧・ページ本体 | 構造化データ（表・JSON） |
| 典型例 | 検索エンジンの索引作成 | 価格・在庫の定点収集 |
語の使い分けとしては、「サイトを回る側面」を指すときにクローリング、「値を取り出す側面」を指すときにスクレイピングと呼ぶ、と捉えると混乱しません。1ページだけを対象にするならクローリングは不要で、スクレイピング単体で完結します。巡回を制御する側の読み方はrobots.txtのクロール制御の書き方にまとめており、取得する側の作法も同じ規定から決められます。
公式API提供がある場合との使い分けとスクレイピングを選ぶ条件
データ提供元が公式のAPIを用意している場合、まずAPIの利用を検討します。APIは提供側が意図的に開いた出入口で、データが構造化された形（多くはJSON）で返り、利用規約や取得上限も明示されています。HTML構造の変更で壊れる心配がなく、保守も軽い。取得の安定性と正当性の両面で、APIが使えるならAPIが優先されます。
スクレイピングを選ぶのは、次の条件のいずれかに当てはまるときです。第一に、必要なデータを返す公式APIが存在しないこと。第二に、APIはあるが取得できる項目・件数・頻度が要件に足りないこと。第三に、複数サイトの情報を横断して集めたく、各社のAPI仕様に個別対応するより画面ベースで統一的に取る方が現実的なこと。逆に、公式APIで要件を満たせるのにスクレイピングを組むのは、保守コストと法務リスクを自ら背負う選択になります。APIで受けるか収集で受けるかの切り分けは、API開発・システム連携の相談窓口で既存システムのデータ経路を見ながら詰められます。
Pythonの主要ライブラリとRequests・BeautifulSoup系の選び分け
Pythonがスクレイピングで使われるのは、目的別のライブラリがそろっているためです。静的サイトなら、HTTPリクエストを送るRequestsで HTMLを取得し、HTML解析ライブラリのBeautifulSoupでタグをたどって値を抜き出す組み合わせが定番です。少量・単発の取得はこの2つで足ります。
大規模な収集や、多数ページを効率よく巡回したい場合は、クローリングとスクレイピングを一体で扱えるフレームワークのScrapyが向きます。非同期でリクエストを並行処理でき、取得したデータの整形・保存までを枠組みとして提供する点が強みです。ただしScrapy公式のAutoThrottleドキュメントによれば、負荷を自動調整するこの拡張は既定がFalseで無効のまま出荷される。初期遅延5.0秒・同時接続の目標値1.0という既定を明示的に入れてから走らせます。動的サイトでJavaScriptの描画が必要なら、ブラウザを自動操作するSeleniumやPlaywrightを使います。以下が選び分けの目安です。
- 静的・少量：Requests＋BeautifulSoup。導入が軽く学習コストも低い
- 静的・大量／継続運用：Scrapy。巡回・抽出・保存を枠組みで管理できる
- 動的（JS描画）：Selenium／Playwright。実ブラウザで描画後のHTMLを取得できる
PyPIで確認できる版は、2026年9月4日時点で requests 2.34系・beautifulsoup4 4.15系・Scrapy 2.18系・playwright 1.62系・selenium 4.48系です。版は移るため導入時に取り直してください。
実装の起点は、対象が静的か動的かの1点です。動的だと分かっている場合を除き、まず軽いRequests＋BeautifulSoupで取得を試し、データが取れなければブラウザ自動操作へ切り替える順が、無駄なくコストを抑えられます。Scrapyでプロジェクトを起こす手順はScrapyの使い方とScrapy Cloudへのデプロイ手順、ドライバ不要の軽量な選択肢はDrissionPageの特徴とSeleniumとの速度差で追えます。Goを選ぶならGoでスクレイピングする方法とgoquery・Collyの使い分けとCollyの運用設定とレート制限の実測が判断材料になる。
Playwrightで描画を待ってから動的サイトのHTMLを取得する
動的サイトでは、ブラウザ本体を落としてから実行します。Playwright公式のPython導入手順では、導入とブラウザ取得が別コマンドです。
pip install playwright
python -m playwright install chromium取得側のコードは次の形です。要点は待ち方で、goto の直後に読むと器が空のままHTMLを掴む。目的の要素が現れるまで wait_for_selector で待ち、現れなければタイムアウトで落とします。固定秒数のsleepより壊れにくい。
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
browser = p.chromium.launch()
page = browser.new_page(user_agent="sample-crawler/1.0")
page.goto("https://example.com/list", wait_until="domcontentloaded")
page.wait_for_selector("li.item", timeout=15000)
for row in page.query_selector_all("li.item"):
print(row.inner_text())
browser.close()実ブラウザ方式は、1ページあたりの所要時間とメモリがRequests方式の数倍に膨らむ。数万ページを回すなら、静的取得で済む部分と描画が要る部分を分け、後者だけブラウザに任せます。設計差はPlaywrightの仕組みとSeleniumとの違いで整理しており、既存資産があるならSelenium 4でWebDriverの手動設定が不要になった書き方から入るほうが軽い。
スクレイピングを採用すべき条件と法務・負荷で見送るべき失敗パターン
ここからは判断を言い切ります。スクレイピングでつまずくのは、技術的なハードルよりも法務とサーバー負荷の線引きの側です。取得できることと、取得してよいことを分けて設計しないと、便利な自動処理が後で相談窓口ではなくトラブル対応の起点になります。
robots.txtと著作権法30条の4・サーバー負荷で守るべき実務上の線
守るべき線は、大きく3つに整理できます。第一が、対象サイトのrobots.txtと利用規約です。robots.txtの規定はRFC 9309（Robots Exclusion Protocol、2022年9月発行）として標準化されています。解析上限は500KiB以上が必須、AllowとDisallowが競合したら一致オクテット数が最多の規則を採る（最長一致）。取得が4xxで失敗したら任意リソースへアクセスしてよく、5xxなら全面禁止と見なす。キャッシュは24時間を超えて使わない。法的な強制力はないものの、これを外した収集は規約違反の根拠になり得ます。利用規約で自動取得を明示的に禁じているサイトからの取得は避けるのが基本線です。
第二が、著作権と情報解析の扱いです。日本では2018年改正の著作権法（e-Gov法令検索の条文）30条の4により、情報解析など著作物の思想・感情の享受を目的としない利用は、権利者の許諾なく行える旨が定められています。AIの学習データ収集はこの範囲に入り得る扱いです。ただし文化庁「AIと著作権について」は、享受目的の利用や、非享受目的に享受目的が併存する場合は適用しないと整理する。収集データをそのまま再配信・転載する行為は別問題で、著作権侵害になり得ます。目的が「解析」か「複製物の利用」かで扱いが変わる。氏名やメールアドレスが混じるなら、個人情報保護委員会のガイドライン（通則編）が定める安全管理措置も確認します。
第三が、サーバー負荷です。短時間に大量のリクエストを送ると、相手サーバーに過大な負荷をかけ、業務妨害と受け取られかねません。過去には、公共図書館のサイトへ自動アクセスした利用者が逮捕された事例（いわゆる岡崎市立中央図書館事件、2010年）もあり、負荷のかけ方次第で刑事事件に発展した前例として引かれます。リクエストの間隔を1秒程度以上空ける、深夜帯に集中させない、User-Agentを明示するといった配慮を、コード側の設計に組み込みます。
robotparserでrobots.txtを読んで取得可否を判定する
robots.txtの確認は、目で見るのではなくコードに組み込みます。Pythonなら標準ライブラリで足りる。urllib.robotparserの公式ドキュメントが示すRobotFileParserは、set_url と read で規則を読み込み、can_fetch で可否を返します。取得間隔を読む crawl_delay と request_rate は3.6、site_maps は3.8で追加されたメソッドです。
import time
import urllib.robotparser as robotparser
UA = "sample-crawler/1.0"
parser = robotparser.RobotFileParser()
parser.set_url("https://example.com/robots.txt")
parser.read()
target = "https://example.com/news/page/2"
if not parser.can_fetch(UA, target):
raise SystemExit("robots.txt が禁止しているため取得しない")
wait = parser.crawl_delay(UA) or 1.0
time.sleep(float(wait))この判定を取得ループの手前に置くだけで、規約違反と過負荷の両方を防げます。crawl_delay が None なら1秒を下限に待ち、宣言があればその値を尊重する。robots.txtは24時間を超えて使い回さない前提なので、定期収集では日次で読み直します。
スクレイピングを見送るべき場面と構造変更・IP遮断の失敗パターン
見送るべきは、正当性か安定性のどちらかが崩れる場面です。公式APIで要件を満たせるのにスクレイピングを選ぶ、利用規約が自動取得を明確に禁じている、収集データを解析ではなく再配信する——これらは法務リスクが技術的な利点を上回ります。
技術面で頻出する失敗パターンは3つあります。1つ目は、サイトのHTML構造が変更され、指定していたタグや属性がずれて抽出が突然壊れるケースです。定期収集を組むなら、抽出失敗を検知して通知する仕組みまで含めて設計しないと、気づかないうちに空データを集め続けます。2つ目は、アクセス頻度の高さからIPアドレスを遮断され、収集が止まるケース。3つ目は、規約や負荷の確認を後回しにしたまま本番運用を始め、相手先からの警告で急遽停止するケースです。特に構造変更への脆さは、収集そのものより保守フェーズのコストを押し上げる要因になります。検知は、取れた件数の前回比とHTTPステータスの分布をログに残せば足ります。
スクレイピングで集めたデータをAIで使う構想と内製か受託かの判断
スクレイピングの用途は、価格監視や市場調査だけではありません。近い用途として増えているのが、社内文書や公開情報を収集し、生成AIの検索対象（RAGの知識源）として使う構想です。この場合、収集の仕組みと、集めたデータを検索・回答に結び付けるAI側の設計を、一体で組む必要があります。取得の正当性を確保し、構造変更に強い保守可能な収集基盤を作り、それをAIの応答品質に接続する——ここまで通して設計できるかが成否を分けます。
自社に収集基盤とAIの両方を実装する知見が薄い段階では、データ収集の設計とAI連携の設計を外部と組み、運用しながら内製比率を上げる進め方が現実的です。収集したデータを問い合わせ対応や社内検索に生かすAIチャットボットまで見据えるなら、データ収集を含むAIチャットボット開発の相談窓口で、どのデータをどう集めてRAGに載せるかの見立てから設計を詰められます。収集の正当性と保守性を最初に固めておくと、後段のAI連携が安定する。土台となる大規模言語モデルの仕組みはLLMの仕組みと企業導入の判断基準で押さえておくと、収集データの生かし方が具体的に描けます。
スクレイピングとクローリング・API・法務に関するよくある質問
実装や導入の検討初期に挙がりやすい疑問を、7点に絞って答えます。
スクレイピングとクローリングは何が違いますか？
目的が異なります。クローリングはリンクをたどってサイトを巡回し、ページのURLや本体を網羅的に集める処理です。スクレイピングは個々のページから必要なデータだけを抜き出す処理を指します。実務では、クローラーで対象URLを集めてから各ページをスクレイピングする、という二段構えで組み合わせて使うことが多くなります。
スクレイピングは違法になりますか？
行為そのものが一律に違法なわけではありません。問題になるのは、利用規約で禁じられたサイトからの取得、過大な負荷による業務妨害、収集した著作物の再配信などです。日本では著作権法30条の4で情報解析など非享受目的の複製が認められる一方、享受目的が併存する場合は適用外とされ、複製物の再利用も別に権利侵害を問われ得ます。robots.txtと規約の確認、リクエスト間隔の配慮、目的が解析の範囲内かの確認を、事前に済ませておく必要があります。
JavaScriptで表示されるサイトはスクレイピングできますか？
できますが、方法が変わります。JavaScript実行後に描画される動的サイトは、通常のHTTPクライアントで取得したHTMLに目的のデータが入っていません。SeleniumやPlaywrightで実際のブラウザを起動し、描画が終わってからHTMLを読む方式を使います。まず対象ページの生HTMLに目的の値が含まれるかを確認し、含まれなければブラウザ自動操作へ切り替えます。
スクレイピングにはどのプログラミング言語が向いていますか？
ライブラリの充実からPythonが広く使われます。静的サイトはRequestsとBeautifulSoup、大規模な収集はScrapy、動的サイトはSeleniumやPlaywrightと、目的別の選択肢がそろっている点が理由です。JavaScript（Node.js）でもPlaywright等で同様の処理は組めますが、初学者が定番の情報を得やすいのはPythonです。並行処理の軽さを重視するならGoでgoqueryやCollyを使う構成も選べます。
APIがあるサイトでもスクレイピングすべきですか？
公式APIで要件を満たせるなら、APIを優先します。APIは提供側が意図的に開いた出入口で、データが構造化され、規約や取得上限も明示されているため、HTML構造の変更で壊れる保守リスクがありません。スクレイピングを選ぶのは、APIが存在しない、または取得項目・件数・頻度が要件に足りない場合に限るのが妥当です。
RequestsとScrapyはどちらを選べばよいですか？
取得するページ数と運用の継続性で分かれます。数十ページの単発ならRequestsとBeautifulSoupが軽く、コードも短い。数千ページ以上を定期的に回すならScrapyが有利で、巡回・抽出・保存・リトライを設定で管理できます。AutoThrottleは既定で無効なので、有効化と遅延の設定を入れてから走らせてください。
robots.txtが無いサイトは自由に取得してよいですか？
いいえ、robots.txtの不在は許諾ではありません。RFC 9309は取得が4xxで失敗した場合にアクセスしてよいと定めますが、これは取得制御の規定で、規約や著作権、負荷の判断は別に残ります。規約の禁止条項を確認し、リクエスト間隔を1秒以上空け、目的が情報解析の範囲かを見て進めてください。
