匿名化

概要

匿名化エンリッチメントは、処理データの分析価値を維持しながら、機密性の高いテキスト属性値を体系的に匿名プレースホルダーに置き換えることで包括的なデータプライバシー保護を提供します。この重要なデータ保護オペレーターは、個人識別情報(PII)、機密ビジネスデータ、およびその他の敏感なテキスト値を一貫した匿名識別子に置き換えることで、GDPR、HIPAA、およびその他のデータ保護基準などのプライバシー規制への準拠を保証します。エンリッチメントは、実際の敏感情報は削除しつつ、プロセス分析に不可欠なデータの関係性やパターンを保持し、外部関係者とのデータ共有、デモンストレーション利用、または安全性の低い環境への保存を安全に行えるようにします。

匿名化エンリッチメントは、同一の属性値をグループ化し、各一意の値を「AttributeName 0001」「AttributeName 0002」の形式で標準化された匿名識別子に置き換えます。この方法により、同じ元の値はすべて同じ匿名識別子で置き換えられ、データの一貫性が維持され、機密情報を露出せずに意味のあるプロセス分析が可能になります。エンリッチメントは、すべてのテキスト属性に自動的に適用することも、プライバシー要件に応じて特定の属性に限定して適用することもでき、どのデータを匿名化し、非機密属性は参照用に残すかを柔軟に制御可能です。

一般的な用途

  • 顧客名、従業員ID、メールアドレス、社会保障番号などの個人識別情報(PII)を保護
  • 口座番号、クレジットカード情報、取引参照番号などの財務データを第三者と共有する前に匿名化
  • 外部のコンサルタントやベンダー向けにデータ機密性を保ったままデータセットを準備
  • 機密性の高い業務情報を公開せずに本番データからデモ用データセットを作成
  • GDPR準拠のためにプロセスマイニングプロジェクト内の個人データを匿名化
  • 医療現場で患者情報を保護しながら症例関係を維持した患者プロセス分析
  • 調達プロセス分析において、競合情報保護のためにサプライヤーやベンダー名を匿名化

設定

属性名(任意): 匿名化対象とする特定のテキスト属性を選択します。空欄の場合、エンリッチメントはケースおよびイベントテーブルのすべてのテキスト属性を自動的に匿名化します。なお、Case IDやActivity名などのシステム属性は除外されます。この選択的設定により、機密性の高い属性のみを匿名化し、非機密の参照用データはそのまま保持できます。ドロップダウンにはデータセット内のすべての利用可能なテキスト属性が表示されます。匿名化したい属性をそれぞれクリックして複数選択可能です。数値型や日付型の属性は通常個人識別情報を含まないため選択できません。

例 1: GDPR準拠のカスタマーサービスプロセス

シナリオ: 通信会社が外部コンサルタントにプロセス最適化解析のため顧客サービスプロセスデータを共有するが、GDPR規制に準拠するために顧客の個人情報を保護しなければならない。

設定:

  • 属性名: Customer_Name, Phone_Number, Email_Address, Account_Number, Address, Credit_Card_Last4

出力: エンリッチメントは機密の顧客データを匿名識別子に置き換えます:

  • Customer_Name: "John Smith" → "Customer_Name 0001"
  • Customer_Name: "Jane Doe" → "Customer_Name 0002"
  • Phone_Number: "+1-555-0123" → "Phone_Number 0001"
  • Email_Address: "john.smith@example.com" → "Email_Address 0001"
  • Account_Number: "ACC-789456123" → "Account_Number 0001"

異なるケースで登場する "John Smith" はすべて "Customer_Name 0001" に一貫して置き換えられ、データ関係性を分析に活用可能です。

インサイト: コンサルタントは実際の個人情報にアクセスすることなく、顧客サービスのパターン解析やボトルネックの特定、改善提案を行え、完全なGDPR準拠を実現しつつ有益なプロセスインサイトを得られます。

例 2: 医療患者経路分析

シナリオ: 病院が患者の治療経路を各部署間で分析したいが、研究目的でデータを使用する前にHIPAA規制に準拠して患者の健康情報(PHI)を保護する必要がある。

設定:

  • 属性名: Patient_Name, Medical_Record_Number, SSN, Insurance_ID, Physician_Name, Diagnosis_Description, Medication_Names

出力: 機密の医療情報を体系的に匿名化:

  • Patient_Name: "Robert Johnson" → "Patient_Name 0001"
  • Medical_Record_Number: "MRN-2024-45678" → "Medical_Record_Number 0001"
  • SSN: "123-45-6789" → "SSN 0001"
  • Physician_Name: "Dr. Sarah Williams" → "Physician_Name 0001"
  • Diagnosis_Description: "Type 2 Diabetes" → "Diagnosis_Description 0001"

複数の症例に現れる同じ診断も同じ匿名識別子を持ち、パターン解析が可能。

インサイト: 研究者は患者移動パターンや治療分析、ケア最適化の機会を特定可能で、完全な患者プライバシー保護とHIPAA準拠を維持できます。

例 3: 財務監査プロセスの匿名化

シナリオ: 会計事務所が実際の監査データを用いて潜在顧客に監査プロセスの手法を示すが、企業名や財務アカウント情報の機密を守る必要がある。

設定:

  • 属性名: Company_Name, Account_Number, Bank_Name, Auditor_Name, Contact_Person, Tax_ID

