EN / JA
Legal & GDPR

GDPRとスパムフィルター：セキュリティ対策にCookie同意は必要か？

· 1 min read

2022年1月、ドイツの地方裁判所が、同意なしにGoogleのサーバーからGoogle Fontsを読み込んだとして、ある中小企業に100ユーロの罰金を科しました。ユーザーを追跡したわけでもなく、データを販売したわけでもありません。フォントリクエストによって、米国にある第三者サーバーにIPアドレスが送信された――ただそれだけの理由です。

フォントファイルひとつでGDPR違反が成立するなら、あなたのスパムフィルターはどうでしょうか？

WordPress向けのスパム対策ソリューションの大半――reCAPTCHA、Akismet、hCaptcha――は、ページが読み込まれるたびにユーザーデータを外部サーバーに送信しています。IPアドレス、ブラウザのフィンガープリント、行動シグナル、Cookie。訪問者がフォームに一文字も入力する前に、これらすべてが送信されます。そして、これらすべてが第三者企業によって処理されます。多くの場合、CJEUがすでに十分なデータ保護が確保されていないと判断した法域に所在する企業です。

これは理論上のリスクではありません。 オーストリア、フランス、イタリアのデータ保護当局は、まさにこの種の越境データ移転について、Google Analyticsおよび関連サービスに対する判決を下しています。有効な移転メカニズムなしに米国のデータ処理者へ個人データを送信するサービスに対して、同じ法的論理が適用されます。

欧州の訪問者にサービスを提供するウェブサイトを運営しているなら、GDPRスパムフィルターの構成は技術的な問題ではなく、コンプライアンスの問題なのです。

問題点：トラッカーを兼ねるスパムフィルター

ほとんどのサイト管理者が見過ごしている不都合な現実があります。コンタクトフォームを保護しているスパム対策ツールは、おそらくマーケティングスタック以上のデータを収集しています。

reCAPTCHAが実際に行っていること

GoogleのreCAPTCHAは、ウェブ上で最も広く導入されているスパムフィルターです。同時に、実質的には監視ツールでもあります。ページにreCAPTCHAを埋め込むと、ユーザーが何も操作する前に以下の処理が実行されます：

  • ユーザーのブラウザにCookie（_GRECAPTCHA）が設定される。
  • google.comからJavaScriptペイロードが読み込まれ、ユーザーのIPアドレスがGoogleのサーバーに送信される。
  • スクリプトがブラウザのフィンガープリントデータを収集する：画面解像度、インストール済みプラグイン、言語設定、タイムゾーン。
  • フォーム内だけでなく、ページ全体にわたってマウスの動き、スクロール動作、キー入力パターンを追跡する。
  • 以降のページ読み込みでCookieを読み取り、複数セッションにまたがるユーザーの行動を関連付ける。

Google自身のプライバシーポリシーによると、reCAPTCHAを通じて収集されたデータは「reCAPTCHAの提供、維持、改善」と「一般的なセキュリティ目的」に使用されます。データが他の目的に使用されないという保証はなく、サイト側がダウンストリームの処理を制限するメカニズムも提供されていません。

GDPRにおける問題

GDPR（およびCookieの設置を具体的に規制するePrivacy指令）の下では、あらゆるデータ処理に法的根拠が必要です。6つの法的根拠が第6条(1)に定義されていますが、ウェブサイトでのCookie設置については、実務上、以下の2つの選択肢に帰結します：

  1. 同意（第6条(1)(a)） ― データが処理される前に、ユーザーが明示的に同意する。
  2. 正当な利益（第6条(1)(f)） ― データ管理者に正当な理由があり、それがユーザーの権利と比較衡量される。

また、ePrivacy指令第5条(3)には、ユーザーが明示的に要求したサービスを提供するために「厳密に必要な」Cookieに対する限定的な免除規定があります。この免除には同意は不要です。

スパムフィルターにとって重要な問いは、それがどのカテゴリに該当するかです。

技術的詳解：「厳密に必要」とそれ以外

ここが、インターネット上の多くのガイダンスが誤っている部分です。「セキュリティCookieは厳密に必要であり、同意は不要」と主張するブログ記事は山ほどあります。しかし、その主張は過度に単純化されており、罰金を招きかねません。

「厳密に必要」の本当の意味

