漏えい等報告の期限と第一報の書き方｜「おそれ」で動く4類型、速報3〜5日・確報30日と公表文のテンプレ

漏えい等報告や公表の第一報には、件数も原因もまだ書けないことが多いです。2026年10月16日に公表された日経の事案では、不正アクセスのあった10月7日の4日後に個人情報保護委員会へ報告し、公表はその5日後でした。さくらインターネットの事案では、第一報の583アカウントが第三報で951アカウントに増えています。

連載「事故から逆算するWebセキュリティ」の第18回は、漏えいしたときの報告義務と第一報の書き方を扱います。漏えい等報告は「確定したら出す」ものではなく、「おそれ」の段階で時計が動くものです。攻撃の入口側の全体像は サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説 にまとめています。

公表までの時間は事案でかなり違います。デジタル庁は6月25日に不審なアクセスを検知し、7月9日に VPN 機器の脆弱性を悪用した侵入だと判明、職員等約24.6万件の漏えいの可能性を公表したのは9月11日でした。第一興商は、委託先の PC 1台のマルウェア感染（10月1〜2日に検知）について10月5日に報告を受け、10月8日に約872万人分の漏えいの「おそれ」として公表しました。外部への流出や不正利用の証拠はまだ確認されていない段階での公表です。

漏えい等報告が必要になる4つの事態

個人情報保護法第26条は、個人データの漏えい等のうち「個人の権利利益を害するおそれが大きいもの」として委員会規則で定める事態が起きたとき、PPCへの報告と本人への通知を求めています。その事態を定めるのが施行規則第7条で、次の4つです。

・第1号 要配慮個人情報：病歴や健康診断の結果などを含む個人データ。1人分でも対象
・第2号 財産的被害のおそれ：クレジットカード番号など、不正に使われると財産的被害が出るおそれがあるもの
・第3号 不正の目的のおそれ：不正アクセスや持ち出しなど。2024年4月1日の改正で、取得しようとしている個人情報（入力フォームを狙うウェブスキミングなど）も含むようになった
・第4号 1,000人超：本人の数が「千人を超える」もの

どの号も、漏えい等が「発生し、又は発生したおそれがある事態」を対象にしています。確証を待たず、疑いの段階で報告の検討を始めるのが前提です。人数も確定値ではなく、おそれのある最大の数で見ます。件数が分からないうちは、そのシステムに登録している全員が上限になります。Studioの第一報も、件数は精査中としたうえで「登録しているすべての顧客」を対象に挙げていました。

漏えい等報告の速報と確報：「おそれ」の段階で時計が動く

施行規則第8条は報告を2段に分けています。第1項が速報で、事態を知ったら「速やかに」、その時点で把握している事項を報告します。PPCは「速やか」の目安を概ね3〜5日以内としています。第2項が確報で、知った日から30日以内、第3号（不正の目的のおそれ）の事態は60日以内です。

起算点の「知った」は、法人ならいずれかの部署が知った時点で、経営層に上がった日ではありません。確報の期限は知った日を1日目として数え、末日が土日・祝日・年末年始なら翌日になります（この2点は、PPCの特定個人情報のガイドラインの同じ記述で確認。通則編の該当箇所の原文は開けていません）。30日・60日は上限で、早く出せるならそのほうが望ましいとされています。確報の時点で分からない事項は、分かり次第追完します。

報告する事項は、概要、漏えい等した個人データの項目、本人の数、原因、二次被害またはそのおそれの有無と内容、本人への対応の実施状況、公表の実施状況、再発防止のための措置、その他参考となる事項です。速報では、このうち分かっているものだけで足ります。

2026年の動き：10月7日の注意喚起と改正法

PPCは2026年10月7日に「大規模な漏えい等事案を踏まえた対応について（注意喚起）」を公表しました。大量の個人情報や、財産的被害・詐欺に使われうる情報を持つ事業者に向けて、アクセス制御や不正アクセスの早期検知、不要になった個人データの消去などを求めています。同じ日に「不正アクセスによる個人データ漏えい防止のための注意喚起」も改訂されました。

また、個人情報保護法等の改正法が2026年7月17日に公布されています。施行は一部を除き公布から2年以内の政令で定める日で、PPCは政令・規則の整備を検討中です。PPCの制度改正方針には、本人の権利利益の保護に欠けるおそれが少ない場合の本人通知を合理化する方向が示されていますが、範囲は今後の委員会規則で決まります。施行までは、この記事で整理した現行のルールのままです。

