TL;DR
2026 年 9 月 1 日、TOPPAN が保険料控除証明書発行サービスの運用業務で、損害保険ジャパン（損保ジャパン）の契約者 177,426 名分（重複を含む可能性がある）のリストを、他の損害保険会社 1 社に誤送付した。複数社分の ZIP ファイルが同じフォルダに並ぶなかで、ドラッグ＆ドロップの操作を誤り、損保ジャパン分が他社向けの ZIP に入った。送付前に ZIP の中身は再確認されていなかった。受け取った保険会社は混入に気づき、同日のうちに日本損害保険協会へ照会している。検出は効いていた。効かなかったのは、配信の前に、宛先と中身の対応を作業者の操作とは別に確かめる層である。
何が起きたか
- 業務: 保険料控除証明書発行サービスの運用。同サービスは損保ジャパンを含む損害保険会社 6 社と日本損害保険協会、TOPPAN が構築し、現在は損害保険会社 14 社が TOPPAN に運用業務を委託している（損保ジャパンの発表による）。
- 誤送付の内容: 損保ジャパンの契約者のうち、控除証明書ハガキの発行が不要となる契約者のリスト（CSV 形式）。他の損害保険会社 1 社に送られた。
- 件数: 177,426 名。同一契約者の重複を含む可能性があり、今後の精査で減ることがある。
- 含まれる項目: カナ氏名、保険料控除用証券番号、業務 ID（控除証明書の発行年・損害保険会社の識別番号・対象契約の証券番号を組み合わせた、証明書単位のユニークキー）。漢字氏名・住所・生年月日・電話番号・メールアドレス・クレジットカード情報・金融機関口座情報・マイナンバーは含まれない。
- 原因の区分: 手作業による誤操作と確認手順の不備。システム障害や外部からの不正アクセス、サイバー攻撃によるものではないと TOPPAN は確認している。
- 当事者の説明: 損保ジャパンは、誤送付先の保険会社に連絡し、データが完全に削除されたことを確認したとしている。外部への二次流出や情報の不正利用の事実は、現時点で確認されていないとする。TOPPAN も、送付先で廃棄・完全削除されており、第三者への流出や外部ネットワークへの漏えいは現時点で確認されていないとしている。今回の納入作業での他社データの混入は本件のみ、と TOPPAN は確認している。
誤送付は次の連鎖で起きている。
- 損害保険各社へ渡すリストデータが、社ごとの ZIP ファイルにまとめられ、複数社分が同じフォルダに並んでいた。
- 運用担当者がマウスのドラッグ＆ドロップ操作を誤り、損保ジャパン分の ZIP を、他社向け ZIP の中にコピーした。
- 送付前に、ZIP の内部は再確認されなかった。
- ファイル転送サービスで他社向けとして配信され、損保ジャパン分が送付先に届いた。
配信の時点で、ZIP の中身が宛先に対応しているかを確かめていたのは、作業者の目と手順だけだった。
時系列 — 公表と対応
- 2026-09-01: 手作業でのデータ送信時に誤送付が発生。同日 17 時 15 分、送付先の損害保険会社が、他社契約者情報の混入について日本損害保険協会へ照会した。
- 2026-09-02: 協会から TOPPAN へ調査要請があり、混入が判明。TOPPAN は判明後ただちに調査を開始し、ファイル転送サービスの配信を停止した。
- 2026-09-29: TOPPAN と損保ジャパンが同日に公表。
本件の事実関係は、TOPPAN と損保ジャパンの公式発表に拠る。発生日と判明までの経緯、発生原因、再発防止策は TOPPAN の発表にのみ記載があり、損保ジャパンの発表はそれらを TOPPAN のリリースに委ねている。件数と項目は両社の発表で一致している。削除の確認と流出が確認されていないことは、当事者の発表である。
公表後の対応と再発防止策は次のとおり。
- 対象契約者への案内: 損保ジャパンが、同サービスに登録されたメールアドレス宛に個別の案内を順次送信し、未登録の契約者には封書を送る。
- TOPPAN の再発防止策: ファイル添付を「ファイルを選択」に統一する、作業者とは別に確認者を置いて全工程を確認する、添付ファイルの容量とタイムスタンプを元データと照合する。恒久対策として、送付プロセスのシステム化を進める。
- 損保ジャパン（誤送付先への対応）: 誤送付先の保険会社に速やかに連絡し、データの削除が行われたことを確認したとしている（日付の記載は無い）。
- 損保ジャパン（今後の対応）: 同サービスに参画する損害保険会社および損保協会と連携のうえ、TOPPAN に再発防止策の徹底を求めていくとともに、業務委託先に対する管理体制の一層の強化に努めるとしている。
混入への気づきは発生当日、公表は発生の 28 日後である。気づきは送付元ではなく、受け取った側から来ている。
なぜ止まらなかったか
この事案の失敗は、外部からの攻撃でも、作業者ひとりの不注意でもない。配信という後戻りできない実行の前に、宛先と中身の対応を、作業者の操作とは別に確かめる層が無かったことにある。
検出は効いていた。受け取った保険会社が、自社分でないデータに気づき、同日のうちに協会へ照会した。ただしその時点で、177,426 名分のリストはすでに社外に出ている。取り返しがつかなくなったのは配信であり、効かなかったのはその手前、「この ZIP は、この宛先に送ってよい中身か」を配信の直前に問う一段である。中身を決めていたのは作業者の操作であり、それを宛先と照らす仕組みは無かった。
TOPPAN の再発防止策のうち、ファイル選択の統一、作業者とは別の確認者、容量とタイムスタンプの元データとの照合は、人の確認を厚くする方向にある。容量の照合は、今回のように ZIP が丸ごと紛れ込む混入なら捉えうる。ただし容量とタイムスタンプが一致することは、中身がその宛先のものであることを直接には示さない。送付のシステム化は人手そのものを減らすが、宛先と中身の対応を、何に基づいて確かめたかを独立に検証できる形にしない限り、その対応は依然として手順と担当者に残る。
同じ構造は、これまでの Brief にも現れている。北海道の国立病院の HDD では「破砕した」という前提が確かめられないまま媒体が中古市場に流れ、支払基金の目視確認では「1 秒以上表示された」という記録が、人が確認したことの証拠にならなかった。Revolut では、要求者の権限が確かめられないまま、数か月にわたり顧客データが渡された。いずれも、後戻りできない一段の手前が、独立に確かめられない人の前提に委ねられていた。
「送付前に ZIP ファイル内部の内容を再確認していませんでした」——TOPPAN の発表
証明があれば、何が変わるか
複数社分のデータを一つの運用者がまとめて扱う委託そのものは、やめる必要がない。事前証明が経路に一段挟まるとすれば、それは作業者の確認を増やすことではなく、「このファイルの中身は、どの保険会社のデータか」と「その保険会社のデータを、この宛先に送ってよいか」を、配信の直前に機械的に照合する一段である。
Lemma がこの落差に対して提示する設計は次の通りである。
- 中身に来歴を束縛する：配信するファイルの一つひとつに、どの保険会社の業務データかを示す来歴の証明を、データを作る段階で付ける。配信前の照合は ZIP を入れ子まで開き、中のファイルを一つずつ確かめる。
- 宛先ごとに受け取れる範囲を決めておく：宛先ごとに、受け取ってよい保険会社と様式をあらかじめ登録し、範囲外の来歴を持つファイルを含む配信は、実行の前に止める。来歴の証明を持たないファイルを含む配信も、同じく止める。
- 照合の結果を、操作とは別の記録に残す：どの証明に基づいて配信が通ったかを、作業者の操作ログとは別に残し、後から監査できるようにする。
事後の検出との違いはここにある。検出は、届いた側が見慣れないデータに気づくことで働く。気づいた時点で、データはすでに手を離れている。証明は、宛先と中身の対応を配信の前に問う。検出の層と、この層は代替ではなく補完の関係にある。
注：宛先ごとの範囲の登録そのものが誤っていれば、誤った配信も通る。また、送付先に届いた後の削除や二次利用の有無は、この照合の対象に含まれない。
Sources
- TOPPAN（一次・企業公式）: 「当社受託『保険料控除証明書発行サービス』運用業務におけるデータ誤送付について」（2026-09-29） — https://www.holdings.toppan.com/ja/info/toppan_info20260929.pdf
- 損害保険ジャパン（一次・企業公式）: 「『保険料控除証明書発行サービス』における業務委託先のデータ誤送付について」（2026-09-29） — https://www.sompo-japan.co.jp/-/media/SJNK/files/news/2026/20260929_1.pdf?la=ja-JP
本件の一次資料は当事者（TOPPAN・損保ジャパン）の公式発表のみで、本Brief執筆時点で、独立した第三者による検証は確認できていない。誤送付先の損害保険会社の名称は公表されていない。