WebDriver BiDiとは何か？

Scrapeless Agent Browser は、ブラウザー自動化クライアント向けに、ドキュメント化された接続インターフェイスを通じて管理されたブラウザーセッションを提供します。

WebDriver BiDi は、ブラウザーをリモート制御しブラウザーイベントを受信するための双方向プロトコルです。「BiDi」は双方向の通信を指し、自動化クライアントがコマンドを送信し、購読されたアクティビティが発生したときにブラウザーがイベントメッセージを送信できます。このイベント駆動モデルは、繰り返しのリクエスト＆レスポンスの問い合わせだけでは表現しにくい観測をサポートします。

WebDriver BiDi はプロトコルであり、ブラウザー、テストランナー、ホスティングサービスではありません。W3C 仕様はまだ作業中であり、実装ごとに対応しているモジュールやコマンドが異なる場合があります。したがって評価には、「そのスタックが“BiDiに対応している”」という一般的な主張ではなく、実際のブラウザー、クライアントバインディング、プロトコル機能、およびタスクに必要な操作が必要になります。

双方向通信がもたらすもの

双方向通信により、クライアントが個々の発生ごとに問い合わせを行うのを待たずに、ブラウザーが関連するアクティビティを報告できるようになります。 WebDriver BiDi プロトコル は、ブラウザーの制御と観測のためのコマンド、レスポンス、イベント、トランスポート、およびモジュールを定義します。

従来のリクエスト＆レスポンス型のやり取りは、多くの操作にとって十分です。クライアントはナビゲーションを要求し、その結果を受け取ります。ドキュメントのコンテキストが変化したり、スクリプトがログエントリを生成したりといった、コマンドの合間にブラウザーがアクティビティを発生させる場合には、イベントベースの観測が有用になります。

重要な改善点は観測モデルであり、すべてのブラウザータスクが速くなるという約束ではありません。タスクが最終的なページタイトルだけを必要とするのであれば、イベントストリームが付加価値を持たない場合もあります。特定のナビゲーションとコンソールアクティビティを関連付ける必要があるタスクでは、サブスクリプションのほうが、スナップショットを定期的に問い合わせるよりも関連性の高い情報を提供できます。

イベントには責任も伴います。クライアントは、何を購読するか、メッセージをどう相関付けるか、どのイベントが完了にとって重要か、いつサブスクリプションを解放するかを決めなければなりません。無制限に観測を収集すると、有用な診断というよりも、保存と解釈の問題になりかねません。

コマンド、レスポンス、イベントには異なる役割がある

コマンドは操作を要求し、レスポンスはその結果を報告し、イベントは購読されたブラウザーアクティビティを記述します。これらのメッセージタイプは、一連の完了したアクションの順序リストとして扱うのではなく、その役割に応じて処理する必要があります。

コマンドレスポンスは、サポートされているプロトコル操作が完了したことを確認できます。イベントは、ページによって開始されたブラウザーアクティビティや、別の操作によって開始されたアクティビティが原因で到着することがあります。クライアントには、その観測を関連するドキュメント、タスク、ナビゲーションと結び付けるための十分なコンテキストが必要です。

イベントが存在することを、アプリケーションがビジネスゴールに到達した証拠として解釈してはいけません。ナビゲーションイベントはナビゲーションについて何かを伝えるにすぎません。タスクには、結果領域の表示、フォームの有効化、特定のアイテムの選択などが、まだ必要かもしれません。

タスクごとに小さな観測契約を定義しましょう。作業を開始するコマンド、有用な証拠を提供するイベント、成功を確立するページ条件、観測を終了するクリーンアップを特定します。これにより、すべての生メッセージを永遠に保持することなく、イベント駆動ワークフローをレビュー可能にできます。

イベント駆動型自動化ではコンテキストの識別が重要

コンテキストの識別は、そのイベントがどのページまたは埋め込みドキュメントに関するものかを決定します。ブラウザーは複数のトップレベルページと子ドキュメントを含み得るため、接続が 1 つの関心ドキュメントだけを意味するわけではありません。

この HTML ブラウジングコンテキストモデル は、ブラウザー内のドキュメントとそれらの関係の基礎となる区別を提供します。ポップアップ、ネストされたフレーム、ナビゲーションはいずれも、どのドキュメントを観測または制御すべきかに影響を与えます。

実用的な例として、別ページで領収書を開くアプリケーションがあります。開始クリックは元のページに属しますが、領収書の準備完了条件は新しいコンテキストに属します。元のドキュメントを読み続けるタスクは、ブラウザーが正常に領収書を開いているにもかかわらず、領収書は存在しないと結論づけてしまうかもしれません。

フレームの識別も同様の注意が必要です。埋め込まれたウィジェットからのログメッセージは、自動的に親アプリケーションに帰属させるべきではありません。診断記録ではコンテキストの識別を保持し、観測結果をそれを生成したドキュメントと結び付けられるようにします。

サブスクリプションにはスコープとライフタイムが必要

サブスクリプションは、そのタスクに必要なイベントとコンテキストを、そのタスクが必要とする期間だけカバーすべきです。これにより、診断ノイズと、無関係なページ情報を保持してしまう可能性の両方を抑えられます。

