フォームのチェックボックスにチェックが入っているだけでは、信頼できる同意プロセスを構築できません。アプリケーションは、どのアクションに対して、いつ、どの範囲で許可が与えられたのかを把握し、同意が撤回されたら処理を停止できる必要があります。この設計は、連絡や、主要サービスの提供に必要ではない処理など、任意の機能で特に重要です。
PHPアプリケーションで撤回可能な同意を設計するには、ひとつのフラグに混在しがちな複数の判断を分離する必要があります。この設計だけで、ある運用が適用される規制に準拠しているかどうかが決まるわけではありません。プロダクト上の判断と、専門家が確認した指示を、検証可能な技術的動作に落とし込みます。
対象となるアクションを定め、概念を分ける
まず、許可が必要な具体的なアクションを記述します。「すべてに同意する」は解釈や撤回が難しい一方、「メールでプロモーション情報を受け取る」なら、目的とチャネルをより明確に限定できます。目的や適用範囲に実質的な変更があった場合、以前の同意が自動的に有効だと見なさないでください。
同意と、関連する次の概念を区別します。
- 利用規約：契約条件やアクセス条件を定めるものです。利用規約への同意だけで、任意の処理を許可したことにはなりません。
- 設定：表示方法や構成に関する選択を表します。同意が必要な場合もありますが、常に同意を意味するとは限りません。
- アクセス権限：認証済みのIDがシステム内で実行できる操作を制御します。任意の許可を撤回しても、それだけでアカウントを無効化すべきではありません。
- 同意：採用した機能上および法的な基準に従い、定義された目的と適用範囲に関する判断を記録します。
各目的を安定したカタログに登録し、画面表示用のわかりやすい説明と、コード内で参照する内部キーを用意します。異なる目的に汎用キーのacceptedを使い回すのは避けてください。
状態とその変更をモデル化する
有用なモデルでは、対象者、目的、適用範囲、状態、判断の発生元、タイムスタンプを特定します。対象者はアカウントの場合も、アカウントに紐づくIDの場合もあります。どちらを選ぶかは、同意と個人、アカウント、チャネルとの関係によって決まります。処理や判断の説明に必要なデータだけを保存してください。
すべてを文脈のないブール値で表すのではなく、参照可能な現在の状態を保持します。監査要件に照らして必要な場合は、変更イベントを不変または追記専用で保存します。イベントには次の情報を含められます。
- 対象者IDと目的キー。
- 記録されたアクション。たとえば、許可または撤回。
- 適用範囲。たとえば、チャネルやカテゴリ。
- 一貫した形式のサーバー日時。
- 発生元。過剰なデータを収集せず、認証済みフォームや管理者向けフローなどを記録。
- 変更の調査に役立つ場合は、相関IDまたは定義のバージョン。
イベント記録は追跡可能性を高めますが、依頼が明確だったこと、画面表示が適切だったこと、判断が法的に有効であることを自動的に証明するものではありません。適切な設計の代わりとして、フォームの不要なコピー、IPアドレス、その他の機微なデータを保存するのは避けてください。
PHPでは、各コントローラーが直接状態を書き換えるのではなく、たとえばConsentServiceのようなドメインサービスに操作を集約します。現在の状態の更新とイベントの挿入で同じストレージを使う場合は、データベーストランザクション内で実行してください。
アクションの実行時に許可を確認する
許可がない場合に画面上の選択肢を非表示にすることはできますが、それだけでは十分な制御になりません。送信をキューに登録する、任意の処理を行う、外部連携を呼び出すなど、アクションを開始する箇所で確認する必要があります。撤回前に作成された送信待ちメッセージも、送信前に確認してください。
ドメイン操作から、たとえばConsentRepository::isGranted($subjectId, $purpose, $scope)のようなインターフェースを呼び出せます。これは例示的な名前です。戻り値では、現在の状態、正確な目的、適用範囲、さらにプロダクトで定めた有効期限やバージョンのルールを考慮する必要があります。あるチャネルへの同意を、別のチャネルへの許可として扱わないでください。
非同期で実行する場合はIDを引き渡し、フォームから送られた古い状態のコピーを信頼するのではなく、ジョブの処理時に状態を再確認します。リポジトリが停止した場合の動作は、明示的に決めてください。機微な任意アクションでは通常、許可を確認できるまで実行しないほうが安全です。不要なデータを露出させずに、運用上の障害を記録してください。
同意を撤回し、変更を伝播させる
撤回とは状態を明示的に遷移させることであり、履歴をひそかに削除したり、セッションを取り消したりすることではありません。任意の許可に基づくアクションを停止しながら、ユーザーは認証状態を維持し、サービスへのアクセスを続けられます。同様に、同意の撤回がすべてのデータの削除を自動的に意味するわけではありません。データの保持、削除、以後の処理については、適切な助言のもとで別途要件を定める必要があります。
撤回を記録する際は、アプリケーションが参照する状態を更新し、後続タスクの連携に使えるイベントを発行します。伝播先として、キュー内のジョブ、スケジューラー、通信システム、外部連携を特定してください。処理の不整合を防ぐには、トランザクショナルOutboxテーブルや冪等なコンシューマーなどのパターンを使い、連携先が利用できない場合の動作も定めます。
すでに実行された効果、たとえば配信済みのメッセージは、常に取り消せるとは限りません。そのため、今後のアクションの防止、未処理タスクのキャンセル、発生済みの効果の是正を区別してください。結果を正確に伝え、伝播に失敗した場合に備えて再試行または運用上の確認手段を用意します。
境界、再試行、部分的な障害をテストする
テストでは、フォームに選択肢が保存されることだけでなく、プロセス全体を網羅する必要があります。許可、拒否、撤回、目的の変更、繰り返しのリクエストを含めてください。撤回を繰り返しても同意が再有効化されないこと、イベントの重複によって送信の重複や矛盾した状態が生じないことを確認します。
- その目的と適用範囲について有効な許可がない場合、アクションが開始されないことを確認する。
- ジョブ作成後に同意を撤回し、コンシューマーが実行前に状態を再確認することを確かめる。
- 状態の更新から連携先への通知までの間に障害を発生させ、整合性の再確認によって伝播を完了できることを確認する。
- 古い状態、データの欠落、リポジトリのエラーをテストし、定義済みの安全な動作を確認する。
- ある目的の撤回によって、他の目的、アクセス権限、セッションが変化しないことを確認する。
運用メトリクスや処理エラーを記録する際、技術ログを個人情報の別の保管庫にしないでください。保留中のタスクと、中央の状態と連携先との不一致を定期的に確認します。
デプロイ前に責任範囲を合意する
プロダクト部門は目的、適用範囲、文言、撤回時の体験を定義し、技術部門は実行経路ごとにその判断を適用します。セキュリティ担当者や法律の専門家は、脅威モデル、データの最小化、保持期間、適用される解釈を確認できます。実装は、そのレビューの代わりにはなりません。
デプロイ前に、各目的に依存するアクション、定義を変更できる担当者、誤りの修正方法を文書化してください。そうすることで、同意は独立したチェックボックスではなく、PHPアプリケーション内で検証、追跡、伝播できる条件になります。
