個人データを扱うシステムに携わるエンジニアは、漏えいへの備えというと監視や暗号化など防ぐ側の設計に意識が向きがちです。ですが制度の側は、起きた後にどう動くかをすでに具体的に定めています。報告の期限も、伝える中身も決まっている以上、それに応えられる検知と記録の設計こそが問われます。この記事では、報告・通知の仕組みと、その手前でエンジニアが用意しておける設計を整理します。

1. 制度は「起きた後」を決めている

防ぐ設計だけでは、起きた後の動きが決まらない

個人データを扱うシステムの設計では、暗号化やアクセス制御、監視といった防ぐための仕組みに時間を割く場面が多くあります。侵入や誤操作を未然に食い止める設計は、たしかにシステムの土台です。ただ、実際に漏えい等が起きたとき、次に何をするのかは別の設計として用意しておく必要があります。

防ぐ設計と、起きた後の対応設計は、求められる技術がまったく違います。前者はネットワークやアクセス経路の話であるのに対し、後者は何が起きたかを検知し、誰の何が含まれるかを言え、期限内に伝えられる記録を残しているかという話になります。防ぐ設計の完成度よりも、起きた後に説明できる設計のほうが実務では重みを持ちます。

報告と通知は別々に必要になる

令和4年4月1日から、個人データの漏えい等が発生し、個人の権利利益を害するおそれがあるときは、個人情報保護委員会への報告及び本人への通知が必要となります¹。報告と通知は同じ行為ではなく、宛先も内容も別に用意する必要がある2つの対応です。

報告は個人情報保護委員会という制度側の窓口に向けたものです。一方の通知は、実際に情報が含まれていた本人に向けたものになります。宛先が異なれば、伝える粒度も変わります。委員会への報告は事態の全体像を示すものになり、本人への通知は自分に関わる部分がどうなっているかを伝えるものになります。

エンジニアの視点で見ると、この2つの宛先に応じたデータを、それぞれ別の形で取り出せるようにしておく設計が必要になります。誰にどこまで伝えるかを、システムの記録から機械的に導けるかどうかが、起きた後の動きの速さを左右します。

出典：個人情報保護委員会「漏えい等報告・本人への通知の義務化について」をもとに作成

次に押さえておきたいのが、この報告と通知に与えられている期限です。起きてから調べ方を考えていては間に合わない長さで、あらかじめ設計に落とし込んでおく必要があります。

2. 期限は概ね3〜5日という時間感覚

「速やか」の中身は数字で示されている

該当する事態にあたる場合、速やか（概ね3〜5日以内）に個人情報保護委員会への報告を行うこととされています⁶。「速やか」という言葉だけを見ると幅があるように感じますが、実際には概ね3〜5日という時間感覚が示されています。

3日から5日という長さは、日常の業務対応としては長い時間ではありません。障害対応の初動を思い浮かべると分かりやすく、原因の切り分けだけでも数日かかることがあります。そこに、誰の何が含まれるかの確認と、報告文書の作成まで含める必要があります。

出典：個人情報保護委員会「漏えい等報告・本人への通知の義務化について」をもとに作成

調べてから動くのでは間に合わない

この期限が意味するのは、漏えい等が起きてから検知の仕組みを作り始めたり、ログの保存場所を探し回ったりする余地がほとんどないということです。検知の仕組みがないまま漏えい等に備えるのは、地図を持たずに山へ入るようなものです。3〜5日という枠の中に収めるには、発生前の時点で検知・記録の設計が仕上がっている必要があります。

具体的には、いつ・どの範囲の個人データに・どのような事象が起きたかを、システム側が自動的に把握できる仕組みが土台になります。ログが分散していたり、保持期間が短すぎたりすると、期限内に事実関係をまとめること自体が難しくなります。

こうした設計は、防ぐための監視とは目的が異なります。防ぐ監視は異常を止めるために動きますが、報告のための記録は、起きた後に何が言えるかを残すために動きます。両方を同じログ基盤で賄えるかどうかは、設計段階で確認しておきたい点です。

期限と並んで押さえておきたいのが、そもそもどの事態が報告の対象になるのかという線引きです。

3. 該当するかは4つの軸で決まる

中身の性質と、起こりうる結果で見る類型

どの漏えい等が報告の対象になるかは、性質・結果・意図・人数という4つの軸で示されています。まず性質の軸では、要配慮個人情報が含まれる事態が挙げられています²。病歴や犯罪歴など、扱いに配慮が要る情報が含まれているかどうかという軸です。

結果の軸では、財産的被害が生じるおそれがある事態が挙げられています³。クレジットカード情報や口座情報のように、そのまま金銭的な被害につながりうる情報が含まれているかどうかを見る軸です。性質の軸が情報そのものの重さを見るのに対し、結果の軸は情報が使われた先に何が起こりうるかを見ています。

