AIブラウザエージェントにおける複数のCAPTCHAウィジェットの取り扱い方法

TL;DR

• 1ページに複数のCAPTCHAウィジェットがある場合、意図されたフォーム、その現在のウィジェットインスタンス、およびソルバーの試行の間のマッピングが必要です。
• DOMコンテナID、プロバイダーウィジェットID、およびソルバータスクIDはそれぞれ異なるものを表しており、互いに置き換えてはなりません。
• CAPTCHAの種類を検出しても、AIエージェントが許可されたフォームに送信できるかどうかはわかりません。
• 許可されたワークフローでサポートされているチャレンジにのみソルバーを使用し、関係のないウィジェットは無視してください。
• 非同期処理の後にフォームとウィジェットの関連性を再確認し、トークン配信とは別に意図されたアプリケーションの結果を検証してください。

AIエージェントは複数のCAPTCHAウィジェットをどのように扱うべきですか？

AIブラウザエージェントは、まず意図されたフォームを選択し、その現在のCAPTCHAウィジェットを特定し、解決とアプリケーション検証を通じてその関連性を保持する必要があります。

所有するサポートポータルに、同じページに2つのフォーム（サポートリクエストとオプションの製品フィードバック）があると仮定してください。認証されたQAエージェントがサポートリクエストをテストしている場合、フィードバックCAPTCHAを完了してもタスクを満たすことはできません。どちらのフォームも同じプロバイダーを使用し、見た目が似ている場合でもです。

CapSolverなどのCAPTCHAソルバーは、エージェントが意図されたサポートチャレンジを特定した後に使用する必要があります。ソルバーは選択されたCAPTCHAタスクの答えを提供し、アプリケーションの統合はその答えを正しい場所にルーティングする責任があります。

これは、チームが所有するまたはテストが許可されているページ用のワークフローおよびQA設計ガイドです。複数のウィジェットに必要な記録、ステージの境界、およびチェックについて説明しています。これは任意のページに即座に適用可能なテスト済みSDK統合を提供するものではありません。

ワークフローを構築する前に何が必要ですか？

信頼性のあるワークフローには、明示的なタスク範囲、所有するフォームからウィジェットへのマッピング、およびアプリケーションの検証結果を検査する方法が必要です。

実際のレイアウトバリアントを含むテストページから始めましょう。意図されたフォームと許可された操作を記録してください。エージェントは、すべての表示される送信ボタンがタスクに含まれていると推測してはなりません。

ページ所有者は、安定したフォーム識別子を公開し、プロバイダーの公開統合によって作成されたウィジェットハンドルを保持する必要があります。reCAPTCHAの場合、これらのハンドルはクライアントサイドのライフサイクルの一部です。これらは、サービスが自動操作をチェックする一般的な役割とは異なります。

また、サポートされているソルバータスク、ページコンテンツ外に保存された資格情報、制限付き待機ポリシー、およびQAハーネスが観測できるバックエンド結果も必要です。アプリケーションが選択したソルバーパスがサポートしていないCAPTCHA形式を使用している場合、代替タスクを推測するのではなく、その境界で停止してください。

通常のフォームロジックのテストには、所有者制御のテスト施設を優先してください。許可されたテストが実際にソルバーパスを評価する場合、そのテストを別途ラベル付けして、シミュレートされたCAPTCHA結果がエンドツーエンドサービス検証と誤認されないようにしてください。

ステージ1: 意図されたフォームを現在のウィジェットにマッピングする

最初のステージでは、エージェントの要求されたアクションを明示的なフォームとウィジェットの関連性に変換します。

入力は、ステージングポータルで合成サポートリクエストを送信するなどの許可された操作です。操作は、アプリケーションの安定した識別子を通じてサポートフォームを特定し、そのコンポーネントが維持するウィジェット参照を取得します。出力は、フォーム参照と現在のウィジェットインスタンスであり、「CAPTCHAが存在する」だけではありません。

GoogleのreCAPTCHA v2表示ドキュメントは、明示的なレンダリングと複数のウィジェットを示しています。レンダリングはウィジェットIDを返します。getResponseやresetなどのメソッドはウィジェットIDを受け取り、省略するとデフォルトで最初のウィジェットが使用されます。意図された操作が別のフォームに属するページでは、このデフォルトは誤っている可能性があります。

CloudflareのTurnstileクライアントサイドレンダリングガイドも、明示的なウィジェットレンダリングとライフサイクル管理を説明しています。プロバイダーのAPIと保持されたハンドルを使用し、プロバイダー間でメソッドの仮定を転送しないでください。

1つのフォームに複数のウィジェットがマッピングされている、またはマッピングが欠如している場合、ステージは実行可能な診断で失敗する必要があります。DOMの順序は所有権の証拠としては十分ではありません。フォーム参照、ページ生成、マッピング結果を検査のために保存してください。診断記録にはトークン値を保存しないでください。

