reCAPTCHA v3は2018年にリリースされて以来、ユーザーに挑戦（チャレンジ）を表示せずにリスクを評価する「不可視」な防御層として進化し続けています。2026年現在、reCAPTCHA v3のスコアリング仕組みを理解することは、QA自動化エンジニアやアンチボット研究者にとって必須の知識です。本記事では、reCAPTCHA v3のスコアがどのように計算され、なぜデータセンターIPがスコアを崩すのか、そして正当な自動化がいかにして合格スコアを獲得できるかを技術的に深掘りします。
reCAPTCHA v3スコアリングの仕組み：0.0〜1.0の連続リスクスコア
reCAPTCHA v3の中核は、grecaptcha.execute()を呼び出すたびに返される0.0〜1.0の連続リスクスコアです。スコアは1.0に近いほど「人間らしい」、0.0に近いほど「ボットらしい」と判定されます。Googleはスコアを0.1刻みの11段階のバケットに分類し、サイト運営者が柔軟なしきい値を設定できるようにしています。
一般的なサイトのしきい値は以下のパターンに従います。
- ブロック（score < 0.3）：リスクが高く、リクエストを拒否またはCAPTCHAチャレンジを強制
- チャレンジ（0.3 ≤ score ≤ 0.6）：追加検証（画像選択やメール確認など）を要求
- 許可（score > 0.6）：人間らしいと判定し、リクエストを通過
ただし、しきい値はサイトごとに大きく異なります。金融系サイトは0.7以上を要求することもあれば、コンテンツサイトは0.3で足切りにすることもあります。reCAPTCHA v3スコアは「絶対値」ではなく、そのサイトのトラフィックパターンに対する相対評価である点に注意が必要です。
reCAPTCHA v3のスコアは単一のシグナルではなく、行動テレメトリ、ブラウザ特性、Cookieグラフ、IPレピュテーションを融合した機械学習モデルの出力です。行動が完璧でも、IPレピュテーションが低ければスコアは下がります。
Googleが融合する5つのシグナルカテゴリ
reCAPTCHA v3のスコアリングモデルは、複数のシグナルを融合して最終スコアを算出します。主要なシグナルカテゴリは以下の通りです。
1. 行動テレメトリ（マウス・スクロール・キーストローク）
ページ上のマウス移動軌跡、スクロール速度、キーストロークのタイミングパターンが収集されます。人間の操作には微細な「ゆらぎ」があり、直線的で機械的な動きは低スコアの要因になります。具体的には、マウス移動のベジエ曲線、イベント間隔の分散、クリック位置のばらつきが評価されます。
2. ページインタラクションテレメトリ
ページ滞在時間、フォーカスイベント、タブ切り替え、DOMインタラクションの順序などが測定されます。ページロード直後にフォーム送信が行われると、ボットの兆候とみなされます。
3. Google Cookieグラフ
GoogleはログインユーザーのCookie（__Secure-3PSIDなど）と広告Cookieを横断的に参照し、ユーザーの過去の行動パターンから信頼性を評価します。Googleアカウントにログインした状態でのアクセスは、一般的にスコア向上に寄与します。
4. ブラウザ特性とフィンガープリント
User-Agent、Canvas APIのレンダリング結果、WebGLパラメータ、navigatorプロパティ、TLSフィンガープリント（JA3/JA4）などが評価されます。ヘッドレスブラウザの特徴的なプロパティ（navigator.webdriver=trueなど）は即座に低スコアを引き起こします。詳細はMDN Web Docsを参照してください。
5. IPレピュテーション
IPアドレスのASN、過去のボット活動履歴、データセンターIPか住宅IPかが評価されます。このシグナルが、プロキシユーザーにとって最も重要な要素になります。GoogleのreCAPTCHA技術についてはGoogle reCAPTCHA v3公式ドキュメントで詳細が確認できます。
なぜデータセンターIPは行動が完璧でもスコアを崩すのか
ここが多くの自動化エンジニアが直面する壁です。どれだけ人間らしいマウス移動を再現しても、データセンターIP（AWS、GCP、DigitalOcean、HetznerなどのASN）からアクセスすると、reCAPTCHA v3のスコアは0.1〜0.3の範囲に押し下げられることが多いです。
理由は明確です。GoogleのIPレピュテーションシステムは、データセンターASNを「ボットが頻繁に使用するIPプール」としてフラグ付けします。過去の膨大なボット活動データに基づき、これらのIPからのトラフィックは事前に低信頼度としてスコアリングされます。行動シグナルが高くても、IPレピュテーションシグナルが低ければ、融合モデルの出力は引き下げられます。
| IPタイプ | 典型的なスコア範囲 | 理由 |
|---|---|---|
| 住宅プロキシ（Residential） | 0.5〜0.9 | ISP割り当てIPで人間トラフィックと同一プール |
| モバイルプロキシ（Mobile） | 0.6〜0.9 | キャリアIPで信頼度が高い |
| データセンタープロキシ | 0.1〜0.3 | ASNがボットフラグ付き |
| 直接アクセス（自宅ISP） | 0.7〜1.0 | Cookieグラフ＋ISP IPの相乗効果 |
したがって、reCAPTCHA v3スコアを0.6以上に維持するには、住宅プロキシが実質的に必須となります。ProxyHatの住宅プロキシは、実際のISPから割り当てられたIPプールを使用するため、IPレピュテーションシグナルをクリアできます。
サーバーサイドのトークン検証：siteverifyの仕組み
クライアント側でgrecaptcha.execute()が返すトークンは、サイトのバックエンドでGoogleのsiteverifyエンドポイントに送信して検証する必要があります。リクエストには以下のパラメータを含めます。
secret：サイトのシークレットキーresponse：クライアントから受け取ったトークンremoteip（オプション）：エンドユーザーのIP
siteverifyのレスポンスには、score、action、hostname、successフィールドが含まれます。ここで重要なのが、actionとhostnameの一致確認です。
クライアント側でgrecaptcha.execute(siteKey, {action: 'login'})として生成したトークンは、siteverifyレスポンスのactionフィールドが'login'と一致することを確認しなければなりません。これを怠ると、攻撃者が別のアクション用トークンを再利用してバイパスできてしまいます。同様に、hostnameフィールドが期待するドメインと一致することも検証が必要です。
import requests
# siteverifyの呼び出し例
resp = requests.post('https://www.google.com/recaptcha/api/siteverify', data={
'secret': 'YOUR_SECRET_KEY',
'response': token_from_client,
'remoteip': user_ip
})
result = resp.json()
if not result['success']:
raise Exception('reCAPTCHA verification failed')
if result['score'] < 0.5:
raise Exception('Score too low')
if result['action'] != 'login':
raise Exception('Action mismatch')
if result['hostname'] != 'example.com':
raise Exception('Hostname mismatch')ProxyHat住宅プロキシを使った正当な自動化の実装
reCAPTCHA v3のスコアを閾値以上に維持する正当なアプローチは、(1) 住宅プロキシでIPレピュテーションをクリア、(2) リアルブラウザ（PlaywrightやSelenium）でブラウザフィンガープリントを自然に保つ、(3) 人間らしいインタラクションテレメトリを生成する、という3層の組み合わせです。
ProxyHatの住宅プロキシは、ゲートウェイgate.proxyhat.comのポート8080（HTTP）または1080（SOCKS5）でアクセスできます。ユーザー名に国コードを指定することで、ジオターゲティングされた住宅IPを使用できます。
from playwright.sync_api import sync_playwright
import time
import random
PROXY = 'gate.proxyhat.com:8080'
PROXY_USER = 'user-country-US'
PROXY_PASS = 'your_password'
with sync_playwright() as p:
browser = p.chromium.launch(
headless=False, # ヘッドレスはwebdriverフラグを隠すのが難しい
proxy={
'server': f'http://{PROXY}',
'username': PROXY_USER,
'password': PROXY_PASS
}
)
page = browser.new_page()
page.goto('https://example.com/login')
# 人間らしいマウス移動と待機
time.sleep(random.uniform(2.0, 4.0))
page.mouse.move(100, 200, steps=20)
time.sleep(random.uniform(0.5, 1.5))
# フォーム入力に人間らしいタイピング間隔を設定
page.fill('#username', 'testuser', delay=50)
time.sleep(random.uniform(0.8, 1.6))
page.fill('#password', 'testpass', delay=50)
time.sleep(random.uniform(1.0, 2.0))
# reCAPTCHAトークンを取得
token = page.evaluate('''() => {
return new Promise((resolve) => {
grecaptcha.execute('SITE_KEY', {action: 'login'})
.then(token => resolve(token));
});
}''')
print(f'Token: {token[:30]}...')
browser.close()この例では、ProxyHatの住宅プロキシ（user-country-US）を通じてアクセスすることで、IPレピュテーションをクリアし、Playwrightのリアルブラウザでブラウザフィンガープリントを自然に保ち、人間らしいマウス移動とタイピング遅延で行動テレメトリを生成しています。3層すべてが揃うことで、スコアは0.6以上を維持しやすくなります。
ProxyHatのプロキシロケーションとプランについては、プロキシロケーション一覧および料金ページを参照してください。ウェブスクレイピングやSERPトラッキングのユースケースについては、それぞれウェブスクレイピングとSERPトラッキングのページで詳しく解説しています。
よくある間違いとエッジケース
ヘッドレスモードでの実行
ヘッドレスChromeはnavigator.webdriverフラグやその他のフィンガープリント特性で検出されやすく、reCAPTCHA v3スコアが0.1〜0.2に低下します。可能な限りheadless=Falseを使用するか、stealthプラグインでフィンガープリントを偽装してください。
同一IPでの高頻度リクエスト
住宅プロキシであっても、同一IPで短時間に大量のgrecaptcha.execute()を呼ぶと、行動パターンがボット的と判定されスコアが下がります。リクエスト間に2〜5秒のランダム待機を挟むことを推奨します。
トークンの2分タイムアウト
reCAPTCHA v3のトークンは発行から約2分で有効期限切れになります。トークンを取得してからsiteverifyに送信するまでの時間が長すぎると、検証が失敗します。トークンは即座にサーバーへ送信してください。
アクション名の不一致
クライアント側のactionパラメータとサーバー側の検証ロジックでアクション名を一致させないと、セキュリティホールになります。各アクション（login、signup、checkoutなど）に対して異なるしきい値を設定することも可能です。
適用範囲と法的・倫理的境界
reCAPTCHA v3のスコアリングを研究し、正当な自動化で合格スコアを獲得することは、以下の用途において正当な技術活動です。
- アクセシビリティQA自動化：WCAG準拠のフォームテストでCAPTCHAが障壁にならないか検証
- 承認されたペンテスト：クライアントから書面での許可を得たセキュリティテスト
- 自社サイトのreCAPTCHA設定検証：自社が導入したreCAPTCHAのしきい値が適切か確認
一方で、以下の用途は明確に不正であり、本記事の対象外です。
- 他者アカウントの大量作成・乗っ取り
- クレジットカード詐欺やチケット転売ボット
- スパム送信やコンテンツスクレイピングの回避
米国ではCFAA（Computer Fraud and Abuse Act, 18 U.S.C. § 1030）が「承認を超えるアクセス」を犯罪として定義しており、reCAPTCHAをバイパスして他者システムに不正アクセスすることは連邦法違反の可能性があります。EUではGDPRの下、自動化された個人データ処理に法的根拠が必要です。詳細な実装ガイダンスについてはProxyHat公式ドキュメントを参照してください。
主要なポイント
- reCAPTCHA v3は0.0〜1.0の連続スコアを返し、一般的に0.6以上で許可、0.3未満でブロック
- スコアは行動テレメトリ、Cookieグラフ、ブラウザ特性、IPレピュテーションの融合モデル
- データセンターIPは行動が完璧でもスコアを0.1〜0.3に押し下げるため、住宅プロキシが必須
- siteverifyで
actionとhostnameの一致を検証しないとトークン再利用攻撃に脆弱 - 住宅プロキシ＋リアルブラウザ＋人間らしいインタラクションの3層構成でスコア0.6以上を維持
- 用途は承認されたテスト・QA自動化・自社検証のみ。CFAAとGDPRに注意
FAQ
reCAPTCHA v3のスコアリングはどのように機能しますか？
reCAPTCHA v3は、grecaptcha.execute()呼び出し時に0.0〜1.0の連続リスクスコアを返します。このスコアは、マウス・スクロール・キーストロークの行動テレメトリ、ページインタラクション、GoogleのCookieグラフ、ブラウザフィンガープリント（TLS/JA3、Canvas、WebGL）、そしてIPレピュテーションを融合した機械学習モデルによって算出されます。スコアは0.1刻みの11バケットに分類され、サイト運営者がしきい値を設定します。
なぜreCAPTCHA v3のスコアがプロキシユーザーにとって重要なのですか？
reCAPTCHA v3のスコアが0.3未満だとリクエストがブロックされ、0.3〜0.6では追加チャレンジが要求されます。プロキシユーザー、特にデータセンターIPを使用する場合、IPレピュテーションシグナルが低く評価されるため、行動が人間らしくてもスコアが0.1〜0.3に押し下げられ、自動化が機能しなくなります。住宅プロキシを使用することで、IPレピュテーションをクリアし、スコアを0.6以上に維持できます。
reCAPTCHA v3のスコアを維持するのに最適なプロキシタイプはどれですか？
住宅プロキシ（Residential Proxy）が最適です。住宅プロキシは実際のISPから割り当てられたIPを使用するため、GoogleのIPレピュテーションシステムで人間トラフィックと同一プールとして評価されます。データセンタープロキシはASNがボットフラグ付きのため、スコアが0.1〜0.3に低下します。モバイルプロキシも高いスコアを維持できますが、コストが高くなる傾向があります。
reCAPTCHA v3を正当に実装する際、ブロックを回避するにはどうすればよいですか？
3層のアプローチを推奨します：(1) ProxyHatの住宅プロキシ（gate.proxyhat.com:8080、ユーザー名user-country-USなど）でIPレピュテーションをクリア、(2) Playwright等のリアルブラウザをheadless=Falseで使用しブラウザフィンガープリントを自然に保つ、(3) ランダムな待機間隔と人間らしいマウス移動で行動テレメトリを生成する。また、トークンは2分で期限切れになるため即座にsiteverifyへ送信し、actionとhostnameの一致を検証してください。
reCAPTCHA v3のトークン検証でactionとhostnameの一致確認がなぜ重要ですか？
クライアント側でgrecaptcha.execute(siteKey, {action: 'login'})で生成したトークンは、siteverifyレスポンスのactionフィールドと一致することを検証しないと、攻撃者が別アクション用のトークンを再利用してバイパスできる脆弱性が生じます。同様にhostnameフィールドが期待するドメインと一致することも検証が必要で、これを怠るとreCAPTCHAの保護が実質的に無効化されます。
