【同意が成果を決める】プライバシー×成果を両立する“同意データ設計”

使う場面	何をするか（実務の動き）	設計の注意点
施策運用	対象の切り替え抑制同意状態に応じて、出し分けのルールを決める。施策側の「何をやって良いか」を明確にして、運用判断を軽くする。	状態定義が曖昧だと現場判断がぶれる。 “未選択”の扱いを先に決めるのが重要。
分析	母集団の定義前提の明示分析対象を同意状態で定義し、レポートの前提を揃える。 “比較可能なデータ”として扱えるようにする。	途中で同意状態が変わることを前提にする。「いつ時点の同意か」を必ず持つ。
社内連携	責任分界参照API プロダクト・営業・CSなどが同じ同意状態を参照できるようにする。「誰が更新し、誰が参照し、誰が監視するか」を決める。	部門ごとに同意の解釈が違うと事故が起きる。状態定義とデータ辞書を共有する。
外部連携	連携条件の統一監視連携先ごとの要件に合わせつつ、同意の解釈を統一する。不整合が起きたときに検知して止められるようにする。	連携先の仕様差で“同意が欠損”して見える場合がある。ログと監視で早期検知する。

段階	やること	成果の見え方（期待値）
定義	目的分解状態定義用語統一目的を整理し、同意の状態（同意/不同意/未選択/撤回など）を定義する。社内で同意の用語と解釈を揃える（データ辞書の土台）。	ここが曖昧だと運用が炎上しやすい。「合意形成」が最大の成果。
設計	同意ログ同意状態適用範囲 “履歴（ログ）”と“現在状態”を分けて持つ。どの文面・どの版で同意したか、どこに適用されるかを定義する。	説明可能性が一気に上がる。ただし細かすぎると運用が重くなる。
実装	UI反映イベント連携権限 UIと状態更新を接続し、同意状態を参照できる仕組みを作る。参照権限・更新権限を明確にして、変更管理を整える。	“同意の取得”が実務として回り始める。初期は欠損や不整合の対応が重要。
運用	監視問い合わせ改善欠損・急変・不整合を定期点検し、影響範囲を切り分ける。文面変更や目的追加などの変更手順を、更新可能な形で整える。	安定運用が成果につながる。 “運用の型”が定着すると強い。