ほとんどのOSINTツールは、ウェブサイトのURL構造変更、エンドポイント移動、CAPTCHA強化によってすぐに古くなります。Maigretは例外です。3,000以上のサイトに対応し、Pythonパッケージ、Telegramボット、Web UIを提供しながら、長期間メンテナンスされ続けています。この記事では、Maigretの実装パターンを分解し、壊れにくいスキャナーやAPIテスト設計にどう応用できるかを解説します。
このガイドは、単に「ユーザー名を検索する方法」ではなく、エンジニア向けにMaigretの設計を読むためのものです。Maigretが何をしているのか、合法的な調査・セキュリティ用途は何か、数千サイトにスケールする仕組みは何か、そしてシグネチャデータベース、ドリフト検出、再帰的検証といった考え方を、日々のAPIテストやApidogでの検証にどう転用できるかを扱います。
まだ読んでいない場合は、2026年版 PostmanなしのAPIテストも参考になります。この記事では、パターンマッチングやドリフト検出をAPIテストの文脈で扱っています。
要約（TL;DR）
- Maigretは、ユーザー名を入力すると3,000以上のサイトで公開アカウントをチェックし、プロフィール情報を抽出します。
- 中核は、バージョン管理されたサイトシグネチャデータベースです。
- 検出は単純なHTTPステータスコードではなく、存在文字列、不在文字列、正規表現、ヘッダー、タグなどの複数シグナルで行われます。
- 正当な用途には、OSINT調査、アカウント回復、行方不明者捜索、ブランド悪用監視、承認済みレッドチーム活動があります。
- 個人の同意なしに使用すると、ハラスメントやストーキングに該当する可能性があります。
- Maigretの設計パターンは、APIテストにもそのまま応用できます。シグネチャ駆動、多信号アサーション、定期リプレイ、ドリフト検出は、ApidogでのAPI検証にも有効です。
Maigretとは何か、そして何ではないか
Maigretは、soxojによってメンテナンスされているMITライセンスのPythonツールです。READMEでは「3,000以上のサイトからユーザー名で個人の情報を収集する」と説明されています。
基本的な使い方は次のような流れです。
pip install maigret
maigret username
Maigretはサイトデータベースを参照し、対象ユーザー名が各サイトに存在するかを確認し、見つかった公開プロフィールから情報を抽出してレポートを生成します。
重要な前提は3つあります。
1つ目は、Maigretが扱うのは公開データのみだということです。ログイン、認証情報の悪用、APIキーの利用は行いません。匿名アクセスで見えるプロフィールページがあれば読み取り、見えなければ「見つからない」または「不明」と判断します。
2つ目は、正当な調査の文脈で使われていることです。調査報道、行方不明者捜索、詐欺対策、ブランド保護、承認済みレッドチーム活動などで利用されています。
3つ目は、悪用可能性があることです。本人の同意なく個人を追跡する目的で実行すると、倫理的にも法的にも問題になります。この記事では、人をターゲットにする手順ではなく、ツール設計とAPIテストに応用できる実装パターンに焦点を当てます。
サイトシグネチャデータベース
Maigretの中心は、サイトごとのシグネチャデータベースです。各エントリは、スキャナーが次の判断を行えるだけの情報を持っています。
- 対象サイトでユーザー名をどうURLに埋め込むか
- アカウントが存在する場合、ページに何が表示されるか
- アカウントが存在しない場合、ページに何が表示されるか
- 公開プロフィールからどの情報を抽出できるか
- レート制限やCAPTCHAの可能性があるか
このデータベースはJSON形式で管理され、リポジトリでバージョン管理されています。Maigretは実行時にGitHubから更新を取得できるため、サイト側の変更に追従しやすくなっています。
APIテストでも同じ考え方が使えます。各エンドポイントには、次のような「シグネチャ」があります。
{
"endpoint": "GET /users/{id}",
"expectedStatus": 200,
"requiredFields": ["id", "name", "email"],
"forbiddenFields": ["password"],
"requiredHeaders": ["content-type"]
}
エンドポイントが増えるほど、チェックをコードに直接書くより、データとして管理した方が保守しやすくなります。コントラクトファーストAPI開発やMCPサーバーテストプレイブックでも同じ発想が使われます。
Maigretが「見つかった」と「見つからない」を判定する方法
単純なスキャナーなら、次のようにHTTP GETしてステータスコードだけを見ます。
https://example.com/user/<username>
しかし実際のサイトでは、存在しないユーザーでも200 OKを返すことがあります。たとえば、次のようなケースです。
- 「そのユーザーはいません」というページを
200で返す - ホームページへフォールバックする
- CAPTCHAページを返す
- キャッシュされた汎用ページを返す
そのため、Maigretはステータスコードだけでは判断しません。サイトシグネチャには、より具体的なルールが含まれます。
urlMainurlpresenseStrsabsenceStrs- ユーザー名抽出用の正規表現
- カスタムヘッダー
- カテゴリタグ
- 国タグ
判定イメージは次のようになります。
def is_found(response_text, presence_strs, absence_strs):
has_required_signals = all(s in response_text for s in presence_strs)
has_absence_signals = any(s in response_text for s in absence_strs)
return has_required_signals and not has_absence_signals
「見つかった」と判断するには、存在を示す文字列が揃っており、不在を示す文字列が含まれていない必要があります。それ以外は「不明」として扱い、手動確認の余地を残します。
これはAPIテストでも重要です。200 OKだけでは不十分です。レスポンス本文、ヘッダー、エラー形式まで検証する必要があります。
Apidogでは、1つのリクエストに対してステータスコード、レスポンスボディ、ヘッダーなどのアサーションを設定できます。これは、MaigretのpresenseStrsとabsenceStrsをAPIテストに置き換えたものです。
再帰的検索と情報抽出
Maigretはアカウントを見つけると、公開プロフィールから追加情報を抽出します。
対象になり得る情報は次のようなものです。
- 別のユーザー名
- 実名
- メールアドレス
- 電話番号
- 外部リンク
- 他サービスのプロフィールURL
抽出ルールもサイトごとに定義されます。GitHub、LinkedIn、Instagramではプロフィール構造が異なるため、同じ抽出ロジックでは不十分です。
さらにMaigretは、抽出した識別子を再度検索に使うことがあります。これにより、1つのユーザー名から関連アカウントをたどる再帰的な探索が可能になります。
APIテストでもこの考え方は使えます。たとえば、あるレスポンスに未文書化フィールドが含まれていた場合、それを無視せず、関連エンドポイントやダウンストリーム処理の検証に使います。
例：
{
"id": "user_123",
"name": "Alice",
"billingProfileId": "bp_789"
}
billingProfileIdが仕様書にないなら、次を確認します。
- このフィールドは意図されたものか
- 関連する請求APIに存在するか
- 公開してよい情報か
- テストケースに追加すべきか
Maigretの再帰的検索は、APIテストにおける「レスポンスから次の検証対象を発見する」パターンとして応用できます。
CAPTCHAとレート制限の処理
Maigretは、CAPTCHAやレート制限を完全に突破するツールではありません。レスポンスの形状から検出し、必要に応じて処理を切り替えます。
主な戦略は次のとおりです。
- User-Agentのローテーション
- サイトごとのリトライヘッダーの尊重
- モバイル版または簡易ドメインへのフォールバック
- サイトが許可する場合のTorまたはI2P経由ルーティング
ただし、サイトが強力な自動化防止策を導入している場合、Maigretは「CAPTCHA検出」と記録し、手動確認を促します。敵対的に防御を突破するのではなく、公開アクセスとして許される範囲で動作します。
APIテストでも同じ姿勢が必要です。レート制限に遭遇したら、突破しようとするのではなく、検出してバックオフします。
例：
if (response.status === 429) {
const retryAfter = response.headers.get("Retry-After");
console.log(`Rate limited. Retry after: ${retryAfter} seconds`);
}
テストランナーがレート制限を無視してリクエストを投げ続けると、チームのIPがブロックされる可能性があります。Maigretのように、制限を信号として扱い、適切に停止または待機する設計が安全です。
シグネチャのドリフト問題
3,000以上のサイトに対応するデータベースは、更新され続けて初めて価値があります。サイトは次のように変化します。
- プロフィールページのHTMLを変更する
- URLパターンを変更する
- CAPTCHAを追加する
- 買収やブランド変更でドメインが変わる
- 存在・不在メッセージの文言が変わる
古いシグネチャは、偽陰性または偽陽性を生みます。
Maigretはこれに対して複数のレイヤーで対応しています。
- GitHubリポジトリからの自動更新
- コミュニティによるプルリクエスト
- 手動更新用の
--updateフラグ - 既知の存在ユーザー名に対する検証ハーネス
重要なのは、既知の存在ユーザー名を使ってシグネチャがまだ機能しているかを確認する点です。これはAPIテストの回帰テストと同じです。
APIでは、既知の良好なレスポンスを保存し、定期的にライブエンドポイントへリプレイします。
保存済みフィクスチャ
↓
定期実行
↓
現在のレスポンスと比較
↓
差分があればドリフトとして通知
Apidogでも、エンドポイントごとに期待レスポンスやアサーションを定義し、継続的に検証できます。DeepSeek V4 APIガイドでは、特定ベンダーAPIを検証する際の考え方も扱っています。
オプションのAI要約モード
Maigretには--aiフラグがあります。これは、OpenAI互換のLLMエンドポイントを使って、生の検索結果を短い調査要約に変換する機能です。APIキーはユーザーが用意します。
重要なのは、LLMが判定を行わないことです。
- ユーザー名が存在するかどうかは、ルールベースで判定する
- LLMは、その結果を読みやすく要約する
- 判断ロジックと文章生成を分離する
これはAPI監視でも良い設計です。
決定論的なアサーション
↓
合否判定
↓
実行ログ
↓
LLMによる要約
↓
Slackやレポートに投稿
LLMをテストの判定者にするのではなく、後処理器として使う方が安定します。コンピューター利用 vs 構造化APIでも、構造化されたルールを先に置く重要性を説明しています。
正当なユースケース
Maigretの使用が明確に適切な場面は限られます。
自分のアカウント回復
過去に使っていたユーザー名から、古い公開アカウントを探します。プライバシー監査やデジタルフットプリント整理に役立ちます。ブランド悪用監視
企業名、製品名、サービス名を使ったなりすましアカウントを検出します。行方不明者捜索
家族の同意や関係機関との連携のもと、公開情報を確認します。単独行動は調査を妨げる可能性があります。承認されたレッドチーム活動
契約範囲内で、組織の公開攻撃対象領域を把握します。調査報道
編集上・法的な審査のもとで、詐欺、公人の不正行為、組織犯罪などを調査します。
一方で、次の用途は不適切です。
- 好奇心で見知らぬ人を調べる
- 元パートナーを追跡する
- 同意のない個人データセットを作る
- ハラスメント目的で使う
ツールが公開情報だけを扱うとしても、使い方によっては法的・倫理的な境界を越えます。
APIテストに適用できるMaigretのパターン
MaigretからAPIテストに直接転用できるパターンは5つあります。
1. チェックをコードではなくシグネチャとして管理する
エンドポイントごとの期待値を、テストコードに埋め込むのではなくデータとして管理します。
{
"name": "Get user profile",
"method": "GET",
"path": "/users/{id}",
"expect": {
"status": 200,
"requiredJsonPaths": ["$.id", "$.name", "$.email"],
"forbiddenJsonPaths": ["$.password"]
}
}
これにより、新しいエンドポイントや外部ベンダーAPIを追加しやすくなります。
2. ステータスコードだけで判定しない
200 OKは成功の一部でしかありません。
最低限、次を組み合わせて確認します。
- ステータスコード
- レスポンスボディの必須フィールド
- 含まれてはいけないフィールド
- エラー形式
- Content-Type
- 認証・認可ヘッダー
3. シグネチャを継続的に更新する
API仕様は変化します。人間が気づく前にテストが検出できるよう、アサーションや仕様を同期・更新できる状態にします。
PostmanなしのAPIテストでも、このワークフローを扱っています。
4. ドリフト検出を定期実行する
既知の良好なフィクスチャを保存し、定期的に実行します。差分が出たら、APIの破壊的変更や仕様外変更として検知します。
5. LLMは判定ではなくレポート生成に使う
合否判定は決定論的なルールで行います。LLMは、実行結果を人間が読みやすい形に要約するために使います。
この分離により、テスト結果の信頼性を保ちながら、レポートの可読性を上げられます。
Maigret実行時の一般的な落とし穴
Maigretを試すエンジニアは、次の点に注意してください。
-
-aなしで完全スキャンだと思い込む デフォルトでは上位サイト中心のスキャンになります。ロングテールまで調べる場合は-aを使います。
maigret username -a
-
タグを無視する
--tagsでカテゴリや国を絞り込めます。対象地域に応じてタグを指定しないと、重要なサイトを見落とす可能性があります。
maigret username --tags jp
- 更新をスキップする 古いシグネチャは誤判定の原因になります。本格的な調査前には更新します。
maigret --update
Torブロックをユーザー情報として解釈する
一部サイトはTor出口ノードをブロックします。これは対象ユーザーの存在有無とは関係ありません。抽出フィールドを証拠として扱う
Maigretはページに公開されている情報を抽出します。ページ自体が偽装されている可能性もあります。結果は証拠ではなく、調査の手がかりとして扱うべきです。
実際のユースケース
あるセキュリティコンサルティング会社では、レッドチーム活動のスコープ確認時にMaigretを使い、クライアントの公開攻撃対象領域を把握しています。出力はキックオフレポートに含められ、調査開始前の共通認識を作るために使われます。
フリーランスの詐欺調査官は、--aiフラグを使って3,000サイトのスキャン結果を短い概要にまとめ、非技術系クライアント向けのレポートにしています。検索と判定は決定論的に行い、LLMは読みやすさを補助します。
あるエンジニアリングチームは、Maigretと同じ設計思想を内部APIテストに応用しています。シグネチャデータベース、定期リプレイ、ドリフト検出を使い、200以上のマイクロサービスのAPI仕様変更を検出しています。実装にはApidogを使っていますが、考え方はMaigretと同じです。
結論
Maigretは、変化し続ける外部サイトに対して、壊れにくい検出ルールをどう管理するかを示す良い実例です。OSINTを実施しないエンジニアにとっても、その設計は学ぶ価値があります。
特に重要なのは次の5点です。
- Maigretは、バージョン管理されたシグネチャデータベースで3,000以上のサイトを扱う
- 単純なステータスコードではなく、複数シグナルで判定する
- 長期運用ではドリフト検出が不可欠
- LLMは判定ではなく後処理に使う
- 同じパターンはApidogでのAPIテストにも応用できる
次にやることはシンプルです。Maigretのサイトデータベース形式を読み、次に自分のAPIエンドポイントを同じ視点で整理してください。各エンドポイントに対して、ステータスコード、必須フィールド、不在であるべきフィールド、ヘッダー、既知の良好なレスポンスを定義します。
ベンダーが深夜にフィールド名を変更したとき、ユーザーより先にテストスイートが検知できれば、その設計は成功です。
<!--kg-card-begin: html-->
<!--kg-card-end: html-->
よくある質問
Maigretは合法的に使用できますか？
管轄区域と対象によります。自分自身、自分が所有するアカウント、書面で許可を得た企業、または承認された調査報道の一部として使う場合は、一般的に問題になりにくいです。一方で、同意のない個人に対して使うと、ストーキングやハラスメント関連の法律に抵触する可能性があります。
MaigretはPythonなしで動作しますか？
公式パッケージはPython 3.10+向けです。作者は、手軽な検索用のTelegramボットや、ローカルインストールを避けたいユーザー向けのCloud Shell設定も提供しています。
3,000サイトという主張はどの程度正確ですか？
リポジトリ内のサイトデータベースには3,000以上のエントリがあります。ただし、すべてが常に有効とは限りません。自動更新とコミュニティのメンテナンスにより、動作するサブセットが更新され続けています。
AIモードは何をしますか？
--aiフラグは、OpenAI互換のLLMを使って決定論的な検索結果を読みやすい要約に変換します。検索や判定そのものを変更するものではありません。APIキーはユーザーが用意します。
MaigretをCIで使えますか？
OSINT調査そのものは対話的な作業であり、CI向きではありません。ただし、Maigretが使っている設計パターン、つまりシグネチャデータベース、ドリフト検出、定期リプレイは、APIテストのCIパイプラインに向いています。Apidogでも同様の考え方を実装できます。
Sherlockとは何が違いますか？
Sherlockはより古く、よりシンプルなユーザー名検索ツールです。Maigretは、情報抽出、再帰検索、CAPTCHA処理、AI要約モード、より豊富なサイトデータベースを追加しています。どちらもMITライセンスで、OSINTツール設計を学ぶ上で参考になります。
古いシグネチャはどこに報告すればよいですか？
MaigretリポジトリのGitHub issueまたはプルリクエストで報告できます。コミュニティによる更新が、サイトデータベースの鮮度を保つ重要な仕組みです。
Top comments (0)