ソニー生命の不正アクセス：38.5万件の対象確認と窓口、停止中の手続き

ソニー生命は2026年10月28日、契約者専用サイト「お客さまWEBサービス」などのシステムが第三者の不正アクセスを受け、顧客情報が漏えいしたと公表しました。漏れたのは、ソニー生命が保険代理店として販売したメディケア生命の契約に関する、契約者と被保険者の情報約38.5万件です。氏名・住所・電話番号に加え、証券番号と契約内容まで含まれています。前半で公式発表から整理するのは、自分が対象かの確かめ方、両社の問い合わせ窓口の電話番号、止まっている手続きの代わりとなる連絡先です。後半は、他社から預かった契約を自社の契約者サイトで返す構造の弱点と、照会を絞る処理をPythonで再現します。

まとめ：ソニー生命の不正アクセスで漏れた38.5万件の項目と、契約者が今日やること

ソニー生命のお詫び文によると、不正アクセスが判明したのは10月27日です。外部から対象システムへのアクセスを遮断し、関係するサービスを止めました。原因と影響範囲は調査中で、10月28日時点で情報の不正使用は確認されていません。金融庁には報告済みで、対象者には順次連絡するとしています。

契約者が今日やることは2つです。メディケア生命の保険をソニー生命の担当者経由で契約した人は、自分が対象に入る前提で、保険会社を名乗る電話・SMS・メールに応じないこと。もう1つは、止まっているWebの手続きで急ぎのものがあれば、公表文に載った番号に自分から電話することです。証券番号と契約内容が漏れたため、契約の中身を言い当てて信用させる連絡が来やすい状態にあります。

メディケア生命の契約者が最初に確かめること：対象の範囲、窓口の番号、停止中の手続き

対象の線引き、ソニー生命が代理店として売ったメディケア生命の契約者と被保険者

今回漏れたのは、ソニー生命自身の保険の情報ではなく、ソニー生命が代理店として販売したメディケア生命の保険の情報です。メディケア生命の10月28日のお知らせは、保険代理店業務を委託しているソニー生命で漏えいが起きたと説明し、ソニー生命の募集による契約以外は漏えいの事実がないとしています。

対象には契約者だけでなく被保険者も入ります。親が契約者で子が被保険者という契約なら、家族2人分の氏名・生年月日・住所が同じ証券番号とひも付いて漏れたことになります。ソニー生命の保険だけを契約している人について、両社の公表文は漏えいの対象として挙げていません。10月29日時点で、証券番号を入れて対象かを調べるページはなく、対象者への連絡は「順次」とされたままです。

ソニー生命の臨時窓口0120-833-344とメディケア生命の0120-315-056

本件の問い合わせ先は2社に分かれています。ソニー生命はお詫び文に臨時フリーダイヤルを載せ、メディケア生命は自社の契約者向けにお問い合わせ窓口を案内しました。

メディケア生命の窓口は祝日と年末年始が休みで、日曜も受け付けます。ソニー生命の2つの番号は日曜が休みです。漏えいの対象かどうかや今後の連絡について聞くなら臨時ダイヤル、止まったWebの代わりに手続きをしたいならカスタマーセンター、と使い分けてください。

止まった6サービスとマイページ新規登録、急ぎの手続きの連絡先

ソニー生命のサービス停止のお知らせによると、10月28日8時から次の6つのサービスを止めています。復旧の時期は未定です。

• お客さまWEBサービス
• ソニー生命 アプリ
• ダイレクト請求サービス
• 申込内容控WEB
• 書類確認WEB
• 為替レート照会システム

止まっている間の急ぎの手続きは、担当者かカスタマーセンター（0120-158-821）に連絡するよう案内されています。メディケア生命も10月29日のお知らせで、マイページの新規利用登録を止めました。ソニー生命の募集以外の契約は11月2日（月）の再開を目指し、ソニー生命経由の契約は安全対策が終わってから使えるようにするとしています。年末調整に使う電子的控除証明書は、メディケア生命マイナ手続きポータルサイトで手続きできます。

証券番号と契約内容を知る相手からの電話・SMSを見分ける基準

