--- title: "ApplyNow不正アクセス：39万6,920人の漏えい確定と対象確認・マイナンバーの対処" url: "https://www.issoh.co.jp/tech/details/19710/" published: 2026-11-13 updated: 2026-11-13 categories: ["セキュリティ"] publisher: "株式会社一創" --- # ApplyNow不正アクセス：39万6,920人の漏えい確定と対象確認・マイナンバーの対処 録画面接のInterview Cloud、採用管理のApplyNow、電子雇用契約のApplyNow Signを提供するApplyNowは2026年11月4日、不正アクセスの調査結果をまとめた最終報を公表しました。漏えいした人数は応募者・契約者・企業ユーザーを合わせて396,920人で、ApplyNow Signで雇用契約を結んだ30,067人のうち一部は、マイナンバーや口座情報も含まれています。原因は、社内で使うデータ分析ツールの公表済みの脆弱性を直していなかったことと、契約が終わった企業のデータを消していなかったことなどです。前半は、対象かどうかの確かめ方、マイナンバーや口座が漏れた人の相談先、偽の連絡の見分け方を、公式の発表と特設ページで確かめます。後半では、契約が終わった利用企業のデータを期限で消す実装を、実行結果つきで示します。 ## まとめ：ApplyNow不正アクセスの最終報で確定した漏えい項目と応募者が今やること 漏えいは「可能性」ではなく、調査で事実と確認されています。対象は3つのサービスにまたがり、応募しただけの人は氏名・電話番号・メールアドレス・生年月日など、雇用契約まで進んだ人は一部でマイナンバー、口座、基礎年金番号、在留カード番号まで含みます。履歴書や面接動画のファイル、本人確認書類の画像、クレジットカード情報は対象外です。 まずやることは2つです。ApplyNowから届いたお知らせのメールで、自分のどの項目が漏れたかを確かめること。そして、補償や本人確認を名目にマイナンバーや暗証番号を聞く連絡には答えないことです。不正利用は、11月4日時点で確認されていません。 | 項目 | 最終報の内容（2026年11月4日） | | ------- | ---------------------- | | 対象サービス | 録画面接・採用管理・電子雇用契約 | | 漏えい人数 | 396,920人 | | うち雇用契約者 | 30,067人 | | 侵入の起点 | 社内のデータ分析ツールの脆弱性 | | 対象外 | 動画・履歴書等のファイル、カード情報 | | 二次被害 | 現時点で確認なし | | 電話窓口 | 0120-401-373（11月30日まで） | | 未公表 | 分析ツール名・脆弱性の番号 | ## 応募者と契約者が確かめること：通知メール、マイナンバー・口座の相談先、偽連絡 ### ApplyNowの3サービス別に確認する応募経路と通知メールの漏えい項目 表の対象サービスは、録画面接のInterview Cloud、採用管理のApplyNow、電子雇用契約のApplyNow Signです。応募や契約に使ったサービスと、通知メールに記載された漏えい項目を照合します。 [ApplyNowの最終報](https://applynow.co.jp/news/20261104)によると、漏えいした項目はサービスごとに違います。録画面接のInterview Cloudは氏名、フリガナ、電話番号、メールアドレス、選考情報、生年月日、性別、職業です。採用管理のApplyNowでこれらに追加される項目は、住所、受験番号、学校名です。利用していたのは企業だけでなく、第1報によれば自治体にも通知が出ています。応募先の採用ページから録画面接や応募フォームに進んだ人は、ApplyNowという名前を知らないまま情報を登録していた場合があります。 [ApplyNowの特設ページ](https://biz.applynow.jp/support/)は、漏えいした項目が一人ずつ違うため、届いたお知らせのメールで確かめるよう案内しています。通知の手段として明記されているのはメールだけです。メールアドレスを変えた、迷惑メールに振り分けられたなどで届いていない人は、電話窓口かメール窓口に連絡すれば対象かどうかを調べてもらえます。電話は平日10時〜18時で、受け付けは11月30日までです。12月1日以降はメールだけになります。 ### マイナンバー・口座・基礎年金番号が含まれた契約者30,067人の相談先 ApplyNow Signで雇用契約を結んだ人のうち一部は、マイナンバー（番号のみ）、金融機関の口座情報、基礎年金番号、在留カード番号、雇用保険被保険者番号、扶養控除に関する情報が漏れています。特設ページは、それぞれの相談先を次のように示しています。 - マイナンバー：番号だけでは税や年金の手続き、預金の引き出しはできない。不正利用のおそれがあれば、本人の申請で市区町村の窓口で番号を変えられる。扶養家族の番号も同じ - 口座情報：漏れたのは金融機関名、支店名、口座種別、口座番号、名義。暗証番号やネットバンキングのログイン情報は含まれない。心当たりのない取引があれば金融機関へ - 基礎年金番号：年金事務所または日本年金機構の電話相談窓口 - 在留カード番号：出入国在留管理庁の相談窓口 - 雇用保険被保険者番号：ハローワーク どの窓口でも、本件のお知らせメールを受け取ったと伝えると話が早く進みます。口座は急いで解約する必要はないとされていますが、引き落としや入金の明細はしばらく毎月見ておくと、不審な動きに早く気付けます。 ### 「補償手続き」「本人確認」を名乗る電話・SMSと、ApplyNowが尋ねない項目 特設ページによると、ApplyNowは電話、メール、SMSで暗証番号、パスワード、認証コード、クレジットカード番号、マイナンバーを尋ねることはなく、振り込みも頼みません。典型的な手口として挙げられているのは、「補償手続き」や「本人確認」を理由に情報を聞き出す連絡、リンク先でログインや入力をさせる連絡、「補償金」「返金」を理由に振り込みやギフトカードの購入を求める連絡です。 今回は氏名、電話番号、応募先や選考の情報までそろっているため、「〇〇市の採用試験の件で」と実在の応募先を名乗る連絡も作れてしまいます。応募先の名前が合っていても、それだけで本物とは判断できません。届いたら返信せずに削除し、名乗った組織の公式サイトに載っている連絡先へ自分から確かめます。入力してしまった場合は、パスワードを変え、金融機関やカード会社に連絡します。相談先は警察相談専用電話の#9110と、消費者ホットラインの188です。偽の連絡が本物らしく見える仕組みは[フィッシング詐欺の成立の仕組みと技術的対策](https://www.issoh.co.jp/tech/details/13548/)で解説しました。 ### 登録した覚えがない人と、応募データの削除・利用停止を求める手順 ApplyNowに登録した覚えがなくても、対象になっている場合があります。特設ページが挙げているのは、求人企業から委託された面接代行の仕組みや、求人サイト経由の応募でデータが保管されていた可能性です。応募先の企業や勤務先にもApplyNowから報告済みで、企業から別に案内が届くこともあります。 自分のデータを消してほしい場合は、窓口で本人確認を受けたうえで、削除か利用停止の手続きを案内されます。求人企業から預かったデータは、その企業と調整してから対応する形です。すでに漏れた情報は削除しても取り戻せないため、削除の依頼と偽の連絡への警戒は並行して進めます。 ## 最終報から読む事案の構造：分析ツールの未修正と契約終了企業のデータ残存 ### 8月9日の侵入から9月7日の一括取得、11月4日の確報までの時系列 最終報と[9月9日の第1報（10月9日に更新）](https://applynow.co.jp/news/20260909)を合わせると、経緯は次のとおりです。 | 日付（2026年） | 出来事 | | --------- | -------------- | | 8月9日 | 侵入、管理者権限を取得 | | 8月23日・26日 | データベースの一部を閲覧 | | 9月7日 | 一括取得、同日に検知して遮断 | | 9月9日 | ホームページで公表 | | 9月11日 | 個人情報保護委員会へ速報 | | 9月19日〜 | 対象者へ個別通知 | | 10月9日 | 約39万人と更新 | | 10月23日 | フォレンジック調査完了 | | 11月4日 | 確報を提出、最終報を公表 | 侵入から検知まで29日かかっています。最終報が認めているのは、不正操作を見つける仕組み自体はあったものの、発見まで時間がかかったという経緯です。8月中に閲覧の段階で気付けていれば、9月7日の一括取得は防げた可能性があります。 ### 最終報が挙げた4つの原因と、分析ツールの名称と脆弱性番号が未公表の点 最終報が挙げた原因は4つです。提供元が公表していた脆弱性を把握しておらず修正版の適用が遅れたこと。接続元を制限していなかったこと。不正操作の発見に時間がかかったこと。そして、分析ツールから個人情報を参照できる構成で、保管期間を定めず、利用を終えた企業のデータを消していなかったことです。 分析ツールの名称と、悪用された脆弱性の番号は書かれていません。同じ時期に、BIツールの脆弱性を突かれた他社の事案もありますが、同じツールかどうかは公表文からは判断できません。再発防止策としては、修正版への更新、接続元IPの制限、データベース接続情報の更新、脆弱性情報の定期確認と期限付きの修正適用を実施済みとし、利用終了企業のデータ削除、保管期間の策定と自動削除、外部機関による年1回の脆弱性診断などを予定しています。 ### 委託元の企業・自治体にも及ぶ報告義務、個人情報保護法26条と確報60日 [個人情報保護委員会の案内](https://www.ppc.go.jp/personalinfo/legal/leakAction/)では、本人の数が1,000人を超える漏えいと、不正の目的をもって行われたおそれがある漏えいは、どちらも報告の対象です。速報は発覚から3〜5日以内、確報は30日以内で、不正の目的が疑われる場合は60日以内です。ApplyNowは9月7日の検知から4日後の9月11日に速報を出し、58日後の11月4日に確報を出しました。マイナンバーを含む漏えいは、委員会の専用フォームから報告する決まりです。 採用担当が見落としやすいのは、委託元の立場です。[個人情報保護法](https://laws.e-gov.go.jp/law/415AC0000000057)の第26条第1項ただし書は、委託を受けた事業者が委託元に事態を通知したときは、委託先自身の報告を不要としています。報告の義務は委託元の企業に残るということです。自治体などの行政機関等は、100人を超えれば報告の対象になります。報告の要件と段取りは[個人情報保護委員会への報告義務の実務](https://www.issoh.co.jp/column/details/17840/)で整理しました。 ## 開発側の対策：契約が終わった利用企業の応募者データを期限で消す実装 ### SaaSの解約後もデータが残る構造と、個人情報保護法22条の消去の努力義務 複数の企業が同じデータベースを使うSaaSでは、解約はたいてい「ログインできなくする」処理で終わります。データを消すには、解約日から猶予を置いて返却を終え、関連するテーブルを漏れなく消す別の処理が要るためです。この処理を後回しにすると、解約済みの企業の応募者データが何年も残り、侵入されたときの被害の母数になります。ApplyNowの第1報も、契約終了企業の応募者情報は調査完了後に企業と協議して削除するとしていました。 個人情報保護法の第22条は、利用する必要がなくなった個人データを遅滞なく消去するよう努めることを事業者に求めています。委託を受けて応募者データを預かるSaaSなら、契約終了で「利用する必要」はなくなります。猶予日数と削除の範囲を利用規約に書き、その日数で動く削除処理を最初から用意しておくのが筋です。 ### 契約終了テナントと不採用者を期限で消すPythonとSQLiteのスクリプト 次のスクリプトは、架空の利用企業3社と応募者1,200件をメモリ上のSQLiteに作り、2つの規則で削除する例です。契約終了から90日を過ぎた企業のデータはすべて消し、契約中の企業でも応募から365日を過ぎた不採用者は消します。消した件数は、個人情報を含まない形で削除記録に残します。 ``` # 契約が終わった利用企業（テナント）の応募者データを、保管期限を過ぎたら消す（Python 3.9以上・標準ライブラリのみ） # 検証用に架空のデータをメモリ上のSQLiteへ作って試す。実在のシステムには触れない import sqlite3 from datetime import date, timedelta TODAY = date(2026, 11, 13) GRACE_DAYS = 90 # 契約終了後、データを返却・確認してもらう猶予 KEEP_DAYS = 365 # 契約中の企業でも、応募から1年を過ぎた不採用者は消す db = sqlite3.connect(":memory:") db.executescript(""" CREATE TABLE tenants (id INTEGER PRIMARY KEY, name TEXT, contract_end TEXT); CREATE TABLE applicants (id INTEGER PRIMARY KEY, tenant_id INTEGER, name TEXT, email TEXT, my_number TEXT, applied_on TEXT, hired INTEGER); CREATE TABLE purge_log (run_on TEXT, tenant_id INTEGER, reason TEXT, rows INTEGER); """) def d(days_ago): return (TODAY - timedelta(days=days_ago)).isoformat() # 架空の利用企業：A社は契約中、B社は400日前に終了、C社は30日前に終了（猶予中） db.executemany("INSERT INTO tenants VALUES (?,?,?)", [(1, "A社", None), (2, "B社", d(400)), (3, "C社", d(30))]) rows = [] for i in range(1, 1201): tenant = 1 if i <= 600 else (2 if i <= 1000 else 3) age = 30 if i % 3 == 0 else 500 # 3人に1人は最近の応募、残りは500日前 mynum = "0" * 12 if i % 10 == 0 else None # 1割は雇用契約まで進みマイナンバーを持つ（架空の値） rows.append((i, tenant, f"応募者{i}", f"user{i}" + "@" + "example.com", mynum, d(age), 1 if mynum else 0)) db.executemany("INSERT INTO applicants VALUES (?,?,?,?,?,?,?)", rows) PLAN = [ ("契約終了後の猶予超え", "tenant_id IN (SELECT id FROM tenants WHERE contract_end IS NOT NULL AND contract_end < ?)", (d(GRACE_DAYS),)), ("不採用者の保管期限超え", "tenant_id IN (SELECT id FROM tenants WHERE contract_end IS NULL) AND hired = 0 AND applied_on < ?", (d(KEEP_DAYS),)), ] def report(title): print(f"--- {title}") for name, total, mynum in db.execute(""" SELECT t.name, COUNT(a.id), COUNT(a.my_number) FROM tenants t LEFT JOIN applicants a ON a.tenant_id = t.id GROUP BY t.id ORDER BY t.id"""): print(f"{name} 応募者 {total:>4}件 うちマイナンバーあり {mynum:>3}件") report("削除前") with db: # 1つのトランザクションで消し、途中で失敗したら全部戻す for reason, where, params in PLAN: for tenant_id, n in db.execute( f"SELECT tenant_id, COUNT(*) FROM applicants WHERE {where} GROUP BY tenant_id", params).fetchall(): db.execute("INSERT INTO purge_log VALUES (?,?,?,?)", (TODAY.isoformat(), tenant_id, reason, n)) db.execute(f"DELETE FROM applicants WHERE {where}", params) report("削除後") print("--- 削除記録（個人情報は残さず件数だけ）") for row in db.execute("SELECT * FROM purge_log"): print(*row) ``` 削除は[Python標準のsqlite3](https://docs.python.org/3/library/sqlite3.html)で、接続を with 文で使い、1つのトランザクションにまとめています。sqlite3の接続はwith文を抜けるときに成功なら確定、例外なら取り消すため、規則の片方だけ消えて記録と合わなくなる事態を防げます。日付の比較値は ? のプレースホルダで渡し、SQL文に直接埋め込んでいません。 ### 架空の応募者1,200件で実行した結果と、本番で足す確認と退避の扱い Python 3.14.10（Windows、SQLite 3.50.4）で実行した結果は次のとおりです。 ``` $ python -X utf8 purge_ended_tenants.py --- 削除前 A社 応募者 600件 うちマイナンバーあり 60件 B社 応募者 400件 うちマイナンバーあり 40件 C社 応募者 200件 うちマイナンバーあり 20件 --- 削除後 A社 応募者 240件 うちマイナンバーあり 60件 B社 応募者 0件 うちマイナンバーあり 0件 C社 応募者 200件 うちマイナンバーあり 20件 --- 削除記録（個人情報は残さず件数だけ） 2026-11-13 2 契約終了後の猶予超え 400 2026-11-13 1 不採用者の保管期限超え 360 ``` 400日前に契約を終えたB社は400件すべてが消え、猶予中のC社は残りました。契約中のA社は、500日前に応募した不採用者360件だけが消え、最近の応募者と採用者の240件が残っています。マイナンバーを持つ採用者の60件は、不採用者の規則に当たらないため残しました。採用後のマイナンバーは税と社会保険の手続きで保管が必要な期間が別にあり、その期限で消す規則を別に足します。 本番では、削除の前に対象件数を委託元の企業へ知らせる確認の手順と、バックアップに残った同じデータの扱いを決めておく必要があります。本番のテーブルを消しても、バックアップや分析用の複製に残っていれば、侵入されたときに同じことが起きます。ApplyNowの事案で漏れたのも、本番の画面ではなく分析ツールから見えるデータでした。 ### 分析ツールの接続元制限と読み取り範囲は、既存の解説で点検する 最終報の原因のうち、接続元を制限していなかった点と、分析ツールから個人情報を見られた点は、データ削除とは別に直す必要があります。[OWASPのDatabase Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Database%5FSecurity%5FCheat%5FSheet.html)は、データベースへの接続を必要なホストだけに絞ることと、接続に使うアカウントに必要最小限の権限だけを与えることを求めています。 BIツールをインターネットから直接届かない場所に置く構成と、接続用のデータベースユーザーを読み取り専用にして見せる列を絞るGRANTは[LEAN BODYの不正アクセスとBIツールの公開設定・パッチ適用](https://www.issoh.co.jp/tech/details/18168/)で扱いました。分析側へ渡す列を許可リストで絞り、会員IDを仮名化するスクリプトは[osinaの情報漏洩と分析ツールへ渡すデータの絞り方](https://www.issoh.co.jp/tech/details/19125/)にあります。外から届くAPIの防御は[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)にまとめています。 ## 判断：採用・人事データを預かるSaaSの運営者と委託元が見直す条件 ### 解約後データの削除を社内で回せる条件と、第三者の診断に頼む場面 利用企業ごとにデータが分かれていて、保管しているテーブルとバックアップの場所を一覧で示せるなら、上のような削除処理は社内で始められます。逆に次のどれかに当たる場合は、削除処理より先に、データの置き場所と経路を外部の目で洗い出すほうが先です。 - 解約した企業のデータが何件残っているか、即答できない - 分析ツールやデータウェアハウスに本番の複製があり、そこに氏名や連絡先の列が入っている - 使っているOSSやツールの脆弱性情報を、決まった担当者が決まった頻度で確かめていない - マイナンバーや口座など、漏れたときの影響が大きい項目を、応募者情報と同じデータベースに置いている 委託元の採用担当も、委託先を選ぶ時点で解約後の削除期限と削除証明の有無を確かめておけば、今回のような残存を避けられます。採用管理の仕組みを選ぶ観点は[採用管理システム（ATS）の機能・種類と自社開発の判断軸](https://www.issoh.co.jp/column/details/13559/)、マイナンバーを区分して管理する要件は[人事管理システムのセキュリティ要件](https://www.issoh.co.jp/column/details/18561/)で整理しました。 個人情報を預かるシステムが外部から届く場所にあるなら、ツールの版と接続元、見える列を第三者の目で確かめる価値があります。診断の種類と費用の考え方は[脆弱性診断の種類・費用相場と外注の判断基準](https://www.issoh.co.jp/column/details/13101/)で解説しました。自社のSaaSや採用・人事システムを外部の目で点検したい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で相談できます。 ## よくある質問 ApplyNowの不正アクセスについて、応募者、契約者、採用担当から出やすい質問をまとめました。 ### ApplyNowの不正アクセスで自分の情報が漏れたか、どう確かめればいいですか？ 対象の人には、ApplyNowからお知らせのメールが順に送られています。漏れた項目は人によって違うため、メールの記載で確かめてください。メールが見当たらない場合は、迷惑メールのフォルダを見たうえで、電話窓口（0120-401-373、平日10時〜18時、11月30日まで）か、特設ページに載っているメール窓口に問い合わせると調べてもらえます。 ### マイナンバーが漏れた場合、番号を変えたほうがいいですか？ 特設ページは、番号だけでは税や年金の手続き、預金の引き出しはできないと説明しています。そのうえで、不正利用のおそれが認められる場合は、本人の申請で市区町村の窓口で番号を変えられるとしています。お知らせメールを持って、住んでいる市区町村の窓口で相談するのが確実です。扶養家族の番号が含まれていた場合も同じ窓口で相談できます。 ### 履歴書や面接の動画は漏れていますか？ 最終報と特設ページによると、面接動画、画像、PDFなどのファイル、本人確認書類の画像、クレジットカード情報は対象外です。ファイルは別の場所に保管されていたためです。雇用契約の内容、緊急連絡先、通勤経路も対象外とされています。応募者のログインパスワードも漏れた項目に含まれていません。 ### ApplyNowで使われていた分析ツールの名前は分かっていますか？ 11月4日の最終報にも、分析ツールの名称と悪用された脆弱性の番号は書かれていません。分かっているのは、提供元が公表していた脆弱性の修正版を適用していなかったこと、接続元を制限していなかったこと、そのツールから個人情報を参照できる構成だったことです。ツール名を推測で特定するのは避け、続報を待つのが妥当です。 ### ApplyNowを使っていた企業の採用担当は何をすればいいですか？ ApplyNowからは9月14日以降、利用企業へ報告が届いています。委託元の企業にも個人情報保護委員会への報告義務があり、委託先の通知で免除されるのは委託先の側です。自社の応募者が何人含まれるかを確かめ、報告と本人への案内の要否を判断します。契約を終えた場合は、データの削除が完了した報告を受け取るところまで確かめてください。 ## 関連記事 - [API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策](https://www.issoh.co.jp/tech/details/18346/)：外部から届くAPIの防御を網羅的に点検する - [不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順と相談窓口](https://www.issoh.co.jp/column/details/18313/)：企業として点検する範囲の全体像 - [フィッシングとは？手口の種類・見分け方と企業が取るべき組織的対策を解説](https://www.issoh.co.jp/column/details/13262/)：漏えいの後に増える偽の連絡への組織的な備え --- 出典: [ApplyNow不正アクセス：39万6,920人の漏えい確定と対象確認・マイナンバーの対処]()（株式会社一創）