Web制作

問い合わせフォームをボットの踏み台にさせない|CAPTCHA・送信制限・自動返信の見直し方

問い合わせフォームをボットの踏み台にさせない|CAPTCHA・送信制限・自動返信の見直し方

Webサイトの問い合わせフォームに、意味の分からない英語の文章や、広告のURLばかりが並んだ送信が毎日のように届く。あるいは、サーバー会社から「お客様のサイトから大量のメールが送信されています」という連絡が来る。問い合わせフォームを設置している会社やお店にとって、こうしたトラブルは決して珍しいものではありません。原因の多くは、人ではなく、プログラムで自動的にフォームを送信する「ボット」です。

レンタルサーバー大手のエックスサーバーは2025年3月、問い合わせフォームの自動返信機能を悪用したスパムメール送信についての注意喚起を出しました。2025年1月頃から、WordPressの問い合わせフォーム用プラグインや、PHP・Perlで作られたフォームを悪用し、利用者のWebサイトを介して大量のスパムメールが不正に送信される事例が急増している、という内容です。フォームを設置している側は被害者であると同時に、知らないうちに迷惑メールの送信元になってしまう可能性があります。

生成AIの普及によって、こうした自動送信のプログラムや文章を用意する手間は、今後さらに下がっていく可能性があります。フォームのような「誰でも送信できる入口」は、ボットにとって狙いやすい対象です。だからといって、フォームを閉じてしまえば、本来の問い合わせまで受け取れなくなります。大切なのは、人からの問い合わせは受け取りつつ、機械的な大量送信だけを止められる仕組みを整えることです。

この記事では、中小企業のWeb担当者の方と、フォームを実装するWeb制作者の方に向けて、問い合わせフォームを狙うボットの手口を整理し、CAPTCHA(Cloudflare Turnstile、reCAPTCHA)の導入、送信回数の制限、自動返信メールの見直し、外部フォームサービスの活用といった対策を、優先順位を付けて紹介します。なお、「フォームから送信したのにメールが届かない」というトラブルについては、フォームが届かない原因の確認方法を解説した記事で扱っています。今回は、届きすぎる、悪用されるという逆側の問題が主題です。

私はフリーランスのWebディレクター兼エンジニアとして、WordPressやNext.jsでのフォーム実装に関わってきました。その立場から、IPAやCloudflare、Googleの公式ドキュメント、レンタルサーバー各社の注意喚起に沿って、実装と運用の両面から解説します。

フォームを狙うボットの三つの手口

手口1:スパムの大量送信

最も分かりやすいのが、広告や詐欺サイトへのリンクを含んだ文章を、フォームから大量に送りつける手口です。届いた問い合わせを一件ずつ確認する担当者の手間が増えるだけでなく、本物の問い合わせがスパムに埋もれて見落とされる原因にもなります。フォームの送信内容をデータベースに保存している場合は、不要なデータがたまり続けることにもなります。また、問い合わせをきっかけに営業や見積もりの対応を始める会社では、スパムへの返信や確認に時間を取られること自体が、見えにくいコストになります。

手口2:自動返信メールを使った「踏み台」

問い合わせフォームの多くには、送信した人に「お問い合わせありがとうございました」と自動でメールを返す機能があります。この機能が悪用されると、フォームは迷惑メールの送信装置になってしまいます。さくらインターネットのフォーム設置講座や、ミライネットの注意喚起では、その流れが次のように説明されています。

  1. メールアドレス欄に、迷惑メールを送りつけたい相手のアドレスを入力する
  2. 問い合わせ内容の欄に、フィッシングサイトや広告のリンクを入力する
  3. 送信すると、入力した内容を含んだ自動返信メールが、1のアドレスに届く

これをプログラムで繰り返すと、まったく関係のない会社のサーバーから、大量の迷惑メールが送られることになります。エックスサーバーの注意喚起では、その影響として、自社のメールアドレスが迷惑メールの送信元と判定されること、自社が送るメールが受信拒否されること、メールの送信数が上限に達して必要なメールを送れなくなることを挙げています。ミライネットの注意喚起では、サーバーのIPアドレスがブラックリストに登録される可能性や、場合によってはサイトを停止する可能性にも触れています。

手口3:入力欄からの攻撃

