スクレイピングとは？クローリング・APIとの違いと実装・法務の判断を解説

スクレイピングは、公開されたWebページから必要なデータだけを自動で抜き出す技術です。ページのHTMLを取得し、そこから目的の値（価格・商品名・投稿本文など）を切り出して、表やデータベースに整える一連の処理を指します。この記事では、スクレイピングがデータを抽出する仕組み、混同されやすいクローリングやAPIとの違い、静的サイトと動的サイトで変わる取得方法、Pythonの主要ライブラリ、そしてrobots.txtや著作権法といった守るべき線と、採用・見送りの判断基準までを、実際にコードを書く立場から整理します。

まとめ：スクレイピングは公開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に含まれるかを確認し、含まれなければ動的サイト向けの手段に切り替える、という順で判断します。

スクレイピングとクローリング・APIの違いとPythonライブラリの選択

スクレイピングは、クローリングやAPI利用としばしば混同されます。三者は目的も向く場面も異なる技術です。違いを押さえると、そもそもスクレイピングを選ぶべきかの判断が付きます。あわせて、実装に使うPythonライブラリの選び分けも整理します。

クローリングとスクレイピングの違いは巡回と抽出という目的の差

クローリングは、リンクをたどってWebサイトを巡回し、ページのURLや全体を収集する処理を指します。検索エンジンのロボットがサイト内を回ってページを見つけ、索引に登録していく動きが典型です。目的は「どのページが存在するかを網羅的に集めること」にあります。

スクレイピングは、個々のページから必要なデータだけを抜き出す処理です。目的は「特定の値を構造化して取り出すこと」に絞られます。両者は対立概念ではなく、実務では組み合わせて使います。まずクローラーで対象ページのURL一覧を集め、次に各URLへスクレイパーが入って価格や本文を抽出する、という二段構えが一般的です。

語の使い分けとしては、「サイトを回る側面」を指すときにクローリング、「値を取り出す側面」を指すときにスクレイピングと呼ぶ、と捉えると混乱しません。1ページだけを対象にするならクローリングは不要で、スクレイピング単体で完結します。

公式API提供がある場合との使い分けとスクレイピングを選ぶ条件

データ提供元が公式のAPIを用意している場合、まずAPIの利用を検討します。APIは提供側が意図的に開いた出入口で、データが構造化された形（多くはJSON）で返り、利用規約や取得上限も明示されています。HTML構造の変更で壊れる心配がなく、保守も軽い。取得の安定性と正当性の両面で、APIが使えるならAPIが優先されます。

スクレイピングを選ぶのは、次の条件のいずれかに当てはまるときです。第一に、必要なデータを返す公式APIが存在しないこと。第二に、APIはあるが取得できる項目・件数・頻度が要件に足りないこと。第三に、複数サイトの情報を横断して集めたく、各社のAPI仕様に個別対応するより画面ベースで統一的に取る方が現実的なこと。逆に、公式APIで要件を満たせるのにスクレイピングを組むのは、保守コストと法務リスクを自ら背負う選択になります。

Pythonの主要ライブラリとRequests・BeautifulSoup系の選び分け

Pythonがスクレイピングで使われるのは、目的別のライブラリがそろっているためです。静的サイトなら、HTTPリクエストを送るRequestsで HTMLを取得し、HTML解析ライブラリのBeautifulSoupでタグをたどって値を抜き出す組み合わせが定番です。少量・単発の取得はこの2つで足ります。BeautifulSoupの導入から基本的な使い方はBeautifulSoupのインストールと解析の基本手順で具体的に解説しています。

大規模な収集や、多数ページを効率よく巡回したい場合は、クローリングとスクレイピングを一体で扱えるフレームワークのScrapyが向きます。非同期でリクエストを並行処理でき、取得したデータの整形・保存までを枠組みとして提供する点が強みです。動的サイトでJavaScriptの描画が必要なら、ブラウザを自動操作するSeleniumやPlaywrightを使います。以下が選び分けの目安です。

• 静的・少量：Requests＋BeautifulSoup。導入が軽く学習コストも低い
• 静的・大量／継続運用：Scrapy。巡回・抽出・保存を枠組みで管理できる
• 動的（JS描画）：Selenium／Playwright。実ブラウザで描画後のHTMLを取得できる

実装の起点は、対象が静的か動的かの1点です。動的だと分かっている場合を除き、まず軽いRequests＋BeautifulSoupで取得を試し、データが取れなければブラウザ自動操作へ切り替える順が、無駄なくコストを抑えられます。

スクレイピングを採用すべき条件と法務・負荷で見送るべき失敗パターン

ここからは判断を言い切ります。スクレイピングでつまずくのは、技術的なハードルよりも法務とサーバー負荷の線引きの側です。取得できることと、取得してよいことを分けて設計しないと、便利な自動処理が後で相談窓口ではなくトラブル対応の起点になります。

