「Have I Been Pwned」は危険？安全性の真実と企業のメールアドレス漏洩を一括監視する手順

「Have I Been Pwned（HIBP）」は、入力情報が抜き取られる危険なサイトではなく、英国政府や米国FBI等の公的機関が公式採用する安全な漏洩検証プラットフォームです。パスワード検索時も「k-Anonymity（k-匿名性）」により平文やハッシュ全体は送信されません。企業ではDNS認証による「Domain Search」で社員アカウントの流出を監視し、Microsoft 365の多要素認証（MFA）強制と併用することが最大の防御策となります。

企業の認証情報が流出し、パスワードリスト攻撃に悪用される事例が相次いでいます。漏洩状況を確認したいものの、「HIBPは安全なのか」と不安を抱く情シス担当者も多いはずです。

本記事では、HIBPの安全性の技術的根拠、自社ドメインを一括監視するDomain Searchの登録手順、漏洩発覚時のアカウント保護フローを実務目線で解説します。

合わせて読みたい
※漏洩したアカウント情報による不正アクセスを100%遮断するMicrosoft 365の多要素認証（MFA）設定手順は、以下の個別ガイドをご覧ください。
→ 中小企業のMicrosoft 365セキュリティ初期設定｜多要素認証

あわせて読みたい

【2026年最新】中小企業のMicrosoft 365セキュリティ初期設定｜今すぐ見直すべき必須項目と多要素認証 Microsoft 365（旧Office 365）を「初期設定のまま」社内で運用するのは極めて危険な状態と言わざるを得ません。マイクロソフト公式の脅威インテリジェンスによれば、多...

---

「Have I Been Pwned（HIBP）」は危険ではない！世界中の政府・公的機関が推奨する理由

HIBPの運営元の信頼性や公的機関との公式連携実績、そして読み取り専用システムの安全構造を順に見ていきましょう。

運営者トロイ・ハント氏の経歴と各国政府・法執行機関が公式推奨する根拠

「Have I Been Pwned（HIBP）」に対して「怪しい海外のハッカーサイトではないか」という懸念を抱く方は少なくありません。しかし、その運営実態と創設者の経歴を確認すれば、極めて高い信頼性を持つプロジェクトであることが分かります。

HIBPは、オーストラリア在住の著名なサイバーセキュリティ研究者であり、Microsoftの地域ディレクター（Regional Director）および元Microsoft MVPを務めるTroy Hunt（トロイ・ハント）氏によって、2013年に設立されました。同氏は世界的なセキュリティカンファレンスで多数の登壇実績を持ち、情報セキュリティ業界における著名な専門家として広く認知されています。

HIBPの信頼性を裏付ける主な国際機関・政府の連携実績を表にまとめました。

連携・推奨機関	具体的な連携内容と活用事例
英国国家サイバーセキュリティセンター（NCSC）	政府機関や国民向けのアカウント侵害早期警戒システムにHIBPのデータを公式採用
オーストラリア連邦警察（AFP）	押収したダークウェブの流出認証情報をHIBPへ提供し、被害者への通知を支援
米国連邦捜査局（FBI）	ボットネット解体作戦等で押収した流出パスワードデータをHIBPと公式共有
東京都サイバーセキュリティポータル	中小企業・都民向けセキュリティガイドブックにて公式の漏洩チェック先として紹介

このように、各国政府や警察組織が押収した流出データベースを正式にHIBPへ提供している事実そのものが、運営元の盤石な信頼性を雄弁に物語っています。単なる民間の無料サイトではなく、国際的なサイバー犯罪対策インフラの一部として機能しているのが実情といえるでしょう。

メールアドレスを入力しても抜かれない？「照合のみ」の読み取り専用システム

多くのユーザーが最も不安に感じるのが、「HIBPの検索窓に社用メールアドレスを入力したら、そのアドレスが新規に記録・収集されて迷惑メールや標的型攻撃の標的にされるのではないか」という点です。

結論からお伝えすると、HIBPの検索エンジンは「過去に流出した公知のデータベースと照合するだけの完全な読み取り専用（Read-Only）」として設計されています。ユーザーが入力した文字列を新たにサーバーへ保存したり、広告企業や第三者へ転売したりする仕組みは一切存在しません。

