情報漏洩対策の最善手は「持たないこと」 — 持つなら何がどれだけ危ないかを 6 段階で整理する

情報漏洩対策でいちばん確実な方法は、情報を持たないことです。暗号化もアクセス制御も、持っているデータを「漏れにくく」するだけで、ゼロにはしません。持っていないデータは、どんな攻撃を受けても漏れません。

とはいえ、サービスを作れば何かしらのデータは持つことになります。そこで次に大事なのが、持つなら本当に必要なものだけを、必要な期間だけにすることです。そして、そのためには「どのデータがどれくらい危ないか」の物差しが要ります。

本稿はその物差しのたたき台です。

先に結論を書きます。

• 日本には「これが公式の危険度ランキング」という一枚の表はありません。 実務では、法律・業界基準・海外の指針を組み合わせて社内の分類表を作ります。
• いちばん使える根拠は、個人情報保護法の「漏えい報告義務」です。 報告義務がある類型は、国が「漏れたら重大」と判断したデータです。
• 設計の判断は「取らない > 自社で持たない > 持つなら守る」の順に考えます。 危険度が高いデータほど、左の選択肢で済ませます。
• 2026 年 7 月に成立した令和 8 年改正で、16 歳未満の子どもの個人情報、顔特徴データ等、課徴金の規律が加わります。原則として公布から 2 年以内（2028 年 7 月まで）に施行されるので、今から作るシステムは見込んでおくのが安全です。

1. 物差しの根拠になるもの

危険度を決めるときに使える資料は、主に次の 3 つです。

個人情報保護法の漏えい報告義務

個人情報保護法第 26 条と施行規則第 7 条により、次の 4 つのどれかに当たる漏えい（漏えいのおそれを含みます）は、委員会への報告が義務になり、本人への通知も原則として義務になります（本人への通知が難しく、代わりに本人の権利利益を守る措置をとる場合は除かれます。法第 26 条第 2 項）。例は委員会のガイドライン（通則編）によります。

1. 要配慮個人情報（病歴、犯罪歴、信条、人種など）が含まれる
2. 不正に使われると財産的な被害が出るおそれがある（例: EC サイトからのクレジットカード番号の漏えい、送金や決済ができるサービスのログイン ID とパスワードの組み合わせの漏えい）
3. 不正の目的によるおそれがある（不正アクセスや内部不正など）
4. 本人の数が 1,000 人を超える

1 と 2 は「データの種類」で決まり、3 と 4 は「漏れ方と規模」で決まります。設計時に効いてくるのは 1 と 2 です。この 2 つに当たるデータは、件数にかかわらず、漏れた（漏れたおそれがある）時点で報告義務が生じる、と考えておきます。

なお、高度な暗号化などの措置を講じた個人データは、4 つすべてで報告の対象から外れます（施行規則第 7 条第 1 号の括弧書きが、条全体に及ぶ定め方になっています）。ただし条件があります。委員会の Q&A（Q6-19）によれば、その時点の技術水準で、第三者が読める状態にすることが困難な暗号化（電子政府推奨暗号リストや ISO/IEC 18033 などに載っている暗号技術を適切に実装したもの）であることに加えて、次のどれかを満たす必要があります。

1. 暗号化した情報と復号鍵を分けて置き、鍵そのものが漏れないようにしている
2. 遠隔操作で、暗号化した情報か復号鍵を消せる
3. 第三者が復号鍵を使えない設計になっている

データと鍵を同じサーバーに置いていれば、1 は満たしません。その場合は 2 か 3 を満たすかどうかを、Q&A の条件に照らして確かめることになります。設計で狙いやすいのは、鍵をデータと別の場所（鍵管理サービスなど）に置いて 1 を満たすことです。暗号化は「漏れにくくする」だけでなく、条件を満たせば「漏れても報告案件にしない」効果もあります。

2. データ危険度 6 段階

以上を踏まえた、設計判断のためのたたき台です。

以下、レベルごとに理由と実装の要点を見ていきます。

レベル 5: 保持しない前提

