ほとんどの企業は、ウェブデータ収集のための成文ルールを持っていない。あるエンジニアが価格調査プロジェクト用にスクレイパーを構築し、別のチームがそれをリード調査用にコピーし、契約社員が3つ目を追加する。その結果、どのサイトからデータを収集しているのか、どんな個人データを保存しているのか、サイト運営者からの苦情に誰が対応するのかを誰も答えられなくなる。作業自体は通常問題ない。問題は、それが問題ないことを誰も示せないという点にある。
短い社内ポリシーがあれば、これは解決する。エンジニアには明確なデフォルトのルールを与え、法務やセキュリティチームには毎回ではなく一度だけ確認すればよい対象を与え、会社には顧客や監査人、サイト運営者からデータ収集方法を尋ねられたときの答えを与えることができる。本ガイドでは、そうしたポリシーが何をカバーすべきかを説明し、応用可能なテンプレートを提示する。
要点
- 収集ポリシーは、エンジニアが実際に読む程度の短さであるべきだ。対象範囲、承認ステップ、情報源に関するルール、個人データに関するルール、誰かが異議を唱えた場合の対応を含める。
- 安全な経路をデフォルトにする。公開されていてログイン不要のページ、正直な識別、控えめなペース、robots.txtの尊重については特別な承認を不要にし、それ以外はすべて承認対象とする。
- 異議は異議として扱う。例えばフランスのデータ保護当局は、robots.txtやCAPTCHAを通じて異議を示すサイトを収集対象から除外することを収集者に求めている。
- 個人データはすべてを変える。収集してよい対象を定義し、収集時点で最小化し、保持期間を設定し、削除を可能にする。
- 責任者と削除対応プロセスを定めておく。最初の苦情が来たときに誰が対応するかを決めるのでは遅い。
- このテンプレートは出発点であり、法的助言ではない。自社の管轄区域や契約に照らして弁護士に確認してもらうこと。
成文ポリシーが重要な理由
実務上の理由は3つある。
一貫性。 成文ルールがなければ、各プロジェクトはrobots.txt、ペース配分、個人データ、保持期間について独自に判断する。慎重なプロジェクトもあれば、そうでないものもあり、会社は最も不注意なプロジェクトのリスクを背負うことになる。
速度。 明確なデフォルトを持つポリシーがあれば、ほとんどのプロジェクトは会議なしで開始できる。法務とセキュリティはポリシーを一度確認すればよく、あとは例外だけを確認すればよい。
証拠。 データ保護規制当局は、管理者がどのような保護措置を講じているかを示せることを求めている。例えばフランスのデータ保護当局CNILは、ウェブスクレイピングによる個人データ収集に関するガイダンスを公表しており、収集基準を事前に定義すること、robots.txtやCAPTCHAを含め明確に異議を示すサイトを除外すること、不要なデータをフィルタリングすること、機微なデータを識別次第削除することなどの措置を挙げている。成文ポリシーは、こうした措置が存在することを示す手段である。
ポリシーがカバーすべき内容
| セクション | それが答える問い |
|---|---|
| 目的と範囲 | どの活動とチームが対象か? |
| 役割 | 誰がポリシーを所有し、誰がプロジェクトを承認し、誰が苦情に対応するか? |
| デフォルトルール | どのプロジェクトも承認なしで何ができるか? |
| 承認 | 何が誰の承認を必要とし、どんな情報とともに申請するか? |
| 情報源 | どのサイトやページが対象範囲内で、それらのシグナルをどう扱うか? |
| 個人データ | 人に関してどんなデータを収集してよく、どう最小化・保護するか? |
| 技術的な振る舞い | 収集者はどう自己識別し、リクエストのペースをどう配分し、認証情報をどう扱うか? |
| ベンダー | プロキシやデータプロバイダーに何を求めるか? |
| 保存と保持 | 収集データはどこに置かれ、誰がアクセスでき、どれだけ保持するか? |
| 異議と削除対応 | サイト運営者、個人、規制当局が異議を唱えた場合どうするか? |
| 記録とレビュー | 何を記録し、いつポリシーを見直すか? |
テンプレート
文言は自社向けに調整し、該当しない項目は削除し、簡潔に保つこと。角括弧内のテキストは記入用である。
1. 目的と範囲
本ポリシーは、[Company]、その従業員および契約社員による、ウェブサイトおよびオンラインサービスからの自動データ収集を対象とする。これにはスクレイパー、クローラー、ブラウザ自動化、および自社に代わって収集する第三者から購入したデータが含まれる。自社ユーザーが提供するデータや、各サービスの独自規約のもとで使用される公式APIは、セクション6が適用される場合を除き対象外とする。
2. 役割
- ポリシーオーナー: [役職、例: データ部門責任者] が本ポリシーおよび収集プロジェクト台帳を維持する。
- 承認者: [法務担当者] と [セキュリティ担当者] が、セクション4に基づき承認を必要とするプロジェクトを承認する。
- プロジェクトオーナー: すべての収集プロジェクトは、本ポリシーの遵守に責任を持つ担当者を一名指名する。
- 削除対応窓口: [役職と共有メールボックス] がセクション10に基づく異議を受け取り、対応する。
3. すべてのプロジェクトに適用されるデフォルトルール
以下の条件を満たすプロジェクトは、追加の承認なしに進めることができる。
- ログインなしで訪問者であれば誰でも閲覧できる公開ページのみを収集する。
- 収集者に適用されるrobots.txtやその他の機械可読なオプトアウトを尊重する。
- 収集者が正直に自らを識別し、自動トラフィックを特定の人物になりすまさせない。
- 対象に目立つ負荷をかけないようリクエストのペースを配分する。
- セクション6で認められている以上の個人データを収集しない。
- 開始前にプロジェクト台帳に記録される。
4. 承認が必要なプロジェクト
以下に該当するプロジェクトは、開始前に承認者からの書面による承認が必要である。
- 業務目的で公開されたビジネス連絡先情報を超える個人データを収集する。
- 健康、宗教、政治的意見など、いかなる特別な種類のデータも収集する。
- ログイン、ペイウォール、その他のアクセス制御の背後にあるページから収集する。
- サイトがrobots.txt、CAPTCHA、ブロック、契約条項、直接の要求などを通じて異議を示した後も継続する。
- 機械学習モデルの訓練、ファインチューニング、評価のために収集する。
- 収集したデータを[Company]の外部に販売、ライセンス供与、または共有する。
申請には、目的、情報源、データ項目、個人データがある場合はその法的根拠、想定される量、保持期間、プロジェクトオーナーを記載する。
5. 情報源とそのシグナル
- 公式のAPI、データフィード、ライセンスが存在し、ニーズを満たす場合はそれを優先する。
- 収集開始前に、各情報源の関連規約を読み、記録する。
- robots.txt、レート制限、CAPTCHA、ブロック、公開された留保事項は、サイトの意向を示すシグナルとして扱い、回避すべき障害として扱わない。
- アクセス制御、技術的保護手段、認証を回避しない。
- 情報源が異議を唱えた場合は速やかに収集を停止し、その停止を台帳に記録する。
6. 個人データ
- 記載された目的に必要な個人データのみを収集し、可能な場合は収集時点でそれ以外の個人データをフィルタリングする。
- セクション4に基づき承認されない限り、特別な種類のデータは一切収集しない。誤って収集された場合は、識別され次第削除する。
- 分析に識別情報自体が不要な場合は、識別子を仮名化する。
- 承認がない限り、収集したデータを他の情報源と組み合わせて個人を特定しない。
- 本人の請求に応じてそのデータを検索し削除できるようにする。
7. 技術的な振る舞い
- プロキシ、API、対象アカウントの認証情報は、承認された秘密情報管理システムに保存し、コード内には決して記載しない。
- セクション8の基準を満たすプロキシおよびデータプロバイダーのみを使用する。
- 収集実行ごとに、時刻、情報源、収集場所、使用した設定を記録する。
- リクエスト量とエラー率を監視し、情報源がリクエストを拒否し始めたら自動的に収集を一時停止する。
8. ベンダー
プロキシおよびデータベンダーは、自社のネットワークやデータがどのように調達され、どのような同意のもとで得られているかを示せること、本人確認(KYC)プロセスを運用していること、利用規約(AUP)を施行していること、本ポリシーと整合する契約条件に署名することが求められる。ポリシーオーナーが承認済みベンダーの一覧を保持する。
9. 保存と保持
- 収集したデータは[承認されたシステム]にのみ保存し、アクセスは必要な人員に限定する。
- 収集した生ページは[期間]を超えて保持せず、抽出済みデータは[期間]を超えて保持しない。ただし承認によって異なる期間が定められた場合を除く。
- 保持期間の終了時にデータを削除し、その削除を記録する。
10. 異議と削除対応
- サイト運営者、個人、または規制当局からの異議は[1営業日以内]に削除対応窓口へ届けられる。
- 異議が審査されている間、法務から別の指示がない限り、該当する収集は一時停止する。
- 削除対応窓口は[期間]以内に回答し、異議の内容、決定内容、削除したデータを記録する。
- 同一プロジェクトに関する異議が繰り返される場合は、そのプロジェクトの承認を見直す。
11. 記録とレビュー
ポリシーオーナーは、プロジェクト台帳、承認記録、ベンダー一覧、削除対応ログを保持し、少なくとも[年に一度]、また法律や会社の活動に重大な変化があった際には本ポリシーを見直す。
定着させるために
共有ドライブに置かれたままのポリシーは何も変えない。実効性を持たせるためのいくつかの習慣がある。
- 台帳をプロジェクトの起点に置く。 エンジニアがすでに使っているツール内に、デフォルトルールをチェックボックス化した短いフォームを置けば、プロジェクトが存在する前の段階で捕捉できる。
- デフォルトをコードに組み込む。 robots.txtを尊重し、正直なUser-Agentを設定し、リクエストのペースを配分し、収集コンテキストを記録する共有収集ライブラリがあれば、ポリシーの遵守が余計な手間ではなく最も簡単な道になる。どのシグナルを読むべきかについてはrobots.txtとAIオプトアウトの尊重を参照のこと。
- データがどこで観測されたかを記録する。 実行ごとに時刻、場所、設定をログに残すことが、後になって収集データの正当性を示す根拠となる。これはvantage-point標準の必要性で論じられている通りである。
- ベンダーを確認する。 プロキシプロバイダーにIPの調達方法を尋ねること。理由についてはプロバイダーが倫理的にレジデンシャルIPを調達する方法と安価なプロキシの裏にあるマルウェア経済を参照のこと。
- 秘密情報をコードから排除する。 CI/CDでのスクレイパー運用では、プロキシ認証情報の安全な扱い方を示している。
- 構築前にシグナルを読む。 情報源を保護している仕組みを素早く確認することで(アンチボットスタックの調査方法を参照)、そのプロジェクトがデフォルトルールの対象か承認が必要かを早期に判断できる。
より広い法的背景についてはウェブスクレイピングは合法かとレジデンシャルプロキシとGDPRを、日々の実務についてはウェブスクレイピングのベストプラクティスを参照のこと。
結論
データ収集ポリシーは長くある必要はない。明確な範囲、ほとんどの作業を進められる安全なデフォルト、リスクの高いケースのための承認ステップ、個人データに関する確固たるルール、そして誰かが異議を唱えたときに対応する担当者の名前があればよい。
一度書き上げ、そのデフォルトをエンジニアが使うツールに組み込み、台帳を最新に保つこと。そうすれば、次に誰かが自社のウェブデータ収集方法を尋ねてきたとき、答えは慌てて用意するものではなく、一つの文書となる。テンプレートを自社の状況に合わせて調整し、採用前に弁護士に確認してもらうこと。