2026.09.09

お問い合わせフォームのスパムが大量送信されている時の対処法｜サーバー停止リスクと根本対策

執筆者情報

中村圭介

株式会社カジヤ/代表取締役　男性向けファッション通販サイト運営の会社を経験し、現職に至る。デザインや開発から、ECやメディアのコンサルティングまでを一貫して行う。お付き合いのあるお客様の事業を成功に導けるように、再現性のある成長支援ができる会社を目指す。

【AIによる要約】
– フォームスパムの大量送信は迷惑メールの問題だけでなく、サーバー停止・送信ドメインのブラックリスト入り・メール送信不能という事故につながります。
– reCAPTCHAやAkismetは導入済みでも防げないケースがあり、設定の確認だけでなくログでの実態把握が先決です。
– まず自動返信メールの停止で拡散を止め、その後はWAF等の多層防御へ。サーバー会社への連絡も初期対応として有効です。

はじめに：「一通のスパム」では済まない話

朝出社して、管理画面とメールボックスを開いたら、お問い合わせフォーム経由のスパムが数百通。

この経験をした担当者は、決して少なくありません。実は当社カジヤでも、業界歴10年以上・300社以上の支援の過程で、この種のインシデント対応には何度も立ち会ってきました。

そして現場でよくあるのが、「reCAPTCHAを入れているのに、なぜ？」という問いです。残念ながら、reCAPTCHAを含む一般的な対策は万能ではありません。人間の入力者を装う手口や、プラグインの隙間を突く攻撃は存在します。

さらにこの問題が深刻なのは、スパムメールが送信されることだけでなく、サーバー停止やメール機能の喪失につながるリスクがある点です。この記事では、その理由や根本対策として何をすべきかを解説します。

なぜフォームスパムが「サーバー停止」まで引き起こすのか

スパム送信は、人間が1件ずつ入力しているわけではありません。プログラムが1秒間に数十〜数百リクエストを送り続けます。このとき起きることを、順番に見ていきます。

フォームへの大量アクセスがサーバー全体を圧迫する様子

1. サーバーリソースの枯渇

フォーム送信は、ページ表示よりはるかに重い処理です。DBへの書き込み、メール送信処理、場合によっては画像処理まで動きます。これが大量に同時発生すると——

CPU・メモリがスパム処理に占有される
正規の閲覧者のページ表示が極端に遅くなる
最悪の場合、サーバー会社から「負荷が高すぎる」としてアカウントを一時停止される

レンタルサーバーには利用規約上の負荷制限があります。共用サーバーでは、自社サイトだけでなく同じサーバーの他サイトへの影響を理由に、事前通告なく停止されることもあります。

2. メール送信のブラックリスト入り（踏み台化）

多くのフォームには「自動返信メール」機能があります。スパマーはここを狙います。

フォームのメール欄に他人のメールアドレスを入れて送信
自動返信がそのアドレス宛に飛ぶ＝あなたのサーバーがスパム配信の踏み台になる
大量の送信により、サーバーのIPアドレスや送信ドメインがブラックリスト（RBL等）に登録される

一度ブラックリストに入ると、「今まで送れていた見積もり依頼の返信が、急に相手に届かなくなる」状態が続きます。営業メール、決済通知、注文確認——ビジネス上の重要メールまで一斉に届かなくなるのです。これはフォームの問題を超えた、会社の通信インフラの事故です。

3. 管理コストの静かな増大

数百〜数千通のスパムが管理画面やDBに蓄積されると、正規の問い合わせが埋もれます。「問い合わせが来たのに返信が遅れた」という機会損失は、金額に換算しづらい分、さらに厄介です。

放置した場合のリスク	影響の範囲
サーバー負荷による停止・アカウント停止	自社サイト全ページ＋EC等の同サーバーサイト
送信ドメイン・IPのブラックリスト入り	全社のメール送信（見積もり、注文確認、営業）
正規問い合わせの取りこぼし	営業機会損失
DB肥大化によるバックアップ・管理の劣化	サイト運用全体

最初にやること：緊急対応の3ステップ

スパムが大量に届いている状況での初動を順に示します。

ステップ1：自動返信メールを止める（最優先）

