アフラック生命保険、不正アクセスによる個人情報漏洩についての調査結果と再発防止策を金融庁へ報告|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年08月03日更新日時: 2026年08月03日

アフラック生命保険株式会社は2026年7月31日、同社の「オンライン相談」および「アフラックよりそうネット」のシステムに対する不正アクセスについて、調査結果と再発防止策を金融庁へ報告したと公表しました。漏えいした個人情報は、第二報から変更はなく、顧客約440万人、うち保険料振替口座情報が含まれる顧客約22万人、代理店約4万店分とされています。

今回の続報では、単なる件数確定だけでなく、通常利用と同様に見えるアクセス形式を直ちに不正アクセスとして検知できなかったこと、短時間の大量データ照会に対する監視・制御が不足していたこと、設計時レビューやリリース前の侵入テストで今回の手口を想定できていなかったことが説明されています。過去の第一報・第二報、金融庁の報告徴求命令とあわせて、金融機関・保険会社だけでなく、大量の個人情報を扱うWebサービス全般にとって重要な教訓を含む事案です。

アフラック不正アクセス調査結果のサマリー

アフラック生命保険は2026年7月31日、不正アクセスによる情報漏えい事案の調査結果と再発防止策を金融庁へ報告したと公表しました。
漏えい件数は顧客約440万人、うち保険料振替口座情報を含む顧客約22万人、代理店約4万店で、7月13日の第二報から変更はありません。
漏えい情報には契約者・被保険者・受取人・第二連絡先の情報、証券番号、保障内容、保険料振替口座情報などが含まれます。
マイナンバー、クレジットカード情報、メールアドレスは含まれていないと説明されています。
原因として、アクセスおよびデータ照会に対する制御不足、大量データ照会の監視・制御不足、設計時レビューや侵入テストでのリスク想定不足が挙げられています。
現時点で本事案に関わる情報の不正利用等は確認されていませんが、保険料振替口座情報や契約情報を使ったフィッシング、なりすまし、不審な電話連絡には注意が必要です。

項目	内容
公表日	第一報：2026年6月30日、第二報：2026年7月13日、調査結果・再発防止策：2026年7月31日
被害企業	アフラック生命保険株式会社
対象システム	「オンライン相談」「アフラックよりそうネット」
判明日	2026年6月25日
初回の情報漏えい発生日	2026年6月10日
漏えい情報の内容	契約者氏名・生年月日・性別・住所・電話番号、被保険者氏名・生年月日・性別、受取人氏名、証券番号、保障内容、第二連絡先の情報、保険料振替口座情報、代理店代表者氏名・代理店住所・代理店電話番号など
漏えい件数	顧客約440万人、うち保険料振替口座情報を含む顧客約22万人、代理店約4万店
含まれない情報	マイナンバー、クレジットカード情報、メールアドレス
発生原因	アクセスとデータ照会に対する制御不足、大量データ照会の監視・制御不足、設計時レビュー・侵入テストでのリスク想定不足
対応状況	関連システムを停止、対象顧客への文書発送を7月30日に完了、保険料振替口座情報が含まれる顧客について金融機関と連携、調査結果と再発防止策を金融庁へ報告
個人情報保護委員会への報告状況	アフラックの公表資料で確認できる範囲では、個人情報保護委員会への直接報告完了という表現は確認できません。一方で、金融庁から保険業法第128条第1項および個人情報の保護に関する法律第146条第1項に基づく報告徴求命令を受領し、7月31日に金融庁へ調査結果と再発防止策を報告しています。
不正利用の確認状況	現時点で本事案に関わる情報の不正利用等は確認されていないと説明されています。

何が起きたか

アフラック生命保険の「オンライン相談」および「アフラックよりそうネット」のシステムが、第三者による不正アクセスを受けました。これにより、顧客や代理店の個人情報を含む一部情報が漏えいしたことが2026年6月25日に判明し、同社は同日、情報漏えいの拡大を防ぐために関連システムを停止しています。

