reCAPTCHA Enterprise

解決する課題

公開アプリのログイン、新規登録、問い合わせ、決済といった入口は、絶えずボットや自動化スクリプトによる不正にさらされます。クレデンシャルスタッフィング、スパム投稿、在庫の買い占め、不正アカウント作成などです。従来の「歪んだ文字を読ませる CAPTCHA」はユーザーの手を止め、離脱を招きます。reCAPTCHA Enterprise は、ユーザー操作を極力止めずにリクエストのリスクをスコア化し、怪しいものだけに対処できるようにします。

• ログイン・登録・決済を自動化された不正から守りたいが、正規ユーザーの体験は損ねたくない
• パズルやチェックボックスで離脱率を上げずにボットを見分けたい
• アカウント乗っ取り（ATO） や不正決済を、振る舞いの異常から検知したい
• 検知の根拠や処理結果を可視化・分析し、しきい値を継続的に調整したい
• Web だけでなく モバイルアプリでも同じ仕組みで保護したい

主要概念と用語

• スコア: 操作がどれだけ人間らしいかを示す 0.0〜1.0 の値。1.0 に近いほど正規ユーザーらしく、0.0 に近いほどボットらしい。サイト側がしきい値を決めて使う
• アセスメント（評価）: フロントで取得したトークンをバックエンドが検証し、スコアやリスク判定を受け取る一連のリクエスト
• トークン: フロントエンドの reCAPTCHA が発行する一時的な文字列。サーバー側で検証して初めて評価結果が得られる
• キー（サイトキー）: 保護対象のサイトやアプリに紐づく識別子。スコアベースか、チェックボックス型かなど挙動を決める
• アクション名: login signup checkout のように、どの操作を評価しているかを示すラベル。アクション別に傾向を分析できる
• スコアベースキー（v3 相当）: ユーザー操作を要求せず、裏側で振る舞いを観測してスコアだけを返す方式
• チェックボックス型キー（v2 相当）: 「私はロボットではありません」を表示し、必要に応じてチャレンジを出す方式
• アカウント乗っ取り対策（Account Defender 系）: 過去の振る舞いと突き合わせ、乗っ取りや不正の疑いを示す機能群
• WAF 連携: Cloud Armor などと組み合わせ、エッジでスコアに基づくアクションを実行する利用形態

仕様・制限・クォータ

• スコアの範囲: 評価結果は 0.0〜1.0 の連続値。「ボットかどうか」を二値で返すのではなく、サイト側がしきい値で判断する
• 検証は必ずサーバー側: フロントで得たトークンは、バックエンドからアセスメント API を呼んで検証する。クライアントだけで完結させてはならない
• トークンの有効期間: 発行されたトークンは短時間で失効する。取得後すみやかに検証する前提
• 対応プラットフォーム: Web に加え、Android / iOS のモバイル SDK を提供する
• キーの種別: スコアベース、チェックボックス型、モバイルなど用途別にキーを使い分ける
• クォータ: アセスメント数などに上限があり、超過分や上位機能は課金対象になる。具体値はプロジェクトやエディションで変わるため、必要に応じて引き上げ申請する
• エディション差: 基本のスコアリングに加え、アカウント乗っ取り対策や不正決済対策などの高度機能は上位の利用形態で提供される

内部の仕組み

reCAPTCHA Enterprise は、フロントエンドで収集した振る舞いのシグナルを Google 側で解析し、リスクをスコアとして返します。重要なのは、判定が必ず「フロントでのトークン取得」と「サーバー側での検証」の二段構えになっている点です。

• フロントの JavaScript / モバイル SDK が、操作のパターンなどからトークンを生成する
• バックエンドはそのトークンをアセスメント API に渡し、スコア・アクション名の一致・リスク理由を受け取る
• スコアは Google が広範なシグナルから機械学習で算出するため、サイト側に判定ロジックを実装する必要がない
• サイトは受け取ったスコアをしきい値と比較し、許可・追加認証（MFA など）・拒否を自分で決める
• アクション名を付与しておくと、login と checkout で別々に傾向を分析・調整できる

設計パターン / ベストプラクティス

• アクションごとにキー/ラベルを分ける: login signup checkout を区別し、それぞれに合ったしきい値を設定する
• しきい値は二者択一にしない: 高スコアは即許可、低スコアは拒否、中間は**追加認証（MFA・メール確認）**に回す三段構えが安全
• 段階導入で調整する: まずスコアを記録するだけで運用し、正規ユーザーの分布を見てからブロックを有効化する
• 多層防御の一部に組み込む: reCAPTCHA だけに頼らず、レート制限や WAF、サーバー側の入力検証と組み合わせる
• モバイルも同じ方針で: Web とモバイルでアクションとしきい値の考え方を揃え、運用を一本化する
• アクション名を必ず付ける: 後からの分析・調整の精度が大きく変わるため、評価ごとに意味のあるアクション名を渡す

運用・監視

• 管理コンソールのメトリクスで、アクション別のスコア分布や評価数、ボット判定の傾向を確認する
• スコアの分布が想定とずれたら、しきい値を見直す。正規ユーザーが弾かれていないかをアクション別に追う
• Cloud Monitoring / Cloud Logging と組み合わせ、アセスメント数の急増や異常なアクセスパターンをアラート化する
• 新しい不正パターンが出たら、追加認証へ回す中間帯のしきい値を調整して対応する
• アカウント乗っ取り対策を使う場合は、提示されるリスク理由を起点に、追加認証やブロックの運用ルールを整える

コスト

課金は基本的に「評価（アセスメント）の回数」に対する従量で、無料枠を超えた分や、アカウント乗っ取り対策・不正決済対策などの高度機能に費用が乗ります。スコアリングの基本利用と高度な不正対策で単価が異なる点を押さえます。

セキュリティ

• スコアの検証は必ずサーバー側で行い、クライアントの自己申告を信用しない
• アクション名の一致を検証し、別アクションのトークン使い回しを防ぐ
• 最小限の入口だけでなく重要導線（ログイン・決済）に確実に適用し、抜け道を作らない
• reCAPTCHA は防御の一層と位置づけ、レート制限・WAF・入力検証と多層で組む
• 評価結果や設定変更は Cloud Audit Logs / Cloud Logging で監査し、しきい値はコードで管理して変更履歴を残す

関連サービス・比較

ボットや不正の防御では、エッジで攻撃を遮断する Google Cloud Armor と役割が補完関係にあります。Cloud Armor はロードバランサのエッジで WAF/レート制限を行い、reCAPTCHA Enterprise はアプリの操作単位でリスクをスコア化します。両者を組み合わせると、エッジとアプリの二層でボット対策を強化できます。

ハンズオン / CLI例

# スコアベースのキーを作成（Web サイト向け）
gcloud recaptcha keys create \
  --display-name "web-frontend-score" \
  --web \
  --integration-type SCORE \
  --domains "example.com"

# プロジェクト内のキー一覧を確認
gcloud recaptcha keys list

# 特定キーの設定を表示
gcloud recaptcha keys describe KEY_ID

# Android アプリ向けのキーを作成
gcloud recaptcha keys create \
  --display-name "android-app" \
  --android \
  --package-names "com.example.app"