Skip to main content
GDN8 PATIO

EU・EEA向けWebサイト制作におけるCookieと同意管理の確認事項

Published
Kenta Toshikura

この記事はEU・EEA向けWebサイトの相談や制作への備忘です。Cookieと同意管理ではGDPRという言葉が先行しますが、実際にはePrivacy指令、各国の国内法、GDPR、利用する外部サービスの要件を分けて確認する必要があります。

Cookieバナーを置けば対応が終わるわけではなく対象国、運営主体、サイトの機能、端末への保存・読取り、個人データの送信先によって必要な対応が変わります。アクセス解析のように国によって同意の例外が異なるものもあります。制作側では見積もりの段階から、どのタグを同意前に止めるか、同意画面を自作するかCMPを使うか、公開後に設定を管理する担当者は誰かまで確認します。準備せずに進めると、公開直前に外部サービスの差替えやタグ構成の変更が必要になります。

対象国、サイトの機能、利用サービスから必要な同意管理を判断できるように、制度ごとの判断軸と実装・検証・運用時の確認事項をまとめます。制度とサービスは変わるため、記述は2026年8月4日時点の公式情報で確認しました。

  • ※ この記事は制作と実装のための技術的な整理であり、個別案件の法的判断ではありません。対象国、事業内容、取得データ、利用サービスが確定した段階で現地法に詳しい専門家へ確認してください。
  • ※ 2017年に提出されたePrivacy規則案は2025年に撤回されました。現在もePrivacy指令を各国が国内法へ反映したルールとGDPRを分けて確認する必要があります。
  • ※ 2025年11月にはePrivacy指令とGDPRの一部改正を含むDigital Omnibus案が提出されました。2026年8月4日時点では審議中であり、成立済みの規則ではありません。

対象地域とGDPRの適用範囲

EEAはEU加盟27か国とEFTA加盟3か国の計30か国で構成されます。

  • EU加盟27か国：アイルランド、イタリア、エストニア、オーストリア、オランダ、キプロス、ギリシャ、クロアチア、スウェーデン、スペイン、スロバキア、スロベニア、チェコ、デンマーク、ドイツ、ハンガリー、フィンランド、フランス、ブルガリア、ベルギー、ポーランド、ポルトガル、マルタ、ラトビア、リトアニア、ルクセンブルク、ルーマニア
  • EEAを構成するEFTA加盟3か国：アイスランド、リヒテンシュタイン、ノルウェー

英国とスイスは含みません。英国とスイスにも独自のCookie・データ保護ルールがあるため、配信先に含む場合は別に確認します。

運営者が日本企業でも次のような場合はGDPRの対象になり得ます。

  • EU・EEAにいる人へ商品やサービスを提供する
  • EU・EEAにいる人の行動を追跡する
  • EU・EEA域内の拠点の活動との関連で個人データを処理する

単に日本語サイトがEU・EEAから閲覧できるだけで、直ちに域外適用されるとは限りません。現地通貨や配送、現地語、広告配信、会員募集など、EU・EEA市場へ向けた活動を総合して判断します。

一方でCookie、広告ID、端末識別子などを使ったインターネット上の追跡と、その後のプロファイリングや行動予測を目的とする処理は「行動の監視」としてGDPRの対象になり得ます。たとえば閲覧した商品から興味関心を推定する、利用者を広告配信用のグループへ分類する、別のサイトでも同じ利用者へ広告を表示する、行動を予測してスコアを付けるといった処理です。継続的な実名識別だけが要件ではありません。一方で単発のサーバーログや個人を追跡しない集計だけで、直ちに行動の監視へ該当するとは限りません。

EU・EEA域内に拠点がない運営者へGDPR第3条2項が適用される場合は、例外に該当しない限り第27条に基づくEU域内代理人の選任も必要です。制作側だけでは決めず、適用範囲と合わせて専門家へ確認します。

制作前には少なくとも次の四つの観点を分けて確認します。

