AI で書かれたフィッシングメールをどう見抜くか — 2026 年の検知設計

3 年前まで「不自然な日本語」「明らかな誤字」「変な敬語」はフィッシングメールを見分ける十分な手がかりだった。受信者の側でも「あ、これはダメだ」と直感的にわかるレベルで文面が破綻していたから、技術側の検知も補助的でよかった。

LLM が攻撃者側の道具になった結果、この前提は完全に崩れた。KnowBe4 が 2025 年から継続観測しているサンプルでは、フィッシングメールの 8 割以上が AI 生成テキストを含んでいる。生成にかかる時間は手作業時代の 16 時間から数分に短縮され、攻撃者は 1 つのキャンペーンで数百種類の文面バリエーションを並列で出せる。文面の品質は通常のビジネスメールと区別できない水準で、敬語・社内用語・業界専門語までターゲットの所属に合わせて出し分けてくる。

人間がメールの文面を読んで判断するレイヤは、もう破綻している前提で防御を設計する必要がある。本稿では「メール本文の判定をやめて、送信インフラと着地先 URL の検証に重心を移す」具体的な実装を整理する。

文面以外の検証点を増やす

文面そのものが破綻していた時代、メールゲートウェイは「テキスト分類器」として機能していた。AI 生成テキストはこの分類器をほぼ確実にすり抜ける。代わりに、攻撃者が偽装しにくい層——つまり「メールの外側」——に検証点を移す。

送信ドメインの認証 — DMARC を reject まで上げる

SPF・DKIM・DMARC は受信側で改ざん検知ができる仕組みで、文面がどれだけきれいでも送信元のインフラまで完全に偽装するのは難しい。問題は導入率ではなく運用の深さで、日本企業の多くは DMARC レコードを発行していても p=none（監視のみ）のまま放置している。

# 自社ドメインの DMARC 状態を確認
dig +short TXT _dmarc.example.co.jp
 
# 期待する出力（p=reject まで上げた状態）
"v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100"

p=none のままだと、受信側 ISP は「DMARC fail」のメールを通常配信する。p=quarantine で迷惑メールフォルダ送り、p=reject で受信拒否となる。段階的に上げていくのが定石で、none で 1〜2 か月分の DMARC レポート（rua）を集めて自社の正規送信経路（外部マーケティング配信、業務システム、社内メール）を全部洗い出してから quarantine、最終的に reject に上げる。reject まで持ち込めれば、自社ドメインを送信元に偽装したフィッシングは受信ボックスに届かなくなる。

着地先ドメインの監視 — 文面より URL を見る

AI が文面を担当しても、リンク先のドメインは攻撃者が用意する必要があり、ここに人間の判断を残せる余地がある。ただし「目視で確認しなさい」と言うだけでは仕組みにならないので、検知側で判定する。

これらのバリエーションを dnstwist で生成し、Certificate Transparency ログと新規登録ドメイン feed に毎日突き合わせると、攻撃者が偽サイトを公開する前後の段階で候補が浮かぶ。手の届く範囲では crt.sh の API + 自前の差分スクリプトで始められるが、月数十ドメイン以上の検知が必要なら自動化されたプラットフォームに任せたほうが TCO は下がる。実装の詳細は タイポスクワッティング検知の実務ガイド で扱った。

ビジュアル類似性 — ピクセル比較ではなく構造

フィッシングサイトは正規サイトのログイン画面を視覚的にコピーする。テキストは AI が書き換えても、レイアウト・カラースキーム・ロゴ位置はターゲットに似せないと意味がない。ここで効くのが構造的類似性スコア（SSIM）と、ロゴやフォーム要素の特徴抽出を組み合わせた判定だ。

