PII（個人を特定できる情報）とは？読み方・piiデータの具体例と個人情報との違い

PIIは「ピーアイアイ」と読み、Personally Identifiable Information（個人を特定できる情報）の略です。氏名やマイナンバーのように単体で本人にたどり着く情報に加え、生年月日と郵便番号のように組み合わせると本人が絞り込める情報も含みます。piiデータは、こうした個人を識別できる情報を指す言い方で、意味はPIIと同じです。データベースやログに限らず、文書やメールに含まれる情報も対象になります。

注意したいのは、PIIが米国由来の実務用語で、日本の法律用語ではない点です。日本で義務がかかるのは個人情報保護法の「個人情報」で、電話番号やクレジットカード番号のように、PIIの解説では直接識別子として並ぶのに、日本法では単体だと個人情報になるとは限らないものがあります。この記事では、PIIの定義と具体例を押さえたうえで、日本法の区分への当てはめ、GDPRとの違い、日本語テキストからPIIを検出する実装までを扱います。

まとめ：PIIと個人情報の違いの要点

• 読み方と意味：ピーアイアイ。NIST SP 800-122 の定義では、個人を識別・追跡できる情報と、個人に結び付けられる（linked or linkable）情報の両方を含む。
• 日本の法律用語ではない：義務の範囲は個人情報保護法の「個人情報」「個人データ」「個人関連情報」で決まる。
• 電話番号・カード番号は個人識別符号ではない：個人情報保護委員会のQ&Aは、氏名などと容易に照合できるときに個人情報になると整理している。単体で個人情報になる番号は、マイナンバー・旅券番号・運転免許証番号など政令で列挙されたものだけ。
• GDPRでもオンライン識別子が対象になり得る：IPアドレスやCookie識別子の扱いは個人の識別可能性で判断する。NISTのPIIにもIPアドレス等が含まれ得るため、単純な広狭では比較できない。
• 日本語の検出は既定設定では足りない：Presidio 2.2.365 は日本向けの認識器を持たず、日本語の文に埋もれたメールアドレスを既定では検出できなかった。

PIIの意味と読み方：NIST SP 800-122の定義

本記事がPIIの定義の根拠とするのは、米国立標準技術研究所（NIST）の SP 800-122 （2010年4月公開）です。同文書は連邦機関が保有する個人に関する情報を対象に、PIIを(1)氏名・社会保障番号・生年月日と出生地・母親の旧姓・生体記録のように個人の身元を識別または追跡できる情報と、(2)医療・教育・金融・雇用の情報のように個人に結び付いている、または結び付けられる情報、の2つで定義しています。

ポイントは (2) です。単体では誰のことか分からない情報でも、本人に結び付けられる状態で持っていればPIIとして扱います。日本では総務省の国民のためのサイバーセキュリティサイトが「個人識別用情報」と訳し、氏名・性別・生年月日・連絡先・顔写真・身分証番号などを例に挙げたうえで、個人情報保護法の「個人情報」「個人データ」とは別の概念だと断っています。

PIIの具体例：直接識別子・準識別子・機微なPII

直接識別子：単体で本人にたどり着く情報

氏名、マイナンバー、旅券番号、運転免許証番号、指紋や顔の特徴データなどが該当します。1件の値だけで本人に結び付くため、漏えいするとなりすましや不正な名寄せに直結します。PIIの解説ではメールアドレスや電話番号もここに入れるのが一般的ですが、次章で見るとおり日本法の扱いは一段違います。

準識別子：組み合わせで本人を絞り込む情報

生年月日、郵便番号、性別、職業、勤務先などは、単体では多くの人に当てはまります。ところが掛け合わせると候補が急に減ります。ラタニヤ・スウィーニーの2000年の研究は、1990年の米国国勢調査をもとに、5桁の郵便番号・性別・生年月日の3項目で米国人口の約87%が一意に特定できる可能性があると推定しました。氏名を消しただけのデータを「匿名」と呼べない理由がここにあります。