確認する場所 確認内容
利用者がいる国 どの国の端末へCookie、識別子、タグを配信するか
対象市場 どの国へ商品・サービスを提供し、広告を配信するか
運営者の拠点 誰が処理目的と手段を決めるか。EU・EEA域内に拠点があるか
データの送信先 ベンダー、サーバー、サポート担当者がどの国にいるか

この四つは同じ国とは限りません。「サーバーがEUにあるから対応済み」「日本企業だからGDPRは無関係」とは判断できません。

端末への処理、個人データ処理、EU・EEA外へのデータ移転を分ける

Web制作では次の三層を分けると整理しやすくなります。

層 主に確認すること 制作上の対応
端末への保存・端末からの読取り ePrivacy指令と対象国の国内法 事前同意が必要か。必要なタグを同意前に止められるか
個人データの処理 GDPR 目的、法的根拠、通知、保存期間、権利対応、安全管理
EU・EEA外への移転 GDPR第5章 EUが十分なデータ保護水準を認めた国・地域への移転（十分性認定）、標準契約条項（SCC）などの移転根拠と追加的な保護措置

最初の層はCookieだけを対象にしていません。localStorage、トラッキングピクセル、URLに埋め込んだ識別子、端末フィンガープリント、SDKなども端末への保存や端末情報へのアクセスとして対象になり得ます。対象となる情報が個人データかどうかだけでは決まりません。Cookieを発行しないという説明だけでも判断できません。

反対にサーバーログへIPアドレスを記録するだけでCookieバナーが必ず必要になるわけでもありません。ただしIPアドレスなどが個人データに当たる場合はGDPR上の目的、法的根拠、保存期間、通知、安全管理を別に確認します。

端末への処理について有効な同意を得ても、その後の個人データ処理が自動的に適法になるわけではありません。反対にGDPR上の正当な利益を設定しても、ePrivacy側で同意が必要な保存・読取りを同意なしで始める根拠にはなりません。Cookie等の説明とGDPRのプライバシー通知は役割が異なり、同意バナーだけで両方を代用することもできません。

サイト機能別の対応基準

複数国へ同じサイトを配信する場合に採用しやすい基本方針をまとめると次のようになります。法令上の結論ではなく、対象国が増えても同じ構成を維持しやすくするための制作上の基準です。

やりたいこと 事前同意の考え方 必要な対応
任意の計測や外部埋込みがない静的サイトを公開する 端末への不要な保存・読取りがなければ、EU・EEAから閲覧できるという理由だけでCookieバナーが必要になるわけではない 実際の通信と保存領域を検査する。サーバーログや問い合わせフォームはプライバシー通知で説明する
ログイン状態やカートを維持する 利用者が明示的に求めた機能へ厳密に必要なら同意なしで使える場合がある 目的、期間、必要性を記録し、Cookie等の説明を掲載する
同意設定を保存する 選択を記憶するために必要な範囲なら同意なしで使える場合がある 同意状態、方針の版、保存期間を管理する。任意の識別情報を混ぜない
アクセス解析を使う EU・EEA横断では事前同意を基本にする。対象国の限定的な例外へ完全に適合するときだけ個別判断する 解析タグを初期状態で止める。目的と事業者を示し、解析だけを選択できるようにする
広告、リマーケティング、コンバージョン計測を使う 原則として利用者が自分で操作して示す事前同意が必要 広告目的を初期状態で無効にする。ベンダーと第三者提供、プロファイリングを説明する
ヒートマップやセッションリプレイを使う 厳密に必要とは通常いえないため事前同意を基本にする 入力欄のマスキング、取得範囲、保存期間、閲覧権限を確認する。高いリスクが見込まれる場合はDPIAの要否も検討する
A/Bテストや任意のパーソナライズを行う 利用者が求めた機能に厳密に必要でなければ事前同意を基本にする テスト用識別子と計測タグを同意前に止める。目的を解析や広告へ流用しない
YouTube、地図、SNS投稿などを埋め込む 読込み時に不要な端末保存・読取りがあれば事前同意が必要になり得る。外部への個人データ送信はGDPRも別に確認する クリック後に読み込む二段階表示、プライバシー強化モード、自社配信を検討する
不正対策やCAPTCHAを使う セキュリティ目的という名称だけで必須にはならない。機能に必要で相当な範囲かを個別に判断する 代替手段、外部送信、取得項目、保存期間、アクセシビリティを確認する
問い合わせ、会員登録、購入を受け付ける フォーム送信の法的根拠はCookie同意とは別に決める 取得項目を必要最小限にし、利用目的、法的根拠、保存期間、送信先、利用者の権利など主な項目を通知する。GDPR第13条・第14条の要件は別途確認する
EU・EEA外のサービスへデータを送る 通常のCookie同意だけではEU・EEA外へのデータ移転の問題を解決できない データの流れを確認し、十分性認定、標準契約条項（SCC）など適切な移転手段を選ぶ

