DSAR を冷静に処理：トラッカーにおける開示請求と消去対応

本記事はプライバシーに関する調査資料であり、法的助言ではありません。詳細はフッターの免責事項をご覧ください。

TL;DR

GDPR 第 15 条と第 17 条はアクセス解析にも適用されます — ハッシュ化された IP、Cookie ID、BLAKE3-HMAC 訪問者シグネチャといった仮名化識別子も、Breyer 判決、IAB Europe 判決、および 2025 年 5 月 14 日のブリュッセル控訴審判決の流れに沿って引き続き個人データとして扱われます。
3 つのエンドポイントを実装済み — POST /api/privacy/opt-out、GET /api/privacy/access、POST /api/privacy/erase — すべて CSRF 保護、レート制限、監査ログ付きです。
ロールアップテーブルは消去後も残ります。識別可能性を超える地点まで既に集計されており、uniqCombined64 HyperLogLog のスケッチはレコードではなくカウントであるため、個別の寄与を逆算することはできません。
8 つのプライバシー監査イベントが、第 28 条(3)(h) のアカウンタビリティ証拠を構造化された形で出力します。オプトアウト、アクセス、消去、同意の付与・撤回、法的ページの閲覧をカバーします。
EDPB の 2025 年協調的執行は消去権に焦点を当てており、2026 年は透明性義務にシフトします。どちらも本記事のアーキテクチャに沿った方向です。

なぜアクセス解析は DSAR で最も見落とされる領域なのか

GDPR の開示請求（DSAR）の運用フローは通常、明らかに個人データが存在するシステム — CRM、ヘルプデスクのチケット、注文履歴、メール配信リスト — を中心に組まれます。Web アクセス解析スタックはたいてい後回しにされ、話題に上ったとしてもサイト運営者の最初の直感はしばしば 「IP はハッシュ化しているので個人データは入っていない」 というものです。この直感は法的にも、アーキテクチャ的にもますます誤りになっています。

EDPB Guidelines 01/2025 on Pseudonymisation（草案）は、2025 年 1 月 16 日の第 101 回本会議で草案として採択され、2025 年 2 月 28 日まで公開コンサルテーションが行われ、2026 年 5 月時点でも策定中ですが、仮名化データ — ハッシュ化 IP、Cookie ID、BLAKE3/HMAC 訪問者シグネチャ、TC ストリングを含む — は、管理者または第三者が利用可能な手段で再識別が合理的に可能である限り、引き続き個人データであることを明確にしています。CJEU の IAB Europe 判決（C-604/22、2024 年 3 月 7 日）は、2025 年 5 月 14 日のブリュッセル控訴審判決（事件番号 2022/AR/292）で追認され、これを TC ストリングだけでなく、IP と組み合わされたあらゆる識別子に拡張しています。Breyer 判決（C-582/14、2016 年 10 月 19 日）は、サイト運営者と IP の問題をはるかに早い時期に決着させていました。

実務的には、これは次のことを意味します。IP、ハッシュ化された Cookie、BLAKE3-HMAC 訪問者シグネチャ、その他訪問者単位の識別子を処理する Web アクセス解析は、GDPR の意味における個人データを処理しています。第 15 条（開示請求権）と第 17 条（消去権）が適用されます。第 28 条(3)(e) は、処理者がいる場合には、管理者によるこれらの請求対応を支援することを求めています。第 33 条の侵害通知の時計も、これらの識別子に影響する侵害を含みます。

以下に続くのは、サイト運営者向けの実装ガイドです。アクセス解析の DSAR の解剖、Statnive Live が提供する 3 つのエンドポイント、必要な監査証跡、ロールアップが消去後も残る理由、開発者にやさしい DSAR ランブック、実際に動作するコード例を扱います。

アクセス解析の DSAR の解剖