第29条作業部会（現在のEDPB）は、意見書04/2012において「厳密に必要」の免除について具体的なガイダンスを提供しています。Cookieまたはデータ処理操作が厳密に必要であるとされるのは、以下の条件をすべて満たす場合のみです：

  • ユーザーが明示的に要求した機能に不可欠であること。
  • それがなければサービスを提供できないこと。
  • その特定の目的のために必要最小限であること。

フォーム送信時のCSRFトークン？厳密に必要です。このトークンなしにはフォームのセキュリティを確保できません。同意は不要です。

ログイン状態を維持するセッションCookie？厳密に必要です。ユーザーがログインを要求し、Cookieがそれを実現する仕組みです。

しかし、すべてのページで読み込まれ、永続的なCookieを設定し、外部サーバーに行動データを送信し、その場のインタラクションをはるかに超えた分析を行う第三者スクリプトは？ 厳密に必要ではありません。 ガイダンスのいかなる合理的な解釈においても、そうは言えません。

3つの判断基準

お使いのGDPRスパムフィルターが厳密に必要な免除に該当するかどうかを評価するには、以下の3つの問いを確認してください：

1. 処理は特定のインタラクションに限定されているか？

フォーム送信時にその場で検証を行い、その後すべてのデータを破棄するスパムフィルターは、厳密に必要であるという強い根拠を持ちます。一方、ユーザーがフォームを操作するかどうかにかかわらず、訪問するすべてのページでトラッキングスクリプトを読み込むフィルターは、該当しません。

2. データはデータ管理者のインフラ内に留まるか？

処理が完全に自社サーバー上で行われる場合、あなたがデータ管理者であり、処理を管理しています。データが第三者サーバー――特にEEA域外のサーバー――に送信される場合、独自の法的根拠、独自のデータ処理契約（DPA）、そしてSchrems IIに基づく移転影響評価が必要なデータ移転が発生します。

3. より少ないデータで同じ結果を達成できないか？

これはデータ最小化の原則（第5条(1)(c)）に基づくものです。Cookieも行動追跡も第三者へのデータ移転もなしに同等の保護を実現できるスパムフィルターがあるなら、より多くのデータを収集するバージョンは定義上「必要」ではありません。より侵襲性の低い代替手段が存在します。GDPRはその使用を求めています。

実用的な比較

基準 reCAPTCHA v3 サーバーサイドHoneypot
Cookieを設定する はい（_GRECAPTCHAおよびGoogle Cookie） いいえ
第三者スクリプトを読み込む はい（google.com） いいえ
第三者にデータを移転する はい（Google、米国拠点） いいえ
ページをまたいで行動を追跡する はい いいえ
フォームのインタラクション以外でデータを処理する はい いいえ
ePrivacy指令に基づく同意が必要 はい いいえ
第三者とのDPAが必要 はい いいえ
移転影響評価（Schrems II）が必要 はい いいえ

コンプライアンスの負担は比較にすらなりません。

法的状況：実際に執行されている事例

これは推測ではありません。欧州各国のデータ保護当局は、これらの原則を積極的に執行しています。

オーストリア：Google Analytics判決（2022年1月）

オーストリアDSB（Datenschutzbehorde）は、Google AnalyticsがIPアドレスやCookie識別子を含む個人データを米国のGoogleサーバーに移転したとして、GDPR違反と判断しました。この判決は、EU-米国プライバシーシールドを無効化したSchrems II判決に基づくものです。

この論理はreCAPTCHAに直接適用されます。 どちらのサービスもGoogleが運営しています。どちらもGoogleの米国インフラに個人データを移転します。どちらもサイト運営者が完全に管理・監査できない方法でGoogleのインフラを通じてデータを処理しています。

フランス：CNILのGoogle Analytics判決（2022年2月）

CNILは、Google Analyticsの移転がGDPRに違反するという複数の判決を下しました。CNILは特に、Googleの補完的措置（暗号化や契約条項を含む）は不十分であると指摘しました。Googleは米国企業として、FISA第702条の監視命令の対象であり、欧州の個人データが米国の情報機関にアクセスされないことを保証できないためです。

ドイツ：バイエルン州DPAの同意メカニズムに関する判断（2022年～2023年）

バイエルン州DPAは一貫して、厳密に必要でないCookieやトラッカーには事前の、情報に基づいた、明示的な同意が必要であり、ダークパターン（事前チェック済みのチェックボックス、混乱させるUI、トラッキングに対する「正当な利益」の主張）を通じて取得された「同意」は有効な同意ではないという立場を取っています。

EU-米国データプライバシーフレームワーク（2023年）

