PII 非識別化の本質——「誰か」は偽ってよい、「何が起きたか」は偽ってはならない
こんにちは！Qualitegプロダクト開発部です！
本日は、PII（ Personally Identifiable Information→個人情報）の非識別化に関する内容を解説いたします。
当社ではこれまで、高精度なPII検出技術やLLM利用時の段階的PIIマスキング、PII検出のテスト設計など、個人情報検出とAIセキュリティに関する技術解説をお届けしてきました。
現在、当社では、PII検出マスキング技術「PII-FIエンジン」と、それを活用したPIIのマスキング・非識別化サービス「PII-FI Scan」「PII-FI API」を開発・提供しています。
本記事では、「PIIを検出したあと、それをどう書き換えるか」の設計原則を、1つの例文を試金石にして、私たちが実際のプロダクトで採用している整理をご紹介します。
先にことわっておきますと、本記事でいう「非識別化(de-identification)」は、文書やログを安全に共有・分析するための技術的な加工(個人を特定できないように加工する処理)のお話です。
個人情報保護法上の「仮名加工情報」「匿名加工情報」に該当することを保証するものではありません（法律用語との関係は後半で触れます）。
非識別化は、何のためにやるのか
まず、そもそも論から始めましょう。
ログや文書を「そのまま」使えるなら、非識別化は必要ありません。
手元に原本があり、自分だけが見るなら、加工する理由がないからです。
非識別化が必要になるのは、
「データを誰かに渡して仕事を進めたいが、生のままでは渡せない」
その瞬間です。
たとえば、
- 分析業務を外部に委託したいが、顧客情報が混ざっている
- 障害解析のため、業務ログをLLMに読み込ませたい
- ログ一式をセキュリティベンダーに分析依頼したい
- PIIを含むファイル他社に送信する前に確認したい
- カルテ情報をAIに整理させたいがAIに入れる前にPIIをマスクしたい
データには「何が起きたか」と「それが誰のことか」が混ざっています。
分析や共有の価値を生むのは前者です。
一方で、本人の不利益（なりすまし、差別、風評など）につながるのは後者です。
つまり非識別化とは、
「出来事」を残して「誰か」を切り離す
技術です。
守られるのは、データに写っている本人だけではありません。
渡す側は漏えい事故の責任から守られ、受け取る側は「持っているだけでリスクになる情報」を預かるリスクと管理負担を減らせます。
試金石：「甲野太郎は高血圧です」
ここからが本題です。次の1文を非識別化することを考えます。
「甲野太郎は高血圧です」
さて、加工の仕方は1つではありません。
代表的な3パターンを比べてみましょう。
パターン1：名前だけを偽名にする
乙山次郎は高血圧です
「甲野太郎↔高血圧」という結びつきは切れました。
読み手には「誰かが高血圧である」という出来事だけが伝わります。そしてこの出来事はまだ真実であり、使えます。症例の内容や対応の妥当性を検討する読み手にとって、この文は材料として機能し続けます。
これが非識別化の基本形です。ただし、ここで成功したのは「この一文の中の結びつきを切ること」だけです。実際の文書では、名前を変えても残りの文脈から本人が推測されることがあります——この限界は落とし穴3で正面から扱います。
パターン2：病名まで偽物にする
乙山次郎は花粉症です
一見、より安全になったように見えます。
しかし、この加工には重大な問題があります。
読み手には「花粉症」が偽物だと見分ける手段がありません。
症例を集計する人も、対応の妥当性を検討する人も、
嘘の事実を材料に仕事をしてしまいます。
「隠す」は安全側の操作です。情報が減るだけで、嘘は増えません。
ところが「別の本物らしい値に差し替える」は、嘘の注入です。データに毒を混ぜる行為だと言ってもよいでしょう。
パターン3：全部伏せ字にする
■■■■は■■■です
はい、安全ではあります。
しかし「誰かが何かである」という情報量ゼロの文になり、データとしては死んでいます。これでは渡す意味そのものがなくなります。
原則：語には2種類ある
この比較は、次の原則に整理できます。
語には2種類ある。
「誰か」を指す語（識別子）——氏名、社員番号、電話番号、メールアドレス。これは自然な偽物に差し替えてよい。読み手はその真実性を消費せず、切るべきは「結びつき」だけだから。
「何が起きたか」を語る語（属性）——病名、金額、人事評価、出来事。これは残すか、正直に伏せるかの二択。偽物にしてはならない。読み手はその真実性で仕事をするから。
もっとも現実の語はこの2つに綺麗に分かれてくれません。
「経理部長」は属性であると同時に、組織の中では本人を指す手がかりです。
年齢や日時も、組み合わせれば「誰か」に近づきます（準識別子と呼ばれます）。だからこそ、判定の物差しは語の型ではなく役割です。
上のフローの問いが「その語は氏名か？」ではなく「読み手はその値が真実であることを使って仕事をするか？」なのは、このためです。
検出した型だけで機械的に方式を決めるのではなく、語が文書の中で果たしている役割と渡し先の用途を組み合わせて加工方式を決めます。
「正直に伏せる」とは、たとえば [病名1] のようなラベルへの置き換えです。
ポイントは連番にすることで、同じ病名にはいつも同じ番号を振ります（これを照応保持と呼んでいます）。
すると「この文書には2種類の病気の話が出てくる」という分析に必要な構造は残り、かつ読み手には「ここは伏せられた」と正直に伝わります。
また、二択の中間として「一般化」という手もあります。「47歳→40代」「詳細な住所→市区町村まで」のように、真実のまま解像度だけを下げる方法です。
嘘は注入せず、特定のリスクだけを下げられるため、識別子にも属性にも使える誠実な中間手です。
ということで、ここまでを、まとめますと、非識別化の方式はこんなふうに整理できます。
| 方式 | 例 | 使ってよい場面 |
|---|---|---|
| ダミー（偽名） | 甲野太郎 → 乙山次郎 | 識別子のみ。照応保持で文書構造を守る |
| ラベル置換 | 高血圧 → [病名1] | 属性を隠したいとき。正直かつ構造が残る |
| 一般化 | 47歳 → 40代 | 真実のまま解像度を下げたいとき |
| 伏せ字 | P@ssw0rd → ＊＊＊＊ | 認証情報など、存在ごと隠すべきもの |
| そのまま | — | 受け手の仕事に必要な、識別につながらない情報 |
さて、ここで一つ注意があります。
表の最後にあるパスワードやAPIキーのような認証情報は、PIIに該当するかどうかとは別に、「シークレット」として扱うべき情報です。
共有用ファイルの上では伏せ字にしますが、外部に漏れた可能性があるなら、伏せ字にして終わりではなく、失効・ローテーションというインシデント対応が別途必要になります。
逆に、
属性へのダミー適用（病名を別の病名に差し替える等）だけは、原則禁止
です。
もし本物らしい偽データが必要な場面があるとすれば、それは受け手が元データの事実性を利用しない用途、たとえばパーサのテスト、デモ、負荷試験、などです。
私たちはそれを非識別化とは呼ばず、「合成データ生成」という別の仕事として扱っています。
標準の世界では合成データの生成も非識別化手法の一つに数えられますが（NIST SP 800-188）、
「意味を保って渡すためのマスキング」と「本物らしい偽物を作る仕事」を同じ処理に混ぜない
これが私たちが採用している設計判断です。
なお、統計データベースの匿名化には、ノイズ付加（数値にランダムな誤差を加える）のように属性値をあえて変える標準技法もあります（ISO/IEC 20889）が、これは、集計したときの統計的性質を保ちながら個々のレコードの真の値を隠すための道具という位置づけです。
これを本記事が対象とする「人やツールがそのまま読む文書・ログ」に持ち込むと、上で述べた嘘の注入と同じ問題を起こします。
実務で踏みがちな、4つの落とし穴
では、実際にPII処理を設計するときの注意点をみていきましょう。
PII処理アプリケーションなどを実装するときに、リアルに出会う4つの課題をご紹介いたします。
1. ファイルをまたぐと、同一人物が別人になる
やみくもに非識別化をしていくと、同一人物のことを複数の人物に変換してしまう場合があります。同一人物は、非識別化したあとも同一人物として追跡できるべきです。これを照応保持といいます。
たとえば、複数のログにある人物名を非識別化することを考えてみましょう。
照応保持を「1ファイルの中」だけで行うと、ログ一式を処理したときにファイルAでは「甲野→乙山」、ファイルBでは「甲野→丙川」になり得ます。
これでは複数ログを横断して関係者の動きを追う分析が壊れてしまいます。
そのため、こういった課題に対処するには、
一式（ジョブ）単位の照応保持
が必要です。
ただし逆の顔もあります。
照応の範囲を広げるほど「同じ偽名の出現パターン＝元の人物の行動パターン」が残るため、特定の手がかりも増えます。そこで、一貫させる範囲は、用途に応じて選べるのがよいようにおもいます。
なお、この論点は人物の偽名に限らず、[病名1] のようなラベルの番号づけにも同じように当てはまります。
2. 偽名が実在の人とかぶる
生成した偽名「乙山次郎」が、たまたま文書に元々登場する本物の乙山さんと同姓同名だったら、分析が混乱するだけでなく、その実在の方に濡れ衣を着せかねません。
この課題には、
文書内に実在する値は、ダミーの候補から除外する
仕組みが要ります。
ただし、自然な人名は「実在しないこと」までは保証できません。誤帰属のリスクを取れない渡し先では、偽名ではなく [人物1] のようなラベルを選ぶ、これも後述する「渡し先」の判断です。
さらに機械的な値については、「実在しえない値」を生成するのが定石です。
ダミーのメールアドレスは予約ドメイン（example.com）、IPアドレスは文書用に予約されたテスト専用領域（192.0.2.0/24 など）、各種番号はチェックデジットが合わない値にしておけば、うっかり連絡や照会をしても誰にも届きません。
3. 非識別化しても「誰か分かる」ことは消せない
氏名や番号をすべて消しても、「経理部の部長が7月3日に処分を受けた」という文脈だけで、社内の人には誰のことか分かります。これはメールに含まれるPIIを非識別化するときによく怒ります。
非識別化は魔法ではなく、特定のリスクを下げる技術です。
そういう意味では、「加工済み＝完全に安全」という思い込みが、いちばんの落とし穴かもしれません。
なお、「仮名加工情報」「匿名加工情報」は個人情報保護法上の定義と要件を持つ法律用語です。
技術的な加工を指す言葉としては、本記事のように「非識別化」「マスキング」と呼ぶのが安全だと私たちは考えています。
4. 加工したファイルは「改変された文書」である
インシデント対応の提出物は、のちに監査や法的手続きの材料になることがあります。
非識別化ファイルは原本ではないので、
「いつ・どんなルールで・何を何件加工したか」と原本のハッシュ値を記録した処理証跡
を成果物に添えることで、原本との関係を第三者に示せるようにしておくべきです。証跡は単なる注意書きではなく、改変の透明性を担保する監査文書です。
正解は「型」ではなく「渡し先」が決める
さて、次の論点に移りましょう。
PII処理において、何を優先させるか、です。
自然さ（分析ツールが壊れない）・安全さ・正直さ（偽物と分かる）の3つは、同時には最大化できません。
どれを優先するかは、そのデータがどこへ行くかで決まります。
- 人が読む提出物 → 正直さ優先。ラベル置換中心＋処理証跡
- ツールで解析するログ → 書式・桁の保持優先。実在しえない値のダミー中心
- LLMに入れるデータ → 自然さ優先。ダミー中心（LLMの応答からの復元と対にする設計もあります）
ちなみに、LLM向けは入力時の置換だけでは完結しません。
置換の対応表はLLMには送らず、手元の信頼境界の内側で管理する。
復元は自由文の文字列一致ではなく管理されたトークンに限定する。
そしてLLMの応答には入力になかったPIIが現れることもあるため、出力側にも再度PII検査をかける。ここまでがワンセットです。
つまり非識別化の設定とは「型ごとの好み」ではなく、
「誰に、何のために渡すか」という宣言
なのです。
私たちのPII-FIでは、この宣言を「渡し先ごとのプロファイル」として設計しています。
まとめ
さて、今回は、非識別化の本質は何か、について私たちの考え方やPII処理の設計課題について具体的に示しながらご紹介してまいりました。
ここで、再度、本記事の要点を整理いたします。
- 非識別化は「渡す」ための技術。「出来事」を残して「誰か」を切り離す
- 語には2種類ある。識別子は偽名にしてよい。属性は「残す・正直に伏せる・一般化」の三択で、偽物にしてはならない
- 属性への偽データ注入は「嘘の注入」。それが許されるのは合成データ生成という別の仕事
- 実務では、ファイル横断の照応保持・偽名の実在衝突・残存する特定リスク・処理証跡の4点に要注意
- 最終的な正解は型ではなく「誰に何のために渡すか」が決める
今回の記事はいかがでしたでしょうか。PII処理の考え方に関して、何かお役にたてましたら幸いです。
当社 株式会社Qualitegでは、本記事の設計思想に基づく高速高精度PII検出・マスキングソリューションとしてログや文書の一式をドラッグ&ドロップで非識別化できるサービス「PII-FI Scan」や、その技術をAPIから使える「PII-FI API」を開発・提供中です。
もし、PII-FIの検出やマスキング、非識別化ご興味ございましたら、お気軽にお問い合わせフォームよりご連絡くださいませ。
それでは、また次回お会いしましょう！
参考（業界標準・ガイドライン）
本記事の整理は、非識別化に関する以下の標準・ガイドラインの考え方と整合しています。あわせてご参照ください。
- NIST IR 8053: De-Identification of Personal Information — 非識別化と再識別に関する研究・実務を幅広く整理した米国NISTの報告書。構造化データに限らず、自由記述や画像も対象とする
- NIST SP 800-188: De-Identifying Government Datasets — 政府データセットを対象とした非識別化の実務ガイド（2023年最終版）。準識別子の変換・合成データ・再識別リスク評価・ガバナンスまで扱う
- ISO/IEC 20889:2018 — 非識別化技法の用語と分類の国際規格。仮名化・一般化・抑制（削除/マスキング）・ノイズ付加などを体系化
- ENISA: Pseudonymisation Techniques and Best Practices — EUサイバーセキュリティ機関による仮名化の実践ガイド。一貫した偽名（照応保持）の有用性と再識別リスクのトレードオフを詳述
- 個人情報保護委員会: 個人情報の保護に関する法律についてのガイドライン（仮名加工情報・匿名加工情報編） — 日本法における「仮名加工情報」「匿名加工情報」の定義・要件・義務
