なぜあなたのエージェントはCAPTCHAsを間違えて解き続けているのか

TL;DR

• エージェントがCAPTCHAを間違えて解いているのは、ページが実行時にレンダリングしたチャレンジではなく、エージェントが推測したチャレンジを解こうとしているためです。
• サイトキー、アクション名、コールバック関数、チャレンジモードがルート間で変化するため、ホイドレーション後のウィジェットコンテキストをキャプチャする必要があります。
• トークンが間違ったフィールドに挿入され、間違ったリクエストで消費され、検証後に再利用される、またはクッキーから分離されている場合、正しい結果でも失敗する可能性があります。
• プランナーには、解決済みのウィジェット、受け入れられたバックエンドリクエスト、完了したビジネスアクションを区別する進捗定義が必要です。
• 繰り返し間違った解決が発生した場合は、タスクを停止し、ソルバーに結果を求めるのではなく、証拠を生成する必要があります。

イントロダクション：推測に基づくソルバーの不一致

エージェントがCAPTCHAを間違えて解き続けるのは、表示されているチャレンジを全体の問題と誤って扱っているためです。CapSolverは承認されたCAPTCHAソルビングワークフローをサポートできますが、エージェントは正確なチャレンジを特定し、実行時のパラメータを収集し、結果を正しいリクエストにバインドし、バックエンドの受け入れを検証する必要があります。ブラウザで正しいように見える結果が、次のステップで拒否されることがあります。最も速い有用な診断は、最初の不一致を特定することです。チャレンジタイプ、パラメータ、トークンの配置、セッションの連続性、またはプランナーのループです。

結果を求める前にチャレンジを分類する

間違った解決は、通常、間違った分類から始まります。エージェントがすべてのチェックボックスが同じであると仮定し、すべての画像グリッドに同じワークフローが必要であると仮定し、すべての非表示チャレンジが任意の隠しフィールドに貼り付け可能なトークンを返すと仮定している場合、エージェントはCAPTCHAを間違えて解き続けます。現代のページは、reCAPTCHA、Turnstile、画像タスク、カスタムリスクプロンプト、サーバーサイドチェックを1つの旅に組み合わせることがあります。

明示的な分類ステップから始めましょう。プロバイダー、バージョン、iframe URL、表示されているウィジェットの状態、サイトキーまたは同等のパラメータ、存在する場合はアクション名、コールバックの動作、およびその後の保護されたリクエストを記録してください。CapSolverのCAPTCHAのコンセプト用語は、チームがカテゴリを議論するのに役立ち、すべてを一般的なチャレンジに簡略化する必要がありません。分類後にCapSolverのCAPTCHAの失敗原因をトラブルシューティングのチェックリストとして使用できます。

W3C WebDriver仕様は、要素の操作可能性について説明しています。これは、自動化が見ている要素の状態に対して正しい動作を行うためのものです。CAPTCHAの分類にも同じような厳格さが必要です。アクションを取る前にレンダリングされた状態を観察する必要があります。

ソルバー呼び出し前の分類スナップショット

手渡しの直前に分類スナップショットを保存してください。このスナップショットはCapSolverのリクエストではありません。エージェントが今後解決しようとしているレンダリングされたチャレンジを証明するためのローカル証拠です。

{
  "challengeId": "login-iframe-03",
  "provider": "recaptcha",
  "version": "v2",
  "frameUrl": "https://www.google.com/recaptcha/",
  "siteKeyObserved": true,
  "protectedRequest": "POST /login",
  "sessionStable": true
}

このスナップショットが欠如している場合、エージェントは別の結果を要求してはなりません。エージェントが分類をスキップし、表示されているウィジェットを十分な証拠として扱う場合、CAPTCHAを間違えて解き続けます。

実行時のウィジェットコンテキストをキャプチャする

静的なソースは信頼性が低いです。エージェントが古いサイトキーを抽出し、ルート固有のアクションを見逃し、JavaScriptフレームワークがホイドレーションする前にプレースホルダーを読み込む場合、エージェントはCAPTCHAを間違えて解き続けます。ログイン後のページ、失敗した送信後のページ、またはリスクスコア変更後のページが異なるウィジェットをレンダリングする可能性があります。

