1 仮名化の概要
1.1 定義と目的
1.1.1 直接識別と間接識別の考え方
仮名化の対象となる情報は、個人をそのまま指し示す要素だけでなく、単独では人物名に直結しない場合でも、他の情報と組み合わさることで特定に近づく要素まで含み得る。前者は氏名や連絡先のような直接識別子に相当し、後者は属性や利用履歴などの間接識別子に当たる。仮名化は、置換後にこれらの結びつきが直ちに復元できない状態を目指す点に特徴がある。
1.1.2 プライバシーリスク低減の狙い
データ処理では、閲覧・分析・保存・共有の各段階で過度な開示が起きると、本人の権利や安心を損ねるおそれがある。仮名化は、元の情報へ即時に到達できない識別子へ置き換えることで、内部者の不正、外部流出、誤使用などの影響範囲を縮小する。さらに、分析に必要な粒度や一貫性を維持しつつ、リスクを管理可能な形に整理することが主目的となる。
1.2 匿名化との違い
1.2.1 再識別可能性の有無
匿名化は、通常の手段では個人が再特定できない水準を狙う概念として用いられることが多い。一方、仮名化では、対応関係を保持している限り再識別が「不可能ではない」。つまり、再特定の可能性をゼロにするよりも、再識別が成立する条件や運用上の障壁を設計し、統制する考え方が中心になる。
1.2.2 対応表の取り扱い
仮名化の要点は、置換の成否よりも対応表（元情報との対応情報）の所在と統制にある。対応表を厳格に隔離し、アクセス経路を絞り、鍵や権限の管理を徹底することで、再識別を現実的に困難にできる。結果として、仮名化の有効性は技術単体ではなく、管理プロセスの整合性で決まる。
1.3 関連用語と整理
1.3.1 識別子の置換
識別子の置換は、氏名や顧客番号のような値を、別の識別子へ置き換えることである。置換後もデータ同士の対応性を残す場合（同じ人が同じ仮名になるなど）と、関連性を意図的に弱める場合がある。どちらを採用するかは、分析要件とプライバシー要求のバランスで決める。
1.3.2 トークン化
トークン化は、識別子をトークン（代理値）へ変換する整理として用いられることがある。トークンは意味を持たないラベルとして扱われることが多いが、生成方法によっては再識別の可能性が変わる。たとえば、同一入力から同一出力が得られる設計か、毎回異なる出力になるかで、運用上のリスクと分析性が異なる。
1.3.3 擬似乱数化
擬似乱数化は、乱数に類似した性質を持つ値で置換し、第三者が元の識別子を推測しにくくする考え方である。乱数であっても、決定論的に再計算できる場合や、値の生成に秘密情報が用いられる場合には再識別の条件が変動する。したがって、擬似乱数化は鍵や乱数管理の性質と一体で理解する必要がある。
2 仮名化の方法
2.1 置換方式
2.1.1 局所的な対応表による置換
局所的な対応表による置換は、処理対象ごとに対応表を用意し、元の値を仮名へ置き換える方式である。たとえば同一データセット内では、一度作成した対応関係を保持して同じ人物の一貫性を確保する。一方で、対応表が増えると統制が複雑になり、破棄や移送の統一ルールが必要になる。
2.1.1.1 ワンウェイ運用の設計
ワンウェイ運用の設計では、仮名から元情報へ戻す経路を意図的に制限する。例えば、対応表を特定の業務ロールのみが参照できる形にし、返戻に厳しい条件を課す。また、再識別が必要な場面（誤配送の照会など）を想定しつつ、通常処理では戻さない運用にする。技術的には復元可能でも、手続き上は「必要時以外に戻せない」状態を作る点が核心となる。
2.1.2 決定論的置換と非決定論的置換
決定論的置換は、同じ入力に対して同じ仮名が得られる性質を持つ。分析では同一個体の追跡や集計がしやすい一方、外部と照合されるとリンク可能性が高まる。非決定論的置換は、入力に対して都度異なる値を生成しやすく、リンク性を弱められるが、時系列の追跡や横断集計の設計に工夫が要る。選択は目的と攻撃モデルの想定に依存する。
2.2 暗号学的方式
2.2.1 形式的暗号化（例：トークン生成）
形式的暗号化は、識別子を暗号学的な変換で置換し、仮名の生成手順を体系化する考え方である。実務では「暗号そのもの」よりも、トークン生成として実装されることが多い。鍵やアルゴリズムの種類、入力の正規化の有無によって挙動が変わり、同一人物の整合性確保と安全性の両立方法が定まる。
2.2.2 ハッシュ化とソルトの考え方
ハッシュ化は、入力から固定長の出力を生成する手法である。ソルトはハッシュ入力に追加する値で、同一入力でも出力の一致を崩しやすくする。これにより、辞書照合のような推測の負担を増やせる場合がある。ただし、ソルトの再利用、ソルトの秘匿性、入力の前処理が不適切だと、想定した防御効果が減るため、設計の前提を明確にする必要がある。
2.2.3 鍵管理と回転（ローテーション）
鍵管理は、暗号学的仮名化の実効性を左右する運用領域である。鍵へのアクセスを最小化し、保管場所、配布経路、変更手順を定めることが重要になる。鍵の回転（ローテーション）は安全性向上のために鍵を更新する施策であるが、回転により仮名の互換性が崩れる場合があるため、移行期間の設計や再仮名化の方針を事前に定める。
2.3 付随情報の扱い
2.3.1 マスキング
マスキングは、識別子そのもの以外の周辺項目に対して、閲覧や推測を難しくする加工を施す方法である。たとえば一部桁の欠落や形式維持による置換などが該当する。仮名化が識別子の結びつきを抑えるのに対し、マスキングはデータの「目印」を減らす役割を担うことが多い。
2.3.2 桁数・粒度の調整
桁数や粒度の調整は、情報の詳細度を下げて特定の精度を抑える考え方である。数値の丸め、時間の粗視化、空間の範囲化などが例として挙げられる。分析要件によっては粗視化が有用性を損ねるため、統計的影響を見積もったうえで最適な度合いを決める。
2.3.3 欠損化・一般化
欠損化は、特定の項目を意図的に欠落させることで識別の手がかりを減らす。一般化は、細かなカテゴリを広い区分にまとめ、個人の特徴が尖り過ぎないようにする。どちらも再識別の弱体化に寄与し得るが、データ品質と利用目的との整合が必要である。
3 運用設計とガバナンス
3.1 対応表（対応情報）の管理
3.1.1 保存場所と権限分離
対応表の保管場所は、仮名化全体の安全性に直結する。通常、仮名化データを扱う領域と、対応表へ到達できる領域を分離し、権限体系を階層化する。さらに、閲覧可能な職務と復元可能な職務を一致させない設計にすると、誤操作や逸脱の機会を抑えられる。
3.1.2 破棄・保管期間の方針
対応表は「必要な期間だけ保持し、不要になれば確実に破棄する」方針が基本となる。保管期間を延ばすと再識別の可能性が残り続けるため、利用目的との期限整合を取る。破棄は削除操作だけでは不十分になり得るため、バックアップやログを含む対象範囲を明確にする。
3.2 アクセス制御と監査
3.2.1 最小権限の原則
最小権限の原則は、業務に必要な範囲だけを付与する考え方である。復元を行う権限は特別な役割に限定し、通常の分析者には対応表が見えない状態を維持する。アクセスの承認フロー、変更申請、例外時の扱いを定めることで、運用上の抜けを減らせる。
3.2.2 監査ログと追跡可能性
監査ログは、誰がいつ何を参照したかを追跡できる形で残す仕組みである。復元に関する操作や対応表への照会が発生した場合、事後検証できることが重要になる。ログの改ざん耐性、保管期間、監査の頻度を定めることで、抑止効果と検知能力が高まる。
3.3 再識別リスク評価
3.3.1 統計的リスクの考え方
再識別の危険は、仮名化後のデータに残る特徴量の偏りや希少性に影響される。統計的な観点では、同一仮名に対応する人数が少ないほど結びつきが強まりやすい。分布の分散、欠損のされ方、カテゴリの細分度などを基に、再特定の見込みを評価する。
3.3.2 組合せ攻撃への備え
組合せ攻撃は、複数の属性や外部の公開情報を結び付けて個人を絞り込もうとする試みである。仮名化は単一の識別子を対象とすることが多いため、付随属性の扱いが甘いと成立し得る。したがって、攻撃が成り立つ条件（外部データの種類、結合キーの有無）を想定し、必要な抑制を講じる。
3.3.3 外部データ連携時の注意
外部連携では、相手側が持つ情報と自組織のデータの重なりが問題になる。連携前に、共通キーの存在、仮名の再利用方針、粒度の差、時間窓の一致などを確認する。連携先の統制能力や再識別への意図しない利用も考慮し、契約や技術的制限を含む対策を設計する。
4 実務での適用
4.1 利用シーン別の要点
4.1.1 研究・統計分析
研究や統計分析では、同一人物の追跡や分割後の再集計が必要になることがある。その場合、決定論的な置換や一貫性のある仮名設計が役立つ。一方で、希少属性が残ると個人が特定されやすくなるため、粒度調整や一般化と組み合わせてリスクを下げる判断が求められる。
4.1.2 業務システム連携
業務システムでは、参照頻度やリアルタイム性が要件に入り、仮名化の計算コストや復元の必要性が変わる。業務上の照会が発生するなら復元手順の明確化が欠かせない。加えて、連携先に渡す範囲を最小化し、再識別に至る情報が同梱されないようにデータ項目を見直す。
4.1.3 分析基盤への投入
分析基盤へ投入する際は、データの標準化、型の整合、欠損の取り扱いなどの前処理が重要になる。仮名化済みの識別子と、付随属性の加工度合いを統一しないと、後段の処理で一貫性が崩れる可能性がある。さらに、基盤側での権限管理や共有設定が過度にならないよう、投入時点でガードレールを敷く。
4.2 手続きの流れ
4.2.1 要件定義とデータ棚卸し
最初に、何のためにデータを使うか、誰が扱うか、どこへ渡るかを整理する。そのうえで、識別子になり得る項目、付随情報、ログやメタデータまで含めた棚卸しを行う。要件が曖昧なまま仮名化を進めると、分析に必要な機能が不足したり、逆にリスク低減が不十分になったりする。
4.2.2 仮名化手順の実装
実装では、置換方式、暗号学的変換、前処理（正規化、欠損処理）の手順を具体化する。対応表の生成と保存、鍵やソルトの扱い、再仮名化の方針も含めて運用を設計する。テストでは、同一入力の整合性、例外ケース、性能指標、失敗時の挙動を確認する。
4.2.3 検証と改善
導入後は、想定通りに結びつきが抑制されているかを点検する。利用者からの要望（分析性の不足）に対しては、対応表や付随情報の調整で再設計を検討する。監査ログのレビューやリスク評価の更新を通じ、運用の実態に合わせて改善を回す。
4.3 失敗例と対策（コツ集）
4.3.1 対応表の取り扱い漏れ
対応表を適切に隔離せず、一般用途の共有領域に置いてしまうと、仮名化の意味が失われる。対策として、保存先の統一、権限分離、持ち出し制御、操作手順のテンプレ化が挙げられる。例外運用を設ける場合は承認条件と記録を強化する。
4.3.2 ソルト漏えい・再利用の問題
ソルトや鍵が漏えいすると、推測耐性が大きく低下する場合がある。再利用の方針が不適切だと、同一人物のリンク可能性が高まり得る。対策として、秘密情報の保管手順、アクセス監視、回転計画、再仮名化の整合を事前に定めることが重要になる。
4.3.3 似た値による推測リスク
似た値が残ると、推測や照合の成功率が上がり得る。たとえば桁欠落のマスキングが弱い、粒度が高すぎる、カテゴリが狭すぎるといった状況が該当する。対策は、置換だけでなく付随属性の一般化や粒度調整を組み合わせ、必要以上に精密な特徴が残らないように設計することである。