漏れたら直接お金が抜かれる、またはなりすましができるデータです。

カード情報。 EC 加盟店は、割賦販売法によってカード番号の漏えいを防ぐ措置を義務付けられています。その措置の具体的な中身を示す実務の指針が、クレジット取引セキュリティ対策協議会の「クレジットカード・セキュリティガイドライン」です（ガイドライン自体は法令ではありませんが、経済産業省の監督の基本方針で実務の指針と位置付けられており、これに沿った措置（またはそれと同等以上の措置）をとっていれば、法律の求める「必要かつ適切な措置」をとっているものとみなされます）。以前は「カード情報を持たない（非保持化）か、持つなら PCI DSS に準拠する」が指針の対策でした。

しかし現行の 6.1 版（2026 年 3 月）は、非保持化しても、それだけでは足りないとしています。最近の主な漏えいは、非保持化した EC 加盟店で、Web サイトの脆弱性を突かれてカード情報が盗まれるものだからです。自社のサイトが改ざんされ、決済画面へ進む前に偽の入力画面を出されれば、カード番号を自社のサーバーに保存していなくても、入力された時点で盗まれます。そのため EC 加盟店には、カード情報を持つかどうかにかかわらず、自社のシステムと Web サイトの脆弱性対策（ウイルス対策、管理者権限の管理など）と、その定期的な点検が求められています。

それでも、カード情報を持たないことが出発点であることは変わりません。中小規模のサービスで PCI DSS に準拠するのは負担が大きいので、まず非保持化を選び、そのうえで脆弱性対策をします。

• 決済代行（Stripe など）のカード入力画面や入力部品を使い、カード番号は自社のサーバーを通さない
• 自社が持つのは、決済代行が返すトークン（カード番号の代わりになる識別子）と、表示用の下 4 桁だけ
• 決済画面に関わる自社の Web サイトと管理画面は、脆弱性対策と定期的な点検の対象にする

PCI DSS は、カード番号そのものの保存は保護を条件に認めていますが、セキュリティコード（CVV など）や暗証番号は、承認後の保存を禁止しています。暗号化していても不可です（要件 3.3.1）。「暗号化すれば持ってよい」が通用しない、数少ないデータです。

パスワード。 平文で持つのは論外として、暗号化（元に戻せる形）で持つのも避けます。持つのはハッシュだけです。OWASP の Password Storage Cheat Sheet は、Argon2id を第一の選択肢に、使えなければ scrypt を挙げています（FIPS 準拠が必要なら PBKDF2、bcrypt は既存システム向け）。

API キー・秘密鍵・セッショントークン。 ここは「持たない」の意味が 2 つに分かれます。

• 自社が発行して利用者に渡し、サーバーは一致するかどうかを確かめるだけのもの（ランダムな文字列の API キー、セッショントークン、リフレッシュトークン）: 元の値を取り出す必要がないので、パスワードと同じくハッシュで持てます。データベースが漏れても、そのまま使える値は出ていきません。ただし、ハッシュにしても、利用者の手元から漏れたトークンは止められないので、失効と定期的な更新の仕組みも用意します
• 自社のサーバーが元の値を使う必要があるもの（外部 API の鍵、署名や暗号化に使う秘密鍵）: ハッシュにすると使えなくなるので、ソースコードやデータベースに置かず、シークレット管理のサービス（AWS Secrets Manager、Cloudflare の Secrets など）に置きます

レベル 4: 原則取得しない

漏えい報告義務の 1 に当たるか、法律で取得・利用そのものが制限されているデータです。