機微なPII：漏えい時の被害が大きい情報

病歴、信条、犯罪の経歴、金融口座やクレジットカード番号などは、漏れたときの被害が差別や金銭被害に及ぶため、他のPIIより強い保護をかけます。同じ氏名の一覧でも、特定の病院の患者名簿であれば病歴を推知させるので機微度が上がります。機微度は項目そのものの性質と利用文脈の両方で判断します。NIST SP 800-122の3.2.3節・3.2.4節も、データ項目の機微性と利用文脈をそれぞれ評価要素に挙げています。

PIIと個人情報の違い：日本の個人情報保護法の区分への当てはめ

日本でpiiデータを扱うときは、PIIの分類ではなく個人情報保護法の区分で義務を判断します。代表的なPIIが日本法でどこに入るかを先に表にまとめます。

個人識別符号：単体で個人情報になる番号は政令で列挙

個人識別符号は、それだけで個人情報になる符号として施行令第1条が列挙したものに限られます。DNAの塩基配列・顔・虹彩・声紋・歩行の態様・静脈・指紋と掌紋を変換した符号（委員会規則の基準を満たすもの）、旅券番号、基礎年金番号、運転免許証番号、住民票コード、マイナンバーなどです。医療・介護保険の識別符号は、保険者番号・被保険者記号・番号の組合せ（記号がない場合は2つ）で判断します。

電話番号とクレジットカード番号はこの一覧に入っていません。個人情報保護委員会はQ&A1-25で、契約形態や運用実態が様々で、いかなる場合も特定の個人を識別できるとは限らないことを理由に挙げ、氏名などと容易に照合できる場合に個人情報になると答えています。顧客テーブルで氏名と同じ行に電話番号があれば、その電話番号は個人情報の一部です。

メールアドレス・苗字だけ・Cookieの扱い

メールアドレスはQ&A1-4で、[email protected] のようにユーザー名とドメイン名から本人が分かる場合は単体で個人情報になり、それ以外は他の情報と容易に照合できるかで決まる、と整理されています。苗字だけの情報も同じ考え方で、同姓の人が多数いる状態では通常それだけでは特定できませんが、社員名簿と照合できる社内データなら個人情報として扱います。

Cookie ID、IPアドレス、閲覧履歴のように、生存する個人に関する情報で、個人情報・仮名加工情報・匿名加工情報のいずれにも当たらないものは「個人関連情報」（第2条7項）です。これ自体に取得の制限はありませんが、提供先が個人データとして取得することが想定されるときは、本人の同意が得られていることを提供元が確認しなければなりません（第31条）。広告タグや外部ツールへの送信で問題になるのはこの場面です。

個人情報・個人データ・保有個人データの3段階

個人情報が検索できるように体系化されたデータベースに入ると「個人データ」になり（第16条3項）、安全管理措置・第三者提供の制限・漏えい報告の対象になります。さらに事業者が開示・訂正・利用停止などの権限を持つものが「保有個人データ」（第16条4項）で、本人からの開示請求などに応じる義務がかかります。piiデータを入れたテーブルは、ほとんどの場合この「個人データ」に当たります。条文ごとの義務は個人情報保護法とは？定義・事業者の4つの義務・罰則を条文番号で解説【2026年10月時点】で整理しています。

要配慮個人情報と特定個人情報：取得の段階から制限される区分

人種・信条・社会的身分・病歴・犯罪の経歴・犯罪被害の事実などを含む個人情報は要配慮個人情報（第2条3項）で、法令に基づく場合などを除き、取得そのものに本人の同意が要ります（第20条2項）。マイナンバーを含む個人情報は特定個人情報で、番号法により利用範囲が法令・条例で定める事務に限定され、本人の同意だけで範囲外の収集・保管が認められるわけではありません。利用対象には、社会保障・税・災害対策以外の行政事務も含まれます。

