HPにメアドを載せたらスパムが増えた件：複数クローラーとコピペ拡散を”前提”に守る方法

ホームページにメールアドレスを掲載したら、ある日突然スパムメールが激増した…。Web担当者なら一度は経験したことがあるのではないでしょうか。

この記事では、なぜメールアドレスを公開するとスパムが増えるのか、その「原因の正体」を技術的な観点から解き明かしながら、今すぐ実践できる具体的な対策を「レイヤー（層）」の考え方で整理してお伝えします。

「フォームにすれば解決？」「robots.txtでブロックすれば大丈夫？」といった疑問にも、根拠を持ってお答えします。

0. まず結論：公開Webに “生メアド” を置くと、拾われる確率が一気に上がる

ホームページに sample@mail.com のような 平文（プレーンテキスト）のメールアドレスを置くと、次のような流れでスパムの標的になりやすくなります。

1. メールアドレス収集ボット（harvester / scraper）に拾われる
   インターネット上を自動巡回し、@ や mailto: を目印にメールアドレスを収集する専用プログラムが存在します。
2. そのページが転載（コピペ）されると、別サイトにもメアドが増殖する
   悪質なスクレイパーは記事ごと丸コピーすることがあり、あなたのメアドも一緒に拡散されてしまいます。
3. 一度リスト化されると、消しても「しばらく」または「長期」続くことがある
   スパムリストは売買・共有されるため、元を断っても完全停止は難しいのが現実です。

ここで押さえておきたいポイントは、「クローラーは一種類じゃない」ということ。検索エンジンのクローラーだけでなく、目的の異なる複数の巡回者が同時にあなたのサイトを訪れています。

1. “複数のクローラー” が同時に来ている（ここが誤解されやすいポイント）

同じ「クローラー」「ボット」という言葉でも、中身はまったく異なります。これを理解することが、効果的な対策の第一歩です。

1-1. 検索エンジン系クローラー（Googlebot等）

目的：Webページを検索結果に表示するためのインデックス作成

Googlebotなどの検索エンジンクローラーは、あなたのサイトを検索結果に載せるために巡回しています。これ自体がスパムを送るわけではありません。

ただし、Googlebotがインデックスした情報は検索結果として公開されるため、悪性スクレイパーに発見される確率が上がるという間接的な影響があります。検索エンジンに載ること自体は悪いことではありませんが、「載る＝見つかりやすくなる」という点は認識しておく必要があります。

1-2. メールアドレス収集ボット（ハーベスター）

目的：Webページからメールアドレスの文字列を収集すること

これがスパムの元凶となるボットです。ハーベスター（harvester＝収穫者）という名前の通り、ページ内のテキストをスキャンし、メールアドレス形式の文字列を片っ端から収集します。

収集の手口はかなり洗練されています：

• @ マークを含む文字列を検出
• mailto: リンクを自動抽出
• [at] や [dot] といった置き換え表記も復元して収集
• HTMLソースだけでなく、JavaScriptで生成された表示も取得可能なものも存在

GitHubには「email-scraper」というタグで300以上のリポジトリが存在し、PythonやNode.jsで手軽にスクレイピングできるツールが公開されています。ScrapeBoxのような商用ツールは、プロキシ経由で大量巡回が可能で、User-Agentを偽装する機能まで備えています。

つまり、「生のメールアドレス」をHTMLに書くということは、専用ツールにとっては格好の標的を用意しているのと同じなのです。

1-3. スクレイパー（コピペ転載・自動コピー）

目的：記事を丸ごと転載して、集客や広告収入に利用すること

近年問題になっているのが、コンテンツを自動的にコピーして別サイトに掲載する「スクレイパー」の存在です。

厄介なのは、あなたがメアドを消しても、転載先に残っていれば拾われ続けるという点です。転載サイトは検索エンジンにインデックスされることもあり、そこからハーベスターがメアドを収集するという二次被害が発生します。

このように、「自分のサイトを直接守る」だけでは不十分で、拡散されることを前提とした設計が必要になってきます。

2. まずやるべき切り分け：原因が “収集” か “転載” か

スパム対策は、闘雲に施策を積み重ねるより、「どこから漏れたか」をざっくり把握する方が効率的です。