三つ目は、フォームの入力欄に、プログラムの命令や特殊な文字を紛れ込ませる手口です。IPAの安全なウェブサイトの作り方「メールヘッダ・インジェクション」では、問い合わせページやアンケートのように、入力内容をメールで送る機能に不備があると、外部の人が送信先を自由に指定できてしまい、迷惑メールの送信に悪用されることがあると説明しています。同じく安全なウェブサイトの作り方では、入力内容を画面に表示する部分の不備によってスクリプトを埋め込まれる「クロスサイト・スクリプティング」なども取り上げられています。これらは、CAPTCHAだけでは防げない、作り方そのものの問題です。

CAPTCHAの選び方と入れ方:Cloudflare TurnstileとreCAPTCHA

CAPTCHAは「人か機械か」を確かめる改札

CAPTCHAは、フォームを送信しようとしている相手が、人なのか機械なのかを確かめる仕組みです。駅の改札のように、フォームの手前に置いて、機械的な送信を通りにくくします。以前は、ゆがんだ文字を読ませたり、信号機の画像を選ばせたりする方式が主流でしたが、現在は、利用者に何も操作させずに裏側で判定する方式が増えています。代表的なものが、Cloudflare TurnstileとGoogleのreCAPTCHAです。

Cloudflare Turnstile

CloudflareのTurnstileのプラン説明によると、Turnstileには無料プランがあり、1アカウントあたり20個までのウィジェットを作成でき、検証の回数に上限はありません。また、Turnstileは他のCloudflareのサービスを使っていなくても単独で利用できるとされています。サイトのDNSやサーバーをCloudflareに移していなくても、フォームにだけ導入できるということです。

WordPressの定番プラグインであるContact Form 7は、2025年6月に公開されたバージョン6.1で、Turnstileとの連携機能を標準で搭載しました。連携の手順は、Cloudflare側でサイトキーとシークレットキーを取得し、WordPressの管理画面の「お問い合わせ」→「インテグレーション」に入力するだけで、すべてのフォームにTurnstileが配置される、という簡単なものです。

reCAPTCHA

GoogleのreCAPTCHAも、広く使われている選択肢です。reCAPTCHA v3は、利用者に操作をさせず、送信のたびに0.0から1.0までのスコアを返します。スコアが低いほどボットの可能性が高いとされ、どのスコアで止めるかはサイト側で決めます。Googleのドキュメントでは、新しく導入する場合は、従来の検証方法ではなく、Google Cloudの評価(CreateAssessment)の方式を使うよう案内されています。料金や利用条件は変わることがあるため、導入前に公式の最新情報を確認してください。

どちらでも「サーバー側の検証」が欠かせない

どちらを使う場合も、最も大切なのは、フォームを受け取るサーバー側で「CAPTCHAの結果が本物か」を確かめることです。Cloudflareのサーバー側検証のドキュメントでは、ウィジェットを画面に置くだけではフォームは守られず、検証APIを呼び出して初めて導入が完了すると明記しています。攻撃者はCAPTCHAを解かずに、任意の文字列をフォームの送信先に直接送ってくることができるためです。トークンの有効期限は5分で、一度しか検証できないことも説明されています。

送信回数の制限と、ボットを見分ける小さな仕掛け

送信回数の制限は「同じ人が何度も通れない」仕組み

CAPTCHAと組み合わせて使いたいのが、送信回数の制限(レート制限)です。同じ送信元から、短い時間に何度もフォームが送信されたら、一定時間受け付けないようにします。人が問い合わせをする場合、数秒おきに何十回も送信することはまずありません。機械的な大量送信だけを、利用者の負担なく止めやすい方法です。

Cloudflareを使っている場合は、WAFのレート制限ルールが無料プランでも1つ利用できます。無料プランでは、パス(URL)を条件にして、IPアドレスごとに10秒間の回数を数え、上限を超えたら10秒間ブロックする、といった設定が可能です。Cloudflareの学習用ドキュメントでは、無料プランで特定のページに対し、同じIPアドレスから10秒以内に5回を超えるリクエストがあったら制限する例が紹介されています。フォームの送信先のURLを対象にすれば、サーバーに届く前に大量送信を抑えられます。

Cloudflareを使っていない場合でも、サーバー側のプログラムで、IPアドレスごとの送信回数や、同じメールアドレスからの送信回数を記録し、一定の回数を超えたら受け付けない仕組みを作ることができます。レンタルサーバーによっては、管理画面から国外からのアクセスを制限する機能が用意されていることもあります。ただし、海外から正当な問い合わせが来る可能性がある事業では、制限の範囲を慎重に検討しましょう。

