2026.10.06 セキュリティ

第一生命の不正アクセスと従業員12万人分の情報｜退職者データを残さない人事システムの設計

第一ライフグループと第一生命保険は2026年10月2日、両社が使う従業員向け人事システムへの不正アクセスを9月24日に検知したと公表しました。閲覧され外部に流出した可能性があるのは約12万人分で、そのうち約7万人は退職した人の情報です。内勤職員は1967年以降の退職者まで対象に入っています。本記事では、公式発表の内容を整理したうえで、人事システムを運営する側が退職者データをいつまで持つべきかを法令の条文で確かめ、期限を過ぎた個人項目を消す手順を手元で動くSQLとPythonで示します。

まとめ：第一生命の人事システム不正アクセスで公表された事実と運営側の点検

確定しているのは次の事実です。2026年9月24日に人事システムへの不正アクセスを検知し、10月2日に公表しました。対象は約12万人で、内訳は従業員約5万人と退職者約7万人です。項目は従業員番号、氏名、住所、電話番号、性別、所属、職位（資格）、職務、管理職上司氏名の9つで、公表時点でお客さま情報への不正アクセスは確認されていません。原因は「第三者による不正アクセス」とだけ書かれ、侵入経路と手口は明らかにされていません。

手口が分からない以上、原因は断定できません。それでも、約60年前の退職者の住所までが同じシステムから読める状態だった、という公表事実は残ります。人事システムを持つ企業は、退職者の個人項目を法定の保存期間を超えて持ち続けていないか、上長名を含む名簿が漏れたときになりすましに備えられているか、の2点をまず確かめてください。

項目	公表されている内容
不正アクセスの検知	2026年9月24日
公表	2026年10月2日
対象者数	約12万人
うち従業員	約5万人（内勤約1.3万人・営業約3.7万人）
うち退職者	約7万人
退職者の範囲	内勤は1967年以降・営業は2017年以降
お客さま情報	不正アクセスは確認されていない
侵入経路と手口	未公表

公式発表を確認する｜9月24日の検知から10月2日の公表までの事実関係

9月24日に人事システムへの不正アクセスを検知し10月2日に公表した経緯

第一ライフグループと第一生命の「退職された皆さまへのお知らせ」（2026年10月2日）によると、両社は9月24日に、両社が利用する従業員向け人事システムへの不正アクセスを検知しました。そのうえで、同システムに保存されていた従業員と退職者の個人情報が第三者に閲覧され、外部へ流出した可能性があると確認しています。

検知から公表までは8日です。お知らせの宛先が「退職された皆さま」となっている点に注目してください。在籍中の従業員には社内の経路で連絡できますが、退職者の中には登録された連絡先が古くなっている人もいるため、公表で広く知らせる形を取ったと考えられます。お知らせは、新たに知らせるべき事項が判明すれば速やかに知らせるとしており、続報で範囲や原因が変わる可能性があります。

約12万人の内訳と内勤職員は1967年以降・営業職員は2017年以降という対象範囲

対象者は約12万人です。従業員が約5万人（内勤職員約1.3万人、営業職員約3.7万人）、退職者が約7万人と内訳が示されています。対象者のうち約58%を退職者が占めている計算です。

退職者の範囲は職種で分かれており、内勤職員は1967年以降、営業職員は2017年以降に退職した人が対象です。第一フロンティア生命保険や第一ネオ生命保険などのグループ会社への出向者と、在籍型出向として勤務した人も含まれます。内勤職員については約59年分の退職者が人事システムに残っていたと読める内容です。同じ生命保険業界の事案としては、権限設定の不備が原因だった生命保険協会の契約照会システム情報漏えいも参考になります。

流出した可能性のある9項目とお客さま情報への影響が確認されていない点

流出した可能性がある項目は、従業員番号、氏名、住所、電話番号、性別、所属、職位（資格）、職務、管理職上司氏名の9つです。生年月日、口座番号、マイナンバーは列挙されていません。

お知らせは、公表時点でお客さま情報への不正アクセスは確認されておらず、退職者に関する二次被害も確認されていないとしています。漏れた可能性があるのは顧客ではなく従業員の情報です。ただし、所属と上長の氏名が組み合わさっている点は、後で述べるなりすましの材料として軽く見られません。

対象となった退職者と従業員が今やること｜不審な電話・郵便物への備え

両社は、不審な電話、郵便物、身に覚えのない請求に注意するよう呼びかけています。住所と電話番号に加えて在籍時の所属と上司の名前が知られているため、「人事部の者ですが」「元上司の○○さんの件で」と切り出す連絡は本物らしく聞こえます。

