EDPBウェブスクレイピングガイドライン: ターゲット型スクレイパーが有利になる理由

EDPBがスクレイパー向けの仕様書を策定

欧州のデータ保護当局は、これまでAIモデルについて多くの見解を示してきました。しかし今年の夏まで、エンジニアが最初のページを取得する前にスクレイパーへ何を実装すべきかを具体的に示したものはありませんでした。

Guidelines 03/2026 on web scraping in the context of generative AIによってその状況が変わりました。欧州データ保護会議（EDPB）は2026年7月7日にこのドラフトを採択し、パブリックコンサルテーションは2026年10月30日に終了します。名目上の対象範囲は狭く、生成AIのトレーニングやファインチューニングを目的として個人データをスクレイピングする民間企業に限定されています。しかし実際には、最初のrequestを発行する前に定義する基準から最後のレコードのタイムスタンプに至るまで、法的に抗弁可能なスクレイピングジョブをどう構築すべきかについて、規制当局が発表した中で最も詳細な記述となっています。

全23ページを精読した私たちの見解は次のとおりです。ドラフトは使用するツールを問題にしていません。何を、どこから、いつ収集したかを明確に説明できるかを重視しています。単一のクエリでそれに回答できるスクレイパーは問題ありません。一方で、オープンエンドなクロールは、ほぼすべての段落の要件に抵触することになります。

（免責事項: 本記事は法的助言ではありません。第一にこれはドラフトを対象としており、私たちはコードの観点からその意味を読み解くエンジニアです。）

ターゲティング型か非ターゲティング型かが決定的な境界線

第8項では、「使用される技術的ツールではなく」、収集の具体性と制限の度合いに基づいてスクレイピングを2つの類型に分類しています。ターゲティング型スクレイピングは、ドメイン、言語、トピックなどの収集基準に従います。非ターゲティング型スクレイピングは、検出したすべてのリンクをたどるクローラーです。EDPBが懸念しているのは明確で、キューが増加するにつれて、管理者側が「どのような個人データが収集および処理されているかをほとんど把握できなくなる」点です。

この区分は、文書のその後の記述全体に貫かれています。データ最小化の原則では、収集開始前に「正確な収集基準を定義」し、「データマッピングおよびインベントリプロセス」を実行することが求められます（第37項）。正当な利益に基づく必要性のテストでは、「インターネットの広範な領域をスクレイピングするのではなく」基準を絞り込むことが、そもそも処理を必要と認める根拠になり得るとされています（第52項）。透明性の原則では、理想的にはドメイン名、URL、収集日を含む情報源の公開リストが求められます（第30項および第31項）。

十数件の小売ドメイン上の固定された製品ページリストを持つ価格トラッカーなら、設定ファイルからこれらすべての成果物を生成できます。しかし、幅優先探索のクロールでは不可能です。Privacy Worldによるドラフトの批評はその矛盾を的確に指摘しています。EDPBは非ターゲティング型クロールがインベントリ化できない個人データを保持する可能性があると認めた直後に、収集内容を正確に把握している管理者を前提とした義務を課しているのです。

実践的な意味: 個人に紐づくデータ (ユーザー名付きのレビュー、担当者の氏名や電話番号を含むリスティング、フォーラムのスレッドなど) をスクレイピングする場合、収集基準そのものがコンプライアンス上の証拠資料になります。担当者の頭の中ではなく、スクレイパーのコードと同じバージョン管理システム内で管理してください。

サイト側の拒絶の意思表示がリスクになる

ここが多くのパイプラインに最も影響を与える部分です。草案では、サイト側がスクレイピングに明確に反対していることを示す技術的手段として、robots.txt、ai.txt、「コンテンツ閲覧のためのロボット認証」、および「人間のみが実行可能なアクションを課す」検証 (37項) を挙げています。学習データに関する推奨事項としては、これらを設定しているサイトを除外することとされています。

同じシグナルが衡量テスト (balancing test) でも考慮されます。サイトがそれらの手段を講じていることをユーザーが知っており、それでもスクレイピングされた場合、ユーザーはそのようなデータ処理を予期しにくいと草案は述べています (64項)。事例5では具体的に示されています。robots.txt による除外設定、人間認証、AI学習禁止の明記があるプラットフォームでは、ユーザーは第三者がその目的でデータをスクレイピングすることを「合理的に予期できない」と判断されます。また、逆は成り立ちません。robots.txt が存在しないことは同意を意味しません (45項)。

フランスの CNIL は先行して同様の見解を示していました。2025年6月に初版が公開された 正当な利益とウェブスクレイピングに関する解説シート では、管理者が robots.txt や人間認証によって異議を申し立てているサイトを除外しない場合、その処理は「データ主体の合理的な予期の範囲内には収まらない」と明記されています。

緩和措置 (66c項) の中には、見落としやすい項目が2点あります。1つは、ログイン後にのみ表示される個人データの除外です。もう1つは、通常のブラウザとスクレイパーの User-Agent とで異なる出力を返すサイトを対象としており、「特にスクレイピングサービスが人間が閲覧できる以上のデータを受信する場合」を指しています。スクレイパーがページ表示以上の詳細データを返す内部 API を読み取っている場合、まさにこのケースに該当します。