GDPR・CCPAの保護対象：オンライン識別子と世帯情報

GDPR：オンライン識別子も個人データになり得る

EUのGDPRは第4条1項で、識別された、または識別され得る自然人に関するあらゆる情報を個人データとし、識別子の例にオンライン識別子を挙げています。前文30は、IPアドレスやCookie識別子などが他の情報と組み合わさって個人の識別に使われ得ると述べています。日本法では個人関連情報にとどまるCookie IDでも、GDPRでは個人の識別に結び付く場合に個人データとなり得ます。GDPRの適用はEU居住者かどうかだけでなく、EU域内の拠点や、域内の人への商品・サービス提供、行動監視などの条件で判断します。適用範囲と日本企業の対応はGDPRとは？EU一般データ保護規則の対象となる個人データと日本企業の対応で解説しています。

CCPA/CPRA：世帯に結び付く情報も対象

米カリフォルニア州のCCPA（CPRAで改正）は、民法典1798.140条(v)で、特定の消費者または世帯を識別し、関連し、描写し、または直接・間接に合理的に結び付けられ得る情報を personal information と定義し、IPアドレス・オンライン識別子・メールアドレスや閲覧履歴を例に含めています（条文はカリフォルニア州プライバシー保護局の公開版で確認できます）。消費者だけでなく世帯単位の情報まで入る点が、PIIの定義より広いところです。

日本語のpiiデータを検出・マスキングする方法：Presidioの実測

ログや問い合わせ本文からPIIを自動で伏せる用途では、Microsoftのオープンソース Presidio がよく使われます。2026年10月25日公開の presidio-analyzer 2.2.365 を Python 3.12 に入れ、架空の顧客情報を含む日本語の文を解析しました。

既定設定で日本語の文を解析した結果

国別の認識器は米国・英国・インド・韓国など18か国分があり、日本向けはありません。電話番号の認識器が既定で照合する地域も US・GB・DE・FR・IL・IN・CA・BR の8つです。英語の既定構成（en_core_web_lg 3.8.0）と、日本語モデル ja_core_news_sm 3.8.0 に切り替えて認識器も日本語用に読み込み直した構成を比べました（モデルだけを替えた比較ではありません）。入力は、架空の氏名・生年月日・メールアドレス・電話番号2件・郵便番号と住所・マイナンバー・12桁の注文番号・カード番号・IPアドレスを1つの文にまとめたものです。

メールアドレスが漏れた原因は、認識器の正規表現にある \w が日本語の文字にも一致することです。「メールは[email protected]です」のアドレス部分が前後の日本語ごと切り出され、末尾が「comです」になってドメインの検証に落ちていました。アドレスの前後に空白を入れると既定の英語エンジンでも検出されたので、日本語の文に埋もれたアドレスが取りこぼされます。

日本向けの認識器を足すコード

電話番号の地域に JP を指定し、メールアドレスには対象文字を限定した正規表現を追加し、マイナンバーはチェックデジットを検算する認識器を足します。入力の形式を限定した実装例で、メールの正規表現は [email protected] のようなアドレスでは [email protected] だけを検出するため、そのまま本番には使えません。チェックデジットの計算式は個人番号等に関する命令の第5条（検査用数字を算出する算式）に定められています。

検証した環境は Python 3.12、presidio-analyzer と presidio-anonymizer 2.2.365、spaCy 3.8.16、ja_core_news_sm 3.8.0 です。導入は次のとおりです。

uv venv -p 3.12 .venv
uv pip install --python .venv/bin/python presidio-analyzer==2.2.365 presidio-anonymizer==2.2.365
uv pip install --python .venv/bin/python "ja_core_news_sm @ https://github.com/explosion/spacy-models/releases/download/ja_core_news_sm-3.8.0/ja_core_news_sm-3.8.0-py3-none-any.whl"

下のコードの入力は、比較表の入力から郵便番号・住所・IPアドレスなどを除いて短くしたものです。

