reCAPTCHA v3とv2の違い・選択と設計ガイド

概要

Google reCAPTCHA はボットによる不正アクセスやスパムから Web サービスを守るための代表的な仕組みです。本記事では reCAPTCHA v3 と v2 の仕組みの違い、実装時に選べる構成パターン、ユーザー体験とセキュリティの観点からの選択指針、そして両バージョンを組み合わせたフォールバック構成について整理します。

バージョン別の基本的な違い

観点	reCAPTCHA v3	reCAPTCHA v2
判定方式	スコアベース (0.0〜1.0) の「人間らしさ」評価。閾値設定が必要	チャレンジベース。チェックボックスや画像選択など、ユーザー操作を伴う
UI 表示	原則 UI なし。バッジ表示のみ (非表示オプションあり)	チェックボックス (I'm not a robot) もしくは invisible (UI 最小)
対応するリクエスト	アクション単位で複数ページに導入可	基本的にフォーム送信など特定のエンドポイント
スパム耐性調整	スコア閾値やアクション毎の監視で柔軟に調整	チャレンジの難易度は自動調整だが開発者による細かな調整は難しい
実装難易度	スコアに応じた分岐ロジックを設計する必要がある	チャレンジ結果を検証するシンプルなフロー
キー	v3 専用サイトキー・シークレットキー	v2 専用サイトキー・シークレットキー (v3 と共通利用不可)

注意: reCAPTCHA v3 と v2 ではサイトキー・シークレットキーが別々に発行されます。v3 用キーを v2 実装に流用することはできないため、導入時にそれぞれのキー管理を行う必要があります。

reCAPTCHA v3 の実装パターンと設計の考え方

スコアベース判定の基本

1. クライアント側で grecaptcha.execute(siteKey, { action: 'login' }) のようにアクションを指定してトークンを取得。
2. サーバー側でトークンを検証し、レスポンスに含まれる score (0.0〜1.0) や action を参照。
3. 定義した閾値と比較し、分岐した処理を実行。

典型的な分岐例

• 高スコア (例: 0.7 以上): 通常処理をそのまま実施。
• 中スコア (例: 0.3〜0.7): ワンタイムパスワードやメール認証など追加ステップを要求。
• 低スコア (例: 0.3 未満): 処理をブロックし、再試行を促す、もしくは v2 チャレンジへ誘導。

スコアの閾値はサイト特性に応じて A/B テストやログ分析で調整することが推奨です。例えばコメント投稿や問い合わせフォームなど被害許容度が低いアクションは閾値を高めに、ログインフォームはユーザー体験を優先して低めに設定するといったチューニングが考えられます。

アクション設計のポイント

• アクション名はページや操作ごとに固有にする: login, signup, contact_submit など。サーバー側で期待したアクション名と一致するかを確認することで、スコア偽装の検知に役立ちます。
• バッジの扱いを設計に組み込む: v3 ではバッジを表示するのが基本です。UIデザイン上どうしても非表示にしたい場合は、利用規約に従い対応するリンクをページに掲載する必要があります。
• スコア監視の仕組みを用意する: 日次でログを収集し、閾値付近のトラフィック量や不正と判断されたアクセス数をモニタリングすると、適切な閾値維持に役立ちます。

reCAPTCHA v2 の実装パターンとユーザー体験

チェックボックス (I'm not a robot)

• ユーザー体験: 通常はチェックを入れるだけで通過。疑わしい場合のみ追加の画像選択などのチャレンジが表示されます。
• 適用場面: 問い合わせフォーム、会員登録フォームなど、フォーム数が限定的でユーザー操作を許容できる場面。
• 実装ポイント: data-sitekey を設定した <div class="g-recaptcha"> を配置し、フォーム送信時に生成されたトークンをサーバー検証します。

Invisible reCAPTCHA

• ユーザー体験: 明示的なチェック操作は不要。ボタン押下時などに自動で判定し、疑わしい場合のみチャレンジが表示されます。
• 適用場面: UX を崩さずにスパム対策をしたいフォーム全般。ただしチャレンジ発生時にはモーダルが出るため、UI テストが必要です。
• 実装ポイント: 対象ボタンに data-sitekey と data-callback を設定し、コールバック内でフォーム送信を実行します。

サーバー側の検証

v2 でもクライアントで取得した g-recaptcha-response をサーバーへ送信し、https://www.google.com/recaptcha/api/siteverify エンドポイントでシークレットキーと共に検証します。レスポンスの success や error-codes を確認し、失敗時はユーザーへリトライを促します。

要件別の選択ガイド

要件・状況	推奨構成	理由
ユーザー体験を最優先し、UI に制約を加えたくない	v3 単独	バッジ以外 UI 変化がなく、スコアに応じた柔軟な追加認証を設計できる
スパム被害が深刻で、確実に人間確認をしたい	v2 チェックボックス	チャレンジによる確実な判定が可能。ユーザー操作は増えるが防御力が高い
モバイル端末などで操作負荷を下げたい	v2 Invisible または v3	通常操作はシームレスだが、疑わしいケースのみチャレンジが発生
スコア判定だけでは不安で最終確認を強化したい	v3 + v2 (フォールバック)	v3 で低スコア時のみ v2 チャレンジへ遷移させることで UX と安全性のバランスが取れる
社内システムや限定公開サイトで一定のユーザーしか利用しない	v3 低閾値 もしくは v2 Invisible	誤判定による業務影響を抑えられる

v3 と v2 を併用するフォールバック構成

1. 通常フロー: ページロード時に v3 を実行し、スコアが閾値以上であればそのまま処理続行。ユーザーはバッジ表示以外の変化を感じません。
2. 低スコア時の分岐: サーバーがスコアを評価し、閾値未満の場合に v2 へ誘導。
   • UI パターン A: 同一ページで v2 チェックボックスを表示し、ユーザーに明示的な操作を求める。
   • UI パターン B: 送信ボタン押下時に invisible v2 を発動し、必要な場合のみチャレンジを挟む。
3. ユーザー体験: 通常ユーザーは v3 のみで完了し、疑わしいトラフィック時のみ v2 の追加操作が発生。これにより、ボットには強い対策を維持しながら人間ユーザーの手間を最小化できます。

フォールバック構成を採用する場合、v3 と v2 のそれぞれに対して専用のサイトキーとシークレットキーを取得・管理する必要があります。サーバー側でどちらのバージョンのトークンを検証しているかを明確にし、ログの区別も付けましょう。

実装チェックリスト

• v3 と v2 で必要なサイトキー・シークレットキーを別々に取得したか。
• 利用規約に沿って reCAPTCHA バッジや必要な文言を表示しているか。
• v3 のスコア閾値をアクション単位で設定し、ログから定期的に見直しているか。
• v2 のチャレンジ失敗時のユーザー通知や再試行導線を用意したか。
• フォールバック構成の場合、v3 低スコア → v2 チャレンジの遷移が UX 的に問題ないかテストしたか。
• サーバー側で reCAPTCHA API の検証結果に応じたレスポンス・エラーハンドリングを実装したか。

まとめ

• reCAPTCHA v3 はスコアベース判定により UI に影響を与えず導入でき、閾値設計が鍵となります。
• reCAPTCHA v2 はユーザー操作を伴いますが、防御力が高く理解しやすい仕組みです。チェックボックスと invisible の 2 パターンを用途に応じて使い分けます。
• 要件に応じたパターン選択とフォールバック構成により、ユーザー体験とセキュリティのバランスを最適化できます。
• v3 と v2 を併用する場合でも、それぞれ専用のキー管理と検証ロジックを忘れずに設計しましょう。