仮名加工情報と匿名加工情報を生成AIのClaudeに渡す前の加工と残るリスク
顧客データをClaudeに分析させる前の加工で、仮名加工情報と匿名加工情報は何が違うのか。個人情報保護委員会ガイドラインの作成基準と、加工後にも残る再識別リスクを読み解きます。
氏名を消しただけでは、仮名加工情報にも匿名加工情報にもならない
顧客データをClaudeに分析させたいとき、氏名の列を消してから渡す運用はよく見かけます。ところが個人情報保護委員会のガイドライン(仮名加工情報・匿名加工情報編)は、この行為を仮名加工情報の作成とは扱いません。
ガイドラインの注記によると、安全管理措置の一環として氏名などの一部を削除(または置き換え)したうえで引き続き個人情報として取り扱う場合は、仮名加工情報を「作成するとき」に該当しません。統計情報や匿名加工情報を作るための加工も同様です。つまり、氏名を消しただけのデータは、法的にはまだ個人情報のままです。
仮名加工情報・匿名加工情報として扱うには、規則が定める加工基準に沿って作成する必要があります。この記事では両者の作成基準の違いを表にしたうえで、加工してからClaudeに渡す流れと、加工後にも残る再識別リスクを読み解きます。法的助言ではなく、ガイドラインの読み方の解説です。
仮名加工情報と匿名加工情報の違いは「照合」と「復元」
定義から見ると、違いは2点に絞れます。
- 仮名加工情報: 他の情報と照合しない限り特定の個人を識別できないように加工したもの
- 匿名加工情報: 特定の個人を識別できず、かつ元の個人情報を復元できないように加工したもの
仮名加工情報は、元データや対応表と突き合わせれば個人が分かる状態を許容します。匿名加工情報は、その突き合わせでも戻せないことを求めます。ただし匿名加工情報の要件も「あらゆる手法で特定できないよう技術的に全ての可能性を排除する」ことまでは求めていません。基準は、一般人や一般的な事業者の能力・手法で通常の方法では特定・復元できない状態です。
作成基準を並べると次のようになります。
| 加工の内容 | 仮名加工情報(規則第31条) | 匿名加工情報(規則第34条) |
|---|---|---|
| 特定の個人を識別できる記述等の削除・置換 | 仮名加工情報(規則第31条)必要 | 匿名加工情報(規則第34条)必要 |
| 個人識別符号の全部の削除・置換 | 仮名加工情報(規則第31条)必要 | 匿名加工情報(規則第34条)必要 |
| 財産的被害のおそれがある記述等の削除 | 仮名加工情報(規則第31条)必要(カード番号など) | 匿名加工情報(規則第34条)明記なし |
| 情報を相互に連結する符号の削除 | 仮名加工情報(規則第31条)明記なし | 匿名加工情報(規則第34条)必要 |
| 特異な記述等の削除 | 仮名加工情報(規則第31条)明記なし | 匿名加工情報(規則第34条)必要 |
| データベースの性質を踏まえた追加措置 | 仮名加工情報(規則第31条)明記なし | 匿名加工情報(規則第34条)必要 |
仮名加工情報は3項目、匿名加工情報は5項目です。匿名加工情報の側にだけ、連結符号・特異な記述・データベース全体の性質への対処が入ります。復元不能まで求めるぶん、加工の範囲が広くなる構造です。
加工の具体例: 何を消し、何を置き換えるか
ガイドラインは加工の事例を挙げています。実務でよく使う3列を例にすると、次のとおりです。
- 氏名: 削除する
- 住所: 削除する、または「○○県△△市」に置き換える
- 生年月日: 削除する、または日を落として生年月に置き換える(匿名加工情報の事例には「生年」への置換も出てきます)
仮名加工情報の事例では、クレジットカード番号や、送金・決済機能のあるWebサービスのログインID・パスワードも削除の例に挙がっています。マイナンバー・旅券番号・免許証番号のような個人識別符号も、全部の削除(または復元できない置換)が必要です。
置き換えるときの条件は「元の記述等を復元できる規則性を有しない方法」であることです。ここに落とし穴があります。
削除と一般化のほかにも、ガイドラインの別表には匿名加工情報の加工手法の例が並びます。
- 項目削除・レコード削除・セル削除: 年齢の列ごと、特定の人の行ごと、特定のセルだけ、のいずれかを消す
- 一般化: 「きゅうり」を「野菜」にする、数値を四捨五入で丸める
- トップ(ボトム)コーディング: 80歳以上を「80歳以上」にまとめる
- ミクロアグリゲーション: グループ化して、グループの代表値に置き換える
- データ交換(スワップ)・ノイズ付加・疑似データ生成: 記述を確率的に入れ替える、乱数的な数値を足す、人工的な合成データを混ぜる
この別表には、一般的な手法の例示であり、他の手法を用いることを妨げるものではないという注記が付いています。
仮IDのハッシュ化は、単純に掛けると規則性が残る
分析用に顧客IDを残したいとき、仮IDを付ける手はよく使われます。ガイドラインは、氏名や連絡先のような個人固有の記述に同じハッシュ関数を単純に掛けると、元の記述を復元できる規則性を持つ可能性があると注意しています。対策として例示されているのが、元の記述に乱数など他の記述を加えてからハッシュ関数を使う方法です。
「規則性が残る」とはどういう状態か、ダミーの会員ID(M と6桁の数字、全100万通り)で試しました。M048213 の素のSHA-256を求め、M000000 から順に同じ関数を掛けて突き合わせる総当たりです。
python3 demo.pyplain sha256: b3bba6837ef07067 ...
recovered: M048213 after 48214 tries, 0.03 sec
hmac: 18b456b88a6f4150 ...
plain-sha256 enumeration against hmac value: None 0.64 sec素のSHA-256は、48,214回目の試行で0.03秒のうちに元のIDへ戻りました。後半は、ランダムな32バイトの鍵を使ったHMAC-SHA256の値に同じ総当たりを向けた結果で、100万通りを0.64秒で調べても一致は出ていません。鍵なしでは照合できない、という性質を持つ作り方です。ただし鍵や乱数を持ち続ける限り、同じ置き換えを再実行できる点は変わりません。
匿名加工情報では、この先に別の制約があります。乱数とハッシュ関数の組み合わせや、氏名と仮IDの対応表を作成後も持ち続けると、同じ置換の再実行や照合で元の個人が分かってしまうためです。ガイドラインは、匿名加工情報の作成後に対応表と、置き換えに使った乱数等のパラメータを破棄するよう求めています。
仮名加工情報では、これらを「削除情報等」として残せます。その代わり、取扱者の権限と責任の明確化、取扱規程の整備と評価、権限のない者の取扱いを防ぐ措置という3点の安全管理措置(規則第32条)が掛かります。対応表のような削除情報等が漏えいした場合は、原則として仮IDを振り直し、仮名加工情報を作り直す措置が必要になる、とも書かれています。匿名加工情報側の同じ位置付けの情報は「加工方法等情報」で、規則第35条が3点の同じ構成の措置を定めます。
Claudeに渡すデータで、対応表や鍵を手元に残したいなら仮名加工情報、残さず完全に切り離すなら匿名加工情報、という分岐です。下の依頼例にある環境変数のsaltも、このパラメータに当たります。
加工はローカルで済ませてから渡す
加工する前の生データは、Claudeに見せない運用が土台です。加工スクリプト自体はClaude Codeに書かせられますが、生データの中身を読ませる必要はありません。列名と型だけを伝えれば足ります。
生データに触れさせずに加工する流れ
- 1
生データの置き場を決めて読み取りを止める
data/raw/のように生データだけを置くディレクトリを作り、そこへのReadのdenyルールを書きます。 - 2
列定義だけでスクリプトを書かせる
列名・型・加工ルールを文章で伝えます。データ本体は貼りません。
- 3
ローカルで実行して別ディレクトリへ出力する
出力先は
data/processed/のようにdenyの外に置きます。 - 4
残りを別の手段で点検してから渡す
自由記述の固有名詞と特異値を確認し、問題がなければ加工後のファイルだけを渡します。
Claude Codeには、特定のファイルを読み取らせない設定があります。Read のdenyルールでパスを指定すると、Claudeのファイルツールからの読み取りを止められます。
{
"permissions": {
"deny": [
"Read(./data/raw/**)"
]
}
}公式ドキュメントには、このdenyルールの届く範囲に限りがあると書かれています。Claudeの組み込みファイルツールと、cat などBash内の認識済みコマンドは対象です。一方、PythonやNodeのスクリプトが自分でファイルを開く場合は対象外です。ファイル名を指定せずに読むコマンド(そのディレクトリで走らせる grep -r pattern . など)も対象外と書かれています。加工スクリプトをローカルで実行するぶんには問題になりませんが、「Claudeが生データを読めない」ことをOSレベルで保証したい場合は、サンドボックスの併用が必要になります。
もう一点、Read のdenyルールは同じパスへの編集と書き込み(新規ファイルの作成を含む)も止めます。編集はv2.1.208以降、書き込みはv2.1.228以降の挙動です。加工後のCSVを data/raw/ の下に出させると、Claudeが書けなくなります。出力先を分けるのはこのためです。
.claudeignoreを置いても生データは隠れない
.claudeignore というファイルを data/raw/ の近くに置いても、Claude Codeの読み取りは止まりません。公式のpermissionsページに、.claudeignore は効果がないので、中身を Read のdenyルールへ移すようにと書かれています。
除外したいパスは、上の settings.json の permissions.deny に書きます。パターンはgitignore形式が基本です。ただし先頭の / は設定ファイルのある場所からの相対パスになるなど、パスの起点の書き方はClaude Code独自のルールに従います。.env のような秘密情報のファイルも同じ方法で止められます。
加工スクリプトの依頼は、たとえば次のような形になります。
data/raw/customers.csv を読み、data/processed/ に加工済み CSV を出力する
Python スクリプトを作ってください。列は member_id, name, address,
birthday, gender, purchase_history(自由記述メモ含む)です。
データ本体は読まず、列定義だけで書いてください。
- name は削除
- address は市区町村まで、birthday は年のみに一般化
- member_id は環境変数の salt を加えた HMAC-SHA256 で仮ID化
- 完了後、出力の先頭 5 行と列名だけを表示生成されたスクリプトが、上の基準を満たすかどうかは別問題です。たとえば氏名の列を消しても、自由記述メモに氏名が混じっていれば、ガイドラインの言う「他の記述等により、なお特定の個人を識別できる」状態が残ります。ガイドラインは氏名削除後に他の記述で識別できる場合、その記述も加工が必要と述べています。出力の先頭数行を見るだけでは足りません。自由記述列に固有名詞が残っていないかを、正規表現や目視のサンプリングで確かめる工程を組み込むと、加工漏れを見つけやすくなります。
仮名加工情報については、取扱者が仮名加工情報だと一見して分かる状態にしておくことが望ましい、とガイドラインは述べています。識別行為や本人への連絡の禁止が課されているためです。出力ファイルの名前にそれを入れる方法があります。
加工後にも残る再識別リスク
ガイドラインの基準どおりに加工しても、次のようなリスクは残ります。医学系研究の計画書でも同じ論点が出るため、手順はClaudeで倫理審査の申請書を下書きするで扱っています。
- 特異な値: 「116歳」を「90歳以上」に置き換えるような処理が要る。症例数の極めて少ない病歴も同じ扱い
- 行動の蓄積: 購買履歴や位置情報のように反復する行動は、単体で識別できなくても、蓄積すると個人の行動習慣が分かる。ガイドラインは、位置情報から自宅・職場が推定できる場合の削除、購入者が極めて限られる商品の品番・色をカテゴリーに置き換える一般化、身長170cmのような突出値を「150cm以上」とするトップコーディングを例示している
- 自由記述: 氏名や社名が本文に混ざる。カラム単位の加工では拾えない
- 削除情報等の管理: 仮名加工情報を作った側が元データや対応表を持っていれば、仮名加工情報は自社にとって「他の情報と容易に照合でき、特定の個人が識別できる」状態にあり、個人情報に該当する
最後の点は見落としやすい部分です。仮名加工情報を委託先などへ渡しても、手元に元データや削除情報等がある限り、作成した側にとっては個人情報のままです。反対に、仮名加工情報の提供を受けた側が元データも削除情報等も持たなければ、その情報は受け取った側にとって個人情報でない仮名加工情報になります。
識別行為の禁止: Claudeの出力を元データに戻すとき
仮名加工情報にも匿名加工情報にも、識別行為の禁止があります。本人を識別する目的で、加工した情報を他の情報と照合してはいけません。
仮名加工情報の識別行為に当たる事例として、ガイドラインは次の2つを挙げています。
- 保有する個人情報と仮名加工情報で共通する記述等を選別し、照合すること
- 仮名加工情報を、作成の元になった個人情報と照合すること
当たらない事例は、複数の仮名加工情報を組み合わせた統計情報の作成と、気象情報や交通情報のような個人と関係のない情報と並べた統計的な分析です。「他の情報」に限定はなく、どんな技術で照合するかも問われません。
Claudeに加工済みの購買データを分析させ、顧客セグメントごとの傾向を出させる使い方は、統計的な分析です。ところが出力された顧客の仮IDを元の顧客台帳と突き合わせ、誰のことかを割り出す運用は、元の個人情報との照合に当たります。別に、仮名加工情報に含まれる連絡先を使って電話・郵便・メールなどで連絡する行為も、本人への連絡等の禁止で止められています。分析の出口が集計なのか個人単位の施策なのかで、加工情報を使う設計そのものが変わります。
加工情報でも残る手続き: 利用目的・第三者提供・委託
加工しても手続きは残ります。ガイドラインが定める主な点は次のとおりです。
仮名加工情報を扱う場合:
- 元の利用目的が引き継がれ、その範囲を超えて扱う場合は利用目的の変更と公表が必要。仮名加工情報には利用目的の変更制限(法第17条第2項)が適用されず、関連性の範囲を超える変更も認められる
- 第三者提供は原則禁止。委託に伴う提供、事業承継、共同利用は第三者に当たらない
- 委託する場合は、委託先に「提供する情報が仮名加工情報である」ことを明示する必要がある
- 漏えい等の報告(法第26条)や本人からの開示請求は仮名加工情報には適用されない。ただし元データや対応表には適用される
匿名加工情報を扱う場合:
- 作成後、遅滞なく、含まれる個人に関する情報の項目を公表する
- 第三者に提供するときは、あらかじめ項目と提供方法を公表し、提供先に匿名加工情報である旨を明示する
- 加工方法等情報(削除した記述、加工の方法に関する情報のうち復元に使えるもの)の安全管理措置を講じる
- 苦情の処理など、取扱いの適正を確保する自主的な措置を講じ、その内容を公表するよう努める(法第43条第6項)
ここで問いになるのが、Claudeへの入力が「第三者提供」に当たるかどうかです。この整理は、入力が委託の枠に収まるか、つまり応答を生成する目的の範囲内かで分かれます。契約や設定の確認は個人情報を含むプロンプト入力は第三者提供にあたるかに、注意喚起の全体像は個人情報保護委員会の生成AI注意喚起を、Claudeの契約・設定に対応づけるにまとめています。Claudeが海外事業者である点は越境移転の記事の論点です。
なお、統計情報は規制の対象外です。複数人の情報から共通項目を抽出して集計したデータは、特定の個人との対応関係が排斥されている限り、個人に関する情報に当たりません。集計表を作ってからClaudeに渡す設計にできれば、加工情報の論点自体を避けられます。
どの加工を選ぶか
用途別に、選び方の目安を表にします。
| 状況 | 向く加工 | 理由 |
|---|---|---|
| 個人に紐づけず、集計傾向だけ見たい | 向く加工統計情報(集計してから渡す) | 理由特定の個人との対応関係がなければ規制対象外 |
| 社内分析で顧客単位の履歴を追いたい | 向く加工仮名加工情報 | 理由仮IDで同一人物の履歴を連結できる。対応表は残せる |
| 対応表を持たず、社外にも出しうる | 向く加工匿名加工情報 | 理由復元不能まで加工する。作成時の公表が要る |
| 氏名列を消しただけ | 向く加工個人情報のまま | 理由加工基準を満たしていない |
仮名加工情報の作成に伴う義務(削除情報等の安全管理措置、利用目的の公表など)は、社内分析だけでも生じます。匿名加工情報は加工が重いぶん、作成時の公表や加工方法等情報の管理が付きます。どちらを選んでも、作成や取扱いの体制は必要です。
まとめ
先に問うのは、集計表で足りないかどうかです。足りるなら、加工情報の手続きは要りません。
顧客単位の履歴が要るなら仮名加工情報になりますが、委託先に渡しても、元データや対応表を持つ作成側では個人情報のままです。Claudeに渡す側の取扱いは、この前提で組むことになります。
参照した一次ソース
この記事の記述は、次の一次ソースと照合しています。更新時に参照先が変わった場合は一覧も更新します。