対象の人は、会社を名乗る連絡を受けたら、その場で個人情報や口座情報を答えず、公式の窓口へかけ直して確かめてください。問い合わせは、お知らせに記載の問い合わせフォームが第一の窓口で、フォームが難しい場合は人事部窓口（平日9時〜17時）に電話できます。

公表事実から読める論点｜約59年分の退職者データが同じ場所にあった構図

侵入経路と手口は未公表・原因の説明を推測で埋めてはいけない部分

お知らせの原因欄は「第三者による不正アクセスを受けたため」の一文だけです。人事システムが自社運用かクラウドサービスか、侵入に使われた認証情報や脆弱性、閲覧の期間は公表されていません。

公表から確定できるのは三つです。人事システムが不正アクセスを受けたこと、そこに退職者約7万人分の個人項目が残っていたこと、項目に管理職上司氏名が含まれていたことです。本記事は侵入の原因を推測しません。以降は、残っていたデータの量と種類を、自社で同じように抱えていないかを確かめる手順に絞ります。侵入の痕跡を調べる側の手順は不正アクセスのログ確認・解析方法にまとめています。

対象者の6割近くが退職者という構成が示す人事システムの保管設計の論点

侵入を完全に防ぐことは誰にもできませんが、侵入されたときに読まれる量は設計で減らせます。今回、対象者の約58%は退職者でした。退職者の氏名と住所が人事システムに残っていなければ、漏えいの規模はその分だけ小さかったことになります。

人事システムでは、退職処理をしても従業員マスタの行は消さず、在籍区分を「退職」に変えるだけの作りがよく見られます。給与や評価の履歴とひも付いているため、行を消すと過去の集計が崩れるからです。その結果、退職者の連絡先は誰も見ないまま何十年も残ります。退会者のデータを残していて被害が広がった事例はタイムズカーの不正アクセスと免許証画像160万件の流出でも扱いました。

上長名と所属がそろった名簿がなりすましメールの材料になる理由

9項目のうち管理職上司氏名は、ほかの漏えい事案ではあまり見ない項目です。所属、職位、上司の名前がそろうと、組織図に近い情報が手に入ります。攻撃者は「誰に」「誰の名前で」連絡すれば信じてもらえるかを知ることになります。

IPAのビジネスメール詐欺（BEC）対策のページは、手口の類型として取引先へのなりすましと経営者などへのなりすましを挙げています。上司の名前で部下に送金や情報提供を求める連絡は、後者の型にそのまま当てはまるものです。標的型攻撃メールの見分け方は標的型攻撃とは？手口の種類と標的型攻撃メールの見分け方で整理しています。

法定保存期間を確かめる｜労働基準法109条と個人情報保護法22条の要件

労働者名簿の保存は退職日から5年・経過措置で当分の間は3年という基準

労働基準法の109条は、使用者に労働者名簿、賃金台帳、雇入れや解雇などの労働関係に関する重要な書類を5年間保存するよう求めています。同法の附則143条1項により、当分の間はこの「五年間」が「三年間」と読み替えられます。

期間をいつから数えるかは、労働基準法施行規則の56条が決めています。労働者名簿は、労働者の死亡、退職、解雇の日が起算日です。つまり労働者名簿としての保存義務は、退職日から3年（本則で5年）で終わります。1967年に退職した人の住所を2026年まで持ち続ける義務は、労働基準法からは出てきません。賃金台帳の起算日や電子保存の扱いは給与明細の保管期間：賃金台帳の5年・起算日と退職者データの設計で詳しく扱っています。

利用する必要がなくなった個人データを遅滞なく消去する努力義務

個人情報保護法の22条は、個人情報取扱事業者に、利用する必要がなくなった個人データを遅滞なく消去するよう努めることを求めています。罰則のない努力義務ですが、退職者の連絡先を「念のため」に残し続ける理由にはなりません。

一方で、退職者のデータを全部消せばよいわけでもありません。退職金や企業年金の支給が続く人、係争中の人、再雇用の候補として本人の同意を得て残している人もいます。設計では、法定の保存期間、社内で決めた利用目的、例外の3つを分けて扱い、期限が来たら氏名や住所など個人を特定する項目から順に消していくのが現実的です。

期限切れの退職者データを棚卸しして消去するSQLとPythonの実装手順

在籍・退職5年以内・5年超に分けて人数を数える人事データの棚卸しSQL

最初にやるのは、いま何人分の退職者データが、どの項目付きで残っているかを数えることです。従業員テーブルに退職日の列（在籍中はNULL）がある前提で、次のSQLで3つの区分に分けて数えます。SQLiteの構文で、保存年数は本則の5年で書いています。

