はじめに
reCAPTCHA v2フォールバックは、v3のスコア判定だけでは判断が難しいトラフィックに対して追加の判定軸を提供する仕組みです。
その実現手段としてreCAPTCHAの新しいキータイプであるポリシーベースのチャレンジキー(Policy-Based Challenge Keys)が2025/10/28にGAとなったので早速使ってみました。
release noteではGAであったものの、導入を検討していた11月末頃はコンソールや日本語の公式ドキュメント上ではまだREVIEWバッジがついている状態だったのでGoogleに問い合わせたところ
Release notesのとおり既に
GAであり、社内で修正に向けたチケットは上がっていたので今後修正が反映されていく。ドキュメントは日本語版だと反映までにラグがあるため、英語版でご確認ください。
とのことでした。12/8現在は日本語ドキュメントおよびコンソールからもREVIEWバッジは消えています。
本記事はv2 fallbackおよびその手段としてreCAPTCHA Policy-Based challenge Keyの導入にあたって考慮した点についてまとめます。
詳細な導入方法や設定等は公式ドキュメントに記載されているので割愛します。
reCAPTCHA v2 フォールバックとは
reCAPTCHA v3はスコアベース（0.0〜1.0）で人間らしさを判定しますが、v2はユーザによる操作（横断歩道を選択させられるアレ）の結果によって判定します。
v2 fallbackとはv3でのスコア判定に加えて低評価の場合にv2の追加チャレンジを求めることでUXと安全性のバランスを行うものです。
例えば以下のようなしきい値の設計が考えられます。
- 0.5以上：成功。UX上は特に変化なくアクションを実行
- 0.4以下：v2 fallbackによる追加判定のうえで実行
reCAPTCHA Policy-Based challenge Keyとは
これまでv2 fallbackを実現するにはv3に加えてv2用のサイトキーを別途取得したうえで、アプリケーション側にて分岐を実装する必要があったのですが、Policy-Based challenge Keyはひとつのキーでv2 fallbackをGoogle Cloudのコンソール上にて制御できるキータイプです。
さらにAction（自由に設定できるユーザー操作の識別子）毎にしきい値を設定することが可能であり、サービス側は対象のアクションの特性ごとに柔軟な設定が可能です。
既にScore-based keyを採用しているサービスに対してPolicy-Based challenge Keyを導入してみたところ、ほぼ追加開発なく簡単にv2 fallbackをインストールすることが出来たのですが、いくつか留意した点があったので紹介します。
画像によるCAPTCHA判定における留意事項
そもそもv2を追加認証とすることのリスクについて。これはGoogle公式ドキュメントでも記載されていることですが、画像によるCAPTCHA判定は経験の浅い攻撃者には有効ですが、逆をいうとそうでない攻撃者に対しては突破されてしまうリスクについて示唆されています。
CAPTCHA チャレンジなどの追加ステップはユーザーの認証負担を増やす側面もありますが、経験の浅い攻撃者の攻撃を阻止する効果があります。
AIでリアルタイムに物体を検出できる「YOLO」（You only look once）を使用。画像分類に照準を絞って調整した「YOLOv8」を使い、実際のユーザーの行動に近づけた環境でテストを行った。その結果、例えば自転車は89％、橋は89％、バスは97％、消火栓は100％など、高い精度で写真を識別することに成功した。
reCAPTCHA v2には評価に応じてチャレンジの難易度を調整する機能が用意されているとのことですが、v3でのスコアが0.0〜0.1等の限りなくbotと判定されたトランザクションに対して、結果v2チャレンジが通れば処理が進められるとすることは逆を言うと一部の攻撃者に対しては隙を与えているとも言えます。
v3低評価トランザクションへの対策
そこで、v3で限りなくbotと判定されたであろう0.0-0.1周辺スコアに対して、v2チャレンジが成功したとしてもNG判定とする処理（以下、「low cut filter」）を独自で用意しました。
ただ、reCAPTCHA Policy-Based challenge Keyは一つのKEYでv3と同様のシーケンスにて実装できる一方で、アプリケーション側にて結果判定する処理がv2追加チャレンジ後となってしまう為、「画像CAPTCHAに成功したのにbot判定されてしまう」というどうしても違和感のあるUXにはなってしまいます。
なので、low cut filterはv2 fallbackと同様にアクションごとに設定可能とした上で、各アクション毎にスコア分布と理由コードをチェックして特にセキュリティのバランスを重視する要所にのみ導入しています。
reCAPTCHA KEYの「ならし運転時」のv3スコア評価の留意事項
これはv2 fallbackに限った話ではないですが、reCAPTCHAキーを新たに作成して利用する際、reCAPTCHAはしばらく充分な評価情報が不足して正しい評価情報を返却しない期間があります。
具体的には導入初期段階ではほとんどのトラフィックにて下記のような評価を返却することを確認しました。
- スコア : 0.9固定
- 理由コード : LOW_CONFIDENCE_SCORE(このサイトから受信したトラフィック量が過少であるため、品質リスク分析を生成できません)
上述したlow cut filterはv2 fallbackが返却されたスコアにて判定するので、固定値だとlow cut filter が動作しません。
検証してみたところ１-２日程度経過すればLOW_CONFIDENCE_SCOREが返却されなくなり正しい評価がレスポンスとして返却されるようになるようでしたので、ウォームアップとしてstaging環境にて本番用のキーを動作させてLOW_CONFIDENCE_SCOREが返却されなくなったことを確認してから、本番環境に本番用のキーを反映させました。
ここで「ならし運転時」と定義しているものは、ほとんどのトラフィックがLOW_CONFIDENCE_SCOREとして固定スコアが返却される、新規キーを導入した直後の期間のことを指しています。
ウォームアップが終わってもreCAPTCHAはサイト上の実際のトラフィックをモニタリングすることで学習していきますので、
実装から 7 日以内にステージング環境で得られたスコアは、長期にわたって本番環境で得られたスコアと異なる場合があります
とあるように、導入したサービス側もgoogle cloudのコンソール上等で定期的にスコア分布等を参照し、アクション毎のスコアしきい値をチューニングすることが肝要です。
終わりに
reCAPTCHA v2 fallbackは、セキュリティとユーザー体験のバランスを取るうえで有効な選択肢ですが、留意事項としてあげた画像CAPTCHAの突破リスクをどう扱うかは、その他の対策手段も合わせて対象のサービスごとの判断が求められる部分だと思います。
Policy-Based challenge Keyの登場により簡単に導入ができるようになったことはもちろんですが、結局のところアクション毎のしきい値の設計が鍵であって導入後においても定期的なスコア分布やログのチェック、チューニングが重要であり、それがGoogle Cloudコンソール上で完結できる恩恵は結構大きいと思います。