✅ チェック1：増え始めたタイミングは掲載直後か？

✅ チェック2：自分のメアドを検索してみる（転載チェック）

検索エンジンで "sample@mail.com" のように ダブルクオート（完全一致検索）で検索してみましょう。

転載先が検索結果に表示されることがあります。もし身に覚えのないサイトにあなたのメアドが載っていたら、転載による拡散が起きている可能性が高いです。

ただし、検索に出ない転載もあるため、出なかったから安心…とは言い切れません。

✅ チェック3：アクセスログの異常をざっくり確認

サーバーのアクセスログが確認できる環境であれば、以下のような異常がないか確認してみましょう。

• 1分間に数十〜数百リクエストの連続アクセス
• 不自然なUser-Agent（空欄、または古いブラウザバージョン）
• 同じIP帯からの連打（特に海外IPからの集中アクセス）

注意：User-Agentは簡単に偽装できます。「Googlebotを名乗っているから安心」という判断は危険です。Googlebotかどうかは、逆引きDNSで googlebot.com ドメインからのアクセスかを確認する方法が確実です。

ログが取れない環境なら、このステップはスキップして次章の「守り」を優先しましょう。

3. 対策は「1発」じゃなく”レイヤーで積む”のが勝ち筋

迷惑メール対策の鉄則は、「1つの施策が突破されることを前提に、複数の対策を重ねがけする」ことです。

セキュリティの世界では「多層防御（Defense in Depth）」と呼ばれるアプローチで、1つの層が破られても次の層で食い止める設計思想です。

ここからは、おすすめ順に対策レイヤーを紹介します。

レイヤーA：そもそも生メアドを出さない（最強の対策）

最も効果的なのは、根本的にメールアドレスを公開しないことです。これに勝る対策はありません。

推奨する構成

「メールで直接やりとりしたい」というニーズがあることは理解できます。しかし、公開Webは実質的に「世界中に公開された掲示板」です。

掲載する＝拾われる可能性がある、という前提で設計するのが現実的です。

レイヤーB：どうしても載せる場合の “見せ方” を工夫する

「どうしてもメールアドレスを掲載しなければならない」という場合は、以下の難読化テクニックを「やらないよりマシ」の補助的対策として検討してください。

ただし、単独では突破される可能性があるため、過信は禁物です。

B-1. Cloudflare Email Address Obfuscation（環境が許すなら手軽）

Cloudflareを利用しているサイトであれば、Scrape Shieldという機能で、メールアドレスの自動難読化が可能です。

仕組み：

• HTMLソース上のメールアドレスを、暗号化された文字列に自動変換
• ブラウザでページを表示するとJavaScriptがデコードして人間には普通に見える
• HTMLを直接スクレイピングするボットには [email protected] のような形式で表示される

設定方法：
Cloudflareダッシュボード → Scrape Shield → Email Address Obfuscation を「On」に設定

Cloudflareの公式ドキュメントによると、この機能は help [at] example.com のような表記や画像化に比べて、クリック可能なリンクを維持しながら難読化できる点がメリットとされています。

実際にCloudflareコミュニティでも「Scrape Shield有効化後もスパムが来た」という報告があり、「洗練されたボットはバイパスできる可能性がある」とCloudflare自身も認めています。これは万能ではなく、あくまで防御レイヤーの1つという位置づけで使いましょう。

B-2. help [at] example [dot] com 表記（古典だけど今も一定の効果あり）

最も古典的な方法ですが、今でも一定の効果があります。

お問い合わせ：sample [at] mail [dot] com

メリット：

• 実装が簡単（HTMLを書き換えるだけ）
• JavaScriptが無効な環境でも表示できる

デメリット：

• 最近のスクレイパーはこの表記を正規表現で復元できるものが増えている
• ユーザーがコピペしづらい

単独対策にはしないのが無難です。他の対策と組み合わせて使いましょう。

B-3. CSSで @ を後付けする方法（HTMLに@を書かない）

HTMLソースに @ マークを直接書かないことで、単純な文字列検索ボットを回避する手法です。

実装例

HTML：