当初の第一報では、不正アクセスが最初に発生した日は2026年6月15日とされていました。その後の調査により、第二報では情報漏えいが最初に発生した日が2026年6月10日に修正されています。7月31日の調査結果でも、この初回発生日は2026年6月10日とされています。

アフラックは、社内および外部専門機関による調査を行い、「オンライン相談」と「アフラックよりそうネット」以外のシステムでは、本事案と同種または類似の情報漏えいはないことを確認したと説明しています。

当サイトでは本事案について、第一報の段階でアフラック生命保険、不正アクセスで約438万人の顧客の個人情報漏洩-約23万人は保険料振替口座情報も対象として取り上げ、その後、アフラック生命保険不正アクセスによる個人情報漏洩で金融庁から報告徴求命令を受領として金融庁の報告徴求命令についても記事化しています。今回の7月31日公表は、これらの続報にあたります。

過去公表から見た経緯

本事案は、6月25日に情報処理装置の高負荷を検知したことが調査の端緒になりました。アフラックのFAQでは、2026年6月25日6時30分にCPUの高負荷状況を検知し、調査により「アフラックよりそうネット」などのシステムで第三者から不正アクセスを受けたことが判明したと説明されています。

2026年6月30日の第一報では、顧客約438万人、うち保険料振替口座情報を含む顧客約23万人、代理店約4万店分が対象とされていました。7月13日の第二報では、初回の情報漏えい発生日が6月10日に修正され、漏えい件数も顧客約440万人、うち保険料振替口座情報を含む顧客約22万人に更新されています。7月31日の調査結果では、漏えいした個人情報の内容と件数は第二報から変更がないとされています。

金融庁は6月30日、アフラックに対して保険業法第128条第1項および個人情報の保護に関する法律第146条第1項に基づく報告徴求命令を発出しました。アフラックは7月1日にその受領を公表し、不正アクセスの手口、事実関係、顧客対応状況、原因分析、再発防止策などについて金融庁に報告すると説明していました。7月31日の公表は、その調査結果および再発防止策を金融庁へ報告したという位置づけです。

漏えいした個人情報

顧客関連の漏えい情報には、

契約者の氏名、生年月日、性別、住所、電話番号のほか、被保険者の氏名、生年月日、性別、受取人氏名、証券番号、保障内容、第二連絡先の情報、保険料振替口座情報などが含まれます。

第二連絡先の情報は、緊急時などに契約者と連絡が取れない場合の連絡先として指定された親族等の氏名、生年月日、性別、住所、電話番号です。

保険料振替口座情報には、金融機関名、支店名、預金種類、口座番号、口座名義などが含まれます。アフラックは、保険料振替口座情報が含まれる一部顧客について、二次被害の防止に向けて関係する金融機関と順次連携していると説明しています。

一方で、マイナンバー、クレジットカード情報、メールアドレスは含まれていないとされています。

メールアドレスが含まれない点はフィッシングメールの観点では限定要素になりますが、氏名、住所、電話番号、契約情報、口座情報の一部が含まれるため、電話や郵送を使ったなりすまし、保険契約を装った不審な連絡、金融機関や保険会社をかたる確認依頼には注意が必要です。

代理店関連では、代理店代表者氏名、代理店住所、代理店電話番号などが漏えい対象です。件数は約4万店で、過去にアフラックと代理店業務委託契約を締結し、現在は委託業務を行っていない代理店も含まれるとされています。

発生原因

7月31日の調査結果で注目すべき点は、攻撃手法そのものの詳細ではなく、アプリケーション側の制御と監視の不足が原因として説明されている点です。アフラックは、「オンライン相談」および「アフラックよりそうネット」のシステムにおいて、今回の攻撃で使われたアクセスとデータ照会の手口に対する制御が不十分だったとしています。

