同意管理とプライバシー ― 同意の有無で分析は変わる

同意の取り方は、計測と分析にどこまで効くのか。結論から言うと、同意の有無で「取得できるデータ」が変わり、その結果として分析の母集団もバイアスも変わります。同意は計測パイプラインの最上流にあるゲートで、後から分析で取り繕う話ではありません。この記事では、計測設計者として押さえる同意管理の勘所と、同意が下流の予測・因果をどう歪めるかを、架空のD2C「SOLNA」のスキーマで具体化します。なお法的な判断は専門家の確認を前提とし、本記事では断定しません。

同意が計測の前提を決める

同意は「測った後に効く」のではなく、「そもそも測れるかどうか」を決めます。ユーザーが解析Cookieを拒否すれば、その行動データは欠測になるのではなく最初から生まれません。ここを取り違えると、「データが少ない」を分析の問題だと思って手法をいじり続け、本当の原因（同意設計）に手が届きません。

実務上の起点は、同意状態を計測そのものに記録することです。第2回で扱ったデータレイヤーに同意状態を乗せ、各イベントに consent_analytics consent_ads のようなフラグを同伴させて初めて、「どのデータが同意付きで取れたのか」を後から監査できます。記録していないと、行動データが無いセッションについて、その理由が同意拒否なのか、Cookie喪失なのか、そもそも接点が無かったのかを区別できません。

SOLNAのスキーマでいえば、sessions テーブルに収集時点で次の列を追加します（第2回のデータレイヤー経由で同伴）。

-- sessions に collection 時点で追加する同意列:
--   consent_analytics BOOL  -- 解析Cookieへの同意
--   consent_ads       BOOL  -- 広告（マーケティング）Cookieへの同意
--   consent_at        TIMESTAMP
 
-- 経路別の同意率（＝行動データが取れた割合の天井）を測る
SELECT
  channel,
  COUNT(*) AS sessions,
  ROUND(AVG(IF(consent_analytics, 1, 0)) * 100, 1) AS analytics_consent_rate,
  ROUND(AVG(IF(consent_ads, 1, 0)) * 100, 1)       AS ads_consent_rate
FROM `solna.sessions`
WHERE session_start >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY channel
ORDER BY sessions DESC;

自社（D2C・EC）で運用した観測のレンジでは、解析同意率は経路により概ね 70% 〜 90% で、直接流入・オーガニックが高く、ディスプレイやSNS流入は低めに出ます。広告同意は解析より一段低く、おおむね 50% 〜 75% のレンジでした。モバイルはデスクトップより数ポイント低い傾向です。あくまでN=1の観測で、CMPのUI文言・業態・地域構成で大きく動きます。

ここで重要なのは数字の絶対値ではなく、同意率が経路で偏っているという事実です。これが後段のバイアスの源になります。

改正個人情報保護法の押さえどころ

先に注意を促しておくと、日本の個人情報保護法は、GDPRやePrivacy指令のように「Cookieに一律で事前同意を求める」枠組みとは構造が異なるとされています。海外の同意UIをそのまま輸入すると、過剰にも過小にもなりやすい。「海外がこうだから日本でも必須」という横展開は、論点をすり替えがちです。

計測設計の文脈で論点として押さえておきたいのは、概ね次のあたりです（いずれも専門家確認前提）。

• 利用目的の特定・公表と、安全管理措置という基本線。計測で何を集め、何に使うかを説明できる状態にしておく。
• 2022年施行の改正で導入された「個人関連情報」の規律。提供元では個人データに当たらないCookie等の情報でも、提供先で個人データとして取得されることが想定される場合に、確認すべき事項があるとされる論点。これは第6回のConversions API・データ連携に直接効きます。
• 海外の媒体・ツールへデータが渡る場合の越境移転に関する論点。

改正の動向も現在進行形で動いています。個人情報保護法のさらなる改正法案が2026年4月7日に閣議決定・国会提出され、5月26日に衆議院を通過、本稿更新時点（2026年7月7日）では参議院の特別委員会で審議中です（未成立）。柱は、「課徴金制度の導入」「統計等の作成目的での第三者提供の同意不要化」「生体データの利用停止等請求」「子どもの個人情報の規律」です。成立すれば施行は公布後2年以内とされ、2028年頃までに実務対応が求められる見込みです。一方で、Cookie・個人関連情報に関する既存の枠組みを直接組み替える内容ではないため、本記事で扱う同意設計の基本線は当面変わりません。審議状況は動くため、最新は個人情報保護委員会の公表資料で確認してください。

