ハイホー不正ログイン：3万8,509件の対象確認と電話勧誘への対処

株式会社ハイホーは2026年10月8日、同社が提供する光回線・インターネット回線サービスのお客様専用サイト「マイページ」に第三者が本人になりすましてログインし、お客様情報を閲覧した、または閲覧した可能性があると公表しました。不正ログインは契約単位で3万8,509件です。手口は、他社への契約切替えを持ちかける電話の中で、ログインに必要な情報を本人から聞き出すというものでした。本記事の前半は、自分は対象か、何が見られたのか、その電話にどう対応するかを公式発表に沿って整理します。後半では、電話番号・郵便番号・生年月日でログインできる仕組みがなぜ破られるのかを整理し、聞き出せる情報に頼らない認証と不審なログインの検知をPythonで示します。

まとめ：ハイホー不正ログインは電話で聞き出した情報による3万8,509件

不正ログインで閲覧された可能性があるのは、氏名、住所、電話番号、メールアドレス、契約情報、請求情報などです。クレジットカード情報と口座情報はマイページで扱っていないため対象外とされています。同社は、システムへの侵入や脆弱性を悪用したアクセスは確認されていないと説明しています。

契約者がやることは3つに絞れます。「ハイホーが倒産する」「手続きのためログイン情報を教えてほしい」といった電話はその場で切ること。ログイン情報を伝えた覚えがあれば、マイページのパスワードを変えること。そして、登録メールアドレスが知らないものに変わっていないか確かめることです。開発者が受け取る教訓は1点です。本人が知っている情報だけでログインできる仕組みは、本人に聞けば破れます。

ハイホーの契約者が最初に確かめること：対象サービス・閲覧情報・電話の断り方

対象は6系統のサービスで、件数は人数ではなく契約単位の3万8,509件

ハイホーの公式発表が対象として挙げたサービスは次の6系統です。

• BiZiMo光／BiZiMoネット
• 光ギガ
• CLOUD LINE
• Toppa!
• ダントツネット／ダントツひかり
• CP WiMAX

3万8,509件は契約ごとに数えた件数です。1人で複数の契約を持っている場合も、契約ごとにそれぞれ1件として数える集計です。実際に閲覧された、または閲覧された可能性がある契約者のうち一部には個別に連絡済みで、該当者全員に書面で個別に案内するとしています。書面が届くかどうかが、対象かを知るいちばん確かな手がかりになります。

閲覧された可能性がある情報：氏名・住所・契約と請求、カードと口座は対象外

発表は、閲覧された可能性がある情報を「お客様ごとに異なります」としたうえで、氏名、住所、電話番号、メールアドレス、契約情報、請求情報、その他マイページ上で確認できる情報を挙げています。契約情報と請求情報が含まれるため、どのプランをいくらで使っているかまで第三者に知られた可能性があります。

カード番号と口座番号は対象外です。マイページではそもそも扱っていないから、というのが同社の説明でした。それでも、契約内容を知っている相手からの電話は本物らしく聞こえます。「今のプランは月額◯円ですね」と正確に言い当てられても、それは本物の証拠になりません。

「ハイホーが倒産する」と言われたら切る：公式が挙げた5つの勧誘トーク

同社は、次のような説明を受けたらその場で答えず、いったん電話を切るよう求めています。

1. 「ハイホーが倒産する」
2. 「今の契約は使えなくなる」
3. 「自動的に他社へ切り替わる」
4. 「手続きのためログイン情報を教えてほしい」
5. 「会社自体がなくなったので窓口がなくなった」

5つとも、急がせて考える時間を奪う型です。マイページのログインID、パスワード、生年月日などの本人確認情報は、電話の相手が誰であっても伝えないでください。確かめたいときは、こちらから公式サイトに載っている窓口へ連絡し直します。電話や偽の連絡で情報を引き出す手口の分類はソーシャルエンジニアリングの手口と技術的対策で解説しています。

ログイン情報を伝えてしまった場合のパスワード変更とメールアドレスの確認

不審な相手にログイン情報を伝えた、または不正ログインが疑われる場合、同社はすぐにマイページのパスワードを変えるよう案内しています。あわせて、マイページに登録されているメールアドレスが身に覚えのないものに変わっていないかを確かめてください。メールアドレスを書き換えられると、パスワード再設定の案内が第三者に届き、本人が締め出されるおそれがあるからです。

同じパスワードを他のサービスで使っているなら、そちらも変えておきます。問い合わせは、BiZiMo光の契約者はBiZiMo光の問い合わせページ、その他のサービスの契約者は各サービスの問い合わせ窓口から行うよう発表に書かれています。本件専用の電話番号は記載がありません。

