お問い合わせフォームにスパム対策を入れるとき、よく使われるのがGoogle reCAPTCHAです。ただ、reCAPTCHAには種類があり、チェックボックスを押すタイプと、ユーザーに見えない形で判定するv3では、実装の考え方が違います。
v3で大切なのは、画面に何かを表示することではありません。送信時にトークンを発行し、そのトークンをサーバー側で検証し、スコアやactionを見て送信を許可することです。フォームまわりの不具合は、見た目には出にくい場所で起きがちです。
v3はチェックボックスではない
v2の「私はロボットではありません」に慣れていると、v3でも画面にチェックボックスを置きたくなります。しかしv3は、送信ボタンを押したタイミングなどで grecaptcha.execute を実行し、裏側でトークンを取得します。
そのため、フォーム上に表示するUIは基本的に増えません。ユーザー体験を邪魔しない反面、実装側では「いつトークンを取るか」「送信前に必ず取得できるか」をきちんと設計する必要があります。
特に注意したいのは、ページ読み込み時に一度だけトークンを取って放置しないことです。入力に時間がかかるフォームでは、送信直前に取得するほうが安定します。確認画面を挟む場合も、どの画面でトークンを発行し、どの処理で検証するかを先に決めておきます。
サーバー側検証が本体
フロント側でトークンを取得しただけでは、スパム対策としては不十分です。取得した g-recaptcha-response を送信処理へ渡し、サーバーからGoogleの検証APIへ問い合わせます。
ここで検証せずにメール送信してしまうと、トークンを置いただけの状態になります。reCAPTCHAは「フォームに貼る部品」ではなく、送信処理の手前に置く判定です。
また、サイトキーは公開される前提ですが、シークレットキーはサーバー側だけで扱います。HTMLやJavaScriptに混ぜない、リポジトリへ不用意に残さない、テスト用と本番用を混同しない。このあたりは小さく見えて、あとから事故になりやすい部分です。
scoreとactionを見る
v3では、成功か失敗かだけでなく、scoreが返ります。一般的には0.0に近いほど怪しく、1.0に近いほど人間らしい挙動と判断されます。また、実行時に指定したactionが、サーバー側で期待しているactionと一致するかも確認します。
お問い合わせフォームなら contact、資料請求なら download のように、用途ごとにactionを分けておくと、不自然な送信を見つけやすくなります。
scoreのしきい値は、一度決めたら終わりではありません。最初は0.5前後で様子を見て、正常な問い合わせが弾かれていないか、スパムが通りすぎていないかを確認します。可能であれば、失敗理由やscoreをログに残し、実際の送信状況を見ながら調整するのが現実的です。
よくある実装ミス
reCAPTCHA v3の導入相談を受けていると、原因のパターンはある程度決まっています。代表的なものを挙げます。
- フロントでトークンを取得しているが、サーバー側の検証処理がそもそも実装されていない
- 本番ドメインをGoogle側の設定に登録し忘れていて、本番だけ検証に失敗する
- テスト用のサイトキー・シークレットキーを本番にそのまま使ってしまっている
- scoreだけを見てactionの一致を確認しておらず、他のフォーム宛のトークンでも通ってしまう
- AIツールやテンプレートを使って実装した際、フロント側のUIだけ生成されて、サーバー側検証が抜け落ちている
特に最後のパターンは、AIで作ったフォームでよく見かけます。見た目上はreCAPTCHAが動いているように見えても、検証部分が抜けていると、実質的には何も防げていません。公開前に、実際にスパムらしい送信を試すか、コードを一度人の目で確認しておくと安心です。
失敗時の案内を用意する
reCAPTCHAの検証に失敗したとき、単に「送信できません」だけでは、正しいユーザーも困ります。時間をおいて再送する案内や、直接メールで問い合わせる代替手段を用意しておくと親切です。
フォームの目的は、スパムをゼロにすることではなく、必要な問い合わせを取りこぼさずに守ることです。強くしすぎて正しい送信を止めてしまうと本末転倒です。v3は見えない対策だからこそ、送信テスト、本番ドメイン設定、失敗時の導線まで含めて確認しましょう。フォームの調子がおかしいと感じたら、AIケアやサイトの健康診断で一度まとめて見直すのもひとつの方法です。
よくある質問
ユーザーの操作を増やしたくないフォームならv3が向いています。ただし、v3はスコアによる推測判定のため、スパムが多い、あるいは誤判定が気になる場合は、v2のチェックボックスやv2の見えないバージョンと組み合わせる選択肢もあります。フォームの重要度と許容できるスパム量で判断します。
Googleが目安として示す0.5前後から始め、実際の送信ログを見ながら調整するのが現実的です。正常な問い合わせが弾かれていないか、スパムが通りすぎていないかを両方確認し、必要に応じてしきい値を上下させます。
フロント側でトークンを取得しているだけで、サーバー側の検証が実装されていないケースがよくあります。取得したトークンをGoogleの検証APIに問い合わせて、scoreとactionを確認する処理まで実装されているかを見直してください。
Webコーダー/ディレクターとして独立後、2026年にI-to.合同会社を設立。Webサイト制作・コーディング代行・AIケアを通じて、社内のWeb業務を整理し、運用しやすい形に整えています。プロフィール詳細