Cookie オプトインの実装例。

何が難しいのか。

利用者の行動計測、チャット、外部事業者の問い合わせフォームといった外部部品を 動かして使う前には、利用者の同意が必要です。なぜでしょうか。外部事業者のサーバーに 接続した時点で、実際の利用がまだ始まっていなくても個人に関わるデータが送られてしまうからです。 もっとも単純な例が IP アドレスで、これが外部事業者のサーバーへ送られます。

考えられる解決策。

外部事業者のサーバーへ通信が飛ぶ前に、同意を得る必要があります。 しかも、訪問者や利用者が自分の意思で行う同意でなければなりません。 その同意はいつでも撤回できることも必要です。つまり、現在の状態を 保存しておかなければなりません。そのためには、行われたオプトインをデータベースに保存し、 一意の ID と結びつけるのが適しています。ウェブサイトを訪れた時点で ID は どのみち作られる（たとえば PHP のセッション ID）ので、この例ではそれを使います。

利用の前に、まず個人データの保存と処理について同意を求めます。 それ以前はオプトアウト型の方式が定着していて、一般に「Cookie 同意表示」と 呼ばれていました。Cookie を使っていることと解除の方法を知らせるだけで足りたのです。 多くの場合、プライバシーポリシーの奥に隠れていました。 その結果、いまはオプトインが必要になりました。 オプトインがなければ、個人データを取得し保存することはできません。

「必須」と「任意」— 二つの区分。

アプリケーションを動かすために必要な仕組みと、あとで分析するなどの目的で 個人データを意図的に集める機能とは、分けて考える必要があります。 ここで示す入力画面では、この二つを単純に 「必須」と「任意」に分けています。必須の機能は選択できません。 それがなければアプリケーションを使えないからです。たとえば、ここで設定した内容そのものも 「必要な」Cookie として保存されます。

任意の機能は、使い勝手をよくしたり、アプリケーションの方向性を 利用者に合わせたりするためのものです。そのためには、使われ方や利用の濃さといった 行動のデータが役に立ちます。この過程で広告が表示されることはなく、 氏名や誕生日といった個人的な内容も扱いません。必要なデータを仮名化または匿名化すれば、 内容を利用者に合わせることもできます。処理を行う場所で その人に結びつけられない ID を使う方法です。

これらのデータを処理するには、利用者の同意が必要です。 この例では、アプリケーションの内容を良くするためのデータ取得を扱っています。 データはさらに匿名で集められ、IP アドレスも伏せられます （192.168.0.100 は 192.168.XXX.XXX になります）。

利用者がチェックを入れ、「現在の設定を使う」を押して初めて、 対応する JavaScript が読み込まれ、外部事業者との通信が始まります。 いわゆるオンプレミス型の仕組みは、GDPR のもとでの実装を簡単にしてくれます。 たとえば行動計測ツールの Matomo は、自社のサーバーに導入して 運用することもできます。

すべては運営者の手のなかに。

ここで示した入力画面は、自前の JavaScript と CSS の読み込みで表示されます。 プログラムはすべて自社のサーバーに置いて動かせるので、 オプトインの画面のために外部事業者を使う必要はありません。オプトインの内容は JavaScript 経由でデータベースに入り、そのデータベースも自社のサーバーで動きます。 こうして、集めたデータはすべて運営者の手のなかに残ります。 そしてそのデータに対する責任も、常に運営者にあります。

理解しておきたいのは、外部事業者の機能すべてについて、 理想を言えばオプトインが必要だということです。埋め込んだ動画や問い合わせフォーム、 その他の外部コンテンツでも、場合によっては個人データが送信されます。 それは利用者の同意があってはじめて許されます。 オプトインがなければ、その内容は読み込まないようにすべきです。