個人情報保護委員会事務局レポート「仮名加工情報・匿名加工情報 ―事例編―」事例1 を参考にした、仮想の事例（デモ）
データはすべて教材用の合成データです。
加工コードそのものではなく、
このスライドは①〜③を通しでたどります。実際に手を動かすところは Colab へ。
どんな会社が、どんなデータを持っていて、何のために加工したいのか。 ここが分かると、以降の加工判断の理由がつかめます。
食品のオンライン通販事業者A が、首都圏で 実店舗の出店 を計画している。
「ある地域で、どんな顧客層（年代・性別）が、どんな商品に関心を持つか」を分析して、出店計画に活かしたい。
加工後の利用目的: 各地域の顧客の興味・ニーズの傾向を分析し、実店舗事業の計画を行う
他の情報と照合しない限り、特定の個人を識別できないように加工した情報。 氏名などは消すが、個人単位の分析は残せるのが特徴。
「同じ人が、いつ・どこで・何を買ったか」を 個人単位でまとめて見たい。
→ だから 仮名加工情報 を選ぶ。
「どう加工するか」より先に、利用目的が何を要求しているかを決める。加工方針はそこから逆算する。
「必要粒度」を先に言語化しておくと、後の加工設計で どこまで粗くしてよいか が機械的に決まります。
次のステップで、これらを 3つのテーブル に整理します。
加工する「前」のデータが、どんな表と項目でできているか。 まず全体像をつかみます。
customers
purchases
web_access
customers 1 : N purchases ／ customers 1 : N web_access。 結合キーは会員ID。ここをどう扱うかが、この事例の設計の要になります。
M
P
A
customers（先頭3行・すべて合成データ）
この中に、そのままでは個人が特定できる／連絡できてしまう項目（氏名・住所・電話・メール）と、 単体では特定できないが不正利用で財産的被害のおそれがある項目（カード番号）が混在しています。
加工方針を決める前の下ごしらえ。 ここは 順序が大事 です。
「必ず削除・置換する項目」を確定する。 情報特性に関わらず必須。分析に使いたくても外せない。
自主的に（予防的に）どこまで加工するかを、分析上の必要性と合わせて判断する。
「危なそうな順に消していく」ではなく、法令で決まっている必須項目を先に固定し、残りを設計判断で詰める。 この順序にすると、加工の根拠が「規則で必須」か「自主的」かをいつでも説明できます。
次のいずれかに当たる記述等は、情報特性に関わらず削除（置換）が必須。
まずここを満たすことが出発点になります。
クレジットカード番号は、それだけでは「誰か」は分かりません（単体での識別性は低い）。 しかし 不正に利用されると財産的被害が生じるおそれ があるため、第31条第3号により削除が必須です。
必須になる理由が、情報特性（識別性）とは別の軸にある点に注意。 だから「① 規則 → ② 情報特性」の順で見る必要があります。
情報特性の見立ては、①の当てはめ（例: そのメールアドレスは氏名等を含み識別できるか＝第1号）の判断にも使います。
カード番号は 識別性「低」なのに必須。表を眺めると、識別性の高さと必須かどうかが一致しないことが一目で分かります。
これらは 自主的に（予防的に）加工方針を判断する対象。次のステップで「分析にどれだけ必要か」と突き合わせます。
各項目を「削除する／置き換える／粗くする／そのまま残す」のどれにするか。 そして、その理由。
置換 意味のない番号などに置き換える
一般化 必要な粗さまで粗くする
削除 列ごと落とす
加工なし 分析に必要なのでそのまま
識別性 × 機微度 × 利用目的上の必要性 × 必要粒度
分析に要らず特定につながる項目は削る。特定はしたくないが分析には要る項目は、必要な粗さまで一般化して残す。個人単位の履歴は整理番号でつなぐ。
削除した項目は加工後データに残りません。「加工なし」は前後で同じ＝分析に必要なので手を付けません。
整理番号は会員IDを振り直しただけ。しかも対応表を持っていれば元に戻せるのでは？
ポイントは3つです。
加工の要否は ① 分析に必要か（設計判断）× ② 加工の根拠 で決まります。
規則で必須（法令）
施行規則第31条＝仮名加工情報の作成基準。
自主的（予防的）
必須とまでは言い切れないが、識別リスクを下げるために行う加工。 解釈によっては「そこまで不要」ともいえるもの。
設計の方針を、具体的な処理（どの列をどう変換するか）に落とし込みます。
基準日で年齢を算出し、一次情報（図表1-3）にならい「10代」「20代」…「70代」「80代以上」に区分（80歳以上は「80代以上」にまとめる）。 年齢 = 基準日の年 − 生年（基準日時点で算出）。
「都道府県 + 市区町村」まで残し、丁目・番地以降を削除。政令市は「◯◯市◯◯区」まで（例: 横浜市青葉区）。
会員IDと1対1で対応する整理番号（例: R000001）を付与し、顧客・購買・アクセスの3テーブルで同じ整理番号を使って個人単位の履歴結合を維持。元の会員IDは削除する。
R000001
設計どおりに動くコードを、Google Colaboratory で実行します。
notebooks/case01_pseudonymized.ipynb
加工前後を比べ、目的の分析が成立するかを確かめます。
R
直接識別子・本人到達性のある項目は全削除。 履歴情報は整理番号で個人単位の結合を維持しつつ、分析に必要な項目をそのまま保持します。
年代別 平均購入金額（円）
年代が上がるほど高い傾向
市区町村別 平均購入金額（上位3・円）
年代別 購入品目トップ3
→ 市区町村単位・年代単位で傾向を読み取れる＝出店計画の検討という利用目的が、加工後も達成できる。
削除・置換・一般化・維持 を、項目ごとに 「識別性 × 機微度 × 利用目的上の必要性 × 必要粒度」で判断する。
整理番号で「誰か」は分からなくても「同じ人の履歴」はたどれる状態を作る。 ただし ① 対応表の分離 ／ ② 識別行為の禁止 とセットで意味を持つ。
加工後も、地域 × 年代 × 性別の傾向分析（出店計画の目的）は成立する。
① 規則で必須の項目を確定 → ② 情報特性から自主的に判断。 この順で考えると、加工の根拠を常に説明できます。
同じ「思考プロセス」を、より厳しい基準の加工で。
出典: 個人情報保護委員会事務局レポート「仮名加工情報・匿名加工情報 ―事例編―」1.1 事例1 サイト: https://gghatano.github.io/pets-seminar-01/ ライセンス: 教材コンテンツ CC BY 4.0 ／ コード MIT