PIIとPII-Free設計とは？個人情報を持たないシステム設計の考え方と中小企業での実践方法
AIやクラウドサービスの業務活用が急速に広がる中、個人情報の取り扱いがこれまで以上にビジネスリスクに直結する時代になりました。2022年に施行された改正個人情報保護法では漏洩時の報告義務が厳格化され、違反企業への罰則も強化されています。中小企業であっても「うちは小さいから大丈夫」とは言えなくなりました。顧客データベース、従業員の人事情報、メールリスト。こうした情報がサイバー攻撃や内部ミスで漏洩すれば、信用の失墜、損害賠償、行政処分といった深刻なダメージを受けます。
そこで注目されているのが、「そもそも個人情報を持たない」というPII-Free設計の考え方です。PII（Personally Identifiable Information：個人識別情報）を業務システムから排除し、漏洩リスクそのものをゼロに近づける。この発想は、セキュリティ対策の最上流に位置するアプローチとして、大企業だけでなく中小企業にとっても現実的な選択肢になりつつあります。本記事では、PIIの定義から始めて、PII-Free設計の3つの実装パターン、そして中小企業が実践するための具体的な5ステップを解説します。
PIIとは何か──個人識別情報の定義と範囲
PIIの基本的な定義
PIIとは、Personally Identifiable Informationの略で、日本語では「個人識別情報」と訳されます。その情報単体、または他の情報と組み合わせることで、特定の個人を識別できるデータのことです。身近な例で言えば、氏名、メールアドレス、電話番号、マイナンバー（個人番号）、パスポート番号などが該当します。
PIIは大きく2つに分類されます。1つ目は「直接識別子」です。氏名、マイナンバー、メールアドレス、電話番号、免許証番号など、それ単体で個人を特定できる情報がこれにあたります。2つ目は「準識別子」です。生年月日、性別、郵便番号、勤務先名、職種など、単体では個人を特定できませんが、複数を組み合わせると特定の個人にたどり着ける情報です。たとえば「1990年3月15日生まれ・男性・〒810-0041」という3つの情報を組み合わせれば、かなり限定された個人が浮かび上がります。
国ごとに異なるPIIの定義
PIIの範囲は、国や法律によって異なります。日本の個人情報保護法では、「生存する個人に関する情報であって、特定の個人を識別することができるもの」と定義されています。2022年4月の改正では、漏洩が発生した場合に個人情報保護委員会への報告と本人への通知が義務化され、対応しなかった場合の罰則も引き上げられました。仮名加工情報や個人関連情報といった新しい概念も導入され、データの利活用と保護のバランスが見直されています。
EUのGDPR（一般データ保護規則）は、PIIの範囲がさらに広く、IPアドレスやCookieのような技術的識別子も個人データに含まれます。違反時の制裁金は最大で全世界年間売上高の4%または2,000万ユーロと非常に重く、EU域内に顧客を持つ企業は規模に関わらず対象になります。米国NIST（国立標準技術研究所）のSP 800-122では、PIIを「個人の身元を区別または追跡するために使用できる情報」と定義しており、連邦政府機関向けのガイドラインとして広く参照されています。
こうした各国の定義の違いを理解しておくことは、海外のクラウドサービスやAI APIを利用する際に特に重要です。日本国内では個人情報に該当しないデータでも、GDPRの観点では個人データに該当し、取り扱いに規制がかかるケースがあるためです。
なぜPII-Free設計が注目されるのか
漏洩リスクの根本解消
セキュリティ対策には「防御を強化する」アプローチと「守るべきものを減らす」アプローチがあります。ファイアウォールや暗号化は前者の典型ですが、PII-Free設計は後者の究極形です。そもそもPIIを保持していなければ、たとえシステムに侵入されても個人情報が漏洩することはありません。「持っていないものは漏れようがない」というシンプルな原則です。
2025年のIPA（情報処理推進機構）の調査によると、個人情報漏洩インシデントの約6割が中小企業で発生しています。大企業と比べてセキュリティ投資に限りがある中小企業にとって、PIIの保有量そのものを減らすことは、最も費用対効果の高い対策と言えます。
コンプライアンスコストの削減
個人情報を保有する量が多いほど、法令遵守のためのコストは増大します。個人情報保護法やGDPRへの対応には、プライバシーポリシーの整備、データ管理台帳の作成、従業員教育、定期的な監査、漏洩時の報告体制の構築といった多岐にわたる作業が必要です。PIIの保有量を減らせば、こうした対応工数が大幅に削減されます。
特にGDPR対応が必要な企業にとってはインパクトが大きいです。GDPRはデータ主体（個人）の「忘れられる権利」や「データポータビリティの権利」を保障しており、対応にはシステム改修を伴うケースも少なくありません。PIIを保持しなければ、これらの権利行使への対応義務そのものが発生しません。
AI・クラウド活用の安全性
ChatGPTやClaudeなどの大規模言語モデル（LLM）を業務に活用する企業が増えていますが、外部のAI APIにPIIを含むデータを送信することには大きなリスクが伴います。AIサービスのプロバイダーがデータをモデルの学習に使用する可能性、APIの通信経路での漏洩リスク、そしてプロンプトインジェクション攻撃によるデータ抽出リスクなどがあります。
PII-Free設計を採用していれば、AIに渡すデータからあらかじめPIIが除去されているため、こうしたリスクを大幅に低減できます。たとえば「田中太郎さんの売上データを分析して」ではなく「顧客ID:TK-0042の売上データを分析して」とする。このシンプルな置き換えだけでも、AI活用時の情報漏洩リスクは格段に下がります。
サイバー攻撃の標的価値低下
ランサムウェア攻撃やデータ窃盗の攻撃者にとって、PIIは高い換金価値を持つターゲットです。ダークウェブでは個人情報1件あたり数百円から数千円で取引されており、大量のPIIを保有するデータベースは格好の標的になります。PII-Free設計によって個人情報を排除すれば、攻撃者にとってのシステムの「価値」が下がり、標的として選ばれるリスク自体を低減できます。
PII-Free設計の3つの実装パターン
トークン化（Tokenization）
トークン化とは、元のPIIデータを無意味なトークン（代替値）に置き換える方法です。たとえば、クレジットカード番号「4111-1111-1111-1111」をトークン「TKN-8X2F-9K3M」に置き換えます。元のデータとトークンの対応関係は、厳重に保護されたトークンデータベース（トークンVault）に保管されます。
トークン化の最大の特徴は復元可能性です。トークンVaultにアクセスできる権限があれば、トークンから元のPIIを復元できます。これは、顧客対応や請求処理など、必要なときに元の個人情報を参照しなければならない業務に適しています。一方で、トークンVaultへのアクセス権を持たないシステムやユーザーにとっては、トークンは完全に無意味な文字列であり、個人情報としての価値がありません。
決済業界では、PCI DSS（クレジットカード業界のセキュリティ基準）への準拠のためにトークン化が広く採用されています。中小企業でも、ECサイトの決済システムにStripeやSquareなどのサービスを利用している場合、すでにトークン化の恩恵を受けていることが多いです。
匿名化（Anonymization）
匿名化とは、不可逆的にPIIを除去し、元の個人への紐づけを完全に不可能にする方法です。データの集計、一般化（年齢を年代に変換するなど）、ノイズ付加（微小な乱数を加えるなど）といった手法を組み合わせて実施します。
匿名化されたデータは、日本の個人情報保護法では「匿名加工情報」に該当し、個人情報としての取り扱い義務が大幅に軽減されます。第三者提供も、一定の条件のもとで本人同意なしに可能になります。そのため、統計分析やマーケティングリサーチなど、個人を特定する必要がない用途に適しています。
ただし、匿名化には「再識別リスク」という課題があります。匿名化したつもりでも、外部データと照合することで個人が特定されてしまうケースが研究で報告されています。匿名化の実施にあたっては、k-匿名性（少なくともk人が同一の属性値を持つようにする）などの技術的な基準を満たすことが推奨されます。
仮名化（Pseudonymization）
仮名化とは、PIIを仮名（仮の識別子）に置き換えつつ、別途保管された鍵情報を使えば元のPIIを復元できる方法です。トークン化と似ていますが、仮名化はGDPRで明確に定義された概念であり、法的な扱いが明確です。
GDPRでは、仮名化されたデータは依然として「個人データ」に該当しますが、セキュリティ対策を講じていると評価されるため、保護義務が軽減されます。たとえば、データ漏洩が発生しても、仮名化が適切に行われていれば、本人への通知義務が免除される場合があります。
日本の個人情報保護法でも2022年改正で「仮名加工情報」という概念が導入されました。仮名加工情報は、個人情報としての利用目的の制限や開示請求への対応義務が緩和されるため、社内でのデータ分析やAI学習に活用しやすいというメリットがあります。
3つのパターンの比較
それぞれの特徴を整理すると以下のようになります。トークン化は復元可能で、顧客対応や決済など元データの参照が必要な場面に適しています。匿名化は復元不可能で、統計分析やマーケティングなど個人特定が不要な場面に最適です。仮名化は鍵があれば復元可能で、社内のデータ分析やAI学習データの作成に向いています。法的な扱いについても、トークン化されたデータは元データと同等の保護が必要、匿名化データは個人情報に該当しない（条件付き）、仮名化データはGDPR上は個人データだが保護義務が軽減されるという違いがあります。
実際のシステム設計では、これら3つのパターンを業務の性質に応じて使い分けることが重要です。すべてを匿名化すればよいわけではなく、業務で個人への対応が必要な部分にはトークン化や仮名化を、分析用途にはを匿名化を適用するという組み合わせが現実的です。
中小企業でPII-Free設計を実践する5ステップ
Step1：自社が保有するPIIの棚卸し
最初のステップは、自社がどこにどれだけのPIIを保有しているかを把握することです。多くの中小企業では、PIIの所在が網羅的に管理されていません。顧客データベース、人事データベース、メールリスト、Excelの顧客名簿、名刺管理アプリ、問い合わせフォームの送信データ、紙のファイルまで、あらゆる場所にPIIが散在しています。
棚卸しでは、各データの保管場所、含まれるPIIの種類（氏名、メール、電話番号等）、データ量、アクセス権限を持つ人数をリスト化します。この作業は手間がかかりますが、PII-Free設計の出発点として欠かせません。Excelやスプレッドシートで簡易な台帳を作るだけでも、現状の可視化に大きな効果があります。
Step2：PIIの分類
棚卸しが完了したら、次は検出されたPIIを「直接識別子」「準識別子」「非PII」に分類します。直接識別子は最もリスクが高く、最優先で対処すべきデータです。準識別子は単体ではリスクが低いものの、組み合わせによるリスクを考慮する必要があります。非PIIは個人を特定する要素を含まないため、特別な対処は不要です。
分類のポイントは「組み合わせによる識別可能性」を考慮することです。性別と生年月日と郵便番号の3つが揃えば、日本の人口では87%以上の個人が一意に特定可能であるという研究結果があります。準識別子であっても、複数が同一のデータベースに存在する場合は、直接識別子と同等のリスクとして扱うべきです。
Step3：業務ごとに「本当にPIIが必要か」を判定
分類が終わったら、それぞれのPIIが業務上本当に必要かどうかを判定します。これはPII-Free設計において最も重要なステップです。多くの企業では「念のため」「過去からの慣習で」PIIを保持しているケースが少なくありません。
たとえば、売上分析に顧客の氏名は必要でしょうか。従業員満足度のアンケート結果に回答者名は必要でしょうか。メールマガジンの効果測定に個人のメールアドレスは必要でしょうか。多くの場合、匿名のIDや集計値で十分に目的を達成できます。業務フローを一つずつ確認し、「PIIがなくても業務が成立するか」を問い直すことが、PII削減の核心です。
Step4：不要なPIIの削除・トークン化・匿名化の適用
Step3で「不要」と判定されたPIIは、速やかに削除するか、トークン化・匿名化を適用します。削除が最もシンプルで効果的ですが、法令で保管義務がある場合（税務関連の帳票など）は、アクセス制御を厳格化したうえで最小限の保管にとどめます。
業務で個人への対応が必要なデータにはトークン化を適用し、本番の業務システムからPIIを分離します。分析用途で使うデータには匿名化を適用し、個人を特定できない形に変換します。このステップでは、一度にすべてを対処しようとせず、リスクの高い直接識別子から優先的に着手することが現実的です。
Step5：新規システム導入時の「PII-Free by Default」ルール策定
既存のPIIを整理するだけでなく、今後新しいシステムやサービスを導入する際に「PIIを保持しない」ことをデフォルトにするルールを策定します。これが「PII-Free by Default」の考え方です。GDPRにおける「Data Protection by Design and by Default」（設計段階からのデータ保護）と同じ発想です。
具体的には、新規SaaS導入時のチェックリストに「このサービスにPIIを保管する必要があるか」という項目を追加する、社内申請フローに「PIIを含むデータの取り扱いが発生する場合は情報セキュリティ担当の承認が必要」というルールを設ける、といった仕組みを整えます。ルールが形骸化しないよう、半年に一度の棚卸しを定例化することも効果的です。
AI・クラウド活用時のPII-Free設計のポイント
LLMにPIIを渡さないプロンプト設計
ChatGPTやClaudeなどのLLMを業務に活用する際、最も注意すべきはプロンプト（入力テキスト）にPIIを含めないことです。「山田花子さんの過去3年間の人事評価をまとめて」というプロンプトをそのままAIに送信すると、氏名という直接識別子がAIサービスのサーバーに送られることになります。
対策としては、PIIを事前にマスキングしてからプロンプトに含める方法が有効です。「社員ID:EMP-1234の過去3年間の人事評価をまとめて」とすれば、AIに渡される情報からPIIが排除されます。AIの出力結果を社内で利用する際に、必要に応じてIDを元の氏名に戻せばよいのです。この「マスキング → AI処理 → 復元」のフローを標準化することが、AI活用時のPII-Free設計の基本です。
クラウドストレージのPII分離アーキテクチャ
クラウドストレージに業務データを保管する際は、PIIを含むデータとそれ以外のデータを物理的または論理的に分離することが推奨されます。たとえば、顧客の購買履歴データベースでは、顧客IDと購買データを一つのストレージに、顧客IDと氏名・住所の対応テーブルを別のストレージ（またはアクセス制御の異なる領域）に保管します。
この分離により、購買データを分析するチームはPIIにアクセスする必要がなくなります。万が一、分析用のストレージが侵害されても、PIIは別の場所にあるため漏洩しません。AWSであればS3のバケットポリシーとIAMロール、Google CloudであればCloud IAMとVPC Service Controlsを使って、こうした分離を実現できます。
SaaS連携時のデータマスキング
複数のSaaSを連携して業務を自動化する場合、SaaS間でやり取りされるデータにPIIが含まれていないかを確認する必要があります。たとえば、CRMからマーケティングオートメーションツールへ顧客リストを連携する際、マーケティング分析に氏名や電話番号は本当に必要でしょうか。メールアドレスのハッシュ値とセグメント情報だけで十分なケースも多いはずです。
ZapierやMake（旧Integromat）などの連携ツールを使っている場合は、データ変換ステップでPIIをマスキングするフィルターを追加できます。APIで直接連携している場合は、データ送信前にPIIを除去するミドルウェアを挟むことで、SaaS間のデータフローからPIIを排除できます。
介護・福祉業界における匿名化の実践例
PIIの取り扱いが特にセンシティブな業界の一つが介護・福祉業界です。利用者の氏名、要介護度、病歴、服薬情報など、高度なプライバシー情報を日常的に取り扱います。この業界では、AIを活用した介護記録の分析や業務改善にあたって、匿名化の手法が実践的に導入されています。
たとえば、介護記録をAIで分析してケアプランの改善提案を得る場合、利用者の氏名を匿名IDに置換し、住所は市区町村レベルまで一般化し、生年月日は年代に変換したうえでAIに入力します。こうすることで、個人を特定できない状態でデータ分析の恩恵を受けることができます。MINORI Learningの研修プログラムでも、こうした実務に即したデータ設計の考え方を扱っています。
まとめ──PII-Free設計はセキュリティの最強の盾
PII-Free設計は、「漏洩を防ぐ」のではなく「漏洩するものをなくす」という発想の転換です。完璧な防御は存在しませんが、守るべきデータそのものを最小化すれば、リスクは限りなくゼロに近づきます。
本記事で紹介した5ステップを振り返ります。まず自社のPIIを棚卸しし、直接識別子と準識別子に分類する。業務ごとにPIIの必要性を判定し、不要なPIIを削除・トークン化・匿名化する。そして新規システム導入時には「PII-Free by Default」をルール化する。この5つを順に実行するだけで、個人情報の漏洩リスクとコンプライアンスコストを大幅に削減できます。
AIやクラウドの活用が当たり前になるこれからの時代、個人情報の扱い方は企業の信頼性を左右する重要な経営課題です。「まずはPIIの棚卸しから始めてみよう」。その一歩が、自社のセキュリティとデータ活用の両方を前進させる起点になります。
株式会社Sei San Seiでは、中小企業のデータ設計やAI導入における個人情報の安全な取り扱いを支援しています。PII-Free設計の導入やクラウド活用のデータ設計にお悩みの方は、お気軽にご相談ください。