TOPPANが受託する損保ジャパンの「保険料控除証明書発行サービス」運用業務での誤送付（契約者177,426名分を別の損害保険会社1社へ）
公表日
損保ジャパンから保険料控除証明書の業務を任されていたTOPPANで作業中の操作ミスが起き、損保ジャパンの契約者177,426名分の情報が別の損害保険会社1社に送られました。送られたのはカナ氏名と証券番号などで、住所や生年月日は含まれていません。
対象者は？
損保ジャパンの契約者177,426名です（同じ契約者が重複して数えられており、確認後に減る可能性があります）。送られたのはカナの氏名、保険料控除用の証券番号、業務IDだけで、漢字の氏名・住所・生年月日・電話番号・メールアドレス・クレジットカード情報・口座情報・マイナンバーは含まれていません。
損保ジャパンから、メールアドレスを登録している方にはメールで、登録していない方には封書で個別に知らせています。お客さま専用窓口（0120-175-675、平日9〜17時）も設けられています。
いますぐできること
- 損保ジャパンや保険会社を名乗る、身に覚えのない連絡で個人情報や支払いを求められても応じない。公式の窓口に自分から確認する
- 損保ジャパンから案内が届いたら、書かれている窓口の番号が公式のお知らせと同じかを照らし合わせる
何が起きたのか
TOPPANは、損害保険会社14社から「保険料控除証明書発行サービス」の運用を任されています。2026年9月1日、各社向けのデータを手作業で送る際にドラッグ＆ドロップの操作を誤り、損保ジャパンのファイルが別の損害保険会社向けのファイルに混ざったまま送られました。受け取った会社が同じ日の夕方に日本損害保険協会へ問い合わせ、翌9月2日に協会からの連絡でTOPPANが事態を把握しました。9月29日にTOPPANと損保ジャパンがそれぞれ公表しました。
なぜ起きたのか・なぜ広がったのか
外部からの攻撃やシステムの障害ではなく、作業中の操作ミスです。複数の会社向けのファイルが同じフォルダに置かれた状態で手作業で送っており、送る前にファイルの中身をもう一度確かめないまま送られました。1つの拠点で各社のデータを同じ作業の流れで扱っていたため、別の会社のデータが混ざりうる状態でした。
いまの状況2026-09-29 時点続報待ち
誤って送られた先の会社はデータを廃棄・完全削除しており、外部への流出や不正利用は確認されていません。TOPPANは送付に使っていたファイル転送サービスの配信を止め、ドラッグ＆ドロップをやめる、別の担当者が全工程を確認する、ファイルの容量や日時を元データと照合する、送付の手順をシステム化する、といった再発防止策を挙げています。重複を除いた実際の人数と、誤って送られた先の会社名は、まだ発表されていません。
企業として考えたいこと
自社では、複数の取引先あてのデータを人の手で振り分けて送っている作業はないでしょうか。送る前に、別の人が中身を確かめる仕組みはあるでしょうか。
技術的な要約
TOPPANが損害保険会社14社から受託している「保険料控除証明書発行サービス」の運用業務で、2026年9月1日、各社向けリストデータをファイル転送サービスで手作業送信する際に、運用担当者のドラッグ＆ドロップの誤操作により損保ジャパンのZIPファイルが別の損害保険会社向けのZIPファイルに混入し、そのまま送信された。誤送付は契約者177,426名分（同一契約者の重複を含み精査で減る可能性あり）で、項目はカナ氏名・保険料控除用証券番号・業務IDに限られ、漢字氏名・住所・生年月日・連絡先・カード・口座・マイナンバーは含まれない。9月1日17時15分に受領した損害保険会社が日本損害保険協会へ照会し、9月2日に協会からの調査要請でTOPPANが把握、ファイル転送サービスの配信を停止した。誤送付先はデータを廃棄・完全削除し、二次被害は確認されていない。TOPPANと損保ジャパンは9月29日に公表し、TOPPANはドラッグ＆ドロップの廃止、別担当者による全工程確認、容量・タイムスタンプ照合、送付プロセスのシステム化を再発防止策に挙げた。
公開情報が限られている点について
攻撃の分類
- 侵入口
- 内部者公表で確認外部からの攻撃ではなく、委託先（TOPPAN株式会社）の運用担当者の誤操作。TOPPANの公式発表によれば、損害保険各社へリストデータ（CSV）を手作業で送信する際、複数社向けのZIPファイルが同一フォルダに置かれた状態で、マウスのドラッグ＆ドロップ操作を誤り損保ジャパンのZIPファイルを別社向けZIPファイルに混入させ、送付前にZIP内部の内容を再確認しないまま送信した。TOPPANは『システム障害や外部からの不正アクセス、サイバー攻撃等に起因するものではない』ことを確認したとしている。悪意（内部不正）を示す記述はない。
- 脆弱性
- CVE 非公表公表で確認保険料控除証明書発行サービスの運用業務における納品（ファイル送付）プロセスソフトウェアの脆弱性ではなく業務プロセスの欠陥。TOPPAN公式発表は原因として、複数社分のZIPファイルが同一フォルダにある状態でのドラッグ＆ドロップ操作と、送付前にZIP内部の内容を再確認しなかったことを挙げる。再発防止策に『作業者とは別の確認者』を置くとしていることから、従来は作業者以外の確認工程がなかったか機能していなかったと読める（解釈）。使用したファイル転送サービスの製品名は非公表。
- 攻撃者
- 特定・主張なし
- ATT&CK
- —
影響
- 業務停止
- なし 9月2日にTOPPANが送付に使っていたファイル転送サービスの配信を停止した。保険料控除証明書の発行スケジュールへの影響は公表されていない。
- データ
- 確定上限 177,426確定 177,426人氏名その他（カナ氏名のみ、保険料控除用証券番号、業務ID）公表値は損保ジャパン契約者177,426名（『名』）。同一契約者の重複があり、精査後に減る可能性があるとされる。項目はカナ氏名・保険料控除用証券番号・業務ID（損保ジャパン発表によれば、発行年・保険会社の識別番号・証券番号を組み合わせた証明書単位のキー）で、漢字氏名、住所、生年月日、電話番号、メールアドレス、クレジットカード情報、金融機関口座情報、マイナンバーは含まれない。誤送付先は損保ジャパン以外の損害保険会社1社（社名非公表）で、対象データを速やかに廃棄・完全削除した。第三者への流出、外部ネットワークへの漏えい、不正利用は確認されていない。誤送付の事実自体は確定しているため certainty は確定とした。TOPPANは今回の納入作業で本件以外の他社データの混入はないとしている。損保ジャパンは、保険料控除用証券番号は同社固有の識別番号で単独では個人や契約を特定できないと説明している。数値・項目はTOPPAN・損保ジャパン両社の公式発表（2026-09-29）で確認。
- 波及先
- 1 社（委託元：損害保険ジャパン）
- 損害保険ジャパン株式会社（委託元。対象契約者へメールまたは封書で個別連絡、専用窓口を設置）
- 誤送付先の損害保険会社1社（社名非公表。データを廃棄・完全削除）
- 金銭影響
- —
- サプライチェーン
- 保険料控除証明書発行サービスは、2021年10月に損害保険会社、日本損害保険協会、凸版系の印刷・BPO事業者（当時トッパン・フォームズ、2023年時点ではTOPPANエッジとして参加）が業界共同で構築した、控除証明書の電子化・マイナポータル連携のための共同システムである。2026年時点でTOPPANは損害保険会社14社から運用を受託しており、各社向けデータを1拠点の同一オペレーションで扱っていた。委託先TOPPANの誤操作により、委託元である損保ジャパンの契約者データが、同じ共同システムを利用する競合の損害保険会社に送られた。検知も、受領した損保会社→日本損害保険協会→TOPPANという業界共同体制の経路で行われた。受託主体はTOPPAN株式会社であることを両社の公式発表で確認した（TOPPANの発表はTOPPAN株式会社名義、問い合わせ先はTOPPANホールディングス広報部。いずれもTOPPANエッジへの言及はない）。なお損保ジャパンの発表はサービスを『損害保険会社6社と損保協会、TOPPANが構築』と記すが、2021年の構築時の参加事業者はトッパン・フォームズ、2023年の参加事業者表記はTOPPANエッジであり（いずれも当時の資料）、凸版グループ内で担当会社の表記が変遷している。運用受託がいつTOPPAN株式会社に移ったかは公表されていない。
時系列
- 2021-10-18損害保険会社6社・日本損害保険協会・トッパン・フォームズが構築した業界共同の保険料控除証明書発行システムがサービス開始（電子化・マイナポータル連携）4
- 2023-10-16共同システムの2023年度サービス提供開始。参加は損害保険会社11社・日本損害保険協会・TOPPANエッジ5
- 2026-09-01
- 2026-09-01 17:15
- 2026-09-02
- 2026-09-29
- 2026-09-29
- 2026-09-29
- 2026-09-30セキュリティ対策Labが報道（ドラッグ＆ドロップの誤操作が原因と整理）3
- 2026-10-05セキュリティ対策Labが2026年9月の個人情報漏洩事例まとめで本件を掲載6
技術解説
業務の構造：業界共同システムの運用を1社が14社分まとめて受託 事実
保険料控除証明書発行サービスは、損害保険の保険料控除証明書（主に地震保険料控除）を電子化しマイナポータル経由でも取得できるようにするため、2021年10月に損害保険会社・日本損害保険協会・凸版系事業者が業界共同で立ち上げた仕組みである（2021年は6社、2023年は11社が参加）。損保ジャパンの発表によれば、現在は14社がTOPPANに運用業務を委託しており、TOPPANの発表によれば各社向けのリストデータをZIPファイルにまとめ、ファイル転送サービスで各社へ手作業で送信していた。つまり競合関係にある複数の保険会社のデータが、1つの委託先の同一オペレーション・同一フォルダで並行して扱われていた。この構造自体が、宛先を取り違えれば他社にそのまま顧客データが渡るリスクを内包していた。
誤送付のメカニズムと検知経路 事実
TOPPANの公式発表では、複数社向けのZIPファイルが同一フォルダに置かれ、担当者がドラッグ＆ドロップの誤操作で損保ジャパンのZIPファイルを別社向けのZIPファイルに混入させた。送信前にZIPの中身を再確認する手順が機能しておらず、そのまま送信された。誤送付は契約者177,426名分のカナ氏名・保険料控除用証券番号・業務ID。検知はTOPPAN側ではなく受領側で、受け取った損害保険会社が当日17時15分に日本損害保険協会へ照会し、翌9月2日に協会からTOPPANへ調査要請が届いて初めてTOPPANが把握した。TOPPANは同日ファイル転送サービスの配信を停止した。システム障害・不正アクセス・サイバー攻撃ではないと明言している。
なぜ17万件規模になったのか（解釈） 解釈
手作業の誤送付は通常1通・1件単位のミスで済むことが多いが、本件ではミスの単位が『1社分のバッチファイル全体』だったため、1回の操作で17万人超の契約者情報が他社に渡った。データ処理がシステム化されていても、最後の受け渡し（納品）だけが人手のファイル操作で残っていると、その一点のミスがバッチ全体の漏えいに直結する。また、送付は保険料控除証明書の発行に向けた時期の定型作業とみられ、毎年同じ手順を繰り返す中で、ZIP内容の確認が形骸化していた可能性がある（推測）。受領した側が中身を開いて他社データに気づいたから検知できたのであり、送信側には宛先とファイル内容の整合を機械的に確認する仕組みがなかったことになる。
再発防止策の評価：人の注意力から仕組みへ移せているか 解釈
TOPPANの再発防止策は、(1)ドラッグ＆ドロップを廃止し『ファイルを選択』方式に統一、(2)作業者とは別の確認者が送付までの全工程を確認、(3)添付ファイルの容量とタイムスタンプを元データと照合、(4)恒久対策として送付プロセスのシステム化、の4点。(1)〜(3)は手作業を前提にした注意喚起・二重チェックの強化で、確認者も同じ画面・同じフォルダを見る限り、同種の取り違えを完全には防げない。エンジニアの視点では、(4)のシステム化の中身が本質で、宛先社コードをファイル内部（ヘッダやマニフェスト）に埋め込み送信時に宛先と照合する、各社専用の暗号鍵で暗号化し誤送付されても復号できないようにする、宛先別の出力ディレクトリと転送ジョブを分けて人がファイルを選ばない構成にする、といった設計が考えられる（推測・提案）。
公表の評価 解釈
委託先TOPPANと委託元の損保ジャパンが同日に公表し、件数・項目・含まれない項目・原因・誤送付先での削除・再発防止策まで示した点は、委託関係の事案として透明性が高い。漏えい項目がカナ氏名と証券番号・業務IDに限られ、漢字氏名・住所・連絡先を含まないため、単体での悪用リスクは比較的低い。一方で、把握（9月2日）から公表（9月29日）まで27日を要した理由、誤送付先の削除確認の方法（証明書の取得など）、個人情報保護委員会や金融庁への報告の有無（両社の発表とも記載なし）、重複を除いた実人数は、確認できた範囲では示されていない。同じ委託先・同じ共同システムを利用する他の13社の業務に同種の手作業が残っているかも明らかでない。
対応
- 封じ込め
- 9月2日に把握後、送付に使用していたファイル転送サービスの配信を停止。誤送付先の損害保険会社が対象データを廃棄・完全削除。TOPPANは今回の納入作業で本件以外に他社データの混入がないことを確認。再発防止策としてドラッグ＆ドロップを廃止し『ファイルを選択』方式に統一、作業者とは別の確認者による全工程確認、添付ファイルの容量・タイムスタンプと元データの照合、恒久対策として送付プロセスのシステム化を進める。損保ジャパンはTOPPANに再発防止策の徹底を求め、自社の業務委託先管理体制を強化し、参画保険会社・損保協会と連携するとした。
- 公表の仕方
- 2026年9月29日にTOPPAN（受託者）と損保ジャパン（委託元）が同日公表。経緯・原因・再発防止策はTOPPANの発表に記載され、損保ジャパンの発表は発生日・原因の詳細を記さずTOPPANの発表を参照させる形。損保ジャパンは対象契約者の登録メールアドレス宛に個別案内（未登録者は封書）し、お客さま専用窓口（0120-175-675、平日9〜17時）を設置。TOPPANの報道窓口はTOPPANホールディングス広報部。両社とも当局報告の有無は記載していない。2026-10-10時点で続報（重複精査後の実人数など）は確認できていない。
- 当局対応
- —
教訓と対策
| 教訓 | 具体的な対策 |
|---|---|
| 宛先別のバッチファイルを同一フォルダで人手で扱い、1回のミスでバッチ全体が他社へ渡った | 宛先ごとに出力ディレクトリと転送ジョブ（SFTP/マネージドファイル転送のアカウント・パス）を分離し、生成処理から送信までを人がファイルを選ばないパイプラインにする。手作業が残る場合も、宛先別フォルダのACLで作業者がその宛先以外のファイルに触れられないようにする |
| 送信前にZIPの中身と宛先の整合を機械的に確認していなかった | 各ファイルに宛先社コード・件数・ハッシュを記したマニフェストを同梱し、送信ジョブが宛先アカウントの社コードと照合、不一致や想定外の件数ならブロックする。ZIP内の各データファイルの先頭行にも委託元社コードを持たせ、受領側の取込処理でも検証する |
| 誤送付された場合に受領者が中身を読めてしまう | 宛先ごとに異なる公開鍵（PGP/age等）で暗号化してから送付し、誤った宛先に届いても復号できないようにする。共有パスワード付きZIPは鍵の取り違えが起きやすく、宛先別の鍵管理に置き換える |
| 誤送付の検知が受領側の気づき頼みで、送信側に検知手段がなかった | 送信ログ（宛先・ファイル名・サイズ・ハッシュ・件数）を自動で照合レポート化し、元データの件数・サイズと突合する。委託元側でも受領データの件数・社コードを自動検証し、異常があれば委託先と業界窓口へ即時通知するフローを契約に組み込む |
| 競合する複数の委託元のデータを1つの委託先が同一オペレーションで扱う構造 | 委託元は委託先監査で、自社データが他社データとどの単位（環境・フォルダ・担当者・転送経路）で分離されているかを確認項目にし、手作業の受け渡し工程の有無と二重化・自動化の状況を年次で報告させる |
自組織などでの確認項目
- あなたの業務で、システム化されたデータ処理の最後に人手の『ファイル選択・添付・アップロード』が残っている工程はどこか。その一操作のミスで何件のデータが誰に渡りうるか。
- 複数の顧客企業のデータを扱う委託先として、顧客ごとのデータ分離は環境・フォルダ・権限・転送経路のどのレベルで実装されているか。顧客Aの担当者が顧客Bのファイルに触れられる状態はないか。
- 誤送付が起きても受領者が内容を読めないようにする（宛先別暗号化など）ことと、送信前に防ぐことのどちらに先に投資すべきか。自社の送付件数とリスクで考えると。
- ドラッグ＆ドロップ禁止や二重チェックといった『人の注意』に頼る再発防止策は、どの程度有効と言えるか。自社で同じ事故が起きたら、どの対策を恒久策として選ぶか。
未解明点
- 重複を除いた実際の対象契約者数（精査後の確定値）
- 誤送付先の損害保険会社名と、廃棄・完全削除をどのように確認したか（削除証明の有無）
- 9月2日の把握から9月29日の公表まで27日を要した理由
- 個人情報保護委員会・金融庁への報告の有無と時期
- 使用していたファイル転送サービスの種類と、送付プロセスのシステム化の具体的な内容・完了時期
- 共同システムの他の委託元13社の業務での同種手作業の有無と、運用受託がTOPPANエッジ等からTOPPAN株式会社へ移った時期
出典
- 1TOPPAN2026-09-29公式本文確認済
- 2損害保険ジャパン2026-09-29公式本文確認済
- 3セキュリティ対策Lab（Rocket Boys）2026-09-30報道本文確認済
- 4Impress Watch2021-10-19報道本文確認済
- 5あいおいニッセイ同和損害保険2023-10-16公式本文確認済
- 6セキュリティ対策Lab（Rocket Boys）2026-10-05報道本文確認済