仮名加工情報と匿名加工情報を生成AIのClaudeに渡す前の加工と残るリスク

氏名を消しただけでは、仮名加工情報にも匿名加工情報にもならない

顧客データをClaudeに分析させたいとき、氏名の列を消してから渡す運用はよく見かけます。ところが個人情報保護委員会のガイドライン(仮名加工情報・匿名加工情報編)は、この行為を仮名加工情報の作成とは扱いません。

ガイドラインの注記によると、安全管理措置の一環として氏名などの一部を削除(または置き換え)したうえで引き続き個人情報として取り扱う場合は、仮名加工情報を「作成するとき」に該当しません。統計情報や匿名加工情報を作るための加工も同様です。つまり、氏名を消しただけのデータは、法的にはまだ個人情報のままです。

仮名加工情報・匿名加工情報として扱うには、規則が定める加工基準に沿って作成する必要があります。この記事では両者の作成基準の違いを表にしたうえで、加工してからClaudeに渡す流れと、加工後にも残る再識別リスクを読み解きます。法的助言ではなく、ガイドラインの読み方の解説です。

仮名加工情報と匿名加工情報の違いは「照合」と「復元」

定義から見ると、違いは2点に絞れます。

• 仮名加工情報: 他の情報と照合しない限り特定の個人を識別できないように加工したもの
• 匿名加工情報: 特定の個人を識別できず、かつ元の個人情報を復元できないように加工したもの

仮名加工情報は、元データや対応表と突き合わせれば個人が分かる状態を許容します。匿名加工情報は、その突き合わせでも戻せないことを求めます。ただし匿名加工情報の要件も「あらゆる手法で特定できないよう技術的に全ての可能性を排除する」ことまでは求めていません。基準は、一般人や一般的な事業者の能力・手法で通常の方法では特定・復元できない状態です。

作成基準を並べると次のようになります。

仮名加工情報は3項目、匿名加工情報は5項目です。匿名加工情報の側にだけ、連結符号・特異な記述・データベース全体の性質への対処が入ります。復元不能まで求めるぶん、加工の範囲が広くなる構造です。

加工の具体例: 何を消し、何を置き換えるか

ガイドラインは加工の事例を挙げています。実務でよく使う3列を例にすると、次のとおりです。

• 氏名: 削除する
• 住所: 削除する、または「○○県△△市」に置き換える
• 生年月日: 削除する、または日を落として生年月に置き換える(匿名加工情報の事例には「生年」への置換も出てきます)

仮名加工情報の事例では、クレジットカード番号や、送金・決済機能のあるWebサービスのログインID・パスワードも削除の例に挙がっています。マイナンバー・旅券番号・免許証番号のような個人識別符号も、全部の削除(または復元できない置換)が必要です。

置き換えるときの条件は「元の記述等を復元できる規則性を有しない方法」であることです。ここに落とし穴があります。

仮IDのハッシュ化は、単純に掛けると規則性が残る

分析用に顧客IDを残したいとき、仮IDを付ける手はよく使われます。ガイドラインは、氏名や連絡先のような個人固有の記述に同じハッシュ関数を単純に掛けると、元の記述を復元できる規則性を持つ可能性があると注意しています。対策として例示されているのが、元の記述に乱数など他の記述を加えてからハッシュ関数を使う方法です。

匿名加工情報では、この先に別の制約があります。乱数とハッシュ関数の組み合わせや、氏名と仮IDの対応表を作成後も持ち続けると、同じ置換の再実行や照合で元の個人が分かってしまいます。ガイドラインは、匿名加工情報の作成後は対応表を破棄することを求めています。仮名加工情報では、対応表のような削除情報等を残せますが、安全管理措置の対象になります。

Claudeに渡すデータで、仮IDの対応表を手元に残したいなら仮名加工情報、残さず完全に切り離すなら匿名加工情報、という分岐です。

加工はローカルで済ませてから渡す

加工する前の生データは、Claudeに見せない運用が土台です。加工スクリプト自体はClaude Codeに書かせられますが、生データの中身を読ませる必要はありません。列名と型だけを伝えれば足ります。

Claude Codeには、特定のファイルを読み取らせない設定があります。Read のdenyルールでパスを指定すると、Claudeのファイルツールからの読み取りを止められます。

{
  "permissions": {
    "deny": [
      "Read(./data/raw/**)"
    ]
  }
}

公式ドキュメントには、このdenyルールの届く範囲に限りがあると書かれています。Claudeの組み込みファイルツールと、cat などBash内の認識済みコマンドは対象です。一方、PythonやNodeのスクリプトが自分でファイルを開く場合は対象外です。加工スクリプトをローカルで実行するぶんには問題になりませんが、「Claudeが生データを読めない」ことをOSレベルで保証したい場合は、サンドボックスの併用が必要になります。

加工スクリプトの依頼は、たとえば次のような形になります。

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 行と列名だけを表示

生成されたスクリプトが、上の基準を満たすかどうかは別問題です。たとえば氏名の列を消しても、自由記述メモに氏名が混じっていれば、ガイドラインの言う「他の記述等により、なお特定の個人を識別できる」状態が残ります。ガイドラインは氏名削除後に他の記述で識別できる場合、その記述も加工が必要と述べています。出力の先頭数行だけでなく、自由記述列に固有名詞が残っていないかを別の手段(正規表現や目視のサンプリング)で確認する工程を組み込むと、加工漏れを見つけやすくなります。

加工後にも残る再識別リスク

ガイドラインの基準どおりに加工しても、次のようなリスクは残ります。

