ウェブサイトのGDPR：作る側のチームのための実務ガイド
GDPRは2018年5月25日から適用されています。8年たった今、ほとんどの企業は自社が遵守していると信じており、私たちが見るウェブサイトのほとんどは遵守していません。
これは通常、無関心のせいではありません。GDPRの作業が一度だけ、文書として行われ、その後システムがその横をすり抜けて進んだからです。新しい分析ツール、新しいCRM、新しいチャットボット、新しいマーケティングオートメーション。それぞれが、記録が決して捉えなかった処理を追加しました。
このガイドは、作る側のチームとして本当にあなたが所有している側面に焦点を当てます。データモデル、連携、権利行使への対応、そしてコードの中で実際に何が起きているか。法的助言ではなく、弁護士が担うべき解釈の問題からは意図的に距離を置きます。
まず短い基礎
規則(EU)2016/679は個人データの処理を扱います。個人データとは、識別された、または識別可能な自然人に関するあらゆる情報であり、「識別可能」は多くのチームが想定するより広い概念です。IPアドレス、Cookie識別子、端末識別子、ハッシュ化されたメールアドレス、ユーザーアカウントIDはすべて含まれます。
EUに拠点を持つならこの規則が適用されます。持っていなくても、EU域内の人に商品やサービスを提供したり、その行動を監視したりするなら適用されます。
管理者は処理の目的と手段を決定します。処理者は管理者に代わって処理します。ウェブサイト所有者の多くは管理者で、SaaSベンダーの多くは処理者ですが、ベンダーが独立した管理者となる場合もあり、その場合必要な契約が変わります。
六つの法的根拠と、誤用されるもの
すべての処理活動には第6条の根拠がひとつ必要です。
- 同意。 自由に与えられ、特定され、情報を与えられ、曖昧さのないもの。与えたのと同じくらい簡単に撤回できること。
- 契約。 データ主体との契約の履行に必要であること。
- 法的義務。 法律が求めていること。
- 重大な利益。 ウェブサイトの文脈では稀。
- 公共の利益。 主に公的部門。
- 正当な利益。 あなたまたは第三者の利益で、データ主体の権利に優越されないもの。
実務では、正当な利益が誤用されるものです。これは本物の根拠ですが、それを成立させるバランステストなしに援用されることが多い。使うつもりなら、利益を特定し、必要性を評価し、データ主体の権利を比較衡量した文書化された評価が必要です。1ページで足ります。何もないのは足りません。
推測してはいけない点がひとつ。ユーザーの端末上のデータへのアクセスや保存は、GDPRだけでなくeプライバシー指令の範囲に入ります。だからこそ、データ自体にどの法的根拠を援用しようと、不可欠でないCookieには同意が必要なのです。
ウェブサイトが実際に失敗する場所
8年間の修正の後、同じリストが繰り返し現れます。
同意の前にスクリプトが読み込まれる
古典です。同意バナーは描画されているのに、Google Analytics、Metaピクセル、チャットウィジェットはすでに <head> から読み込まれている。ユーザーは何もクリックしていないのに、三つの第三者がすでにそのIPアドレスを受け取っています。
これはプラットフォームの問題ではなくコードの問題です。同意プラットフォームは自分が知っているスクリプトをブロックできますが、あなたが自分で追加したscriptタグは、条件付けしない限りいずれにせよ読み込まれます。本当の修正は条件付き読み込みです。同意の状態が分かるまでスクリプトを注入しない。
監督機関がやるようにテストしてください。クリーンなプロファイルでブラウザを開き、ネットワークタブを開き、ページを読み込み、バナーに触れず、何が外に出ていくかを見る。それが監査です。
同意バナーが無効
要件は固まっており、多くのバナーは少なくともひとつに違反しています。
- 拒否は受諾と同じくらい簡単でなければならない。同じ階層のボタンとして、メニューの中に隠さない。
- あらかじめチェックされたボックスは同意ではない。
- 「閲覧を続けることで同意したものとみなします」は同意ではない。
- 同意は目的ごとに分離可能でなければならない。ひとつの包括スイッチでは足りない。
- 撤回は付与と同じくらい簡単でなければならず、つまり設定を再度開く常設リンクが必要。
- 同意の証拠を保存しなければならない。何に同意したか、いつ、どのバージョンのバナーで。
最後の項目が最も忘れられます。同意ログがなければ、「ユーザーは同意した」という主張は証明できません。
ルールセットは変化しつつあります。デジタル・オムニバスで提案されている第88a条と第88b条は、これらのルールをGDPRに移し、拒否後6か月の沈黙期間を加え、機械可読なシグナルに法的拘束力を与えます。まだ協議中で、現状はデジタル・オムニバス後のCookie同意で扱っています。
データ主体からの請求に応えられない
ユーザーが自分のデータの写しを求めてきます。すべてが必要で、「すべて」とはあらゆるシステムを意味します。本番データベース、分析、CRM、ヘルプデスク、メールプラットフォーム、ファイルストレージ、ログ、バックアップ、データウェアハウス。
多くの組織は本番データベースから答えられて、残りは推測します。それはコンプライアンスではなく運です。
期限は請求受領から1か月、複雑な場合は2か月延長できますが、最初の月内に延長を通知することが条件です。
実装しなければならない権利：
- アクセス権。 データの写しと処理に関する情報。
- 訂正権。 不正確なデータの修正。
- 消去権。 条件が満たされたときの削除。
- 処理の制限。 データは保持するが処理は止める。
- ポータビリティ。 構造化され、一般に使用され、機械可読な形式で、技術的に可能なら他の管理者への直接移転。
- 異議申立権。 特にダイレクトマーケティングに対しては、停止は無条件。
- もっぱら自動化された意思決定に服さない権利（法的効果または同様の重大な影響を生じる場合）。
このために作るポータビリティAPIは、データ法が製品データについて求めるのとほぼ同じ基盤です。一度作る価値があります。
保存期間が実質的に永久
GDPRは個人データを収集した目的に必要な期間だけ保持することを求めます。実務では、削除を作った人がいないので、多くのシステムはすべてを永久に保持します。
うまくいくやり方は、保存期間をポリシー文書ではなくデータモデルの属性にすることです。個人データを含むテーブルごとに保存ルールを与え、ルールごとにスケジュールジョブを与え、ジョブは何を削除したかをログに残す。それがなければ、「これはどれくらい保持していますか」という監督機関の問いへの答えは「誰かが思い出すまで」になり、それは答えになりません。
バックアップは継続的な論点です。復元されたデータが再び処理されないことを保証し、バックアップのローテーションとともに消えることを担保する文書化されたプロセスがあれば、バックアップは対象を絞った削除に対応しなくてよい、というのが広く受け入れられた立場です。この立場は、必要になる前に書き留めておくべきです。
国際移転が表面的に扱われている
データがEUの外に出るなら、移転メカニズムが必要です。十分性認定、標準契約条項、または拘束的企業準則。標準契約条項を使うなら、移転影響評価も必要です。
実務上の難しさは棚卸しです。多くのチームは大きなベンダーを把握し、小さなものを見落とします。フォントのホスティング、CDN、エラートラッキング、メール配信、サポートウィジェット、A/Bテストプラットフォーム。ベンダーがEUの外で処理するなら、そのすべてが移転です。
正しさを保つための作り方
コンプライアンスを保つサイトと、ずれていくサイトの違いは構造的です。
処理活動の記録を生きた成果物にする。 これは第30条の要件で、多くの場所では期限切れのスプレッドシートです。コードの近くに置き、新しい連携が加わるたびに見直し、ベンダー導入プロセスの一部にしてください。
個人データを集約する。 個人データが散らばるシステムが多いほど、権利行使への対応は高くつきます。参照を持つ正規の人物エンティティをひとつ、コピーではなく。
権利対応を一度、きちんと作る。 すべてのシステムに問い合わせ、結果をまとめ、何をしたか記録するひとつのワークフロー。手作業だと遅く、一貫性がなく、そして最も重要なときに期限を落とします。
同意状態を第一級の概念にする。 アプリケーションは同意状態をプログラムから問い合わせ、サーバー側でそれに基づいて判断できるべきです。ブラウザでスクリプトが読み込まれるかどうかだけではありません。
決定はその場で記録する。 なぜ正当な利益を選んだのか、なぜ保存期間が24か月なのか、なぜこのベンダーは管理者でなく処理者なのか。これらの記録こそ監督機関が求めるもので、1年後に再構成するのはほぼ不可能です。
データ侵害
個人データ侵害を知った時から72時間以内に監督機関へ通知（侵害がリスクをもたらすおそれが低い場合を除く）。高リスクの侵害では、不当な遅滞なくデータ主体にも通知します。
組織がNIS2やサイバーレジリエンス法の義務も負っているなら、異なる機関に対して異なる閾値の時計が並行して動きます。これらは一緒に設計してください。どちらもここで書きました。NIS2ガイドとサイバーレジリエンス法ガイドです。
制裁金と、実際に引き金を引くもの
上限は最も重い違反で2000万ユーロまたは全世界年間売上高の4%のいずれか高い方、その他の違反で1000万ユーロまたは2%です。
実務では、執行の引き金は予測可能です。回答を得られなかったデータ主体からの苦情、監督機関が業種別に走らせるCookieバナーの一斉調査、より広い監査につながる報告済みの侵害、そして競合他社に通報されるアドテク関連のサイト。
パターンは、小さなことが扉を開け、監査がすべてを覆うというものです。
現実的な着手順
不確かな地点から始めるなら、この順序が最も早く成果を出します。
- 同意の前に何が読み込まれるかを確認する。 1時間で済み、最も多い発見です。
- システム別に個人データを棚卸しする。 完璧でなくてよいが正直に。多くの組織は誰も一覧に入れていなかったシステムを見つけます。
- 自分でデータ主体の請求を試す。 自分のデータを請求し、どれだけ時間がかかり、何が欠けるかを見る。
- ベンダー一覧を移転と契約の観点で見直す。 個人データに触れるベンダーはすべてデータ処理契約が必要です。
- データが最も速く増える場所に保存期間を設定する。 ログ、分析、サポートチケット。
これは数週間の作業で四半期ではなく、推測から把握へと移してくれます。
私たちが入るところ
私たちは欧州で事業を行う企業向けにソフトウェアを構築・保守しており、これは日常的に行っている作業です。サーバー側でも成立する同意アーキテクチャ、すべてのシステムを網羅するデータ主体対応のワークフロー、保存期間の自動化、そして導入プロセスに接続されているから正しいままでいるデータマップ。
私たちは法律事務所ではなく、法的助言も行いません。あなたの弁護士が決めた立場を、動くシステムに変えるのが私たちの仕事です。
サイトやプロダクトにこの作業が必要なら、office@c9group.dev までご連絡ください。より広い規制の全体像は2026年EUデジタル規制ガイドに、欧州での取り組みの詳細はEU市場参入のページにあります。