• 要配慮個人情報: 取得には原則として本人の同意が必要で（法第 20 条第 2 項）、漏れれば件数に関係なく報告義務があります
• マイナンバー: 番号法で、利用できる事務が限られ、その範囲外で集めたり保管したりすること自体が禁止されています（第 20 条）。本人の同意があっても、この制限は外れません。税や社会保険の手続きに必要な場合以外は、取得しないのが原則です
• 顔特徴データなどの生体データ: 現行法でも、顔の特徴をコンピューターで扱える形にしたデータ（本人を識別できるもの）は「個人識別符号」として個人情報に当たります。指紋や声紋なども同様です。一方で、体温や心拍のような生体の測定値がすべて個人識別符号に当たるわけではなく、法的な扱いはデータの種類と加工の仕方で変わります。令和 8 年改正で、顔特徴データ等についての規律が強まります（後述）
• 子どものデータ: ほかの 3 つと違い、漏れたときの被害が特別に大きいからではなく、取り扱いの手続きが重くなるからここに置いています。現行のガイドラインと Q&A でも、一般に 12〜15 歳以下の子どもについては法定代理人（親など）から同意を得る必要があるとされています。令和 8 年改正で、16 歳未満の本人についての規律が法律に明記されます（後述）。子どもを対象にしないサービスなら、子どものデータを取らない設計にするのが最も簡単です

設計で最初に問うべきは「本当にこれを取る必要があるか」です。例えば年齢確認なら、生年月日を持たずに「18 歳以上かどうか」の真偽値だけを持てば済む場合があります。

レベル 3: 高

単体で、または組み合わせることで、なりすましや詐欺に使えるデータです。

• 本人確認書類の画像: 氏名・生年月日・住所・顔写真がまとめて載っています。確認が終わったら画像を消し、「いつ、何の書類で、誰が確認したか」の記録だけを残す設計にできないか検討します。本人確認を外部の事業者に任せれば、画像そのものを持たずに済みます
• 銀行口座番号: 振込先として必要でも、画面に全桁を出す必要はありません
• 精密な位置情報: 自宅や勤務先が分かります。用途に合わせて精度を落とす（市区町村単位にするなど）か、保存期間を短くします
• 氏名＋生年月日＋住所のセット: 一つひとつはレベル 2 でも、揃うとなりすましに使えます

持つなら、暗号化、閲覧できる人の最小化、保存期間の設定の 3 点が要ります。保存期間を決めて自動で消す仕組みは、最も効く対策の一つです。消したデータは漏れません。

レベル 2: 中

氏名、住所、電話番号、メールアドレス。多くのサービスが持つデータです。

単体なら被害は迷惑メールや迷惑電話にとどまることが多いのですが、漏れた本人の数が 1,000 人を超えれば、それだけで報告義務の対象になります。数えるのは会員の総数ではなく、漏れた個人データの本人の数です。会員が多いサービスほど、このレベルのデータでも一度に 1,000 人分を超えて漏れれば報告案件になる、ということです。

組み合わせで危険度が上がる点にも注意が要ります。氏名とメールアドレスに、購入履歴やパスワードの使い回しが加わると、標的型の詐欺に使われます。

レベル 1: 低

Cookie ID、閲覧履歴、仮名化データ。それ自体では誰のものか分からないデータです。

ただし、渡した先で個人データになり得る点に注意します。現行法でも、提供先で個人データとして取得されることが想定される場合、提供元は、提供先が本人の同意を得ていることを確認しなければなりません（法第 31 条、個人関連情報の第三者提供の規律）。

また、法律上の「仮名加工情報」（他の情報と照合しない限り個人を識別できないように加工したもの）は、個人情報とは別に定義された区分で、専用の規律（法第 41 条・第 42 条）があります。そのうえで、元の個人情報や削除した情報を持っている自社の中では、照合すれば個人を識別できるので、個人情報にも当たります（委員会のガイドライン（仮名加工情報・匿名加工情報編））。個人データである仮名加工情報は、委託などの例外を除いて第三者に提供できません。「仮名にしたから低リスク」と考えて扱いを緩めるのは危険です。広告やアクセス解析のタグを入れるときは、このレベルのデータを外に出していることを意識します。

レベル 0: 最小

特定の個人を識別できない形に加工したデータです。ただし、集計しただけで安全になるわけではありません。該当者が数人しかいない区分や、珍しい属性の組み合わせが残っていると、統計データからでも個人が特定できます。区分ごとの人数が少なすぎないかなど、再識別のリスクを確認したものだけをこのレベルとして扱います。法律上の匿名加工情報は、委員会規則の加工基準を満たして作ったものを指します。

