Skip to main content

AgentforceとPII：AI導入前に機密データを保護する

Agentforceは、Salesforceのテキストフィールドに隠れたPIIを読み取ります。コンプライアンスリスクを低減するため、導入前に機密データを見つけて修復する方法を学びましょう。

更新日

AgentforceとPII：AI導入前に機密データを保護する

Agentforceがレコードを取得すると、読み取るフィールドに入っているものすべてがAIのコンテキストに入ります。これには、たとえそれらのフィールドが機密データを保持することを意図していなくても、自由記述フィールドに隠れているあらゆる個人を特定できる情報（PII）が含まれます。Caseコメントに貼り付けられたSocial Security Numberは、エージェントが読み取り、推論し、生成された応答に表面化させうるものの一部になります。

このガイドでは、PIIがどのようにAgentforceのコンテキストに到達するか、Salesforceのどこに蓄積するか、そして本番稼働前にどのように見つけて修復するかを説明します。本ガイドは、関連する2つのガイドの上に成り立っています。導入対応全体を扱うAgentforceの準備ハブと、DQSのパターンマッチングの仕組みを扱うPII Detectionです。

PIIはどのようにAgentforceのコンテキストに入るのか

Agentforceエージェントは一貫したフローに従います。Salesforceレコードを取得し、読み取ったフィールド値に推論の根拠を置き、そのコンテキストから応答を生成します。PIIは取得のステップで入ります。エージェントは、機密データを意図したフィールドと、機密データが偶然に紛れ込んだ自由記述フィールドを区別しません。どちらも読み取ります。

3つの発生源が、時間とともにテキストフィールドをPIIで満たします。

  • email-to-case。 受信メッセージがCaseのDescriptionとCommentsにそのまま取得されます。顧客は問題を説明する際にSSN、口座番号、カード情報を含めます。そのすべてがテキストフィールドに到達します。
  • サポートとセールスのメモ。 担当者は通話中に、本人確認の詳細、支払い情報、連絡先データをメモに貼り付けます。そのメモは、やり取りが終わった後も長く残ります。
  • インポートおよび連携されたデータ。 移行やインテグレーションは、連絡先の詳細、生年月日、識別子を、検証が走らないdescriptionやcommentフィールドに書き込みます。

そのデータがいったん取得可能なフィールドに置かれると、そのオブジェクトを読むようスコープ設定されたエージェントは誰でもそれをコンテキストに引き込めます。露出は、1つもエージェントを導入する前から存在しています。導入は、休眠状態のデータ問題を活性化した問題に変えます。

PIIはSalesforceのどこに隠れているのか

PIIは非構造化のテキストフィールドに集中します。構造化フィールド（Email、Phone）は設計上PIIを含み、それに応じて管理されています。リスクは、ユーザーがメモ書きの場として扱う自由記述フィールドに潜んでいます。

オブジェクト 高リスクなフィールド 蓄積する理由
Case Description、Comments email-to-caseが顧客メッセージをそのまま書き込む
Lead Description インポートしたリストやフォーム送信がここに到達する
Contact Description 本人確認や口座詳細に関するメモ
Account Description 関係性のメモや請求コンテキスト
Task / Event Description、Comments 本人確認データを捉える通話メモ
Opportunity Description 支払い条件に言及する商談メモ
Note (Content) Body 任意のレコードへの自由形式の添付

CaseのDescriptionとCommentsフィールドは、email-to-caseがそれらを自動的かつ大量に供給するため、最も高いリスクを抱えます。それら2つのフィールドを、どのスキャンでも最優先として扱ってください。隠れ場所のシナリオの全体については、PII Detectionのシナリオを参照してください。

どの規制が適用されるのか

取得可能なフィールド内のPIIは、組織がすでに運用しているプライバシーおよびセキュリティのフレームワークに関わる可能性があります。具体的な内容は、データ、管轄区域、契約上の義務によって異なるため、以下の点は法的助言ではなく、コンプライアンスチームと確認するための出発点リストとして扱ってください。

  • GDPR。 データ最小化や目的限定といった原則は、通常、PIIが意図された用途を超えたフィールドに置かれるべきではないことを意味します。descriptionフィールドから生年月日を読み取るエージェントは、そのデータが収集された目的の範囲外になる可能性があります。
  • HIPAA。 保護対象保健情報（PHI）がサポートメモやCaseテキストに現れる場合、それらのフィールドを処理するあらゆるシステム、AIエージェントを含めて、取り扱いルールが適用される可能性があります。
  • PCI DSS。 自由記述フィールド内のカードデータは、通常、保存と取り扱いの要件に該当します。CaseのCommentsにあるカード番号は、一般的かつ優先度の高い検出結果です。

DQSは完全にSalesforce内で実行されるため、PIIのスキャンは新たなデータ転送を生んだり、データを外部サービスに移したりしません。データが組織を離れることはありません。これにより、検出のステップ自体が、国境を越えた転送や処理者に関する懸念の対象外に保たれます。導入前に、自社の状況に対する規制マッピングをコンプライアンスチームと確認してください。

DQSでどのようにPIIをスキャンするのか