公式発表で整理する10月8日の公表内容と、同日に報じられた逮捕事案との関係

10月8日の公表で分かっている事実と、10月16日時点で公表されていない事項

発表によると、他社サービスへの契約切替えを目的とする第三者が電話で勧誘し、その過程で本人からマイページへのログインに必要な情報を聞き出していました。一部の契約者については、電話以外の方法で情報が入手された可能性もあるとしています。同社は不正ログインが疑われる通信元からのアクセスを遮断し、電話番号・郵便番号・生年月日によるログイン方式を廃止しました。より安全性の高い認証方式への移行を進め、警察に相談したうえで関係機関と連携して事実確認を進めているとしています。

一方、不正ログインがいつからいつまで続いたのか、勧誘した第三者が誰なのか、補償があるのかは書かれていません。個人情報保護委員会への報告についても、公式発表の記載からは報告の有無が不明です。同社のニュースリリース一覧を10月16日に確認した時点で、続報は出ていません。本記事はこれらを推測で補いません。

同日に報じられた光回線販売会社の社員逮捕は、本件との関係が公表されていない

同じ10月8日には、光回線の販売会社の社員2人が、他の通信事業者の顧客向けマイページに本人確認情報を使ってログインし、取得した契約情報を乗り換え営業に使ったとして、不正アクセス禁止法違反などの疑いで警視庁に逮捕されたと複数の報道機関が伝えました。手口は似ています。

ただし、ハイホーも警視庁も、この事件がハイホーの3万8,509件に含まれるとは公表していません。公表日と手口が近いことだけを根拠に、同じ事件と決めつけるのは避けるべきです。本記事では別の事案として扱い、関係が公表された時点で追記します。

電話番号・郵便番号・生年月日のログインが破られる理由と知識情報の限界

電話で聞き出せる本人の情報：NIST SP 800-63B-4の知識ベース認証

電話番号、郵便番号、生年月日は、本人が覚えている「知識情報」です。米国国立標準技術研究所のNIST SP 800-63B-4は、3.1.1.2節で、利用者に知識ベース認証（KBA）を使わせてはならない（SHALL NOT）と定め、「最初のペットの名前は？」のような質問を例に挙げています。理由は単純で、こうした情報は本人以外も知っているか、調べられるか、聞き出せるからです。

電話番号と郵便番号は郵便物や契約書類に印字されています。生年月日も、名簿や会話から手に入ります。3つを組み合わせても、秘密の度合いは上がりません。今回の手口は、その3つを本人の口から言わせるものでした。パスワードを推測で破る必要すらなく、正しい値を持った第三者がログイン画面に入力しただけです。

システムへの侵入がなくても漏えいは起きる：正規のログイン画面を通る不正

同社は「システムへの侵入や、システム上の脆弱性を悪用したアクセスは確認されていない」と書いています。これは事実として受け止めてよい一方、安全だったという意味にはなりません。第三者は正規のログイン画面から、正しい値でログインしています。ファイアウォールや脆弱性診断では見つからない種類の不正です。

防ぐ手段は2つの層に分かれます。1つは認証そのものを、聞き出しても使えない形に変えること。もう1つは、正しい値でのログインでも、振る舞いが不自然なら止めることです。3万8,509件という規模は、少数の第三者が多数の契約にログインした可能性を示しており、後者の検知が効く場面です。次の章のコードは、この2つの層を最小限の形で示します。

秘密の質問や生年月日を本人確認に残している会員サイトの見直し箇所

ログイン画面を直しても、パスワード再設定や問い合わせ窓口で生年月日を本人確認に使っていれば、そこが新しい入口になります。OWASPの秘密の質問に関するチートシートも、秘密の質問は答えが調べられたり推測されたりしやすく、単独の認証手段にすべきでないという立場です。見直す箇所は、ログイン、パスワード再設定、メールアドレス変更、電話窓口での本人確認の4か所です。パスワードの扱いそのものはNIST SP 800-63B-4に沿ったパスワード管理で整理しています。

マイページ認証を作り直すPythonコード：パスワード照合・再認証・多契約検知

生年月日を照合に使わず、メール変更に再認証を求めるPythonコードの全文

次の例は、マイページの認証を3つの部品に分けたものです。ログインはIDとパスワードで行い、パスワードはPython標準のhashlibにあるscryptでハッシュ化して保存します。メールアドレスの変更は、直近5分以内の再認証を条件とし、旧アドレスと新アドレスの両方が通知先となる設計です。最後に、1つの通信元が1時間に5つ以上の契約へログインしていたら検知します。追加のインストールなしで動きます。

