WebDriver BiDi とは何ですか？

Scrapeless Agent Browser は、管理されたブラウザー自動化と動的なページ操作のために CDP 接続を公開します。

WebDriver BiDi は、クライアントからのコマンドとブラウザーからのイベントを双方向接続でやり取りするブラウザー自動化プロトコルです。BiDi という名前は bidirectional（双方向）を意味します。このプロトコルにより、制御側のソフトウェアは、ブラウザーの現在の状態を尋ねる個別のリクエストとしてあらゆる観測を表現するのではなく、ブラウザーの活動を発生時に観測できます。

WebDriver BiDi は W3C 仕様として開発中であり、その実装サポートはブラウザー、クライアントライブラリ、機能によって異なります。プロトコルは定義された自動化インターフェイスとして扱い、そのうえでプロジェクトに必要な具体的な操作が利用可能か検証してください。WebSocket を用いたブラウザー接続があるだけでは、その接続が BiDi を話すという十分な証拠にはなりません。

ブラウザー自動化にイベントが必要な理由

ブラウザーイベントは、次のクライアントコマンドによって開始されない動作を自動化側から観測できるようにします。ページは、クライアントが他の処理をしている間にもコンソールメッセージを書き込んだり、別のブラウジングコンテキストを開いたり、ネットワークリクエストを開始したりできます。

コマンドとレスポンスによるやり取りでは、クライアントは動作や状態を要求し、その結果を受け取ります。このモデルはナビゲーションや要素操作には引き続き有用です。一方で、クライアントがブラウザーによって独立に生成される観測のストリームを必要とするときには、直接的ではありません。

この WebDriver BiDi 仕様 は、双方向メカニズムとそのコマンドおよびイベントを定義しています。このイベントモデルは、アクションが完了した後だけを確認するのではなく、ワークフロー全体を通じて関連ログを収集するといったタスクを表現するのに役立ちます。

イベントが完了条件の必要性を無くすわけではありません。コンソールメッセージは、アプリケーションの準備完了を証明しないまま、有用な診断証拠になりえます。どのイベントやページ条件がタスクの意図された状態に対応するのかを決めてください。

コマンド、結果、イベントは異なる役割を持つ

BiDi のコマンドはブラウザー操作を要求し、コマンドレスポンスはその結果を報告し、イベントは購読しているクライアントに配信されるブラウザーの活動を記述します。これらの役割を区別しておくことで、メッセージ順序に関する誤った前提を防ぎます。

クライアントは、他のブラウザー活動がすでに進行中でも操作を送信できます。接続は、ブラウザー側の動作によっては、コマンドレスポンスの前後いずれかにイベントを運ぶことがあります。コマンドレスポンスはそのリクエストと関連付け、イベントは関連するコンテキストおよびサブスクリプションを通じて解釈してください。

どのメッセージの到着も、処理を先に進めてよいという許可とみなしてはいけません。ナビゲーション関連のイベント、スクリプト結果、ログエントリは、それぞれ異なる問いに答えます。クライアントは、観測結果をそれが関係するページやアクションと結び付ける必要があります。

診断的なワークフローでは、観測ウィンドウを定義してください。観測したい活動の前に購読を開始し、その活動を説明するのに必要な情報を保持し、ジョブに不要になったら購読を解除します。そうしないと、長時間生存するクライアントは無関係な作業からの観測を蓄積してしまいます。

ブラウジングコンテキストはイベントの場所を与える

ブラウジングコンテキストは、トップレベルページや埋め込みフレームなど、ブラウザー活動が行われる場所を識別します。複数のページが類似したイベントを発行しうる場合、コンテキストの識別が重要になります。

ポップアップは、それを開いたページとは異なるトップレベルコンテキストに属しているかもしれません。iframe は親ページの内部で独立してナビゲートできます。クライアントがすべてのイベントが最初に開いたドキュメントに属すると仮定していると、抽出やテストに誤った証拠を結び付けてしまう可能性があります。

見えているタイトルだけに頼るのではなく、タスクに必要なコンテキストを追跡してください。タイトルや URL は変わることがあり、別々のコンテキストが一時的に同じアドレスを表示することもあります。コンテキスト識別子はプロトコルレベルの参照を提供し、URL とタイトルは人間にとって読みやすいコンテキストを提供します。

ナビゲーションはスクリプト環境にも影響します。あるドキュメントから取得した値が、同じタブ内で後から読み込まれたドキュメントを記述していると想定すべきではありません。ワークフローはコンテキストとその現在のドキュメントのライフサイクルを中心に構築してください。

従来の WebDriver、BiDi、CDP は異なるインターフェイス

従来の WebDriver、WebDriver BiDi、Chrome DevTools Protocol は、それぞれ異なるブラウザー制御インターフェイスを提供します。ライブラリは複数をサポートできますが、サポートは対象ブラウザーと操作ごとに確認しなければなりません。

この WebDriver リモートインターフェイス は、従来のセッションとコマンドを理解するための基盤であり続けます。BiDi は、既存のすべてのコマンド名やトランスポートを相互に置き換え可能にするのではなく、標準化された双方向プロトコルを追加します。