Web アクセス解析スタックに対する DSAR は、CRM に対する DSAR とは異なります。メールアドレスも顧客名も、わかりやすい主キーもありません。データ主体は、要するに次のように連絡してきます。「ときどき御サイトを訪れます。私についてどのようなデータを保有していますか。削除してください。」

サイト運営者は実際に何を保有しているのでしょうか。

Statnive Live を consent-free モードで運用する Cookie レスのファーストパーティアクセス解析スタックでは、答えは次のとおりです。訪問者の IP、User-Agent、サイトスコープ、および 1 日単位でローテーションするソルトから導出した日単位の仮名シグネチャで、そのソルトは 1 日の終わりに破棄されます。アーキテクチャの詳細は 2026 年 EU 同意なしアクセス解析プレイブックで解説しています。その日のシグネチャは、次の 00:00 UTC でソルトがローテーションされるまで生のイベントテーブル上に存在します。ローテーション後は、そのシグネチャを生み出したソルトが消えているため、シグネチャは実質的に不可逆になります。ロールアップは、ソルトのローテーション前にそのシグネチャをカウントに集計するため、訪問者単位の識別子はロールアップテーブルにはまったく存在せず、日別・ページ別・流入元別のユニーク訪問者数のカウントのみが残ります。

consent-required または hybrid モードの Statnive Live で同意が付与されている場合は、さらにブラウザに Cookie ID（生の UUID）が発行されます。サーバーは SHA-256(master_secret || site_id || cookieID) を h: プレフィックス付きの永続化キーとして保存します。日をまたぐ訪問者の継続性は、日次ローテーションのソルトではなく、ハッシュ化された Cookie ID によって保たれます。

ここから 3 つのことが導かれます。

第 15 条の開示請求。 データ主体は、サイト運営者が照会できる材料を提供できます。典型的にはブラウザの Cookie ID（現在のセッションに存在する場合）か、訪問内容の説明（日付、ページ、おおよその時刻、既知のネットワークからの IP）です。サイト運営者は一致するイベントを返却できます。
第 17 条の消去。 サイト運営者は同じイベントを特定し、削除できます。サイト運営者が特定できるレコードは、サイト運営者が消去できるレコードです。
特定できないものは消去できず、保持することもできません。 00:00 UTC におけるソルト破棄は、日をまたぐ再識別能力を同時並行で自動的に消去します。訪問者のセッション 1 日目のシグネチャは、1 日目のソルトが破棄された時点で 2 日目のシグネチャと永続的に切り離されます。2 日目にサイト運営者へ届く第 17 条請求は、1 日目のレコードの削除を求めることはできませんが（特定できないため）、もはや再識別できないため問題ありません。

このアーキテクチャは、識別可能データの定常状態の保持量が小さくなるように設計されています。ソルトのローテーションが GDPR 第 5 条(1)(c) のデータ最小化作業の大部分を自動的に行っています。このように設計されたアクセス解析スタックに対する DSAR は、本質的に CRM に対する DSAR よりも件数が少なくなります。ソルトがローテーションすれば、ほとんどの訪問者には訪問者単位のレコードが残らないからです。

3 つのエンドポイント

Statnive Live はデフォルトで 3 つのプライバシーエンドポイントを提供します。3 つともすべて CSRF 保護、レート制限を備え、構造化された監査イベントを出力します。

POST /api/privacy/opt-out

第 21 条の異議申し立て権エンドポイントです。訪問者は、サイト運営者のプライバシーポリシーに置かれたボタンから呼び出します。サーバーは、ユーザーの選択を表す strictly-necessary Cookie としてオプトアウトを登録します（ePrivacy § 25(2)(ii) / TDDDG / 同等の各国国内法での実装で許容されています。ユーザーが明示的に要求したサービス設定を実装するためです）。同じブラウザからの後続の取り込みリクエストは、訪問者シグネチャが計算される前に取り込み層でドロップされます。

代替として、訪問者のハッシュ化シグネチャをキーとし、適切な TTL を持つサプレッションリストでオプトアウトをサーバー側に永続化することもできます。この選択はサイト運営者が設定可能です。