今回の漏えいで厄介なのは、相手が証券番号と契約内容を言い当てられる点です。「〇〇の医療保険の件で」と契約の中身を正確に言われると、本物だと思いやすくなります。両社とも、メールや電話でパスワード・暗証番号・ワンタイムパスワードを尋ねることはないとしています。

ソニー生命の偽装サイト・不審電話への注意喚起のページは、さらに具体的です。メールやSMSで口座情報や本人確認書類の画像を求めないこと、外部の決済サービスや送金アプリで支払いを求めないこと、自動音声で未納や新契約を案内しないことを挙げています。「+1」「+86」など海外の番号からかかる電話もありません。このページに載るカスタマーセンターの番号は0120-498-321です。これらと違う番号に折り返すよう求められたら、いったん切って上の表の番号にかけ直してください。偽の連絡が成り立つ仕組みはフィッシング詐欺の成立の仕組みと技術的対策で取り上げました。

公式発表で追う経過：10月27日の判明から28日の公表、11月2日の再開予定まで

両社の発表の日付を並べると、次のとおりです。

1. 10月27日（火）：ソニー生命が、自社システムへの第三者の不正アクセスを把握
2. 10月28日（水）8時：お客さまWEBサービスなど6サービスを停止
3. 10月28日（水）：ソニー生命とメディケア生命が漏えいを公表、金融庁へ報告済み
4. 10月29日（木）：メディケア生命がマイページの新規利用登録を停止
5. 11月2日（月）：メディケア生命が、ソニー生命経由以外の契約で再開を予定

判明から公表まで1日で、サービスの停止は公表より先に済ませています。いつ侵入されたのか、どの経路で読み出されたのかは書かれていません。38.5万件という数は概数で、確定した件数も今後の発表を待つことになります。

金融庁への報告と、個人情報保護委員会が定める確報期限から見た続報の時期

漏えい等の報告は個人情報保護法の第26条が定めています。個人情報保護委員会の漏えい等の対応ページは、速報を発覚から3〜5日以内、確報を30日以内とし、不正な目的によるおそれがある場合の確報は60日以内としています。不正アクセスによる漏えいに当てはまるのは、この60日以内という確報の期限です。判明日の10月27日から数えると、確報の期限は12月下旬です。侵入経路や確定件数は、そのころまでに続報として出る可能性があります。速報と確報に何を書くかは個人情報保護委員会への報告義務の実務で整理しました。

開発側の教訓：代理店として預かる他社の契約を、自社の契約者サイトで返す設計

自社の契約と受託分を同じ契約者サイトで扱う構造と、委託先の監督の条文

今回の事案は、漏れたのが「システムを持つ会社の顧客」ではなく「その会社に販売を委託した別の保険会社の顧客」だった点で特殊です。メディケア生命から見ると、ソニー生命は個人データの取扱いを委託した先にあたります。個人情報保護法の第25条が定めているのは、委託元による委託先の監督です。委託元が自分で守れない場所で漏れても、顧客への説明と窓口の用意は委託元が担います。メディケア生命が自社で窓口を開き、マイページの登録まで止めたのはこのためです。

開発の側から見ると、問題は受託分の契約が自社の契約と同じ照会経路に乗っていることです。契約者が1つのログインで両方の保険を見られるのは便利ですが、その経路を破られると受託分もまとめて出ていきます。受託分は委託元ごとに持ち、どの画面からどの委託元の契約を返してよいかを、データを読む処理の側で決めておく必要があります。ソニー生命のシステムがどう組まれていたかは公表されていないので、ここからは一般論です。

証券番号の書き換えと連番の照会を止める認可と上限をPythonで再現

契約者サイトの照会でよくある穴は、URLやAPIの引数にある証券番号を書き換えると他人の契約が返ってくるものです。OWASP API Security Top 10 2023のAPI1は、これをオブジェクトレベルの認可の不備として筆頭に置いています。次のコードは標準ライブラリだけで動き、本人の契約だけを返す条件、受託分を画面ごとに許す条件、1セッションで照会できる契約数の上限を1つの関数にまとめました。

# 契約者ポータルの照会処理で「本人の契約だけ返す」「受託分を分ける」「件数で止める」を再現する（Python 3.8以上・標準ライブラリのみ）
# 使い方: python portal_demo.py
import sqlite3

