プロンプトと適用範囲
あるチームが、ブラウザのネットワークインターセプトをプライベートなデバッグプロトコルから WebDriver BiDi へ移行しようとしています。セッション設定、イベント購読、インターセプトのライフサイクル、並行処理の分離、および障害復旧をどのように設計するか説明してください。
面接官が評価するポイント
- BiDi が WebDriver の双方向・イベント駆動型プロトコルであり、現在も W3C Working Draft であることを理解しているか。
- セッション、コンテキスト、インターセプト ID、リクエスト ID、およびイベント購読の責務を区別できているか。
- テスト間の相互汚染を防ぐため、URL パターン、フェーズ、コンテキストによってインターセプトのスコープを限定できているか。
- 単にスクリプトを提示するだけでなく、タイムアウト、キャンセル、切断処理、マスキング（redaction）を設計できているか。
明確化のための質問
- テストはトラフィックを監視するだけですか、それともリクエストまたはレスポンスのフェーズで変更/ブロックしますか？
- ブラウザ、ドライバー、ランタイムは必要な BiDi モジュールをサポートしていますか？
- 各テストがブラウザコンテキストを所有しますか？また、ルールとイベントログはどのくらいの期間保持されますか？
- 障害発生時、実際のネットワーク通信を復元すべきですか、それとも診断情報とともに対象テストを即座に失敗させるべきですか？
30秒の回答フレームワーク
テストごとに独立した BiDi セッションとブラウジングコンテキストを作成し、機能をネゴシエーションして、必要なイベントのみを購読します。ルールは URL、フェーズ、コンテキストを制約し、beforeRequestSent などのイベントによって、リクエスト ID ごとに「続行」「ブロック」「モックレスポンスの提供」という単一の決定が下されます。すべてのルールにはタイムアウトとクリーンアップフックを設定します。切断時は変更処理を停止してテストをインフラ障害として失敗させ、ログにはマスキングされたメタデータのみを保持します。本番トラフィックがこのインターセプターを使用することは決してありません。
段階的な詳細解説
1. プロトコルと実装の境界を確認する
WebDriver BiDi は双方向のイベント駆動型通信に WebSocket を使用します。W3C 2026年6月1日バージョンは依然として Working Draft です。クライアントは、ドラフトのフィールドがどこでも安定していると仮定するのではなく、ドライバーとブラウザの capability を読み取る必要があります。従来の WebDriver HTTP コマンドと BiDi イベントは共存できますが、各状態に対して責任を持つチャネルは1つに限定しなければなりません。
2. 独立したセッションとコンテキストを作成する
テスト開始時に、セッションと独立したブラウジングコンテキストを作成し、セッション、コンテキスト、テスト実行 ID のマッピングを記録します。各インターセプトルールに一意のインターセプト ID を割り当て、必要な URL パターン、フェーズ、コンテキストにのみバインドします。ティアダウン（終了処理）時には、購読解除、インターセプトの削除、コンテキストのクローズを逆順で実行し、ルールが次のテストに漏洩しないようにします。
3. イベントとインターセプトの判定を設計する
session.subscribe でネットワークイベントを購読し、各イベントのリクエスト ID を使用してテスト状態を特定します。マッチしたリクエストは、サポートされているフェーズで「続行」「ブロック」「レスポンスの提供」のいずれか1つの明示的なアクションを受け取ります。判定レイヤーには冪等性キーとタイムアウトが必要です。未知のリクエスト ID、重複イベント、サポートされていないフェーズが発生した場合は、暗黙的に続行するのではなく、観測可能なエラーとして扱います。
4. 並行性、切断、およびセキュリティを処理する
並行実行されるテストは、変更可能なインターセプトテーブルを共有してはなりません。各コンテキストが自身のルールとイベントバッファを所有します。WebSocket 切断時は、トラフィックの変更を停止し、テストをインフラ障害としてマークし、URL、ステータス、タイムラインをマスキングして保持した上でクリーンアップを行います。ヘッダー、Cookie、ボディ、トークンはデフォルトでマスキングします。有効期間の短いテスト用認証情報を使用し、テスト用ブラウザでのみ実行し、本番ドメインに対して実行してはなりません。
質の高い模範解答
私は BiDi をプロトコルの境界として扱い、特定の自動化ライブラリのルート API を単に真似るようなことはしません。各テストは独立したセッションとブラウジングコンテキストを取得し、capability を読み取り、必要なネットワークイベントを購読します。インターセプトには一意の ID が付与され、URL パターン、フェーズ、コンテキストによって制限されます。イベントはリクエスト ID を使用して、続行、ブロック、またはモックのいずれか1つの決定を下します。ティアダウンでは購読解除、ルールの削除、コンテキストのクローズを逆順に行います。すべてのアクションにタイムアウト、冪等性、診断記録を持たせます。WebSocket の切断が発生した場合は、不明な状態でトラフィックを変更し続けるのではなく、インフラ障害としてテストを失敗させてクリーンアップします。ログはマスキングされ、テストブラウザは本番環境から分離され、互換性の違いは capability マトリックスで明示されます。
よくある間違い
- すべてのブラウザやドライバーで Working Draft のフィールドが安定した API であるかのように扱うこと。
- コンテキスト、フェーズ、テスト実行のスコープを定めず、URL のみでグローバルにインターセプトすること。
- 事前の購読を怠ったり、イベント ID、インターセプト ID、コンテキスト ID を混同したりすること。
- 切断後も変更リクエストを送信し続け、結果の解釈を不能にすること。
- ティアダウン後にインターセプトルールをアクティブなまま放置し、後続のテストを汚染すること。
- Cookie、Authorization、レスポンスボディをそのままログに出力すること。
- 本番ブラウザや実際のユーザートラフィックでテスト用インターセプターを有効化すること。
フォローアップ質問と回答
BiDi は従来の WebDriver とどのように共存できますか？
従来の WebDriver は命令型の制御に適しており、BiDi は継続的なイベントやネットワークの監視に適しています。これらはブラウザセッションを共有できますが、両方のチャネルが同一コンテキストを同時に変更しないよう、状態の所有権とシャットダウンの順序を明示する必要があります。
なぜインターセプトルールにフェーズが必要なのですか？
リクエスト送信前、レスポンス開始時、レスポンス完了時で利用可能なデータが異なるためです。フェーズを指定することで変更可能な対象が定まり、実行時に推測するのではなく、サポートされていないフェーズを早期に失敗させることができます。
テスト間の相互汚染がないことをどのように証明しますか？
すべてのテストに独自のコンテキストとインターセプト ID を割り当て、ティアダウン時にそのコンテキストのルールを照会してクリアし、分離チェックを実行します。購読、キャンセル、クローズの各イベントを記録することで、障害発生時にも完全なタイムラインが保持されるようにします。