意図の有無と、人数で見る類型

意図の軸では、不正の目的をもって行われた漏えい等が発生した事態が挙げられています⁴。ここでは、外部からの攻撃なのか、内部の誤操作なのかという意図の有無そのものが判断材料になります。意図があったかどうかを見極めるには、発生の経緯を辿れる記録が要ります。

人数の軸では、1,000人を超える漏えい等が発生した事態が挙げられています⁵。ここまでの3つの軸が情報の中身や経緯を見るのに対し、人数の軸だけは規模そのものを見る軸です。性質や結果を見る軸よりも、人数を見る軸のほうが、数える仕組みがなければ判断そのものができません。

4つの軸を一覧にすると、それぞれがどの事態を指しているかが見渡しやすくなります。性質・結果・意図・人数のいずれの軸も、判断の材料がシステム側に残っているかどうかが分かれ目になります。

軸	該当する事態	出典
性質	要配慮個人情報が含まれる事態	2
結果	財産的被害が生じるおそれがある事態	3
意図	不正の目的をもって行われた漏えい等が発生した事態	4
人数	1,000人を超える漏えい等が発生した事態	5

とくに人数の軸は、数えられる仕組みがなければそもそも判断のしようがありません。次に、この人数という軸を詳しく見ていきます。

4. 人数を数えられないと判断できない

1,000人という線引きの意味

1,000人を超える漏えい等が発生した事態は、それ単独で該当する事態として挙げられています⁵。情報の中身がどうであれ、対象となった人数がこの線を超えれば、報告の対象になる事態にあたるということです。

1,000人という数字は、大企業だけの話ではありません。個人向けサービスを扱うシステムであれば、会員データベースの一部が対象になるだけでも届く規模です。案件の規模にかかわらず、意識しておきたい線引きになります。

出典：個人情報保護委員会「漏えい等報告・本人への通知の義務化について」をもとに作成

数えられる設計とは何を指すのか

人数を数えられる設計とは、漏えい等の対象となった個人データの範囲を、システムが特定できる状態を指します。どのテーブルの、どの期間の、何件のレコードが影響を受けたのかを、後から突き合わせられる記録が土台になります。

逆に、ログが断片的だったり、個人データの範囲があいまいなまま設計されていたりすると、対象人数を確定するだけで時間がかかります。1,000人という線を超えているかどうかを判断すること自体が、期限内に間に合わなくなる要因になります。

対象人数を数える設計は、個人データの項目を洗い出し、どのテーブルにどの範囲で格納されているかを把握しておく作業から始まります。この棚卸しは、報告のためだけでなく、日々の設計判断でも役立つ材料になります。

人数を数えられたら、次に必要なのは、通知の中で何を伝えるかという設計です。

5. 通知には項目と原因が要る

何を伝えるかが決まっている

本人へ通知する際には、当該事態の状況に応じて速やかに、概要、個人データの項目、原因などの内容を、本人にとって分かりやすい方法で行うこととされています⁷。伝える中身がすでに決まっているという点が、通知の設計を考えるうえでの出発点になります。

概要は、何が起きたのかという事態の全体像です。個人データの項目は、漏えいした情報のうち、氏名やメールアドレスなど具体的に何が含まれていたかを指します。原因は、なぜ発生に至ったのかという経緯です。この3つを、本人に分かる言葉で伝えられる状態にしておく必要があります。

通知で伝える中身と、実際に使われる伝達手段を、資料の記載に沿って整理すると次のとおりです。手段が使えない場合の代替措置もあわせて確認しておきたいところです。

通知の要素	内容・具体例	出典
概要	漏えい等が発生した事態の概要	7
個人データの項目	漏えいした情報の項目	7
原因	発生に至った原因	7
伝達手段の例	文書の郵送、電子メールの送信	8
伝えられない場合	ホームページ等での公表、問合せ窓口の設置（代替措置）	9

伝える手段と、伝えられないときの備え

通知の方法の例としては、文書の郵送や電子メールの送信が挙げられています⁸。どちらも、本人の連絡先を保持していることが前提になる手段です。連絡先そのものが古くなっていたり、収集していなかったりすると、この手段は使えません。

本人への通知が困難な場合は、ホームページ等での公表や問合せ窓口の設置といった代替措置を講じることも可能とされています⁹。連絡先を持たない、あるいは連絡がつかない相手に対しても、伝える手段が用意されているということです。

文書を用意することよりも、日頃のログ設計のほうが、通知までの時間を左右します。概要・項目・原因を後から作文するのではなく、発生時点のログから機械的に導ける形にしておくことが土台になります。連絡先の保有状況もあわせて把握しておけば、郵送やメールで伝えるか、公表という代替措置に切り替えるかを、期限内に判断できます。

