【2026年版】お問い合わせフォームからの迷惑メール対策・スパム対策

皆さんこんにちは。
taneCREATIVEの「ちほうタイガー」です。

この記事は、お問い合わせフォームからの迷惑メール対策・スパム対策に関するもので、2026年1月6日に改訂しています。

Webサイトには、お問い合わせフォームはあって当然の機能となっていますが、お問い合わせフォームからの迷惑メール、スパムメールが年々増えていると感じています。

そして、当社が保守を担当させていただいている企業のご担当者より、何とかしてほしいという相談をよく頂きます。

そこで、本記事では、企業のWebサイト担当の皆様に向けて、Web制作会社である当社の観点から、お問い合わせフォームからの迷惑メール対策・スパム対策について解説してみようと思います。

メールを専門とする企業ではなく、あくまでセキュリティ対策と技術力に多少強みを有するWeb制作会社に過ぎない当社の認識ということで、ご容赦いただけますと幸いです。

少しでも皆様のお役に立てる記事にできればと思います。
どうぞよろしくお願い致します。

近年の迷惑メール・スパムメールは、送信者情報（From表示）やドメインを詐称して正規の企業・組織を装う「なりすましメール」や、特定の個人・組織を狙って内容を作り込む「標的型攻撃メール」などにより巧妙化しています。こうした手口は情報窃取やマルウェア感染、金銭被害につながり得るため、個人・組織を問わず継続的な対策が重要です。

迷惑メール・スパムメールを放置するリスクは次の通りです。

カスタマーサポートやお問い合わせフォーム宛てのメールに大量の迷惑メール・スパムメールが混入すると、本来対応すべき正規ユーザーからのお問い合わせを見落とすリスクが高まります。
特に特定の組織や部署を狙った「標的型メール攻撃」を受けた場合、短時間に大量のメールが送信されることがあり、顧客対応の遅延や品質低下を招き、結果として顧客体験やブランドイメージの悪化につながる恐れがあります。

迷惑メールの確認・仕分け・削除といった対応に時間を取られることで、担当者の業務負荷が増大し、本来の業務効率が低下します。
特に送信元や件名を巧妙に偽装した「なりすましメール」が増加すると、正規メールとの判別が困難となり、対応に多くの工数を要する原因となります。

フィッシング詐欺の典型例は、正規の企業や金融機関などを装ったメールを送信し、メール本文内に設置したリンクから偽ページや改ざんした本物のページへと誘導して、受信者が入力したパスワード・クレジットカード情報・個人情報などを盗み取るというものです。
個人情報の盗難被害はもとより、クレジットカード番号や口座情報を抜き取られると不正利用や不正送金につながる可能性がある他、パスワードなどのセキュリティ情報が盗まれると、社内ネットワークやオンラインサービスへの不正侵入を許してしまう恐れもあります。

迷惑メール・スパムメールには、悪意のあるリンクを通じてマルウェアをダウンロードさせる手法や、添付ファイル（ZIP、PDF、Word、Excel など）を開かせてマルウェアを実行させる手法があります。
感染すると、データの暗号化による業務停止（ランサムウェア被害）や、機密情報・個人情報の外部流出など、組織にとって深刻な被害へ発展する恐れがあります。

お問い合わせフォームから送信される迷惑メール・スパムメールに対しては、次の手法を組み合わせて対策をすること（多層防御）をお勧めいたします。

CAPTCHA（Completely Automated Public Turing test to tell Computers and Humans Apart）は、アクセス主体が人間か自動プログラム（Bot）かを判別するための自動化されたテスト手法を意味します。

具体的には、以下のような形で利用されます（GoogleのreCAPTCHAを例にします）。

数年前までは、CAPTCHAと言えばGoogleのreCAPTCHA一択でしたが、提供形態が Google Cloud に統合され、無料枠が縮小・従量課金制の料金体系へ移行しているため、一定以上のトラフィックでは有料となるケースが発生しています。
そのため、最近では、無料で使えるCloudflareが提供するTurnstileも広く利用され始めています。