robots.txtと著作権法30条の4・サーバー負荷で守るべき実務上の線

守るべき線は、大きく3つに整理できます。第一が、対象サイトのrobots.txtと利用規約です。robots.txtはクローラーの巡回可否を示す取り決めで、法的な強制力はないものの、これを無視した収集は規約違反の根拠になり得ます。利用規約で自動取得を明示的に禁じているサイトからの取得は避けるのが基本線です。

第二が、著作権と情報解析の扱いです。日本では2018年改正の著作権法30条の4により、情報解析（多数の著作物から情報を抽出・比較・分類する解析）を目的とする複製は、権利者の許諾なく行える旨が定められています。AIの学習データ収集などはこの範囲に入り得る扱いです。ただし、収集したデータをそのまま再配信・転載する行為は別問題で、著作権侵害になり得ます。目的が「解析」か「複製物の利用」かで扱いが変わる点を押さえておく必要があります。

第三が、サーバー負荷です。短時間に大量のリクエストを送ると、相手サーバーに過大な負荷をかけ、業務妨害と受け取られかねません。過去には、公共図書館のサイトへ自動アクセスした利用者が逮捕された事例（いわゆる岡崎市立中央図書館事件、2010年）もあり、負荷のかけ方次第で刑事事件に発展した前例として引かれます。リクエストの間隔を1秒程度以上空ける、深夜帯に集中させない、User-Agentを明示するといった配慮を、コード側の設計に組み込みます。

スクレイピングを見送るべき場面と構造変更・IP遮断の失敗パターン

見送るべきは、正当性か安定性のどちらかが崩れる場面です。公式APIで要件を満たせるのにスクレイピングを選ぶ、利用規約が自動取得を明確に禁じている、収集データを解析ではなく再配信する——これらは法務リスクが技術的な利点を上回ります。

技術面で頻出する失敗パターンは3つあります。1つ目は、サイトのHTML構造が変更され、指定していたタグや属性がずれて抽出が突然壊れるケースです。定期収集を組むなら、抽出失敗を検知して通知する仕組みまで含めて設計しないと、気づかないうちに空データを集め続けます。2つ目は、アクセス頻度の高さからIPアドレスを遮断され、収集が止まるケース。3つ目は、規約や負荷の確認を後回しにしたまま本番運用を始め、相手先からの警告で急遽停止するケースです。特に構造変更への脆さは、収集そのものより保守フェーズのコストを押し上げる要因になります。

スクレイピングで集めたデータをAIで使う構想と内製か受託かの判断

スクレイピングの用途は、価格監視や市場調査だけではありません。近い用途として増えているのが、社内文書や公開情報を収集し、生成AIの検索対象（RAGの知識源）として使う構想です。この場合、収集の仕組みと、集めたデータを検索・回答に結び付けるAI側の設計を、一体で組む必要があります。取得の正当性を確保し、構造変更に強い保守可能な収集基盤を作り、それをAIの応答品質に接続する——ここまで通して設計できるかが成否を分けます。

自社に収集基盤とAIの両方を実装する知見が薄い段階では、データ収集の設計とAI連携の設計を外部と組み、運用しながら内製比率を上げる進め方が現実的です。収集したデータを問い合わせ対応や社内検索に生かすAIチャットボットまで見据えるなら、データ収集を含むAIチャットボット開発の相談窓口で、どのデータをどう集めてRAGに載せるかの見立てから設計を詰められます。収集の正当性と保守性を最初に固めておくと、後段のAI連携が安定する。土台となる大規模言語モデルの仕組みはLLMの仕組みと企業導入の判断基準で押さえておくと、収集データの生かし方が具体的に描けます。

スクレイピングとクローリング・API・法務に関するよくある質問

実装や導入の検討初期に挙がりやすい疑問を、5点に絞って答えます。

スクレイピングとクローリングは何が違いますか？

目的が異なります。クローリングはリンクをたどってサイトを巡回し、ページの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です。

APIがあるサイトでもスクレイピングすべきですか？

公式APIで要件を満たせるなら、APIを優先します。APIは提供側が意図的に開いた出入口で、データが構造化され、規約や取得上限も明示されているため、HTML構造の変更で壊れる保守リスクがありません。スクレイピングを選ぶのは、APIが存在しない、または取得項目・件数・頻度が要件に足りない場合に限るのが妥当です。

関連記事

• BeautifulSoupとは？インストールから基本的な使い方・スクレイピングまで解説：静的サイトのHTML解析に使う定番ライブラリ。本記事の抽出段階を具体的なコードで実装する際の入口になります。
• Playwright MCPで始めるブラウザ自動化の基本：JavaScriptで描画される動的サイトの取得に必要なブラウザ自動操作。動的サイトのスクレイピングを組む土台です。
• LLMとは？大規模言語モデルの仕組みと企業導入の判断基準：収集したデータをRAGや生成AIで使う際の土台。集めたデータをどう活かすかを検討する前段として押さえられます。