DQSは、8つの事前定義された正規表現パターンでテキストフィールドをスキャンし、露出を単一の指標としてレポートします。検出は決定論的かつ透明です。適用されるすべてのパターンを確認でき、同じ入力は常に同じ結果を返します。

8つのパターンは4つのカテゴリーをカバーします。

カテゴリー パターン
金融 Social Security Number、Credit Card Number、IBAN
連絡先 Email Address、US Phone Number、International Phone
技術 IP Address
識別 Date of Birth

スキャンは3つのコントロールで設定します。

  • プリセット。 CriticalプリセットはSSNとCredit Cardのみを有効にします。誤検知がほぼゼロの、素早い金融系PIIチェックに使ってください。StandardプリセットはEmailとUS Phoneを追加します。Extendedプリセットは8つすべてを実行します。
  • フィールドごとのオーバーライド。 異なるフィールドに異なるパターンセットを適用します。Emailフィールドではメールのマッチが想定されるため、SSNとCredit Cardのみをスキャンします。DescriptionとCommentsは、あらゆる種類のPIIが現れうるため、Extendedの全セットでスキャンします。
  • PII Exposure Rate。 これが見出しの指標です。少なくとも1つのパターンに一致するレコードの、スキャン対象に占める割合です。クレンジングの範囲を見極めるため、Records with PII の件数と組み合わせて使ってください。

Definition Builderで高リスクなオブジェクトごとに定義を作成し、DescriptionとCommentsフィールドを対象にして、まずCriticalプリセットを実行して金融系PIIを分離してください。その後、完全なインベントリのためにExtendedを実行します。

修復のプレイブックはどのようなものか

PIIスキャンはマッチのリストを生成します。修復は、そのリストを解決済みの検出結果に変えます。次の順序で進めてください。

  1. マッチをレビューする。 いくつかのパターンには誤検知のリスクがあります。Date of Birthは米国形式の任意の日付に一致し、Credit Cardは長い注文番号に一致することがあります。PIIとして扱う前に各マッチを確認してください。トリアージにはパターンのカテゴリーを使います。金融系の検出結果が最初です。
  2. フィールドごとにアクションを決める。 確認された各検出結果について、3つの対応のうち1つを選びます。
    • マスク。 周囲のテキストをエージェントが使える状態に保ちながら、機密の値を置き換えます。
    • 削除。 ビジネス上の目的を果たさない箇所で値を取り除きます。
    • エージェントスコープからフィールドを除外する。 あるフィールドが、エージェントが必要としないPIIを確実に保持している場合は、エージェントの取得スコープから外し、データがコンテキストに入らないようにします。
  3. 再実行して検証する。 修復後、同じスキャンをもう一度実行します。PII Exposure Rateを修復前のベースラインと比較してください。その数値がクレンジングの成功を裏付けます。すべての次元にわたる体系的なクレンジングの手順については、Agentforce向けSalesforceデータクリーンアップガイドに従ってください。

エージェントスコープからフィールドを除外することは、そのフィールドにAI上の価値がない場合に最も速いコントロールです。マスクと削除は、エージェントがまだ読む必要のあるフィールドに対処します。

導入前のPII安全性目標

データが、Agentforceがアクセスするすべてのテキストフィールドで次の目標を満たすまで、導入を保留してください。

  • エージェントスコープ内のテキストフィールドでPII Exposure Rateが1%未満。
  • CaseのDescriptionとCommentsでSSNのマッチがゼロ。
  • CaseのDescriptionとCommentsでクレジットカードのマッチがゼロ。
  • EmailやPhoneのフィールドが率を押し上げないよう、想定コンテンツのフィールドに対してフィールドごとのオーバーライドを設定。

これらのしきい値はAgentforceデータ対応チェックリストに由来します。本番稼働前にそれらを基準としてコンプライアンスチームの承認を得て、修復済みデータでエージェントの応答をテストし、生成されたコンテンツにPIIが現れないことを確認してください。

本番稼働後にPIIをどう締め出し続けるか

PIIの露出は一度きりのクレンジングではありません。email-to-caseは顧客メッセージをCaseフィールドに書き込み続け、ユーザーは本人確認の詳細をメモに貼り付け続けます。クリーンなデータセットも数週間以内に新たな露出を蓄積します。

劣化を早期に捕捉するため、定期スキャンをスケジュールしてください。

スキャン 頻度 オブジェクト
PII Detection（Criticalプリセット） 毎週 Case、Lead（大量のテキストフィールド）
PII Detection（Extendedプリセット） 毎月 エージェントスコープ内のすべてのオブジェクト

PII Exposure Rateを時系列で追跡し、上昇傾向がエージェントに到達する前にレビューのきっかけになるようにしてください。CaseとLeadへの毎週のスキャンは、新しいPIIが最も速く到達するフィールドをカバーします。スキャン結果がアクションにつながるよう、検出結果をレビューする担当を割り当てましょう。

未検出のPIIは、エージェントがコンプライアンスに反する出力を生む最も一般的な理由の1つです。より広い障害パターンについては、Agentforceエージェントが失敗する理由を参照してください。

次のステップ