ソルバーへの手渡しの直前にウィジェットコンテキストをキャプチャしてください。reCAPTCHAの場合、バージョン、サイトキー、アクション、コールバック、エンタープライズフラグ、フォームのターゲットを記録してください。Turnstileの場合、サイトキー、アクション、cData、コールバック、iframe URL、およびターゲットリクエストを記録してください。画像タスクの場合、指示テキストと画像グリッドの状態を記録してください。ページのチャレンジファミリーが不明な場合、CapSolverのreCAPTCHAタイプの識別は役立ちます。

実行時の状態はJavaScriptの完了に依存します。MDNのドキュメントの準備状態はインストルメンテーションをガイドしますが、準備状態だけでは不十分です。ウィジェットと保護されたフォームの状態を待つ必要があります。ページの読み込みだけではなく。

実行時キャプチャ後のオフィシャルタスクフィールド

実行時のパラメータがキャプチャされた後、エージェントはCapSolverタスクを構築する必要があります。reCAPTCHA v2の場合、オフィシャルなCapSolver reCAPTCHA v2ドキュメントはReCaptchaV2TaskProxyLessタスクの形状を示し、オフィシャルな getTaskResultフローは作成されたタスクの結果を返します。

{
  "clientKey": "YOUR_API_KEY",
  "task": {
    "type": "ReCaptchaV2TaskProxyLess",
    "websiteURL": "https://www.google.com/recaptcha/api2/demo",
    "websiteKey": "6Le-wvkSAAAAAPBMRTvw0Q4Muexq9bi0DJwx_mJ-"
  }
}

選択されたオフィシャルなタスクタイプがそれらを文書化していない限り、推測されたアクション名、コールバックフィールド、またはページ固有のメタデータをこのリクエストに追加しないでください。これらの値をローカルのインシデントパケットに保持してください。

トークン出力をターゲットリクエストに接続する

正しいトークンでも誤って使用されることがあります。エージェントが結果を間違ったフィールドに配置し、フォームが再レンダリングされた後に送信し、失敗した送信後に再利用される、または同じクッキーを持たないリクエストで消費される場合、エージェントはCAPTCHAを間違えて解き続けます。トークン出力は1回限りのバインディングである必要があります。トークンが作成され、フィールドが設定され、送信が送信され、バックエンドの応答が受信される必要があります。

HTMLフォーム送信は状態を持つものです。WHATWGのフォームデータの構築の定義は、ブラウザが送信時にコントロールからペイロードを構築することを説明しています。エージェントが隠しフィールドを変更し、その後Reactの再レンダリングをトリガーすると、最終的なペイロードに期待している値が含まれていない可能性があります。

CapSolverのreCAPTCHA v2製品とreCAPTCHA v3製品は異なるトークンの期待にマップされます。これらを混ぜてはいけません。v3スタイルのアクション結果はv2のチェックボックスコールバックの失敗を修復できませんし、v2の結果はスコアベースのアクションポリシーを満たすことはできません。

1つのトークン、1つの送信試行

各結果に対して1つのバインディング記録を作成してください。この記録はタスクID、ブラウザコンテキスト、ターゲットリクエスト、トークンの配置、送信時間、バックエンドの応答を接続する必要があります。これは1回の送信試行後に期限切れになります。

{
  "challengeId": "login-iframe-03",
  "taskId": "capsolver-task-id",
  "browserContextId": "ctx-77",
  "submitRequest": "POST /login",
  "tokenAttached": true,
  "backendStatus": 200,
  "reuseAllowed": false
}

この記録により、トークンの再利用が視覚化されます。バックエンドが送信を拒否した場合、次の診断の質問は「どこでバインディングが破損したか」であり、「同じ解決を繰り返すか」ではありません。

CapSolverのボーナスコードを引き換える

自動化予算を即座に増やす！
CapSolverアカウントにチャージする際にボーナスコード CAP26 を使用すると、すべてのチャージで5%のボーナスが追加されます - 制限なし。
今すぐCapSolverダッシュボードで引き換えてください

プランナーに進捗を何と定義するかを教える

AIプランナーは進捗を誤って読み取ることがあります。ウィジェットが消えると、プランナーは成功と仮定します。隠しフィールドが埋められると、再度送信します。バックエンドが同じページを返すと、別のトークンを要求します。エージェントが視覚的な完了とアプリケーションの受け入れの間に状態がない場合、CAPTCHAを間違えて解き続けます。