ステージ2: 異なる識別子を別々に保持する

2番目のステージでは、非同期処理がページコンポーネントをリモートソルバータスクと混同しないように、各識別子に単一の意味を割り当てます。

識別子	何を表すか	何を置き換えてはならないか
フォーム参照	所有するアプリケーションの操作	プロバイダータスクID
DOMコンテナID	ウィジェットを含むページ要素	プロバイダーの実行時ウィジェットハンドル
プロバイダーウィジェットID	レンダリングされたウィジェットインスタンス	CAPTCHAサイトキー
サイトキー	プロバイダー統合の構成	フォーム試行のユニークな識別子
ソルバータスクID	送信されたリモート解決要求	ブラウザ要素またはフォーム識別子
アプリケーション試行参照	意図された操作の1回の実行	同じページでの以降の再試行

これらのラベルは、プロバイダーの応答スキーマではなく、提案されたアプリケーション記録です。各ハンドルの元の値と型を保持し、すべての識別子を交換可能な文字列に正規化しないでください。

2つのウィジェットが構成を共有していても、異なるフォームに属する可能性があります。したがって、所有ページが意図的にその構成を再利用している場合、サイトキーだけで選択することは不十分です。アプリケーションは、前のステージで確立したフォームの関連性が必要です。

記録にページまたはコンポーネントの生成を添付してください。ダイアログは新しいウィジェットインスタンスで閉じて再開されても、表示されるタイトルは保持されます。生成情報により、後のステージで見た目が似たフォームが解決試行を開始したインスタンスではないことを検出できます。

ステージ3: そのウィジェットに該当するソルバー情報を選択する

3番目のステージでは、選択されたウィジェットの関連性をサポートされているソルバー情報に変換し、それが意図されたフォームへの接続を保持します。

CapSolver Core SDKリファレンスは、いくつかの操作を区別しています: detect(page)はCAPTCHAの種類を返し、get_captcha_info(page)はCAPTCHA情報のレコードを返し、solve(info)は解決を返します。ドキュメントされたトークンモードのカバレッジにはreCAPTCHA v2、reCAPTCHA v3、Turnstileが含まれますが、画像グリッドのクリックやスライダーのドラッグは含まれていません。

このリファレンスは、container_id、callback、binded_button_idなどのブラウザフィルバックメタデータも説明しています。これらは所有フォームマッピングと調整する証拠として扱ってください。検出されたタイプはウィジェットインスタンスの数ではなく、リストの最初のエントリはエージェントのタスクに属している証拠ではありません。

自前のページで利用可能な情報を検査してください。そのフレームとレンダリング動作も含まれます。検出器が意図されたウィジェットを選択するのに十分な証拠を公開していない場合、統合修正のために停止してください。ページ上のすべてのチャレンジにタスクを拡大してはなりません。

このステージの出力は、1つの選択された情報レコードと、それが選択された理由を説明するアプリケーションの関連性です。失敗境界は曖昧さまたはサポートされていないカバレッジです。有用な証拠には、選択されたプロバイダータイプとマッピング決定が含まれ、シークレットや解決トークンは省略されます。

CapSolverボーナスコードを取得する

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

ステージ4: 結果を元のフォーム試行にルーティングする

4番目のステージでは、選択されたフォームとウィジェットの関連性が現在のままである場合にのみ、ソルバーの結果を受け入れます。

解決をリクエストする前に、試行を「選択されたCAPTCHA情報に待機中」とマークしてください。非同期操作が戻ってきたら、ページ生成とウィジェットの関連性を再確認してください。サポートダイアログが閉じたり、そのCAPTCHAが更新された場合、元の結果をフィードバックフォームに再割り当てしてはなりません。

CapSolverはsolve_on_pageをページレベルのパイプラインとしてドキュメント化しており、情報、解決、フィルステータス、エラーを含む結果を返します。そのリストされたオプションにはウィジェットセレクターは含まれていません。自身の検証済み統合が必要なスコープを確立しない限り、このメソッドをフォームスコープの操作として説明しないでください。手動のsolve(info)ステージは解決を返します。結果の配信だけで、正しいフォームが埋められたことを確立することはできません。

所有アプリケーションでは、既にウィジェットを所有しているコンポーネント統合を通じて答えをルーティングしてください。このアプリケーション固有のステップをプロバイダー検出から分離してください。グローバルな「最新トークン」変数は、結果がどのフォームに属するかを説明するのが難しく、フォーム間のミスを隠す可能性があります。

このステージの出力は、現在のコンポーネントに渡される、もう必要ない、または関連性が変更されたため拒否されるという処置です。提出前にどの処置が発生したかを記録してください。ソルバーのエラーは、関係のないフィードバックウィジェットを触らないでください。

