reCAPTCHA
よみ: リキャプチャ
Google が提供する、悪意のあるボット(自動プログラム)によるスパム攻撃を防ぐためのセキュリティサービス。フォーム(メールフォーム)送信時などに用いられ、主に「v2」と「v3」の 2 種類が現役で使われている。
- v2：フォーム送信時に「私はロボットではありません」のチェックや、指定された画像を選ぶクイズ(画像認証)を表示する従来型。
- v3：ユーザーに一切の認証操作を求めず、バックグラウンドでの行動履歴から人間かボットかを自動判定する透明なスコア方式。
大規模サイト向けの上位版「reCAPTCHA Enterprise」は有料になる。
運用の要点：設定キーの管理と「v2/v3」の使い分け
reCAPTCHA を動かすには、Google から発行される「サイトキー(公開用)」と「シークレットキー(秘密用)」の 2 つが必要。実装にあたっては、以下の論点をクリアにする必要がある。
- UX と確実性のトレードオフ：ユーザーに手間をかけさせない UX(UI / UX)(ユーザー体験)を重視するなら「v3」、確実にボットを防ぐことを最優先するなら「v2」を選ぶ。
- v3 の閾値(しきいち)設計：v3 の場合、ボットと判定するボーダーライン(閾値)を 0.0〜1.0 で設定する(0.5 が一般的だが、スパムが多い業種は 0.7 など厳しめにする)。
- プライバシー法規制への対応：reCAPTCHA は判定のために Google へユーザーデータを送信するため、ヨーロッパの GDPRや日本の改正個人情報保護法における「Cookie同意バナー」の対象となる。
現場でよくある「落とし穴」
セキュリティ対策のつもりが、実装ミスで「誰も問い合わせできないフォーム」を生み出す大事故が頻発する。
- 正規ユーザーを弾いてしまう事故：v3 の閾値を厳しくしすぎた結果、本物のお客さんまでボット扱いしてブロックしてしまい、公開後に「問い合わせがパッタリ来なくなった!」と大慌てする(必ず実機で動作テスト(公開前チェック)を行うこと)。
- 実装の甘さによるセキュリティ崩壊：クライアント側(ブラウザの見た目)だけで判定を終わらせ、サーバ側(システム裏側)でのスコア検証を実装しなかった結果、悪意のあるプログラムにあっさり突破され、数万件のスパムメールが届いてサーバがパンクする。
- キーの管理ミスと漏洩：本番環境とテスト環境で別々のキーを設定し忘れ、本番でフォームが送信できなくなる。また、絶対に他人に知られてはいけない「シークレットキー」を HTML ソースコードに直書きしてしまい、誰でも不正アクセスできる状態にしてしまう。
- 法令違反リスク：ユーザーから Cookie の同意を得る前に reCAPTCHA を読み込ませて稼働させてしまい、法令違反状態になる。
言葉をよく利用する人
- コーダー / フロントエンドエンジニア
- バックエンドエンジニア
- Web 担当者(発注側)
- 情シス
- 法務 / 契約担当
会話上での使用例
フォームからの問い合わせが急に減った原因を探る場面
-
カスタマーサポート
問い合わせが先週からぱったり減ってしまっているんです。
-
Web 担当者
reCAPTCHA の判定を厳しくした影響かもしれません。正規のユーザーまで弾かれていないか、過去一ヶ月のスコアの分布を確認します。いったん閾値を下げて様子を見つつ、フォームの送信ログも合わせて見てみましょう。
-
カスタマーサポート
お願いします。送信できなかった人がいないか、こちらも問い合わせ履歴を確認します。
スパム対策と Cookie 同意の関係を法務と整理する場面
-
法務 / 契約担当
reCAPTCHA は Google にデータが送られる以上、Cookie 同意の対象になりますよね。
-
Web 担当者
おっしゃる通りで、同意を取る前に読み込むのは原則 NG です。フォームのページだけ先に同意を取ってから読み込む流れにするか、あるいは別のスパム対策を併用する設計に変えます。代替案を整理してお持ちしますね。
-
法務 / 契約担当
では両案を比較したうえで、リスクの低いほうで進めましょう。