一方で、AIを利用してCAPTCHAを突破しようとする動きも活発化しているため、honeypot、レートリミット、WAF、Bot挙動分析などの他の迷惑メール対策・スパムメール対策との併用が必要になってきています。

honeypot（ハニーポット）とは、ユーザーには表示されないダミーのフォームフィールド（隠しフィールド）を設置し、サーバー側のフォーム処理において当該フィールドに値が入力されているかどうかを検査することで、Botによる自動投稿を判別する手法です。

通常のユーザーは、ダミーフィールドが画面上に表示されない、または操作対象とならないため、正しくフォームを入力してもこの項目に値が入ることはありません。
一方で、スパムボットはフォーム内の全入力項目を機械的に埋めて送信する傾向があるため、ダミーフィールドにも値を入力してしまうという特性を利用して検出します。

実装が比較的容易で、ユーザー体験を損ねにくいというメリットがありますが、honeypotの仕組みは広く知られているため、非表示フィールドを意図的に無視する高度なBotには効果が限定的となる場合があります。そのため、単独での利用ではなく、CAPTCHAやレートリミット、WAFなど、他の迷惑メール・スパムメール対策との併用が前提となります。

なお、一部のアクセシビリティ支援ツールやブラウザの自動入力機能、拡張機能などが、非表示フィールドに誤って値を補完してしまうケースがあり、その結果、正規ユーザーの送信がブロックされる可能性があるため、実装方法には注意が必要です。

過剰送信ブロックとは、一定時間内に一定回数以上の送信が行われた場合に、その送信を制限または遮断する仕組みであり、レートリミットや投稿回数制限とも呼ばれます。

手法としては、IPアドレスごとに送信回数のカウントし、上限回数（例えば5回/分など）を超えた場合に、そのIPアドレスからのアクセスを一定時間ブロックするというものや、クッキーやセッションを利用することで、同じブラウザセッションからの送信回数をカウントし、短時間での過剰送信をブロックするなどの手法があります（ただし、IPアドレス単位の制御と比べると、匿名モードやCookie削除などで回避される確率が高いと思います）。

また、一部のWAF（Web Application Firewall）やクラウド型セキュリティサービスにはレートリミット機能が搭載されており、攻撃の種類や規模に合わせてブロックルールをチューニングできたりします。

一方で、過剰送信ブロックの設定を厳しくしすぎると、本来は正当なリクエストが弾かれてしまう確率が高まります。例えば、IPアドレスごとの上限回数を少なくしすぎると、複数人が同じグローバルIPアドレスを共有してアクセスしてくるケース（企業や公共施設など）で弾かれてしまうというようなことが起こりえます。

このため、過剰送信ブロック機能を実装する場合、テスト環境で想定シナリオをしっかり検証してから本番導入を行う必要があります。

多くのスパムbotはJavaScriptを実行しない、または限定的にしか実行しないという特徴を利用して、不正投稿を見分ける対処法です。
一般的には次の３つの方法があります。

①　JavaScriptでトークンを生成し、サーバー側で検証する方法

ユーザーがフォームページを開いた段階で、JavaScriptを使って有効期限を設けた「トークン」を生成し、送信時にトークンが正しい場合のみ受付を許可するよう、サーバー側でチェックを行う手法です。
スパムボットはフォームページのHTMLやJavaScriptを無視し、直接POSTリクエストだけを送ることが多いため、トークンが生成されない（あるいは正しいトークンを入手できない）まま送信されたものを、サーバー側で「不正な投稿」と判断します。

一方で、高度なボットやヘッドレスブラウザ（JavaScriptを実行できる仕組み）を使う攻撃者には突破される可能性があること、ユーザーがJavaScriptをオフにしている場合はフォームを使えないことがあること（最近では少数だと思いますが…）などのデメリットも理解した上で、使用する必要があります。

②　ページ表示後に動的にフォーム要素を組み立てる方法

フォーム要素を初期状態では設置せず、HTML上では最低限の要素のみ表示しておき、メールアドレス欄などの実際のフォーム要素をJavaScriptで動的に生成することで、JavaScriptを実行しない（または実行できない）ボットが正しいフォーム構造を取得できないようにする手法です。
もしボットが無理やりPOSTしてきたとしても、サーバー側で「必須フィールドが存在しない」と判断して弾くなどの対応が可能です。