ステージ5: 意図された送信を検証し、証拠を保持する

最終ステージでは、サポートリクエスト自体を検証し、ソルバー、ルーティング、アプリケーションの失敗を区別する十分なコンテキストを記録します。

Googleのサーバーサイド応答検証ガイドでは、応答トークンの検証が必要であり、トークンは1回限りで2分後に有効期限が切れることを示しています。これらのルールは、ソルバーの別個の結果取得ウィンドウと混同してはなりません。所有アプリケーションは、プロバイダー固有のバックエンド検証を実行する必要があります。

QAハーネスは、アプリケーションの実際の完了シグナルを検査する必要があります。サポートポータルの場合、これは所有バックエンドが返すテストリクエスト参照かもしれません。緑色のウィジェットや埋められた応答フィールドだけでは、正しいサポートリクエストが受け入れられたことを確立できません。

テストケース参照、フォーム参照、ウィジェット生成、ソルバー処置、バックエンド検証処置、意図された操作結果を含むコンパクトな結果を保存してください。これらは提案されたアプリケーションフィールドです。通常のログには、生の解決トークン、実際のサポートメッセージの内容、資格情報を保存しないでください。

テストが失敗した場合、最後に成功したステージを保持してください。「ウィジェットマッピングが見つからない」「ソルバーがエラーを返す」「アプリケーションが送信を拒否する」は、異なる修正が必要です。このステージ履歴は、1つの区別できないCAPTCHAエラーよりも調査に役立ちます。

どのマルチウィジェットケースをテストすべきですか？

有用なテストマトリクスでは、ウィジェットの順序とライフサイクルを変更しながら、意図されたフォーム操作を一定に保ちます。

所有ページのテストケース	期待されるワークフローの動作
フィードバックウィジェットがサポートウィジェットの前に表示される	エージェントはサポートフォームのウィジェットを選択し続ける
両方のフォームがサイトキーを共有する	フォームの関連性が選択を決定する
解決中にサポートダイアログが閉じる	結果はもう必要ないとして記録される
解決中にサポートウィジェットが更新される	古い結果は置き換えに割り当てられない
関係のないウィジェットがエラーを報告する	エージェントは意図された操作を変更しない
意図されたフォームに一意のウィジェットマッピングがない	ソルバー要求の前にワークフローが停止する
バックエンドが送信された応答を拒否する	テストは検証失敗として報告される、成功ではない

制御されたフィクスチャでマトリクスを実行し、許可された範囲でサポートされている本格的な統合を別途テストしてください。フィクスチャテストはローカルルーティング動作を確立しますが、外部のソルバーまたはプロバイダーチェックサービスが動作することを証明するものではありません。

この問題は、一度に複数の独立したソルバータスクを起動することとは異なります。複数のreCAPTCHAチャレンジを同時に処理する方法に関する既存のガイドは、同時タスク処理をカバーしています。複数のウィジェットがあるページでは、1つの意図されたアクションとその特定のウィジェットの関係を保持するというより難しい要件があります。

この順序でワークフローを構成してください: フォームを選択し、そのウィジェットの関連性を保持し、サポートされているソルバー情報を選択し、結果をルーティングし、アプリケーションの結果を検証します。所有権チェックが明確でテスト可能な場合、CapSolverをソルバーのステージに追加してください。

FAQ

Q: reCAPTCHAの検出はエージェントにどのフォームを送信すべきかを教えてくれますか？

検出は意図されたフォームを確立しません。エージェントは解決をリクエストしたり、何らかのものを送信する前に、アプリケーションのタスク範囲と明示的なフォームからウィジェットへの関連性が必要です。

Q: 同じページに2つのウィジェットが同じサイトキーを使用できますか？

ページはウィジェット間で統合構成を再利用できるため、サイトキーは一意のフォーム試行識別子として扱ってはなりません。ウィジェットインスタンスと所有フォームマッピングを一緒に使用してください。

Q: 最初のCAPTCHA情報レコードを選択できますか？

所有ページマッピングが意図されたウィジェットであることを確認した場合にのみ、最初のレコードを選択してください。リスト内の位置は所有権を確立しません。ページの変更により、最初に表示されるコンポーネントが変化する可能性があります。

Q: AIエージェントは見つかったすべてのCAPTCHAを解決する必要がありますか？

エージェントは、許可された操作で必要なサポートされているチャレンジのみを解決する必要があります。関係のないウィジェットは、同じページに表示されていてもタスクの外にあります。

Q: 解決中にページが変更された場合、何が起こりますか？

ワークフローは結果を使用する前にページとウィジェットの関連性を再確認する必要があります。元のコンポーネントが置き換えられたり、試行が終了した場合、結果を未使用として記録し、他の場所にルーティングせず、その試行を停止してください。