エンドポイントは privacy.opt_out_received 監査イベントを発行し、タイムスタンプ、サイト ID、および監査ログとの相互参照のための訪問者シグネチャのハッシュを含めます。

GET /api/privacy/access

第 15 条の開示請求権エンドポイントです。訪問者は次のいずれかを提供します。

現在ブラウザに保存されている Cookie ID（存在する場合）、または
署名済みの事前共有識別子（自社の DSAR ポータルと連携するサイト運営者向け）、または
サイト運営者が特定できる程度に絞り込まれた訪問内容の説明（日付、ページ、おおよその時刻、流入元ネットワーク）。

エンドポイントは記録上のイベントを返します。レスポンスは、照会に一致する生のイベントと、訪問者に関連するロールアップ由来のメタデータ（同じバケット内の他の訪問者を開示せず、その訪問が寄与したロールアップバケットの情報）を含む JSON オブジェクトです。監査イベント: privacy.dsar_access_requested。

POST /api/privacy/erase

第 17 条の消去権エンドポイントです。照会方法は第 15 条と同じです。エンドポイントは ClickHouse 上で system.tables のイントロスペクションによりストレージバックエンドのテーブルを動的に列挙し、visitor_signature または cookie_id_hash カラムを持つすべてのテーブルから該当行を削除します。動的な列挙は意図的なものです。将来スキーマに追加されたテーブルが訪問者識別子を持ちながら消去パスに追加されていない場合、動的列挙を検証する統合テストがスキーマに含まれるすべてのテーブルを対象とするため、フェイルクローズします。

集計ロールアップは削除されません。その理由 — それも GDPR 上正しい理由 — は次のセクションで述べます。監査イベント: privacy.dsar_erase_requested。

3 つのエンドポイントはすべて、署名のないクロスオリジンリクエストを拒否し、サイト運営者のセッションから派生した CSRF トークンを要求し、IP ごとおよび (IP, site_id) タプルごとにレート制限を行って悪用を防ぎます。監査ログはアクセス解析データベースとは別に保持され、サイト運営者の監査ログ保持ポリシー（典型的には 25 か月のアクセス解析ロールアップ期間より長い）に従って保管されます。

なぜロールアップは消去後も残るのか — そしてそれが正しい理由

アクセス解析 DSAR 設計で最も直感に反する部分は、第 17 条の消去請求を超えて集計ロールアップテーブルが残存する点です。最初の反応はたいてい次のようなものです。「ユーザーが削除を望むなら、寄与したカウントを含めて、ユーザーに関するすべてのデータが消えるべきではないか？」

答えは、ロールアップテーブルが実際に何を含んでいるかにかかっています。hourly_visitors の 1 行は、例えば site_id=X, hour=Y, unique_visitors=4271 を記録します。この行は、訪問者のシグネチャも、訪問者の IP も、訪問者単位の識別子も含みません。uniqCombined64 HyperLogLog のスケッチを含みますが、これは個別の値を保存せずに正確な基数推定値を生成する確率的データ構造です。uniqCombined64 スケッチは カウント であって、誰の記録でもありません。訪問者の寄与をスケッチから逆算することはできません。

これは集計データに関する EDPB の標準的な立場です。一度データが識別可能性を超える地点 — 個別の寄与を再構成できる地点を超えて — 集計されれば、もはや個人データではなくなります。CNIL Sheet 16 が推奨する 10 単位への集計は、同じ原則に基づいています。イタリア Garante の Caffeina Media 決定における匿名化分析は、再識別が 合理的に可能か どうかに依拠しています。HyperLogLog スケッチから導出された集計カウントについて、それは合理的ではありません。