必要な証拠を生むアクティビティの前に観測を確立してください。アクションの直後にページが関連するイベントを生成し得る場合、その後からオブザーバーを取り付けるとギャップが生じる可能性があります。順序が自動的に処理されると想定せず、実際のクライアントバインディングのライフサイクル動作を確認してください。

収集後に何を保存するかを選択します。イベントタイプ、コンテキスト識別子、関連する結果の簡潔な記録で、ジョブサマリーとしては十分な場合があります。完全なログメッセージやネットワーク詳細には機密性の高いアプリケーションデータが含まれ得るため、保持する記録はトラブルシューティング要件に見合ったものにすべきです。

所有者が終了したらサブスクリプションを閉じてください。複数のタスクを制御する長寿命クライアントでは、以前のタスクのオブザーバーが後のタスクに誤って紐付くべきではありません。明示的な所有関係があれば、観測の欠落と、誤ったジョブに現れる観測の両方を説明しやすくなります。

WebDriver BiDi、Classic WebDriver、および CDP

WebDriver BiDi、classic WebDriver、そして Chrome DevTools Protocol は、それぞれ異なる制御インターフェイスです。ブラウザ自動化や WebSocket トランスポートを共用していても、互換的に入れ替えられることを意味しません。

この classic WebDriver コマンドモデル は、その標準化されたインターフェイスを通じてリモートブラウザ操作を定義します。BiDi は双方向プロトコルモデルを追加します。CDP は Chromium ツーリングに関連付けられた独自のコマンドおよびイベント面を持ちます。アプリケーションに必要な実際のブラウザカバレッジと操作に基づいて選択してください。

移行では、すべての操作を一度に置き換える必要はありません。BiDi を必要とする観測を特定し、選択したクライアントがそれを既存のブラウザ制御とどのように組み合わせるかを確認してください。広範な診断能力という限定的な要件しかない場合に、プロトコル全体の書き換えは避けましょう。

ブラウザサポートは操作ごとに評価する必要がある

WebDriver BiDi のブラウザサポートは、操作および環境ごとに評価する必要があります。接続が成功するとトランスポートは確立されますが、サポートされたサブスクリプションまたはコマンドは、より狭い機能を確立します。

この Selenium BiDi クライアントインターフェイス は、Selenium を利用するアプリケーションに実装コンテキストを提供します。実際の言語バインディングとブラウザの組み合わせを確認する必要がなくなるわけではありません。ある言語で実演された機能が、別の言語では異なるインターフェイスやサポート状況を持つ場合があります。

タスクに結びついた機能チェックリストを作成してください。必要な各操作について、ブラウザ環境、クライアントメソッド、期待されるプロトコル動作、およびそれが機能していると証明する条件を指定します。サポートされていない機能は明示的に記録し、イベントが存在しないことをアプリケーション結果が空であることと取り違えないようにします。

最新のドキュメントを確認せずに、古い実験用フラグや接続例を流用するのは避けてください。プロトコルの作業は進化しており、かつてプレビューフィーチャーを有効にしていた構成が、もはやサポートされる経路を表していないことがあります。本用語集は意図的に、未実行の接続コードや万能なサポート表を提供していません。

有用な BiDi 受け入れシナリオ

有用な受け入れシナリオは、イベントを目に見えるページ結果に結びつけます。制御されたテストアプリケーション上で、ページアクションが既知のドキュメントを開き、識別しやすい診断メッセージを発するように構成します。

アクションを開始する前に、必要なイベントカテゴリとスコープを購読します。アクションを実行し、新しいドキュメントコンテキストを特定し、対象ページの状態を検査します。期待される観測が期待されるコンテキストに属し、かつアプリケーションの結果が正しい場合にのみ、テストは合格となります。

クリーンアップも実行してください。観測を終了し、無関係な作業を行い、古いタスクが引き続き証拠を蓄積していないことを確認します。これは、多くの場合ハッピーパスの例では検証されないサブスクリプションの所有権をチェックします。

最終的なレポートでは、プロトコルの結果とビジネス上の結果を分けてください。失敗したサブスクリプション、閉じられたコンテキスト、不足しているページ記録は、それぞれ別個の説明を必要とします。この区別は、複数のインフラおよびアプリケーションレイヤーが独立して故障しうるリモート実行において、特に有用です。

Scrapeless で BiDi の概念を利用する

BiDi の概念はイベント駆動オートメーションの説明に役立ちますが、Scrapeless エンドポイントは、そのドキュメント化されたプロトコルを通じて使用する必要があります。 Agent Browser CDP surface は CDP 操作を文書化するものであり、WebDriver BiDi エンドポイントの証拠ではありません。

この Agent Browser プラットフォーム は、マネージドなブラウザ実行と観測機能を提供します。 ブラウザコンソールおよびセッション診断 に関する議論は関連する運用コンテキストを与え、 Scrapeless 料金 はワークロード計画を支援します。プロトコルの概念を製品連携に翻訳する前に、必要なインターフェイスを確認してください。

結論

WebDriver BiDi は、ブラウザイベントを制御の会話の一部にします。イベントベースの観測が明確な要件を解決するときにそれを使用し、コンテキストの識別、購読スコープ、完了条件、クリーンアップを一体として設計してください。互換性は、単なるプロトコル名ではなく、実際のブラウザとクライアントが実行できる操作によって確立されます。