ディップ株式会社は2026年10月9日、運営する求人情報サイト「バイトル」「バイトルNEXT」が第三者から不正アクセスを受け、登録会員のメールアドレスが一部漏えいしたと公表しました。漏えいした可能性のある件数は最大3,885,771件で、漏れた情報はメールアドレスのみとされています。本記事の前半は、自分は対象か、パスワードは変えるべきか、バイトルを名乗るメールは本物かという登録者の疑問への、公式発表に沿った回答です。後半では、原因とされた「仕様の不備」で起こりうる型を整理し、他人のメールアドレスを返さないAPIの作り方をPythonのコードで示します。
まとめ：バイトル不正アクセスで漏えいしたのはメールアドレス最大388万件
漏えいしたのはメールアドレスだけで、氏名、電話番号、パスワード、クレジットカード情報などは含まれていない、というのが同社の説明です。10月9日の時点で、メールアドレス以外の流出、インターネット上への流出、不正利用は確認されていません。バイトルとバイトルNEXTは引き続き利用できます。
登録者がやることは1つに絞れます。バイトルを名乗ってパスワードやカード番号を聞くメールやSMSには応じないことです。同社はメール等でそれらを尋ねることは一切ないと明言しています。開発者が受け取る教訓は、画面に出していない項目でもAPIが返していれば取られる、という点と、会員番号を順に読む総当たりを件数で止める仕組みの有無です。
| 項目 | 公表されている内容（2026年10月14日時点） |
|---|---|
| 対象サービス | バイトル・バイトルNEXT |
| 件数 | 最大3,885,771件（漏えいした可能性） |
| 漏えいした情報 | メールアドレスのみ |
| 含まれない情報 | 氏名・電話番号・パスワード・カード情報等 |
| 確認日 | 2026年10月6日 |
| 原因 | 一部機能の仕様の不備を突いた海外からの不正アクセス |
| 窓口 | 問い合わせフォーム（電話窓口の案内なし） |
| 未公表 | 対象機能・手口の詳細・補償 |
利用者が最初に確かめること：漏れた範囲、届く連絡の真偽、パスワード変更
漏れたのはメールアドレスだけ：氏名・電話番号・パスワード・応募先の扱い
ディップのお知らせとお詫びは、漏えいした情報を「メールアドレスのみ」とし、氏名、電話番号、パスワード、クレジットカード情報等は含まれていないと書いています。応募履歴や応募先の企業名、職務経歴については記載がありません。発表は漏えいした項目をメールアドレスに限っているため、それ以外の項目が漏れたと読む根拠は今のところありません。
件数の読み方にも注意が要ります。3,885,771件は「漏えいした可能性のある件数」の最大値です。388万件すべての流出が確定したという意味ではなく、自分のアドレスが確実に含まれているとも、含まれていないとも、この数字からは判断できません。
自分が対象か確かめる方法：サイト上のお知らせと順次届く個別の案内
同社は10月6日にバイトルとバイトルNEXTのサイト上で対象会員へ知らせ、順次メール等で個別に案内しているとしています。登録者が自分で対象かを調べる照会ページの案内は、10月14日時点の発表にはありません。個別の案内メールの件名や送信元アドレスも公表されていないため、件名だけで本物かどうかを見分けることはできない状況です。
案内が来ていなくても、対象外と言い切れるわけではありません。分からないときは、メール内のリンクではなく、公式サイトから入るか、同社の発表に載っている問い合わせフォームから確かめるのが確実です。
バイトルを名乗るメールは本物か：パスワードやカード番号を聞く連絡は偽物
同社は、対象のメールアドレスが悪用された場合、スパムメールやなりすましメールが届くおそれがあるとして、身に覚えのないリンクや添付ファイルを開かないよう求めています。そのうえで「当社からメール等でパスワードやクレジットカード情報等をお伺いすることは一切ございません」と書いています。
見分ける基準はこの一文です。バイトルの名前で、パスワードの再設定、カード番号の入力、本人確認書類の送付を求めてくるものは偽物と考えて、開かずに削除するのが安全です。求人サイトの登録者であることが知られた以上、「面接日程の確認」「応募の確認」「スカウトのお知らせ」といった仕事探しに合わせた件名が使われる可能性もあります。手口の全体像はフィッシング詐欺の仕組みと技術的な対策で解説しています。
パスワード変更は必須ではない：同じアドレスで登録した他サービスの点検
パスワードは漏えいした情報に含まれていないため、同社は利用者にパスワード変更を求めていません。それでも、他のサービスで同じメールアドレスと同じパスワードを使い回しているなら、そちらを変えておく価値はあります。過去に別のサイトから漏れたパスワードと今回のアドレスが組み合わされると、他のサイトへのログインを試される材料が増えるためです。変更するときは、届いたメールのリンクではなく、公式アプリか、ブラウザに自分で入力した公式サイトから操作します。
公式発表で整理する経緯：10月6日の確認から10月9日の公表までの時系列
10月6日の確認から個別の案内まで、公表された6つの対応を時系列で並べる
- 10月6日：Webサイトの一部機能で第三者からの不正アクセスを確認
- 確認後ただちに：海外からのアクセスを全て遮断し、プログラムを改修
- 10月6日：バイトル・バイトルNEXT上で対象会員へお知らせ
- 以降順次：対象会員へメール等で個別に案内
- 10月9日：お知らせとお詫びを公表（最大3,885,771件）
- 10月9日時点：個人情報保護委員会と総務省関東総合通信局への報告、警察への相談を進行中
同社は該当箇所の改修で同様の手法によるアクセスができないよう修正を完了し、監視体制も強化したとしています。10月14日時点で、同社のニュース一覧に続報は掲載されていません。
10月14日時点で公表されていない対象機能・手口・アクセス期間・補償
原因は「システムの一部機能における仕様の不備を突いた、海外からの不正アクセス」と書かれているだけです。どの機能か、どんな手順でメールアドレスが取られたか、いつからアクセスされていたかは公表されていません。補償やお詫びの品についても、記載は見当たらない状況です。本記事はこれらを推測で補いません。以降の技術章は、本件の原因を特定するものではなく、「仕様の不備」と呼ばれる欠陥がメールアドレスの大量流出につながる一般的な型を、開発者の点検項目として整理したものです。
「仕様の不備」で起こりうる3つの型：OWASP API Top 10で整理する点検箇所
パスワードの解読やサーバーへの侵入が無くても、アプリやWebの仕様そのものが情報を渡してしまう欠陥は珍しくありません。メールアドレスだけが大量に出ていく形に当てはまるのは、主に次の3つです。
画面に出さない項目をAPIが返す型：API3の過剰なデータ露出
OWASP API Security Top 10の API3:2023は、利用者が読むべきでないプロパティをAPIが返す欠陥を挙げています。画面には表示名しか出していなくても、裏で呼ぶAPIの応答にメールアドレスが入っていれば、通信を見るだけで取得できる状態です。OWASPは対策として、オブジェクトを丸ごと文字列にする汎用的な変換を避け、機能に必要なプロパティだけを返すこと、応答をスキーマで検証することを求めています。
番号を変えると他人の情報が読める型：API1のオブジェクト単位の認可不備
API1:2023は、リクエストに含まれる会員番号や応募番号を書き換えると、他人のデータが返る欠陥です。ログインしているかどうかしか確かめず、その番号のデータを読む権限があるかを確かめていないと起こります。番号が連番なら、1から順に増やすだけで全会員を読めてしまいます。
登録画面や再設定画面の応答差でアドレスを確かめる型：アカウント列挙
メールアドレスそのものは返さなくても、「このアドレスは登録済みです」のような応答の違いから、登録の有無を確かめられる仕様もあります。この型は攻撃者が持っているアドレスの一覧をふるいにかけるもので、仕組みと防ぎ方はスタディサプリの不正アクセスとアカウント列挙を防ぐ実装で詳しく扱いました。どの型でも、短時間に大量のリクエストを許していれば被害は会員数の規模まで広がります。API4:2023が、クライアントごとの呼び出し回数の制限や、1回の応答で返すレコード数の上限を求めているのはこのためです。
他人のメールアドレスを返さず番号の総当たりを止めるPythonコードと実行結果
返す項目を許可リストで固定し、1分間に読める他人の会員数を30件に絞るコード
次の例は、会員情報を返すAPIの処理を最小限の形にしたものです。本人が自分の情報を読むときだけメールアドレスを返し、他人の情報には表示名と都道府県しか返しません。あわせて、1つのクライアントが1分間に参照できる他人の会員数を30件に絞ります。会員データはPython標準のdataclassesで表し、追加のインストールなしで動きます。
# 会員APIで他人のメールアドレスを返さず、番号の総当たりを止める最小例（Python 3.10以上・標準ライブラリのみ）
from collections import Counter, defaultdict, deque
from dataclasses import dataclass
@dataclass
class Member:
member_id: int
email: str
nickname: str
prefecture: str
MEMBERS = {i: Member(i, f"mail-{i}", f"会員{i}", "東京都") for i in range(1, 2001)}
PUBLIC_FIELDS = ("member_id", "nickname", "prefecture") # 他人に返してよい項目
SELF_FIELDS = PUBLIC_FIELDS + ("email",) # 本人にだけ返す項目
WINDOW_SEC = 60 # 集計する時間幅（秒）
MAX_DISTINCT = 30 # 時間幅の中で参照してよい他人の会員数
recent = defaultdict(deque) # クライアントごとの (時刻, 参照した会員番号)
def get_member(client_id, viewer_id, member_id, now):
member = MEMBERS.get(member_id)
if member is None:
return 404, None
if member_id != viewer_id:
q = recent[client_id]
while q and now - q[0][0] >= WINDOW_SEC:
q.popleft()
if len({mid for _, mid in q} | {member_id}) > MAX_DISTINCT:
return 429, None # 短時間に別々の会員を読みすぎている
q.append((now, member_id))
fields = SELF_FIELDS if member_id == viewer_id else PUBLIC_FIELDS
return 200, {f: getattr(member, f) for f in fields} # 返す項目を許可リストで固定
print("本人:", get_member("app-001", 10, 10, 0.0))
print("他人:", get_member("app-001", 10, 11, 0.0))
# 会員番号を1つずつ増やし、0.05秒間隔で他人の情報を読み続けるクライアント
status, emails = Counter(), 0
for i, mid in enumerate(range(12, 2001)):
code, body = get_member("bot-77", 10, mid, i * 0.05)
status[code] += 1
emails += bool(body and "email" in body)
print("総当たりの結果:", dict(status), "取得できたメールアドレス:", emails)Python 3.14.6の実行結果：1,989回の総当たりで取れたメールアドレスは0件
本人: (200, {'member_id': 10, 'nickname': '会員10', 'prefecture': '東京都', 'email': 'mail-10'})
他人: (200, {'member_id': 11, 'nickname': '会員11', 'prefecture': '東京都'})
総当たりの結果: {200: 60, 429: 1929} 取得できたメールアドレス: 0本人の応答にだけemailが入り、他人の応答には入っていません。会員番号12〜2000を約100秒で読み続けたクライアントは、最初の1分で30件、時間幅が進んだ後にさらに30件の計60件だけが通り、残り1,929回は429で止まりました。通った60件にもメールアドレスは含まれていません。
この2つは役割が違います。許可リストは「取られても困らない項目しか返さない」ための対策で、件数の制限は「許可された項目でも全件は持ち出させない」ための対策です。どちらか一方だけでは足りません。数えるのはリクエスト数ではなく、参照した会員番号の種類です。同じ求人や同じ会員を何度も開く通常の操作と、別々の会員を次々に読む取得を区別できます。上限値は、業務ごとの実績の最大値を1か月ほど測ってから決めるのが無難です。本番では、プロセスのメモリではなくRedisなどの共有ストアで数え、APIキーとIPアドレスの両方を単位にします。制限方式の選び方と429応答の設計はAPIレート制限の5方式の比較と分散実装で比べています。
海外からのアクセス遮断は応急処置：国内の経路を使われた場合に残る穴
同社は確認後ただちに海外からのアクセスを全て遮断しました。アクセス元の国で止める方法は、攻撃が続いている最中の応急処置として即効性があります。ただし、国内のクラウドや中継サーバーを経由すれば同じリクエストは届くため、恒久的な対策にはなりません。同社も遮断と並行してプログラムを改修しています。自社のサービスで同じ判断をするなら、国別の遮断は時間を稼ぐ手段と位置づけ、その間に応答項目と件数制限を直す順番で進めます。
求人サイト・会員サイトの運営者が点検する順番と個人情報保護委員会への報告
メールアドレスだけの漏えいでも委員会への報告が要る場面と期限
ディップは個人情報保護委員会への報告を進めていると公表しています。個人情報保護委員会の案内では、不正アクセスのように不正の目的をもって行われたおそれがある漏えいは、件数にかかわらず報告の対象になります。速報は事態を知った日から3〜5日以内、確報は60日以内です。メールアドレスだけだから報告は不要、という判断は成り立ちません。報告の段取りは個人情報保護委員会への報告義務の実務にまとめています。
自社の会員APIで確かめる3項目：返す項目・番号の権限・件数の上限
判断は言い切れます。会員情報を返すAPIを持つなら、確かめる項目は3つです。1つ目に、ブラウザの開発者ツールで実際の応答を開き、画面に出していないメールアドレスや電話番号が入っていないかを見ておきます。2つ目は会員番号を他人のものに書き換えたリクエストが拒否されるかどうか、3つ目は1つのクライアントが短時間に読める会員数に上限があるかどうかの確認です。3つとも問題が無ければ、仕様起因の大量流出の入口はかなり狭まります。
逆に、会員が数百人規模で、他人の情報を表示する機能そのものが無いサイトなら、件数制限の仕組みまで作り込むのは過剰です。応答項目の確認だけで足ります。自社で判断がつかない場合や、APIの数が多く手で確かめきれない場合は、脆弱性診断・セキュリティ診断で応答項目と認可の点検を受け付けています。
よくある質問
バイトル・バイトルNEXTの不正アクセスとメールアドレス漏えいについて、登録者から出やすい質問をまとめました。
バイトルに登録していますが、自分が対象か確認する方法はありますか？
10月14日時点で、登録者が自分で対象かを調べる照会ページは案内されていません。同社は10月6日にサイト上で対象会員へ知らせ、メール等で順次個別に案内しているとしています。分からない場合は、メール内のリンクを使わず、同社の発表に載っている問い合わせフォームから確かめてください。
バイトルのパスワードは変更したほうがいいですか？
パスワードは漏えいした情報に含まれていないと同社は説明しており、変更は求められていません。ただし同じメールアドレスと同じパスワードを他のサービスで使い回しているなら、そちらを変えておくと安心です。変更は公式アプリか、自分で入力した公式サイトから行います。
バイトルを名乗るメールが届きました。本物ですか？
件名や送信元は公表されていないため、見た目だけで本物とは判断できません。同社はメール等でパスワードやクレジットカード情報を聞くことは一切ないとしています。パスワードの再設定、カード番号の入力、本人確認書類の送付を求めるメールは開かずに削除してください。
氏名や電話番号、応募先の企業も漏れていますか？
同社の発表では、漏えいした情報はメールアドレスのみで、氏名、電話番号、パスワード、クレジットカード情報等は含まれていません。応募履歴や応募先については発表に記載がありません。10月9日時点で、メールアドレス以外の流出や不正利用は確認されていないとされています。
バイトルの問い合わせ先はどこですか？補償はありますか？
利用者向けの窓口はバイトル応募ユーザー様お問い合わせフォームで、電話窓口は案内されていません。補償やお詫びの品については、10月14日時点で公表がありません。補償を名目に振込や手数料、カード番号の入力を求める連絡があれば応じないでください。
関連記事
- スタディサプリの不正アクセスとメールアドレス3,687件｜アカウント列挙を防ぐ実装：メールアドレスの登録有無を確かめる手口と応答の揃え方
- ブックオフ不正アクセス：約638万人の対象確認と本物メールの見分け方：同じ週に公表された会員情報の大量流出と大量取得の検知
- skyticket不正アクセス：1,464万件流出の対象確認と本物メールの見分け方：同時期に公表されたハッシュ化パスワードを含む流出
- Commune不正アクセス：約30.7万人漏えいの対象確認と共通署名鍵の教訓：同時期に公表された会員情報の漏えい
- ローソンID不正アクセス：215万件漏えいの対象確認と本物メールの見分け方：同時期に公表された215万件の会員情報の漏えい
- 不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順：運営者として点検する範囲の全体像
