アンチボットとセキュリティ 12 分で読めます

reCAPTCHA v3のスコアリングの仕組み：不可視リスクエンジンの技術解説と合法自動化の実践

reCAPTCHA v3の0.0〜1.0リスクスコアがどのように算出されるかを、行動テレメトリ・Cookieグラフ・IPレピュテーションの観点から技術的に解説。住宅プロキシと実ブラウザを組み合わせた合法的な自動化アプローチも紹介します。

ProxyHat Team
How reCAPTCHA v3 Scoring Works: A Technical Deep Dive for 2026

2026年現在、reCAPTCHA v3のスコアリングの仕組みを理解することは、QA自動化エンジニアやアンチボット研究者にとって必須の知識です。v3は従来のチャレンジ画像を廃止し、バックグラウンドで継続的にトラフィックをスコアリングする「不可視」なリスクエンジンへと進化しました。本記事では、reCAPTCHA v3 scoreがどのように計算され、どのようなシグナルが融合されるか、そしてなぜデータセンターIPではスコアが崩壊するのかを技術的に掘り下げます。

reCAPTCHA v3のスコアリングの仕組み：基本モデル

reCAPTCHA v3は、grecaptcha.execute(siteKey, {action: 'login'})の呼び出しに対して、0.0から1.0の連続リスクスコアを返します。このスコアは1回のアクションごとに生成され、サイト管理者がクライアント側で受け取ったトークンをサーバー側でsiteverifyエンドポイントに送信することで確定します。スコア1.0に近いほど「人間らしい」、0.0に近いほど「ボットらしい」と判断されます。

Googleはスコアを0.1刻みの11段階のバケットに分類しています（0.0, 0.1, 0.2, ..., 1.0）。サイト管理者は管理コンソールで、各アクション（login, signup, checkoutなど）に対して閾値を個別に設定できます。一般的な閾値パターンは以下の通りです：

スコア範囲典型的な対応実例
0.0 – 0.3ブロック / 2FA強制ログイン拒否、アカウント作成禁止
0.3 – 0.6チャレンジ提示（v2フォールバック）画像選択タスクの表示
0.6 – 1.0許可（通常フロー）そのまま通過

重要なのは、reCAPTCHA v3 scoreが「絶対的な真実」ではなく、Googleのグローバルトラフィックパターンに対する相対的な確率値であるという点です。同じユーザー・同じブラウザでも、時間帯や対象サイトのトラフィック量によってスコアが変動します。Googleの公式ドキュメントでも、スコアの解釈はコンテキスト依存であることが明記されています。

技術的コンテキスト：なぜこの問題が存在するのか

従来のreCAPTCHA v2は「画像を選べ」という明示的なチャレンジによって人間とボットを区別していました。しかし、このアプローチにはユーザー体験の悪化、コンバージョン率の低下、アクセシビリティの問題という3つの根本的な欠陥がありました。Googleは2018年にv3をリリースし、チャレンジを完全に廃止して「摩擦のない」リスク評価へ移行しました。

v3の設計思想は、リスクを「バイナリ判定」ではなく「連続確率」として扱うことです。これにより、サイト管理者はスコアに応じて段階的な対応を設計できます。たとえば、スコア0.4のユーザーにはメール確認を追加要求し、スコア0.1のリクエストは完全にブロックする、といった具合です。

しかし、この「不可視」な設計は自動化エンジニアにとって新たな課題を生み出します。v2では画像を解けば通過できましたが、v3では「何がスコアを下げているのか」がブラックボックス化しているため、ボットらしさの原因を特定して修正する必要があります。これがreCAPTCHA v3の仕組みを深く理解する理由です。

Googleが融合する5つのシグナルカテゴリ

reCAPTCHA v3のスコアリングエンジンは、単一の指標ではなく、複数のシグナルカテゴリを融合して最終スコアを算出します。以下の5つが主要なカテゴリです。

1. 行動テレメトリ（マウス・スクロール・キーストローク）

最も重みの高いシグナルの一つが、ページ上でのインタラクションのタイミングデータです。具体的には：

  • マウス移動の軌跡と速度（直線的か、曲線的か）
  • スクロールの間隔と加速パターン
  • キーストロークの間隔分布（一定間隔 vs 自然なばらつき）
  • ページ滞在時間とインタラクション開始までの遅延

