reCAPTCHAを入れたらフォームを送れない？表示・トークン・サーバー検証を確認する手順

reCAPTCHAを導入した後に問い合わせを送れなくなったら、まず画面で認証できないのか、送信時の検証で拒否されるのか、受付後の通知だけが届かないのかを分けてください。チェックが見えないことだけで故障とは限らず、逆にチェックを完了したことだけで問い合わせの受付が成功したともいえません。

この記事は企業のWeb担当者と、WordPressやフォームを実装する制作会社向けです。主にreCAPTCHA v2/v3の公式仕様を基に、利用中の方式を確認し、表示、送信、検証、実受付の記録を対応させる手順を説明します。Cloud側の構成やプラグイン独自の実装では手順が異なるため、製品・版・管理方法を確認してから適用します。読者サイトの設定変更や送信試験を実施したという報告ではありません。

1. 送れない場所と、利用中の方式を確認する

見えるチェック欄だけで正常・異常を決めない

GoogleのreCAPTCHA v2の説明では、ウィジェットの表示と利用者の応答の検証を分けています。v3の説明はスコアとアクションを使う方式を案内しており、常に利用者がチェック欄を操作する構成ではありません。現在のフォームがどの方式を使うか、見た目だけで判断しないでください。

対象URL、フォームの用途、使っているプラグインと版、reCAPTCHAの方式、管理担当を控えます。「Googleの認証がある」という情報だけでは、v2/v3や別の製品のどの設定を見ればよいか確定しません。設定画面を共有する場合は、秘密鍵や個人情報が写らない範囲にします。

次に、症状が起きる段階を記録します。認証部分が表示されない、入力後に認証エラーが出る、待機中から進まない、完了画面は出るが担当者が通知を受け取れない、では調べる場所が異なります。エラー文を正確に控え、発生する端末・ブラウザー・時刻・操作の順番も残してください。

導入直後なら、同時に変えたフォーム、キャッシュや最適化、同意管理、テーマ、セキュリティ機能がないかも照合します。導入日が近いという理由だけで、すべての不達をreCAPTCHAの原因と断定しません。実受付は成功して通知だけが届かない場合もあります。

2. キー・対象ドメイン・連携する製品を照合する

サイトキーと秘密鍵を、調査資料へそのまま載せない

管理者は、フォームの連携設定と、キーの管理元、方式、対象ドメインが一致するかを確認します。本番と検証環境、旧ドメインと現行ドメイン、利用する製品が違うキーを混ぜていないかを見ます。設定画面でキーが入っていることだけでは、正しい組み合わせを使っている証拠になりません。

サイト側へ出すキーとサーバー側で使う秘密情報は役割が異なります。問い合わせ本文、スクリーンショット、公開ログ、記事原稿へ秘密鍵を貼らないでください。調査記録には、どの管理元のどの設定を照合したか、値が一致したかという結果を残せば足りる場合があります。

プラグインが連携を管理しているなら、独自コードを足す前に、その製品の現行の公式手順と対応方式を確かめます。複数のプラグインやテーマが同じフォームへ認証を追加していないかも確認します。製品名が同じでも、版や連携方式が違えば設定欄が異なることがあります。

キーを作り直す、対象ドメインを増やす、連携を切り替える作業は、管理者と影響を確認して行います。認証が通らないからという理由で対象の制限を広げたり、仕組み全体を外したりすることを、最初の共通手順にはしません。現在値と戻し方を用意してから限定して変更します。

3. 認証の表示とJavaScriptの読込を確認する

画面があることと、必要な処理が動くことを分ける

制作側は、対象ページで必要なスクリプトが取得されているか、実行順序やコールバックのエラーがないかを確認します。v2の公式資料は表示方法と読込順を説明しています。キャッシュ・遅延読込・コードの結合などが関わる場合も、実際の応答とエラーを見て、変更した部品との関係を調べます。

同意を求める仕組みやブラウザーの制限によって、外部スクリプトが読み込まれない場合も確認候補です。その場合、同意前に必ず読み込ませる設定へ変えると決めつけず、利用中の方針、案内、フォームの動作を担当者と照合します。CSP等の制限を広く解除する作業へも勝手に広げません。

v2では、応答の期限切れや読込エラーに対応するコールバックが公式に用意されています。期限切れのまま送信ボタンを押せない、エラーが表示されず待ち続ける場合は、利用者へ状況と次の操作を伝える処理も確認します。表示が崩れて操作できない場合は、PCとスマートフォンの実際の幅で試します。

調査で残すのは、対象URL、スクリプトの取得結果、エラーの場所、再現する条件です。顧客の問い合わせ本文や秘密情報を含んだ通信を、そのまま共有しないでください。単に再読み込みで直った場合も、原因が確定したという報告にはしません。

4. トークンの期限と、送るタイミングを確認する

入力開始時の認証結果を、ずっと使い回さない

Googleの応答検証の説明では、利用者の応答トークンは2分の有効期間があり、検証は一度だけとされています。ページを開いた時点で取得し、長い入力の後に古いトークンを送る、同じトークンを再送する、といった構成は確認候補になります。