「機能を提供する側に便利」という理由だけでは厳密に必要な処理になりません。利用者が明示的に求めたサービスを提供するため、その保存や読取りがなければ機能しないことを説明できるかが基準です。

ePrivacy指令が同意の例外として示すのは、通信を伝送することだけを目的とする場合と、利用者が明示的に求めたサービスの提供へ厳密に必要な場合です。どちらに当たるかは目的と実際の処理をもとに対象国の国内法で確認します。

同意前の初期状態

同意は自由意思による、目的ごとの、説明を受けた上での明確な意思表示である必要があります。EU・EEAの複数国へ配信する初期実装では次を共通の基準にします。

  • 解析、広告、任意の外部埋込みは初期状態で読み込まない
  • チェックボックスを事前にオンにしない
  • スクロールやサイトの継続利用を同意として扱わない
  • 「すべて同意」を置くなら、同じ階層に「すべて拒否」を置く
  • 解析、広告、機能拡張など目的ごとに選択できるようにする
  • ボタンの色、コントラスト、文言で拒否を不当に見つけにくくしない
  • 同意しなければ閲覧できず、拒否しても利用できる選択肢がないCookieウォールは使わない
  • フッターなど常時見つけられる場所に設定変更の入口を置く
  • 同意の撤回後は同意に依存する以後の処理を止める。同意以外の保存根拠がないCookieや識別子は削除し、証明や法的義務のために残す記録は必要最小限にする

同意と拒否のボタンを完全に同じ色へ揃えるという一律の規則があるわけではありません。重要なのは選択肢の理解しやすさと操作の容易さです。配色だけでなく、ボタンの大きさ、配置、クリック数、文言を含めて評価します。

Cookieや識別子は保存元によって削除方法が異なります。HttpOnly Cookieはクライアント側のJavaScriptから削除できないため、サーバー側で期限切れにする処理が必要です。第三者Cookieはサイト側から直接削除できない場合があります。CMPや提供者が用意する削除・オプトアウト機能を確認し、以後のサービス読込みを止めます。設定の反映にページの再読込みが必要かも含め、ブラウザで確認します。

また同意を得た事実は運営者側が説明できなければなりません。法令が同意記録の統一書式を定めているわけではありません。必要以上に利用者を識別せず、実際に用意した選択肢と同意を証明するために必要な範囲で次の情報を記録します。

  • 選択日時と同意状態
  • 選択された目的とベンダー
  • 表示した説明文とプライバシー通知の版
  • CMPやタグ設定の版
  • 同意を撤回または変更した履歴

実装では利用者を直接識別する情報を必要以上に保存せず、ランダムな同意IDで記録します。アカウントなどとの対応が必要な場合は対応表を分離してアクセスを制限し、保存期間を決めます。ランダムIDだけでも会員データベースやCRMと対応付けられる状態にある場合や実際に結合した場合は匿名情報ではありません。同意ログ自体を個人データとして管理します。