人間のマウス移動は微細な揺らぎと加速・減速を含みます。ボットがelement.click()で瞬時にクリックに到達する軌跡は、ベジェ曲線で近似しても高次の統計的特徴量で識別可能です。GoogleはこのテレメトリをWebSocket経由でリアルタイムに収集していると推測されます。

2. ページインタラクションテレメトリ

ページ読み込みからgrecaptcha.execute()呼び出しまでの時間、DOMイベントの発火順序、focus/blurイベントの有無などが評価されます。headlessブラウザがDOMを構築直後にexecuteを呼び出すパターンは、人間の行動（平均2〜5秒の読み時間）と乖離するため、スコアが下がります。

3. Google Cookieグラフ

ユーザーがGoogleアカウントにログインしている場合、またはGoogleのCookie（NID, SIDなど）が存在する場合、reCAPTCHAはそのユーザーの過去の行動履歴を参照できます。長期間にわたり正当な活動を行っているGoogleアカウントは、高い信頼スコアを持ちます。逆に、Cookieを完全にクリアした「クリーン」な環境は、履歴がないこと自体がリスクシグナルとなります。

4. ブラウザ特性とフィンガープリント

reCAPTCHAはブラウザの技術的特徴を詳細に検査します。具体的な検査項目には以下が含まれます：

  • Canvas fingerprint：GPU・ドライバ・フォントの組み合わせで生成される一意のハッシュ
  • WebGL fingerprint：レンダリングパイプラインの挙動差異
  • AudioContext fingerprint：オーディオ処理の浮動小数点の丸め差異
  • JA3/JA4 TLS fingerprint：TLSハンドシェイク時のClientHelloの暗号スイート順序
  • navigator プロパティ：userAgent, platform, hardwareConcurrency, deviceMemoryの整合性

特にJA3/JA4フィンガープリントは重要です。TLS ClientHelloパケットの暗号スイートリストの順序は、ブラウザの実装に固有のパターンを持ちます。たとえばChrome 120のClientHelloはTLS_AES_256_GCM_SHA384を最初に提示し、Firefox 121はTLS_AES_128_GCM_SHA256を先に提示します。headless ChromeやPuppeteerのデフォルトTLSスタックは、通常のChromeと微妙に異なる暗号スイート順序を示すことがあり、これがフィンガープリント不一致として検出されます。

5. IPレピュテーション

リクエスト元のIPアドレスのレピュテーションは、スコアに決定的な影響を与えます。Googleは自社のトラフィックデータと脅威インテリジェンスを融合し、IPを以下のカテゴリで分類しています：

  • 住宅IP（ISP割り当て）→ 高信頼
  • モバイルIP（キャリア割り当て）→ 高信頼
  • データセンターIP（AWS, GCP, Azure等）→ 低信頼
  • 既知のプロキシ/VPN/Tor出口ノード → 極低信頼

データセンターIPからのリクエストは、行動テレメトリが完璧であってもスコアが0.1〜0.3に抑えられることが観察されています。これは、Googleが過去のボット攻撃パターンの大部分をデータセンターIPから確認しているためです。

なぜデータセンターIPとフラグ済みIPでスコアが崩壊するのか

reCAPTCHA v3のスコアリングモデルは、シグナルの加重和ではなく、機械学習モデルによる非線形な融合です。つまり、IPレピュテーションが「1つの重み」ではなく、他のシグナルの解釈自体を変えるゲートとして機能します。

データセンターIPからのリクエストの場合、Googleのモデルは「行動テレメトリが人間的であっても、データセンターIP = 自動化インフラの可能性が高い」と判断し、他のポジティブシグナルの重みを圧縮します。これは実質的に、IPレピュテーションが一定のスコア上限を設ける「キャップ」として働くことを意味します。

この問題を解決するには、リクエスト元IPを住宅プロキシに切り替える必要があります。住宅IPはISPから実際の住民に割り当てられたIPアドレスであり、GoogleのIPレピュテーションシステムでは「通常のインターネットユーザー」として分類されます。これにより、IPレピュテーションのキャップが解除され、行動テレメトリやブラウザフィンガープリントのポジティブシグナルが本来の重みで評価されるようになります。

重要：住宅プロキシはスコアを「保証」するものではありません。スコアを下げるIPレピュテーションキャップを解除するだけで、最終スコアは依然として行動テレメトリとブラウザフィンガープリントに依存します。