実務上の効果: 第 17 条の消去請求は、生イベント行（訪問者単位のシグネチャ、IP 由来のジオロケーション、ホスト名のみのリファラー、ページを含む）を削除しますが、ロールアップテーブルは無傷で残します。サイト運営者のダッシュボードは引き続きそのページへの過去のトラフィックを表示しますが、ダッシュボード上のどの行も、消去を請求したデータ主体まで遡ることはできません。

これはサイト運営者のプライバシーポリシーで 「識別可能性を超えて集計済み」 と表現します。これが正しい言い回しで、「匿名」と過大に主張することも、「依然として個人データ」と過小に主張することもありません。ロールアップは、アクセス解析の保持に関する GDPR 上正しい定常状態です。

ロールアップ TTL の 25 か月の上限（750 日、011_rollup_ttl.sql マイグレーション経由）はどのような場合でも適用されます。集計カウントですら CNIL Sheet 16 のタイムラインで自動的に期限切れになります。

監査証跡 — 8 つのプライバシーイベント

Statnive Live は、プライバシーと法的な領域をカバーする 8 つの構造化監査イベントを発行します。これらは、サイト運営者の DPO、管理者の監査人、またはデータ保護当局による監査のための、第 28 条(3)(h) のアカウンタビリティ証拠です。

イベント	トリガー	目的
`privacy.opt_out_received`	`POST /api/privacy/opt-out`	第 21 条の異議申し立ての登録
`privacy.dsar_access_requested`	`GET /api/privacy/access`	第 15 条請求の開始
`privacy.dsar_erase_requested`	`POST /api/privacy/erase`	第 17 条請求の開始
`privacy.consent_given`	`statnive.acceptConsent()`	`consent-required` ／ `hybrid` モードでの同意付与
`privacy.consent_withdrawn`	`statnive.withdrawConsent()`	同意の撤回
`legal.lia_viewed`	`GET /legal/lia`	サイト運営者の LIA ページの配信
`legal.dpa_viewed`	`GET /legal/dpa`	第 28 条 DPA ページの配信
`legal.privacy_policy_viewed`	`GET /legal/privacy-policy/{lang}`	プライバシーポリシーページの配信

各イベントは、タイムスタンプ、サイト ID、リクエスト ID、および関連するフィンガープリントを含む構造化 JSON です。監査ログはアクセス解析データベースとは別であり、ロールアップされず、25 か月のアクセス解析 TTL で期限切れにもなりません。サイト運営者の監査ログポリシーに従って保持されます（典型的にはより長く、コンプライアンス証拠として無期限に保持されることも多くあります）。

監査証跡は、サイト運営者が監査で規制当局に提出するものです。プライバシーポリシーは公開向けの立場であり、監査イベントはその立場が実際に実装されたことの同時並行的な証拠です。CNIL の査察対応パックには通常、(a) LIA、(b) プライバシーポリシー、(c) 査察対象期間の監査ログ、(d) イベント監査エンドポイントの出力（フランス展開向けの 3 イベント上限チェック）が含まれます。Statnive Live はこの 4 つすべてを標準で生成します。

サイト運営者向け DSAR ランブック

Statnive Live 展開に対する DSAR を処理するための実用的なランブックです。

ステップ 1: 請求を特定する。 データ主体は通常、管理者が公表する DSAR 宛先にメールで連絡します。請求はサイト運営者がデータを特定できる程度に具体的でなければなりません。典型的には、訪問者のブラウザに現在保存されている Cookie ID（訪問者は DevTools で確認可能）か、イベントウィンドウを特定できる程度に絞り込まれた訪問内容の説明を意味します。

ステップ 2: 請求者の本人性を確認する。 GDPR 第 12 条(6) は、データ主体の本人性確認のために合理的に必要な場合、管理者が追加の身分証明を求めることを認めています。アクセス解析の請求では、証明は通常、Cookie ID の支配（訪問者が DevTools の Cookie 表示のスクリーンショットを送付）か、訪問元 IP の支配（同じ IP からの認証済みログイン、またはコールバックチャレンジ）です。サイト運営者は、請求を確認するために必要以上の身分証明を求めるべきではありません。