EU・EEA全域で同意を一律に何か月ごとに取り直すという固定期間はありません。目的、ベンダー、処理内容を大きく変更したときや対象国の監督機関が更新を求めるときに再取得します。保存期間を長くしすぎないことも必要です。

国ごとに異なるアクセス解析の例外

アクセス解析は国ごとの差が出やすい領域です。ある国の例外をEU・EEA全体へ適用してはいけません。

配信先 実務上の考え方
EU・EEAの複数国 解析を事前同意の対象にする構成が最も運用しやすい。対象国ごとの例外を使うなら国別配信と設定維持が必要
フランス CNILが示す限定条件をすべて満たすアクセス解析（オーディエンス測定）は同意なしで使える場合がある。サイト運営者のための測定に限定し、匿名統計のみを作り、他目的への再利用、サイト横断追跡、非匿名データの第三者提供をしないなどの制約がある
ドイツ BfDIは技術的に不要な追跡、アクセス解析、パーソナライズ広告に同意が必要と説明している。必要性は運営者が具体的に説明する
一つの国だけを対象にする その国のePrivacy国内法と監督機関の最新ガイダンスを確認する。ツール名ではなく実際の設定とデータ利用で判断する

CNILは、提供者が取得データを自社目的で再利用する通常のGoogle Analyticsなどについて同意免除の対象にならないと説明しています。免除を検討する場合は、サイト運営者専用の測定、匿名統計のみの生成、サイト横断追跡や第三者提供の禁止に加え、提供者による再利用を契約上禁止し、CNILの条件に沿った設定であることを確認します。国別の例外を使う場合は法務判断だけでなく、対象国の判定方法、タグ設定、将来の変更管理まで実装要件に含めます。

CNILは現在、同意免除へ適合する解析ツールの認証や公式一覧を提供していません。実装時点のCNILによる自己評価基準と提供者の資料を確認し、実際の設定が条件を満たすことをサイト運営者側でも記録します。ツール名や過去の評価だけで判断しないようにします。

外部サービスをサービス単位でリストアップする

「Cookie一覧」だけではCookieを使わない通信やページ表示後に動く処理を見落とします。タグマネージャー、埋込み、CDN、チャット、動画、フォント、決済、不正対策などをサービス単位でリストアップします。

リストアップする項目 記録する内容
サービス名と管理者 誰が導入し、誰が設定を変更できるか
利用目的 必須、機能、解析、広告など。目的を曖昧にまとめない
端末への処理 Cookie、localStorage、ピクセル、フィンガープリント、URL識別子など
取得データ IPアドレス、端末情報、閲覧履歴、入力内容、会員IDなど
送信先と役割 受領者、処理者、共同管理者になり得る者
保存期間 ブラウザ、ベンダー、運営者それぞれの期間
EU・EEA外へのデータ移転 保存国だけでなく国外からのアクセスも含む
実行条件 初期表示、同意後、クリック後など
停止方法 CMP、タグマネージャー、サーバー側設定、埋込みの置換など

プライバシーポリシーにサービス名を書くだけでは事前同意の代わりになりません。反対に同意バナーがあっても、HTMLへ直書きしたタグが選択前に動いていれば実装として成立していません。

CMPを使う場合

CMPはConsent Management Platformの略です。同意画面を表示し、利用者の選択をタグや外部サービスへ反映する仕組みです。

CMPは主に次の処理をまとめて管理します。

  • 国・言語に応じた同意画面の表示
  • 必須、機能、解析、広告など目的ごとの選択
  • 同意前のタグ、SDK、iframeの停止
  • 同意日時、選択内容、表示した文面の版の記録
  • 同意設定の変更と撤回
  • タグマネージャーや外部サービスへの同意状態の伝達
  • 複数サイトやサブドメイン間の設定管理

EU・EEAの法令が特定のCMPを使うよう求めているわけではありません。要件を満たせるなら自社で同意画面と管理機能を実装できます。任意のタグや端末への保存・読取りがないサイトでは、CMP自体が不要な場合もあります。

