必要な処理を、
個人情報を渡さずに。

代理ID

本人情報そのものではなく、サービスごとに分けた識別子で利用者を参照する設計です。異なるサービス間で同じIDを共有しないことで、照合や追跡につながる範囲を抑えます。

検討事項：企業・サービスごとのID分離、識別子の推測困難性、ID更新と削除、対応表へのアクセス制限。

トークン化

メールアドレスや住所の代わりに、用途を限定した参照トークンを使います。どの処理で使えるか、有効期限や利用回数までを管理する設計です。

検討事項：漏れたトークンの悪用防止、再利用の制限、取り消し、トークンを実データに戻せる主体の限定。単純なハッシュ化を匿名化とみなさない設計が必要です。

アクセス権限

「企業Aは配送のために、この注文の住所を一度だけ利用できる」といった条件を、処理のたびに検証する設計です。ログイン済みかどうかだけではなく、誰が、何のために、どの情報を扱えるかを確認します。

検討事項：企業間の分離、用途と範囲の指定、期限、取り消し、管理権限、操作履歴。技術上の許可と本人の同意・契約上の根拠は区別して扱います。

データ保管庫

本人情報を業務データから分離し、限定した経路からだけ利用する保管庫です。保存時と通信時の暗号化に加え、鍵管理、管理者権限、バックアップ、削除までを一体で設計します。鍵の保管・暗号処理には、Azure Key VaultやAWS KMSなど、導入先のクラウドに合わせた鍵管理サービスを利用します。

検討事項：鍵とデータの分離、テナント境界、復旧と可用性、証跡、保持期間。集約によって保管庫が重要な攻撃対象になるリスクも考慮します。