プロンプトとユースケース
同意、取り消し、利用目的の変更を記録し、監査クエリをサポートするマルチテナント対応の同意レシート台帳を設計してください。このプロンプトは、システムデザイン、プライバシーエンジニアリング、プラットフォームインフラの面接に適しています。重要なのは、同意を上書き可能なブール値としてではなく、追跡可能なファクト（事実）としてモデル化することです。
面接官が評価するポイント
- 同意イベント、目的のバージョン、データカテゴリ、証拠、および取り消しのセマンティクスを定義しているか。
- テナント分離、追記専用（append-only）の完全性、冪等性、検証可能なクエリが一体となって設計されているか。
- 取り消しの伝播、遅延したコンシューマー、リトライ、履歴の修正が適切に処理されているか。
- プライバシー最小化、監査可能性、クエリパフォーマンス、データ保持期間のバランスが取れているか。
回答前に確認すべき明確化のための質問
サブジェクトがエンドユーザーか企業管理者か、また同意のスコープが利用目的、データカテゴリ、リージョン、またはプロセッサーごとに区切られているかを確認します。ピーク時のイベント量、クエリの次元、監査の期限、クロスリージョンストレージ、取り消しの即時性、ダウンストリームからの応答確認について質問します。機械可読形式のエクスポート、リーガルホールド（法的保持）、削除リクエスト、テナント管理の暗号鍵について明確にします。
30秒の回答フレームワーク
「バージョン管理された目的と、同意付与、更新、取り消し、伝播結果のための追記専用イベントストリームを使用します。書き込みはテナントごとにパーティション分割され冪等であり、読み取りは指定された時点における有効な状態と証拠チェーンを返します。取り消しは、リトライと人間による確認を備えた信頼性の高いキューを介してダウンストリームのプロセッサーに通知されます。暗号化、最小限のフィールド、テナント鍵、保持ポリシーによってデータ露出を制限します。」
ステップごとの詳細な回答
- ドメインモデル: サブジェクト、テナント、目的のバージョン、データカテゴリ、同意元（source）、言語、タイムスタンプ、証拠テキスト、状態遷移を定義します。
- 書き込みと完全性: 単調増加シーケンスとリクエスト冪等性キーを使用してイベントを追記します。サイレントな改ざんを防ぐためにハッシュチェーンや署名を使用し、鍵のローテーションとテナント分離を切り離します。
- 状態の読み取り: サブジェクトおよび目的ごとのクエリ用にプロジェクションを構築しつつ、イベントの位置、プロジェクションのバージョン、証拠への参照を保持します。
- 取り消しの伝播: ダウンストリームのプロセッサーに取り消しを発行し、各受信者の確認応答（ACK）、リトライ、最終的な失敗を記録します。「送信済み」が「処理停止済み」を意味してはなりません。
- 運用とガバナンス: データのパーティショニング、ストレージの階層化、アクセスの監査、削除とリーガルホールドの優先順位付けを行い、テナントによって認可されたエクスポートとページネーションを提供します。
高品質な回答サンプル
私はこの台帳を、イミュータブルなイベント層、再構築可能なプロジェクション、およびアクセス制御された証拠ストレージに分割します。各イベントには、テナント、不可逆なサブジェクト参照、目的とバージョン、データカテゴリ、アクション、ソース、時刻、ポリシーのバージョン、リクエスト冪等性キーを含めます。元の同意テキストやUIのスナップショットは暗号化ストレージに保存し、通常のクエリ対象から除外します。テナントには個別のパーティションと鍵スコープを持たせ、イベントはテナントシーケンスに追記され、ハッシュと署名を使用してサイレントな編集を検出します。クエリサービスはプロジェクションを読み取って指定された時点の有効な状態を取得し、イベント位置と証拠参照を返します。取り消しイベントは信頼性の高いキューに入り、ダウンストリームのプロセッサーごとに確認応答を追跡します。タイムアウトや拒否が発生した場合はリトライとエスカレーションを行い、記録済み（recorded）、送信済み（sent）、確認済み（acknowledged）、失敗（failed）の明示的な状態を持たせます。プロジェクションは、目的バージョンの変更や履歴修正のために台帳から再構築可能です。テナント分離、重複リクエスト、順序不同のイベント、鍵ローテーション、取り消しレイテンシ、エクスポート認可、削除ホールドについて、テストやリプレイドリルを用いて検証します。
よくある間違い
consent=trueのみを保存し、目的のバージョンや取り消し履歴を消去してしまうこと。- ダウンストリームへの通知成功を、処理が停止したことの証明として扱うこと。
- 追記専用イベントを編集可能な行で置き換えてしまい、履歴変更の証拠を失うこと。
- 識別可能なサブジェクトやテナントデータをグローバルインデックスに配置し、分離と最小化の原則を破ること。
- 順序不同のイベント、リトライ、プロジェクションの再構築、削除、またはリーガルホールドを考慮せずに書き込みを設計すること。
フォローアップの質問と回答
ユーザーが同意を2回クリックした場合はどうなりますか？
リクエストの冪等性キーとイベントフィンガープリントを使用して重複を排除しつつ、有意義なソースやUIバージョンの変更は保持します。有効な状態を返し、どのリクエストが統合されたか、または無視されたかを記録しておきます。
目的バージョンの変更には新たな同意が必要ですか？
目的のテキストとバージョンはイミュータブルな参照として扱います。新しいバージョンで処理範囲が拡大する場合は、「再同意が必要（re-consent-needed）」な状態を作成し、新しい目的に対して古い同意を暗黙的に適用しないようにします。
台帳は削除リクエストをどのようにサポートしますか？
保持する必要がある監査証拠と、削除可能なサブジェクトデータを分離し、非識別参照や必要に応じて暗号学的消去（cryptographic erasure）を使用します。リーガルホールドは通常の削除よりも優先され、そのスコープと例外は制御されたイベントとして記録されます。
クエリがイベントを見落としていないことをどのように証明しますか？
テナントのシーケンス範囲、プロジェクションのバージョン、イベントチェックのサマリーを返します。監査ツールは同じ時点でイベント層を再生（リプレイ）し、プロジェクションと比較することができます。