ボットを見分ける小さな仕掛け

CAPTCHAやレート制限ほど強力ではありませんが、実装の手間が少なく、組み合わせると効果を発揮しやすい仕掛けもあります。いずれもよく使われる方法ですが、単独では突破されることがあるため、補助的な対策として考えてください。

  • 人には見えない入力欄(ハニーポット)を置き、そこに何かが入力されていたら送信を受け付けない
  • フォームを表示してから送信までの時間を記録し、数秒もかからずに送信されたものは疑わしいと判断する
  • 入力内容に、URLが一定数以上含まれている場合は受け付けない、または目視確認に回す
  • 必須項目や入力形式のチェックを、画面側だけでなくサーバー側でも行う

入力欄からの攻撃には「作り方」で備える

入力欄からの攻撃に対しては、IPAのメールヘッダ・インジェクションの解説が具体的な対策を示しています。メールの宛先や件名などのヘッダは固定値にし、外部からの入力はすべて本文に出力すること。HTMLの隠しパラメータに宛先を指定しないこと。外部からの入力の改行コードを取り除くこと。いずれも、フォームを自作する場合に確認しておきたい基本です。

自動返信メールの見直しと、外部フォームサービスの活用

自動返信は「入力内容をそのまま返さない」ことが基本

踏み台にされる手口の中心にあるのが、自動返信メールです。さくらインターネットのフォーム設置講座では、自動返信機能をオフにすることを根本的な対策として挙げています。また、reCAPTCHAを突破するボットも現れているとして、推奨設定を、投稿内容を転載した自動返信メールを送らない、または固定の文言だけを送ることだとしています。Contact Form 7では、自動返信の機能(メール(2))は初期設定でオフになっているとも説明されています。

悪い自動返信と、改善した自動返信

ここでは、よくある自動返信と、見直した自動返信を比べてみます。

項目

悪い例

改善例

本文

入力された問い合わせ内容を、すべて引用して返す

「お問い合わせを受け付けました」という固定の文言だけを返す

件名

入力された件名や名前をそのまま使う

「【会社名】お問い合わせを受け付けました」などの固定の件名にする

宛名

「〇〇様」に入力された名前をそのまま差し込む

宛名を入れないか、差し込む場合も文字数や記号を制限する

送信の条件

どんな送信にも、無条件に自動返信する

CAPTCHAの検証に通った送信にだけ返信する

確認の手段

入力内容の控えを、メールでしか確認できない

送信直後の画面に、受付完了と今後の流れを表示する

宛名に名前を差し込むだけでも、攻撃者は名前の欄に広告の文章やURLを入れてくることがあります。自動返信を残す場合は、「攻撃者が自由に書き込める部分が、メールに一文字も含まれない」状態を目指すのが安全です。自動返信をやめる場合は、フォームの近くに「セキュリティのため自動返信メールは送信しておりません。担当者より〇営業日以内にご連絡します」と書いておくと、問い合わせた人も安心できます。

外部フォームサービスを使うという選択

フォームを自社のサーバーで動かすこと自体を見直す方法もあります。Googleフォームのような汎用のフォームや、問い合わせ管理に特化した外部のフォームサービスを使えば、ボット対策や入力欄からの攻撃への備え、メールの送信処理を、サービスの提供元に任せることができます。さくらインターネットの講座でも、GoogleフォームやMicrosoft Formsを利用する方法が、選択肢の一つとして紹介されています。自社のサーバーから自動返信メールを送らなくなるため、踏み台にされたときにサーバーやメールの評判が下がる心配も小さくなります。

一方で、外部サービスにも注意点があります。フォームのデザインの自由度が下がること、サービスの管理画面のアカウントを守る必要があること、問い合わせに個人情報が含まれる場合はデータの保存先や取り扱いを確認する必要があることです。外部サービスにも自動返信の設定がある場合は、上の表と同じ考え方で内容を見直しましょう。

現場でつまずきやすいポイント

CAPTCHAを「画面に置いただけ」になっている

最もよくあるのが、CAPTCHAのウィジェットを画面に表示しただけで、サーバー側の検証をしていないケースです。前に触れたとおり、Cloudflareのドキュメントでは、検証APIを呼ばなければフォームは守られないと明記しています。自作のフォームにTurnstileを組み込む場合、サーバー側の処理はたとえば次のようになります。