from presidio_analyzer import AnalyzerEngine, PatternRecognizer, Pattern, RecognizerRegistry
from presidio_analyzer.nlp_engine import NlpEngineProvider
from presidio_analyzer.predefined_recognizers import PhoneRecognizer, EmailRecognizer, CreditCardRecognizer
from presidio_anonymizer import AnonymizerEngine

def mynumber_check_digit(d11):
    # 下位の桁から n=1..11 と数え、重み n+1（n<=6）または n-5（n>=7）を掛けて合計する
    s = sum(int(d11[11 - n]) * (n + 1 if n <= 6 else n - 5) for n in range(1, 12))
    r = s % 11
    return 0 if r <= 1 else 11 - r

class MyNumberRecognizer(PatternRecognizer):
    def validate_result(self, pattern_text):
        return mynumber_check_digit(pattern_text[:11]) == int(pattern_text[11])

nlp = NlpEngineProvider(nlp_configuration={"nlp_engine_name": "spacy",
    "models": [{"lang_code": "ja", "model_name": "ja_core_news_sm"}]}).create_engine()
reg = RecognizerRegistry(supported_languages=["ja"])
reg.load_predefined_recognizers(languages=["ja"])
reg.add_recognizer(PhoneRecognizer(supported_regions=("JP",), supported_language="ja"))
reg.add_recognizer(EmailRecognizer(supported_language="ja", patterns=[
    Pattern("email_ja", r"[A-Za-z0-9._%+\-]+@[A-Za-z0-9.\-]+\.[A-Za-z]{2,}", 0.6)]))
reg.add_recognizer(CreditCardRecognizer(supported_language="ja"))
reg.add_recognizer(MyNumberRecognizer(supported_entity="JP_MY_NUMBER", supported_language="ja",
    patterns=[Pattern("mynumber", r"(?<!\d)\d{12}(?!\d)", 0.3)]))
analyzer = AnalyzerEngine(nlp_engine=nlp, registry=reg, supported_languages=["ja"])

text = ("顧客：山田太郎（1985年4月1日生）、メールは[email protected]です。"
        "電話 03-1234-5678。個人番号 123456789018、注文番号 123456789012。カード 4111111111111111")
entities = ["PERSON", "EMAIL_ADDRESS", "PHONE_NUMBER", "JP_MY_NUMBER", "CREDIT_CARD"]
results = analyzer.analyze(text=text, language="ja", entities=entities, score_threshold=0.4)
print(AnonymizerEngine().anonymize(text=text, analyzer_results=results).text)

出力は次のとおりです。この入力では、検算に通った 123456789018 が置き換わり、検算に通らない注文番号は残りました。ただし、チェックデジットが一致する注文番号も検出されるため、この検算だけでマイナンバーと他の12桁番号を区別することはできません。

顧客：<PERSON>1985年4月1日<PERSON>、メールは<EMAIL_ADDRESS>です。電話 <PHONE_NUMBER>。個人番号 <JP_MY_NUMBER>、注文番号 123456789012。カード <CREDIT_CARD>

しきい値と誤検知：本番で決めておく3点

1つ目はしきい値です。電話番号の認識器は基礎スコアが0.4に固定されており、文脈語も英語（phone、telephone など）しか持たないため、しきい値を0.5にすると電話番号がそのまま残りました。日本語の文脈語を足すか、電話番号だけしきい値を下げます。

2つ目は検出対象の絞り込みです。日本語モデルの固有表現抽出は12桁の注文番号を日付（DATE_TIME）と判定し、括弧の後ろの「生）」も人名と判定しました。対象から DATE_TIME を外すと注文番号の日付誤検知は除外できますが、生年月日も検出対象から外れます。PERSON は対象に残しているため、「生）」の人名誤検知は解消しません。生年月日は準識別子なので、分析用に渡すデータなら別途、年単位に丸めるなどの加工が要ります。