メールアドレス照合の安全な処理フローを一覧表に整理しました。

ステップ	処理内容	サーバー側でのデータの扱い
1. 検索クエリ受信	入力されたメールアドレスを受け取る	一時メモリ上でのみ処理
2. 既存DB照合	過去の公知データ侵害レコードと照合	新規保存やリスト化は一切なし
3. 結果の表示	一致する侵害事件名（Breach）を返却	画面上に該当サービスを表示
4. セッション破棄	照合完了後にクエリを即時破棄	ログや外部への転売リスクはゼロ

つまり、HIBPで「Pwned!（漏洩しています）」と判定されたとしても、それは「HIBPに入力したから漏洩した」のではなく、「過去に利用していた外部サービスから既に流出していた事実が判明した」に過ぎません。健康診断で病気が見つかるのと同じであり、検査ツール自体が病気を引き起こしているわけではないのです。

1PasswordやFirefoxなど大手セキュリティ製品にバックエンド統合された実績

HIBPの客観的な安全性と精度の高さを証明するもう一つの強力な証拠が、世界的な商用セキュリティソフトウェアや主要WebブラウザへのAPI公式統合です。

もしHIBPのシステムに少しでもセキュリティ上の欠陥や危険性があれば、厳格なセキュリティ監査をクリアしなければならない大手IT企業が自社製品に組み込むことは不可能です。

HIBPのAPIをバックエンドに採用している代表的な商用サービスを表にまとめました。

統合サービス名	活用されている機能	具体的な連携内容
1Password	Watchtower機能	登録パスワードの漏洩チェックにHIBP APIを採用
Mozilla Firefox	Firefox Monitor	ブラウザ標準のデータ侵害アラート基盤として連携
Okta / Cloudflare	エンタープライズ認証	侵害されたパスワードによる不正ログイン遮断に活用

このように、業界の主要プレイヤーたちがこぞって信頼を置くプラットフォームであるため、企業の実務においても安心して利用できる環境が整っています。

---

【注意】パスワード検索画面に「現在使っている本物のパスワード」を入力するのがNGな理由

暗号技術k-Anonymityの数学的な仕組みと、なぜ現役パスワードの入力が推奨されないのかという実務上の境界線を解説します。

ハッシュの先頭5文字しか送らない「k-Anonymity（k-匿名性）」の数学的安全性

HIBPには、メールアドレスだけでなく「特定のパスワードが過去の漏洩リストに含まれているか」を照合できる「Pwned Passwords」という機能が存在します。

これを聞くと、「パスワードを入力させるなんて絶対に危険だ」と感じるのが自然な反応でしょう。しかし、Pwned Passwordsは「k-Anonymity（k-匿名性）」と呼ばれる高度なプライバシー保護技術を実装しており、暗号学的に極めてエレガントな安全性を確保しています。

k-Anonymityによるパスワード照合の仕組みを以下の表にまとめました。

ステップ	実行場所	処理内容と送受信データ
ステップ1	ユーザーのローカルブラウザ	入力したパスワードを「SHA-1ハッシュ値」（40桁の16進数）に変換
ステップ2	ネットワーク送信	ハッシュ値の「先頭5文字（プレフィックス）」のみをHIBPサーバーへ送信
ステップ3	HIBPサーバー側	先頭5文字が一致する過去の漏洩ハッシュ末尾（サフィックス）リストを抽出
ステップ4	サーバーからの応答	一致した数百〜数千件のハッシュ末尾リストをユーザーのブラウザへ返却
ステップ5	ユーザーのローカルブラウザ	返却されたリストの中に、自分の「残り35文字」が含まれるかを端末内で照合

このプロトコルの核心は、「平文のパスワードはもちろん、40桁のフルハッシュすらインターネット上を一切流れない」という点にあります。

先頭5文字（例: 5BAA6）だけでは、世界中に存在する天文学的な数のパスワードが該当するため、HIBPのサーバー管理者や途中の通信傍受者であっても、ユーザーがどのパスワードを照合しようとしたのかを特定することは数学的に不可能です。

なぜ現役パスワードの直接入力は避けるべきか？ショルダーハックと画面共有のリスク