<span class="email">
  <span class="user">sample</span><span class="domain">mail.com</span>
</span>

CSS：

.email .domain::before {
  content: '@';
}

ブラウザでの表示：sample@mail.com
HTMLソース上：sample と mail.com が分離、@ はCSSで後付け

実務上の注意点（重要）

この方法にも限界があります。

1. CSS無効の環境では samplemail.com と表示される
   アクセシビリティの観点で問題がある
2. レンダリング後のDOMを取得するタイプのスクレイパーには無力
   Puppeteer、Selenium、Playwrightなどのヘッドレスブラウザを使ったスクレイピングでは、CSSが適用された後の状態を取得できる
3. 転載先でHTMLが整形されると、結局 @ 付きで再構成されることがある

この手法も「確率を下げる」補助輪として使い、主戦力はフォーム導線に置くのがおすすめです。

B-4. 「リンクにしない」という選択肢

mailto: リンクは特に収集されやすいため、どうしてもメアドを載せるならクリック不可のテキストにするという割り切りもあります。

非推奨（mailto: は格好の標的）：

<a href="mailto:sample@mail.com">sample@mail.com</a>

代替案（テキストのみ）：

<p>お問い合わせ：sample@mail.com（コピーしてご利用ください）</p>

UX（ユーザー体験）は下がりますが、収集コストを上げる効果はあります。

レイヤーC：問い合わせフォームを “スパム耐性フォーム” にする

メールアドレスを隠すと、次に攻撃されるのがフォームそのものです。

フォームスパムは、自動プログラムがフォームに大量の送信を行う攻撃で、最初から防具を着せておくことが重要です。

C-1. Honeypot（ハニーポット）

仕組み：
人間には見えない（CSSで非表示にした）入力欄を用意し、そこに値が入力されていたらボットと判定する手法です。

ボットはHTMLを解析して全フォーム項目を埋めようとするため、「人間は入力しないはずの隠しフィールド」に値が入っていればボットだと判断できます。

WordPressでの実装例（Contact Form 7）：

プラグイン Honeypot for Contact Form 7 をインストールし、フォームに [honeypot your-name] のようなタグを追加するだけです。

メリット：

• ユーザーに負担をかけない（見えないので）
• 実装が簡単

デメリット：

• 高度なボットはHoneypotの存在を検知して回避することがある

C-2. CAPTCHA / Turnstile

CAPTCHA（キャプチャ）は、「あなたは人間ですか？」を確認する認証システムです。

Google reCAPTCHA

長年の定番ですが、2024年後半から無料枠が月間10,000件に縮小されました。大規模サイトでは従量課金が発生する可能性があります。

Cloudflare Turnstile（おすすめ）

Cloudflareが提供する無料のCAPTCHA代替サービスです。

特徴：

• 完全無料（回数制限なし）
• ユーザーに画像選択やパズル解答を求めない「ゼロフリクション」認証
• バックグラウンドで自動的に人間かどうかを判定
• プライバシー重視（広告リターゲティング用のデータ収集なし）

Contact Form 7はTurnstileに公式対応しており、マニュアルでも「reCAPTCHAを使うべき理由が特にないのであれば、Turnstileを選択してください」と案内されています。

設定方法（WordPress + Contact Form 7）：

1. Cloudflareでアカウント作成（無料）
2. ダッシュボード → Turnstile → ウィジェットを作成
3. サイトキーとシークレットキーを取得
4. WordPress管理画面 → お問い合わせ → インテグレーション → Turnstile を設定
5. フォームに [turnstile] タグを追加

C-3. レート制限（送信回数制限）

同一IPアドレス/User-Agentからの短時間連投を制限する仕組みです。

実装方法：

• CloudflareなどのCDN/WAFレベルで設定するのが効果的
• WordPressプラグインでも実現可能（例：WPブルートフォース対策系プラグイン）

設定例：
「同一IPから5分間に3回以上のフォーム送信があった場合、一時的にブロック」

レイヤーD：コピペ転載（スクレイピング）対策は “割り切り” が大事

正直なところ、コピー対策の「完全防止」は技術的に非常に困難です。

HTMLをリクエストすれば取得できてしまうのがWebの仕組みである以上、スクレイピング自体を完全に止めることはできません。