進捗レベルを定義してください。レベル1はチャレンジの検出、レベル2は結果の受信、レベル3は正しいブラウザセッションへの結果のバインディング、レベル4は保護されたリクエストの受け入れ、レベル5はビジネスアクションの完了です。ソルバー呼び出しはエージェントをレベル2にのみ移動させます。CapSolverのCAPTCHAループの破壊記事は、このプランナー設計にとって役立つ補完です。ループ制御は解決品質とは別にあります。

アプリケーションセキュリティプログラムは、階層化された検証を使用する理由があります。OWASP ASVSは検証コントロールカテゴリを提供し、認証、セッション、入力処理を分離しています。あなたのエージェントもCAPTCHA出力、セッション証拠、最終的なリクエストの受け入れを同じように分離する必要があります。

複数チャレンジのクロストークを避ける

1つのページライフサイクルで複数のチャレンジが存在する可能性があります。ログインページは最初に非表示トークンをロードし、パスワードの失敗後に画像チャレンジを表示し、送信後にサーバーサイドのリスクチェックをトリガーする可能性があります。エージェントが最初のチャレンジの結果を2番目のチャレンジのコールバックに送信する場合、CAPTCHAを間違えて解き続けます。

チャレンジIDを使用してください。検出された各ウィジェットには、プロバイダー、フレーム、パラメータ、レンダータイム、ターゲットリクエストを持つローカルIDを割り当てます。ページが再レンダリングされた場合、古いチャレンジIDを閉じて新しいIDを作成してください。CapSolverのCAPTCHA成功率の要因はIDごとに追跡され、ページレベルの成功数よりも役立ちます。

マルチチャレンジフロー中にクッキーの連続性が依然として重要です。MDNのHTTPクッキーの動作は、バックエンドが検証状態をストレージと関連付ける理由を示しています。ワークフローが意図的に再起動する場合を除き、チャレンジID間で新しいコンテキストを開かないでください。

バウンダリーで失敗を監査する

最善の失敗レポートは破損したバウンダリーを名前付けます。エージェントがCAPTCHAを間違えて解き続けるのは、分類が失敗した、パラメータのキャプチャが失敗した、ソルバー出力が失敗した、トークンの配置が失敗した、バックエンド検証が失敗した、またはビジネスロジックが失敗したためです。これらは異なる修復です。一般的な再試行はバウンダリーを隠します。

小さな失敗の分類を作成してください。wrong_provider、stale_parameters、missing_callback、token_not_submitted、session_changed、backend_rejected、business_rule_rejectedは開始に十分です。各失敗にスクリーンショットとリクエストの証拠を保存してください。CapSolverのソルバーのワークフローはこの分類の下に配置され、サービスステップとして機能します。あなたのエージェントは周囲の証拠を所有しています。

繰り返しのバウンダリー同一の失敗後に停止してください。2回の試行がtoken_not_submittedで失敗した場合、3回目のトークンを購入しないでください。フォームのシリアライゼーションを修正してください。2回の試行がsession_changedで失敗した場合、ブラウザコンテキストの永続性を修正してください。2回の試行がアクセス拒否で失敗した場合、権限を確認してください。これは、間違った解決ループがコストの漏れではなくエンジニアリングチケットになる方法です。

間違った解決のインシデントパケットを構築する

エージェントがCAPTCHAを間違えて解き続けるたびに、コンパクトなインシデントパケットを作成してください。このパケットには、レンダリングされたウィジェットのスクリーンショット、プロバイダーの分類、実行時のパラメータ、フレームURL、コールバック名、トークンの受信時間、フィールドの変更、送信リクエスト、バックエンドのステータス、プランナーの決定が含まれます。この証拠により、漠然とした不満がバウンダリー固有の修復に変わります。

プランナーが証拠を要約しないようにしてください。構造化されたログに生の値を保存し、モデルが簡潔な解釈を読むようにしてください。モデルが「CAPTCHAが再度失敗しました」という文だけを受け取ると、別の解決を選びます。モデルが「送信ペイロードからトークンフィールドが見つからない」と受け取ると、タスクをフォームシリアライゼーションの修復にルーティングできます。

あなたが2回目に見るすべての失敗クラスに対して合成テストページを追加してください。1つのページは古くなったトークンを拒否し、別のページはアクション名を回転させ、別のページは隠しフィールドを再レンダリングし、別のページはバックエンドのビジネス拒否をシミュレートします。エージェントは、ライブソルバーを呼び出さずに各失敗を分類できるようにする必要があります。これにより、間違った解決ループが本番環境に侵入することを防ぎます。

