PII匿名化パターン ​

個人を特定できる情報（PII）は、エンタープライズデータ全体に存在します。サポートチケットには、顧客名と連絡先詳細が含まれます。 HRレコードには、従業員の個人情報が含まれます。営業レコードには、見込み客データが含まれます。 PIIカテゴリには、名前、メールアドレス、電話番号、国民識別番号、健康データ、金融口座の詳細が含まれます。 Genieはこのデータを取得、処理、保存し、LLMに渡します。つまり、このデータは外部モデルによって処理されます。

これにより、多くの組織でコンプライアンス上の問題が生じます。 PIIはLLMに到達してもよいのでしょうか。答えは、ユースケース、データの機密性、組織の規制上の義務によって異なります。このページでは、PIIを管理できる3つのレイヤー、各レイヤーを適用するタイミング、およびレイヤーの実装方法について説明します。

PIIの3レイヤーモデル ​

GenieワークフローにおけるPII匿名化には、3つの介入ポイントがあります。それぞれ異なるレイヤーで動作し、異なる目的を果たします。適切なアプローチでは、データの機密性と特定のユースケース要件に応じて、1つ、2つ、または3つすべてのレイヤーを使用します。

• レイヤー1：コンテンツがナレッジベースに書き込まれる前に、PIIを削除または置換します。ナレッジベースには PII が含まれていません。 LLMは匿名化されたコンテンツを取得します。
• レイヤー2: スキルは外部システムからデータを取得して匿名化し、その結果を Return response ステップが Genie に送信します。 LLMは匿名化されたデータを受け取り、元のPIIを見ることなくそれについて推論します。
• レイヤー3: Genie のジョブ記述を通じて LLM に指示し、ユーザー入力または取得したデータから PII を削除してからスキルに渡すか保存します。これは最も柔軟なレイヤーですが、信頼性は最も低くなります。決定論的な処理ではなく、LLMが指示に従うことに依存します。

Guardrails の PII 検出はこれらのレイヤーと連携して動作します。 Guardrails は Genie レベルの制御であり、ユーザー入力、ツールの入力と出力、および Genie の出力内の PII を検出します。 Guardrails は、選択した取り扱いモードに基づいて、検出した PII をブロック、マスキング、またはトークン化します。詳細については Guardrails を参照し、Guardrails と各レイヤーが Genie ワークフローにどのように適用されるかについては「Combine Guardrails and genie workflow anonymization」を参照してください。

レイヤー1：ナレッジベース取り込み前の匿名化 ​

ナレッジベース取り込み前のレイヤー1匿名化ガイドラインについては、次のセクションを確認してください。

レイヤー1を使用するタイミング ​

次の場合はレイヤー1匿名化を使用します。

• 取り込むコンテンツに、Genieの取得タスクに不要なPIIが含まれている場合
• 元のPIIを見るべきでないユーザーがナレッジベースにアクセスする場合
• 規制要件により、LLMがアクセス可能なベクトルストアへのPII保存が禁止されている場合

例

• 顧客名と連絡先詳細を含むクローズ済みサポートチケットを取り込む場合。チケットコンテンツを検索可能にしつつ、顧客PIIがナレッジベースに保存されないように、取り込み前に匿名化します。
• HRアシスタントのナレッジベース用にHRレコードを取り込む場合。ポリシー取得のユースケースに不要な従業員の個人情報詳細を削除します。

レイヤー1の実装方法 ​

レイヤー1匿名化は、コンテンツがナレッジベースに書き込まれる前に、ナレッジベース取り込みレシピで実行されます。

ソースシステムからコンテンツを取得し、それを匿名化する変換ステップを追加してから、匿名化された出力をナレッジベース取り込みステップにマッピングします。レシピの Formula ステップまたはカスタムコードステップを使用して変換を適用します。ソースデータがオンプレミスシステムに存在する場合や、非構造化テキスト内の PII を検出する必要がある場合は、取り込み前に匿名化ロジックを実行するオンプレミスエージェント経由でコンテンツをルーティングできます。