暗号学的にどれほどk-Anonymityが安全であるとしても、企業セキュリティの実務においては「現在業務で実際に使っている現役の生パスワードを、いかなるWebフォームにも直接入力させてはならない」という鉄則が存在します。

技術的な安全性の問題ではなく、ヒューマンエラーや運用上のセキュリティリスクが原因です。

現役パスワードをWeb検索画面に入力することを禁止すべき主なリスク要因を表にまとめました。

懸念されるリスク	具体的な脅威シナリオ	企業実務での対策
画面共有・覗き見	Web会議やオフィス内でパスワード文字が見られる	現役パスワードの入力自体を禁止
端末マルウェア	PC内のキーロガーや不正拡張機能に入力を盗まれる	送信前のローカル傍受を予防
リテラシーの誤認	「Webフォームに本物パスワードを入れてよい」と誤学習	フィッシング詐欺耐性の低下を防止

したがって、情シス部門が社員に案内する際は、「メールアドレスの検索は推奨するが、パスワード検索画面に社内システムの現役パスワードを打ち込んではならない」という明確な境界線を設ける必要があります。

Pwned Passwordsの正しい活用法！過去パスワードの破棄確認と社内ルール設定

では、Pwned Passwords機能はどのように実務活用するのが正しいアプローチなのでしょうか。

最も推奨される使い方は、「過去に使っていた古いパスワードが漏洩リストに載っているかの確認」や、「これから設定しようとしている新しいパスワード候補が、世界中で既に流通している危険な文字列でないかの事前チェック」です。

効果的な活用ユースケースをまとめました。

• 過去パスワードの破棄検証：「以前使っていたあのパスワードは大丈夫だったか」を確認し、もし漏洩していた場合は、現在別のサービスで使い回していないかを徹底点検する。
• パスワードポリシーの辞書攻撃対策：企業内の認証サーバー（Active DirectoryやAzure AD）において、HIBPのPwned Passwords APIを連携させ、社員が「既に漏洩したパスワード」を新規登録しようとした際に自動で弾くセキュリティフィルターを構築する。

道具の特性を正しく理解し、適切な運用ルールと組み合わせることで、強固な防御壁を築くことが可能になります。

---

自社ドメインの漏洩を一括監視するDomain Search登録手順と発覚時の初動対応

情シス担当者必見のDomain Search導入手順から、社員の漏洩が発覚した際の具体的な初動対応フローまでを詳しく見ていきましょう。

情シス必見！DNS TXTレコード認証で自社ドメインを登録する3ステップ

企業のシステム管理者にとって、社員一人ひとりに「各自でHIBPを検索してください」と依頼するのは実効性に欠けます。退職者やアカウント放置、個人の確認漏れが発生するためです。

そこで活用すべきなのが、自社が保有するコーポレートドメイン（例: @company.co.jp）を一括登録し、傘下の全メールアドレスの漏洩を一元管理できる「Domain Search」機能です。

他人が勝手に他社のドメインをスキャンできないよう、厳格なドメイン所有権認証（DNS認証）が義務付けられています。具体的な登録3ステップを一覧表に整理しました。

ステップ	作業内容	具体的な操作手順
ステップ1	ドメイン登録申請	HIBPの「Domain search」画面で自社ドメイン名（company.co.jp）を入力
ステップ2	DNS TXTレコード設定	発行された認証用トークン（TXTレコード）を自社のDNS設定に1行追加
ステップ3	所有権の検証とスキャン	HIBP画面で「Verify」をクリックし、認証完了後に全アドレスの漏洩レポートを抽出

DNS設定権限を持つ正規の管理者しか登録できない仕組みになっているため、機密保持の観点からも極めて安全です。

一度認証を済ませておけば、将来的に新たな大規模情報漏洩事件が発生した際にも、自社の社員アドレスが含まれていた場合に自動でアラート通知を受け取ることができます。

社員のメールアドレス漏洩が見つかった瞬間にやるべき「パスワード強制リセット」

Domain Searchを実行した結果、自社の社員アドレスが「Pwned」として検出された場合、情シス担当者はパニックにならず、あらかじめ定められた緊急初動対応プロトコルに従って迅速に対処する必要があります。