D-1. 取られても被害が小さい構造にする

これが最も現実的なアプローチです。

D-2. 取るコストを上げる（WAF / Bot対策）

完全防止は無理でも、「コストを上げる」ことで攻撃者を諦めさせる戦略は有効です。

具体的な対策：

• 異常なアクセスパターン（連続アクセス、深夜帯の大量リクエストなど）をWAFでブロック
• 不審なIP帯（既知のデータセンター、VPN出口など）をレート制限
• リクエストパスやクエリパラメータの不自然なパターンをフィルタ

D-3. robots.txtは “善良なボット向けのお願い” と割り切る

robots.txtは便利ですが、悪性ボットが守る保証はありません。

# 連絡先ページをクローラーから除外する設定例
User-agent: *
Disallow: /contact/

この設定は「Googlebotなどの行儀の良いクローラー」には有効ですが、メール収集ボットは無視して巡回することがあります。

さらに注意点として、robots.txtでブロックしても、外部サイトからリンクがあるとURLだけがGoogleにインデックスされる可能性があります（コンテンツは非表示でもURLは残る）。

D-4. 必要なら “noindex” を使う

検索結果に出したくないページには、noindex メタタグを設定する選択肢もあります。

<head>
  <meta name="robots" content="noindex">
</head>

使いどころの例：

• 連絡先ページ（検索流入が不要な場合）
• 会員専用ページ
• 社内向け情報ページ

ただし、本当に検索から消したいのかはSEO・導線の観点でしっかり検討してください。

レイヤーE：メールそのものを固める（SPF / DKIM / DMARC）

ここは誤解が多いポイントなので、丁寧に説明します。

よくある誤解

❌ 「SPF/DKIM/DMARCを設定すれば、受信スパムが減る」

これは半分正解、半分間違いです。

正確には：

• ✅ あなたのドメインを騙る「なりすましメール」は減らせる
• ❌ あなたが受信するスパム全体を減らす魔法ではない

なぜ重要なのか

HPにメアドを載せた → 収集された → 次に来るのが「なりすまし」という流れがあります。

攻撃者があなたのドメイン @example.com を詐称して、取引先や顧客にフィッシングメールを送信するリスクがあるのです。SPF/DKIM/DMARCは、これを防ぐための重要な技術です。

2024年の大きな変化：Gmail送信者ガイドラインの厳格化

2024年2月以降、Googleは送信ドメイン認証を義務化しました。

対応していない場合、Gmailにメールが届かなくなる（迷惑メール判定または受信拒否）可能性があります。

これはGoogleだけでなく、Yahoo!やMicrosoftも同様の方向で対応を進めています。

各技術の役割

DMARCポリシーの段階的な強化（推奨手順）

いきなり厳格なポリシーにすると、正規のメールまで拒否されるリスクがあります。段階を踏むのが安全です。

ステップ1：監視モード（p=none）

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

→ 認証失敗しても何もしない。レポートで現状を把握する

ステップ2：隔離モード（p=quarantine）

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com

→ 認証失敗したメールは迷惑メールフォルダへ

ステップ3：拒否モード（p=reject）

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

→ 認証失敗したメールは受信拒否（最強）

4. すぐ使える「運用レシピ」

状況別に、おすすめの対策セットをまとめました。

レシピ1：個人サイト/ポートフォリオ（被害最小化優先）

• ☑ 生メアドは載せない（フォーム一本化）
• ☑ フォーム：Honeypot + Turnstile
• ☑ どうしても載せるなら：CSS @後付け or [at][dot]表記を”補助”で
• ☑ 受信用アドレスは専用化（捨てやすいもの）

レシピ2：事業サイト（問い合わせが売上に直結）

• ☑ フォームを主導線に（自動返信＋必須項目の最適化）
• ☑ WAF/CDNでレート制限（Cloudflare無料プランでも可）
• ☑ SPF/DKIM/DMARCを整備（なりすまし対策）
• ☑ フォームにはTurnstile + Honeypotの二重対策

レシピ3：WordPressで現実的に固める