このレイヤーで一般的な匿名化手法には、次のものがあります。

• 固有表現の置換：検出された名前、メールアドレス、電話番号、その他の識別子を汎用プレースホルダーに置き換えます。 Jade Anderson at [email protected] reported... は The employee at [EMAIL_REDACTED] reported... になります。
• 一貫した仮名化: 一般的なプレースホルダーではなく一貫した仮名で PII を置き換え、同じ人物が文書内または関連文書間で同じ仮名に対応するようにします。これにより、実際の身元を公開せずに、特定の人物の履歴について推論する能力を維持できます。 Customer_Aは、取り込まれたすべてのチケット全体で同じ人物を一貫して指します。
• データ最小化：取得ユースケースに不要なPIIを含むフィールドまたはドキュメントセクションを削除します。トラブルシューティング目的で取り込まれたサポートチケットには、顧客の請求先住所は必要ありません。取り込み前にそのセクション全体を削除します。

NLP ライブラリやクラウドの PII 検出 API など、非構造化テキストに対して PII を識別するエンティティ検出ツールまたはサービスを使用します。レシピからそのサービスを、例えば HTTP コネクターを使って呼び出します。

制限事項 ​

レイヤー1匿名化は前処理ステップです。スキル出力や会話内のユーザー自身のメッセージなど、他のチャネルを通じてGenieに到達するPIIには影響しません。レイヤー1は、取り込まれたナレッジベースコンテンツ内のPIIのみを保護します。 Guardrails の PII 検出は、ナレッジベース取り込み中のコンテンツを評価しません。

レイヤー2：LLMに到達する前のスキル出力での匿名化 ​

LLMに到達する前のスキル出力におけるレイヤー2匿名化ガイドラインについては、次のセクションを確認してください。

レイヤー2を使用するタイミング ​

次の場合はレイヤー2匿名化を使用します。

• スキルがPIIを含むデータを外部システムから取得する場合
• Genieがタスクを完了するために実際のPII値を必要とせず、匿名化または集計された情報のみを必要とする場合
• 組織のデータガバナンスポリシーにより、特定のPIIカテゴリをLLMに渡すことが禁止されている場合

例

• サポートチケット取得スキルが、顧客名、メール、電話番号を含むチケット詳細を取得する場合。 Genieが分析に必要とするのは、チケットの件名、説明、ステータスのみです。 Genieに返す前に、顧客の連絡先フィールドを匿名化します。
• HRデータスキルが、給与、健康保険プラン加入、個人住所を含む従業員レコードを取得する場合。 Genieが必要とするのは、従業員名と休暇残高のみです。返す前に他のすべてのフィールドを除去します。

レイヤー2の実装方法 ​

レイヤー2匿名化は、外部システムAPI呼び出しとReturn responseステップの間で、スキル内で実行されます。

外部システムからデータを取得し、出力がReturn responseステップにマッピングされる前に匿名化を適用するデータ変換ステップを追加します。変換は次のように実装できます。

• フィールド除外：スキルの出力マッピングにPIIフィールドを含めません。 Genieが顧客のメールアドレスを必要としない場合は、返却スキーマに含めないでください。これは厳密な意味での匿名化ではありませんが、同じ結果を実現します。 PII は LLM に到達しません。
• Workatoレシピステップでの置換：レシピ内のFormulaステップまたはカスタムRuby/Python関数を使用して、特定のフィールド値を出力にマッピングする前に匿名化された同等値に置き換えます。
• カスタム匿名化ロジック: チケットの説明や通話メモのような、非構造化テキストフィールド内の PII 検出など複雑な要件に対しては、出力を Genie に返す前に独自の匿名化ロジックを適用します。ソースデータがオンプレミスシステムに存在する場合やロジックをネットワーク内で実行する必要がある場合は、出力をオンプレミスエージェント経由でルーティングします。これは、完全に除外できないフリーテキストフィールドに PII が現れるケースを処理します。