設計者の実務的な立ち位置はシンプルです。法解釈を決めるのは法務・弁護士であって、設計者の仕事は「同意カテゴリと計測挙動の対応表を作り、同意状態を監査可能な形で記録する」こと。この線引きを守ると、法務との会話も「どう実装で担保するか」に集約できます。

CMPと同意モードの役割

CMP（同意管理プラットフォーム）は、同意の取得・記録・適用を一元化する層です。役割は三つに分解できます。UIで同意を取得する、同意状態を保存する、その状態を計測タグやデータレイヤーへ渡す。

設計者が監査すべきは製品の機能比較よりも先に、CMPの結果が確実に下流まで配線されているかです。CMPを入れても配線が切れていれば、拒否したのにタグが発火する、あるいは同意したのにイベントが欠ける、という事故が静かに起きます。とくに第3回で扱ったサーバーサイド（sGTM）側へ同意状態が伝わっているかは見落としやすい点です。

同意モードは、媒体が提供する「同意状態に応じて計測の送信挙動を変える」仕組みを指します。同意が無い分を媒体側でモデル化して補完する考え方もあります（=モデル化コンバージョン。第7回で再訪します）。

なお、個別のCMP製品の選定や設定手順は本記事の範囲外です（私的参考に留めます）。製品選定の前に決めるべきは、同意カテゴリの設計と配線の正しさで、ここが曖昧なままツールを入れても問題は解けません。

実装層の静かな失敗 ― 同意バナーが飾りになる2パターン

配線の話を、もう一段だけ実装に降ろします。CMPと同意モードを概念どおりに入れたつもりでも、実装層の落とし穴で「同意バナーが飾り」になっている事故が実際に起きます。どちらもエラーが一切出ないため、静かに壊れる計測の同意層版と言えます。

1つ目は、consent update を送る「形式」の問題です。Googleの同意モードでは、同意状態の更新は gtag() 関数形式——arguments オブジェクトを dataLayer に push する形——で送るのが仕様です。同じ「dataLayer に push する」でも、配列リテラルで書くと consent コマンドとして解釈されません。

// NG: 配列リテラルの push。エラーは出ないが、consent コマンドとして解釈されない
window.dataLayer.push(["consent", "update", { analytics_storage: "granted" }]);
 
// OK: gtag() 関数形式（arguments オブジェクトを push する）
window.dataLayer = window.dataLayer || [];
function gtag() { dataLayer.push(arguments); }
gtag("consent", "update", {
  analytics_storage: "granted",
  ad_storage: "granted",
  ad_user_data: "granted",
  ad_personalization: "granted",
});

（2026-07時点・Google公式の実装仕様に準拠。GTM側の解釈挙動はバージョンで変わり得るため、実装時は Tag Assistant で着弾確認を。）

症状が独特です。バナーは正常に表示され、押せば同意も保存されるのに、計測側は denied のまま——つまりデータが静かにゼロになります。Next.jsサイトの実装で、私はこれを実際に踏みました。もう一つ現代的な注意として、同意バナーの実装をLLMに書かせると配列リテラル形式を選びがちです。生成コードの見た目は自然で、レビューでも見逃しやすい。

2つ目は、CSP（Content Security Policy）による計測ブロックです。CSPに googletagmanager.com、GA4のビーコン送信先、GTMの noscript iframe の許可が入っていないと、GTM_ID をどれだけ正しく設定しても計測は届きません。厄介なのは、開発環境ではCSPが緩いことが多く、「本番だけ計測ゼロ」として本番で初めて発覚する点です。確認はブラウザのコンソール（CSP違反のエラーが出る）と、ネットワークタブに collect リクエストが出ているかの2点で足ります。

この2つに共通する防御は、完了条件を「設定した」から「着弾を確認した」に変えることです。ステージングの実機で Tag Assistant を開くか、ネットワークタブで collect リクエストを見て、consent パラメータ（gcs / gcd）に同意状態が反映されているところまで見届けて、はじめて完了とします。

同意の有無が分析を歪める

その前に一つだけ前提を。ここから先の議論は、同意が正しく計測に伝わっていることを前提にします。前節の実装層で落ちていると、分析しているのは「全員 denied」のデータです。

ここが本回の分析的な核心です。同意者だけが行動データを残すため、分析の母集団は「同意した人」に偏ります。