2023年7月に採択されたEU-米国データプライバシーフレームワークは、認証を受けた米国企業に対する新たな十分性認定を提供しました。Googleは認証を受けています。しかし、法学者やプライバシー擁護者――特に、元のSchrems訴訟の背後にある組織noyb――はこのフレームワークに異議を申し立てています。Schrems III訴訟が広く予想されています。

無効化される可能性のある移転メカニズムの上にコンプライアンス戦略を構築することはリスクです。 そもそもデータを移転しないソリューションの上に構築すれば、リスクは完全に排除されます。

欧州のサイト運営者が第三者スパムフィルターから離れつつある理由

このトレンドは数値で裏付けられています。2020年7月のSchrems II判決以降、プライバシーファーストで自社ホスティング型の、米国SaaSツールに代わる選択肢への需要が、あらゆるカテゴリ――アナリティクス、フォント、スパムフィルタリング、CDNサービス――で著しく増加しています。

その要因は明快です。

1. コンプライアンスコスト

GDPR準拠の方法でreCAPTCHAを使用するには、以下が必要です：

  • 同意を取得するまでreCAPTCHAスクリプトをブロックする同意管理プラットフォーム（CMP）。
  • Googleとのデータ処理契約（DPA）（利用可能ですが、サイト運営者に多大な義務を課します）。
  • 処理を記録する処理活動の記録（ROPA）のエントリ。
  • 米国政府によるアクセスリスクを評価する移転影響評価。
  • 処理内容、移転されるデータ、法的根拠を開示するプライバシーポリシーの更新。
  • ユーザーが同意を撤回しデータの削除を求めるメカニズム――データがGoogleのインフラに到達した後では、事実上不可能です。

個人データを処理せず、Cookieも設定しないサーバーサイドソリューションの場合？上記のいずれも不要です。コンプライアンスコストはゼロです。

2. 同意のパラドックス

スパム対策に同意を求めることには、根本的なUX上の問題があります。ユーザーが同意するまでreCAPTCHAをブロックすると、ユーザーはスパム対策なしにフォームを送信できてしまいます。スパム対策が機能するのは、Cookieバナーで「同意する」をクリックしたユーザーに対してだけです。

ボットはもちろん「同意する」をクリックしません。プログラムでフォームを送信し、同意レイヤーを完全にバイパスします。

結果として： reCAPTCHAで「保護」されるのは、トラッキングに同意したユーザーだけです。同意を拒否したユーザー（とボット）は保護されないまま送信できます。スパムフィルターは、まさに保護すべきでない対象だけを保護しているのです。

これは単なる技術的問題ではありません。アーキテクチャ上の矛盾です。同意に依存するセキュリティは、本質的に矛盾しています。

3. 責任リスク

GDPRの下では、データ管理者（サイト運営者であるあなた）が処理に対して責任を負います――データ処理者（Google、Akismetなど）ではありません。DPAがあなたのreCAPTCHA使用が第44条（国際移転）に違反すると判断した場合、罰金が科されるのはあなたです。Googleではありません。

GDPRの最大罰金額は、年間の世界全体の売上高の4%または2,000万ユーロのいずれか大きい方です。組織の規模が小さくても、コンプライアンスリスクは第三者スパムフィルターが提供する価値に対して不釣り合いです。

今後の方向性はアーキテクチャ的にシンプルですが、スパムフィルタリングの「あるべき姿」に対する前提の見直しが必要です。

上記のすべての問題を回避するGDPRスパムフィルターには、4つの条件を満たす必要があります：

Cookieが設定されなければ、ePrivacy指令の同意要件は適用されません。CMPの統合、Cookieバナー、同意ロジック――スパム対策レイヤーにおいて、これらすべてが不要になります。

2. 第三者へのデータ移転なし

すべての処理が自社サーバー上で行われる場合、越境データ移転は発生しません。Schrems II分析は不要です。DPAも不要です。覆される可能性のある十分性認定への依存もありません。

3. 行動追跡なし

スパム検出メカニズムがページをまたいでユーザーの行動を追跡せず――マウスの動きを記録せず、ブラウザのフィンガープリントを取得せず、セッションを関連付けなければ――データ最小化の原則はデフォルトで満たされます。

4. サーバーサイド検証

検出ロジックはサーバー上で実行される必要があります。そこではボットによる検査や操作ができません。クライアントサイドのみの防御は、セキュリティ上の脆弱性であると同時にプライバシー上の懸念でもあります（ユーザーのブラウザ上でシグナルを収集するためにJavaScriptの実行が必要なため）。