出力スキーマの原則 ​

レイヤー2匿名化で最も信頼性の高いアプローチは、Genieが必要としないPIIを除外するよう、最初からスキル出力スキーマを設計することです。 Genieがタスクに必要なものだけを返すことは、スキル設計の中核となる原則です。この原則には、機微な PII に対するセキュリティ上の側面があります。出力スキーマから除外されたフィールドは、匿名化ではなく設計によって保護されます。

スキルに匿名化ロジックを追加する前に、Genieがそのフィールドを実際に必要とするかどうかを確認してください。不要な場合は、出力スキーマから除外します。匿名化は、Genieが情報を必要とするものの、匿名化された形式で受け取るべきフィールドに対してのみ適切なアプローチです。

制限事項 ​

レイヤー2匿名化は、ユーザー自身が会話に持ち込むPIIには影響しません。自分自身の個人情報、または同僚の連絡先詳細をチャットに入力するユーザーは、レイヤー2の制御を完全に回避します。また、Genieがナレッジベースから取得するPIIにも影響しません。これはレイヤー1で対応します。

レイヤー3：LLMレベルの匿名化 ​

レイヤー3のLLMレベル匿名化ガイドラインについては、次のセクションを確認してください。

レイヤー3を使用するタイミング ​

次の場合はレイヤー3匿名化を使用します。

• スキルに渡す前または保存する前に、PIIを含む可能性があるユーザー提供コンテンツを処理するユースケースの場合
• Genieが応答する前に自身の出力からPIIを除去する必要がある場合。たとえば、入力に顧客データが含まれ、そのデータを応答にそのまま表示すべきでない要約ユースケースです
• 組織が、レイヤー1と2で処理されないPIIを捕捉する多層防御レイヤーを必要とする場合

LLM が指示に従うことに依存しない PII 処理が必要な場合は、レイヤー3 の有無にかかわらず Guardrails の PII 検出を使用します。

例

• 顧客フィードバックを処理するGenie。ユーザーが、顧客名と連絡先詳細を含む生のフィードバックテキストを貼り付けます。 Genieには、要約して保存する前にフィードバックを匿名化するよう指示します。
• 通話トランスクリプトを要約するGenie。トランスクリプトには、顧客名と連絡先詳細が含まれます。 Genieには、ストレージスキルに渡す前に、要約内の識別可能な情報を汎用参照に置き換えるよう指示します。

レイヤー3の実装方法 ​

レイヤー3匿名化は、特定のアクションの前にPIIを特定して置換するようGenieに指示するジョブ説明の指示を通じて実装されます。

PII HANDLING

スキルにデータを渡す前や
コンテンツを保存する前に、次の
匿名化ルールを適用してください:

- 顧客名を "the customer" に置き換えるか、複数の顧客が関与する場合は
  "Customer_[number]" に置き換える
- メールアドレスを [EMAIL_REDACTED] に置き換える
- 電話番号を [PHONE_REDACTED] に置き換える
- 国民 ID 番号、口座番号、金融識別子を
  [ID_REDACTED] に置き換える
- 住所を [ADDRESS_REDACTED] に置き換える

これらの置換は、単一の処理タスク内で一貫して適用してください。「Josh Hernandez」が同じコンテンツ内で後に
"Mr. Hernandez" や "Josh" として参照されている場合は、すべての参照に同じ
置換を適用します。

次には匿名化を適用しないでください:
- スキルトリガーコンテキストに含まれる、
  要求ユーザー自身の認証済み ID
- 組織内の従業員名で、職務上の肩書きとして
  使用されているもの

レイヤー3の制限事項 ​

レイヤー3は、LLMが匿名化の指示に一貫して従うことに依存します。 LLMは確率的です。 PIIインスタンスを見落としたり、置換を一貫せずに適用したり、あいまいなコンテキストで識別子をPIIとして認識できなかったりすることがあります。