コールバック処理を注意深くレビューしてください。一部のページではJavaScriptコールバックが必要であり、隠し入力値だけではありません。他のページでは両方が必要です。正しい結果が到着した後でもエージェントがCAPTCHAを間違えて解き続ける場合、ページのイベントハンドラーが実行されたか、保護された送信がこれらのハンドラーの完了後に発生したかを確認してください。

失敗のバウンダリーごとにコストを追跡してください。総チャレンジ数だけでなく、バウンダリーごとに。ほとんどの失敗がwrong_providerに集中している場合、分類を改善してください。token_not_submittedに集中している場合、ブラウザツールを修正してください。backend_rejectedに集中している場合、アプリケーションの所有者に関与してください。ソルバーの成功率だけでは、エージェントのどの部分が壊れているかを教えてくれません。

繰り返しの間違った解決に対してレビュー規則を設定してください。2回のバウンダリー同一の失敗後、エージェントは停止し、インシデントパケットを添付する必要があります。このルールは、ターゲットサイトを保護し、自動化予算を保護し、エンジニアが特定の不一致を修正するための証拠を提供します。

構造化されたフィールドがキャプチャされた後のみ、視覚的な差分を追加してください。スクリーンショットはレビューに役立ちますが、プロバイダー、バージョン、アクション、コールバック、リクエストの証拠よりも弱いです。エージェントが隠しパラメータの変更を無視しながら視覚的な類似性に依存している場合、CAPTCHAを間違えて解き続けます。

試行間で古くなった結果が漏れないようにしてください。失敗した送信後にローカルトークン変数をクリアし、古いチャレンジIDを閉じ、コールバックをリセットしてください。後続の試行が偶然に古い値を再利用しないようにしてください。この小さなクリーンアップステップは、一見ランダムな間違った解決報告を多くの場合防ぎます。

バックエンドの所有者をループに含めてください。保護されたアプリケーションがトークンをサーバーサイドで検証する場合、ブラウザエンジニアは物語の半分しか見ていません。相関ID、検証の理由、アプリケーションルールの結果を尋ねて、インシデントパケットがチャレンジから決定に至る完全なパスをカバーするようにしてください。

すべての間違った解決のインシデントでエージェントのプロンプトとブラウザツールのバージョンを記録してください。プランナーの指示はチャレンジの解釈を変える可能性があり、ブラウザツールの更新はフレームアクセスやイベントタイミングを変える可能性があります。これらのバージョンがなければ、チームはページの統合を修正するかもしれませんが、実際の回帰はオーケストレーションにあります。すべての保護された実行でバージョンフィールドを必須としてください。これにより、後で静かに回帰が発生することを防ぎます。

結論

エージェントが繰り返しCAPTCHAを誤って解こうとする場合、修正方法は同じソルバーコールを繰り返すのではなく、最初の不一致を見つけることです。レンダリングされたチャレンジを分類し、実行時パラメータをキャプチャし、各結果を1つのリクエストに関連付け、プランナーに受け入れられた進捗の意味を教えること、および同一の境界で失敗が繰り返された場合に停止します。CAPTCHAの解決が承認されている法的なワークフローにおいては、CapSolverがチャレンジの結果を処理し、エージェントがコンテキストと検証を正しいままに保つことができます。

FAQ

CAPTCHAが解決されたように見えるのに、ページがエージェントを拒否するのはなぜですか？

結果が正しいリクエストに添付されていない、セッションが変更されている、トークンが古くなっている、またはバックエンドが後続のビジネスルールを拒否している可能性があります。視覚的な完了はリクエストの承認とは異なります。

エージェントが間違ったCAPTCHAタイプを選択したかどうかをどうやって知ればよいですか？

プロバイダー、バージョン、iframeのURL、サイトキー、アクション、コールバック、保護されたリクエストをログに記録してください。これらのフィールドが使用されたソルバーワークフローと一致しない場合、エージェントがチャレンジを誤って分類した可能性があります。

失敗した送信後にエージェントが別の解決を要求すべきですか？

失敗を分類した後のみです。トークンが送信されていない、セッションが変更された、またはバックエンドがアクセスを拒否した場合、別の解決では根本的な問題は解決しません。

間違った解決のための最も有用なデバッグアーティファクトはどれですか？

境界タイムラインが最も有用なアーティファクトです。チャレンジが検出された、パラメータがキャプチャされた、結果が受け取られた、フィールドまたはコールバックが更新された、送信が送信された、バックエンドの応答、プランナーの決定。