Privacy by Designとしてのインシデントレディネス — 欧州の議論の最前線
この記事の著者
プライバシーエキスパート
栗原 宏平
【免責事項】 本記事は筆者個人の見解に基づき執筆したものであり、筆者は弁護士資格を有しておりません。法律上のアドバイスを目的としたものではありませんので、あらかじめご了承ください。
はじめに
ご存知の方も多いGDPR（欧州一般データ保護規則）では、第25条で「データ保護バイデザイン及びデータ保護バイデフォルト」を定義しており、技術的な対策等をデータ保護の基本原則に基づいた形で事業者に対して求めるように明記されています。
この第25条で定義される「バイデザイン、バイデフォルト」の考え方は、2009年にカナダのオンタリオ州で当時情報コミッショナーを務めていたアン・カブキアン博士が考案した「プライバシー・バイ・デザイン」の考え方を取り入れていると紹介する記事もあり、インシデント対応を考慮したようなシステム開発を行う上では「プライバシー・バイ・デザイン」の考え方を取り入れることはとても大切です。
プライバシー・バイ・デザインの7原則とは
「プライバシー・バイ・デザイン」は7つの原則によって構成され、システムを設計する前段階から、原則に沿った形の設計思想で開発が行われているかを照らし合わせて確認します。7つの原則の内容は以下の通りです。
事後的ではなく、事前的 ; 救済的でなく予防的
プライバシー侵害が起きてから対応するのではなく、プライバシー侵害が発生しないように予防するため、事前に対策として取り組む
初期設定 としてのプライバシー
プライバシー保護を標準ルールとして採用し、自動的に保護される仕組みとして組み込む
デザインに組み込まれるプライバシー
付帯サービスとしてプライバシー保護を実装するのではなく、設計要素として含んだ上で開発する
全機能的 — ゼロサムではなく、ポジティブサム
セキュリティ対策とプライバシー保護のどちらかを優先するのではなく、同時にどちらも実現する
最初から最後までのセキュリティ — すべてのライフサイクルを保護
情報のライフサイクル全体にセキュリティとプライバシー保護を組み込み設計する
可視性と透明性 — 公開の維持
利用者及び提供者が相互に検証し、信頼し合う環境を構築するために透明性や理解できる設計を行う
利用者のプライバシーの尊重 — 利用者中心主義を維持する
利用者を中心として、個人の利益を最大限に維持する
この7原則を軸として、利用者の権利を保護した上で、信頼できるシステム構築を進める上ではより重要な考え方になります。
日本を含めたG7各国の規制当局が推奨する「プライバシー・バイ・デザイン」
「プライバシー・バイ・デザイン」の7原則が考案されてから、約17年が経ち、当時予測されたデジタル社会が徐々に現実に近づいてきています。
これまでは法規制への対応を中心としたコンプライアンスやガバナンスが話題の中心となり、各国の規制当局も法対応を積極的に求めてきましたが、AIがビジネス環境で徐々に当たり前になりつつある中でコンプライアンスと合わせて、サービスデザインやサービス設計の重要性が高まりつつあります。
特に未成年が利用するサービスについては、子供の個人情報を保護することを求めるような声明が数多く発表され、2025年6月にカナダ・オタワで開催されたG7データ保護・プライバシー機関ラウンドテーブルでは、子供の個人情報の取り扱いに関して「特定の法域で法的に要求されているかどうかにかかわらず、プライバシー・バイ・デザインの実践を採用することで、事業者が責任あるイノベーターとして行動することを奨励する」声明が出されました。
子供の個人情報に関しては、他の情報と比較して漏洩した場合に悪用されるケースも考えられるため、サービスを設計する段階から「プライバシー・バイ・デザイン」の原則に沿った形でシステム開発を進めていくことが推奨されます。
また、本年6月にフランスのパリで開催されたG7データ保護・プライバシー機関ラウンドテーブルでは、昨年の声明で奨励した「プライバシー・バイ・デザイン」に加えて、未成年であるか否かを判断する際の年齢認証の設計に加える必要性についても言及されることになりました。
また別の声明では「インターネットに接続された家庭用機器とこどものプライバシー保護」に関するテーマについても言及があり、デジタルサービスを提供する企業だけでなく、ハードウェアを製造する企業にとっても、プライバシー保護は製品設計において重要なテーマの一つになりつつあります。
インシデント対応を設計からデザインする
ここまで、世界的な動向や国際ルールに関する動きについて紹介してきました。
設計段階からプライバシー保護に取り組む必要性は理解できるものの、実務を考えた上で「なぜバイデザイン」の考え方を取り入れるべきなのか気になった方も多いと思います。
私が「バイデザイン」に取り組むべきであると考える大きな理由の一つに、各国の規制で求められる企業の報告義務（インシデントレポート）があります。
昨今、外部攻撃に限らず企業が個人情報を漏洩するケースが良くみられるようになりました。個人情報が漏洩すると、内部のセキュリティやガバナンスの強化だけに止まらず、漏洩状況を把握し、素早く状況報告を行う体制を整えることが求められます。
これは、「プライバシー・バイ・デザイン」が定める「情報のライフサイクル」という視点で設計を考えることが重要であるということを意味します。
GDPRでは第33条で「監督機関に対する個人データ侵害の通知」を求めており、72時間以内に所轄監督機関に対して、個人情報漏洩を含む侵害通知を行う必要があります。この72時間という短期間の間に、各企業は発生した問題を特定し、かつ必要な項目への回答を揃えた上で対応することが求められるのです。
実際に欧州でのGDPRの第33条違反で罰則を受けたケースを見てみると、Enforcement Trackerと呼ばれる罰則ケースをまとめたリストには2018年にGDPRが施行されてから、2026年4月30日までの間に101件（第33条以外に違反した条項も含む）が対象事案になると記載されています。
このように、システム設計段階から、インシデント対応を前提に開発を行っていない場合には報告義務への対応が遅れ、罰則金に至るケースも見られます。
まずは自社が取り扱う個人情報のリスク評価を実施してみる
では具体的に「プライバシー・バイ・デザイン」を自社でどのように取り組めばいいのかと思った方も多いのではないかと思います。「プライバシー・バイ・デザイン」の原則で定められている7つの原則は、少し抽象度が高いため実務者的にはわかりづらい部分も多々存在しています。
そこで、まずはGDPRの第35条で求められるDPIA（Data Protection Impact Assessment：データ保護影響評価）に取り組むことをお勧めします。
※日本では、個⼈情報保護委員が「プライバシー・バイ・デザイン」を実践するための手法の一つであるPIA（Privacy Impact Assessment：個人情報保護評価）について記した留意点を2021年6月30日にドキュメントとして公表しています。
このDPIAとは、GDPRの下で処理する個人データが高リスク対象に該当する場合に、事前に起こりうるリスクを評価し、評価した結果を報告書として取りまとめた上で記録しておくものです。
今年の4月に欧州各国の規制当局が参加するEDPB（欧州データ保護委員会）がDPIAのテンプレートを公開し、DPIAを実施する際に評価すべき項目について公表しています。
テンプレート内では第25条で定義されている「データ保護バイデザイン及びデータ保護バイデフォルト」を実施できているのかを評価する項目も含まれており、まずはこのテンプレートに沿った形で、「バイデザイン」に該当する対策が実施できているのかを確認するようにします。
テンプレートに沿った上で、「バイデザイン」の対応ができているのかを以下の項目に照らし合わせて評価していきます。
（以下は第25条で定義された内容のリスク評価をテンプレートに沿って実施した一例）
評価項目 | 満たしている機能 | 適切性の説明（評価） | 実装状況 |
データ処理の最小化 | 外部LLMのAPIを呼び出す前に、ネームドエンティティ認識から個人識別子を削除する | 必要な情報以外は制限するような機能要件となっている | 計画中 |
データの保管期間の最小化 | 30日後に自動でログが削除される機能を実装する | 運用するために必要不可欠なデータを除き、データが必要以上に保管されない設計となっている | 部分的に実装 |
デフォルトでプライバシーを設定する機能の実装 | 学習モデルが再度学習するような機能設定がデフォルトでオフ設定になっている | デフォルト設定を変更しない限り、データが異なる目的で処理されない構造になっている | 計画中 |
ユーザーによるデータ管理と仮名化 | システム全体で仮名化を実現できるようにIDを自動でハッシュ化する | 管理されたデータサーバーごとにデータが関連づけられない設定になっている | 実装済み |
評価項目：GDPRの第25条で定義されている項目
満たしている機能：GDPRの第25条で定義されている項目を満たすために実装している機能。もしくは今後実装予定の機能
適切性評価：実装、もしくは実装する予定の機能が項目を満たすために適切であると評価した理由の説明
実装状況：機能の実装状況
ここで紹介した例を参照し、第25条で定められている「バイデザイン」の要件を満たすような仕様になっているかを、事前にリスク判定した上で評価項目を埋めていきます。また、現在の実装ステータスについても明記した上で、起こりうるリスク度合いについても評価していきます。
現時点で実装できておらず、将来的に実装を検討している機能については、機能を実装するに至るまでのスケジュールや計画についても記載します。各項目を埋めることによって、特定のサービスや製品に足りていない項目が明確になり、組織内での個人情報に関するリスクを適切に評価できるようになります。
リスクの高いデータがどこにあるのかを自社で理解しておく
ここまではリスク評価のテンプレートを用いて、「バイデザイン」の要件が導入できているのかどうかを確認する方法を紹介してきました。事前に実装すべき要件をリスクに合わせて整理しておくことで、システムを公開した後に発生し得るリスク影響を最小限に止めることができます。
この対応手法について欧州委員会が公表したページでは「リスクベースド・アプローチ」と呼んでおり、システム上で個人データを処理する際に、どのようなリスクがあるのかを事前に評価し、想定されるリスクを透明性のある形で把握しておくことが求められます。
仮に、インシデントが発生しシステムの不備や脆弱性によって個人データが漏洩したり、不正利用の疑いが考えられる際にも、リスクベースでのアプローチをとっておくことによって逸早くリスク検知ができ、72時間という限られた時間の中でも対象となる規制当局に対して報告を実施することができるようになります。
このような「リスクベースド・アプローチ」を実施するにあたり、企業ができることとしては、自社でどのようなデータを扱い、どれくらいのデータを処理するのかを把握することが必要になります。
そのための手法として「データマッピング」という考え方があり、まずはこの「データマッピング」を実施することをお勧めします。2022年10月に個人情報保護委員会が公表した「データマッピング・ツールキット」には、「データマッピング」を実施する意義や導入方法がわかりやすく解説されています。
この記事では「プライバシー・バイ・デザイン」の観点から、まずは企業が取り組むべき手順について紹介してきました。特に情報漏洩時のインシデント対応は、問題が起きた後に対処方法を検討するのではなく、事前にシステム設計段階からインシデントリスクも想定してリスク評価を実施する必要性がより高まってきているので、実務的な対策を考える上で参考にしてください。
参考資料
この記事の著者
プライバシーエキスパート
栗原 宏平
大学在学時に政治家の事務所で働き、卒業後は楽天に入社。2年間の営業経験を経て起業。国外のデジタルサービスの日本展開や国内のサービスの国外展開を支援。2017年より米国の非営利法人Government Blockchain Associationの日本代表を務める。
その後、スタートアップの創業に関わる傍ら、ユネスコを始めとした国際会議でブロックチェーン関連で登壇を経験。2020年に一般社団法人Privacy by Design Labを立ち上げ、プライバシーに関するアドボカシー活動を中心に国際的な場づくりに取り組む。専門領域は、データ保護（個人情報保護）、デジタルマーケティング、ブロックチェーン。国内外のプライバシー業界のリーダーへ直接お話を聞くインタビューメディア“Privacy Talk”を運営。
この記事をシェア
お役立ち記事一覧
