詳細情報:
Apex をアーカイブ — 忘れられる権利 (RTBF)
データプライバシー規制では、個人に忘れられる権利 (RTBF) が付与されているため、組織は要求に応じて個人データを安全に消去する必要があります。Archive Apexは、アーカイブ・アプリケーションから特定のデータを特定して削除することでコンプライアンスを実現し、他のアーカイブ・データの整合性を維持しながら徹底的な削除を実現します。
RTBF 検索条件
RTBF 要求を処理するには、適切な検索条件を指定します。次に例を示します。
| 条件 | 例 |
|---|---|
| 項目名 | 従業員 ID |
| オブジェクト | 取引先責任者 |
| 値 | ID 123456789011121314 |
重要な考慮事項
- 申請は 1 日あたり 10,000 件に制限され、ルートレコードの検索制限は 10,000 件です。
- RTBF 削除プロセスは、階層内の直接および間接的に関連する子レコードにまで拡張されます。
- 検索結果が重複すると、監査ファイルで一部のレコードがすでに削除されたとマークされる場合があります。
- 検索結果の制限に達すると、Apex活動状況には、このエラーを含む
200状況コードが表示されます。Request processed. Maximum search results reached. Refine your search or submit a new request. - ほとんどの標準 RTBF 要求は 30 分以内に完了します。
- 最適な結果を得るには、ルートオブジェクトを対象にします。
- [オブジェクト] および [項目名] 検索条件では、大文字と小文字は区別されません。
- アーカイブでは部分削除はサポートされていません。
アーカイブ階層の子レコードの RTBF の動作
子レコードで RTBF 要求を実行すると、その要求に関連付けられているアーカイブ済み階層全体が削除されます。
たとえば、特定のケースレコードを検索してアーカイブ RTBF 要求を送信すると、要求によってケース、関連付けられた ToDo、および関連付けられた取引先ルートレコードが削除されます。これらのレコードは一緒にアーカイブされているため、RTBF はアーカイブされた階層全体を削除します。
ただし、取引先が個別にアーカイブされている場合、ケースレコードで RTBF を実行すると、ケースとその ToDo のみが削除され、取引先レコードは削除されません。
RTBF のしくみ
RTBF プロセスは非同期プロセスとして実行され、これらの連続する API コールに従います。
- データ識別 — Apex は Archive を照会し、指定された検索条件に一致するすべてのレコードを検索します。
- データ削除:Apex がアーカイブに削除要求を送信し、一致するすべてのレコードを削除します。
プロセスが完了すると、アーカイブコンソールの [活動] タブに RTBF 活動アイコンが表示されます。
RTBF 要求の例
元従業員の Maria Johnson が、システムからすべての個人データを削除する RTBF 要求を送信します。会社は、メールのやり取り、顧客とのやりとり、プロジェクトの割り当てと共に従業員レコードをアーカイブします。RTBF 要求に従うには、次の検索条件を使用します。
| オブジェクト | 項目名 | 値 |
|---|---|---|
| 取引先責任者 | メール | Maria@own.com |
| ケース | 従業員 ID | 987654321 |
| ToDo | 割り当て先 | マリア・ジョンソン |
| メール | 送信者 | Maria@own.com |
| ドキュメント | 所有者 | マリア・ジョンソン |
この要求により、Maria の連絡先情報、Maria が関与したケース、Maria に割り当てられた ToDo、Maria にリンクされているすべてのメールおよびドキュメントレコードなどのデータが完全に削除されます。このプロセスは、機密情報の完全かつ正確な削除を確保しながら、データプライバシー規制へのコンプライアンスを維持するのに役立ちます。
API メソッドと応答処理
RTBF 要求を送信する前に Apex データ クエリでクエリを実行して条件を検証することをお勧めします。
| 入力 | 出力 | 定義 |
|---|---|---|
ArchiverAccessorResponse |
|
Forget API コールからの応答。getRTBFStatus メソッドを使用して要求の状況を追跡するrequestIdを返します。 |
Criteria(文字列sObjectName、文字列fieldName、文字列value) |
||
forgetArchivedRecords(list<Criteria>
inputFilters) |
ArchiverAccessorResponse |
アーカイブする忘れ物要求と削除する条件のリストを作成する公開メソッド。 |
getRTBFStatus(string requestId) |
削除された情報のすべての詳細が含まれる CSV レポート。 | RTBF 要求をフォローアップできる公開メソッド。 |
- Archive Apex:RTBF 要求の実行
Archive Apex を手動でテストし、Archive アプリケーションで RTBF 要求を実行します。 - Archive Apex — RTBF 使用事例のシナリオ
Archive アプリケーションでの RTBF の使用事例シナリオ。 - Archive Apex:Archive AppでのPIIの匿名化
レコード自体を削除することなく、アーカイブ済みレコードの個人識別情報 (PII) を匿名化します。匿名化により、機密値が元に戻せないプレースホルダーに置き換えられ、アーカイブアプリケーションのレコード構造を維持しながらプライバシー規制に準拠することができます。
Archive Apex:RTBF 要求の実行
Archive Apex を手動でテストし、Archive アプリケーションで RTBF 要求を実行します。
- [設定] アイコンをクリックします。
- [開発者コンソール] を選択します。
-
コンソールを開くには、Windows の場合は
F12またはCtrl+Shift+I、Mac の場合はCmd+Eを押します。 -
コンソールで、次のコードを実行して条件リストを作成し、RTBF 要求を送信し、アーカイブから
requestIdを取得します。SF_Archive.Criteria criteria1 = new SF_Archive.Criteria('Account', 'Name', 'example name'); list<SF_Archive.Criteria> lst = new list<SF_Archive.Criteria>(); lst.add(criteria1); SF_Archive.ArchiverAccessorResponse response = SF_Archive.ArchiverAccessor.forgetArchivedRecords(lst); Map<String, String> values = (Map<String, String>)JSON.deserialize(response.getBody(), Map<String, String>.class); String requestId = values.get('request_id'); system.debug(requestId); -
[Execute (実行)] をクリックします。
要求が開始されます。完了すると、
requestIdは実行ログに保存されます。
RTBF 要求の状況の表示
RTBF 要求を送信したら、要求の状況を表示できます。
- ページの右上にある [設定] アイコンをクリックします。
- [開発者コンソール] を選択します。
-
Command + Eキーを押します。 -
RTBF 要求の
requestIdを使用して、次のコードを実行します。SF_Archive.ArchiverAccessorResponse reportResponse = SF_Archive.ArchiverAccessor.getRTBFStatus(requestId); system.debug(reportResponse.getBody()); -
[Execute (実行)] をクリックします。
状況要求が開始されます。完了すると、次のいずれかの状況が実行ログに表示されます。
Request failed, please contact support.要求は失敗し、失敗しました。
Request handled, no matching results were found.:指定された条件に一致するレコードはありませんでした。
Request is open. Scan is still in progress.要求はまだ処理中です。
要求が正常に終了すると、削除された情報のすべての詳細を含む CSV レポートを受信します。
CSV レポートには次の情報が含まれます。
| 項目 | 説明 |
|---|---|
| 条件レコード | 要求の削除条件に一致するレコード項目。 |
| 条件レコードタイプ | 要求の条件。 |
| 削除を誘発した関連 Salesforce ID | テーブルの別のレコードが参照し、条件にも一致する行。 |
| Salesforce ID | レポート行に含まれるレコードの ID。 |
| 状況 | レコードが削除されたかを示します。 |
RTBF の一般的なエラー
無効な条件
- 項目はオブジェクトと一致する必要があります。
- 同じオブジェクトで複数の条件を指定することはできません。
- 要求ごとに最大 10 個の条件を送信できます。
結果なし
- 値を部分的にすることはできません。
- 条件は、アーカイブ済みのレコードタイプである必要があります。
たとえば、ID Xを持つアカウントがあり、その ID に属するケースをアーカイブした場合、そのアカウントに属するケースを除外する必要があります。そのためには、次の検索条件を作成します。
Object type: Case, field: AccountId, value: XObject type: Account, field: Id, value: X[アーカイブ] には関連する取引先がないため、この条件では何も削除されません。Archive Apex — RTBF 使用事例のシナリオ
Archive アプリケーションでの RTBF の使用事例シナリオ。
シナリオ 1: 複数のオブジェクトが含まれる RTBF
Jane Doe は、過去 2 年間口座を持っていた XYZ Bank の顧客です。最近、一般データ保護規則 (GDPR) に基づいて RTBF を実行することにしました。Jane は、銀行が自分に関する不要な個人データを保持しており、それをレコードから消去することを希望していると考えています。
Jane は、RTBF 要求を XYZ Bank に送信し、消去する個人データを指定します。これには、口座情報、取引履歴、銀行が保有するその他の個人データが含まれる場合があります。銀行は Jane の個人データの特定と特定を進めます。
| 条件 | 検索条件 | 検索条件 | 検索条件 | 検索条件 |
|---|---|---|---|---|
| オブジェクト | 取引先 | Transaction_c | ケース | メール |
| 項目名 | 名前 | トランザクションユーザー | 顧客名 | 開始 |
| 値 | ジェーン・ドウ | ジェーン・ドウ | ジェーン・ドウ | ジェーン・ドウ |
RTBF 要求には、最大 10 個の個別のオブジェクトを含めることができます。
結果:
[アーカイブ] では、1 件の取引先、2,000 件のトランザクション、15 件のケース (ルート)、30 件のメールが検出されます。
シナリオ 2: RTBF 単一オブジェクト
製薬会社が関節炎を治療する実験薬エディエリクサーを発売しましたしかし、患者の間で深刻な副作用を引き起こしました。薬物を取り消した後、会社はエディのエリクサーに関連するすべての公開レコードとデジタルコンテンツを削除するように RTBF 要求を提出しました。
| 条件 | 検索条件 |
|---|---|
| オブジェクト | Case |
| 項目名 | 薬品名 |
| 値 | エディの万能薬 |
結果:
[アーカイブ] では、1,000 件のケースがルートとして検出され、1,000 件の患者レコードがルートの下に子レコードとしてアーカイブされます。すべて削除されます。
[アーカイブコンソール活動] タブに 1 つの活動が作成され、RTBF アイコンが表示されます。
シナリオ 3: 10,000 件を超えるルートレコードが見つかった RTBF
人気のあるソーシャルメディアプラットフォーム「ConnectWorld」の常連ユーザーである Emily Jones は、アカウントを無効化し、データ保護規制に基づいて RTBF を実行するように要求します。
| オブジェクト | 検索条件 | 検索条件 | 検索条件 |
|---|---|---|---|
| オブジェクト | ユーザーアカウント | 取引先責任者 | ケース |
| 項目名 | 名前 | Phone | 関連 ID |
| 値 | Emily Jones の取引先 ID | エミリーの電話番号 | Emily Jones の取引先 ID |
結果:
[アーカイブ] では、20,000 件のルートケースレコード、300,000 件の取引先責任者、10,000 件のケースがルートとして検出され、ルートの下に子レコードとしてアーカイブされた 150,000 件の取引先責任者が削除されます。
[アーカイブコンソール活動] タブに 1 つの活動が作成され、RTBF アイコンが表示されます。
getRTBFStatus は状況コード 200 を返し、エラーメッセージ「Request processed.検索結果の最大数に達しました。検索を絞り込むか、新しい要求を送信して他のレコードを表示します。"
アーカイブでは、RTBF Apex 要求あたり最大 10,000 件のルート レコードのみを処理できます。このエラーを解決するには、クエリを再度実行して残りのレコードを取得します。
Archive Apex:Archive AppでのPIIの匿名化
レコード自体を削除することなく、アーカイブ済みレコードの個人識別情報 (PII) を匿名化します。匿名化により、機密値が元に戻せないプレースホルダーに置き換えられ、アーカイブアプリケーションのレコード構造を維持しながらプライバシー規制に準拠することができます。
匿名化はマスキングとも呼ばれ、忘れられる権利 (RTBF) などのプライバシー要求に準拠するのに役立ちます。このプロセスでは、アーカイブ済みレコードに対して一括更新が実行されます。データを完全に削除する消去アクションとは異なり、匿名化では特定の機密値が redacted@example.com などの汎用テキストに置き換えられます。
匿名化のしくみ
オブジェクトメタデータを使用して、名前、メール、電話、住所などの PII 項目が検出されます。要求を送信すると、元に戻せないプレースホルダーを使用して元の PII 値がマスクされます。レコード ID やタイムスタンプなどの非 PII データは変更されず、検索可能です。
匿名化は包括的です。ルートレコードを匿名化すると、匿名化プロセスは同じアーカイブ済み階層内のすべての関連子レコードに自動的にカスケードされます。たとえば、取引先責任者レコードを匿名化すると、そのレコードの関連する ToDo と行動の PII も匿名化されます。
重要な考慮事項
- 匿名化プロセスは永続的です。匿名化後に元の PII 値を復元または表示することはできません。
- レコードを匿名化できるのは 1 回のみです。匿名レコードの重複要求を送信すると、システムは無視します。
- 匿名化では、1 組織あたり 1 日あたり 10,000 件のアーカイブ RTBF の標準レート制限が共有されます。
- 匿名化する項目を手動で選択することはできません。[リカバリ] アルゴリズムに基づいて PII 項目が自動的に識別されます。
- 法的に保持されているレコードは匿名化できません。現在訴訟ホールドまたは保持ロック中のレコードは自動的に除外されます。
匿名化要求の送信
SF_Archive.ArchiverAccessor Apex クラスを使用して、対象条件を定義し、匿名化ジョブを送信します。
次の要件を満たしていることを確認してください。
- Apex コードを実行しているユーザーに、
SF_Archive名前空間にアクセスする権限がある。 - 開発者コンソールまたは IDE にアクセスして匿名 Apex を実行。
- 開発者コンソールまたは任意の Apex 実行ツールを開きます。
- [Execute Anonymous (匿名実行)] ウィンドウを開きます。
-
条件を定義して要求を送信するには、次のコードを実行します。このコードブロックは、取引先責任者レコードのメールアドレス項目を匿名化します。
// 1. Define the criteria for the records to anonymize. // Syntax: new Criteria('ObjectAPIName', 'FieldAPIName', 'ValueToMatch'); List<SF_Archive.Criteria> criteriaList = new List<SF_Archive.Criteria>(); // Example: Anonymize a specific Contact by Email criteriaList.add(new SF_Archive.Criteria( 'Contact', 'Email', 'mickey.mouse@example.com' )); // 2. Submit the anonymization request. SF_Archive.ArchiverAccessorResponse response = SF_Archive.ArchiverAccessor.maskArchivedRecords(criteriaList); // 3. Process the response to get the request ID. Map<String, String> values = (Map<String, String>)JSON.deserialize(response.getBody(), Map<String, String>.class); String requestId = values.get('request_id'); // Output the request ID for tracking. System.debug('Anonymization Job Submitted. Request ID: ' + requestId);
匿名化状況の確認
送信時に生成された要求 ID を使用して、匿名化ジョブの状況を確認し、監査レポートを生成します。
匿名化は非同期プロセスです。要求を送信したら、返された要求 ID を使用して進行状況を追跡し、結果を検証します。
-
匿名化ジョブの状況を確認するには、[Execute Anonymous (匿名実行)] ウィンドウで次のコードを実行します。
// Paste the Request ID found in the Debug Log from the anonymization request. // Example: String requestId = '0Qn5e000000abcD'; String requestId = 'YOUR_REQUEST_ID_HERE'; // Check the status. String statusResponse = SF_Archive.ArchiverAccessor.getMaskingStatus(requestId); System.debug('Anonymization Job Status: ' + statusResponse); -
匿名化ジョブの完了後に監査レポートを生成するには、[Execute Anonymous (匿名実行)] ウィンドウで次のコードを実行します。
String requestId = 'YOUR_REQUEST_ID_HERE'; String report = SF_Archive.ArchiverAccessor.getMaskingReport(requestId); System.debug('Anonymization Audit Report: ' + report);
匿名化の結果
匿名化プロセスの完了後に PII 項目がどのように表示されるかを確認します。ジョブの状況が [HANDLED] の場合、アーカイブされたデータはただちに更新されます。
- メールアドレスのように元の PII を使用する検索では、結果は返されません。
- レコード ID などの非機密識別子を使用する検索では、匿名化されたレコードが返されます。
- 検索、エクスポート、またはアーカイブ解除を使用してレコードを表示すると、PII 項目にプレースホルダー値が表示されます。
| 項目 | 元の値 | 匿名値 |
|---|---|---|
| 名前 | ミッキーマウス | redacted_first_name |
| メール | mickey.mouse@example.com | redacted@example.com |
| 電話 | +1-415-555-1234 | 000-000-0000 |
| ContactId | 003XX0000123AbC | 003XX0000123AbC |

