メール登録先を調べるOSINTにholeheが選ばれる理由｜類似ツールとの違い

holehe は、あるメールアドレスがどのサービスに登録されているかを外部から推定する Python 製の OSINT ツールです。GitHub のスター数は 13,932、対応サイトは 120 以上と、メールアドレス軸の OSINT では代表的な選択肢のひとつになっています（megadose/holehe）。

ただし、メールアドレスから登録先を洗い出す用途では、ユーザー名軸で幅広く走査する sherlock、少数プラットフォームを高精度で判定する socialscan など、目的が近い OSS が複数存在します。初見のエンジニアが holehe を採用してよいかを判断するには、対応範囲だけでなく、類似ツールとの棲み分け・更新頻度・ライセンスや法的な制約まで見比べる必要があります。

一方で、holehe は最終コミットが 2024 年 9 月時点にとどまり、コミュニティからはレートリミットや偽陽性の増加が指摘されています。ライセンスは GPL-3.0 で、README には Built for educational purposes only. と明記されているため、商用組み込みや業務利用に持ち込む前には確認したい論点がいくつかあります。

本記事では、holehe の位置づけ・基本仕様・使い方の概要、sherlock・socialscan などとの違い、導入前に押さえるべき制約とメンテナンス状況を、公式リポジトリの一次情報をもとに整理します。動作検証は行わず、README・Issue・公開ドキュメントおよび gh api /repos/megadose/holehe で取得したメタデータのみを根拠とします。読み終えたときに「メール軸の登録アカウント特定用途で holehe を採用すべきか」を判断するための材料が揃うことを目指します。

holeheが解決するOSINT課題とメールアドレス調査の位置づけ

OSINT（Open Source Intelligence）文脈で「あるメールアドレスがどのサービスに登録されているか」を洗い出したい場面は複数あります。holehe はこの「メール軸の登録アカウント特定」に用途を絞ったツールです。

メールベース OSINT の主要ユースケース

メールアドレスから登録先を推定するニーズは、主に次の 3 パターンに整理できます。

• 自身・自組織のフットプリント調査: 使い回しているアカウントや、意図せず残っている登録情報を棚卸しする用途。個人ではデジタルフットプリントの点検、企業では退職者アカウントの残存確認などに使われます
• SOC・インシデントレスポンスの初動: 漏洩したメールアドレスがどのサービスに登録されている可能性が高いかを短時間で列挙し、パスワードリセットやアクセス制限など初動対応の優先順位付けに使う用途
• レッドチーム・ペネトレーションテストの偵察フェーズ: 標的メールに紐づく SNS・SaaS の存在をあらかじめ列挙し、ソーシャルエンジニアリングの計画立案に用いる用途

いずれのユースケースでも共通しているのは、「メールアドレスという入力から、対応する登録先を『広く浅く』洗い出す」という工程です。holehe はこの工程を対象サイト 120 以上に対して自動化することを目的にしています。

ターゲットに通知が飛ばない挙動

holehe は、各サービスの「パスワードを忘れた場合」機能などのエンドポイントを利用してアカウント存在の有無を推定する設計です。仕組み上気になるのが「調査対象にメール通知が飛ぶのか」という点ですが、GitHub の Issue #12 ではメンテナがこの点に明確に回答しており、holehe の判定処理ではターゲットのメール受信箱に通知が飛ばない挙動が説明されています。

このため、対象に気付かれずに「登録済みか否か」だけを外部から推定できる点が、他の一般的なパスワードリセット依頼と区別される特徴になっています。ただし後述するとおり、法的な観点で「対象への同意なしにこの調査を行ってよいか」は別問題であり、技術的に通知が飛ばないことは免罪符にはなりません。

holeheの基本仕様と対応サービス120以上の内訳

holehe の基本仕様は、GitHub リポジトリ megadose/holehe の README と、記事執筆時点で gh api /repos/megadose/holehe から取得したメタデータで把握できます。本記事執筆時点では、リポジトリはアーカイブされておらず（archived=false）、フォーク版でもない本家リポジトリ（fork=false）で、可視性は public・無効化もされていません（megadose/holehe）。