ブラックリスト入りを防ぐため、まず自動返信機能をオフにします。Contact Form 7 なら「メール」タブで送信を無効化、MW WP Form なら設定画面で自動返信を停止します。これで「外部への拡散」が止まり、踏み台化の進行を食い止められます。

ステップ2：スパムの実態をログで確認する

どのURL（フォーム）に、
どのIPアドレスから、
どの程度の頻度でアクセスが来ているか

をサーバーのアクセスログで確認します。特定IPや特定の国・AS番号（インターネット回線の事業者単位の番号。クラウド事業者など）に偏っている場合、後述の対策が格段にやりやすくなります。ここを確認せずに「対策プラグインを入れてみる」と、効果が出ないまま時間だけが過ぎます。

ステップ3：サーバー会社・保守担当へ連絡する

共用サーバーの場合、サーバー会社側でIP制限やWAF（Web Application Firewall）の設定ができることがあります。自社だけで抱え込まず、初期対応として連絡するのが正解です。当社が保守を担当している案件でも、この段階でサーバー会社との連携を行い、当日中に拡散を止めたケースが複数あります。

根本対策：reCAPTCHAだけでは不十分な理由と多層防御

初動で送信は止められても、攻撃は続きます。ここからが根本対策です。

reCAPTCHA・レート制限・ボット検知の多層防御のイメージ

reCAPTCHAの限界

reCAPTCHA v2/v3は、人間の入力者を「スコア」で判定する仕組みです。しかし:

v3はスコア制のため、閾値設定が甘いとボットでも通過する
プラグインの実装漏れ（別フォームやエンドポイント）があると、そこを突かれる
クラウドソーシング等で「人間に解かせる」手口には原理的に無力

当社の見解として、「reCAPTCHAは多層防御の1層であって、対策の全部ではない」という前提を持つことが重要です。

効果的な多層防御の構成

対策	内容	効果
WAF / ボット対策	サーバー側でボットシグネチャを遮断	スパム処理自体をサーバーにさせない
IP / 国別制限	ログ分析で判明した送信元を制限	踏み台化と負荷を直接抑制
ノンス・ハニーポット	フォームに人間用の隠し項目を実装	プラグイン標準機能で可能な低コスト対策
送信回数制限	同一IPからの送信を単位時間あたり制限	負荷の上限を担保
自動返信の設計見直し	宛先検証・レート制限を付ける	踏み台化の根本対策
Akismet等のフィルタ	本文パターンで判別	漏れたスパムの二次フィルタ

ポイントは、「フォーム側の防御」と「サーバー側の防御」の両方を入れることです。フォーム側だけだと、リクエスト自体は届き続けるため、負荷の問題が残ります。

ブラックリスト入りしてしまった時の確認方法

すでに「メールが届かない」という声が出ているなら、送信ドメインの状態を確認します。

MXToolboxで自ドメイン・サーバーIPのブラックリスト掲載を確認
Googleのメール管理者向けPostmaster Toolsや、受信側（Gmail等）へのテスト送信で届達状況を確認
掲載が確認できたら、各リストの削除申請（delisting）手続きを実施

解除申請は英語のフォーム対応が必要なリストもあり、反映まで数日を見ます。この間も営業メールは届かない状態が続くため、繰り返しますが、自動返信を止める初動の価値は非常に大きいのです。

自社で対応すべき範囲と、プロに任せるべき範囲

社内でどこまで対応し、どこから外注すべきか。当社の判断基準を明確に述べます。

自社で対応可能： 自動返信の停止、reCAPTCHAやAkismetの設定見直し、プラグインのアップデート
プロに任せるべき： アクセスログの分析とWAF設定、サーバー会社との交渉、ブラックリスト解除、フォーム送信処理そのものの改修

理由は単純で、ログ分析とWAF設定は誤ると正規ユーザーまで遮断してしまう作業だからです。サイトが止まったら元も子もない。300社以上の支援の中で、自社での設定ミスによる二次障害の相談も実際に受けています。

なお、当社自身も複数のWebサービス・ECサイトを運営している当事者です。フォームが止まれば受注が止まる、メールが届かなければ商談が消える——その重みを事業として知っているからこそ、「スパム対応は金曜午後に細々やる作業」ではなく「通信インフラを守るインシデント対応」として扱うようお伝えしています。