コンテンツにスキップ

case01(仮名加工情報): 情報特性の評価 — 3/7

加工方針を決める前の下ごしらえ。順序が大事です。まず ① 委員会規則(施行規則第31条=仮名加工情報の作成基準)で「必ず削除・置換する項目」を確定し、その上で ② 情報特性の観点から、自主的に(予防的に)どこまで加工するかを考えます。用語は 用語集 を参照。

見るポイント① 委員会規則(施行規則第31条)— まず必須の加工を確定する

仮名加工情報では、次のいずれかに当たる記述等は、情報特性に関わらず削除(置換)が規則で必須です(施行規則第31条=仮名加工情報の作成基準)。まずここを満たします。

  • 第1号: 特定の個人を識別できる記述等(例: 氏名)
  • 第2号: 個人識別符号(例: マイナンバー、生体データ)— 本事例には該当なし
  • 第3号: 不正に利用されると財産的被害が生じるおそれのある記述等(例: クレジットカード番号)

「特定できる」から必須なのではない — クレジットカード番号の例

クレジットカード番号は、それだけでは「誰か」は分かりません(単体での識別性は低い)。しかし不正に利用されると財産的被害が生じるおそれがあるため、第31条第3号により削除が必須です。「識別できるから削除」ではなく「財産的被害のおそれだから削除」——必須になる理由が情報特性とは違う点に注意してください。

見るポイント② 情報特性(誰が特定されうるか)— その上で自主的に判断する

①で必須の項目を落としたうえで、残りの項目を情報特性の観点で見て、予防的に(自主的に)加工するか・どの粒度まで粗くするかを、分析上の必要性と合わせて判断します。

  • 直接識別子: 単体で個人を特定できる(例: 氏名)。
  • 準識別子: 単体では特定できないが、組合せで特定につながりうる(例: 生年月日+性別+住所)。
  • 本人到達性: その情報で本人に連絡・到達できる(例: メール・電話)。単体では「誰か」までは分からないことが多い。
  • 結合キー性: テーブル・履歴の結合に必要(例: 会員ID)。
  • 機微度: 特定された場合のプライバシー影響の大きさ(加工設計の補助指標)。

(情報特性の見立ては、①の当てはめ——たとえば「そのメールアドレスは氏名等を含み識別できるか(第1号)」——の判断にも使います。)

チェック結果(項目別)

① 第31条の該当(規則で必須) を先に確定し、② 情報特性 を突き合わせます。第31条に当たる項目(上の3行)は、分析に使いたくても削除(置換)が必須。それ以外は情報特性から、分析上の必要性と合わせて加工方針を判断します(次ページ)。

項目 第31条の該当(規則で必須) 情報特性の分類 単体での識別性 結合キー 機微度
氏名 第1号 直接識別子 高 ― 中
電子メールアドレス 第1号(識別できる場合) 本人到達性 中(氏名等を含めば高) ― 中
クレジットカード番号 第3号 財産的被害のおそれ 低 ― 高
会員ID ― 内部管理識別子 低 ○ 低
生年月日 ― 準識別子 低(組合せで高) ― 中
性別 ― 準識別子 低 ― 低
郵便番号 ― 準識別子 低 ― 低
住所 ― 準識別子 低(組合せで高) ― 中
携帯電話番号 ― 本人到達性 低 ― 中
Cookie ID ―(個人識別符号ではない) オンライン識別子 低 ○ 中
購入年月日・品目・数量・金額 ― 行動・履歴 低 ― 低
アクセス日時・閲覧カテゴリ ― 行動・履歴 低 ― 低

チェック結果のまとめ: まず第31条で必須の 氏名(第1号)/電子メールアドレス(第1号・識別できる場合)/クレジットカード番号(第3号) を確定します(個人識別符号=第2号は本事例に該当なし)。その上で、残りの項目を準識別子・本人到達性・結合キー性から見て、自主的に(予防的に)加工方針を判断します。

→ この「① 規則で必須 → ② 情報特性から自主的に判断」の評価を、次の 加工の設計 で「分析にどれだけ必要か・どの粒度が要るか」と突き合わせて決めます。