# 会員マイページの認証を「聞き出せる情報」に頼らない形にする最小例（Python 3.10以上・標準ライブラリのみ）
import hashlib
import hmac
import os
from collections import defaultdict

# 1. ログインはIDとパスワード（scryptでハッシュ化して保存）。生年月日・郵便番号・電話番号は照合に使わない
def hash_pw(password, salt=None):
    salt = salt or os.urandom(16)
    digest = hashlib.scrypt(password.encode(), salt=salt, n=2**14, r=8, p=1)
    return salt, digest

def login(user, password):
    _, expected = hash_pw(password, user["salt"])
    return hmac.compare_digest(expected, user["hash"])

# 2. メールアドレスの変更は直近5分以内の再認証を条件にし、旧アドレスにも通知する
def change_email(user, new_email, reauth_at, now):
    if now - reauth_at > 300:
        return "拒否: 再認証が必要"
    notices = [("旧アドレス", user["email"]), ("新アドレス", new_email)]
    user["email"] = new_email
    return "変更: " + " / ".join(f"{k}に通知" for k, _ in notices)

# 3. 1つの通信元が短時間に多数の契約へログインしていないかを検知する
def multi_account_sources(events, window=3600, threshold=5):
    seen = defaultdict(set)
    flagged = {}
    for ts, src, account in sorted(events):
        seen[src] = {(t, a) for t, a in seen[src] if ts - t <= window}
        seen[src].add((ts, account))
        accounts = {a for _, a in seen[src]}
        if len(accounts) >= threshold:
            flagged[src] = len(accounts)
    return flagged

salt, h = hash_pw("long-unique-passphrase")
user = {"salt": salt, "hash": h, "email": "old-addr"}
print("正しいパスワード:", login(user, "long-unique-passphrase"))
print("生年月日を入れた場合:", login(user, "19800101"))
print("再認証なしの変更:", change_email(user, "new-addr", reauth_at=0, now=1000))
print("再認証ありの変更:", change_email(user, "new-addr", reauth_at=900, now=1000))

events = [(i * 60, "203.0.113.7", f"contract-{i:03d}") for i in range(8)]
events += [(100, "198.51.100.20", "contract-500"), (200, "198.51.100.20", "contract-500")]
print("多数の契約へログインした通信元:", multi_account_sources(events))

Python 3.14.7の実行結果：1つの通信元から8契約へのログインを検知

正しいパスワード: True
生年月日を入れた場合: False
再認証なしの変更: 拒否: 再認証が必要
再認証ありの変更: 変更: 旧アドレスに通知 / 新アドレスに通知
多数の契約へログインした通信元: {'203.0.113.7': 8}

2行目は、生年月日を入力してもログインできないことを示しています。照合に使っているのは本人が決めたパスワードのハッシュだけなので、電話で生年月日を聞き出されても入口になりません。3行目と4行目は、再認証から5分を過ぎた変更が拒否され、5分以内の変更では旧アドレスにも通知が飛ぶことを示します。NIST SP 800-63B-4の4.6節も、認証器の追加やアカウント回復のような出来事を、登録済みの通知先へ知らせることを求めています。

5行目では、203.0.113.7という1つの通信元が7分間で8つの契約にログインしたため検知されました。同じ通信元から同じ契約へ2回ログインした198.51.100.20は、契約数が1なので対象外です。家族が1台のパソコンで2〜3契約を見るのは普通でも、1時間に数十の契約へログインする利用者はまずいません。

検知のしきい値の決め方と、SMS認証を追加するかどうかの判断基準

しきい値の5は例です。実際には、過去のログイン記録から「1つの通信元が1時間にログインした契約数」の分布を取り、上位0.1%に当たる値を初期値にします。代理店や法人の管理者が多数の契約を扱う運用があるなら、その通信元を別枠で管理します。連続したログイン失敗の上限は、NIST SP 800-63B-4の3.2.2節が100回以下と定めており、これより低い値を選んでかまいません。

パスワードに加えてSMSのワンタイムコードを求めるかは、電話で聞き出される手口に効くかで判断します。SMSのコードも「今届いた番号を読み上げてください」と言われれば聞き出せるため、それだけでは本件の手口を防ぎ切れません。メールアドレス変更時の通知と、多契約ログインの検知を先に入れ、その次に認証の強化を検討する順番が現実的です。要素の組み合わせ方は多要素認証（MFA）の3要素と実装方式、パスワード自体をなくす移行はパスワードレス認証の方式4分類と移行判断で扱っています。

