はじめに: その設計判断、法的に大丈夫？
個人情報を扱うアプリを設計していたときのことです。
ユーザーの性格診断データをサーバーに保存する必要がありました。MBTI、エニアグラム、ストレングスファインダー......これらは直接的な個人情報ではないものの、組み合わせれば個人を特定できる可能性があります。
そこで思いつきました。「フロント側で暗号化して、サーバーには暗号文だけ保存すればいいのでは？ サーバーが復号できないなら、個人情報を"扱っている"ことにならないだろう」。
エンジニアあるあるの「技術で法律をハックできるのでは？」という発想です。結論から言うと、法律はそこまで甘くありませんでした。
この仮説、半分は正しく、半分は間違っていました。
調べてみると、暗号化と個人情報保護法の関係には、多くのエンジニアが見落としているグレーゾーンがありました。
前提: 個人情報保護法における「個人情報」の定義
まず基本を押さえましょう。個人情報保護法における「個人情報」とは:
- 生存する個人に関する情報
- 氏名、生年月日、その他の記述等により特定の個人を識別できるもの
- 他の情報と容易に照合でき、それにより特定の個人を識別できるもの
ポイントは「特定の個人を識別できるか」です。暗号化は「データの形式」を変えるだけで、「データの性質」は変わりません。
結論から: 暗号化しても個人情報は個人情報
いきなり結論ですが、暗号化されたデータは、個人情報保護法上、依然として個人情報です。
「え、サーバー側で復号できないのに？」
はい。法律上の定義では、暗号化は「安全管理措置」の一つであり、データの法的性質を変えるものではありません。暗号化した名前は、まだ名前です。ただし鍵がないと読めないだけで。
これは金庫に入れた現金と同じです。金庫に入れても現金の性質は変わりません。ただし、泥棒に入られたときの被害が変わります。
では暗号化する意味は何か? -- 「漏えい報告義務の免除」
暗号化しても個人情報のままなら、暗号化する意味はないのか？ いいえ、大きな意味があります。
高度な暗号化がされている場合、漏えい時の報告義務が免除されます。
個人情報保護委員会のガイドラインQ&Aによると、「高度な暗号化等の秘匿化」の要件は以下の3つのうちいずれか1つを満たすこと:
- 分離管理: 暗号化した情報と復号鍵を分離し、復号鍵の漏えい防止措置を講じている
- 遠隔削除: 遠隔操作により暗号化データまたは復号鍵を削除する機能がある
- 第三者排除設計: 第三者が復号鍵を行使できないように設計されている
暗号技術は、電子政府推奨暗号リストまたはISO/IEC18033に掲載されているものが求められます。AES-256やRSA-2048などが該当します。
本題: クライアント側暗号化のグレーゾーン
ここからが本題です。
アーキテクチャの想定
サーバーは暗号文を保管するだけ。復号鍵はユーザーの端末にしか存在しない。サーバー運営者はデータの中身を見ることができません。
グレーゾーン1: サーバーは「個人データを取り扱っている」のか？
法的な答え: はい、取り扱っています。
暗号文の保管は「個人データの取扱い」に該当します。たとえ中身を読めなくても、その暗号文が個人データの暗号化結果である以上、保管行為自体が「取扱い」です。
これは、中身の分からない封筒を預かる行為が「書類の保管」であることと同じです。封筒を開けられなくても、保管の責任は発生します。
グレーゾーン2: 漏えい報告義務はどうなる？
法的な答え: 免除される可能性が高い。
先述の3要件のうち、③「第三者が復号鍵を行使できない設計」を満たします。サーバー運営者を含む全ての第三者が復号できない設計だからです。
ただし、以下の条件を全て満たす必要があります:
- 暗号技術がAES-256-GCM等の推奨暗号であること
- 鍵導出がPBKDF2やArgon2等の適切なアルゴリズムであること
- 実装に脆弱性がないこと（ここが実務上の最大リスク）
グレーゾーン3: GDPRではどう扱われるか？
日本だけでなく、GDPRの観点も押さえておくべきです。グローバルサービスなら避けて通れません。
GDPRでは、暗号化データの扱いがさらにグレーです。
| 概念 | 鍵の所在 | GDPR上の扱い |
|---|---|---|
| 匿名化 | 鍵を破棄 | 個人データではない |
| 仮名化 | 処理者が保有 | 個人データ |
| 暗号化（サーバー側暗号化） | サーバーが保有 | 個人データ |
| 暗号化（クライアント側） | ユーザーのみ保有 | グレーゾーン |
IAPP（国際プライバシー専門家協会）の分析によると:
クラウドプロバイダが復号鍵を持たない場合、「実質的に個人データを処理していない」という議論がある
しかし、公式な判例やガイダンスは出ていません。GDPR 34条3項(a)により、暗号化されていればデータ主体への漏えい通知は免除されますが、「個人データではない」とは明言されていません。
エンジニアが取るべき設計判断
「グレーゾーンがあるなら、どう設計すればいいのか？」
設計方針: 「個人情報として扱いつつ、暗号化で実害を最小化する」
法律的に安全な立場は「暗号化しても個人情報として扱う」です。その上で、暗号化により以下のメリットを得ます:
- 漏えい報告義務の免除（高度な暗号化要件を満たす場合）
- データ侵害時の実質的被害ゼロ（復号不能）
- ユーザーへの信頼性向上
実装チェックリスト
□ 暗号化アルゴリズム: AES-256-GCM（電子政府推奨暗号リスト掲載）
□ 鍵導出: PBKDF2（10万回以上）またはArgon2id
□ 鍵の保管: ブラウザのWeb Crypto APIまたはIndexedDB（暗号化済み）
□ サーバー側: 復号鍵を一切保持しない設計
□ 通信: TLS 1.3
□ 監査ログ: 暗号文へのアクセスログを記録（中身は見えなくても）
□ プライバシーポリシー: 暗号化の設計を明記
□ 安全管理措置: 個人情報保護法上の措置を実装
やってはいけないこと
- 「暗号化しているから個人情報保護法は関係ない」と判断する → 法的に誤り
- サーバー側にバックドアを仕込む → 要件③を満たさなくなる
- 独自暗号を使う → 推奨暗号リスト外は「高度な暗号化」と認められない
- 鍵導出のイテレーション回数を減らす → ブルートフォースで突破されるリスク
まとめ
| よくある誤解 | 実際 |
|---|---|
| 暗号化すれば個人情報じゃなくなる | 個人情報のまま |
| サーバーが復号できないから安全 | 法的義務は残る（安全管理措置等） |
| 暗号化する意味がない | 漏えい報告義務の免除 + 実害ゼロ |
| GDPRでは個人データではない | 未確定（グレーゾーン） |
暗号化は「個人情報でなくする魔法」ではなく、「漏えい時の被害と法的義務を最小化する設計判断」です。
金庫に入れた現金は、まだ現金です。でも、泥棒に入られたとき「金庫ごと持っていかれたが中身は開けられない」と報告できるのと、「現金がそのまま盗まれた」と報告するのでは、状況が全く違います。
設計段階で暗号化を仕込むことの価値は、そこにあります。
補足: セキュリティは「正解」ではなく「判断」
ここまで暗号化の設計について書きましたが、一つ正直に言っておきたいことがあります。
セキュリティは、プロダクトの規模やフェーズによっては過剰なリソース投下になりやすい領域です。個人情報保護法の完全準拠、暗号化アーキテクチャの設計、監査ログの実装......。これらを全てやってからローンチしていたら、そのプロダクトは世に出る前に資金が尽きるかもしれません。
ビジネスにおいて「まず売上を立てる」ことは、セキュリティと同じくらい重要です。ユーザーが0人のプロダクトの個人情報を守っても、守る相手がいません。
リスクを取れるフェーズなら、セキュリティ要件を最小限にして攻めるという判断もあり得ます。MVP段階でフル暗号化を実装する必要はないかもしれない。重要なのは「やらない」と「知らない」の違いです。
リスクを理解した上で「今はやらない」と判断するのは戦略。リスクを知らずに「やっていない」のは事故の前兆です。
ただ、リソースがかけられない中でも、ほんの少しアーキテクチャを組み替えるだけで、プロダクトを信頼して使ってくれているお客さまの情報を守ることができます。クライアント側暗号化は、まさにその「ほんの少しの組み替え」の一つです。
この記事が、安心して使ってもらえるプロダクトを作るための一助になれば幸いです。
参考
- 個人情報保護委員会 Q&A: 高度な暗号化等の秘匿化
- 個人情報保護委員会: 漏えい等の対応ガイドライン
- IAPP: Is encrypted data personal data under the GDPR?
- GDPR Article 34, Section 3(a)
- 電子政府推奨暗号リスト（CRYPTREC）
セキュリティ × AIの実践的な設計手法は、拙著で詳しく解説しています。
📕 MCPサーバーのセキュリティ実践ガイド（Amazon Kindle）
免責事項: 本記事はエンジニアの設計判断を支援する目的で書かれており、法的アドバイスではありません。具体的な法的判断については弁護士にご相談ください。