InfoQ が Artificial Intelligence-Driven Phishing: How Phishing Technique Is Evolving and Implemented（2026-06-08）で、フィッシングが AI によって「手作業の標的型」から「自動化・スケール化された攻撃モデル」へ変質していることを取り上げました。偵察（ターゲットの収集）・なりすまし生成（メール文面や偽サイトの作成）・配信（大量送信）・回避（検知をすり抜ける）というフィッシングのライフサイクルの各段階が AI で高度化し、「精巧ななりすましを、大量に、低コストで」送れる時代になりつつあります。従来は不自然な日本語や粗い偽サイトで見抜けた攻撃が、見分けにくく、数も桁違いに増えていく――これが現場の前提になりました。
受託システム開発・セキュリティの現場では、「メールセキュリティ製品を 1 つ導入して終わり」「DMARC を設定しただけで安心」という事故が繰り返されてきました。受託で顧客を支える立場では、これは 「ツールを入れるか」ではなく、「送信ドメイン認証・なりすまし検知・認証強化・従業員演習・インシデント対応を、組織として運用できる耐性として引き渡せるか」を設計に組み込む課題だと捉えています。これまで Webセキュリティ基礎（GH Media） で扱った 守るべき基本、セキュリティ・バイ・デザイン（GH Media） で扱った 「最初から守りを織り込む」発想と接続して、本記事では 「フィッシング対策（メール認証・なりすまし耐性）実装支援」を 受託パッケージとして整理します。なお本記事は防御側の提供内容に徹し、攻撃手法の手順は一切扱いません。
なぜ「いま」フィッシング対策を作り直すのか
| 観点 | 従来型フィッシング | AI駆動フィッシング（2026） |
|---|---|---|
| 偵察 | 攻撃者が手作業で標的を調査 | 公開情報を自動収集・プロファイル化 |
| なりすまし精度 | 不自然な文面・粗い偽サイト | 自然な文面・精巧な偽サイトを自動生成 |
| 配信量 | 標的を絞った少量送信 | 大量・連続・多言語に展開 |
| 検知回避 | パターンで弾けることも多い | 文面を変化させ既存フィルタをすり抜け |
| コスト | 人手がかかる | 自動化で限界費用が下がる |
| 防御の前提 | 「気づける」前提が成り立つ | 人の目だけに頼れない |
つまり 「製品を 1 つ入れる」ことと「組織としてフィッシング耐性を保つ」ことは別物であり、受託でも 「送信ドメイン認証を段階導入し、なりすましを検知・報告し、認証を強化し、人を演習で鍛える」ことが品質の前提になりました。これにより 「技術＋運用＋演習の多層防御」を成果物として保証できます。
受託で実装する多層防御の柱
① 送信ドメイン認証（SPF / DKIM / DMARC・BIMI）
SPF は「どのサーバが自社ドメインのメールを送ってよいか」を、DKIM は「メールが改ざんされていないか・正規の署名があるか」を、DMARC は「SPF / DKIM に失敗したメールをどう扱うか（受信側にどう指示するか）」を宣言する仕組みです。DMARC のポリシーには p=none（監視のみ・拒否しない）／ p=quarantine（迷惑メール扱い）／ p=reject（受信拒否）の三段階があり、いきなり reject にすると正規メールまで落ちるため、none でレポートを集めて送信実態を把握してから段階的に引き上げます。BIMI は DMARC が quarantine 以上で運用されていることを前提に、認証済みメールに自社ロゴを表示してなりすましとの差を可視化する仕組みです。
; DMARC レコード例（まずは監視から始める段階）
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1; adkim=s; aspf=s"rua に集約レポートの送信先を指定し、送信実態を可視化したうえで p=none → quarantine → reject へ引き上げるのが定石です。
② なりすまし・偽サイトの検知と報告
DMARC の集約レポートで 自社ドメインを騙る送信を継続監視し、偽サイト（フィッシングサイト）の出現を検知したら テイクダウン（停止申請）に動ける窓口と手順を用意します。あわせて、従業員が「怪しいメール」を 1 クリックで報告できる経路（報告ボタン・専用窓口）を整備し、検知した情報を防御側に還流させます。検知しても報告フローがなければ対応が始まりません。
③ Web・認証側のなりすまし耐性（パスキー等）
正規ドメインを徹底し（紛らわしいドメインを増やさない・正規 URL を周知する）、ログインや重要操作の認証を強化します。パスワード単独はフィッシングで奪われやすいため、フィッシング耐性のある パスキー（GH Media） などのパスワードレス認証への移行を設計します。フォームや問い合わせ導線では、添付・リンクの扱い方針を定め、正規サイトと偽サイトを利用者が見分けられる状態を保ちます。
④ 従業員向け演習と教育
技術対策をすり抜けたメールに最後に対峙するのは人です。定期的なフィッシング演習（訓練）と教育で「報告する」行動を習慣化し、演習結果（クリック率・報告率）を指標として運用に組み込みます。叱責のための訓練ではなく、報告文化を育てる訓練として設計します。
受託で提供する「フィッシング対策（メール認証・なりすまし耐性）実装支援」5フェーズ
フェーズ 1: 診断（1〜2 週間）
- 送信ドメインの棚卸し・SPF / DKIM / DMARC の現状確認
- なりすまし・偽サイトの監視状況、報告フローの有無の確認
- 認証方式（パスワード / 多要素 / パスキー）と演習の実施状況の確認
- 成果物: フィッシング耐性診断レポート + 優先度付き改善計画
フェーズ 2: 設計（1〜2 週間）
- DMARC 段階導入のロードマップ（
none→quarantine→reject）策定 - なりすまし検知・報告・テイクダウンの運用フロー設計
- 認証強化（パスキー等）・添付/リンク方針の設計
- 成果物: 多層防御設計書 + DMARC 移行計画書
フェーズ 3: 実装（2〜4 週間）
- SPF の整理（後述の 10 ルックアップ対策）・DKIM 署名の整備
- DMARC を
p=noneで導入し集約レポート受信基盤を構築 - 報告ボタン / 窓口・偽サイト検知の通知経路の実装
- 認証強化・演習基盤の準備
- 成果物: 実装済み設定 + 運用手順書
フェーズ 4: 検証・引き渡し（1〜2 週間）
- レポートで送信実態を検証し
quarantine→rejectへの引き上げ可否を判断 - 正規メールが落ちないことを確認したうえでポリシーを引き上げ
- インシデント対応手順の引き渡し・演習の初回実施
- 成果物: 検証レポート + インシデント対応手順書 + 演習結果
フェーズ 5: 継続運用（継続）
- DMARC レポートの定点監視・なりすまし送信の追跡
- 偽サイト検知時のテイクダウン支援
- 定期演習の実施と指標（クリック率 / 報告率）の改善
受託向け対策標準セット
| 領域 | 推奨 | 避ける |
|---|---|---|
| 送信ドメイン認証 | SPF / DKIM / DMARC を揃える | DMARC 未設定 / p=none 放置 |
| DMARC 移行 | none → quarantine → reject の段階導入 | いきなり p=reject |
| SPF | 10 ルックアップ以内に整理 | include の無秩序な追加 |
| なりすまし可視化 | DMARC 運用＋ BIMI | 監視なしの放置 |
| 認証 | パスキー等のフィッシング耐性認証 | パスワード単独 |
| 人の対策 | 定期演習＋報告フロー | 教育のみ / 報告経路なし |
どの組織に必要か / 優先度が低いか
| 必要な組織 | 優先度が低い組織 |
|---|---|
| 自社ドメインでメールを多く送る | メール送信がほぼない |
| 取引先・顧客とメールでやり取りする | 外部接点が限定的 |
| ブランドを騙られるリスクがある | 知名度・標的性が低い |
| ログイン・決済など重要操作を扱う | 認証を要する機能がない |
| 過去になりすまし被害・ヒヤリがある | 既存の運用で問題が出ていない |
受託契約に書く6つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 対象範囲 | 対象ドメイン / システムの範囲 | 子会社・別ドメインの扱い |
| DMARC 移行 | 段階導入の進め方と判断基準 | reject 到達の目標時期 |
| 正規メール影響 | 段階導入で落とさない保証 | 送信元の事前棚卸し |
| 検知・報告 | なりすまし検知と報告フロー | 一次対応の責任分界 |
| インシデント対応 | 偽サイト検知時の手順 | テイクダウンの支援範囲 |
| 継続運用 | レポート監視・演習の頻度 | 運用費用と指標 |
価格モデル — フィッシング対策実装パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 診断 | 25 万円〜 | 1 組織 | 現状診断 + 改善計画 |
| 標準実装 | 90 万円〜 | 中規模 | SPF/DKIM/DMARC 整備 + 報告フロー |
| 本格実装 | 180 万円〜 | 大規模 | + reject 到達 + 認証強化 + 演習基盤 |
| Lite 保守 | 4 万円〜 / 月 | 小規模 | レポート監視 + 軽微修正 |
| Standard 保守 | 12 万円〜 / 月 | 中規模 | + テイクダウン支援 + 定期演習運用 |
顧客側 ROI 試算（メールを多く送る組織想定）
| 項目 | 対策前 | 対策後 | 差分 |
|---|---|---|---|
| なりすまし送信 | 自社ドメインを騙られる | reject で停止 | ブランド毀損リスクの低減 |
| 被害リスク | 従業員・顧客がだまされる | 多層防御で大幅減 | 被害・対応コストの圧縮 |
| メール到達率 | 認証不備で迷惑扱いも | 認証整備で改善 | 正規メールの到達率向上 |
| 人の対応 | 気づけず通報されない | 報告文化が定着 | 早期検知・初動の高速化 |
| 年間効果 | — | — | なりすまし停止 + 被害低減 + 到達改善 |
診断（25 万円〜）だけでも、「いまの送信ドメインが、どれだけなりすましに晒されているか」を DMARC レポートで可視化できること自体に価値があります。なりすまし送信は、たいてい気づかないうちにブランドと顧客の信頼をじわじわ削っていきます。
ハマりやすい5つの落とし穴
落とし穴 1: DMARC を p=none のまま放置する
レポートは集めても拒否ポリシーに上げないと、なりすましは止まりません。quarantine → reject への引き上げを計画に組み込みます。
落とし穴 2: SPF の 10 ルックアップを超える
SPF は DNS ルックアップが 10 回を超えると評価が失敗します。include を整理し、上限内に収めます。
落とし穴 3: いきなり p=reject にして正規メールが落ちる
送信元を棚卸しせずに拒否ポリシーへ上げると、業務メールや外部配信サービスのメールが届かなくなります。レポートで実態を把握してから段階的に上げます。
落とし穴 4: 演習だけで技術対策が無い
教育や訓練をしても、送信ドメイン認証や認証強化が無ければ守りは穴だらけです。技術と人の対策を両輪で設計します。
落とし穴 5: 報告フローが無く検知が活きない
従業員が怪しいメールに気づいても、報告経路が無ければ防御側に情報が届きません。1 クリックで報告できる経路を先に整えます。
90日アクションプラン
| 週 | アクション |
|---|---|
| Week 1〜2 | 送信ドメイン棚卸し + SPF/DKIM/DMARC の現状診断 |
| Week 3〜4 | DMARC を p=none で導入 + 集約レポート受信開始 |
| Week 5〜7 | SPF 整理（10 ルックアップ内）・DKIM 整備・報告フロー構築 |
| Week 8〜9 | レポート検証 + p=quarantine へ引き上げ |
| Week 10〜11 | 認証強化（パスキー等）の設計・演習の初回実施 |
| Week 12〜13 | 正規メール影響を確認し p=reject へ到達 + 手順整備 |
まとめ — 「製品を入れる」から「耐性を引き渡す」へ
AI によってフィッシングが自動化・スケール化された以上、防御も「製品を 1 つ入れる」から「送信ドメイン認証・なりすまし検知・認証強化・演習・インシデント対応を組織の耐性として運用する」へと進めるべき局面です。受託でセキュリティを支える立場では、SPF/DKIM/DMARC を段階導入し、なりすましを検知・報告し、認証を強化し、人を演習で鍛えて引き渡す 「フィッシング対策（メール認証・なりすまし耐性）実装支援」が、技術と運用を両輪にした成果物を届ける主力サービスです。社内のセキュリティ運用や検知の自動化まで含めて見直すなら SecOps の MCP 連携（GH Media） を併読してください。
弊社では診断 / 標準実装 / 本格実装 / Lite / Standard の各段階で本パッケージを提供しています。「自社ドメインのなりすましを止めたい」「DMARC を reject まで安全に上げたい」「従業員のフィッシング耐性を鍛えたい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