ここまで見てきた報告・通知の仕組みは、どれも起きた後にどう動くかという設計です。最後に、検知と記録という視点であらためて全体を整理します。

6. まとめ

個人データの漏えい等に備える設計は、防ぐための監視と、起きた後に説明するための記録という、2つの役割に分けて考えると整理しやすくなります。報告と通知という2つの対応、性質・結果・意図・人数という4つの軸、そして概要・項目・原因を伝える通知の中身。どれも、あらかじめ形にしておきたい設計項目です。

ここまで見てきた報告・通知の要件を、システム側で用意しておきたい設計項目として整理すると、次のチェックリストのようになります。

設計しておきたいもの	対応する視点	目的
漏えい等を検知する仕組み	性質・結果・意図の判定	該当する事態かどうかを早期に見極める
対象人数を数えられる記録	人数	1,000人を超えるかどうかを判断する5
発生から報告までの時間を管理する仕組み	期限	速やか（概ね3〜5日以内）に報告する6
項目・原因を辿れるログ	通知の内容	概要・項目・原因を分かりやすく伝える7

起きた後にどう動くかの設計は、火が出てから消火器を探すか、あらかじめ手の届くところに用意しておくかの違いにたとえられます。こうした設計に取り組んだ経験は、個人データを扱う基盤に関わるエンジニアとしての強みになります。場所に縛られずに裁量を持って働きたいと考えるなら、案件の90%以上がフルリモート可能です¹⁰というRemoguの実像は、後押しになるはずです。

検知と記録の設計を、防ぐ設計と同じ重みで考えられるエンジニアは、個人データを扱う案件で評価されやすい立場になります。まずは自分の経験がどの案件に活きるのか、Remoguで確かめてみることから始められます。

7. よくある質問

ここまでの内容を、検知と記録という4つの視点で整理した図とあわせて、よくある疑問に答えます。

図の作成：Remogu編集部。個人情報保護委員会が示す該当する事態の類型を、検知・記録の設計の視点から整理したものです。統計データではありません。

報告と通知はどちらか一方でよいのですか

いいえ、該当する事態にあたる場合は、個人情報保護委員会への報告及び本人への通知の両方が必要となります¹。宛先も内容も異なる2つの対応のため、片方だけを整えておく設計では不足します。

自社のシステムはどの軸で該当を確認すればよいですか

性質・結果・意図・人数という4つの軸で確認します。要配慮個人情報が含まれるか²、財産的被害が生じるおそれがあるか³、不正の目的によるものか⁴、そして対象が1,000人を超えるか⁵を、それぞれ独立に判定できる状態にしておくことが土台になります。

通知の連絡先が分からない相手にはどうすればよいですか

本人への通知が困難な場合は、ホームページ等での公表や問合せ窓口の設置といった代替措置を講じることも可能とされています⁹。連絡先を保有していない、あるいは連絡がつかない場合の備えとして押さえておきたい選択肢です。

検知の仕組みは何から手をつければよいですか

まずは、個人データがどのテーブルにどの範囲で存在するかを洗い出すことから始まります。範囲が分かっていれば、対象人数を数える基盤にもなり⁵、概要・項目・原因を伝える通知の材料にもなります⁷。防ぐ設計と並行して、起きた後に説明できる記録の設計を進めておくと、速やかな報告にもつながります⁶。

こうした経験は、案件探しでどう活かせますか

個人データを扱う基盤で検知・記録の設計に携わった経験は、同様の要件を持つ案件で評価されやすいものです。Remoguでは、そうした経験を活かせるリモート案件を探せます。まずは自分の経験に合う条件を、確かめてみることから始められます。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 個人情報保護委員会「漏えい等報告・本人への通知の義務化について」制度の概要（2026年）
＊2 個人情報保護委員会「漏えい等報告・本人への通知の義務化について」該当する事態（2026年）
＊3 個人情報保護委員会「漏えい等報告・本人への通知の義務化について」該当する事態（2026年）
＊4 個人情報保護委員会「漏えい等報告・本人への通知の義務化について」該当する事態（2026年）
＊5 個人情報保護委員会「漏えい等報告・本人への通知の義務化について」該当する事態（2026年）
＊6 個人情報保護委員会「漏えい等報告・本人への通知の義務化について」報告の時期（2026年）
＊7 個人情報保護委員会「漏えい等報告・本人への通知の義務化について」本人への通知（2026年）
＊8 個人情報保護委員会「漏えい等報告・本人への通知の義務化について」通知の方法の例（2026年）
＊9 個人情報保護委員会「漏えい等報告・本人への通知の義務化について」代替措置（2026年）
＊10 Remoguサイト公開情報（フルリモート可能案件の割合）