仮に同意するかどうかが成果と完全に無関係なら、同意者サンプルは縮むだけで偏りません。問題は、同意の傾向が属性・チャネル・成果と相関するときです。前節で見たとおり同意率は経路で偏っており、無関係という前提はまず成り立ちません。

SOLNAでは会員（customer_id）の成果はCRM側（orders）で取れるので、同意の有無と成果に系統差があるかを部分的に突合できます。

-- 会員ごとに「解析同意付きセッションを1回でも持つか」を判定し、
-- 成果（再購入・定期化の有無）と突合 → 同意の有無で母集団が偏るかを見る
WITH consent_flag AS (
  SELECT
    customer_id,
    MAX(IF(consent_analytics, 1, 0)) AS has_consented_session
  FROM `solna.sessions`
  WHERE customer_id IS NOT NULL
  GROUP BY customer_id
),
repeat_flag AS (
  SELECT
    customer_id,
    MAX(IF(order_type IN ('repeat', 'subscription'), 1, 0)) AS repeated
  FROM `solna.orders`
  GROUP BY customer_id
)
SELECT
  c.has_consented_session,
  COUNT(*)               AS customers,
  ROUND(AVG(r.repeated) * 100, 1) AS repeat_rate
FROM consent_flag c
JOIN repeat_flag r USING (customer_id)
GROUP BY c.has_consented_session;
-- repeat_rate が両群で食い違うほど、同意者だけの行動データで作るモデルは母集団を代表しない

両群で repeat_rate がずれていれば、それは「同意する人」と「成果を出す人」が相関している証拠です。この状態で同意者だけの行動データから予測モデルや因果推定を組むと、非同意者へ一般化できない。記述・予測編で「接合率が下流手法の適用範囲の上限を決める」と書きましたが、同じことを設計側から言い直すと、同意設計が接合率の天井そのものを動かしているということです。

部分的に補正する発想はあります。観測できる属性から同意確率をモデル化し、同意者を逆確率で重み付けして全体に近づける、IPW的なアプローチです。

# 同意者サンプルから全体を推定する発想（IPW）。あくまで最小構成。
from sklearn.linear_model import LogisticRegression
 
# df: 全セッション。X_cols=観測属性（channel, device, 流入時間帯 等）、
#     consent_analytics=解析同意(0/1)、y=見たい指標（例: engaged）
ps_model = LogisticRegression(max_iter=1000).fit(df[X_cols], df["consent_analytics"])
df["p_consent"] = ps_model.predict_proba(df[X_cols])[:, 1]
 
consented = df[df["consent_analytics"] == 1].copy()
consented["w"] = 1.0 / consented["p_consent"]                       # 逆確率重み
weighted_estimate = (consented["y"] * consented["w"]).sum() / consented["w"].sum()
 
# 限界（必読）:
# 1) この補正は「同意確率が観測属性 X で説明しきれる（MAR）」という検証不能な仮定に乗る。
# 2) 非同意者の y はそもそも観測できない。重みは外挿であって実測の復元ではない。
# 3) 直す前に、まず同意率そのものを上げる（同意UI・目的提示の改善）方が筋が良いことが多い。

強調しておきたいのは限界です。逆確率重み付けは「同意するかどうかは観測属性で説明できる」という、それ自体は検証できない仮定に依存します。非同意者の行動は定義上どこにも無いので、これは欠損の復元ではなく外挿です。補正で取り繕う前に、同意率を素直に引き上げる打ち手（同意UIの改善、利用目的の明確化）を先に検討するのが、たいていは健全です。

章末チェックリスト

• 同意状態（解析／広告）を計測時にデータレイヤーへ乗せ、各イベントに記録しているか
• 「行動なし」を、同意拒否・Cookie喪失・構造的に接点なし、の三つに区別できるか
• CMPの同意結果が、クライアント計測とサーバーサイド送信の両方に正しく配線されているか
• 経路別・デバイス別の同意率を一度測ったか
• 同意の有無で母集団（属性・成果）が偏っていないかを確認したか
• 同意者だけのデータでモデルを作るリスク（選択バイアス）を認識しているか
• モデル化で補完された数字を、実測値と別カラムで扱っているか
• プライバシーポリシー・同意文言を弁護士レビューに回したか

ここまでが、計測の前提条件としての同意設計です。同意が決める「どこまで辿れるか」を、自社のデータで実際に成立する手法へ翻訳する判断は、対になる記述・予測編へ。次回は識別子の統合と、接合率の作り方そのものに入ります。