トークン検証の仕組み：siteverifyとaction/hostname一致

クライアント側でgrecaptcha.execute()が返すトークンは、単独では意味を持ちません。サーバー側でGoogleのsiteverifyエンドポイントにトークンを送信して初めて、スコアと検証結果が確定します。

リクエスト形式は以下の通りです：

POST https://www.google.com/recaptcha/api/siteverify
Content-Type: application/x-www-form-urlencoded

secret=YOUR_SECRET_KEY&token=CLIENT_TOKEN

レスポンスには以下のフィールドが含まれます：

{
  "success": true,
  "score": 0.7,
  "action": "login",
  "challenge_ts": "2026-01-15T12:00:00Z",
  "hostname": "example.com",
  "error-codes": []
}

サーバー側で必ず検証すべき項目は3つあります：

  1. actionの一致：レスポンスのactionが、クライアント側でexecuteに渡したactionと一致すること。不一致はトークン再利用攻撃の兆候です。
  2. hostnameの一致：レスポンスのhostnameが、サイトの実際のドメインと一致すること。異なるドメインで生成されたトークンの再利用を防ぎます。
  3. scoreの閾値チェック：アクションごとに設定した閾値に対してスコアを評価し、適切な対応（許可/チャレンジ/ブロック）を選択する。

トークンの有効期間は約2分間です。期限切れのトークンを送信するとtimeout-or-duplicateエラーが返されます。この短い有効期間は、トークンの横取りや再利用を困難にする設計です。

実践：ProxyHat住宅プロキシと実ブラウザでスコアを維持する

以下は、正当なQA自動化またはアクセシビリティテストの文脈で、reCAPTCHA v3スコアを閾値以上に維持するアプローチの実装例です。关键な要素は3つです：

  1. 住宅プロキシによるIPレピュテーションの確保
  2. 実ブラウザ（または適切にステルス化したブラウザ）によるフィンガープリントの整合
  3. 人間らしいインタラクション遅延の注入

ProxyHat接続設定

ProxyHatの住宅プロキシは、ユーザー名フィールドでジオターゲティングとセッション管理を行います。米国の住宅IPを使用する場合：

http://user-country-US:password@gate.proxyhat.com:8080

特定の都市を指定する場合：

http://user-country-US-city-newyork:password@gate.proxyhat.com:8080

セッションを固定して同じIPを維持する場合：

http://user-session-qa-test-01:password@gate.proxyhat.com:8080

SOCKS5プロトコルを使用する場合はポート1080を指定します：

socks5://user-country-US:password@gate.proxyhat.com:1080

Python実装例

以下は、PlaywrightとProxyHat住宅プロキシを組み合わせた実装例です。このコードはQAテストやアクセシビリティ検証の文脈で使用することを前提としています。

import asyncio
import random
from playwright.async_api import async_playwright

PROXY_URL = "http://user-country-US:password@gate.proxyhat.com:8080"
TARGET_URL = "https://example.com/login"

async def human_delay(min_s=0.5, max_s=2.0):
    """人間らしいランダム遅延を注入"""
    await asyncio.sleep(random.uniform(min_s, max_s))

async def human_mouse_move(page, element):
    """ベジェ曲線風のマウス移動"""
    box = await element.bounding_box()
    if box:
        # 複数の中間点を経由して曲線的に移動
        steps = random.randint(15, 30)
        for i in range(steps):
            t = i / steps
            # 2次ベジェ曲線で近似
            offset_x = box["x"] + box["width"] / 2 * t + random.gauss(0, 3)
            offset_y = box["y"] + box["height"] / 2 * t + random.gauss(0, 3)
            await page.mouse.move(offset_x, offset_y)
            await asyncio.sleep(random.uniform(0.005, 0.02))