ステップ 3: 開示クエリを実行する。 サイト運営者は照会識別子を指定して GET /api/privacy/access を呼び出します。レスポンスは一致するイベントです。請求が第 15 条の開示請求であれば、これがデータ主体に送付する回答となり、サイト運営者の DSAR ポータルが好む形式（CSV、JSON、PDF）で整形されます。

ステップ 4: 消去を実行する（請求された場合）。 サイト運営者は同じ照会識別子を指定して POST /api/privacy/erase を呼び出します。エンドポイントは、訪問者識別子を持つすべてのテーブルから該当行を削除します。ロールアップテーブルは無傷で残されます（前セクション参照）。エンドポイントはテーブルごとの削除行数を返します。

ステップ 5: データ主体に確認する。 GDPR 第 12 条(3) は最長 1 か月の回答期限を認めており、複雑な請求についてはさらに 2 か月延長できます。サイト運営者の回答は次の内容を含むべきです。

データが特定され、（消去が請求された場合は）削除されたことの確認。
保持されたもの — ロールアップの集計値 — とそれが個人データではない理由の説明。
サイト運営者の監査ログ保持の旨（DSAR 請求自体がログ記録された事実）。

ステップ 6: 回答を監査ログに記録する。 Statnive Live の監査イベントは、サイト運営者が API エンドポイントを呼び出した際に自動的に発行されました。サイト運営者は、データ主体に送付した回答も、より広範な DSAR 対応システム（通常はヘルプデスクまたは DPMS）に記録しておくべきです。

ランブック全体は半ページのチェックリストに収まります。初めて実装するサイト運営者の多くは、アクセス解析の DSAR が難しいと心配しますが、実際にはこのアーキテクチャは、データが小さく明確に定義されたウィンドウに存在するか、まったく存在しないかのいずれかになるよう設計されています。件数は少なく、クエリは有界で、レスポンス形式は標準化されています。

実装サンプル

自社の DSAR ポータルを Statnive Live と統合するサイト運営者向けに、次のパターンが端から端まで機能します。

// Triggered from a DSAR portal after identity verification
async function handleAccessRequest(verifiedRequest) {
  const response = await fetch(
    `https://app.statnive.live/api/privacy/access?site_id=${SITE_ID}&cookie_id=${verifiedRequest.cookieId}`,
    {
      method: 'GET',
      headers: {
        'X-Statnive-CSRF': await getCsrfToken(),
        'X-Statnive-Operator-Key': OPERATOR_API_KEY,
      },
    }
  );
  if (!response.ok) {
    throw new Error(`DSAR access failed: ${response.status}`);
  }
  const { events, rollup_metadata } = await response.json();
  return { events, rollup_metadata };
}

async function handleErasureRequest(verifiedRequest) {
  const response = await fetch(
    `https://app.statnive.live/api/privacy/erase`,
    {
      method: 'POST',
      headers: {
        'X-Statnive-CSRF': await getCsrfToken(),
        'X-Statnive-Operator-Key': OPERATOR_API_KEY,
        'Content-Type': 'application/json',
      },
      body: JSON.stringify({
        site_id: SITE_ID,
        cookie_id: verifiedRequest.cookieId,
      }),
    }
  );
  if (!response.ok) {
    throw new Error(`DSAR erasure failed: ${response.status}`);
  }
  const { rows_deleted_by_table } = await response.json();
  return { rows_deleted_by_table };
}

オペレーターキーはサイト運営者のシークレットローテーションポリシーに従って交換されます。CSRF トークンは、Statnive Live の標準的な管理者認証フローの一部としてサイト運営者のセッションから派生します。

セルフホスト展開で変わる点

Statnive Live をセルフホスト展開（サイト運営者自身のインフラ上で実行するバイナリ）として運用するサイト運営者にとって、管理者・処理者の関係の分析は変わります。Statnive はサイト運営者のアクセス解析データの処理者ではなく、サイト運営者が唯一の管理者です。Statnive が処理者となる対象がないため、署名すべき Statnive ↔ サイト運営者間の DPA はありません。