con = sqlite3.connect(":memory:")
con.executescript("""
CREATE TABLE contracts(policy_no TEXT PRIMARY KEY, owner_id TEXT, insurer TEXT, name TEXT, plan TEXT);
INSERT INTO contracts VALUES
 ('S-0001', 'c01', 'own',     'aoi',    'life'),
 ('M-0001', 'c01', 'partner', 'aoi',    'medical'),
 ('M-0002', 'c02', 'partner', 'hikaru', 'medical'),
 ('M-0003', 'c03', 'partner', 'sora',   'cancer');
""")

# 受託分（他社の契約）は、委託元が許した画面だけで返す
ALLOWED = {"mypage": {"own", "partner"}, "fx_rate": set()}
LIMIT = 3          # 1セッションで照会できる契約の上限（例の値）
seen = {}          # セッションごとに照会した証券番号

def get_contract(session, customer_id, screen, policy_no):
    rows = seen.setdefault(session, set())
    if len(rows | {policy_no}) > LIMIT:
        return "BLOCK: too many policies in one session"
    rows.add(policy_no)
    insurers = sorted(ALLOWED.get(screen, set()))
    if not insurers:
        return "DENY: screen has no contract scope"
    q = "SELECT policy_no, insurer, plan FROM contracts WHERE policy_no = ? AND owner_id = ? AND insurer IN (%s)" % ",".join("?" * len(insurers))
    row = con.execute(q, (policy_no, customer_id, *insurers)).fetchone()
    return row or "DENY: not your policy"   # 他人の契約も存在しない契約も同じ応答にする

# 1) 本人の契約は2社分とも返る
print("[own   ]", get_contract("s1", "c01", "mypage", "S-0001"))
print("[own   ]", get_contract("s1", "c01", "mypage", "M-0001"))
# 2) 証券番号を書き換えて他人の契約を読もうとしても返らない
print("[idor  ]", get_contract("s1", "c01", "mypage", "M-0002"))
# 3) 連番で次々に試すと、上限で止まる
print("[enum  ]", get_contract("s1", "c01", "mypage", "M-0003"))
# 4) 契約を扱わない画面の経路からは、本人の契約でも返さない
print("[scope ]", get_contract("s2", "c01", "fx_rate", "M-0001"))

Python 3.14.7（Windows）で実行した結果です。

$ python portal_demo.py
[own   ] ('S-0001', 'own', 'life')
[own   ] ('M-0001', 'partner', 'medical')
[idor  ] DENY: not your policy
[enum  ] BLOCK: too many policies in one session
[scope ] DENY: screen has no contract scope

1行目と2行目は、契約者c01が自社の生命保険と受託分の医療保険の両方を見られることを示します。3行目では、証券番号をM-0002に書き換えても、所有者の条件がSQLのWHERE句に入っているため何も返りません。応答を「存在しない」と同じ文言にしているのは、番号の実在を外から確かめられないようにするためです。

4行目は、拒否された照会も件数に数えている点が要です。拒否を数えないと、攻撃者は失敗を気にせず連番を回し続けられます。5行目は、為替レートの照会のように契約を扱わない画面の経路からは、本人の契約でも返さない設定です。値はPythonのsqlite3のプレースホルダで渡し、文字列の連結でSQLを組み立てていません。上限の3は例で、本番では1人が持つ契約数の分布から決めます。照会の量を時間あたりで絞る方法はアフラックの事案で解説した照会量制御の実装、APIの入口で認可とトークンの失効を組む手順はAPI不正アクセス対策の実装手順で扱っています。

契約を扱わない画面まで止めた6サービス停止から読む、認証基盤の共有範囲

止まった6サービスには、為替レート照会システムが含まれています。外貨建て保険のレートを見せる画面で、個人の契約を返す必要はないはずです。それでも同時に止めたのは、6つが同じ入口や認証の仕組みを共有していて、どこまでが安全かを切り分けきれなかったからだと読めます。ソニー生命はこの理由を説明していません。

入口を共有すると、1か所の不備で全サービスを止めることになります。契約を返す画面と返さない画面で、ログインのセッションや内部APIの権限を分けておけば、止める範囲を絞れます。先のコードの5行目は、この「画面ごとに返してよい契約の範囲」を表したものです。

