「またリスト型か」——2026年6月5日、エン・ジャパンが運営するハイクラス向け転職サイト「ミドルの転職」で不正ログインが確認された、という発表を見たときの私の第一声がこれでした。今月も胃薬のお世話になりそうな予感です。
転職サイトという、職務経歴という極めてセンシティブな情報を預かるサービスで起きた今回のインシデント。攻撃手法は、私たち情シスがもう何年も戦い続けている「リスト型アカウントハッキング（リスト型攻撃）」でした。新しい脆弱性を突かれたわけではありません。だからこそ、根が深いんですよね、この問題は。
この記事では、公式発表の確定情報を整理したうえで、「なぜリスト型攻撃はなくならないのか」「自社が同じ目に遭わないために、情シスは何を仕組みとして用意すべきか」を、現場目線で掘り下げていきます。
- 何が起きたのか——公式発表の確定情報を整理します
- そもそもリスト型攻撃とは——「あなたの使い回し」が武器になる仕組み
- なぜリスト型攻撃はなくならないのか——構造から考えます
- 対策設計——「予防層」と「被害局限層」の2層で考える
- 情シスの実装チェックリスト
- FAQ——よくある疑問に答えます
- まとめ——人を責めず、仕組みで守る
何が起きたのか——公式発表の確定情報を整理します
まずは事実関係から。憶測を混ぜず、エン株式会社の公式リリースで確認できた内容だけを並べます。
エン株式会社のニュースリリース（2026年6月5日付）によれば、同社が運営する「ミドルの転職」のWebサーバーにおいて、2026年6月2日に不審なログインを検知。調査の結果、2026年5月26日から6月2日にかけて、外部から不正に取得されたとみられるID（メールアドレス）とパスワードを用いた不正なログイン試行があったことが判明しました。
報道で確認できる範囲では、不正ログインの総数は2,503件。一部ユーザーの会員情報ページが第三者に閲覧された可能性があるとされています（エン株式会社 公式リリース）。
| 項目 | 内容 |
|---|---|
| 対象サービス | ミドルの転職（ハイクラス向け転職サイト） |
| 検知日 | 2026年6月2日 |
| 不正ログイン期間 | 2026年5月26日〜6月2日 |
| 攻撃手法 | リスト型アカウントハッキング（リスト型攻撃） |
| 不正ログイン総数 | 2,503件 |
| 影響の可能性 | 一部ユーザーの会員情報ページの閲覧 |
ここで一点、城咲子として強調しておきたいことがあります。同社は「当社内からIDやパスワードが流出した事実は確認していない」と明記しています。つまり、エン・ジャパン側のデータベースが破られたわけではない、という主張です。これがリスト型攻撃の厄介なところなんですよね。後ほど詳しく説明します。
そして対応のスピード感は評価すべきだと思います。送信元IPアドレス群のブロック、対象を含むパスワードの一括リセット、個人情報保護委員会への報告、所轄警察署への通報・相談、そして6月5日にユーザー相談窓口を設置。「異常を検知した後（異常系）」の動き方として、これは教科書的に正しい初動です。
そもそもリスト型攻撃とは——「あなたの使い回し」が武器になる仕組み
ここで用語の定義を明確にしておきます。専門用語のまま流すと、対策の議論が空中戦になってしまうので。
リスト型アカウントハッキング（リスト型攻撃）とは、他社サービスから流出したIDとパスワードの組み合わせ（リスト）を使って、別のサービスへ片っ端からログインを試みる攻撃のことです。英語では Credential Stuffing（クレデンシャル・スタッフィング）と呼ばれます。「詰め込む（stuffing）」という名前のとおり、入手済みのID・パスワードのリストを、ログイン画面に機械的に詰め込んでいくイメージです。
ポイントは、攻撃者は「ミドルの転職」のサーバーを破ってパスワードを盗んだわけではない、という点です。どこか別の、まったく無関係なサービスから漏れたID・パスワードのリストを使って、「この組み合わせ、転職サイトでも使い回してる人いるだろう」と当たりをつけて試している。そして——残念ながら、それなりの確率で当たってしまうんです。
なぜ当たるのか。答えはシンプルで、多くの人がパスワードを使い回しているからです。ここを責めるつもりはありません。10も20もサービスを使う時代に、全部別々の複雑なパスワードを記憶するなんて、人間の脳には無理があります。分かります、その気持ち。私だって、仕組みがなければ同じことをしているはずです。
だからこそ、ここでも私の持論が顔を出します。人間の記憶力や注意力に頼る設計は、いずれ失敗する。失敗する可能性のあるものは、いつか必ず失敗するんです。
【関連記事】認証の基礎から固めたい方は必見です。
なぜリスト型攻撃はなくならないのか——構造から考えます
「もう何年も言われている攻撃なのに、どうして繰り返されるのか」。ここから分析できることを、構造の面から整理してみます。
第一に、攻撃のコストが異常に低いこと。流出したID・パスワードのリストはダークウェブで安価に出回っており、ログイン試行を自動化するツールも揃っています。攻撃側は、ほぼ自動・低コストで「数撃ちゃ当たる」を回せてしまう。2,503件という数字の裏には、その何十倍・何百倍もの試行があったと考えるのが自然でしょう。
第二に、防御側にとって「正規のログインと見分けがつきにくい」こと。攻撃者が使っているのは、本物のID・パスワードの組み合わせです。盗まれた合鍵で正面玄関から入ってくるようなもので、鍵穴をこじ開けた痕跡が残りません。だからこそ、ログインの「成功/失敗」だけを見ていても気づきにくい。ここで効いてくるのが、私がしつこく言い続けている「測定できなければ管理できない」という原則です。
測定すべきは、個々のログインの成否ではありません。異常な「パターン」です。短時間に大量のログイン失敗が特定IPから発生していないか。普段と違う国・時間帯からのアクセスが急増していないか。同一IPが大量のアカウントを順番に試していないか。こうした異常系のシグナルを定量化し、しきい値を超えたらアラートを上げる。これは人間が目視で追える量ではないので、仕組みで監視するしかないんですよね。
【関連記事】過去の不正アクセス事例から学びたい方に。
対策設計——「予防層」と「被害局限層」の2層で考える
さて、ここからが情シスの本番です。リスト型攻撃への対策を、城咲子流に「予防層（入らせない）」と「被害局限層（入られても被害を最小化する）」の2層に分けて設計していきます。片方だけでは片手落ちです。失敗を前提に、両方を用意します。
予防層——そもそも合鍵を使えなくする
リスト型攻撃の本質は「正しいパスワードでログインされる」ことです。であれば、パスワード単体ではログインを完結させない設計が最も効きます。
最大の対策は、やはり多要素認証（MFA）です。MFAとは、パスワード（知識情報）に加えて、スマホアプリやハードウェアキー（所持情報）、指紋や顔（生体情報）など、複数の要素を組み合わせて本人確認をする仕組みのこと。たとえパスワードが流出していても、攻撃者は二つ目の要素を持っていないため、ログインを完結できません。リスト型攻撃に対しては、これが決定打になります。
さらに堅牢にするなら、フィッシング耐性のあるパスキーやハードウェアセキュリティキーへの移行も視野に入ります。サービス提供側としては、MFAを「任意」ではなく「既定で有効」にする設計判断が重要です。任意にした瞬間、設定する人はごく一部に限られる——これは人間心理として避けられないので、仕組みで寄せていくしかありません。
【関連記事】認証戦略を体系的に固めたい方は必見です。
予防層では、ほかにもレートリミット（同一IPからのログイン試行回数の制限）、CAPTCHA、流出パスワードのブラックリスト照合（既知の漏洩パスワードでの登録・ログインを弾く）といった手立てがあります。「正規のログインに見える攻撃」を、振る舞いの異常さで削っていくイメージですね。
そして、これはサービス提供側だけでなく一人ひとりの利用者にも言えることなのですが——人間がパスワードを覚えきれないのは、もう「当たり前」として受け入れたほうがいいと思っています。10も20もあるサービスのパスワードを、全部別々に記憶する。そんなのは無理です。だから記憶に頼るのをやめて、仕組みに任せる。私自身、Windowsデスクトップも、仕事のMacBookも、iPhoneも、家族用のAndroidタブレットも、全部1Passwordで管理しています。OSをまたいで同じ金庫が同期してくれるので、「どの端末でログインするか」を一切気にしなくていい。サービスごとに自動生成した長くてランダムなパスワードを使えるので、そもそも使い回しが発生しようがないんです。リスト型攻撃に対しては、これが地味に効きます。
【関連記事】パスワードマネージャー導入を具体的に検討したい方は必見です。
被害局限層——入られた後、どこまで被害を抑えられるか
ここが、英雄的な気合いではなく設計力が問われるところです。予防層は必ずどこかで漏れます。だから、「突破された後」を最初から想定しておく。
ログインの異常検知（不審なIP・地理的にあり得ない移動・短時間の大量試行）を仕組みで監視し、自動でアラートとブロックにつなげる。今回のエン・ジャパンの初動——IPブロックとパスワード一括リセット——は、まさにこの被害局限層の動きです。検知から対応までの時間（いわゆるMTTD/MTTR）をいかに短くできるかが、被害規模を左右します。
そしてもう一つ、地味ですが効くのが最小権限の原則です。仮にアカウントが乗っ取られても、そのアカウントが触れる情報・操作の範囲が絞られていれば、被害は限定されます。「ログインできた＝何でもできる」という設計を避ける。会員情報ページの表示にあたって、本当に必要な情報だけを返す設計になっているか——こういう地道な権限設計が、最後の防波堤になるんです。
情シスの実装チェックリスト
明日から自社で確認できる形に落とし込みます。自分の組織のログイン画面を思い浮かべながら、チェックしてみてください。
- [ ] 自社サービスのログインにMFAを実装しているか。任意ではなく「既定で有効」になっているか
- [ ] 同一IP・同一アカウントからのログイン試行にレートリミットがかかっているか
- [ ] ログイン失敗の急増・地理的異常を検知するアラートが設定されているか（測定できているか）
- [ ] 検知後の初動手順（IPブロック・強制パスワードリセット）がSOPとして文書化されているか
- [ ] 既知の流出パスワード（漏洩リスト）との照合を実装しているか
- [ ] アカウント乗っ取り時に被害が広がらないよう、最小権限でデータアクセスを設計しているか
- [ ] 個人情報保護委員会・警察への報告フローが事前に整備されているか（やらかしてから調べない）
最後の項目、地味に大事です。インシデントが起きてから報告先や手順を調べ始めると、初動が確実に遅れます。報告フローこそ、平時に仕組みとして用意しておくべきものなんですよね。
【関連記事】法令対応の土台を整えたい方に。
FAQ——よくある疑問に答えます
Q. エン・ジャパンのセキュリティが甘かったから漏れたのですか？
- 今回に関しては、その見方は正確ではありません。公式発表では「自社からのID・パスワード流出は確認されていない」とされています。攻撃に使われたID・パスワードは、別のサービスから流出したものを使い回していたユーザーのものである可能性が高い、という構図です。とはいえ、サービス提供側にもMFA既定化や異常検知という打ち手があるのも事実で、「ユーザーだけの責任」で終わらせる話でもありません。双方の問題、というのが私の見方です。
Q. 自分が利用者として今すぐやるべきことは？
- 三つあります。①「ミドルの転職」で使っていたパスワードを、他のサービスでも使い回していたなら、それらを今すぐ別々のパスワードに変更する。②可能なサービスはすべてMFAを有効にする。③1Passwordのようなパスワードマネージャーを導入し、サービスごとに異なる強固なパスワードを使う。OSをまたいで同期できるものを選ぶと、PCでもスマホでも管理が一本化できて挫折しにくいです。使い回しをやめるだけで、リスト型攻撃の的中率は劇的に下がります。
Q. パスワードを複雑にすれば、リスト型攻撃は防げますか？
- 残念ながら、複雑さだけでは防げません。リスト型攻撃は「正しいパスワード」を使ってくる攻撃なので、どれだけ複雑でも、それが他社から流出していれば意味がないんです。効くのは「使い回さないこと」と「MFA」。複雑さよりも、ここに力を入れてください。
まとめ——人を責めず、仕組みで守る
リスト型攻撃は、新しい脆弱性でも高度なゼロデイでもありません。「パスワードの使い回し」という、人間ならではの弱点を突いた、極めて古典的な攻撃です。だからこそ、なくならない。
ここで「ユーザーがパスワードを使い回すのが悪い」と説教しても、何も解決しません。人間の注意力に期待する設計は、いずれ失敗するからです。私たち情シスがやるべきは、使い回していても突破されない仕組み——MFAの既定化、異常検知、最小権限——を、当たり前のレールとして敷いておくこと。
「失敗する可能性のあるものは、いつか失敗する」。だから、失敗を前提に、予防層と被害局限層の2枚を重ねて守る。今回のインシデントは、自社のログイン設計を見直すいい機会だと思います。さあ、自社のログイン画面、MFAは既定で有効になっていますか——?