最優先で実施すべきアクションは、「該当アカウントのパスワード即時強制リセット」です。

流出が発覚した際の初動対応ステップをまとめました。

1. 該当社員への即時通知と利用状況のヒアリング：漏洩元の外部サービス（例: 過去に業務で登録した外部Webツール等）を確認し、社内システムと同じパスワードを使い回していなかったかを調査。
2. 社内IdP（Entra ID / Google Workspace）での強制パスワード変更：管理コンソールから該当ユーザーのパスワードをリセットし、次回サインイン時に推測不可能な新パスワードの再設定を強制。
3. パスワード生成ルールの適用：16文字以上、大文字・小文字・数字・記号を組み合わせたランダム文字列をパスワードマネージャー等で生成させる。

パスワードを変更しただけでは、既にログインに成功している攻撃者を締め出すことはできません。次のステップが極めて重要になります。

全セッション即時破棄とMicrosoft 365の多要素認証（MFA）義務化

パスワード変更と同時に絶対に見落としてはならないのが、「既存アクティブセッションの強制破棄（Revoke Sessions）」です。

現代のクラウドサービス（Microsoft 365やGoogle Workspace）では、一度ログインすると数日〜数週間にわたりセッションクッキー（リフレッシュトークン）が維持されます。そのため、パスワードだけを変更しても、既に侵入している攻撃者の接続は切れず、社内メールやSharePointの機密データを盗み見られ続ける危険性があります。

情シス管理者が直ちに行うべきクラウド認証保護の設定項目を表に整理しました。

対象プラットフォーム	実施すべき設定・操作	具体的な効果
Microsoft 365（Entra ID）	「すべてのセッションを取り消す（Revoke）」を実行	攻撃者が接続中のPC・スマホ全端末から強制ログアウト
Google Workspace	「ログインCookieをリセット」を実行	アクティブな全Webセッションおよびアプリ接続を無効化
多要素認証（MFA）	条件付きアクセスまたはMFA強制ポリシーの適用	パスワードが漏洩していても追加認証なしではログイン不可

多要素認証（MFA）が有効になっていれば、仮にダークウェブでIDとパスワードが完全に流出していたとしても、攻撃者は物理デバイスによる追加認証を突破できず、不正アクセスは100%水際で遮断されます。

合わせて読みたい
※万が一社内ネットワークへの実害や不審なアクセスログが確認された場合の全社初動対応手順は、以下のマニュアルをご覧ください。
→ サイバー攻撃・個人情報漏洩時の初動対応マニュアル

あわせて読みたい

【2026年最新】サイバー攻撃・個人情報漏洩時の初動対応マニュアル｜報告義務とフォレンジック調査の費... サイバー攻撃やランサムウェア感染、個人情報漏洩などのセキュリティインシデントが発生した際、企業の命運を分けるのは「発覚直後1時間の初動対応」と「法制度に則った...

パスワード使い回しによるクレデンシャルスタッフィング攻撃を断つ社内教育

なぜ社員のメールアドレス漏洩が企業にとって致命的な脅威となるのか、その根本的な理由は「社員による私用・公用パスワードの使い回し」にあります。

サイバー攻撃者は、HIBPに登録されているような外部サービスの大規模流出リストを入手すると、専用のボットネットを用いて標的企業のMicrosoft 365やVPNゲートウェイに対して自動で総当たりログインを試みます。これが「クレデンシャルスタッフィング（リスト型アカウントハッキング）」と呼ばれる攻撃です。

社員が「業務とは無関係な民間のセミナーサイトや勉強会サイト」に社用メールアドレスと社内共通パスワードを登録していた場合、そのマイナーサイトがハッキングされただけで、企業の基幹システムへノーマークで侵入されてしまうのです。

社内セキュリティ教育で徹底すべき重点ルールを整理しました。

• 社用メールアドレスの私的利用の厳罰化：プライベートなショッピングサイトや趣味のWebサービスに社用アドレスを登録することを規約で禁止する。
• パスワード使い回しの全面禁止とパスワードマネージャーの導入：全社で「1Password」や「Bitwarden」などの法人パスワードマネージャーを配備し、全サイトで異なるランダム文字列を生成させる。
• 定期的な漏洩監査の社内アナウンス：「情シスが定期的にドメイン全体の漏洩チェックを行っている」と周知することで、社員のパスワード管理意識を底上げする。