• 特異な値: 「116歳」を「90歳以上」に置き換えるような処理が要る。症例数の極めて少ない病歴も同じ扱い
• 行動の蓄積: 購買履歴や位置情報のように反復する行動は、単体で識別できなくても、蓄積すると個人の行動習慣が分かる。ガイドラインは、位置情報から自宅・職場が推定できる場合の削除、購入者が極めて限られる商品の品番・色をカテゴリーに置き換える一般化、身長170cmのような突出値を「150cm以上」とするトップコーディングを例示している
• 自由記述: 氏名や社名が本文に混ざる。カラム単位の加工では拾えない
• 削除情報等の管理: 仮名加工情報を作った側が元データや対応表を持っていれば、仮名加工情報は自社にとって「他の情報と容易に照合でき、特定の個人が識別できる」状態にあり、個人情報に該当する

最後の点は見落としやすい部分です。仮名加工情報として外に出しても、手元に元データがある限り、自社の管理下では個人情報のまま扱います。反対に、仮名加工情報を受け取った側が元データも対応表も持たなければ、その情報は受け取った側にとって個人情報でない仮名加工情報になります。

識別行為の禁止: Claudeの出力を元データに戻すとき

仮名加工情報にも匿名加工情報にも、識別行為の禁止があります。本人を識別する目的で、加工した情報を他の情報と照合してはいけません。

仮名加工情報の識別行為に当たる事例は、元の個人情報との照合です。当たらない事例には、複数の仮名加工情報を組み合わせた統計情報の作成が挙がっています。

Claudeに加工済みの購買データを分析させ、顧客セグメントごとの傾向を出させる使い方は、統計的な分析です。ところがその結果を仮IDで元の顧客台帳に戻し、特定の顧客へ個別に連絡する運用は、本人への連絡等の禁止に触れる可能性があります。ガイドラインは仮名加工情報を用いた本人への連絡等も禁じているためです。分析の出口が集計なのか個人単位の施策なのかで、加工情報を使う設計そのものが変わります。

加工情報でも残る手続き: 利用目的・第三者提供・委託

加工しても手続きは残ります。ガイドラインが定める主な点は次のとおりです。

仮名加工情報を扱う場合:

• 元の利用目的が引き継がれ、その範囲を超えて扱う場合は利用目的の変更と公表が必要。仮名加工情報には利用目的の変更制限(法第17条第2項)が適用されず、関連性の範囲を超える変更も認められる
• 第三者提供は原則禁止。委託に伴う提供、事業承継、共同利用は第三者に当たらない
• 委託する場合は、委託先に「提供する情報が仮名加工情報である」ことを明示する必要がある
• 漏えい等の報告(法第26条)や本人からの開示請求は仮名加工情報には適用されない。ただし元データや対応表には適用される

匿名加工情報を扱う場合:

• 作成後、遅滞なく、含まれる個人に関する情報の項目を公表する
• 第三者に提供するときは、あらかじめ項目と提供方法を公表し、提供先に匿名加工情報である旨を明示する
• 加工方法等情報(削除した記述、加工の方法に関する情報のうち復元に使えるもの)の安全管理措置を講じる

ここで問いになるのが、Claudeへの入力が「第三者提供」に当たるかどうかです。この整理は、入力が委託の枠に収まるか、つまり応答を生成する目的の範囲内かで分かれます。契約や設定の確認は個人情報を含むプロンプト入力は第三者提供にあたるかに、注意喚起の全体像は個人情報保護委員会の生成AI注意喚起を、Claudeの契約・設定に対応づけるにまとめています。Claudeが海外事業者である点は越境移転の記事の論点です。

なお、統計情報は規制の対象外です。複数人の情報から共通項目を抽出して集計したデータは、特定の個人との対応関係が排斥されている限り、個人に関する情報に当たりません。集計表を作ってからClaudeに渡す設計にできれば、加工情報の論点自体を避けられます。

どの加工を選ぶか

用途別に、選び方の目安を表にします。

仮名加工情報の作成に伴う義務(削除情報等の安全管理措置、利用目的の公表など)は、社内分析だけでも生じます。匿名加工情報は加工が重いぶん、作成時の公表や加工方法等情報の管理が付きます。どちらを選んでも、作成や取扱いの体制は必要です。

よくある質問

仮IDを付けたデータは、匿名加工情報になるか

仮IDだけでは足りません。連結符号の置換に加え、特異な記述の削除やデータベースの性質を踏まえた追加措置が要ります。仮IDと元の情報の対応表が手元に残っていれば、匿名加工情報の要件を満たしません。

加工済みデータをClaudeに渡せば、契約や設定の確認は不要になるか

不要にはなりません。仮名加工情報を委託先に渡す場合は、仮名加工情報であることの明示が必要です。匿名加工情報も、第三者提供に当たる形なら公表と明示が要ります。加えて、入力先の契約・設定がどうなっているかは別に確認する項目です。

まとめ

氏名を消しただけのデータは個人情報のままで、仮名加工情報にも匿名加工情報にもなりません。仮名加工情報は3項目の基準で照合しない限り特定できない状態を、匿名加工情報は5項目の基準で復元もできない状態を作ります。

加工してからClaudeに渡す運用の実務は、生データをClaudeに見せず、ローカルで加工し、自由記述や特異値の残りを別の手段で確かめる流れです。加工しても、利用目的・委託先への明示・識別行為の禁止といった手続きは残ります。渡す前に、自分のデータが個人情報のまま扱う段階か、加工情報として扱える段階かを見極めておくことが、Claudeへの入力の整理の出発点になります。