WebSocket はトランスポートであり、互換性の保証ではありません。CDP エンドポイントと BiDi エンドポイントは、どちらも永続的な接続を利用しつつ、異なるメッセージを受け付けることがあります。一方のプロトコルのコマンドを他方に送ることは移行戦略にはなりません。

サブスクリプションのスコープは観測可能性をどう変えるか

サブスクリプションは、プロトコルのイベントルールに基づいてクライアントが受信するブラウザーイベントを決定します。有用なサブスクリプションは、ワークフローに必要な観測情報を含め、不要なアクティビティを除外します。

認証済みアプリケーションページを開き、必要なレコードを確認するテストを考えてみましょう。ブラウザログは、そのレコードが表示されなかった理由を診断するのに役立つ場合があります。その操作の前後でログを収集することで、共有セッションの閲覧履歴全体を保持することなく、関連する一連の動作を保存できます。

ネットワーク観測には、URL やアカウントに関連するメタデータなど、機密情報が含まれる可能性があります。収集はタスクの範囲内に限定し、保持する成果物から秘密情報を編集（マスキング）し、診断の必要性に見合った保持ポリシーを選択してください。

サブスクリプションのクリーンアップは、クライアントの正しさの一部です。再利用されたセッションが完了したタスクからイベントを送り続けると、後続のタスクがそれらを誤って解釈する可能性があります。ジョブの境界を持たないグローバルなイベントコレクターに依存するのではなく、サブスクリプションとコンテキストマッピングの所有権を明示的に維持してください。

機能ごとに実装サポートを確認する必要があります

BiDi サポートは、オートメーションスタック全体に対する単一のイエス・ノーのラベルではなく、機能レベルの互換性に関する問題です。ブラウザーのバージョン、リモート環境、言語バインディングはすべて、利用可能な操作に影響を与える可能性があります。

「The」 Selenium 双方向自動化モデル クライアントエコシステムがこれらの機能をどのように公開しているかを示しています。別のバインディングの例を当て推量で翻訳するのではなく、使用している言語とリリース向けの API を確認してください。

ワークフローのための簡潔な互換性インベントリを作成してください。必要なイベントファミリー、スクリプト操作、コンテキスト処理、およびネットワーク機能を含めてください。どれが必須で、どれが任意の診断用補助機能かを明示してください。そのうえで、そのインベントリを実際の環境に対してテストしてください。

BiDi 接続を広告しているブラウザがあるからといって、特定のモジュールが完全であることや、リモートプロバイダーがそれを公開していることが証明されるわけではありません。意味のあるテストとは、必要な操作を実行し、代表的な条件下で期待される応答やイベントを観察することです。

プロトコルのサポートとデータの正確性は分けて考えてください。有効なイベントストリームは、誤った抽出ルールと共存し得ます。ワークフローを採用する前に、自動化インターフェースとページレベルの結果の両方を検証してください。

すべてを書き換えることなく BiDi を導入する計画

BiDi の導入は、既存の自動化と並行して、範囲を限定した観測要件から始めることができます。利点が明確で、その挙動を単独でテストできる機能を選びましょう。

たとえば、チームがアプリケーションフローの障害発生時にブラウザログの収集を必要とする場合があります。関連するコンテキストを定義し、アクションの前にサブスクライブし、期待される診断エントリが正しいページに関連付けられていることを確認します。新しい観測パスを評価する際は、確立済みのナビゲーションおよび抽出チェックを維持してください。

プロトコルの移行を、性能や信頼性の向上を証明するものとして扱わないでください。そうした結果は、クライアント実装やワークロードに依存します。速度やリソース使用量が判断材料の一部である場合は、代表的なジョブを計測してください。

接続の作成、イベント購読、およびセッション終了の責任の所在を文書化してください。アプリケーションがライフサイクルの決定を担う明確な単一の箇所を持っていると、プロトコル機能の保守が容易になります。

プロトコルの選択において Scrapeless Agent Browser が位置づけられる場所

スクレイプレス エージェント ブラウザー CDP ベースのブラウザー接続を文書化し カスタム CDP 機能. 文書化された CDP インターフェイスは、WebDriver BiDi のサポートを確立しません。

アプリケーションに対して双方向（BiDi）が必須要件である場合は、ブラウザホスティング方式を選択する前に、その要件を明示的に確認してください。必要なワークフローが既に文書化された CDP クライアントを使用している場合は、その経路をそれ自体の観点から評価してください。適切な選択は、その作業で実際に必要とされるプロトコル機能に従います。

その Selenium 自動化に関する議論 ブラウザー主導のワークフローに関する関連コンテキストを提供します。レビューしてください。 スクレイプレス・プラン 接続と機能の要件が明確になってからのみ。

結論

WebDriver BiDi は、コマンドとブラウザー生成イベントを双方向の自動化プロトコルにもたらします。その価値は、正確なコンテキスト追跡、スコープされたサブスクリプション、および検証された機能サポートに依存します。具体的な操作を中心にインターフェイスを選択し、プロトコル互換性と、ブラウザーが生成するデータの正確性とを明確に区別してください。