実際の仕組み

サーバーサイドのHoneypotフィールドは、このアーキテクチャの最も明確な例です。サーバーがランダムな名前と期待値を持つ隠しフォームフィールドを生成します。正規のユーザーのブラウザはフォームを通常通りレンダリングし、隠しフィールドは表示されず、ブラウザが期待値のまま送信します。プログラム的にフォームを解析するボットは、隠しフィールドに値を入力するか（正体が露呈）、予期しない値を送信します（正体が露呈）。

全体のインタラクションは以下の通りです：

  1. サーバーが隠しフィールドを含むフォームを生成。Cookie不要。外部スクリプト不要。
  2. ユーザーがフォームに入力して送信。ブラウザは自動的に隠しフィールドを期待値のまま送信。
  3. サーバーが隠しフィールドを検証。一致しなければ送信を拒否。

個人データは処理されません。 行動データの収集もありません。データがサーバーの外に出ることもありません。検出はフォーム送信の構造的な整合性にのみ基づいており、ユーザーが誰であるか、ページ上で何をしたかには基づいていません。

Contact Form 7を使用しているWordPressサイトでは、Samurai Honeypot for Formsがまさにこのパターンを実装しています。Cookieゼロ、第三者依存ゼロ、個人データ処理ゼロの多層サーバーサイドHoneypot検証です。GDPRコンプライアンスの議論自体が不要になるアーキテクチャです。なぜなら、コンプライアンスの対象となるもの自体が存在しないからです。

実践チェックリスト：現在のスパムフィルターのGDPR準拠を監査する

現在のスパム対策がGDPR上の責任を生じさせるかどうか不明な場合は、以下の質問を確認してください：

  • [ ] スパムフィルターはCookieを設定していますか？ ブラウザのDevToolsを開き、Cookieをクリアし、フォームのあるページを読み込んで、何が設定されたか確認してください。同意バナーを操作する前に何かが表示された場合、問題があります。
  • [ ] 外部スクリプトを読み込んでいますか？ DevToolsのNetworkタブを確認してください。google.com、gstatic.com、akismet.com、その他の第三者ドメインへのリクエストが見られる場合、データが移転されています。
  • [ ] スパムフィルターはCMPによって、同意していないユーザーに対してブロックされていますか？ されていなければ、法的根拠なくデータを処理しています。されている場合、それらのユーザーのフォームは保護されていません。
  • [ ] スパムフィルター提供者とのDPAはありますか？ データが第三者に移転される場合、必要です。サブプロセッサーの義務と国際移転条項を確認してください。
  • [ ] 処理はROPAに記録されていますか？ GDPR第30条で義務付けられています。
  • [ ] プライバシーポリシーに処理が開示されていますか？ スパムフィルターがGoogleにデータを送信しているにもかかわらず、プライバシーポリシーにその記載がない場合、第13条に違反しています。

いずれかの項目にチェックが入っていない場合、あなたのスパムフィルターはコンプライアンス上のギャップです。

まとめ

  • すべてのスパムフィルターがGDPRの「厳密に必要」に該当するわけではありません。 この免除は、不可欠で、最小限で、ユーザーが要求した特定のサービスに限定された処理にのみ適用されます。すべてのページで読み込まれ、米国のサーバーに行動データを送信する第三者のトラッキングスクリプトは該当しません。
  • 同意のパラドックスにより、同意依存型のスパムフィルターはアーキテクチャ的に破綻しています。 スパム対策がトラッキングに同意したユーザーに対してのみ機能するなら、それはまったく機能していません。なぜなら、ボットは同意メカニズムを完全にバイパスするからです。
  • サーバーサイドのCookieを使わないスパムフィルタリングは、GDPRコンプライアンスの負担を完全に排除します。 Cookieがなければ、ePrivacyの同意要件は不要です。第三者への移転がなければ、Schrems IIのリスクはありません。行動追跡がなければ、データ最小化はデフォルトで満たされます。
  • 欧州での執行は現実に、そして増加傾向にあります。 オーストリア、フランス、ドイツの当局は、米国のサービスへのデータ移転に対してすでに罰金を科しています。その法的論理は、reCAPTCHAおよび同様のサービスに全面的に適用されます。
  • 最も安全なコンプライアンス戦略は、問題を回避することです。 継続的な法的分析、十分性認定、同意管理を必要とする基盤の上にセキュリティを構築しないでください。同意の対象となるものがないアーキテクチャの上に構築してください。
← すべてのコラム