スクレイピングの注意点｜規約違反・停止・保守地獄を避ける判断フロー

結論：スクレイピングは「規約→代替→許可→最小限」の順で判断すると安全

スクレイピングは、技術的に“できる”ことと、実務として“やっていい”ことが別です。副業で自動化を仕事につなげたいなら、まず利用規約（契約）を確認し、次にAPIやエクスポートなどの代替手段を探し、それでも必要な場合に許可（書面）を取って、最後に最小限のスクレイピングを検討するのが安全ルートです。X（旧Twitter）は規約サマリーで「書面許可なしのスクレイピング不可」と明記しています。

なぜ「スクレイピング 規約 注意」が副業初心者の地雷になりやすいのか

副業では、クライアントから「競合の価格を一覧化して」「店舗情報を集めて」「求人を集計して」など、データ収集の自動化が求められがちです。ここでスクレイピングを安易に選ぶと、次のようなリスクが現実に起こります。

• 規約違反（契約違反）：サイト側の禁止条項に触れてアカウント停止・アクセス遮断・損害対応の話になる
• 信頼リスク：クライアントが「そのデータ、出どころ大丈夫？」と不安になり、継続案件になりにくい
• 技術リスク：仕様変更・bot対策で突然動かなくなり、納期直前に崩壊する
• 権利・個人情報リスク：転載・再配布・個人データの扱いで炎上やトラブルの引き金になる

大事なのは「スクレイピングするか？」ではなく、目的を達成する最も安全で再現性の高い手段は何か？で考えることです。

まず整理：スクレイピング／クローリング／自動化は何が違う？

用語が混ざると判断がブレます。最初に雑にでも線引きしておくと、クライアント説明もラクになります。

• スクレイピング：ページから「欲しい情報（価格、住所、見出し等）」を抽出してデータ化する行為
• クローリング：リンクを辿ってページを巡回（収集）する行為（抽出を伴う場合も多い）
• ブラウザ自動化（RPA/ヘッドレス）：人間の操作を真似してログインやクリックを自動化する行為（規約違反になりやすい）

初心者がつまずきやすいのは「HTMLは読める＝許される」だと勘違いする点です。許可の根拠は技術ではなく、規約・許諾・提供されている公式手段（API等）にあります。

robots.txtは「許可証」ではない（見ても安心できない）

「robots.txtでDisallowされてないからOK」——これは危険です。robots.txt（Robots Exclusion Protocol）は、クローラーに対するお願い（推奨）であり、RFCでもアクセス認可（authorization）の仕組みではないと説明されています。

つまり、robots.txtが許可していても規約で禁止されていることがありますし、逆にrobots.txtでDisallowでも、サイト運営者から許可を取っていれば実務上問題ないケースもあります。判断の中心は、robots.txtではなく利用規約と許諾です。

迷ったらこれ：判断フロー（API→エクスポート→許可→最小スクレイピング）

「取れるかどうか」より「安全に納品できるか」で並べ替えると、判断が速くなります。

目的：データを集めたい ↓ 1) 公式APIはある？（提供元が許可している道） 
├─ Yes → APIで取得（最優先） 
└─ No ↓ 2) エクスポート/フィード/配布データはある？（CSV・RSS・公開データ等） 
　　├─ Yes → それを使う 
　　└─ No ↓ 3) 許可を取れる？（書面・メールでOK範囲を明確化）
　　　　├─ Yes → 許可の範囲で実施 
　　　　└─ No ↓ 4) それでも必要？（要件を縮小：頻度/件数/対象ページ） 
　　　　　　└─ 最小限のスクレイピング＋マナー設計（負荷・個人情報・再配布を避ける）

この順番にしておくと、仮に途中で「やっぱり規約が厳しい」と分かっても、代替案に自然に戻れます。

利用規約で見るべきポイント（副業で事故が起きるのはここ）

規約は長いですが、初心者が確認すべきポイントはだいたい固定です。検索（Ctrl+F）で次の単語を探すと早いです。

• automated / bot / crawler / scraping / data extraction / data mining（自動取得の禁止）
• commercial / business / resale / reproduce（商用利用・再配布の制限）
• login / account / security（ログイン後に適用される追加制限）
• API / rate limit（公式手段・上限の有無）

実際に、大手サービスでは「自動取得・抽出」を明確に止めています。例えばAmazonの利用規約（Amazon Relay JPのページ）には、書面の明示的承諾なしに「データマイニング、ロボットなどのデータ収集・抽出ツール」を使った抽出や再利用ができない旨が記載されています。

X（旧Twitter）も、規約サマリーで「書面許可なしのスクレイピング不可」と明記しています。またLinkedInも、Service Termsで「書面で明示的に許可されない限り、スクレイピングやデータ抽出の自動手段を使わない」旨が記載されています。

Instagramも「明示的許可なく自動的にアクセス・収集する行為」を含む禁止を規約に含めています。（※アクセス制限で全文確認できないことがあるため、最新のTermsページを必ず自身でも確認してください）

日本の法律との距離感：著作権法30条の4は“免罪符”ではない

注意：ここは一般情報です。個別案件での適法性判断は、状況で変わります。迷う場合はクライアントと合意条件を整理し、必要に応じて専門家へ相談してください。

日本には、著作物を「思想・感情の享受を目的としない」形で利用する場合の柔軟な権利制限規定（著作権法30条の4）があります。文化庁の資料でも、情報解析（AI学習データ収集など）に伴う利用が整理されています。