// app/api/contact/route.ts(Next.js App Router の例)
export async function POST(request: Request) {
  const form = await request.formData();
  const token = form.get("cf-turnstile-response");

  const res = await fetch("https://challenges.cloudflare.com/turnstile/v0/siteverify", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      secret: process.env.TURNSTILE_SECRET_KEY,
      response: token,
    }),
  });
  const result = await res.json();

  if (!result.success) {
    return Response.json({ message: "送信を確認できませんでした" }, { status: 400 });
  }

  // 検証に通った場合だけ、メール送信や保存の処理に進む
}

シークレットキーは環境変数などで管理し、画面側のJavaScriptに書き込まないでください。Cloudflareも、フロントエンドに含めると検証を回避されるおそれがあると注意しています。共用レンタルサーバーとNext.jsを組み合わせたフォームの構成については、Next.jsと共用サーバーでの問い合わせフォームの記事も参考にしてください。

トークンの有効期限切れで、本物の問い合わせが失敗する

Turnstileのトークンは5分、reCAPTCHAのトークンは2分で有効期限が切れ、どちらも一度しか検証できません。長い文章を書いている間に期限が切れ、送信ボタンを押したらエラーになる、ということが起こり得ます。期限切れの場合はウィジェットを再読み込みする、エラーメッセージで「もう一度送信してください」と案内するなど、本物の利用者が困らない作りにしておきましょう。

reCAPTCHA v3のスコアの基準を決めずに導入する

reCAPTCHA v3は、スコアを返すだけで、止めるかどうかはサイト側の判断です。導入直後はスコアを記録して傾向を確かめ、そのうえで基準を調整しましょう。

古いフォームのプログラムが残ったままになっている

リニューアル前に使っていたフォームのプログラムや、テスト用に設置したフォームが、サーバーに残ったままになっていることがあります。画面からリンクされていなくても、URLが分かれば送信できてしまいます。エックスサーバーの注意喚起でも、WordPressなどのプログラムを最新版に更新することが対策として挙げられています。使っていないフォームは削除し、使っているフォームのプラグインやプログラムは、最新の状態を保ちましょう。

まとめ:フォームは「受け付ける入口」だからこそ、仕組みで守る

問い合わせフォームは、誰でも送信できることに価値がある仕組みです。しかし、その「誰でも」には、人だけでなくボットも含まれます。スパムの大量送信、自動返信メールを使った踏み台、入力欄からの攻撃。どれも、フォームを設置している会社の規模や知名度に関係なく起こり得ます。そして踏み台にされた場合、自社のメールが届かなくなったり、サーバー会社からサイトを止められたりと、日々の業務にまで影響が及ぶことがあります。

この記事で紹介した対策は、次の四つの層に整理できます。

  1. CAPTCHA(Cloudflare TurnstileやreCAPTCHA)を導入し、サーバー側で結果を検証する
  2. 送信回数の制限やハニーポットなどで、機械的な大量送信を止める
  3. 自動返信メールを見直し、入力内容を返さない、または自動返信をやめる
  4. メールヘッダの固定や改行の除去など、フォームの作り方そのものを安全にする

どれか一つで完結するものではなく、組み合わせることで守りが厚くなります。WordPressでContact Form 7を使っている場合は、プラグインを最新にしてTurnstileの連携を設定し、自動返信の内容を確認する。それだけでも、すぐに始められる対策になります。フォームを自作している場合は、サーバー側の検証と、メールヘッダの扱いを改めて点検してください。自社でフォームを持つ必要が薄いなら、外部のフォームサービスに任せることも、有効な選択肢です。

まずは、次の三つを確認してみてください。

  1. 自社のフォームに、CAPTCHAなどのボット対策が入っているか(入っている場合は、サーバー側で検証されているか)
  2. 自動返信メールに、問い合わせ内容や名前など、入力された内容がそのまま含まれていないか
  3. 使っていない古いフォームや、テスト用のフォームがサーバーに残っていないか

Web制作者の方であれば、新しくフォームを納品する際に、この三つを標準の確認項目にしておくことをおすすめします。あわせて、公開後にサーバー会社から注意喚起が届いたときの連絡先や、誰が設定を変えるのかを、クライアントと事前に決めておくと、いざというときの対応が早くなります。

「フォームに迷惑な送信が増えて困っている」「自動返信メールの設定が安全か分からない」「フォームを外部サービスに切り替えるべきか迷っている」という企業・店舗の方は、既存フォームの設定の確認と見直しからご相談を承っています。相談・お問い合わせからお気軽にご連絡ください。