「スクレイピングって名前は聞くけど、結局なに？」「やってみたいけど違法じゃない？」「クローリングやAPIと何が違うの？」――この記事では、これからスクレイピングを学びたい人と、業務での導入を検討している人の両方に向けて、定義・仕組み・違法性・活用例・実装方法を実務目線で整理します。法律の根拠条文や実際の判例、ツール選定の指針まで、初心者がつまずきやすい論点を網羅的に解説します。
スクレイピング（scraping）は、英単語 scrape（削る・こすり取る）が語源です。 30秒でわかる定義
スクレイピングには大きく2種類あります。一般に「スクレイピング」というとき、ほとんどのケースは後者のWebスクレイピングを指します。
スクレイピングとは
ITの分野では、Webサイトから必要な情報を自動で取り出し、データとして使える形に整える技術を指します。
たとえば、ECサイトの商品価格を毎日取得して比較したり、求人サイトから条件に合う案件だけを抽出してスプレッドシートに溜めたり――こうした「人間がブラウザでやれば数時間かかる作業」を、プログラムが数秒で代行するイメージです。
スクレイピングとクローリング・APIの違い
初学者が最も混同しやすいのが、クローリングとAPIとの関係です。3者は目的も役割も違うため、ここを最初に整理しておくと、以降の話がスッと入ります。
クローリングとの違い：「巡回」と「抽出」
クローリングは、Webを「巡回して発見・収集する」技術です。代表例はGoogleの検索エンジン用クローラ（Googlebot）で、リンクをたどりながら未知のページを見つけて回ります。一方スクレイピングは、見つけたページから「特定のデータを抜き出す」技術です。
| 観点 | クローリング | スクレイピング |
|---|---|---|
| 主目的 | Webを巡回し、ページを発見・収集する | ページから必要なデータを抽出する |
| 探索の幅と深さ | 広く浅く（網羅的） | 狭く深く（特定項目に集中） |
| 主な出力 | URL一覧、ページ全体 | 価格・商品名・在庫など、構造化データ |
| 代表例 | Googlebot、サイトマップクローラ | 価格比較ツール、競合分析ツール |
実務では2つを組み合わせることが多く、「クローリングでURLを収集し、各URLにスクレイピングをかけてデータを抽出する」のが定番のパイプラインです。
APIとの違い：「公式の窓口」か「独自取得」か
APIは、サービス提供者側が「ここからどうぞ」と用意した公式の窓口です。X（旧Twitter）APIやGoogle Maps APIのように、提供者が許可した範囲のデータを、JSON等の構造化形式で安定的に取れます。一方スクレイピングは、提供者の意図に関わらず、HTMLに表示される情報を取得側が独自に取り出す手法です。
| 観点 | API利用 | スクレイピング |
|---|---|---|
| 提供元の立場 | サービス側が許可・公開 | 取得側が独自に取得 |
| 取れるデータ | 提供者が許可した範囲のみ | HTMLに表示される情報すべて |
| 形式 | JSON / XML など構造化済み | HTMLを都度パースする必要 |
| 安定性 | 仕様変更時は事前通知あり | サイト構造変更で予告なく停止 |
| 法的安全性 | 利用規約に従えば原則OK | 規約・著作権・個人情報法のリスクあり |
| カバー率 | 提供されないデータは取れない | HTMLがあれば原則取得可能 |
使い分けの原則
APIがあるなら、まずAPIを使う。これが鉄則です。安定性・速度・法的安全性のすべてでAPIが上回ります。スクレイピングは「APIが提供されていない」「APIに必要なデータが含まれていない」「APIの利用上限が厳しすぎる」といったAPIの限界を補う手段と位置づけるのが健全です。
スクレイピングの仕組み
Webスクレイピングは、技術的には次の3ステップに分解できます。どのライブラリ、どのツールを使っても、内部的にはこの流れをたどっています。
1. ページの取得（HTTPリクエスト）
対象のURLにHTTPリクエストを送り、レスポンス（HTMLや関連リソース）を取得します。Pythonであれば requests ライブラリ、Node.jsなら fetch や axios がよく使われます。シンプルなページならこれだけで完結します。
2. HTMLの解析（パース）
取得したHTML文字列を、プログラムが扱いやすいツリー構造に変換します。代表的なライブラリは Python の BeautifulSoup、Node.js の Cheerio。CSSセレクタやXPathで目的の要素を指定できるようになります。
3. データの抽出と整形
パースしたツリーから、必要な要素（商品名、価格、URLなど）を取り出し、CSV・JSON・データベースなどの形式に整えます。文字コードの変換、不要なHTMLタグの除去、価格表記の正規化（「￥1,980」→ 1980）といった泥臭い処理がここに入ります。
静的サイトと動的サイトで難易度が変わる
-
静的サイト（サーバーサイドレンダリング）：HTTPで取得したHTMLに必要な情報がすでに含まれている。
requests + BeautifulSoupで軽快に処理できる -
動的サイト（JavaScriptレンダリング、SPA）：ブラウザがJSを実行した後に情報が描画される。
Selenium/Playwrightなどのヘッドレスブラウザが必要で、処理コストが大きく上がる
スクレイピングのメリット
手作業では現実的でない規模のデータ収集を、安価かつ継続的に実現できる――これがスクレイピングの本質的な価値です。
- 大量データを自動収集できる：数千〜数百万ページのデータを、人手をかけずに収集可能。コピペでは1日で力尽きる量を、プログラムなら数時間で処理できる
- APIが提供されていないデータも取れる：ほとんどのWebサイトはAPIを公開していない。スクレイピングは「公式チャネルがない」状況の唯一の選択肢になることが多い
- リアルタイム性：1時間ごと、1日ごとなど任意の頻度で最新データを取り続けられる。価格変動や在庫の動きを常時モニタリングできる
- 取得形式を自由に設計できる：自社の分析基盤に合わせてカラム構成・粒度を自由に決められる。後段のBIツールやAIモデルに直接流し込める
- 競合・市場の継続観察：定点観測することで、価格戦略や新商品投入の傾向など、Webからしか見えない動きを捉えられる
スクレイピングのデメリット・運用上の落とし穴
一方で、スクレイピングは「動いた瞬間がゴール」ではなく、運用フェーズに入ってから本当の難しさが出てきます。導入前に必ず押さえておきたい論点を整理します。
- サイト構造の変更で壊れる：HTMLのクラス名やDOM構造が変わるたびにスクリプトが動かなくなる。「作って終わり」がなく、永久にメンテが続くと思っておくのが現実的
- サーバー負荷とブロック対策：取得頻度が高いとIPブロック、レート制限、CAPTCHAなどの対策を受ける。プロキシやリトライ設計が必要になる
- 動的サイトの技術ハードル：SPA・JS描画サイトはヘッドレスブラウザが必要で、CPU・メモリ消費が10倍以上になることもある
- 法的リスクの管理コスト：規約・著作権・個人情報の3点セットを継続的に確認する必要がある。法務レビューを通せる体制が必要
- アンチボット技術への対応：Cloudflare Bot Management、reCAPTCHA、DataDomeなどの検知に対応するコストは年々上がっている
注意：スクレイピングは「初期構築コスト」より「運用維持コスト」のほうが圧倒的に大きくなります。「1回動かしたら終わり」のつもりで始めると、ほぼ確実に半年以内に破綻します。最初から監視・通知・差分検知の設計を入れておくのが堅実です。
スクレイピングは違法か？4つの法律リスクと根拠
最も読者が気になるのがここでしょう。結論から言うと、スクレイピングという行為そのものは違法ではありません。Webサイトに公開されている情報を機械的に取得しているに過ぎず、技術的には「ブラウザで開く」のと同じことをしているからです。
ただし、取得方法・取得対象・取得後の使い方によって、複数の法律に抵触し得ます。実際に逮捕者が出た事例も存在するため、ここを軽く扱うのは危険です。以下、代表的な4つのリスクを根拠条文とセットで整理します。
① 業務妨害罪（刑法233条 / 234条の2）
最も「刑事事件化」しやすいのがこのリスクです。過剰なアクセスで対象サイトのサーバーが不安定になったり停止したりすると、偽計業務妨害（刑法233条）または電子計算機損壊等業務妨害（刑法234条の2）に問われる可能性があります。
判例：岡崎市立中央図書館事件（2010年）
ある男性が、岡崎市立中央図書館の蔵書検索システムから新着図書情報を自動取得するクローラを運用したところ、システムにアクセス障害が発生。男性は偽計業務妨害容疑で逮捕、22日間勾留されました。最終的に起訴猶予となりましたが、注目すべきはクローラの動作が「1秒に1アクセス程度」と極めて穏当だったことです。原因の大半は、図書館側が使っていた旧版ソフトウェアの不具合（1時間あたり400リクエスト超で他のリクエストを処理できなくなる）にありました。
この事件が示しているのは、「礼儀正しいクロール」をしていても、相手のシステム次第で刑事リスクを負うことがあるという現実です。本番運用前には必ず、対象サーバーへの影響を見積もる必要があります。
② 個人情報保護法違反
Webから個人情報（氏名、メールアドレス、電話番号など）を取得する場合、利用目的を事前に公表または通知する義務があります（個人情報保護法21条）。さらに、病歴・犯罪歴・人種などの要配慮個人情報は本人同意なく取得することができません（同法20条2項）。
- 取得時：利用目的の事前公表・通知が必須
- 要配慮個人情報：本人の事前同意が必要
- 第三者提供：原則として本人同意が必要
SNSや口コミサイトから氏名・連絡先を集めて営業リスト化する、といった用途は法令違反のリスクが極めて高い領域です。
③ 利用規約違反（民事責任）
サイトの利用規約で「スクレイピング・自動取得を禁止する」と明記されている場合、それに反する取得は債務不履行や不法行為として、損害賠償請求や差止請求の対象になり得ます。Amazon・楽天・メルカリ・X（旧Twitter）・Instagram など、多くの大手プラットフォームが規約で明確に禁止しています。
利用規約は「読まなくても同意したことになる」性質を持つため、取得開始前に必ず規約を確認するのが必須プロセスです。
④ 著作権法21条違反（複製権）
スクレイピングは、技術的には対象ページのHTMLや画像を自分のサーバーに「複製」する行為です。著作物の複製は原則として権利者の同意が必要です（著作権法21条）。ただし、ここには重要な例外があります。
重要な例外：著作権法30条の4（情報解析の権利制限）
2018年改正で導入された条文です。「著作物に表現された思想又は感情の享受を目的としない」利用――つまり、人間がコンテンツを鑑賞する目的ではなく、AI学習や統計解析のためにデータを処理する目的であれば、権利者の許諾なく利用できます。AI開発のための大量データ収集は、原則としてこの規定で適法化されています。
ただし、「権利者の利益を不当に害する場合」は対象外です。たとえば、有償提供されているデータベースを丸ごとコピーする行為は、たとえAI学習目的でもこの例外にあたりません。
robots.txt は守るべきか？
robots.txt は、Webサイト側がクローラに「ここはアクセスを控えてほしい」と示す設定ファイルです。日本では法的拘束力はなく、無視しても直ちに犯罪とはなりません。いわゆる「紳士協定」です。
ただし、米国では robots.txt 無視が訴訟における「悪意の証拠」として使われた事例があり、EU の GDPR でも「正当な利益」を主張するうえで不利な要素になります。グローバル展開を見据えるなら、遵守を強く推奨します。
スクレイピングの代表的な活用シーン
ここまで読んで「結局、何に使えるのか？」が気になっている方も多いはずです。実務での代表的なユースケースを整理します。市場規模の観点では、世界のWebスクレイピング市場は2025年時点で約99億ドル、2030年には228億ドルへ拡大すると予測されており、企業活動のあらゆる場面でデータ収集の需要が高まっています。
価格・在庫モニタリング（EC・小売）
競合ECの価格を毎日取得し、自社の販売価格を動的に調整する用途。プライシング戦略やセール検知の基盤となります。Amazon、楽天、ヨドバシなど主要ECの価格を横断的に追うニーズは年々高まっています。
競合・市場リサーチ
競合サイトの新商品・キャンペーン・採用情報を継続的に取得し、市場の動きを定点観測する用途。手作業でやれば数日かかる作業を、自動化することで日次の意思決定材料に変えられます。
不動産・求人情報の集約
SUUMO・HOME’S・Indeed など、複数の業界ポータルから物件・求人情報を集約し、検索性の高い独自プラットフォームに整える用途。アグリゲーション型ビジネスの根幹技術です。
ニュース・SNS の動向分析
ニュースサイトやSNSから自社・自社製品への言及を集め、ブランドモニタリングやセンチメント分析に使う用途。広報・PR部門での需要が大きい領域です。
AI・機械学習用の学習データ収集
生成AIや業務特化AIの学習用に、テキスト・画像データを大量収集する用途。スタートアップAI企業の約4割が自動データ収集ツールを使っているという調査もあり、現代AI開発の基盤になっています。著作権法30条の4の権利制限規定によって、日本ではこの用途のスクレイピングは比較的やりやすい立て付けになっています。
SEO競合分析
検索結果ページ（SERP）の順位、上位記事の見出し構成、被リンクの動向などを取得し、SEO戦略立案に活用する用途。Ahrefs や Semrush の中身も、本質的にはこの種のスクレイピング技術が支えています。
スクレイピングを実現する3つの方法
スクレイピングを社内で導入する際、選択肢は大きく3つです。「コスト・柔軟性・運用負荷」のトレードオフで決めることになります。
① 自前実装（PythonなどのプログラミングでDIY）
- メリット：完全にカスタマイズ可能。ライセンス費用ゼロ。社内に技術資産が残る
- デメリット：開発・運用・法務すべて自社負担。属人化しやすい。動的サイト対応に技術力が要る
- 向くケース：エンジニアが社内にいて、長期的に内製したい。要件が特殊で既製ツールに合わない
② ノーコードツールの活用（Octoparse、ParseHub、Apify など）
- メリット：プログラミング不要、立ち上げが早い、テンプレが豊富
- デメリット：細かい挙動の制御に限界。月額費用がかかる。ベンダーロックインのリスク
- 向くケース：エンジニアがいない／早く検証したい／対象サイトが標準的な構造
③ 業務委託（スクレイピング専業会社への外注）
- メリット：要件整理から運用・法務まで丸投げできる。プロのノウハウで失敗リスクを抑えられる
- デメリット：初期費用・月額が比較的高め。情報共有のオーバーヘッドはある
- 向くケース：社内に専門人材がいない／規模が大きい／継続運用が前提／法的リスクを最小化したい
| 選択肢 | 初期コスト | 運用負荷 | 柔軟性 | 法務サポート |
|---|---|---|---|---|
| 自前実装 | 低（開発工数次第） | 高い（自社で監視・修正） | ◎ | ×（自社対応） |
| ノーコードツール | 低〜中 | 中（設定変更で対応） | △ | △（限定的） |
| 業務委託 | 中〜高 | 低い（丸投げ可能） | ○ | ◎ |
スクレイピングに使われる主要言語・ツール
実装に使う言語とライブラリは、対象サイトの性質によって選ぶべきものが変わります。代表的な選択肢を整理します。
Python（最も主流）
日本語の情報量・コミュニティ・ライブラリの豊富さでトップ。初心者にも経験者にも第一候補です。
| ライブラリ | 主な役割 | 適した場面 |
|---|---|---|
| Requests | HTTPリクエスト | 静的ページの取得。軽量で速い |
| BeautifulSoup | HTML / XMLパース | 抽出ロジックを書きやすい。Requestsとセットで定番 |
| Scrapy | クローリング＋抽出のフレームワーク | 大規模・並列・継続運用。本格運用ならまずこれ |
| Selenium | ブラウザ自動化 | JS描画・ログイン・フォーム操作が必要なサイト |
| Playwright | ブラウザ自動化（Microsoft製） | Selenium後継。複数ブラウザ対応で速度・安定性が高い |
JavaScript / Node.js
フロントエンドエンジニアが多い組織や、JS製のSPAを対象にするときに有力。
- Puppeteer：Google製のヘッドレスChrome操作ライブラリ
- Playwright：複数ブラウザ対応の自動化ライブラリ（Node.js版）
- Cheerio：jQueryライクな書き味でHTMLをパースできる軽量ライブラリ
- Crawlee：Apify社が公開する、本格運用向けのクロールフレームワーク
ノーコードツール
コードを書かずにブラウザ操作を記録・再生する形でスクレイピングできるツール群。非エンジニアでも扱えます。
| ツール | 強み | 注意点 |
|---|---|---|
| Octoparse | AI自動検出機能、テンプレ豊富、初心者に最も親しみやすい | 大量実行はクラウド有料プラン必須 |
| ParseHub | JS・AJAX・複雑な動的サイトに強い | 学習コストはやや高め |
| Apify | 6,000以上の事前構築Actorとクラウド実行環境 | 完全ノーコードではなく、入力スキーマの理解が要る |
| Bright Data | 世界最大級のプロキシ網、Cloudflare等のアンチボットを突破するWeb Unlocker | エンタープライズ価格帯。個人利用には重い |
スクレイピング導入の判断フロー
最後に、これからスクレイピングを始める／導入を検討している方向けに、判断ステップを整理します。順番が大事です。技術的に動く前に、必ず規約と代替手段を確認してください。
ステップ1：対象サイトの規約・robots.txt を確認
まずは対象サイトの利用規約に「スクレイピング」「自動取得」「ロボット」「クローラ」などの単語で禁止条項がないかを確認します。robots.txt は https://対象ドメイン/robots.txt で誰でも読めます。明示的に禁止されているサイトは候補から外すのが原則です。
ステップ2：APIや代替手段の有無を確認
対象サービスに公式APIがある場合は、まずそちらを検討します。データセット販売（Statista、SimilarWeb、Bright Dataのデータマーケット等）が代替になることもあります。「APIで足りるならAPI、データセットで足りるならデータセット」を必ず先に検証します。
ステップ3：取得頻度・データ量を見積もる
1日のリクエスト数、ページ数、対象サーバーへの想定負荷を見積もります。岡崎図書館事件のように、相手のシステム次第で「常識的なペース」でも問題になり得ます。本番運用前に、テスト環境で負荷を計測することを強く推奨します。
ステップ4：内製・ツール・外注の3択を選ぶ
- 社内エンジニアあり × 長期運用：自前実装が有利
- 非エンジニア × 標準的なサイト × 短期検証：ノーコードツール
- 大規模 × 継続運用 × 法務リスクを最小化したい：業務委託
ステップ5：監視・メンテ体制を先に作る
スクレイピングは「作ってから運用」ではなく、「監視ありきで作る」のが事故を防ぐコツです。少なくとも以下の3点は最初から仕込んでおきます。
- 成功率の監視：URL単位・サイト単位での成功・失敗をメトリクス化
- 抽出品質の監視：必須フィールドの欠損率、型エラー率
- 変化量の監視：取得値が前日比で異常な動きをしていないか（壊れた抽出を検知できる）
スクレイピングの設計・運用でお困りではありませんか？
スクレイピング特化のWilicoでは、要件整理・実装・運用監視・法務確認まで一貫してご支援しています。価格モニタリング、競合分析、データ集約など、ECからメディア運営まで多数の実績があります。「自社で作るか外注するか」の判断段階からご相談いただけます。
スクレイピングに関するよくある質問
Q. スクレイピングは犯罪になりますか？
スクレイピングという行為そのものは犯罪ではありません。ただし、過剰なアクセスでサーバーに障害を与えれば偽計業務妨害・電子計算機損壊等業務妨害に問われ得ますし、個人情報を不適切に扱えば個人情報保護法違反、規約違反は民事の損害賠償リスクになります。「やり方次第で犯罪になり得る」と理解するのが正確です。
Q. robots.txt を守れば100%安全ですか？
いいえ。robots.txt はあくまで「紳士協定」であり、それに従っても利用規約違反や著作権侵害が成立することはあります。逆に、robots.txt が許可していても、規約で禁止されていれば民事リスクが残ります。規約・robots.txt・著作権の3点セットで確認するのが正しい運用です。
Q. ログインが必要なサイトはスクレイピングしてOK？
ログインが必要 = 利用規約への同意を要求されているケースがほとんどです。多くのサービスは規約で自動取得を禁じているため、ログイン後のページのスクレイピングは原則NGと考えるのが安全です。どうしても必要な場合は、API提供の有無やパートナー契約の可能性を先に確認します。
Q. 取得したデータは自由に利用できますか？
いいえ。取得行為が適法でも、取得後の利用には著作権法・個人情報保護法・不正競争防止法（営業秘密）などが別途かかります。「取れたから使える」ではなく、用途ごとに権利関係を確認するのが原則です。社外公開や商用販売はとくに慎重に判断します。
Q. APIが提供されているサイトをスクレイピングしてもいい？
技術的には可能ですが、APIがあるのにスクレイピングを使うのは合理的ではありません。安定性・速度・法的安全性のすべてでAPIが上回るうえ、APIを提供している側は規約で「APIを通じてアクセスせよ」と定めていることも多く、規約違反になります。原則はAPI、APIで足りない部分だけスクレイピングが健全です。
Q. AI学習用にスクレイピングするのは合法ですか？
日本では2018年改正の著作権法30条の4により、AI学習や統計解析など「思想・感情の享受を目的としない利用」は権利者の許諾なしで可能とされています。AI開発のためのデータ収集は、原則としてこの規定で適法化されているといえます。ただし、有償データベースの丸ごとコピーなど「権利者の利益を不当に害する」場合は対象外です。また、利用規約での禁止や個人情報保護法の規制は別途適用されるため、合算でリスクを判断する必要があります。
Q. 個人で趣味目的のスクレイピングは大丈夫？
個人利用かつ私的範囲であれば、著作権法30条（私的使用のための複製）でカバーされる範囲が広がります。ただし、規約違反や業務妨害のリスクは個人利用でも変わらず発生し得ます。岡崎市立中央図書館事件の被疑者も、業務目的ではなく純粋に技術的興味で始めた個人プロジェクトでした。「個人だから安全」は通用しないと理解しておくのが安全です。
まとめ
- スクレイピングは「Webから必要なデータを自動抽出する技術」。仕組みは取得・解析・抽出の3ステップ
- クローリングは「巡回」、APIは「公式の窓口」。スクレイピングはAPIで足りない部分を補う独自取得と位置づけるのが健全
- 行為自体は違法ではないが、業務妨害・個人情報・規約違反・著作権の4つのリスクを常に意識する必要がある
- AI学習用のスクレイピングは著作権法30条の4で広く許容されているが、規約・個人情報の規制は別途適用される
- 実装は Python（Requests・BeautifulSoup・Scrapy・Playwright）が主流。動的サイトはヘッドレスブラウザ必須
- 導入時は規約確認 → API代替検討 → 負荷見積もり → 内製/ツール/外注の選択 → 監視設計の順で進める
スクレイピングは強力な武器ですが、「技術的に動かすだけ」と「事故なく長期運用する」の間には大きな隔たりがあります。最初から運用・法務・監視を組み込んだ設計にしておくことが、結果的に最短ルートになります。
参考資料