DSAR エンドポイントは、ホスト型 Statnive Live SaaS 展開とまったく同じ方法でセルフホストバイナリ上でも動作します。監査イベントは、サイト運営者が選択したログシンク（コンテナ展開では stdout / stderr、伝統的なホストでは syslog、セルフホスト構成では専用の監査テーブル）に出力されます。上記の実装サンプルは、サイト運営者自身のエンドポイントに対しても同じ方法で動作します。

異なる点: 第三者データ主体からの第 15 条請求に対する管理者の回答は、管理者単独の回答です。支援する Statnive 副処理者は存在せず、サイト運営者の IT チームが DSAR 対応者となります。

これはセルフホスト対プライベート EU SaaS の記事で扱うトレードオフの 1 つです。第三者がデータに触れない厳格な姿勢を持つサイト運営者（規制業種、エアギャップ環境）にとっては、セルフホスト形態が明快な答えです。署名済み処理者契約の厳格な姿勢を持つサイト運営者（ISO 27001 ベンダーアンケート、大規模な調達）にとっては、第 28 条 DPA を備えた SaaS 形態が明快な答えです。DSAR アーキテクチャは双方で同じ方法で機能します。

サイト運営者が得られるもの

実務上の成果:

クリーンな DSAR 対応パックで、アクセス解析層に対するあらゆる第 15 条 / 17 条請求に対応可能です。3 つのエンドポイント、8 つの監査イベント、ランブック、実装サンプルを備えます。
ロールアップ残存に関する弁明可能な回答。 「識別可能性を超えて集計済み」という表現は EDPB に整合した立場であり、25 か月のロールアップ TTL はどのような場合でも適用されます。
アカウンタビリティの証跡が、処理者関係に関する第 28 条(3)(h) の監査支援、および管理者自身の記録に関するより広範な第 5 条(2) のアカウンタビリティ原則にマッピングされます。
前方互換性 — Digital Omnibus 第 88a 条のデータ主体権利期待事項との互換性。現行テキストは実質的な第 15 条・第 17 条の義務を変更しないため、DSAR エンドポイントは変更なしで機能します。

提供しないもの: 25 か月のロールアップウィンドウを超えて生の訪問者単位データを保持する方法（ソルト破棄により不可能）。削除請求を「取り消す」方法（削除は不可逆）。「内部」請求の監査ログをスキップする方法（内部請求は存在しません — 3 つのエンドポイントへのすべての呼び出しがイベントを発行します）。

やるべきこと・避けるべきこと

Do	Don’t
ハッシュ化された訪問者識別子を低リスクの個人データとして扱い、第 15 条、第 17 条、第 21 条を順守する。	ハッシュ化識別子を「匿名」と謳う — 仮名化が法的に正しい用語であり、2025 年 5 月 14 日のブリュッセル裁判所がそれを追認しました。
3 つのプライバシーエンドポイント（`/api/privacy/opt-out`、`/api/privacy/access`、`/api/privacy/erase`）を CSRF 保護、レート制限、監査ログ付きで配線する。	監査ログをバイパスする単発の DSAR ハンドラーを構築する — 第 28 条(3)(h) のアカウンタビリティは査察時に必要な証拠パックです。
第 17 条のもとでのロールアップテーブル残存を「識別可能性を超えて集計済み」と表現する — 「匿名」と過大に主張することも、「個人データ」と過小に主張することもしない。	第 17 条請求への対応としてロールアップテーブルの行を削除する — 集計カウントであって訪問者単位のレコードではなく、GDPR 上の利益なしに過去のトラフィック可視性を失います。
アクセス / 消去クエリを実行する前に、GDPR 第 12 条(6) に従って請求者の本人性を確認する — 典型的には Cookie ID の支配またはコールバックチャレンジによる。	必要以上の身分証明を要求する。EDPB 01/2022 開示請求ガイダンスは、過剰な要求が権利を損なうことを明示しています。
ランブックを文書化し、すべてのプライバシー監査イベントをログに残す — EDPB 2025 CEF の焦点は消去権、EDPB 2026 CEF の焦点は透明性です。	DSAR 対応を単発の運用作業として扱う — 協調的な DPA 執行は活発であり、同時並行的な監査証跡が正しい答えです。