レイヤー3 は、高機密の PII に対する唯一の匿名化制御として使用すべきではありません。これは多層防御の一つのレイヤーであり、レイヤー1 と 2 でカバーされないケースを捕捉するうえで有用ですが、それ単独で信頼できるほどのものではありません。 Guardrails の PII 検出を使用し、レイヤー3 の指示は、LLM に依存せずにユーザー入力および Genie 出力内の PII を処理するための補足として扱います。

GDPR、HIPAA、CCPA の対象データを含む健康情報、金融口座データ、国民識別番号などの規制対象データカテゴリについては、レイヤー1 またはレイヤー2 の制御を主要な匿名化メカニズムとして適用します。レイヤー3は補助レイヤーとして使用します。

Guardrails と Genie ワークフローの匿名化を組み合わせる ​

Guardrails と匿名化レイヤーは、Genie ワークフローの異なる部分をカバーします。次の表を使用して、Workatoワークフローのどこにデータ制御が適用されるかを理解し、自身のユースケースに対してGuardrailsとPII匿名化レイヤーをどのように組み合わせるかを判断してください。

Guardrails の取り扱いモードを選択する ​

検出した各 PII タイプには、次のいずれかの取り扱いモードを使用します。 Genie がその値に対して何を行う必要があるかに基づいてモードを選択します。

サポートチケット Genie のユースケース例 ​

サポート Genie は、クローズ済みチケットを使って質問に回答し、スキルを通じてオープンチケットを検索します。制御は次のように適用します。

• レイヤー1 を用いたナレッジ取り込み: チケット本文内のメールアドレスを、ナレッジベースステップの前にマスクする Formula ステップを追加します。例えば、description.gsub(/[\w.+-]+@[\w-]+\.[\w.]+/, "[EMAIL_REDACTED]") のようにします。ここで、description はチケット本文のデータピルです。
• レイヤー2 を用いたチケット検索スキル: Return response スキーマでは subject、description、status のみを返します。 customer_name、email、phone を除外します。
• Guardrails: Social Security 番号やクレジットカード番号などの高リスク PII タイプは、デフォルトどおり Block に設定したままにします。 Email addresses をオンにして Tokenize に設定し、ユーザーがチャットにメールアドレスを貼り付けて Genie に返信で使用させても、LLM にはアドレスが見えないようにします。
• レイヤー3 を用いたジョブ記述: How to implement Layer 3 の PII 取り扱い手順を追加し、Guardrails でカバーされていない識別子、たとえば有効化していない PII タイプとしての名前や、custom regex pattern にマッチしない組織固有データなどに対する補完とします。

デバッグトレース内の Input Guardrails および Output Guardrails ステップを確認し、どの PII が検出され、どのように処理されたかを確認します。スキルレシピのジョブ詳細を確認し、Return response の出力を確認します。

ユースケースに適したレイヤーの選択 ​

適切なレイヤーの組み合わせは、データの機密性、規制要件、およびワークフロー内でPIIが出現する場所によって異なります。

ユースケースに適したレイヤーを選択するには、次の表を使用してください。

プロダクションでの匿名化のテスト ​

PIIを処理するGenieをデプロイする前に、実際のPIIパターンを含む現実的なデータで匿名化制御をテストします。テストPIIとして[CUSTOMER_NAME]を使用するテストでは、匿名化ロジックがDr. Sarah Williamsを正しく処理できるかどうかは明らかになりません。

各レイヤーを個別にテストします。

• レイヤー1：データを取り込み、ソースコンテンツ内の既知のPIIをナレッジベースで検索して、それが置換または削除されていることを確認します。
• レイヤー2: 現実的なソースデータを使用してテストレシピ内でスキルを直接呼び出し、Return response ステップの前に PII フィールドが除外または置換されていることを確認するために出力を検査します。
• レイヤー3: テストモードに切り替え、Genie に現実的な PII パターンを含むコンテンツを与え、そのコンテンツの要約や処理を依頼します。応答とスキル入力を検査して、PIIが指示に従って処理されたことを確認します。