SELECT CASE
         WHEN retired_on IS NULL THEN '在籍'
         WHEN date(retired_on, '+5 years') >= date('now') THEN '退職5年以内'
         ELSE '退職5年超'
       END AS bucket,
       COUNT(*) AS people,
       SUM(name IS NOT NULL) AS with_name,
       SUM(supervisor_name IS NOT NULL) AS with_supervisor,
       MIN(retired_on) AS oldest_retired_on
FROM employees
GROUP BY bucket
ORDER BY bucket;

在籍2人、2024年退職1人、1967年から2021年に退職した4人を入れた架空のデータで、2026年10月6日に実行した結果です。

在籍 | 2 | 2 | 2 |
退職5年以内 | 1 | 1 | 1 | 2024-12-31
退職5年超 | 4 | 4 | 4 | 1967-03-31

「退職5年超」の行で、with_nameとwith_supervisorが0になっていなければ、保存期間を過ぎた氏名や上長名が残っています。oldest_retired_onは最も古い退職日で、今回の事案でいえば1967年がここに出ることになります。

保存期限を過ぎた退職者の氏名・住所・上長名を消すPythonスクリプト

次のスクリプトは、保存年数を超えた退職者を抽出し、–applyを付けたときだけ氏名、住所、電話番号、上長名をNULLにします。従業員番号と退職日は残すため、給与履歴などとのひも付けは崩れません。Python 3の標準ライブラリだけで動きます。retention_check.pyとして保存します。

import sqlite3, sys
from datetime import date

DB = sys.argv[1] if len(sys.argv) > 1 else "hr.db"
YEARS = int(sys.argv[2]) if len(sys.argv) > 2 else 5
APPLY = "--apply" in sys.argv
today = date.today().isoformat()

con = sqlite3.connect(DB)
rows = con.execute(f"""
SELECT employee_no, retired_on
FROM employees
WHERE retired_on IS NOT NULL
  AND date(retired_on, '+{YEARS} years') < date(?)
  AND name IS NOT NULL
ORDER BY retired_on""", (today,)).fetchall()

print(f"基準日={today} 保存年数={YEARS} 期限切れの退職者={len(rows)}件")
for no, d in rows[:5]:
    print(f"  {no} 退職日={d}")

if APPLY and rows:
    con.executemany("""
    UPDATE employees
    SET name=NULL, address=NULL, phone=NULL, supervisor_name=NULL,
        minimized_on=?
    WHERE employee_no=?""", [(today, no) for no, _ in rows])
    con.commit()
    print(f"{len(rows)}件の氏名・住所・電話番号・上長名を消去しました")

同じ架空データで、2026年10月6日に確認なし、消去あり、再確認の順に実行した結果です。

$ python retention_check.py hr.db 5
基準日=2026-10-06 保存年数=5 期限切れの退職者=4件
  R1967 退職日=1967-03-31
  R1990 退職日=1990-09-30
  R2015 退職日=2015-06-30
  R2021 退職日=2021-03-31

$ python retention_check.py hr.db 5 --apply
基準日=2026-10-06 保存年数=5 期限切れの退職者=4件
  R1967 退職日=1967-03-31
  R1990 退職日=1990-09-30
  R2015 退職日=2015-06-30
  R2021 退職日=2021-03-31
4件の氏名・住所・電話番号・上長名を消去しました

$ python retention_check.py hr.db 5
基準日=2026-10-06 保存年数=5 期限切れの退職者=0件

2021年3月31日に退職した人は、5年を過ぎた2026年4月以降に対象になります。2024年に退職した人は残ります。最初は–applyを付けずに一覧だけ出し、人事と法務で例外の人を確認してから本番で消してください。月に1回のバッチにしておけば、期限を迎えた人から順に消えていきます。

消去の前に決めておく例外｜退職金・企業年金・訴訟対応で残す項目

実際の人事システムでは、例外の人を消去の対象から外す列（例：retention_hold）を足し、WHERE句で除外します。理由と期限も一緒に記録しておくと、例外が増え続けるのを防げます。

退職者の統計（勤続年数や離職率の推移）を分析に使いたい場合は、氏名や住所を消したあとの行で分析は可能です。個人を特定できない形で分析用に残す方法は仮名加工情報とは？作成基準と利用制限を分析基盤の設計要件に翻訳して解説で解説しています。消すのが難しい場合でも、退職者の行を在籍者と別のテーブルや別のデータベースに移し、日常の画面やAPIから読めないようにするだけで、侵入されたときに読まれる範囲は狭まります。

従業員情報が漏れた後の対策｜上長を騙るメールと電話への備え方

管理職上司氏名を使ったなりすましに備える送金・情報提供の確認手順

