invisible reCAPTCHAは送信buttonへ付ける前にserver側の検証と受付記録を決める

invisible reCAPTCHAは、利用者へ常にcheckboxを操作させず、問い合わせformなどの操作に合わせて確認を行う仕組みです。送信buttonにscriptを付ければspam対策が終わるわけではありません。browserで得たresponseをserver側でも確認し、確認できなかった送信をどう扱うか、正しく受け付けた問い合わせをどこへ残すかを決めてから使います。

問い合わせformの目的は、botを弾くことではなく、必要な人からの連絡を受け、担当者が内容を確認して返答できるようにすることです。spamが多いからといって、正当な利用者の送信を止める設定を強くすれば、問い合わせの入口を狭くします。対策の導入と、受け付けられなかった人への案内を同じ作業として考えます。

buttonの操作とserverの判定を分ける

Googleのinvisible reCAPTCHAは、既存のbuttonへ結び付ける方法と、JavaScriptから呼び出す方法を用意しています。利用者が送信buttonを押したときに確認を行い、完了後のcallbackからformを送信する構成にできます。この流れは、browser上での操作を整えるものです。

browser側でtokenを得たことだけでは、問い合わせを受け付けてよい根拠になりません。formを受け取るserverは、secret keyを使ってtokenをverify serviceへ送信し、responseを確認します。site keyはpageへ出すための値ですが、secret keyはbrowserのHTML、JavaScript、theme fileへ出しません。keyを入力した人、scriptを追加した人、server側の設定を変更した人を分けるなら、secret keyを誰が保管するかも決めます。

説明用の仮例として、資料請求formに氏名、メールaddress、問い合わせ内容を入れる場合を考えます。buttonを押してtokenが返り、formがserverへ届いたあとで、serverがtokenを確認します。確認結果が正しくないなら、受付メールを送る前に入力画面へ戻し、もう一度試す方法か別の連絡先を示します。確認が通ったときには、問い合わせ内容を受付記録へ残し、担当者へ通知します。reCAPTCHAの確認と、メールが届いたこと、担当者が返答したことは別の結果です。

送信を止める条件を先に決める

invisible reCAPTCHAを入れると、通常は利用者の操作を少なくしながら確認できます。それでも、確認画面が出る、scriptを読めない、networkが不安定、verify serviceへ接続できないといった場合があります。失敗時にformを何も表示せず止めると、利用者は送信できたのか分かりません。

導入前に、少なくとも三つの結果を決めます。第一に、tokenを確認できて正常に受け付けた場合です。送信完了画面と、受け付けた内容または問い合わせ番号を表示するかを決めます。第二に、browser側の確認を完了できなかった場合です。入力内容を消さずに再試行できるか、電話やメールの連絡先を示すかを決めます。第三に、server側の確認が失敗した場合です。外部serviceの一時的な問題と決めつけず、送信記録を残すか、あとで確認する窓口を置くかを決めます。

ここで「怪しい送信はすべて捨てる」とだけ決めると、判断の理由が残りません。問い合わせが多いsiteほど、拒否した時刻、URL、form名、確認結果を調べられる記録が必要です。入力内容を必要以上にlogへ複製しないよう注意しながら、担当者が再現できる情報を選びます。spamを減らす作業と、個人情報を保存する作業も別に考えます。

formの見た目を変えても受付の経路を確認する

invisible reCAPTCHAは画面上のcheckboxが目立たないため、導入後に何が動いているかを見失いやすくなります。公開前には、利用者の画面、browserの送信、serverのverify、受付記録、通知メールを順に確認します。管理画面でpluginを有効にしたことや、buttonが表示されたことだけを完了にしません。

WordPressでform pluginを使う場合も、plugin名だけで判断しません。site keyをどこへ入力するか、secret keyをどこへ保存するか、tokenをどの処理でverifyするか、失敗時のmessageをどこで変えるかを確認します。themeの独自formとpluginのformで設定が別なら、片方だけが保護されている場合があります。公開しているform URLを一覧にし、資料請求、採用応募、予約、注文など、同じ受付経路を使うものを一つずつ試します。

送信後の画面が「完了」と表示されても、受信側のmail boxに届いたかは別に確認します。serverでtokenの確認が通ったことは、メール配送や担当者の対応を保証しません。問い合わせを受ける目的なら、確認用の内容で一件送信し、受付記録、通知、返信先を確かめます。テストに実在の顧客dataを使わず、誰が確認したかを残します。

公開後は拒否された送信だけを数えない

spamが減ったことは、formが適切に機能している証拠の一部にすぎません。導入後には、正常な問い合わせ数、確認できなかった送信、利用者からの「送れない」という連絡、対応に掛かった時間を分けて見ます。問い合わせ数が減ったときも、営業の状況だけでなくformの送信経路を確認します。

変更を委託する場合は、依頼書に「reCAPTCHAを付ける」とだけ書きません。対象formのURL、site keyの登録先、secret keyの保管者、verifyするserver側の処理、失敗時の表示、通知メール、公開後に見る記録を並べます。この内容が決まれば、作業者が変わっても、何を確認すれば受付が動いているかを追えます。

最初の一手は、問い合わせformを一つ選び、利用者がbuttonを押してから担当者が内容を読むまでの経路を書き出すことです。その経路のどこでreCAPTCHAを確認し、どこに受付記録を残し、失敗時に何を案内するかを決めます。画面の操作を減らすことと、必要な問い合わせを確実に扱うことを一緒に確認します。