ただし、副業で問題になりやすいのは「著作権だけ」ではありません。たとえ著作権の論点が整理できても、

• サイトの利用規約（契約）に違反していればトラブルになり得る
• 個人情報・営業秘密・再配布など別の論点が出る
• 大量アクセスでサービス運営を妨げる形になると別リスクになる

だから初心者ほど、まずは「規約遵守」と「公式手段の優先」に倒すのが現実的です。

代替案：スクレイピングせずに目的を達成する方法（まずここを探す）

「自動で集めたい」＝「スクレイピング」ではありません。実務では、次の代替案がいちばん安定します。

例えばAmazonにはProduct Advertising APIのような公式APIが用意されています（用途・条件あり）。 InstagramもMetaの公式API群が案内されています。 Xも開発者向け契約・ポリシーが公開されています。

「APIがあるかどうか」を最初に確認するだけで、後から崩れる案件をかなり減らせます。

それでも必要なら：トラブルを起こしにくい設計（やるなら“最小・低負荷・説明可能”）

どうしてもスクレイピングが必要な状況（例：対象が自社サイト、許可済みサイト、クライアント保有データの収集など）では、次の方針を徹底すると事故が減ります。

• 対象を絞る：全ページではなく「必要なURLだけ」に限定
• 頻度を落とす：連打しない。429（Too Many Requests）等が出たら停止
• キャッシュする：同じページを何度も取りにいかない
• ログイン前提の取得を避ける：個人情報や会員限定領域は特に危険
• 再配布しない：集めたデータをそのまま公開・販売しない（要件を再確認）

実装のイメージ（「負荷をかけない」ための最低限）だけ、短く載せます。※回避・突破系のテクニック（CAPTCHA回避等）は扱いません。

import time
import requests

URLS = [
    # 許可済み / 自社 / 規約で許されている範囲のURLだけに限定する
]

session = requests.Session()
headers = {"User-Agent": "YourServiceName (contact: you@example.com)"}

for url in URLS:
    r = session.get(url, headers=headers, timeout=10)

    # レート制限っぽい挙動が出たら即停止（無理に続けない）
    if r.status_code in (429, 403):
        break

    # ここで抽出処理（省略）

    time.sleep(1.0)  # 連打しない。最低限の待機を入れる

よくある失敗4選（初心者がやりがち）と回避策

• 失敗1：robots.txtだけ見て実行
  回避：robots.txtは許可証ではない。規約・許諾・公式手段（API）を優先する。
• 失敗2：「無料で集めたデータ」をそのまま納品・再配布
  回避：納品形態（再配布・公開・二次利用）まで含めて規約と合意を確認。データの“使い道”が一番危ない。
• 失敗3：ログイン後に自動化してしまう
  回避：ログイン領域は追加規約・個人情報が絡みやすい。必要なら必ず許可と範囲を明確化し、要件を縮小する。
• 失敗4：仕様変更で壊れて納期遅延
  回避：最初から代替案（API・エクスポート・手作業）を用意し、壊れたら切り替える運用にする。

具体例：副業で「競合の価格一覧を毎日ほしい」と言われたらどうする？

たとえば、クライアントから「競合サイトの価格を毎日集計してスプレッドシートにしてほしい」と依頼されたケースを考えます。未経験だと「よし、スクレイピングで一発だ」となりがちですが、ここで判断フローに戻します。

• Step1：目的の再定義：毎日必要？週1でも意思決定できる？「上位20商品だけ」でも足りる？
• Step2：公式手段の探索：API、CSV配布、RSS、メール通知、提携データがないか確認
• Step3：許可・合意を取る：対象サイトが限定されるなら、運営者に許可を取れるか検討（難しいなら要件を縮小）
• Step4：最小実装：どうしても必要で、かつ許可/規約上問題ない範囲に限定できる場合のみ、低負荷で実装

この進め方だと、仮にスクレイピングができなくても「代替案で納品できる」状態を保てます。副業で強いのは、コード力よりもトラブルを起こさずに納品する設計力です。

すぐ使えるチェックリスト（コピペOK）

• 目的は「何を」「どの頻度で」「どの形式で」必要？（要件を削れる？）
• 対象サイトに公式API・提供データ（CSV/RSS等）はある？
• 利用規約に「scraping / automated / data extraction」等の禁止がないか確認した？
• ログインが必要なページを対象にしていない？（原則避ける）
• 取得データを再配布・公開・販売しない？（二次利用条件を確認）
• アクセス頻度を落とし、429/403が出たら停止する設計？
• 仕様変更で壊れたときの代替案（手作業/別手段）を用意した？
• クライアントに「データの出どころ・取得方法」を説明できる？

まとめ

スクレイピングは、うまく使えば自動化の武器になりますが、副業初心者が最初に触ると事故りやすい領域です。安全に進めるコツはシンプルで、規約確認→代替案→許可→最小限の順で判断すること。robots.txtは認可ではないので、安心材料にしない。

大手サービスはスクレイピングや自動抽出を明確に禁止している例があるため、まず公式APIや提供データを探すのが現実的です。

次にやること（3ステップ）

• ステップ1：今考えている自動化を、判断フローに当てはめて「API/提供データ/許可」の可能性を洗い出す
• ステップ2：対象サイトの利用規約で「automated / scraping / data extraction」を検索し、NGなら要件を縮小して代替案へ
• ステップ3：実装するなら「対象URL限定・低頻度・停止条件（429/403）・キャッシュ」を最低限入れて、説明可能な形にする