ピクセル単位の完全一致比較は誤検知だらけになるが、SSIM は数 % のレイアウト変更を吸収しながら全体構造の類似度を測れる。さらに pHash（perceptual hash）を併用すると、攻撃者が画像の解像度や色味をいじっても 70〜80 % 以上の類似度を保ったまま検出できる。新規登録ドメインから拾った候補ドメインを定期的にスクリーンショットし、自社の正規ページと SSIM + pHash で比較する——この流れを 1 日 1 回回すだけで、ビジュアル偽装を量で捕まえられる。

URL の振る舞い検査

メール内 URL を受信時にリアルタイムで踏んで挙動を見る、いわゆる sandboxing 系の検知も有効性を保っている。チェック項目はシンプルで、リダイレクト回数、ドメイン年齢、SSL 証明書の発行元、ランディングページのフォーム有無の 4 つ。

正規 URL は通常 1〜2 回のリダイレクトで終わるが、フィッシングは検知回避のために 4〜5 回の経由を挟むことが多い。新規登録ドメイン（24 時間以内）+ Let's Encrypt の組み合わせは典型的な警告兆候で、ランディングページに認証情報を求めるフォームがあれば確度が一段上がる。これらを点数化してスコア閾値で判定するルールベースのシステムが、テンプレートマッチングより遥かに頑健に動く。

量で攻めてくる相手に量で守る

AI 生成フィッシングの厄介さは、文面の品質ではなく量にある。1 つのキャンペーンで数百種のメールが、1 日に数千件のドメイン登録が、1 ターゲットに対して数十経路（メール・SMS・LINE・Instagram DM・QR コード）から並行で来る。Bolster の 2026 年レポートでは 2025 年中に確認された悪意あるドメインが 1,190 万件、ピーク時の 1 日あたりアクティブが 37.8 万件——人手や個別ルールで追える数ではない。

ここから先は自動化前提の話になる。CT ログと NRD feed の 24 時間監視、新規候補ドメインの自動スクリーンショットとビジュアル比較、フィッシング判定後の registrar abuse 通報とブラウザブロックリスト並行提出、SMS や SNS 経由のチャネル横断監視——これらを手で並行運用するのはコスト的に成立しない。SaaS で自動化するか、専任内製チームを置くかの判断は、被害頻度と社内予算の関数になる。中堅企業の選び方は テイクダウンサービス比較 でまとめた。

訓練の方向も変える

技術側の話を進めながら、人側の訓練も従来の「変な日本語を見分けろ」から方向転換する必要がある。AI 生成メールは見た目で判断できない以上、訓練の軸は「メールの中身を見ない判断ルール」にずらす。

具体的には、送信元アドレスを必ずホバーして表示し、リンク先 URL を踏む前にホバーで確認する習慣を作る。緊急性を煽る文面（「至急」「本日中に」「アカウント停止」）は無条件で疑い、送信者本人に Slack か電話で別チャネル確認する文化を運用に組み込む。模擬フィッシングは年 1 回の集合研修ではなく、月 1〜2 回の不定期配信で実シナリオに近づける。

クリックしてしまった人を追加研修対象にするのは構わないが、人事評価には絶対に使わない——ここで罰則制にすると、ミスを報告しなくなり、結果として全体の検知ラインが下がる。「報告すれば称賛される」運用にすることで、実害発生前にセキュリティチームに情報が届く確率を上げる。

OpenBait の位置付け

OpenBait は CT ログと NRD feed の 24 時間監視、新規候補のビジュアル比較、フィッシング判定後の registrar abuse 通報と ブラウザブロックリスト 3 系統への並行提出を 1 つのワークスペースで運用できる中堅企業向けプラットフォーム。月額 $79 から、Business 以上で年契約・銀行振込・請求書払い対応。実装の判断材料として 無料枠 で自社ドメインに対して試せる。

関連記事

• 企業のフィッシング対策ガイド — 検知・テイクダウン・顧客防御
• タイポスクワッティング検知の実務ガイド
• テイクダウンサービス比較 — 内製・代行・SaaS
• フィッシング被害発見後 48 時間にやるべき 7 ステップ