単に恐怖を煽るのではなく、適切なツールとルールをセットで提供することが、組織全体のセキュリティ耐性を高める鍵となります。

まとめ：Have I Been Pwnedが危険か見極めて漏洩対策を自動化しよう

ここまで、「Have I Been Pwned」の運営元の信頼性や暗号学的安全性、パスワード直接入力のリスク、そして情シス向けのDomain Search導入手順から初動対応までを詳しく解説してきました。

HIBPは、決して個人情報を抜き取るような危険なサイトではなく、世界中の公的機関やトップ企業が標準採用しているセキュリティ監視基盤です。メールアドレスの照合は完全な読み取り専用であり、パスワード照合もk-Anonymityによって通信経路上に秘密情報が一切流れません。

企業防衛のために明日から実践すべきアクションプランを箇条書きで振り返りましょう。

• HIBPの安全性を正しく理解する：トロイ・ハント氏の権威性と公的機関連携を把握し、過度な不安を払拭する
• 生パスワードのWeb直接入力は禁止する：暗号学的に安全でも、運用上のショルダーハックやマルウェアリスクを避ける
• 自社ドメインのDomain Searchを設定する：DNS TXTレコード認証で所有権を証明し、全社員のアドレス漏洩を一括監視
• 漏洩発覚時は即時リセット＆全セッション破棄：Entra IDやGoogleコンソールからサインアウトを実行し攻撃者を締め出す
• 多要素認証（MFA）を全社義務化する：パスワードが盗まれていても侵入を100%防ぐ強固な多層防御を構築

サイバー攻撃の脅威は日々進化していますが、正しい知識と自動化された監視体制を持っていれば、恐れる必要はありません。ぜひ自社ドメインのHIBP監視を導入し、安心・安全なBtoBIT環境を実現してください！

---

よくある質問

Q1. 日本語のサイトや日本のサービスから漏洩したデータも登録されていますか？

はい、登録されています。HIBPは海外の大規模サービス（Facebook、X、Adobe、Canva等）だけでなく、日本国内で発生した企業・Webサービスの大規模情報流出データもダークウェブ等で公知となったものは幅広く収集・インデックス化しています。社用アドレスや個人アドレスが過去に日本のショッピングサイトや予約サイト等から流出していた場合でも、しっかりと検知対象に含まれます。

Q2. 自分のメアドが「Pwned!」と赤く表示されたら、即座に被害に遭っているということですか？

即座に不正アクセス被害に遭っているとは限りません。「Pwned!」という警告は、過去のいずれかの外部サービスでデータ侵害が発生し、流出リストの中にあなたのメールアドレスが含まれていたという「過去の事実」を示しているに過ぎません。その流出後にパスワードを変更済みであり、かつ多要素認証（MFA）を設定していれば、現在のアカウントが乗っ取られる危険性は極めて低いです。ただし、同じパスワードを現在も使い回している場合は、直ちに変更する必要があります。

Q3. HIBPの企業向けDomain Searchは無料で利用できますか？

基本的なドメイン検索機能は無料で利用可能です。DNSのTXTレコード認証等でドメイン所有権を証明すれば、登録ドメイン内の全メールアドレスの漏洩履歴を確認できます。さらに、数万アカウント規模の大規模エンタープライズや、APIを通じて社内SIEMツールと常時自動連携させたい組織向けには、月額・年額の有料サブスクリプション（APIキープラン）も提供されています。中小企業であれば、まずは無料枠のドメイン登録から始めることで十分な恩恵を受けられます。

Q4. 漏洩通知メールが届いた場合、どのサービスのアカウントを変更すればいいですか？

通知画面またはメール内に、漏洩元となった具体的な「Breach（侵害事件の名称）」が記載されています（例: 「LinkedIn」「Dropbox」など）。まずはその該当サービスにログインしてパスワードを変更してください。そして最も重要なのは、「その漏洩元サービスで使っていたパスワードと同じ文字列を、社内メールや他社クラウドで使い回していないか」を確認し、もし使い回していた場合は、該当するすべてのサービスのパスワードを一斉に変更することです。

---