データ匿名化を準備し、再識別リスクを確認する方法。
明白な識別子を削除しても匿名性は保証されません。個人を特定できる可能性が残るフィールドの組み合わせや珍しい値を確認してください。
作業手順をタスクに合わせましょう。
直接識別子、珍しい組み合わせ、身元を明らかにしうる自由記述を特定します。公開目的を合意し、それに応じてフィールドを削除、一般化、置換してください。再識別キーがあれば別に保管し、結果を自動的に匿名と呼ばず、残存リスクを説明します。
- 用意するもの
- 提供された小規模データセットと選択したマスキング方針。
- 得られるもの
- マスキング済みまたは合成の代替値と残存リスクの注記。
入力と結果を確認しましょう。
説明用の入力と出力 · 実際の WebAct 実行ではない学習用サンプル
入力項目サンプル個
Fictional internal table: name Alex Example; email alex@example.com; role "sole night-shift laboratory coordinator". Prepare a public summary requiring only a broad job family.
完成例
Public-summary draft: job_family: operations Removed: name, email and unique role wording. No stable person ID is needed for this purpose. A single-record summary could still be identifying through context; this transformation is not an anonymity certification.
この入力をプロンプトに読み込み、WebAct にコピーして試してください。結果は掲載例と異なる場合があります。
判断のポイントとトラブル対処。
名前をランダムな IDs に置き換えるとデータセットは匿名になりますか？
レコードを仮名化するだけにとどまる場合があります。他のフィールドや保管した対応表により、依然として個人に結び付けられる可能性があります。
メールアドレスを削除しても個人を認識できるのはなぜですか？
固有の役職、日付、場所、記述の詳細は、組み合わせると個人を特定しうります。レコード全体と想定する閲覧者を確認してください。
自分の資料で試しましょう。
タスクのプロンプト内の例を自分の資料に置き換えてください。必要な要件を残し、タスクを WebAct にコピーします。
タスクを調整してコピー ↑