v3の公式資料も、保護する操作に合わせて実行し、得たトークンを速やかにサーバーへ送る説明をしています。フォームの入力に時間がかかることは通常の利用として考慮します。利用者に毎回すばやく入力させる案内で済ませず、発行と送信のタイミングを実装側で照合してください。

サーバーの検証で timeout-or-duplicate が返る場合、公式説明では期限切れまたは既使用の応答を示します。これだけでどちらだったか確定はしないため、発行・送信・検証の時点と、再送の有無を照らし合わせます。トークンの中身を広く記録せず、必要な状態と識別方法を決めます。

失敗後に再試行させる場合は、新しい認証と送信へ進めるか、入力内容が失われないかも確認します。同じ問い合わせが既に受け付けられている可能性があるなら、再送を促す前に受付記録を照合します。認証の再試行と、問い合わせそのものの二重受付対策は別の処理です。

5. サーバー側の検証と、フォームの受付を照合する

ブラウザーで認証できても、サーバーへ応答が渡らない、検証先への通信が失敗する、設定が一致しない、結果を正しく扱えない、といった場合があります。制作側は、受け取った応答の有無、検証の結果、フォームの受付処理へ進んだかを分けて確認します。

v2/v3の応答検証の資料では、成功・失敗とエラーコード、ホスト名などの項目が説明されています。v3ではアクション名などの追加項目もあり、期待した操作と一致するかの確認が必要です。Cloud側の別方式を使う場合に、同じ検証先や結果形式をそのまま当てはめないでください。

v3のスコアは、それ自体を問い合わせの正当性の確定判定にしません。公式資料もサイトの利用状況を見て判断する考え方を説明しています。正常な相談が拒否されたから一律に基準を下げる、すべて受け付ける、といった変更へ直結させず、対象の操作と受付方針、誤判定への対応を確認します。

6. エラーの案内と、代わりの相談方法を用意する

認証に失敗した利用者が、入力を直すべきか、接続を確かめるべきか、時間を置くべきか分からない画面では、相談を続けにくくなります。実際の失敗段階に合わせて、再試行できる操作と、入力が残るかを伝えます。エラーが出たのに送信済みと見せる案内は避けてください。

電話や別の窓口を案内する場合は、現在受け付けている連絡方法と対応範囲へ合わせます。読者を助けるためという理由で、未確認の電話対応時間や無料対応を追加しません。障害時だけ別の受付を使うなら、その案内を誰が出し、通常状態へ戻すかも決めます。

フォームの項目や入力エラーの全体を見直したい場合は、認証固有の調査と分けて考えます。今回の目的が認証後に送れない不具合なら、先に該当する処理を調べ、フォーム全体の作り直しやデザイン変更を必須にしません。正常な相談を受け付けられる状態と、スパムへの対応の両方を確認します。

7. 正常・長時間入力・再試行を、合意した方法で試す

試験前に、検証環境、試験の入力、受信先、受付記録を見る担当、公開後の確認方法を決めます。本番で本物の顧客情報を使ったり、実際の担当へ無断で大量送信したりしません。公開フォームの閲覧だけで、認証から実受信まで検証済みとは扱わないでください。

変更前には、対象の設定と実装、利用中のキーの管理元、原本、影響と戻し方を保存します。秘密鍵の取り扱いとバックアップの閲覧範囲も管理します。公開直前に別担当者の更新が入ったら、差分を確認してから反映します。

試験結果は、確認した条件と残る未確認を並べて引き継ぎます。送信できた一回の確認を、すべての環境で誤判定がない保証にはしません。受付件数、スパム、実相談、対応負担を別々に観察し、導入した事実だけを成果として報告しないことも大切です。

8. Acquaへは方式と症状、必要な調査範囲を伝える

自社の管理者が設定と処理を把握し、原因の確認と限定修正、実受付の試験まで行えるなら、その記録を残して運用できます。表示元や検証処理が分からない、WordPressの連携やエラー表示を直したい場合に、対象を絞って調査を依頼します。

企業担当者はWeb制作・運用の案内、制作会社はWordPress実装・既存修正の受託案内から、必要な実務を相談できます。Acquaが担当する範囲は、フォームと連携の調査、必要な実装修正、合意した試験と公開検収、更新手順の引継ぎなどを個別に決めます。Googleや外部製品の仕様変更への対応や、すべてのスパムの排除を保証する意味ではありません。

相談窓口には、対象URL、分かる範囲の方式・製品、症状、発生条件、最近変えたことをお知らせください。秘密鍵、パスワード、実際の問い合わせ内容は初回の文章へ貼らず、調査に必要な共有方法と権限を別に確認します。

支援後の目標は、正常な相談が合意した経路で受け付けられ、失敗時の利用者が次の操作を選べ、担当者が認証・受付・通知を分けて調べられることです。設定の保存と実際の受付を区別し、原本・確認結果・残る条件・戻し方を引き継ぎます。

一次資料確認：2026年10月15日。公式のv2/v3の仕様と、本記事の調査・依頼用の確認表を区別しています。実装・試験・成果を実施済みと示す記事ではありません。