結論

GDPR 第 15 条と第 17 条のもとでの開示請求権と消去権は、Web アクセス解析にも適用されます。EDPB Guidelines 01/2025、CJEU の Breyer と IAB Europe 判決、そして各国規制当局の一貫した立場がすべてそれを示しています。アーキテクチャ上の決定はそれにどう対応するかであり、答えは、訪問者単位のデータウィンドウを小さく保ち（日次ソルトローテーション）、ロールアップウィンドウを有界に保ち（25 か月 TTL）、3 つのエンドポイント（オプトアウト、アクセス、消去）を公開し、8 つの監査イベントを発行し、プライバシーポリシーにその立場を文書化することです。

Statnive Live はこの領域をデフォルトで提供します。サイト運営者はそれに対して統合し、監査ログが同時並行的な証拠を捕捉し、ロールアップテーブルは識別可能性を超えて既に集計されているため消去後も残ります。DSAR の騒動は、起こったとしても手続き的なもの — 1 か月の時計、確認ステップ、API 呼び出し、確認メール — であって、アーキテクチャ上のものではありません。

より広範なプライバシー枠組みについては 2026 年 EU 同意なしアクセス解析プレイブックを参照してください。日次ローテーションのソルトがアーキテクチャを本質的にミニマルにする理由については、国別マップを参照してください。同じ監査イベントが GPC とハイブリッドモードの統合をどう支えるかについては、リンク先の記事を参照してください。DSAR の領域は、4 本すべての記事をつなぐ結合組織です。

本記事はプライバシーに関する調査資料であり、法的助言ではありません。 記載した DSAR エンドポイントは技術的可用性の機能です。第 15 条 / 17 条 / 21 条の請求に対するあらゆる回答の法的正確性は、GDPR 第 12 条および関連する各国法のもとでの管理者の責任です。すべての Statnive 顧客はデータ管理者であり続け、自身の設定および DPIA について責任を負います。公開前に必ず管轄の有資格弁護士と相互参照してください。

規制関連参照の状況 — 2026 年 5 月 13 日時点: GDPR 第 12 条、第 15 条、第 17 条、第 21 条、第 28 条(3)(e)、第 28 条(3)(h)、第 33 条；EDPB Guidelines 01/2022 on Right of Access（最終版は 2023 年 3 月採択）；CJEU C-582/14 Breyer 2016 年 10 月 19 日（ECLI:EU:C:2016:779）；CJEU C-604/22 IAB Europe 2024 年 3 月 7 日；2025 年 5 月 14 日のブリュッセル控訴審判決 事件 2022/AR/292（IAB Europe / TC ストリングの流れを追認）；草案 EDPB Guidelines 01/2025 on Pseudonymisation（第 101 回本会議で 2025 年 1 月 16 日に草案採択；公開コンサルテーションは 2025 年 2 月 28 日まで；2026 年 5 月時点で最終版未公表；EDPB スプリントチームは 2026 年夏の完了を目標）；EDPB Guidelines 1/2024 on Legitimate Interest 2024 年 10 月 8 日；EDPB 2025 協調的執行枠組みの焦点: 消去権（第 17 条）；EDPB 2026 協調的執行枠組みの焦点: 透明性および情報提供義務（第 13 条 / 第 14 条）；ePrivacy 指令 2002/58/EC（施行中）および § 25 TDDDG（ドイツ）、Loi 78-17 第 82 条（フランス）などの各加盟国国内化。