• ☑ Contact Form 7 または WPForms でフォーム作成
• ☑ Honeypot for Contact Form 7 をインストール
• ☑ Cloudflare Turnstile を設定
• ☑ 可能ならCloudflareの Email Obfuscation を併用（補助輪）
• ☑ SPF/DKIMはサーバー設定で（多くのレンタルサーバーは対応済み）

5. FAQ：よくある質問と回答

Q1. メアドをページから消したらスパムは止まりますか？

減ることはありますが、完全停止は難しいです。

一度スパムリストに載ると、そのリストは売買・共有されて拡散します。また、転載サイトに残っている場合は、そこから継続的に収集される可能性があります。

根本対策は「今後増やさない構造（フォーム中心）」を作ることです。

Q2. robots.txtで連絡先ページをDisallowすればOKですか？

善良なクローラーには効きますが、悪性スクレイパーは無視することがあります。

また、robots.txtでブロックしても、外部サイトからリンクされているとURLだけがGoogleにインデックスされる可能性があります（内容は表示されないがURLは残る）。

本当に検索に出したくないなら noindex メタタグを使いましょう。

Q3. 右クリック禁止やコピー禁止JSで守れますか？

ほぼ意味がありません。

スクレイピングはブラウザを使わず、直接HTTPリクエストでHTMLを取得します。JavaScriptで右クリックを禁止しても、HTMLソースは普通に取得できます。

「取られても困らない設計」と「取るコストを上げる」が現実的な対策です。

Q4. DMARCを入れれば迷惑メールが減りますか？

「あなたのドメインのなりすまし」は減らせます。

ただし、あなたが受信するスパム全体をゼロにする仕組みではありません。受信側のスパムフィルタと、送信側のドメイン認証は別の話です。

Q5. Cloudflare Turnstileは本当に無料ですか？

はい、完全無料で回数制限もありません（2025年1月時点）。

Google reCAPTCHAは月間10,000件を超えると有料になりますが、Turnstileにはその制限がありません。Contact Form 7の公式マニュアルでも推奨されています。

Q6. SPF/DKIM/DMARCは難しそうですが、自分で設定できますか？

多くのレンタルサーバーでは管理画面から簡単に設定できます。

Xserver、ConoHa WING、お名前.comレンタルサーバーなど、主要なサービスではSPF/DKIMは標準または簡単設定で対応しています。DMARCは手動でDNSレコードを追加する必要がありますが、1行のTXTレコードを追加するだけです。

6. まとめ：勝ち筋は「出さない」＋「フォーム防御」＋「メール認証」

この記事で解説した対策をまとめると、以下の3層構造になります。

最強の防御：そもそも出さない

• 公開Webに生メアドは置かない
• 問い合わせ導線はフォーム中心に設計
• どうしても載せるなら、難読化は”補助輪”として（CSS @後付けなど）

フォームを固める

• Honeypot + Turnstile（または reCAPTCHA）
• レート制限で連投を防止
• WAF/CDN連携で異常アクセスをブロック

メール認証で信頼性を確保

• SPF/DKIM/DMARCを設定
• DMARCはp=none→quarantine→rejectと段階的に強化
• レポートを活用してなりすましを監視

どれか1つではなく、重ねがけ（レイヤー構造）が効くというのがこの記事の主旨です。

スパム対策は「やったら終わり」ではなく、定期的な見直しが必要です。新しい手口が出てきたら対策も更新していきましょう。

参考資料（公式ドキュメント中心）

以下は執筆の参考にした一次情報・公式ドキュメントです。

Cloudflare関連

• Email Address Obfuscation（Cloudflare公式）
• Cloudflare Turnstile（公式）
• Turnstile ドキュメント

Google関連

• メール送信者のガイドライン（Google Workspace）
• robots.txt 入門（Google Search Central）
• noindex によるインデックス登録のブロック

メール認証関連

• Email authentication（Microsoft Learn）
• DMARC.org Overview

WordPress関連

• Contact Form 7 Honeypot（WordPress.org）
• Contact Form 7 Turnstile Integration

この記事は2026年1月時点の情報に基づいて執筆しています。各サービスの仕様は変更される可能性がありますので、最新情報は公式ドキュメントをご確認ください。