名簿が漏れたあとに会社側で打てる手は、なりすましの連絡が届いても実害につながらない手順を決めておくことです。具体的には次の4点を社内で周知します。

上司や人事部の名前で、送金、口座変更、個人情報の提出を求めるメールやチャットが来たら、返信ではなく社内の電話帳の番号にかけ直して確かめる
メールゲートウェイで、表示名が社内の役職者と同じなのに送信元が社外のドメインになっているメールに警告を付ける
退職者向けの連絡は公式サイトと書面に限り、電話で口座や個人情報を聞かないことを公表しておく
問い合わせ窓口に、なりすまし連絡の報告を受け付ける項目を設け、件数を記録する

声や映像まで使ったなりすましの実例と検知の方法はディープフェイク詐欺とは？BEC・音声クローンの手口と実装者向けの検知・防御で扱っています。あわせて、第三者の不正アクセスによる漏えいのおそれは、件数にかかわらず個人情報保護委員会への報告と本人への通知の対象になる類型です。対応の流れは個人情報保護委員会の漏えい等の対応とお役立ち資料と、社内向けに段取りを整理した個人情報保護委員会への報告義務で確認できます。

人事システムの退職者データを今すぐ見直すべき企業と後回しでよい企業

自社サーバーや自社開発の人事システムに退職者を数十年分残している企業

自社サーバーで動く人事システムや、自社向けに開発した人事システムを長く使っている企業は、本記事の棚卸しSQLに相当する集計を今月中に回してください。「退職5年超」の人数と最も古い退職日を出すだけで、残しすぎかどうかはすぐに分かります。システムを入れ替えるたびに旧システムのデータを全件移行してきた企業ほど、古い退職者が多く残っている傾向があります。

結果が数千人規模になったら、例外の洗い出し、消去バッチ、退職者データの別保管の3つを改修として計画します。自社だけで設計しきれない場合は、人事・労務管理システム開発で、保存期限の管理と消去機能の追加を既存システムの改修として相談できます。

クラウド型人事サービスの標準機能で保管期限を管理している企業

クラウド型の人事サービスを使い、退職者データの保存期限や自動削除を標準機能で設定している企業では、自前でスクリプトを組む運用は過剰です。その場合は、設定画面で保存期限が実際に有効になっているか、管理者アカウントに多要素認証がかかっているかを確かめれば足ります。

判断に迷うのは、旧システムから移行した退職者データがサービスの外（ファイルサーバーやCSV）に残っている場合です。人事システム本体が整っていても、移行時の書き出しファイルが共有フォルダに置かれたままでは、同じ量の情報が別の場所から読めてしまいます。

よくある質問

第一生命の不正アクセスについて、対象となった人と人事システムを運営する担当者から出やすい質問をまとめました。

第一生命の顧客（契約者）の情報は漏れていますか？

2026年10月2日の公表時点では、お客さま情報への不正アクセスは確認されていないとされています。流出した可能性があるのは、第一ライフグループと第一生命の従業員と退職者の情報です。続報で範囲が変わる可能性があるため、契約者は同社の公式サイトのお知らせを確認してください。

自分が対象かどうかはどう確認できますか？

対象は、両社の従業員と、内勤職員として1967年以降、営業職員として2017年以降に退職した人です。グループ会社への出向者と在籍型出向で勤務した人も含まれます。お知らせに記載の問い合わせフォームか、フォームが難しい場合は人事部窓口（平日9時〜17時）で確認できます。

不正アクセスの原因や手口は公表されていますか？

公表されていません。お知らせの原因欄は「第三者による不正アクセスを受けたため」だけで、侵入経路、使われた脆弱性や認証情報、閲覧の期間は書かれていません。新たに知らせるべき事項が判明した場合は速やかに知らせるとしています。

退職者の個人情報は会社がいつまで保管してよいのですか？

労働基準法109条は労働者名簿などの保存を求めており、施行規則56条により労働者名簿は退職日から数えます。期間は本則で5年、附則143条により当分の間は3年です。個人情報保護法22条は、利用する必要がなくなった個人データを遅滞なく消去するよう努めることを求めています。退職金や企業年金などで別に保存が必要な項目は、その目的に必要な範囲に限って残します。

自社の人事システムで同じことが起きないか、何から確かめればよいですか？

最初に、在籍者、退職から5年以内、5年超の3区分で人数と最も古い退職日を数えます。次に、5年超の人のうち例外として残す人を人事と法務で決め、それ以外の氏名、住所、電話番号、上長名を消します。最後に、上司の名前を騙る連絡への確認手順を社内に周知してください。本記事のSQLとスクリプトはその出発点として使えます。