3つ目は限界の受け止め方です。検出漏れは必ず起きる前提で、マスキングは「外部に出す前の一層」と位置づけ、送信先の制限やアクセス制御と組み合わせます。機械学習モデルで検出する選択肢として、OpenAI Privacy Filterとは？日本語PII検出の実測と使い方・限界やAmazon Comprehend（コンプリヘンド）とは？読み方・できること・料金と日本語で使える機能も比較対象になります。生成AIに業務データを渡す前のマスキング設計から相談したい場合は、AIセキュリティ対策の支援で対応しています。

piiデータの漏えい対策と報告義務

報告が必要な4つの事態と期限

個人データの漏えい等のうち、施行規則第7条の4つの事態に当たるものは、個人情報保護委員会への報告と本人への通知が義務です。要配慮個人情報を含む場合、クレジットカード番号のように不正利用で財産的被害が生じるおそれがある場合、不正アクセスなど不正の目的によるおそれがある場合、本人の数が1,000人を超える場合の4つです。高度な暗号化等による除外には、第三者による見読が困難であることに加え、復号鍵などの手段が適切に管理されていることが必要です。報告は、知った後速やかに速報し、30日以内（不正の目的によるおそれがある事態は60日以内）に確報します（同第8条）。日付の数え方や様式は個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務にまとめています。

収集の最小化と仮名化・匿名化

漏えい時の被害を小さくする最も確実な方法は、持たないことです。利用目的に要らない項目は取得せず、保存期間を過ぎたデータは削除します。分析に使うときは、氏名などを削って他の情報と照合しない限り本人が分からない状態にする仮名加工情報（第2条5項）か、復元できない状態まで加工して第三者にも提供できる匿名加工情報（第2条6項）を選びます。どちらにも加工基準と利用制限があり、氏名を消すだけでは足りません。設計上の要件は仮名加工情報とは？作成基準と利用制限を分析基盤の設計要件に翻訳して解説と匿名加工情報とは？加工基準と第三者提供の義務をデータ提供の設計要件に翻訳で扱っています。

よくある質問

PIIの読み方と正式名称は何ですか？

「ピーアイアイ」と読みます。正式名称は Personally Identifiable Information で、日本語では「個人を特定できる情報」「個人識別情報」「個人識別用情報」などと訳されます。

メールアドレスはPIIですか？

PIIの一般的な分類では直接識別子に入ります。日本の個人情報保護法では、ユーザー名とドメインから本人が分かるアドレスは単体で個人情報になり、それ以外は氏名など他の情報と容易に照合できるかで判断します（個人情報保護委員会Q&A1-4）。

電話番号だけでも個人情報になりますか？

電話番号は個人識別符号ではないため、番号だけでは個人情報になるとは限りません。顧客名簿のように氏名などと容易に照合できる状態で持っていれば、個人情報として扱います（Q&A1-25）。

IPアドレスやCookieはPIIに含まれますか？

単体では個人を特定しにくいものの、他の情報と結び付けられればPIIとして扱われます。日本法では通常「個人関連情報」で、GDPRでは前文30によりオンライン識別子として個人データになり得ます。本人の識別可能性とGDPR第3条の適用条件を確認して扱ってください。

指紋や顔のデータは個人情報ですか？

指紋・掌紋・顔・虹彩・静脈などの身体の特徴を、本人を識別できる水準で符号化したデータは個人識別符号で、単体で個人情報になります。生体認証の登録データやログを扱うシステムは、個人データとして安全管理措置の対象にします。

関連記事

• 個人情報保護法とは？定義・事業者の4つの義務・罰則を条文番号で解説【2026年10月時点】
• GDPRとは？EU一般データ保護規則の対象となる個人データと日本企業の対応
• 個人情報保護法改正とは？2026年7月公布の令和8年改正で企業対応はこう変わる
• 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務
• OpenAI Privacy Filterとは？日本語PII検出の実測と使い方・限界