Stagehand CAPTCHA処理: ブラウザ操作 vs ソルバー

TL;DR

• Stagehandのブラウザ操作とCAPTCHAの解決には異なる役割があります。1つはページを制御し、もう1つはサポートされている認証チャレンジを処理します。
• サーバー上でブラウザが実行されているか確認してください。ホストされたセッションでは、既にCAPTCHA処理が有効になっている可能性があります。
• BrowserbaseはサポートされているCAPTCHAの自動解決をドキュメント化していますが、これによりすべてのローカルなStagehandブラウザが管理された解決セッションになるわけではありません。
• CapSolverなどの別サービスは、明確な統合境界が必要です。返されたトークンはブラウザタスクの完了を意味しません。
• 各チャレンジに対して1つのコンポーネントを選択し、エージェントが次のステップに進む前に、期待されるページの結果を確認してください。

AIエージェントは、検索フィールドを見つけてクエリを入力し、結果を選択することができても、CAPTCHAチェックポイントで助けを必要とすることがあります。"検索を完了する"という指示を改善しても、そのチェックポイントの処理方法を定義するものではありません。

StagehandとCapSolverを検討しているチームにとって、最初の決定はCAPTCHA解決がどこにあるべきかです。このガイドでは、責任とデプロイメントの選択肢を比較します。これは特定のStagehand-to-CapSolverアダプタがインストールされテストされているという主張ではなく、選択ガイドです。

CAPTCHAが表示される前にStagehandは何を行いますか？

Stagehandは、アプリケーションがインタラクションを記述し、ページデータを抽出するためのブラウザ自動化の基本的なプリミティブを提供します。

公式のStagehand actドキュメンテーションではページのインタラクションが説明されており、抽出ドキュメンテーションでは構造化された情報を取得する方法が説明されています。これらは、承認された製品カタログを読み取るや、所有するアプリケーション内の情報を確認するなどのタスクのための有用な構築ブロックです。

一般的なタスクには明確なビジネス目的があります。たとえば、製品ページを開き、指定されたモデルの在庫を返すことです。CAPTCHA処理はそのタスク内の可能性のある中断です。これはタスクの目的を置き換えてはなりません。

この区別はAIウェブスクレイピングにおいて重要です。エージェントが間違ったページからテキストを成功裏に抽出する可能性があります。認証画面が製品一覧表示の代わりに表示されている場合、うまく構造化された答えを出しても、要求されたデータが取得されたことを示しません。

したがって、アプリケーションはページの状態と必要な結果の両方を識別する必要があります。"ツールが返した"と"正しい製品が読み取られた"は異なる主張です。

ブラウザ操作とCAPTCHAソルバー：どのコンポーネントが何を担当するのか？

ブラウザ操作はナビゲーションとインタラクションを担当し、CAPTCHAソルバーは割り当てられたサポートされているチャレンジ操作を担当します。

責任	ブラウザ操作レイヤー	CAPTCHA解決レイヤー
要求されたページを開く	許可されたタスク内でナビゲートする	ナビゲーションを置き換えない
意図したフォームやレコードを選択する	現在のページコンテキストを使用する	正しいチャレンジコンテキストが必要
サポートされているCAPTCHAを処理する	ワークフローに応じて一時停止または委譲する	文書化された解決策を生成または適用する
ビジネスタスクを再開する	チェックポイントが解決された後に継続する	ビジネス結果を決定しない
要求された結果を確認する	正しいページとデータをチェックする	ソルバーの完了だけでは不十分

これらの役割はブラウザプロバイダーによってパッケージ化されることがあります。また、個別に実装することも可能です。パッケージ化の変更は誰が接続を維持するかを変更しますが、チャレンジ結果と要求されたビジネス結果の区別は残ります。

例えば、カタログエージェントは選択されたモデルの在庫を返すべきです。ソルバーの結果は、モデル、国、バリアントが正しいかどうかをアプリケーションに伝えられません。これらのチェックはタスク自体に属します。

両方のレイヤーに制御不能な権限を与えないようにしてください。ページ操作が継続的にクリックし、別のコンポーネントがチャレンジを処理していると、ワークフローが診断しにくくなります。その間、どのコンポーネントが責任を持つのかを定義してください。

ブラウザ環境が選択に与える影響は？

ブラウザ環境は、すでに利用可能なCAPTCHA機能と、アプリケーションが供給しなければならない機能を決定します。

Stagehandの現在のブラウザ設定ドキュメンテーションでは、マネージドなBrowserbaseブラウザ、ローカルブラウザ、およびCDPを介した既存のChromiumブラウザへの接続が説明されています。実際の実行で使用する環境を特定するための実用的な出発点です。

フレームワーク名から環境を推測しないでください。開発マシンとホストされたデプロイメントは、ビジネスタスクが同じでも異なるブラウザサービスを使用する可能性があります。