第一報の数字はなぜ変わるのか：2026年の事案から

2026年の事案のタイムライン

確認から公表までは、さくらが8日、ソースネクストが2日、Studioが3日でした。これは公表の日付で、PPCへの報告日は日経以外は分かりません。

第一報のあとに数字が動く理由

第一報の時点では、ログの保全も影響範囲の調査も途中です。数字は調べるほど増えることが多く、範囲も広がります。さくらインターネット不正アクセスとは｜第三報の951と136万・2023年4月からの期間・自分の確認手順 では、第一報で「影響は確認されておりません」とされたのは提供環境の話で、第二報で販売管理システムの会員情報（1,360,563アカウント、可能性）が加わりました。

日経不正アクセスで183万件漏えい｜システム開発に利用するクラウドの認証情報が入口、対象者と開発チームの点検 では、PPCへの報告（10月11日）が公表（10月16日）より先でした。法令が求めるのはPPCへの報告と本人への通知で、公表は本人への通知が難しいときの代替措置の1つとして出てきます。報告と公表は別の手続きです。

2026年10月の発表を並べると、変わる数字への備え方は大きく3つに分かれます。

漏えい等報告の対象かを判定する補助を書いて試す

初動の場では「これは報告対象か」「確報はいつまでか」を何度も聞かれます。4類型と期限の数え方をそのまま小さな関数にして、手元で試しました（Python 3.13.16、2026-10-17）。学習用の補助で、法的な判断を代わりにするものではありません。

# leak_report_check.py — 漏えい等報告の「4類型」に当たるかを整理する学習用の補助（法的助言ではない）
from dataclasses import dataclass
from datetime import date, timedelta

@dataclass
class Incident:
    known_on: date           # 社内のどこかの部署が事態を知った日
    people_max: int          # おそれのある本人の数（分からなければ最大で見積もる）
    sensitive: bool = False  # 要配慮個人情報（病歴・健診結果など）を含む
    financial: bool = False  # カード番号・ネットバンキングのID/パスワードなど
    malicious: bool = False  # 不正アクセス・持ち出しなど、不正の目的のおそれ
    secured: bool = False    # 高度な暗号化等で秘匿化済みで、鍵も漏れていない

def judge(i: Incident) -> dict:
    hits = []
    if i.secured and not i.malicious:
        return {"report": False, "why": ["高度な暗号化等の例外に当たるかを要件で確認"]}
    if i.sensitive: hits.append("1号 要配慮個人情報")
    if i.financial: hits.append("2号 財産的被害のおそれ")
    if i.malicious: hits.append("3号 不正の目的のおそれ")
    if i.people_max > 1000: hits.append("4号 1,000人超")
    if not hits:
        return {"report": False, "why": ["4類型に当たらない。記録・原因究明・再発防止は行う"]}
    last = i.known_on + timedelta(days=(60 if i.malicious else 30) - 1)  # 知った日を1日目
    while last.weekday() >= 5:      # 末日が土日なら翌日へ（祝日・年末年始は未対応）
        last += timedelta(days=1)
    return {"report": True, "why": hits,
            "速報の目安": f"{i.known_on + timedelta(3)}〜{i.known_on + timedelta(5)}",
            "確報の期限": str(last), "本人通知": "状況に応じて速やかに"}

if __name__ == "__main__":
    d = date(2026, 10, 13)  # 架空の「知った日」
    cases = {
        "外部攻撃で1,001人": Incident(d, 1001, malicious=True),
        "誤送信10人・機微なし": Incident(d, 10),
        "誤送信1,000人ちょうど": Incident(d, 1000),
        "誤送信1,001人(BCC漏れ)": Incident(d, 1001),
        "健診結果1人を誤送付": Incident(d, 1, sensitive=True),
        "末日が土曜(10/16に知る)": Incident(date(2026, 10, 16), 1001),
    }
    expect = [True, False, False, True, True, True]
    for (name, inc), want in zip(cases.items(), expect):
        r = judge(inc)
        assert r["report"] is want, name
        tail = f" | 速報目安 {r['速報の目安']} | 確報 {r['確報の期限']}" if r["report"] else ""
        print(f"{name} | 報告={r['report']} | {' / '.join(r['why'])}{tail}")
    assert judge(cases["末日が土曜(10/16に知る)"])["確報の期限"] == "2026-11-16"
    print("all", len(cases), "cases passed")

