結論から言うと： GDPR はウェブスクレイピングそのものを禁止していません。ただし、スクレイパーが「特定できる個人」に関する情報を収集・保存・整理・再利用する場合、それは個人データの処理にあたります。「公開されていたから」というのは、コンプライアンス戦略にはなりません。
この線引きは、いまや無視できないほど重要になっています。2026年7月、欧州データ保護会議（EDPB）は、スクレイピングに個人データの処理行為が含まれる場合には GDPR が適用されるとの見解を示し、目的の限定と透明性を主要な論点として挙げました。新たなウェブスクレイピング・ガイドラインはまだ意見公募の段階ですが、方向性は明白です。つまり、ページを技術的に取得する行為は、コンプライアンス上の問いの入口にすぎないということです。EDPB の発表
本記事は法的助言ではなく、実務的な運用フレームワークです。プロダクトやエンジニアリングの判断を改善するために活用し、実際にリスクを伴うケースについてはプライバシー担当の弁護士や DPO（データ保護責任者）に相談してください。
まず「取得できるか」と「使えるか」を切り分ける
次の3つの異なる問いは、しばしば一緒くたにされがちです。
| 問い | 何を問うているか |
|---|---|
| アクセス | そのサイトにアクセスし、コンテンツを収集する権限があるか？ |
| データ保護 | 個人が特定できる場合、GDPR のもとでそのデータを処理できるか？ |
| 再利用 | それを保持・エンリッチ・販売・学習・公開したり、その情報で個人に連絡したりできるか？ |
どれか1つをクリアしても、残りをクリアしたことにはなりません。ページが誰でも閲覧できる状態でも、そこにあるデータが個人データであることに変わりはありません。技術的にクロールが成功しても、GDPR、契約、知的財産、データベース権、消費者保護、マーケティング法上の問題が生じる可能性があります。
そのため、コンプライアンスは「あとからプライバシーポリシーに一文足すもの」ではなく、ジョブを走らせる前のワークフローとして扱ってください。
1. GDPR の適用対象かどうかを判断する
まずは2つの問いから始めます。
そのデータセットに個人データは含まれるか？
個人データは、氏名やメールアドレスよりもはるかに広い概念です。識別された、または識別可能な個人に関する情報が該当し、プロフィール写真、個人と紐づけられるユーザー名、位置情報、IP アドレス、職歴、レビュー、あるいは単体では平凡な項目の組み合わせなども含まれます。EDPB による定義
企業単位のデータであれば問題にならないケースもあります。しかし「法人の連絡先」レコードでも、個人事業主の氏名、従業員の直通メールアドレス、携帯番号、紐づけられたプロフィールなどが含まれていれば、たちまち個人データになり得ます。理想化されたデータセットではなく、現実に取得されるデータセットを前提に設計しましょう。
自社と、その利用目的に GDPR は適用されるか？
GDPR は、処理が EU 内の拠点と結びついている場合に適用され得ます。また、EU 域外の組織であっても、EU 内の人々に商品やサービスを提供している場合、あるいはその行動をモニタリングしている場合には適用され得ます。欧州委員会による概説
両方の答えが「はい」なら、そのスクレイピングには文書化された GDPR 対応の道筋が必要だと考えてください。判断がつかない場合、その曖昧さを「ゴーサイン」と解釈してはいけません。エスカレーションしましょう。
2. クローラーを動かす前に、A4 一枚の「収集ブリーフ」を書く
もっともシンプルな統制が、もっとも価値があります。収集する前に、何が必要かを明文化することです。
ブリーフでは次の点に答えてください。
- 目的： どんな具体的な意思決定・サービス・分析のために、このデータが必要なのか？
- 対象者と項目： どのカテゴリの人物が登場し得るか。必要な項目は正確にどれか？
- ソースとアクセス： そのコンテンツは自由にアクセスできるか。利用規約、robots による制御、ログイン壁、その他の技術的手段によって、提供元は収集に異議を示していないか？
- 利用と提供先： 結果を誰が見るのか。データはエンリッチ、エクスポート、共有、ダイレクトマーケティング、モデル学習に使われるか？
- 保持期間： 生データ、作業ファイル、派生レコードは、いつ削除または見直すのか？
- 責任の所在： 管理者（コントローラー）は誰か、処理者（プロセッサー）は誰か、データ主体の権利行使には誰が対応するのか？
これは形式的な官僚仕事ではありません。GDPR の原則は、目的が特定されていること、そしてデータがその目的に照らして適切・関連性があり、必要最小限に限定されていることを求めています。欧州委員会が示す原則
3. 適法性の根拠を選び、文書化する——「あるはず」で済ませない
個人データの処理には必ず適法性の根拠（法的根拠）が必要です。同意が適するプロダクトもありますが、公開ウェブデータにおける既定の答えではありません。民間組織によっては、範囲を絞り、実効的なセーフガードを講じたスクレイピングについて、正当な利益が根拠になり得ます。ただし自動的に認められるものではありません。
説明に耐えうる「正当な利益」評価では、次の3点を問います。
- その利益は適法で、具体的で、実在し、現在のものか？
- その目的の達成に、この収集は本当に必要か。より侵害の少ない手段はないか？
- 対象者の利益・権利・合理的な期待が、自社の利益を上回っていないか？
CNIL（フランスのデータ保護当局）は、スクレイピングで収集した公開データは一般に「正当な利益」の枠組みで検討されるとしつつ、個人への影響を軽減する追加措置を求めています。また、一律の許可ではなく、ケースバイケースの分析を重視しています。CNIL のガイダンス
分析内容、その前提、そして選択した緩和策を文書化してください。「そのプロフィールは公開だった」というのは、バランステストの文脈情報であって、テストそのものではありません。
4. データ最小化を「技術要件」にする
もっともコンプライアンス上安全なレコードは、そもそもスクレイパーが取得しなかったレコードであることが多いのです。
収集ジョブには、次のガードレールを組み込みましょう。
- 項目をホワイトリスト化する。 必要な項目を定義し、「簡単に取れるから」という理由で見えている項目を全部取らないこと。
- 要配慮カテゴリをブロックする。 健康、政治、宗教、労働組合、性生活、生体情報などの特別カテゴリのシグナルは、弁護士が具体的な適法ルートを設計していない限り除外します。何気ないテキストが、思わぬ形でこれらのカテゴリを露呈させることがあります。
- ハイリスクなソースを除外する。 サポートグループ、健康関連フォーラム、子ども向けスペースなど、再利用が意外性や害を伴いかねない場所は、デフォルトの除外リストで管理します。
- こぼれたデータは即座に削除する。 関係のない個人データを取得してしまった場合は、「念のため」と黙って保持せず、隔離して削除します。
- 来歴（プロベナンス）を記録する。 ソース URL、収集日時、関連する収集設定をデータセットとともに保存します。これが正確性の担保、削除対応、権利行使への対応を支えます。
CNIL は、対象カテゴリを事前に決めること、不要または要配慮データをフィルタすること、無関係なデータを削除すること、そして収集に対する技術的・法的な拒否の意思を尊重することを明確に推奨しています。CNIL のセーフガード
5. 透明性をプロダクトの一部として作り込む
ウェブサイトから収集したデータは、通常「間接取得」にあたります。つまり、第14条の透明性義務が関係し得るということです。自社が何者か、目的、データのカテゴリと取得元、適法性の根拠、保持期間、提供先、越境移転、そしてデータ主体の権利を説明する必要があります。
欧州委員会の要約によれば、他のソースからデータを取得した場合、情報提供は原則として1か月以内、最初の連絡時、または最初の開示時のいずれか該当するタイミングまでに行う必要があります。通知が不可能な場合や、過度な労力を要する場合などの例外もありますが、これらは条件付きであり、当然のものと決め込まず、評価して文書化すべきです。欧州委員会が示す義務
大規模な収集の場合、分かりにくい法務ページよりも、明快な公開通知、データセット説明ページ、専用の問い合わせ窓口、そして異議申立て・開示請求・訂正・削除の手順が見つけやすいことのほうが、はるかに意味を持ちます。適切な形式は、処理の内容とリスクによって決まります。
6. 公開前に、削除と権利対応のワークフローを用意する
大規模にスクレイピングすると、後始末のコストが跳ね上がります。データには識別子を付与し、ソースとレコードの対応表を管理下に置き、生データ、データベース、エクスポート、インデックス、下流の処理者にまたがって、特定個人のデータを見つけ出し、削除または抑止できるようにしておきましょう。
最低限、次の点を決めておきます。
- 誰が権利行使のリクエストを受け付け、本人確認を行うのか
- 不要な追加情報を求めずに、どうやって該当レコードを特定するのか
- 削除や異議申立てを、どのように下流システムへ伝播させるのか
- 誤って再収集しないよう、どのように抑止（サプレッション）するのか
- ログやバックアップにレコードがどれだけ残るのか、例外処理はどうするのか
そのデータセットがモデル学習、エンリッチメントのグラフ、プロファイリング、ダイレクトマーケティングに流れる場合は、この計画をさらに厳格にしてください。データが遠くまで流れるほど、権利を実質的に尊重するのは難しくなります。
7. データセットを保護し、ハイリスク案件は早期に評価する
GDPR は、リスクに見合った措置を求めています。これには、不正アクセス、消失、破壊、違法な処理からの保護が含まれます。「プライバシー・バイ・デザインおよびバイ・デフォルト」とは、こうした統制を侵害が起きてからではなく、最初の段階で選ぶという意味です。欧州委員会が示す義務
有用なベースライン統制としては、ロールベースのアクセス制御、通信時および保管時の暗号化、シークレット管理、監査ログ、ベンダー審査、データエクスポートの制御、そして訓練済みのインシデント対応プロセスが挙げられます。仮名化はリスクを下げますが、匿名化と同じではなく、それだけで GDPR の義務がなくなるわけではありません。
高いリスクを生む可能性がある処理の前には、DPIA（データ保護影響評価）の実施を検討すべきです。特に、次の要素が組み合わさる場合は要注意です。
- 大規模な収集やモニタリング
- プロファイリング、または個人に影響を与える判断
- 特別カテゴリのデータ、または極めてセンシティブな個人データ
- 子どもやその他の脆弱な立場にある人々
- データセットを組み合わせて新たな推論を導き出すこと
- 継続的な識別、位置情報、データブローカー的な再利用
- AI 学習、または個人データを記憶・露出しかねないモデル
欧州委員会は、体系的かつ広範な自動評価、大規模な要配慮データの処理、大規模かつ体系的なモニタリングを、DPIA が必要となるケースとして挙げています。DPIA に関するガイダンス
ウェブスクレイピング担当チーム向けのローンチ・チェックリスト
本番ジョブを実行する前に、以下をすべて確認してください。
- その収集に個人データが含まれるかどうか、そして GDPR が適用される／されない理由を把握している。
- 目的を明確に文書化し、必要な項目のホワイトリストを用意している。
- 適法性の根拠を文書化し、該当する場合は正当な利益の評価も行っている。
- 要配慮・ハイリスクなソースやカテゴリを、デフォルトで除外している。
- 提供元の制限事項を評価済みで、アクセス制御を迂回していない。
- 透明性のある公開説明と、権利行使・異議申立てに対応できる実効的な窓口がある。
- 管理者／処理者の役割を把握し、適切なベンダー契約条件を結んでいる。
- 保持、削除、抑止、下流への伝播の手順が整っている。
- リスクに見合ったセキュリティ統制と、インシデント対応の責任者が決まっている。
- DPIA と越境移転の評価を完了している、または不要である理由を意識的に文書化している。
実務上の要点
ウェブスクレイパーにとっての GDPR コンプライアンスとは、robots ファイルの中に魔法の一行を見つけることでも、プロダクトに免責文を貼りつけることでもありません。明示した目的に見合う範囲で収集し、人々に実質的な可視性とコントロールを与え、あとから自分たちの判断を証明できるようにすることです。
範囲は狭く始める。取得は少なく。ソースとタイムスタンプは残す。削除をデータモデルに組み込む。要配慮データ、大規模処理、プロファイリング、AI 学習用途は、データが下流に流れる前にエスカレーションする。こうした習慣が、スクレイパーをより信頼できるものにし、最初のプライバシー問い合わせが来たときの運用をずっと楽にしてくれます。
本記事は一般的な情報提供であり、法的助言ではありません。自社の事実関係、管轄、データカテゴリ、想定用途については、有資格の専門家に助言を求めてください。
もっと詳しく