一方で、JavaScript依存度が高く、ユーザー側でJavaScriptが無効化されている場合は正常にフォームが使えない可能性があること、大規模サイトでは動的生成の仕組みが複雑になりやすく、メンテナンスが煩雑になる可能性があること、などのデメリットも理解した上で使用する必要があります。

③　JavaScriptによるタイミングや行動解析による方法

JavaScriptでページ読み込みから送信ボタンが押されるまでの時間・キー入力速度などを計測し、一定基準に満たない場合（例えば「ページを開いて1秒以内にフォーム送信された場合は人間ではあり得ない」など）はスパムと判定する手法や、ユーザーがどのフォーム項目にフォーカスしたか、マウス移動を行ったかなどをチェックし、「人間らしい」挙動かを判断する手法などです（これに近い仕組みがGoogleのreCAPTCHA v3に実装されています）。

一方で、実装がやや複雑で、誤判定も起きやすいこと、ヘッドレスブラウザ+スクリプトである程度の操作をエミュレートするボットには通用しない場合があること、などのデメリットも理解した上で使用する必要があります。

特定のIPアドレスや送信元ドメインが頻繁に悪意ある投稿を行う場合に、ブラックリスト登録によってアクセスや投稿を遮断する対処法です。
比較的即効性がある一方、回避されやすい側面もあるため、他の対策と併用することが前提となります。
一般的には次の4つの方法があります。

①　個別ブラックリストを作成し遮断する方法

攻撃やスパム投稿を検知するたびに、問題のあるIPアドレスや送信元ドメインを手動でブラックリストに登録して遮断する方法です。

通常はWebサーバー（nginx / Apache）やファイアウォールレベルで特定のIPアドレスをブロックしていきます。
アプリケーションに到達する前に遮断できるため、セキュリティ面・サーバー負荷の両面でメリットはありますが、ブラックリストへの追加・管理は通常手動で行うため運用コストの課題はあります。

一方で、WordPressなどのCMSでは、管理画面でスパム元のIPアドレスや送信元ドメインを拒否設定できるプラグイン（Wordfence SecurityやAll-In-One Security）があります。
IPリストの管理・更新がWordPressの管理画面から容易にできるため手動での追加工数を若干削減できる一方で、悪意のあるメールがPHPレイヤーまで到達してしまう上に、サーバーリソースを多少消費してしまうというデメリットもあります。

なお、IPv6環境ではIPアドレスが頻繁に変わるケースも多く、IP単体での遮断では効果が限定的となる場合があります。そのため、状況によってはサブネットやAS単位での制御が検討されることもあります。

②　外部ブラックリスト（Web投稿向けRBL）を活用し遮断する方法

外部サービスが提供するブラックリストを参照し、既知のスパム送信元IPアドレスやホストからの投稿を遮断する方法です。
Stop Forum Spam など、Webフォーム投稿向けに特化したブラックリストが代表例として挙げられます。

既に多数のスパムボットや攻撃元が登録されている場合があり、導入直後からスパム投稿を大幅に減らせるケースもあります。
一方で、外部リストには誤判定や情報の鮮度にばらつきがある可能性もあるため、過信は禁物です。

このため、外部ブラックリストは単独で使うのではなく、スコアリングや補助的な判定要素として利用されることが一般的です。

③　国別IPブロック（GeoIP）で遮断する方法

アクセス元の国・地域情報（GeoIP）を基に、特定の国・地域からのアクセスを一括で遮断する方法です。

対象サイトのビジネス範囲が特定地域に限定されている場合、特定の国・地域からのアクセスが不要であれば一括ブロックで被害を大きく減らせる可能性がありますが、一方で、海外からの正当なユーザー（旅行中の既存顧客など）をブロックしてしまうリスクがある上に、軽々にアメリカをブロックするとGooglebotやBingbot（両方とも主に米国IP）をはじめとする、検索エンジンのクローラーがアクセスできなくなる可能性が高いため、検索結果にヒットしなくなるリスクがあります（GoogleなどのIPアドレスをホワイトリストにいれたり、リバースDNSを用いて、アクセス元がgooglebot.com になっているかをチェックし通過させる方法などで回避できますが、いずれにせよ対応コストがかかります）。