async def run_qa_test():
    async with async_playwright() as p:
        browser = await p.chromium.launch(
            headless=False,  # 実ブラウザ推奨
            proxy={"server": PROXY_URL}
        )
        context = await browser.new_context(
            viewport={"width": 1920, "height": 1080},
            locale="en-US",
            timezone_id="America/New_York",
        )
        page = await context.new_page()

        await page.goto(TARGET_URL, wait_until="networkidle")
        await human_delay(2.0, 5.0)  # ページ読み込み後の人間らしい滞在

        # スクロールでインタラクションを示す
        await page.mouse.wheel(0, 200)
        await human_delay(0.5, 1.5)

        # フォーム入力
        email_input = page.locator("input[name='email']")
        await human_mouse_move(page, email_input)
        await email_input.click()
        await human_delay(0.3, 0.8)

        # キーストローク間隔にばらつきを持たせる
        for char in "test@example.com":
            await page.keyboard.type(char)
            await asyncio.sleep(random.uniform(0.05, 0.15))

        # reCAPTCHAトークンを取得
        token = await page.evaluate("""
            async () => {
                return await grecaptcha.execute(
                    'SITE_KEY', {action: 'login'}
                );
            }
        """)
        print(f"reCAPTCHA token: {token[:20]}...")

        await browser.close()

asyncio.run(run_qa_test())

この実装のポイントは、headless=Falseで実際のブラウザウィンドウを使用し、マウス移動にベジェ曲線風の軌跡を適用し、キーストローク間隔に0.05〜0.15秒のランダムばらつきを注入している点です。ProxyHatの住宅プロキシ（gate.proxyhat.com:8080）により、IPレピュテーションキャップが解除され、これらの行動シグナルが本来の重みで評価されます。

よくある間違いとエッジケース

間違い1：ヘッドレスブラウザのデフォルト使用

PuppeteerやPlaywrightのデフォルトヘッドレスモードは、navigator.webdriverプロパティがtrueを返し、Canvas描画のGPUアクセラレーションが無効になるため、フィンガープリントが通常のChromeと異なります。これだけでスコアが0.2〜0.3低下することがあります。headless=Falseまたは適切なステルスプラグインの使用が必要です。

間違い2：セッションIPの頻繁な切り替え

リクエストごとにIPをローテーションすると、同一セッション内でIPが変わることがGoogleのCookieグラフと矛盾し、リスクシグナルとなります。ProxyHatのuser-session-xxxフラグでセッションを固定し、1回のQAセッション中は同じ住宅IPを維持してください。

間違い3：トークンの再利用

reCAPTCHA v3のトークンは2分間のみ有効で、1回しか使用できません。トークンをキャッシュして再利用しようとするとtimeout-or-duplicateエラーが返されます。アクションごとに新しいトークンをexecute()で取得する必要があります。

間違い4：actionの不一致

クライアント側で{action: 'submit'}を指定してトークンを生成し、サーバー側でaction: 'login'を期待している場合、検証が失敗します。action名はクライアント・サーバー間で厳密に一致させる必要があります。

エッジケース：reCAPTCHA score 0.3の境界付近

スコア0.3は多くのサイトで「ブロック」と「チャレンジ」の境界です。この境界付近ではスコアが日時やトラフィックパターンで変動するため、ある日は通過しても翌日にブロックされることがあります。本番環境では0.5以上のマージンを確保することを推奨します。詳細なトラブルシューティングについてはProxyHatドキュメントを参照してください。

適切な利用範囲と法的留意点

本記事で解説した技術は、以下の正当な目的にのみ使用してください：

  • QA自動化：自社サイトのreCAPTCHA導入後のユーザー体験検証
  • アクセシビリティテスト：障害のあるユーザーの代替フロー検証
  • セキュリティ研究：認可されたペネトレーションテストの一環としての評価
  • 学術研究：アンチボット機構の学術的分析（適切な倫理審査のもと）

これらの技術を不正な目的（アカウント大量作成、クレジットカード詐欺、チケット転売、スパム送信など）に使用することは明確に禁止されます。米国のComputer Fraud and Abuse Act (CFAA)は、認可を超えてコンピュータシステムにアクセスする行為を連邦犯罪として規定しており、reCAPTCHAを回避してサービス利用条件に違反する行為はこれに該当する可能性があります。また、EU一般データ保護規則（GDPR）の下では、ユーザーデータの処理に関する正当な根拠が必要です。

ProxyHatの住宅プロキシは、料金プランに従って利用可能で、世界中のロケーションから選択できます。QA自動化やSERP追跡のユースケースについては、WebスクレイピングおよびSERP追跡のページを参照してください。

