Webサイトへお問い合わせフォームを設置すると、英語だけの営業メール、不自然なリンク、意味のない文字列などが送られてくることがあります。
フォームの項目を必須にしても、迷惑送信が止まらない場合もあります。
これは、人が一件ずつ入力しているのではなく、自動化されたプログラムがWeb上のフォームを探し、機械的に送信している可能性があるためです。
迷惑送信を防ぐ方法として、reCAPTCHAやCloudflare Turnstileなどの仕組みが利用されています。
今回は、お問い合わせフォームへ迷惑送信が届く理由と、CAPTCHAやTurnstileの役割、導入後に確認すべきポイントを初心者向けに解説します。
迷惑送信の多くは自動化されている
Webサイトを公開すると、検索エンジンだけでなく、さまざまな自動プログラムがページへアクセスします。
すべてが危険なものではありませんが、フォームを探して自動送信するプログラムも存在します。
このようなプログラムは、次のような操作を繰り返します。
フォームがあるページを探す
入力欄の種類を確認する
名前やメールアドレスを自動入力する
宣伝文やリンクを本文へ入れる
送信ボタンを実行する
別のサイトでも同じ処理を行う
人がブラウザを操作するよりも短時間で大量に送信できるため、小規模なWebサイトにも迷惑メールが届く可能性があります。
アクセス数が少ないサイトだから狙われないとは限りません。
必須項目だけでは迷惑送信を防げない
フォームの名前、メールアドレス、本文などを必須にすれば、空のまま送信されることは防げます。
しかし、自動プログラムも必要な項目へ文字を入力できます。
メールアドレスの形式を確認する機能があっても、形式に合った架空のアドレスを入力されれば通過する可能性があります。
入力内容の確認は、利用者の入力ミスを防ぐために必要です。
一方、送信者が人間なのか、自動プログラムなのかを判定するには、別の対策が必要になります。
CAPTCHAは人間と自動プログラムを見分ける仕組み
CAPTCHAは、フォームを操作しているのが人間か、自動プログラムかを判定するための仕組みです。
以前は、画像に書かれた文字を入力したり、指定された物が写っている写真を選んだりする方法が多く使われていました。
自動プログラムには解きにくく、人間には判断できる問題を出すことで、不正な送信を減らします。
現在では、利用者に毎回問題を出すのではなく、ページ上での動作や通信情報などを利用して判定する仕組みも増えています。
CAPTCHAという言葉は特定のサービス名ではなく、人間と自動処理を見分けるための考え方を表しています。
reCAPTCHAとは
reCAPTCHAは、Googleが提供する不正送信対策の仕組みです。
画面へチェック項目を表示する方式や、画像を選択させる方式、利用者の操作をもとに危険度を判定する方式などがあります。
多くのWordPressプラグインやフォームサービスで利用されているため、設定画面で名前を見たことがある人も多いでしょう。
導入すると迷惑送信を減らせる可能性がありますが、利用方法によっては次のような点へ配慮が必要です。
画像問題が表示されて送信に時間がかかる
判定によって正常な利用者も止められる可能性がある
外部サービスのファイルを読み込む必要がある
プライバシーに関する案内が必要になる場合がある
サービス側の設定変更へ対応する必要がある
導入済みだから永久に何もしなくてよいわけではなく、正常に動いているか定期的に確認します。
Cloudflare Turnstileとは
Cloudflare Turnstileも、フォームを操作しているのが人間か自動プログラムかを判断するための仕組みです。
利用者へ画像問題を何度も出すのではなく、ブラウザや通信の状態などを利用して確認することが特徴です。
多くの場合、利用者は複雑な操作を求められず、そのままフォームを送信できます。
ただし、画面上で目立った確認操作がないからといって、何も行われていないわけではありません。
ページの裏側で確認処理が行われ、問題がないと判断された場合に送信を許可します。
フォームの使いやすさを保ちながら迷惑送信対策を行いたい場合の選択肢になります。
Site KeyとSecret Keyの違い
reCAPTCHAやTurnstileを設定するときには、Site KeyとSecret Keyが発行されます。
名前が似ていますが、役割は異なります。
Site Keyは、Webサイト側で確認機能を表示・実行するために使用します。
ブラウザへ渡される情報なので、ページの動作を確認すると見つけられる場合があります。
一方、Secret Keyは、送信時に得られた情報が正しいかをサーバー側で確認するために使用します。
Secret Keyは外部へ公開してはいけません。
テーマのJavaScriptへ直接書いたり、公開リポジトリへ保存したりすると、第三者に取得される可能性があります。
設定画面で入力するときは、二つのキーを逆にしていないかも確認します。
キーを登録しただけでは対策が完了しない
管理画面へキーを入力すると、設定が完了したように見えることがあります。
しかし、実際のフォームで確認処理が行われていなければ、不正送信を防げません。
導入後は、次の状態を確認します。
フォームのページで必要なファイルが読み込まれているか
正常に送信できるか
確認に失敗したときは送信を止められるか
ブラウザのコンソールにエラーがないか
対象のドメインが正しく登録されているか
テスト環境と本番環境の両方に対応しているか
キャッシュ削除後も正常に動くか
設定画面に「接続済み」と表示されていても、利用者と同じ状態でフォームを送信して確認する必要があります。
ドメインの登録間違いに注意する
不正送信対策サービスでは、発行したキーを利用できるドメインを指定することがあります。
本番サイトのドメインだけを登録している場合、ローカル環境やテスト用サブドメインでは正しく動かない可能性があります。
反対に、テスト環境の設定をそのまま本番へ移行すると、本番ドメインが許可されていない場合があります。
サイト移行やドメイン変更を行ったときは、次の点を確認します。
新しいドメインが登録されているか
古いドメインだけが残っていないか
サブドメインも対象になる設定か
本番用とテスト用のキーを混同していないか
使用していないドメインを放置していないか
フォーム本体を移行できていても、外部サービス側のドメイン設定は自動で変わらないことがあります。
迷惑送信対策とメール到達率は別の問題
reCAPTCHAやTurnstileを設定すれば、フォームから送信されたメールが必ず受信トレイへ届くようになるわけではありません。
これらの役割は、主に自動プログラムによる送信を判定して減らすことです。
フォームから送信されたメールが迷惑メールフォルダへ入る問題には、別の原因が考えられます。
たとえば、次のような原因です。
送信元アドレスの設定が不自然
サイトのドメインと送信元が一致していない
メール認証の設定が不足している
サーバーからの送信が信用されていない
本文や件名が迷惑メールと判定されている
受信側のフィルターに止められている
迷惑送信を受け取る問題と、正常なメールが届かない問題は分けて考えます。
CAPTCHAだけですべての迷惑送信は防げない
CAPTCHAやTurnstileを導入しても、迷惑送信を完全にゼロにできるとは限りません。
自動プログラム側も対策を回避する方法を変化させるためです。
また、人が直接送信している営業メールは、人間として正常に判定される可能性があります。
必要に応じて、次のような対策も組み合わせます。
短時間の連続送信を制限する
サーバー側でも入力内容を確認する
画面には見えない入力欄を利用する
特定の文字列やリンク数を確認する
同じ内容の連続送信を拒否する
不要なフォームを公開し続けない
迷惑送信の傾向を記録する
一つの仕組みだけへ依存せず、利用者への負担と安全性のバランスを考えます。
画面に見えない入力欄を使う方法
迷惑送信対策には、通常の利用者には表示しない入力欄を用意する方法もあります。
人間には見えないため、通常は何も入力されません。
しかし、自動プログラムがフォーム内のすべての項目へ機械的に入力すると、その隠れた項目にも文字が入ります。
そこで、見えない項目へ入力があった場合は、自動送信の可能性が高いと判断します。
この方法はハニーポットと呼ばれます。
利用者へ画像選択などを求めないことがメリットですが、高度な自動プログラムには見抜かれる可能性があります。
CAPTCHAや送信回数の制限などと組み合わせて使用されることがあります。
厳しくしすぎると正常な問い合わせも減る
迷惑送信を減らすことだけを考えて判定を厳しくすると、本来のお問い合わせまで拒否する可能性があります。
特に、スマートフォン、古いブラウザ、通信が不安定な環境、プライバシー保護機能を利用している環境などでは、判定処理が正常に完了しない場合があります。
また、画像を何度も選ばせる仕組みは、利用者にとって大きな負担になります。
お問い合わせフォームは、営業や相談につながる重要な窓口です。
対策後は迷惑送信の数だけでなく、正常な問い合わせが送れているかも確認します。
アクセシビリティへの配慮も必要
人間であることを確認する操作が、すべての利用者にとって簡単とは限りません。
画像の内容を判別する方式は、視覚に障害がある人や小さな画面を使用している人には操作しにくい場合があります。
音声による確認方法が用意されていても、周囲の環境によっては利用できません。
導入する仕組みを選ぶときは、次の点も確認します。
キーボードだけで操作できるか
読み上げ機能で内容を理解できるか
小さな画面でも操作できるか
失敗した理由が表示されるか
再試行の方法が分かるか
確認操作が何度も繰り返されないか
不正送信を止めるために、必要な利用者までお問い合わせできなくならないようにします。
WordPressではプラグイン同士の重複に注意する
WordPressでは、フォームプラグイン、セキュリティプラグイン、迷惑送信対策プラグインなどが、それぞれCAPTCHA機能を持っていることがあります。
複数のプラグインで同じ対策を有効にすると、確認処理が重複する可能性があります。
その結果、次のような問題が発生することがあります。
フォームを送信できない
確認表示が複数出る
JavaScriptエラーが発生する
ページの表示が遅くなる
正常な送信まで拒否される
管理するキーが増えて分かりにくくなる
現在どのプラグインが不正送信対策を担当しているのかを整理し、同じ役割の機能を必要以上に増やさないことが大切です。
導入後にテストする内容
迷惑送信対策を設定したら、管理画面を見るだけでなく、実際のフォームからテスト送信を行います。
確認したい項目は次のとおりです。
パソコンから正常に送信できるか
スマートフォンから正常に送信できるか
必須項目が空ならエラーになるか
確認処理が失敗した場合に送信を止められるか
管理者宛てメールが届くか
自動返信メールが届くか
迷惑メールフォルダへ入っていないか
送信完了メッセージが表示されるか
コンソールにエラーが出ていないか
キャッシュや高速化機能を有効にしても動くか
一度成功しただけで終わらせず、WordPressやプラグインを更新したあとにも確認します。
まとめ
お問い合わせフォームへ届く迷惑送信の多くは、自動プログラムによって機械的に送られています。
入力欄を必須にするだけでは、自動入力による送信を防ぐことはできません。
reCAPTCHAやCloudflare Turnstileは、フォームを操作しているのが人間か自動プログラムかを判定し、不正な送信を減らすための仕組みです。
ただし、導入すればすべての迷惑送信がなくなるわけではなく、メールが受信トレイへ届く問題を直接解決するものでもありません。
ドメイン、キー、プラグインの設定を確認し、送信回数の制限やサーバー側の入力確認なども必要に応じて組み合わせます。
対策を厳しくしすぎて、本来の利用者が問い合わせできなくなっては意味がありません。
迷惑送信を減らしながら、正常な問い合わせを簡単に送れる状態を保つことが、安全で使いやすいフォーム運用につながります。