同社の説明によれば、対象システムには不正アクセスを検知・遮断する機能が備わっていました。しかし、今回のアクセス形式が通常利用時と同様だったため、不正アクセスとして直ちに検知できませんでした。さらに、短時間に大量のデータ照会があった場合に監視・制御する機能が不足していたことも確認されています。

実務目線で見ると、これは単にWAFや不正アクセス検知装置を入れていれば十分という話ではありません。正規の画面遷移やAPI呼び出しに見えるアクセスであっても、照会件数、照会速度、利用者ごとの権限範囲、通常行動からの逸脱、連続取得の兆候をどこまでアプリケーション側で制御できているかが問われます。

アフラックは、システム設計時のセキュリティレビューやシステムリリース前の侵入テストを実施していたものの、今回の攻撃で使われた手口に関するリスクを想定できていなかったとも説明しています。不正アクセスとは-定義・件数・手口・目的・防止策を専門家が解説でも触れている通り、不正アクセス対策は認証強化だけでなく、認可、監視、ログ分析、異常行動検知を含めて設計する必要があります。

再発防止策

アフラックは再発防止策として、アクセスおよびデータ照会における制御の強化を挙げています。具体的には、システムへのアクセス時の認証、データ照会時の認可を強化するとしています。今回のように情報参照が問題になる事案では、ログインできるかどうかだけでなく、ログイン後にどの範囲のデータを、どの条件で、どの量まで参照できるかが重要になります。

大量アクセスに対する監視と制御も強化対象です。アプリケーションおよびセキュリティ対策機器において、大量アクセスへの監視と制御を強化するとされています。保険契約情報のように高い機微性を持つデータでは、通常業務での参照パターンを踏まえたしきい値設計、連続照会の制限、異常検知時の一時停止、調査用ログの保全が欠かせません。

設計時のセキュリティレビューやリリース前の侵入テストについても、不正アクセスのリスクを多層的に分析し、セキュリティ要件を最新化することで実効性を高めるとしています。形式的なチェックリスト消化ではなく、業務フロー、権限設計、API、データ照会、ログ監視、運用時の検知対応まで含めてレビューする体制が求められます。

情報セキュリティ管理態勢については、セキュリティ標準・基準の再整備、セキュリティレビューの強化、システムリリース前の検証強化、リリース後の監視体制強化、継続的な改善活動の強化が示されています。さらに、人財の増強や体制の強化も含めて取り組むとしています。

金融庁への報告と責任の所在

アフラックは2026年7月31日、本事案に関する調査結果および再発防止策を金融庁へ報告したと公表しました。6月30日に金融庁から保険業法および個人情報保護法に基づく報告徴求命令を受けていたため、今回の報告は行政対応上も重要な節目になります。

責任の所在を明確にする対応として、情報セキュリティ管理態勢の強化について管理監督責任を有する役員が、報酬の一部を自主返納することも公表されています。対象は、代表取締役会長、代表取締役社長、取締役専務執行役員チーフ・デジタル・インフォメーション・オフィサー、常務執行役員チーフ・リスク・オフィサーです。

役職	氏名	報酬返納額
代表取締役会長	チャールズ・レイク	月額報酬の30%×1カ月
代表取締役社長	古出眞敏	月額報酬の30%×1カ月
取締役専務執行役員チーフ・デジタル・インフォメーション・オフィサー	二見通	月額報酬の20%×1カ月
常務執行役員チーフ・リスク・オフィサー	長瀬昭	月額報酬の20%×1カ月

大規模な情報漏えい事案では、技術的な再発防止策だけでなく、経営管理、リスク管理、システム開発プロセス、リリース後監視の責任範囲をどのように整理するかが問われます。今回の公表では、単に外部から攻撃を受けたという説明にとどまらず、管理態勢の再評価と役員報酬の自主返納まで踏み込んだ点が特徴です。

システム停止と顧客対応