事業者の判断：契約者向けWebサービスを持つ保険会社・代理店で診断を入れる条件

受託分の契約を扱う代理店システムは、照会経路の認可を年1回点検

保険に限らず、自社の顧客サイトで他社から預かった契約や会員を一緒に見せている事業者は少なくありません。証券会社の仲介、カード会社の提携、通信会社の代理販売も同じ形です。委託元から見れば、委託先のシステムで漏れても顧客対応の負担は自社に返ってきます。生命保険協会の契約照会システムで起きた漏えいも、権限の設定1つで外から読める状態になっていました。

次の3つのどれかに当てはまるなら、外部の脆弱性診断を入れ、照会経路の認可が正しく働いているかを年1回確かめてください。他社から預かった契約や会員を自社の顧客サイトで返していること、証券番号や会員番号を引数に取る照会APIを持っていること、1人あたりの照会件数を監視していないことです。逆に、受託分を持たず、契約の照会を紙や電話だけで受けている代理店なら、まずは委託元との取り決めで保存する項目と期間を絞るほうが先です。診断の種類と費用の考え方は脆弱性診断の種類・費用相場と外注の判断基準、企業として点検する範囲は不正アクセス対策の点検手順で解説しています。

契約者サイトやアプリ、代理店向けの管理画面に同じ弱点が残っていないかを第三者に確かめてもらいたいなら、脆弱性診断・セキュリティ診断で相談できます。

よくある質問

ソニー生命の不正アクセスについて、契約者から出やすい質問をまとめました。

ソニー生命の保険だけを契約している人も対象ですか？

10月29日時点で両社が漏えいの対象として挙げているのは、ソニー生命が代理店として扱ったメディケア生命の保険の契約者と被保険者です。ソニー生命自身の保険だけを契約している人の情報が漏れたとは書かれていません。調査は続いているため、範囲が変わる場合はソニー生命の公式ホームページで知らせるとしています。

自分が対象かどうか、どうすれば分かりますか？

証券番号を入れて対象かを調べるページは、10月29日時点でありません。ソニー生命は対象者に順次連絡するとしています。待てない場合は、ソニー生命の臨時フリーダイヤル（0120-833-344）かメディケア生命のお問い合わせ窓口（0120-315-056）に問い合わせてください。どちらも自分からかける番号として使い、折り返しを求める連絡の番号は使わないでください。

お客さまWEBサービスやアプリはいつ再開しますか？

ソニー生命の6サービスは、10月29日時点で復旧時期が未定です。急ぎの手続きは担当者かカスタマーセンター（0120-158-821）で受け付けています。メディケア生命のマイページは、ソニー生命経由以外の契約で11月2日の再開を目指しており、ソニー生命経由の契約は安全対策の完了後とされています。

漏れた情報でクレジットカードや口座が使われる心配はありますか？

両社の公表では、マイナンバー・クレジットカード情報・保険料振替口座情報は漏れた項目に含まれていません。心配なのは、氏名・住所・証券番号を知った相手が保険会社を装って口座番号や暗証番号を聞き出そうとする連絡です。両社ともメールや電話でパスワードや暗証番号を尋ねることはないとしています。

ソニー生命の情報漏洩で補償はありますか？

10月29日時点で、ソニー生命とメディケア生命の公表文に補償の記載はありません。情報が不正に使われた事実も確認されていないとしています。補償や今後の対応は、対象者への連絡や続報で確かめてください。

関連記事

• アフラックの情報漏洩440万人｜大量照会を止められなかった原因と照会量制御の実装：保険会社の契約情報が大量に照会された事案
• 生命保険協会の情報漏洩｜原因はゲストユーザー権限の誤付与、2.7万件の対象と現在の状況：契約照会システムの権限設定で起きた漏えい
• 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：漏えい時に事業者が報告する内容と期限
• 顧客情報管理システムの要件｜個人情報保護法の安全管理措置・保存期間・削除を設計に落とす【2026年版】：預かった顧客情報の保存期間と削除の設計
• フィッシング詐欺とは？成立の仕組みと実装者向けの技術的対策を解説：漏れた契約情報を使った偽の連絡の手口