会員マイページを持つ通信・サービス事業者が点検する順番と委員会への報告

閲覧された時点で漏えいに当たる：速報3〜5日以内と確報60日以内の報告

第三者がマイページで個人データを閲覧すれば、それは漏えいに当たります。個人情報保護委員会の案内では、不正の目的をもって行われたおそれがある漏えいは件数にかかわらず報告の対象で、速報は事態を知った日から3〜5日以内、確報は60日以内とされています。本人への通知も必要です。ハイホーが該当者全員に書面で案内するとしているのは、この通知に当たる対応と読めます。報告の段取りは個人情報保護委員会への報告義務の実務にまとめています。

知識情報だけでログインできる会員サイトは作り直す：採用と見送りの条件

判断は言い切れます。電話番号、郵便番号、生年月日、会員番号のように、郵便物や会話から手に入る値だけでマイページに入れるなら、その方式は作り直す対象です。ID発行の手間を省くために導入されていたとしても、今回の件で、聞き出す手口の前ではほぼ無防備だと分かりました。最初に、ログインとパスワード再設定とメールアドレス変更の3か所で、知識情報だけで通れる経路が残っていないかを洗い出します。

逆に、すでに本人が決めたパスワードとメール通知で運用していて、ログインの記録を通信元ごとに見られるなら、作り直しまでは要りません。多契約ログインの検知を足し、電話窓口での本人確認の手順を見直せば足ります。会員マイページの認証方式の切り替えや、ログイン記録の集計基盤を自社だけで組み直すのが難しい場合は、会員管理システム開発で設計から相談を受け付けています。

よくある質問

ハイホーのマイページへの不正ログインについて、契約者から出やすい質問をまとめました。

ハイホーの不正ログインの対象かどうか、自分で確認する方法はありますか？

10月16日時点で、自分が対象かを調べる照会ページは案内されていません。同社は該当する契約者の一部に個別に連絡済みで、該当者全員に書面で個別に案内するとしています。書面を待つ間も、マイページの登録メールアドレスが変わっていないかは自分で確かめられます。不安な場合は、契約しているサービスの公式問い合わせ窓口に、自分から連絡してください。

ハイホーの担当を名乗る電話がかかってきました。本物ですか？

電話の相手が本物かどうかは、その場では判断できません。同社は「ハイホーが倒産する」「今の契約は使えなくなる」「手続きのためログイン情報を教えてほしい」などと言われたら、その場で答えずに電話を切るよう求めています。ログインIDやパスワード、生年月日は誰にも伝えず、公式サイトに載っている窓口へ自分から確かめ直してください。

クレジットカード番号や銀行口座は見られていますか？

同社によると、マイページではクレジットカード情報と口座情報を扱っていないため、これらが閲覧された可能性はありません。閲覧された可能性があるのは、氏名、住所、電話番号、メールアドレス、契約情報、請求情報などです。金銭被害や不正利用などの二次被害は、公表時点で確認されていないとされています。

hi-hoのプロバイダを使っていますが、対象になりますか？

発表が対象として挙げたのは、BiZiMo光／BiZiMoネット、光ギガ、CLOUD LINE、Toppa!、ダントツネット／ダントツひかり、CP WiMAXの6系統です。この一覧に含まれないサービスについて、発表は触れていません。自分の契約がどのサービス名か分からない場合は、請求書や契約書類のサービス名を確かめ、その窓口に問い合わせてください。

ログイン情報を伝えてしまいました。何をすればいいですか？

すぐにマイページのパスワードを変更し、登録メールアドレスが身に覚えのないものに変わっていないかを確かめてください。同社が発表で求めている対応です。同じパスワードを他のサービスで使っていれば、そちらも変えます。補償の有無は10月16日時点で公表されていないため、補償を名目に振込やカード番号の入力を求める連絡には応じないでください。

関連記事

• KDDI系メール漏えい：BIGLOBE・@niftyの「システムアップグレードに伴う本人確認のお願い」と電話は本物か：同じプロバイダ業界で起きた事案と、本人確認を装う連絡の見分け方
• ローソンID不正アクセス：215万件漏えいの対象確認と本物メールの見分け方：同じ10月8日に公表された会員情報の流出と本人表示APIのトークン検証
• ソーシャルエンジニアリングとは？手口の分類と実装者向けの技術的対策を解説：電話で情報を聞き出す手口の全体像
• 多要素認証（MFA）とは？3要素と実装方式・耐フィッシングMFAをコード付きで解説：知識情報に頼らない認証要素の組み合わせ方
• 不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順：運営者として点検する範囲の全体像