Key Takeaways

  • reCAPTCHA v3は連続スコアモデル：0.0〜1.0の11段階バケットで評価され、一般的に0.3未満はブロック、0.3〜0.6はチャレンジ、0.6以上は許可。
  • 5つのシグナルカテゴリが融合：行動テレメトリ、ページインタラクション、Cookieグラフ、ブラウザフィンガープリント（JA3/JA4含む）、IPレピュテーション。
  • IPレピュテーションはキャップとして機能：データセンターIPでは行動シグナルが完璧でもスコアが0.1〜0.3に抑えられる。住宅プロキシでキャップを解除する必要がある。
  • サーバー側検証が必須：siteverifyでactionとhostnameの一致を確認し、トークンの2分間有効期限に注意。
  • 人間らしいインタラクションが鍵：マウス移動の曲線性、キーストローク間隔のばらつき、ページ滞在時間の確保がスコア維持に不可欠。
  • 正当な目的でのみ使用：QA自動化・アクセシビリティ検証・認可されたセキュリティ研究に限定し、CFAA/GDPRを遵守すること。

FAQ

reCAPTCHA v3のスコアリングの仕組みとは何ですか？

reCAPTCHA v3は、ユーザーの行動テレメトリ、ブラウザフィンガープリント、Google Cookieグラフ、IPレピュテーションなどの複数シグナルを機械学習モデルで融合し、0.0〜1.0の連続リスクスコアを生成します。チャレンジ画像は表示されず、バックグラウンドでスコアリングが行われます。スコアはgrecaptcha.execute()の呼び出しごとに生成され、サーバー側のsiteverifyで確定されます。

なぜreCAPTCHA v3のスコアリングの仕組みがプロキシユーザーにとって重要なのですか？

reCAPTCHA v3のスコアはIPレピュテーションに大きく依存し、データセンターIPやフラグ済みIPからのリクエストは行動が人間的でもスコアが0.1〜0.3に抑えられます。プロキシユーザーがスコア閾値を超えるには、住宅プロキシでIPレピュテーションキャップを解除する必要があります。スコアリングの仕組みを理解せずにプロキシを運用すると、スコアが低すぎてサイトにアクセスできない問題に直面します。

reCAPTCHA v3 scoreに最適なプロキシタイプはどれですか？

住宅プロキシが最適です。住宅IPはISPから実際の住民に割り当てられたIPアドレスであり、GoogleのIPレピュテーションシステムで「通常のインターネットユーザー」として分類されます。データセンタープロキシは低レピュテーションでスコアが抑制され、モバイルプロキシも高信頼ですが利用可能なIPプールが小さい場合があります。ProxyHatの住宅プロキシ（gate.proxyhat.com:8080）は、国・都市レベルのジオターゲティングをサポートします。

reCAPTCHA v3の実装でブロックを回避するにはどうすればよいですか？

3つの要素を組み合わせます：（1）住宅プロキシでIPレピュテーションを確保、（2）実ブラウザまたはステルス化したブラウザでフィンガープリントの整合を維持、（3）マウス移動に曲線的軌跡、キーストロークに0.05〜0.15秒のランダム間隔、ページ滞在時間に2〜5秒の遅延を注入して人間らしい行動をシミュレートします。また、トークンの2分有効期限とaction/hostname一致のサーバー側検証も忘れないでください。

reCAPTCHA score 0.3の境界付近でスコアが変動するのはなぜですか？

reCAPTCHA v3のスコアはGoogleのグローバルトラフィックパターンに対する相対値であり、対象サイトのトラフィック量や時間帯によって変動します。0.3は多くのサイトで「ブロック」と「チャレンジ」の境界であり、この境界付近では日によって通過したりブロックされたりします。本番環境では0.5以上のマージンを確保し、ProxyHatのuser-session-xxxフラグでセッション中のIP固定を行うことで安定性を向上させることができます。

始める準備はできましたか？

AIフィルタリングで148か国以上、5,000万以上のレジデンシャルIPにアクセス。

料金を見るレジデンシャルプロキシ
How IP Reputation and Fraud Scoring Work (IPQualityScore): A 2026 Deep Dive
アンチボットとセキュリティ

IPレピュテーションと不正スコアの仕組み：IPQualityScoreで読み解くプロキシ検知

IPQualityScore（IPQS）の0〜100不正スコアがどのように構築されるかを技術的に解説。ASN分類、ハニーポット、機械学習、ライブ検査の各シグナルを拆解し、データセンタープロキシが検知され、レジデンシャルプロキシが通過する理由を実例とPythonコードで説明します。

12 分で読めます続きを読む →
← ブログに戻る