出力: 財務および企業識別子を匿名コードに置換:

  • Company_Name: "Acme Corporation" → "Company_Name 0001"
  • Account_Number: "4532-1234-5678-9012" → "Account_Number 0001"
  • Bank_Name: "First National Bank" → "Bank_Name 0001"
  • Auditor_Name: "Michael Chen" → "Auditor_Name 0001"

異なる監査段階においても「Acme Corporation」は同じ "Company_Name 0001" を使用。

インサイト: 事務所は監査プロセスの効率性や準拠確認手順をクライアントに示し、機密情報を明かさずに方法論を強調できます。

例 4: サプライチェーンデータ共有

シナリオ: 製造業者が物流最適化ベンダーにサプライチェーンプロセスデータを共有するが、競合からのサプライヤー関係や価格情報保護が必要。

設定:

  • 属性名: Supplier_Name, Supplier_Contact, PO_Number, Part_Number, Supplier_Location

出力: サプライヤーや部品情報を匿名化し関係性を保持:

  • Supplier_Name: "TechParts Asia Ltd" → "Supplier_Name 0001"
  • Supplier_Contact: "Lisa Wang" → "Supplier_Contact 0001"
  • PO_Number: "PO-2024-789456" → "PO_Number 0001"
  • Part_Number: "CPU-X7-2024-ADV" → "Part_Number 0001"

複数の発注書に登場する同一サプライヤーは一貫した匿名化を保持。

インサイト: ベンダーはサプライチェーンパターンや配送のボトルネックを分析し、競合のサプライヤー情報や価格を知ることなくルーティング最適化を実施可能。

例 5: 従業員パフォーマンスレビュー

シナリオ: 人事コンサルティング会社がパフォーマンスレビューの最適化をサポートするため、実際の従業員名やID、給与情報を除外したプロセスデータへのアクセスを必要とする。

設定:

  • 属性名: (空欄のままにしておくとすべてのテキスト属性を自動的に匿名化)

出力: すべてのテキスト属性が自動的に匿名化されます:

  • Employee_Name: "Jennifer Brown" → "Employee_Name 0001"
  • Manager_Name: "David Lee" → "Manager_Name 0001"
  • Department: "Sales West" → "Department 0001"
  • Job_Title: "Senior Account Manager" → "Job_Title 0001"
  • Review_Comments: "Exceeds expectations" → "Review_Comments 0001"
  • Employee_ID: "EMP-45678" → "Employee_ID 0001"

Review_ScoreやYears_of_Serviceなどの数値属性は分析用にそのまま保持。

インサイト: コンサルタントはレビューサイクル時間やプロセスの非効率性を分析し、従業員の完全な機密性とプライバシーを保持しながら改善提案が可能。

出力

匿名化エンリッチメントは既存のテキスト属性値をインプレースで変更し、属性構造やデータ型を維持しつつ機密情報を匿名識別子に置き換えます。匿名化はプロセスマイニング分析に不可欠なデータ関係性を維持する一貫したパターンに従います。

匿名化形式: 各属性内の一意の値は "[AttributeName] [4桁数字]" の形式で置き換えられます。数字は0001から順に割り当てられます。たとえば「Customer_Name」属性の最初の一意の値は「Customer_Name 0001」になり、2番目は「Customer_Name 0002」となります。

一貫性保証: 同じ元の値はすべてのケースやイベントで同じ匿名識別子に置き換えられます。この一貫性の維持はデータ関係性を保ち、意味のあるプロセス分析を可能にします。例えば「John Smith」が100の異なるケースに登場する場合、全てが同じ「Customer_Name 0001」に置き換えられます。

匿名化範囲: 特定の属性を選択しない場合、エンリッチメントはケーステーブルおよびイベントテーブルのすべてのテキスト(文字列)属性を自動的に匿名化します。ただし、以下は除外されます:

  • ケースID属性はケース識別のため保持
  • アクティビティ名はプロセスフローの可視化のため保持
  • 計算属性は元データを含まないためスキップ
  • 非表示属性はスキップ
  • 数値、日付、ブールなどの非テキスト属性は変更しない

不可逆性: mindzieStudio内では匿名化プロセスは不可逆です。適用後は匿名化されたデータセットから元の値を復元できません。元データを他目的で利用する可能性がある場合は、匿名化を適用する前に必ず元データのバックアップを保持してください。

パフォーマンス考慮: エンリッチメントは属性ごとにすべての一意の値をグループ化してから匿名化を適用するため、大規模データセットでも効率的に処理します。連番付与の方式により、予測可能で読みやすい形式を維持しつつ一意性を確保します。

他機能との統合: 匿名化された属性は元のデータ型を維持し、mindzieStudioのすべての機能(フィルター、プロセスマップ、他のエンリッチメントなど)で使用可能です。匿名識別子は元の値と同様にグループ化、準拠性チェック、パフォーマンス分析に利用でき、一貫した置換により匿名化後もプロセスのパターン、頻度、関係性の分析が可能です。

関連項目

  • Hide Attribute - データを変更せずに機密属性を完全に非表示にする
  • Hide Blank Attributes - 値が空の属性をデータセットから除去する
  • Group Attribute Values - 類似する属性値をカテゴリーにまとめる
  • Categorize Attribute Values - 属性の範囲から意味のあるカテゴリーを作成する
  • Trim Text - テキスト属性の先頭・末尾の空白を除去し整形する
  • Text Start - テキスト属性の先頭部分を抽出する
  • Text End - テキスト属性の末尾部分を抽出する

本ドキュメントはmindzieStudioプロセスマイニングプラットフォームの一部です。