一方で次のような案件ではCMPを使う方が管理しやすくなります。

  • 複数のEU・EEA加盟国へ同じサイトを配信する
  • 多言語で同意画面とプライバシー通知を管理する
  • 解析、広告、動画、地図、チャットなど外部サービスが多い
  • 複数サイト、アプリ、サブドメインを同じ方針で運用する
  • 公開後もマーケティング担当者がタグを追加する
  • 同意時点の設定と表示内容を後から説明する必要がある
  • 広告配信でIAB Europe TCFを利用する

CMP、Google Consent Mode、IAB Europe TCFは役割が異なります。

名称 役割
CMP 選択画面を表示し、同意・拒否・異議申立てなどの状態を管理する製品または仕組み
Google Consent Mode CMPなどから受け取った同意状態をGoogleタグへ伝え、タグの動作を切り替える仕組み
IAB Europe TCF サイト運営者、広告事業者、CMPなどの間で法的根拠や利用者の選択を伝達する広告業界の自主的な標準

TCFへ対応しているだけで法令適合が保証されるわけではありません。すべてのサイトがTCFを導入する必要もありません。多数の広告事業者が関与する媒体では有力な選択肢ですが、解析タグが数個ある企業サイトへ一律に導入するものではありません。

Google認定CMPが必要になる場合

Google AdSense、Google Ad Manager、Google AdMobを使い、EU・EEAの利用者へパーソナライズ広告を配信する場合、Googleは認定CMPとIAB Europe TCFの利用をサービス要件として定めています。この要件は英国とスイス向けの配信にも適用されます。EU法がGoogle認定製品を直接指定しているわけではありません。

GA4やGoogle Adsのコンバージョン計測を使うだけなら、必ずGoogle認定CMPを選ばなければならないわけではありません。自社で作った同意画面からConsent Modeへ状態を送る実装もできます。ただしGoogleのEU User Consent Policyと対象国の法令を満たし、同意前後のタグ動作を検証する必要があります。

認定やパートナー表示も法令適合を保証するものではありません。CMPを導入するサイト運営者が目的、対象サービス、表示文、初期状態を正しく設定します。

CMPを選ぶときの確認事項

導入前には料金やデザインだけでなく次を確認します。

  • 対象国、表示言語、Web・アプリへの対応範囲
  • 自動ブロック、手動ブロック、タグマネージャー連携の仕組み
  • 同意画面より前にCMP自身が行う通信と端末への保存
  • 目的とベンダーを案件に合わせて編集できるか
  • 同意記録の保存場所、保存期間、閲覧権限、書出し方法
  • 複数ドメイン、サブドメイン、クロスデバイスへの対応
  • Google Consent Mode、IAB Europe TCFなど必要な連携への対応
  • キーボード操作、読み上げ、コントラストなどのアクセシビリティ
  • タグスキャンで検出できない動的な処理を手動登録できるか
  • 契約終了時に設定と同意記録を移行または削除できるか

自動スキャンでCookie名が見つかっただけでは正しい分類になりません。同じサービスでも設定と利用目的によって必要な同意が変わります。最終的な分類と説明文はサイト運営者が確認します。

Google Consent Modeを使う場合

Google Consent Modeは同意を取得する画面ではありません。バナーやCMPで得た選択をGoogleタグの動作へ反映する仕組みです。

Basic Modeは選択前にGoogleタグの読込みを止めます。Advanced Modeは同意状態がdeniedでもタグを読み込み、Cookieを使わないpingを送る構成があります。そのためdeniedという値だけを見て「外部送信なし」と判断してはいけません。送信されるリクエスト、パラメーター、利用目的を確認し、対象国の判断とプライバシー通知へ反映します。

複数国向けの初期実装ではBasic Modeのように選択前の任意通信を止める設計が確認しやすくなります。Advanced Modeを使う場合は法務、マーケティング、制作側で送信内容を共有してから採用します。