基本仕様

一次情報から確認できる主要項目は次のとおりです。

Python 3 系で動作するライブラリ／CLI として提供されており、GPL-3.0 の下で配布されています。スター 1 万超・フォーク 1,800 超という規模は、メール軸 OSINT ツールとしては存在感のある水準です。

対応サイト120以上のカテゴリ傾向

README の Modules テーブルには 120 以上のモジュールが列挙されています。網羅すると煩雑になるためカテゴリ傾向のみ整理すると、SNS（Instagram・Twitter・Snapchat など）、ビジネス／SaaS（Atlassian・Adobe など）、EC・レビュー系サービス、ロシア語圏・フランス語圏に強い地域特化サイト、成人向けサイトなど、幅広いジャンルが混在します。「メール登録の有無」を確認したいサイト側の性質によってモジュールが分かれている構造です。

サイトごとに個別モジュール（holehe/modules/** 配下）として実装されており、対応サイトの追加・修正は該当モジュール単位で行う設計になっています。

モジュール出力フォーマット

各モジュールは辞書型で結果を返し、フィールドは次のように定義されています（megadose/holehe README）。

• name: 対象サイト名
• rateLimit: レートリミットに引っかかったかどうか
• exists: メールアドレスがそのサイトで使用されているかどうか
• emailrecovery: パスワードリセット用に部分マスクされたメールなど、追加取得できたリカバリ情報
• phoneNumber: 部分マスクされた電話番号
• others: サイトから追加取得できたその他情報

「登録の有無」だけでなく、パスワードリセット機能から得られる断片情報（マスク済みメール・電話番号など）も一部モジュールで取得できる設計になっている点が、holehe の情報密度を高めています。

CLI・Pythonライブラリ・Dockerでのholehe使い方

holehe は、CLI／Python ライブラリ／Docker の 3 通りで利用できます。ここでは README の Installation / Quick Start セクションからの抜粋を、改変せずに引用します。

CLI での基本実行

PyPI からインストールし、CLI として実行する例です。

pip3 install holehe

（出典: megadose/holehe README）

インストール後は、メールアドレスを引数として与えます。

holehe test@gmail.com

（出典: megadose/holehe README）

CLI 実行では、対応モジュールをまとめて走査し、モジュールごとに exists / emailrecovery / phoneNumber / rateLimit の判定結果が出力されます。PoC として「特定のメールアドレスに対して holehe がどの程度の情報を返すか」を素早く確認するには、この経路が最短です。

Python ライブラリとして統合する

Python アプリケーションに組み込む場合は、モジュールを個別に呼び出す例が README に示されています。ここでは Snapchat モジュールを非同期に呼び出す例を、原文のまま引用します。

import trio
import httpx
from holehe.modules.social_media.snapchat import snapchat

async def main():
    email = "test@gmail.com"
    out = []
    client = httpx.AsyncClient()

    await snapchat(email, client, out)

    print(out)
    await client.aclose()

trio.run(main)

（出典: megadose/holehe README）

trio と httpx.AsyncClient を用いて非同期に個別モジュールを呼び出す形になっており、必要なサイトだけを狙って呼び出したい場合や、他の調査パイプラインに部分的に組み込みたい場合はこの経路が向きます。逆にすべてのモジュールを一度に走らせたい場合は、CLI 実行のほうが素直です。

Docker で隔離実行する

Git 直接クローンや Docker 実行の手順も README に記載されています。Docker 経路の代表例を抜粋します。

docker build . -t my-holehe-image

（出典: megadose/holehe README）

docker run my-holehe-image holehe test@gmail.com

（出典: megadose/holehe README）

コンテナで実行することで、ホスト環境から依存を切り離せます。加えて、後述するレートリミットを避ける目的で、コンテナごとにネットワーク経路を切り替える運用が採られることもあります。ただしレートリミットの根本原因は各サービス側のレート制御であり、コンテナで回避できる範囲は限定的です。

sherlock・socialscanとの違いと選定判断の軸

「メール／ユーザー名から登録先を洗い出す OSINT ツール」というカテゴリでは、holehe 以外にも代表的な選択肢が複数あります。ここでは類似性の高い 2 リポジトリを軸に比較します。

比較表

一次情報として参照したのは、それぞれの公式リポジトリです（sherlock-project/sherlock / iojw/socialscan）。

holehe は「メールアドレスを入力し、対応サイトの数を稼ぐ」方向に振っており、socialscan は「対応数を絞ってでも精度を担保する」方向、sherlock は「そもそも入力軸をユーザー名にする」方向で、狙いが明確に分かれています。

なお参考として、ユーザー名軸でさらに対応数を広げた soxoj/maigret もあり、ユーザー名軸で 3,100 サイト以上への対応とプロファイル解析を提供します。メール軸／ユーザー名軸のどちらから攻めるかで最適な選択肢は変わります。

用途別の使い分け

上記の性格を踏まえると、実務上の使い分けは次のように整理できます。

• 入力がメールアドレスで、まずは広く浅く登録先を洗い出したい → holehe が第一候補。パスワードリセット機能由来の偽陽性やレートリミットが混入する前提で結果を扱う
• 少数プラットフォームでよいので、判定精度をできる限り担保したい → socialscan を検討。登録用エンドポイントを直接叩く方針で精度を優先しており、メール対応 8／全体 14 プラットフォームに絞られる
• 入力がユーザー名（メールではない）で、大量サイトを横断したい → sherlock／maigret。holehe は入力軸が違うため代替にはならない
• メール軸とユーザー名軸を同時に走らせたい → holehe（メール軸）と sherlock／maigret（ユーザー名軸）を並走させ、パイプライン側で結果を突合するのが素直

「メール軸」「ユーザー名軸」「精度優先」の 3 つの軸で見ると、これらのツールは代替関係というより相補関係にあります。holehe 単体で決めるのではなく、少なくとも入力軸と精度スタンスを揃えたうえで比較すべきカテゴリです。

導入前に押さえたい制約とメンテナンス状況

対応範囲と使い方だけで採用判断をすると、運用に持ち込んだ後で困る論点がいくつかあります。以下は事前に確認しておきたい 3 点です。

最終更新と偽陽性・レートリミットの実態

gh api /repos/megadose/holehe で取得したメタデータでは、最終 push は 2024-09-10 です。本記事執筆時点（2026 年 8 月）で約 1 年 11 か月にわたり更新がない状態になっています。リポジトリはアーカイブ状態にはされていない（archived=false）ものの、アクティブに追随されているとは言えません。

コミュニティ側でも、対象サイトの仕様変更に追従できていないモジュールが増え、レートリミットに引っかかりやすくなっている点や、偽陽性・偽陰性が増えている点への言及があります（例: DEV Community "RIP Holehe: Why User-Scanner is the New King…）。継続的な結果精度を前提とする業務用途では、モジュールごとの動作確認・スポットチェックの運用コストを織り込む必要があります。

GPL-3.0 のコピーレフト影響

holehe のライセンスは GPL-3.0 です。GPL は「派生物にも同じライセンスの適用を求める」コピーレフト条項を持ち、holehe のコードを取り込んだプロダクトを配布する場合、そのプロダクト全体を GPL 準拠で公開する必要が生じる可能性があります。ライセンス条文の一次ソースは GNU 公式の GPL-3.0 全文 です。

社内ツールで使う分にはコピーレフトの配布要件は発生しにくい一方、SaaS の一部として提供する場合や、顧客に配布するパッケージに組み込む場合は、GPL の適用範囲・AGPL との差異・リンク方式（プロセス分離か直接インポートか）を事前に確認しておく必要があります。判断が難しい場合は、法務や OSS ライセンスに詳しい担当と早めに擦り合わせるべき論点です。

「教育目的のみ」と日本国内の法的注意

README には Built for educational purposes only. と明記されています。この文言は開発側の免責の位置づけであり、実務利用時のリスクを利用者が引き受ける前提です。

日本国内で運用する場合、少なくとも次の観点は事前確認が必要です。

• 同意取得: 調査対象のメールアドレス所有者が、自組織のリソース（従業員アカウント）ではない場合、無断で他社サービスへの登録有無を洗い出す行為が個人情報保護・プライバシー侵害・不正競争防止法などの観点で問題にならないかを確認する
• 不正アクセス禁止法との関係: holehe の設計上は「登録済みかどうかの推定」であり、他人のアカウントに実際にアクセスするわけではないものの、パスワードリセットフローの利用がサービス提供者の利用規約に抵触するケースがある
• ログ管理と説明責任: 業務として実施するのであれば、いつ・誰が・どの目的で・どのメールアドレスに対して調査を行ったかを追跡できるようにしておく
• 国外サーバとの通信: 対応モジュールには海外サービスが多く含まれ、通信ログの取り扱いに関する社内規程への抵触有無を確認する

「技術的に通知が飛ばない」ことと「法的・契約的に許容される」ことは別問題です。少なくとも自組織の情報セキュリティ規程・法務レビューを通したうえで運用に組み込むことが前提になります。

holeheを採用すべきか判断する3つのチェックリスト

ここまでの整理を判断軸に落とし込むと、holehe を採用してよいかは次の 3 点で概ね絞り込めます。

• (a) 入力軸がメールアドレスで、対応サイトの広さを優先したい調査か？ 「はい」なら候補として妥当。「入力がユーザー名」「精度重視で少数サイトでよい」場合は、sherlock／maigret／socialscan を優先候補にすべきカテゴリです
• (b) 最終更新 2024 年 9 月から止まっている状態を許容できる用途か？ ワンショットの調査や、モジュール単位で結果を検証しながら使う用途は許容しやすい一方、継続的な結果精度を前提にした自動化パイプラインでは、モジュール別のスポットチェック運用が必要です
• (c) GPL-3.0 のコピーレフトと「教育目的のみ」の免責を許容できる利用形態か？ 社内での調査利用は許容しやすい一方、外部配布・SaaS への組み込みは GPL の適用範囲を法務と確認する前提になります。業務利用は自組織の情報セキュリティ規程・法務レビューを通したうえで実施することが前提です

3 点すべてで「許容できる」となる場合は、holehe は現時点でもメール軸 OSINT の有力候補として選定に値します。逆にいずれかで引っかかる場合は、sherlock／socialscan／maigret などの近接ツールで代替可能かを併せて検討するのが安全な進め方です。

まとめ

holehe は、メールアドレスから登録済みアカウントを洗い出す用途に特化した Python 製の OSINT ツールで、対応サイト 120 以上と幅広い網羅性を持ちます。パスワードリセット機能を利用する設計上、対象に通知が飛ばずに「登録の有無」を確認できる点は、この用途で選ばれる大きな理由のひとつです。

一方で、最終更新が 2024 年 9 月にとどまり、コミュニティからは偽陽性・レートリミット増加への指摘が出ています。ライセンスは GPL-3.0 のコピーレフトで、README にも Built for educational purposes only. と明記されています。継続的な結果精度・商用組み込み・法的リスクを前提とする用途では、これらの制約を織り込んだうえで採用可否を判断する必要があります。

初見のエンジニアが holehe を採用すべきかを判断する際は、入力軸（メール軸か、ユーザー名軸か）と精度要件（対応数優先か、精度優先か）で sherlock・socialscan・maigret と比較し、そのうえで更新頻度と GPL・法的注意を許容できる利用形態かを確認する順序が実務的です。この記事で示した 3 つのチェックリストが、その判断の材料になれば幸いです。

関連情報

OSINT ツールを組み込んだセキュリティ調査基盤・監査ワークフローの設計や、Python ベースの内製ツール整備をご検討中の方は、お問い合わせフォーム からご相談ください。要件整理の段階からご相談いただけます。