python3 leak_report_check.py の出力です。

外部攻撃で1,001人 | 報告=True | 3号 不正の目的のおそれ / 4号 1,000人超 | 速報目安 2026-10-16〜2026-10-18 | 確報 2026-12-11
誤送信10人・機微なし | 報告=False | 4類型に当たらない。記録・原因究明・再発防止は行う
誤送信1,000人ちょうど | 報告=False | 4類型に当たらない。記録・原因究明・再発防止は行う
誤送信1,001人(BCC漏れ) | 報告=True | 4号 1,000人超 | 速報目安 2026-10-16〜2026-10-18 | 確報 2026-11-11
健診結果1人を誤送付 | 報告=True | 1号 要配慮個人情報 | 速報目安 2026-10-16〜2026-10-18 | 確報 2026-11-11
末日が土曜(10/16に知る) | 報告=True | 4号 1,000人超 | 速報目安 2026-10-19〜2026-10-21 | 確報 2026-11-16
all 6 cases passed

外部攻撃の1,001人は第3号と第4号に当たり、確報は60日目の12月11日になりました。機微でない10人分の誤送信は4類型に当たりません。人数の境目は「千人を超える」なので、1,000人ちょうどは対象外、1,001人で対象になります。期待値を1つわざと逆にすると AssertionError で止まることも確かめました。

割り切った点もあります。祝日と年末年始の繰り下げは入れていません。暗号化の例外は、不正の目的のおそれがあるときは当てずに報告の側に倒しています。「財産的被害のおそれ」や「不正の目的のおそれ」に当たるかどうかは、関数ではなく人が事実から判断する入力です。

本人通知と第一報のテンプレート

本人への通知は、施行規則第10条で「当該事態の状況に応じて速やかに」とされています。PPCのガイドラインは、事実関係がすべて分かるまで待つ必要はないとしています。連絡先が分からないなど通知が難しいときは、事案の公表や問い合わせ窓口の設置といった代替措置をとります。

利用者向けの第一報は、次の4つの欄に分けると数字が変わっても崩れにくくなります。

数字を出すときは、何を数えたか（アカウント数か本人の数か）と、いつ時点かを必ず添えます。583と1,360,563のように数え方の違う数字が並ぶと、足し算されて誤解が広がります。

事前の対策：連絡網・判断表・テンプレ

速報の目安が3〜5日だと、調べながら判断する時間はほとんどありません。当日に決めることを減らすには、次の3つを前もって用意します。

・連絡網：開発・運用・CS・法務・広報のどこが「知った」ら、誰に何分以内に上げるか。夜間・休日の当番も決める
・判断表と台帳：システムごとに、持っている個人データの種類（要配慮・カード番号の有無）と本人の数の上限を記録しておく。上の判定の入力がすぐ埋まる
・テンプレート：上の4つの欄を持つ第一報の雛形と、PPCへの報告事項の下書き。社内の承認経路も決めておく

台帳が無いと、第4号の「1,000人超」に当たるかが当日に分かりません。不要になった個人データを消しておくことは、10月7日の注意喚起でも求められている対策で、漏えいしたときの本人の数そのものを減らします。

参照ソース

• Digital Agency “Possibility of Leakage of Personal Information of Employees, etc. by Unauthorized Access to Government Solution Services”（2026-09-11）と同 Q&A（デジタル庁の英語版ページ）
• 第一興商 “Notice Regarding the Potential Leakage of Personal Information at a Contractor”（2026-10-08）（英語版ページ）
• 個人情報保護委員会「漏えい等報告・本人への通知の義務化について」（4類型、速報の目安「概ね3～5日以内」、確報30日・60日）
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」（確報の追完、本人通知の時期。同上）
• 個人情報保護委員会「漏えい等の対応とお役立ち資料」（報告の窓口と様式）
• 個人情報保護委員会 FAQ Q6-19（高度な暗号化等の秘匿化）
• e-Gov法令検索「個人情報の保護に関する法律」（第26条）
• 個人情報保護委員会「大規模な漏えい等事案を踏まえた対応について（注意喚起）」（2026年10月7日）
• 個人情報保護委員会「令和8年 改正個人情報保護法について」
• 参議院「個人情報の保護に関する法律等の一部を改正する法律案」議案情報（公布日・施行時期）