Cookie同意とEU・EEA外へのデータ移転を分ける

EU・EEAの利用者が解析や広告へ同意しても、そのデータをEU・EEA外へ移転できるとは限りません。GDPR第49条には明示的な同意を含む限定的な例外がありますが、反復的な移転を通常のCookieバナーだけに依存させるものではありません。まず次の順に確認します。

EU・EEA外への通信がすべてGDPR第5章上の移転になるわけではありません。管理者は処理の目的と手段を決める側、処理者は管理者の指示で処理する側、共同管理者は目的と手段を共同で決める側です。GDPRの適用を受ける管理者または処理者が別の管理者、共同管理者、処理者へ個人データを開示し、その受領者が第三国または国際機関に所在するかを確認します。

  1. 誰がどのデータを受け取るかをデータフローにする
  2. 受領者が処理者、管理者、共同管理者のどれに当たるかを確認する
  3. 処理者とは必要なデータ処理契約を結ぶ
  4. EU・EEA外への移転がある場合は十分性認定、標準契約条項（SCC）、拘束的企業準則（BCR）など適切な根拠を確認する。日本への十分性認定や、認証済み米国企業に対するEU-US Data Privacy Frameworkも対象と実際の受領者を照合する
  5. 標準契約条項（SCC）を使う場合は移転先の法制度と実務上のリスクを評価し、契約だけでは足りない場合に必要な技術・運用上の保護措置を検討する
  6. プライバシー通知へ受領者、移転先、移転手段を記載する

サーバーの設置場所だけでなく、海外拠点の担当者が管理画面から閲覧できる場合も確認します。Cookie同意、個人データ処理の法的根拠、EU・EEA外へのデータ移転の根拠は別々に成立させる必要があります。

ブラウザで実装を確認する

仕様書とCMPの管理画面だけでは不十分です。新しいブラウザープロファイルを使い、開発者ツールのNetworkとApplicationを確認します。

  1. 未選択の状態でページを開き、任意のタグ、iframe、API通信が発生していないか確認する
  2. Cookie、localStorage、sessionStorage、IndexedDB、Service Workerを確認する
  3. 「すべて拒否」を選び、同意が必要な保存と通信が始まらないことを確認する
  4. 解析だけを許可し、解析以外の広告や埋込みが動かないことを確認する
  5. 「すべて同意」を選び、予定したサービスだけが動くことを確認する
  6. 設定を撤回し、以後の任意処理が止まることを確認する
  7. 別ページ、言語ページ、サブドメインでも同意状態と実行条件を確認する
  8. タグマネージャーを更新した後も同じ確認を行う

第三者Cookieだけを見ず、第三者ドメインへのリクエスト全体を確認します。タグがCookieを作らなくても、IPアドレス、URL、端末情報などが外部へ送られることがあります。

確認事項

制作開始前に次の項目を決めておくと後からCMPやタグ構成を作り直すリスクを減らせます。

  • 対象とするEU・EEAの国
  • 現地向けの商品、価格、配送、広告、言語
  • 個人データの管理者と問い合わせ窓口
  • 使用予定の解析、広告、動画、地図、チャット、決済、フォント、CAPTCHA
  • 各サービスの目的、取得項目、保存期間、送信先
  • 必須処理と任意処理の分類根拠
  • EU・EEA外へのデータ移転と利用する移転手段
  • CMPの設定、文言、翻訳、同意記録を管理する担当者
  • タグ追加時の承認手順と公開後の定期点検
  • 対象国の専門家へ確認する範囲

CMPは導入して終わる仕組みではありません。新しいタグを追加した場合やベンダーの利用目的が変わった場合にサービス一覧、表示文、実行条件を更新する運用が必要です。

参考

  • ※ ePrivacy指令やGDPRを変更する提案が審議されることがあります。公開時には成立済みの法令と対象国の監督機関による最新資料を確認してください。