分析や AI の学習に使うなら、生データではなくこのレベルまで加工したものを渡すのが理想です。ただし匿名加工情報を作ったり提供したりするときにも、加工の基準や公表など、法律上の手続きがあります。

3. 令和 8 年改正で設計に効くところ

2026 年 7 月 10 日に「個人情報の保護に関する法律等の一部を改正する法律」が成立し、7 月 17 日に公布されました。施行は原則として公布の日から 2 年以内（2028 年 7 月まで）で、具体的な日は政令で決まります。対象の範囲や手続きの細部も、多くはこれから委員会規則などで定められます。以下は個人情報保護委員会の改正法の概要に基づいています。

設計に直接効くのは次の点です。

16 歳未満と顔特徴データ等は、上の表でレベル 4 に置いた理由そのものです（子どものデータは、漏れたときの被害ではなく、手続きの重さで置いています）。施行前でも、これから作るシステムには「年齢でデータの扱いを分ける」「顔特徴データを消せる」設計を入れておくほうが、後から作り直すより安く済みます。

4. 設計の順番: 取らない > 持たない > 守る

各レベルのデータについて、次の順に検討します。

1. 取らない。 その項目がないと、本当にサービスが成り立たないか。生年月日ではなく「成人かどうか」で足りないか。住所ではなく都道府県で足りないか
2. 自社で持たない。 取る必要があっても、決済代行のトークン化、本人確認の外部委託、認証の外部サービス（Google ログインなど）で、自社のデータベースに置かずに済まないか
3. 持つなら守る。 暗号化、閲覧権限の最小化、保存期間を決めて自動で消す、アクセスの記録を残す

レベルが高いデータほど、1 か 2 で済ませます。レベル 5 は 1 か 2 しか選ばない、レベル 4 は原則 1、どうしても必要なら 3 を全部やる、というのが目安です。

「持つなら守る」は最後の手段です。守りは必ずどこかで破られる前提で考えます。そのときに漏れる量を減らせるのは、持っている量を減らすことだけです。

5. 社内の分類表にするには

この表をそのまま使うのではなく、自社のサービスで扱う項目を一つずつ並べ、次の 4 列を埋めると、設計レビューで使える分類表になります。

社内規程にまで落とし込むなら、プライバシーマークの基準になっている JIS Q 15001 や、国際規格の ISO/IEC 27701 の枠組みが使えます。

まとめ

• 漏れないデータは、持っていないデータだけ
• 持つ必要があるなら、危険度を物差しにして「取らない > 持たない > 守る」の順に考える
• 物差しの根拠は、個人情報保護法の漏えい報告義務、PCI DSS、NIST SP 800-122
• 令和 8 年改正で、子どものデータと顔特徴データの扱いが厳しくなる。今から作るなら見込んでおく

本稿の表はあくまで設計判断のたたき台です。法的な判断が必要な場面では、最新のガイドラインを確認し、専門家に相談してください。

参考資料

• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」
• PCI Security Standards Council, Document Library（PCI DSS v4.0.1）
• NIST SP 800-122, Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)
• OWASP Password Storage Cheat Sheet
• OWASP Application Security Verification Standard (ASVS)
• 日本クレジット協会「クレジットカード・セキュリティガイドライン」
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（仮名加工情報・匿名加工情報編）」
• 個人情報保護委員会「「個人情報の保護に関する法律についてのガイドライン」に関するQ&A」
• 個人情報保護委員会「令和8年 改正個人情報保護法について」（概要 PDF）
• e-Gov 法令検索「個人情報の保護に関する法律施行規則」
• e-Gov 法令検索「行政手続における特定の個人を識別するための番号の利用等に関する法律」
• BUSINESS LAWYERS「令和8年改正個人情報保護法とは？ポイントを弁護士が解説」
• 長瀬総合法律事務所「2026年（令和8年）改正個人情報保護法の全貌と企業実務への影響」
• issoh「個人情報保護法改正とは？2026年7月公布の令和8年改正で企業対応はこう変わる」