BrowserbaseセッションでのStagehand

BrowserbaseのCAPTCHA解決ドキュメンテーションでは、セッションで解決がデフォルトで有効になっており、プロセスの開始と終了のイベントが説明されています。また、その動作を無効にする構成もドキュメント化されています。

この環境をすでに使用しているチームは、追加のプロバイダーを追加する前に、セッション設定とドキュメント化された解決動作を確認してください。チャレンジがサポートされているか、ブラウザがすでに処理を開始しているかを確認してください。

サポートされている動作がニーズに合致し、保守するコンポーネントを減らしたい場合、マネージドオプションは合理的な最初の選択肢です。実際に使用する許可されたページに対して評価してください。機能の説明がすべてのチャレンジやすべてのサイトの最終的な受け入れを保証するとは考えないでください。

ローカルまたは別途ホストされたブラウザでのStagehand

ローカルブラウザは、Stagehandが制御していてもBrowserbaseのホスト機能を自動的に取得しません。

選択したブラウザ環境が必要な解決機能を提供していない場合、別の統合が適切かもしれません。アプリケーションは、チャレンジを識別し、文書化された入力を提供し、結果を受信し、正しいブラウザコンテキストに適用する方法が必要です。

この作業は、小さな受け入れテストを持つ統合プロジェクトとして扱う必要があります。ホストセッションの例をローカル設定にコピーし、周囲のサービスが存在すると仮定しないでください。

既存のリモートブラウザの場合、接続とブラウザのライフタイムを誰が制御しているかを確認してください。別のタブや放棄されたセッションに接続された解決操作は、エージェントの現在のタスクが継続可能であることを証明しません。

CapSolverはStagehandワークフローでどこに適合するか？

CapSolverは、明確に設計されたブラウザ統合の裏側でサポートされているCAPTCHAサービスを提供できます。

CapSolverの自動化統合概要では、ブラウザ自動化のAPIおよび拡張アプローチが説明されています。APIアプローチでは、アプリケーションコードが文書化されたリクエストと結果の処理の責任を負います。拡張アプローチでは、適切なブラウザ環境とその拡張機能のサポートに依存します。

使用するブラウザ、チャレンジタイプ、および必要な制御に基づいて選択してください。ブラウザ自動化で使用可能であることは、ネイティブなStagehandプラグインまたはユニバーサルなワンライン設定の証拠ではありません。

CapSolver Core SDKは、検出、パラメータ読み取り、トークン解決、ブラウザへの入力のPythonメソッドを提供します。文書化されたトークンモードのカバー範囲にはreCAPTCHA v2/v3とTurnstileが含まれますが、画像グリッドのクリックやスライダーのドラッグは含まれていません。これは、特定のコンポーネントがチャレンジに適合するかどうかを決定する際に重要です。

同じドキュメンテーションでは、Playwrightページを用いたブラウザメソッドが説明されています。他のフレームワークで名前が「page」とされているオブジェクトが交換可能であると仮定しないでください。SDKや言語をまたぐ設計の場合、提案された接続が動作することを証明してから、運用可能な統合として提示してください。

大きなビルドなしで有用な評価を開始することは可能です。正確なブラウザ、サポートされているチャレンジ、選択されたCapSolverパス、および最終的なページ状態を文書化してください。その後、所有または明示的に承認された環境で最小限の完全なパスをテストしてください。

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

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

エージェントがチャレンジに到達したときに何が起こるべきか？

チャレンジは、明確な戻り条件を持つ制御されたオフロードをトリガーすべきです。

仮想のディストリビューターのカタログワークフローを考えてみましょう。エージェントは、承認された製品ページを開き、特定の部品の在庫を報告する必要があります。以下のシーケンスは、デプロイされたカスタマーアイテムの記録ではなく、提案された設計です：

1. 適切なカタログページに移動し、要求された部品を識別します。
2. ページがビジネスアクションに準備ができているか、またはCAPTCHAが表示されているかを確認します。
3. サポートされている、許可されたチャレンジが存在する場合、選択された解決コンポーネントにそのステップの制御を渡します。
4. 結果または制限付きの失敗を待つことにより、関係のないページ操作を続けるのではなく、明確な結果を待ちます。
5. 現在のページを再確認し、要求された部品と在庫を読み取ります。
6. チャレンジまたはビジネスステップが解決されていない場合、不完全な結果を返します。

このシーケンスは、ソルバーの後に2つの有用なチェックを残します。ページが期待される状態に移動したか、データが要求されたアイテムに属しているか？

エージェントの指示をこれらの観測可能な結果に焦点を当ててください。広範な指示「成功するまで繰り返す」は、有用な制限や完了の明確な定義を与えません。