「オンライン相談」および「アフラックよりそうネット」は、不正アクセス判明後に関連システムとして停止されています。7月31日の公表時点では、再発防止策の確実な実行を前提として、一日も早い再開を目指すと説明されており、再開時期はアフラックのオフィシャルホームページで案内するとされています。

顧客対応では、該当する顧客に対して7月10日からお詫びとお願いの文書を送付し、7月30日に発送を完了したとしています。第二報では、保険料振替口座情報が含まれる顧客から優先的に文書を発送すると説明されていました。

現時点で不正利用等は確認されていないとされていますが、アフラックは、不審な連絡を受けた場合や、保険料振替口座における不審な取引などの懸念が生じた場合には、同社連絡先へ連絡するよう案内しています。

利用者が注意すべき二次被害リスク

本事案では、メールアドレスは漏えい対象に含まれていないとされています。そのため、メールアドレスを直接使った標的型フィッシングのリスクは、メールアドレス漏えいを伴う事案と比べれば異なります。ただし、住所、電話番号、契約情報、保障内容、証券番号、口座情報の一部が含まれる点を軽く見るべきではありません。

特に注意したいのは、保険会社や金融機関をかたる電話、SMS、郵送物です。契約情報や口座情報の一部を知っている相手から連絡が来ると、利用者側は正規の連絡だと誤認しやすくなります。本人確認、口座確認、返金手続き、セキュリティ確認、補償手続きなどを名目に、追加の個人情報、認証情報、ワンタイムパスワード、キャッシュカード情報を聞き出す手口には警戒が必要です。

保険契約に関する情報は、病歴そのものが含まれていない場合でも、保障内容や契約関係者の情報から生活状況や家族構成を推測される可能性があります。企業側のインシデント対応では、漏えい項目を単に一覧化するだけでなく、それらを組み合わせた場合にどのような詐欺やなりすましが起こり得るかまで想定して、利用者向け注意喚起を設計する必要があります。

情報システム部門への示唆

今回の事案は、正規の利用と見分けにくいアクセスが大量照会につながった場合、一般的な不正アクセス検知だけでは止めきれないことを示しています。情報システム部門は、ログイン認証、WAF、EDR、IDS/IPSといった入口対策だけでなく、アプリケーション内部の認可設計とデータ照会制御を点検する必要があります。

優先して確認したいのは、利用者や代理店、社内担当者、外部連携先ごとに、参照できるデータ範囲が最小限に制限されているかです。画面上では制限されていても、APIや検索条件、ID指定の照会で本来見えるべきでない情報を取得できる場合があります。権限境界をまたいだデータ参照、連番IDの探索、大量検索、ページングを使った連続取得は、Webアプリケーション診断や侵入テストで重点的に確認すべき項目です。

監視面では、短時間の大量照会、通常時間帯から外れた連続アクセス、特定アカウントや特定IPからの異常な参照件数、検索条件の偏り、APIレスポンス量の急増を検知できるかを確認してください。セキュリティ機器のログだけでは業務上の不自然さを把握できない場合があるため、アプリケーションログ、監査ログ、業務ログを相関して見る設計が必要です。

リリース前のセキュリティレビューと侵入テストも、認証突破や脆弱性検出だけに偏らないよう見直すべきです。今回のような事案では、仕様上は正規に見える操作が、攻撃者にとって大量データ取得の経路になることがあります。開発段階で、誰が、どの条件で、どのデータを、どの量まで取得できるのかを明文化し、異常時の遮断や通知まで含めてセキュリティ要件に落とし込むことが重要です。

組織面では、重大インシデント発生後の顧客通知、監督官庁対応、金融機関との連携、コールセンター体制、FAQ更新、再発防止策の進捗モニタリングまで一連の流れとして準備しておく必要があります。特に保険、金融、医療、通信、公共分野のように大量の個人情報と契約情報を扱う組織では、二次被害を前提にした利用者向け説明と、問い合わせ窓口のなりすまし対策も平時から整備しておくべきです。