④　Tor出口ノード（Tor Exit Node）をブロックする方法

匿名ネットワーク（Tor）を経由したアクセスを拒否する方法です。

Torは本来的にはプライバシー保護の目的で使われるべきものですが、近年スパムや攻撃に悪用されるケースが多くなっているため、Tor出口ノードをブロックすることで一定の効果が期待できます。

一方で、Torを経由していないスパムも多くある上に、Torノードリストは頻繁に変わるため、常に最新の出口ノード情報を更新・参照する必要があり、運用上のコストがかかるという課題があります。

なお、WAFやクラウド型セキュリティサービスを利用すれば、Tor判定やブロックを自動化できる場合もあります。

WAF（Web Application Firewall）とは、Webアプリケーションへの通信内容を解析し、不正なリクエストや攻撃を検知・遮断するセキュリティ機構です。
Cloudflare、AWS WAF、Azure WAF などのクラウド型サービスや、ModSecurity に代表されるオンプレミス型WAFを利用し、迷惑メール・スパム投稿の送信元となるIPアドレスやリクエストをルールベースで遮断する方法です。

WAFでは、既知の攻撃パターンに基づくシグネチャ、IPレピュテーション、ドメインレピュテーション、挙動分析などを組み合わせて判定を行うため、スパム投稿やBotアクセスを自動的に検知・遮断でき、手動でブラックリストを管理する負担を軽減できます。

一方で、WAFの導入・運用にはコストがかかるほか、設定内容によっては正規ユーザーのアクセスを誤って遮断してしまう「誤検知」が発生する可能性があります。
そのため、導入直後には検知ログを確認しながらルールの調整（チューニング）を行い、誤検知を抑制する作業が必要となりますが、このチューニングにはセキュリティ、ネットワーク、WAF製品特有の挙動に関する知識が求められ、一定の運用コストが発生する点には注意が必要です。

クラウド型セキュリティサービスは通常、CDNを利用したコンテンツ配信・キャッシュ最適化に加え、DDoS緩和、WAF、レートリミット、ボット管理、SSL/TLSターミネーションなど、包括的なセキュリティ・パフォーマンス管理機能を備えたサービスです。

前述のCloudflareのWAFも、Cloudflareというクラウド型セキュリティサービスのWAF機能と位置付けてよいでしょう。

これらのサービスでは、CDNのエッジ段階で通常のユーザーアクセスと不審なトラフィックを判別し、スパムbotや攻撃リクエストをWebサーバーやフォーム処理に到達する前に遮断できるため、「そもそもスパムボットがお問い合わせフォームに到達できない」構成を実現でき、フォーム送信への攻撃を包括的に防御できる点が大きなメリットです。

一方で、WAFと同様に初期設定やルール設計、誤検知を抑えるためのチューニングが必要となり、導入・運用には一定のコストと専門知識が求められます。
特に、業務上重要なフォームを扱う場合は、段階的な有効化やログ監視を行いながら慎重に調整する必要があります。

なお、EU一般データ保護規則（GDPR、General Data Protection Regulation）の順守が求められる企業の場合で、米国に拠点を持つクラウド型セキュリティサービス（CDN＋WAF）を導入する場合、これらのサービスは一般的にトラフィックを複数の海外サーバーに中継するため、EU域外への個人データ移転が生じる可能性があります。
もうこのあたりは、企業の法務部の皆様と当社のようなベンダーがいかにしてクリアするかをケースバイケースで検討するしかない状況です。

上記のように、迷惑メール・スパムメールへの対策は多層防御が基本となります。

しかしながら、どのような手法にも誤検知・誤判断のおそれはありますし、それぞれの環境によって選択すべき対策手法は異なってきます。
また、対策を実施しようにも知見が必要であったり、設定が複雑であるなどの問題に直面することもあるかと思います。