Meta Platforms, Inc.とBright Data Ltd.の紛争は、「公開Webデータのスクレイピングはどこから違法・契約違反になるのか」を設計目線で整理するうえで、示唆が多い事例です。本記事では、2024年1月23日の米連邦地裁（北カリフォルニア地区）によるサマリージャッジメント（契約面）を軸に、合法性を高めるスクレイピングの要件を「ログイン有無」「対象データの公開性」「同意と契約」「技術的制限の扱い」に分解して解説します。
結論
Meta vs Bright Dataの判断から得られる実務的な結論は次のとおりです。
- 「ログアウト状態で閲覧できる公開情報」の収集は、少なくとも本件の契約解釈では、規約条項の適用範囲外になり得る。
- 一方で、ログイン必須領域、非公開情報、認証情報の不正利用、アクセス制御の回避、過剰な負荷は、契約・不正アクセス・プライバシー等の別ルートでリスクが上がる。
- 合法スクレイピング設計は「公開範囲の固定」「同意/契約の境界管理」「収集の最小化」「ブロック回避を前提にしない」までを仕様として落とし込むのが肝です。
判決の要点
本件では、裁判所が契約（Facebook/InstagramのTerms）に基づく主張を精査し、「Facebook/InstagramのToSは“非ログイン”状態の公開データのスクレイプや販売を禁止しない」と解し、Meta側の契約違反主張を退ける形でBright Data側に有利な判断が示されました。
論点はログイン有無
裁判所は、Metaが主張する規約条項が「サービスの利用（use）」を前提としている点や、ログアウト状態で閲覧可能な公開情報の収集にまで当然に及ぶのかを慎重に検討しています。結論として、「ログアウトでの公開データ収集を契約違反と断定できない」、という整理が実務上の分水嶺になりました。
非公開収集の証拠不足
命令文では、Metaが「保護されたデータ（非公開データ）」が収集・販売されたことを具体的に示せていない旨が述べられています。言い換えると、訴訟で争点化したいなら「どのデータが」「どう非公開で」「どう取得されたか」を立証できる運用ログや技術的事実が重要になります。
（参考）Meta Platforms, Inc. v. Bright Data Ltd. 裁判所命令
合法設計の原則
さて、ここからが本題です。判決の射程を「何でも取ってよい」に拡大解釈せず、設計に落とすときの原則をチェックリスト化します。
公開範囲を固定する
- ログアウトで閲覧できるURLのみをクロール対象に限定する
- セッションCookie・アクセストークン・ログイン状態が混入しない設計にする
- HTML上に見えている情報に限定し、裏APIや管理用エンドポイントへ寄らない
契約同意を境界化
規約は「誰が」「どの状態で」同意したかが重要です。ログインして同意が成立している場合、規約条項による制約を受ける可能性が高まります。逆に、ログアウトでの公開閲覧を前提とするなら、仕様として「ログイン導線に乗らない」ことがリスク低減になります。
注意点として、契約論点だけで安全が確定するわけではありません。サイトのアクセス制御の回避、個人データの取り扱い、著作権・不正競争、州法・国際法など別の法領域でリスクが立ち上がります。
収集データを最小化
公開情報でも、個人識別性が高い属性（氏名、メール、住所、顔画像、位置情報など）を大量に集めると、プライバシー・規制・説明責任の負担が急増します。設計では「目的に必要なカラムだけ」「保持期間を短く」「再識別を避ける」を要件化しましょう。
負荷と礼儀を仕様化
法的に争われる以前に、運用として迷惑行為に見えればブロック・通知・開示請求の対象になります。レート制限、バックオフ、キャッシュ、差分取得をデフォルトにします。
回避前提を捨てる
プロキシや自動化の技術は、運用要件（冗長化、IP分散、安定取得）として有用な場面があります。ただし「ブロックを突破する」ことを要件にすると、アクセス制御回避・不正アクセス類型に接近しやすいのが実情です。設計段階で、対象サイトの許容レンジ（API、提供データ、利用許諾）を優先し、拒否されたら停止できるフローにします。
論点別の設計
ログアウト収集
本件が示したのは「ログアウトで公開されている」ことの重要性です。設計では次を満たすと整理しやすくなります。
- ログイン画面に遷移したら即停止（認証が必要＝公開ではない）
- Cookieレスでも取得できることを自動テストで検証
- 言語/地域差で公開範囲が変わる場合、取得条件を固定
ログイン領域
ログイン必須領域の自動取得は、契約違反の論点が強まりやすく、また認証情報の取り扱い（利用者同意、委任、監査ログ）も必須になります。業務要件として必要なら、公式APIやデータ提供契約を優先してください。
個人データ
公開プロフィールであっても、個人データの処理は別次元でリスクが出ます。EU/米州法/各国法、プラットフォームポリシー、社内のプライバシー基準（DPIA相当の評価、削除請求対応）まで含めて運用設計が必要です。
実務チェック表
設計レビューで使えるよう、要点を比較表にまとめます。
| 観点 | 低リスク設計 | 高リスク設計 |
|---|---|---|
| アクセス状態 | ログアウトで閲覧可能なURLのみ | ログイン必須、セッション依存 |
| データ範囲 | 目的最小、集計・匿名化中心 | 個人識別子を大量取得・長期保持 |
| 手段 | 通常ブラウザ相当、負荷制御あり | 検知回避・制限突破を要件化 |
| 同意/契約 | 同意が発生しない動線を維持 | 同意後に規約違反行為を自動化 |
| 停止設計 | 拒否・ブロック・警告で即停止 | 停止せず迂回を継続 |
誤解しやすい点
公開=自由ではない
公開情報でも、無制限に再配布・商用利用できるとは限りません。契約、著作権、プライバシー、表示権限（robots.txtを含む運用慣行）、不正競争など、別の根拠で制限される可能性があります。
判決の射程
本件は米国の特定事件であり、争点も「Metaの規約違反（契約）」が中心です。国・州・裁判所・請求原因が変われば評価も変わります。導入時は、対象国の法務レビューとログ設計（いつ何を取得したかを説明できる状態）をセットにしてください。
合法収集を設計しませんか？
公開データでも、契約・個人データ・負荷の設計を誤るとリスクが跳ね上がります。要件整理から取得方式、運用ルールまで一緒に整備します。
まとめ
Meta対Bright Dataの判断は、少なくとも契約面では「ログアウトで閲覧できる公開情報の収集」を強く意識させる内容でした。実務では、(1)公開範囲の固定、(2)同意/契約の境界管理、(3)収集最小化と保持制限、(4)負荷制御と停止設計、(5)回避前提を捨てる、の5点を要件として落とし込むのが安全です。
参考文献