より広範な中断パターンについては、AIエージェントのタスクがCAPTCHAで詰まる理由のガイドが、繰り返しのナビゲーションと解決がループを形成する理由を説明しています。Stagehandの設計では、次のアクションが可能なコンポーネントと、それが継続するための証拠がどのようになるかという質問が重要です。

コストとメンテナンスをどのように比較するか？

単一のソルバー要求をタスク全体と見なすのではなく、全体のワークフローのコストと統合の努力を比較してください。

ホストオプションは、チームが維持する接続の数を減らす可能性があります。別個のソルバーは、サービスコール、タスクの診断、プロバイダーの選択の直接的な制御を提供します。どちらも自動的にあなたのワークロードに安くはありません。

観測可能な実際のコストを評価してください。ブラウザの実行時間、モデル呼び出し、ソルバーの使用、失敗した試行、およびエラーの診断にかかるエンジニアの時間。使用不可能なページで解決されたチャレンジを成功したビジネス結果として数えないでください。

また、変更の所有権も考慮してください。チャレンジが動作しなくなった場合、原因がブラウザの設定、リクエストフィールド、サービスの障害、またはアプリケーションの検証にあるかどうかをチームが特定できるか？必要な証拠を公開するアプローチは、短期的な設定例だけを選択するよりも維持が簡単かもしれません。

関連するサイトからのパフォーマンスの主張ではなく、代表的な許可されたパイロットを使用してください。評価中にブラウザタスク、期待される出力、および受け入れ条件を一貫して保ちます。

どのアプローチを選ぶべきか？

既存のブラウザ環境に適合し、最小限の不要な統合作業で必要なページ結果を示すアプローチを選択してください。

すでに利用可能なマネージドブラウザのサポートされた処理がタスクを満たしている場合、それを最初に選択してください。現在の環境が提供しないサポートされているCAPTCHA機能やサービス制御が必要な場合、別個のCapSolver統合を検討してください。

どちらのアプローチを採用する前に、4つの実用的な質問に答えます：

• 指定されたページで自動化は許可されていますか？
• 選択された解決パスは実際のチャレンジをサポートしていますか？
• ワークフローはページを保持し、クリーンに制御を戻すことができますか？
• アプリケーションは完全な結果と未解決のチェックポイントを区別できますか？

パイロットには、通常のページ、サポートされているチャレンジ、および未解決のチャレンジが含まれるべきです。未解決のケースは価値があります。エージェントが有用な制限を報告するのか、成功を偽造するのかを示します。

同じチャレンジに対して複数の解決パスを有効にしないでください。後でフォールバックを導入する場合、移行を定義し、次のコンポーネントが制御を引き継ぐ前に最初の試行が終了したことを確認してください。

CapSolverで信頼できる自動化ワークフローを構築する

Stagehandはエージェントにページとインタラクションする方法を提供します。CAPTCHA解決には、独自のサポートされたパスとワークフロー内の明確な場所が必要です。ブラウザ環境がそのパスのどの部分が既に存在するかを決定します。

CapSolverを特定の、承認されたブラウザタスクに対して評価してください。統合を確認できるほど小さくし、エージェントが正しいページに到達し、要求された結果を返すときにのみ受け入れてください。

FAQ

Q: StagehandはすべてのCAPTCHAを自動的に解決しますか？

Stagehandを使用したからといって、すべてのCAPTCHAを自動的に解決するという万能の保証はありません。CAPTCHA処理はブラウザ環境、その構成、およびサポートされているチャレンジに依存します。Browserbaseはそのセッションで自動解決をドキュメント化しています。ローカルブラウザは独自の適切なパスが必要です。

Q: Stagehandのプロンプトを変更することでCAPTCHAを解決できますか？

プロンプトはエージェントに一時停止するタイミングと確認する結果を伝えることができますが、サポートされているCAPTCHA解決サービスを作成することはできません。ワークフローには、適切なブラウザ機能または統合が必要です。

Q: CapSolver Core SDKはネイティブなStagehandプラグインですか？

提示されたCore SDKドキュメンテーションはPython SDKとPlaywrightベースのブラウザメソッドを説明しています。これはネイティブなStagehandプラグインを確立するものではありません。提案された接続は、関連する実行時環境とインターフェースに対して検証する必要があります。

Q: マネージドソルバーとCapSolverを同時に有効にすべきですか？

各チャレンジに1つのアクティブな処理パスを提供してください。調整なしに両方を有効にすると、所有権と失敗の診断が不明確になります。2番目のプロバイダーを明確なオフロードを通じて評価してください。同時に試行するのではなく。

Q: 私のエージェントでCAPTCHA処理が機能したことが証明されますか？

解決ステップが適切に終了し、アプリケーションが意図したページ状態に到達し、正しいタスク結果を返す必要があります。トークン、ツールの応答、またはプロバイダーのイベントだけでは十分ではありません。