機械可読なシグナル (robots.txt の拡張仕様、署名付きエージェント、コンテンツシグナル) については Search, Agent, Training: The Web's New Bot Rules で、拒絶する代わりに課金を選択するパブリッシャーについては Pay-Per-Crawl Is Splitting the Web in Two で解説しました。EDPB の草案は、規制当局がこれらのシグナルを「ユーザーの予期」を測る証拠として扱った初の事例です。

実践的な意味: 収集時におけるドメインごとの robots.txt (およびサイトに存在する場合は ai.txt) の状態を、データと併せて記録してください。1年後に「なぜこのソースが学習セットに含まれているのか」と問われた際、「取得した当日は許可されていた」と主張できるのは、そのログを記録している場合のみです。

スクレイパーが処理者となるケース

セクション3.2.1は短く、読み飛ばされがちです。しかし、クライアント向けにスクレイパーを構築している場合は特に見過ごせません。開発者の「文書化された指示に従って」その代理としてトレーニングデータセットを作成する場合、自身が処理者（プロセッサー）、開発者が管理者（コントローラー）となる可能性があります（第18項）。クライアントと共同で収集基準を設定する場合、共同管理者となる可能性があります（第20項、例1）。自身で独自にデータセットをスクレイピングし、第三者がそれを再利用する場合、双方がそれぞれの処理に対して責任を負います（第19項）。

Brian Hengesbaugh氏による草案に関するIAPPのコラムでは、ビジネス上の観点が指摘されています。契約書でベンダーを処理者と定めている場合、ガイドラインに記載されたコンプライアンス対応はクライアントが担うことになり、ベンダー自身の直接の義務は「想定よりも限定的で、安心できるものではない可能性がある」とされています。これは双方に影響します。クライアントはスクレイパーを作成したフリーランサーにコンプライアンスを丸投げできませんし、データソースの選定を独自に進めてしまったフリーランサーは、意図せず管理者になってしまうリスクがあります。

データチームが今すぐ変更すべきこと

大半の商用スクレイピングはこれによる影響を受けません。価格、在庫数、製品仕様、時刻表などは一般に個人データではないため、GDPRの対象外です。草案では、「混合」データセットにおいては個人データの部分に適用されることが明記されています（第13項）。したがって、出品者の氏名を含む出品情報や、ユーザー名を含むレビューなどは、その部分が対象となります。

個人に関するデータを収集するジョブについて、草案が求めている要件をパイプラインへ落とし込む方法は以下のとおりです。

このうち2つの項目は、表のセル以上の説明が必要です。

数週間後のクリーンアップジョブではなく、パース時にフィルタリングを実行してください。第38項では、収集時に適用する社会保障番号や電話番号などの形式に対する正規表現が挙げられています。保存していないデータについて説明責任を求められることはありません。また第60項では、これがAIにおいて重要である理由が端的に述べられています。モデルのトレーニング完了後、そこから個人データを「容易に削除することはできない」ためです。

すべてのレコードにソースURLと取得時刻を保持してください。第42項では正確性のためにタイムスタンプを求めていますが、この2つのフィールドは後から情報の出所を問われた際にもそのまま回答になります。AI法のもとでトレーニングデータの規則はすでに厳格化が進んでおり（4月にこれについて解説しました）、常に同じ確認が求められます。

クライアント向けに開発を行う場合、ソース、フィールド、除外対象などの指示を書面で残す必要があります。草案では、文書化された指示が存在することが、共同管理者ではなく処理者と見なされる条件とされています。後から役割について議論するよりも、1ページの仕様書を用意しておくほうが確実です。

10月30日以降の展開

最終的な条文は変更される見込みであり、より大きな変化は欧州データ保護会議（EDPB）からではなくブリュッセルからもたらされる可能性があります。2026年10月21日、欧州連合理事会はGDPRを修正する法案パッケージであるDigital Omnibusに関する交渉姿勢で合意しました。IAPPによる委任事項に関する報告によると、加盟国はAI学習データ向けに「個人データ処理の適法な根拠の明確化と、適切なセーフガードを維持する必要性」を追加しました。次は欧州議会との交渉に進みます。どのような文言になるにせよ、加盟国はセーフガードの維持を求めており、これは本草案と同様の比較衡量の適用を示唆しています。

ターゲット型と非ターゲット型の区別は、法律というよりエンジニアリングに関わる草案唯一の部分であるため、両方のプロセスを経ても残ると考えられます。規制当局がクローラーのコードを読むことはありません。当局が要求できるのは収集基準、ソースリスト、タイムスタンプであり、それらを当日の午後に提出できるチームには、反論すべき余地がほとんど残りません。

したがって、プライバシー規制当局がスクレイパーに対して次に行う質問は「どう動作するか」ではなく、「何を収集するよう指示されたか」になるはずです。