ブラウザ自動化の録画FPSはどう選ぶ？agent-browser v0.37.0実践ガイド

ブラウザ自動化のレビュー目的からフレームレートを選ぶ

まずは30 fpsを基準にします。通常のクリック、ホバー状態、スクロール、CSSトランジション、操作手順は、60 fpsほどの負荷をかけなくても十分に読み取れるため、これが新しい既定値になりました。

--fpsに指定できる範囲は1〜60です。数値を上げれば、証跡として必ず強くなるわけではありません。ページの再描画頻度が指定値より低ければ、60 fpsを指定しても、実際に異なるページ状態が毎秒60枚生成されることはありません。

v0.37.0で変わったこと

新しいレコーダーは、動画を「いま操作しているページを時間軸で捉えたもの」として扱います。record startとrecord restartは現在のアクティブページを既定の30 fpsで取得し、--fps 1-60を受け付け、ChromeのPage.startScreencastを使用します。つまり、時々スクリーンショットを撮るのではなく、ブラウザの表示パイプラインにカメラを直結するように、Chrome自身が配信する再描画後のページフレームを受け取ります。

v0.37.0のリリースでは、失敗時の挙動も厳格になりました。ffmpegがない、出力パスに拡張子がない、録画オプションが不正といった場合は、ブラウザや録画状態が変わる前に失敗します。撮り直しの開始に失敗しても、進行中の録画は維持されます。録画中に移動した場合も、通常のページ移動と同じように、古くなった要素参照とフレーム状態が消去されます。

実際のQAループでは、この違いが重要です。動画のパスが不正だからといってテスト対象ページまで気づかないうちに変わるべきではなく、次のテイクが正常に始まると確認できる前に、最初のテイクを失うべきでもありません。

録画を確実に残す5ステップ

安定する順序は、確認、オープン、録画、アサーション、停止です。最後のコマンドでファイルを書き出して保存するため、停止も証跡を成立させる手順に含まれます。

agent-browser doctor
agent-browser open https://app.example.com/login
agent-browser record start ./login-flow.mp4 --fps 30
agent-browser snapshot -i
agent-browser click @e1
agent-browser wait --url "**/dashboard"
agent-browser record stop

1. 最初にエンコーダーを確認します。 agent-browser doctorを実行すると、ffmpegと録画用エンコーダーが表示されます。MP4にはlibx264、WebMにはlibvpxが必要です。標準的なHomebrew版またはDebian/Ubuntu版のffmpegには、通常どちらも含まれています。

2. 適切なページをアクティブタブに用意します。 record startにURLを付けない場合、レコーダーはアクティブページの現在の状態にそのまま接続します。再読み込み、新しいタブの作成、クリーンなブラウザコンテキストの生成は行いません。ハイドレーション済みのアプリ、認証済みセッション、ページ内の状態に依存する不具合を記録するときに有効です。URLを指定した場合は、まずアクティブタブがそのURLへ移動し、読み込み完了後に録画が始まります。

3. 拡張子でコンテナを選びます。 .mp4ではlibx264によるH.264、.webmではlibvpxによるVP8が選ばれます。それ以外の拡張子はH.264としてffmpegへ渡され、ffmpegがそのコンテナを扱える場合に限って動作します。拡張子のないファイル名は拒否されます。

4. 合否判定は自動化の中に残します。 例では、wait --urlでブラウザがダッシュボードへ到達したかを確認しています。動画は、人が何が起きたかを理解する助けになります。ピクセルをテストのアサーションに変えるものではありません。

5. 閉じる前に停止します。 record stopでテイクを保存し、残りのデータを書き出します。先にセッションを閉じると、残すつもりだったファイルを失う可能性があります。現在のアクティブページで1本を閉じ、そのまま次のテイクを始めたい場合はrecord restartを使います。

capturedFramesとframesが示すものは異なる

2つのカウンターは、素材と完成映像として読み分けます。capturedFramesはページが生成した異なるフレーム数、framesは動画ファイルに書き込まれたフレーム数です。静止したページでは異なる画像がほとんど生成されなくても、ffmpegが同じフレームを繰り返し書き込み、見やすいテイクに仕上げることがあります。

タイミングには重要な注意点があります。ページの変化が止まると、最後のフレームが保持されます。1回の静止区間は最大5秒まで保持され、それ以降の変化しない部分は省略されます。つまり、短い間は動画に残る一方、長いアイドル時間は圧縮されます。ソークテストの経過時間を測るストップウォッチとして、再生時間を使わないでください。

したがって、capturedFramesが少なくても、録画失敗とは限りません。単にページが静止していた可能性があります。60 fpsを、本当に動きを精査すべき場面だけに使う理由もここにあります。録画ガイドによると、60 fpsのビットレートは30 fpsのおよそ2倍になりますが、異なるフレームが何枚得られるかは、やはりページの再描画に左右されます。

ffmpegで画面録画するとコストはどう変わる？

すでにagent-browserを運用しているチームなら、基本的な動画証跡のために別の録画ツールのライセンスを追加する必要はなくなります。v0.37.0のパッケージはApache-2.0ライセンスを明記しているため、レコーダー自体にユーザー単位のソフトウェアライセンス料はかかりません。追加コストになるのは、ffmpegのセットアップ、CIの実行時間、成果物のストレージ、そして担当者が結果を確認する時間です。

これは、総合的なフィードバック基盤やテスト基盤を購入する場合とは大きく異なります。Jam Teamは年払いでクリエイター1人あたり月額$14、BugHerd Standardは月払いで5人まで月額$50とし、動画フィードバックも含みます。BrowserStack Automateは年払いでChrome Desktopの並列実行1つが月額$59で、デバッグツールに動画録画が含まれます。

これらの製品が提供するのは録画だけではないため、全面的に置き換えられると考えるのは適切ではありません。BrowserStackは管理されたブラウザカバレッジ、BugHerdとJamはコラボレーション、課題記録、外部連携を提供します。判断すべきコストはもっと限定的です。agent-browserがすでにフローを実行しており、不足している成果物が確認しやすい動画だけなら、2つ目のキャプチャ層を購入しないという選択ができます。

効果を得やすいチーム別：7つの活用例

1. 失敗したCIフローを調査するプロダクトチーム

ログインやチェックアウトのテストが不安定な場合、プロダクトチームは問題が起きやすい経路の直前で30 fps録画を開始し、URLや要素のアサーションを維持したまま、失敗時のMP4をCI成果物として残せます。エンジニアは、テキストログでは見落としやすい同意バナー、遅れて現れるオーバーレイ、フォーカスの飛び、トランジションを確認できます。断続的な状態を再現するために使う、有償のエンジニアリング時間を減らせるのが利点です。

2. ドラッグ、スクロール、アニメーションを確認するフロントエンドチーム

フロントエンドエンジニアは、短いインタラクションだけを切り出して60 fpsで記録し、開始時と終了時のスクリーンショットを動画に添えられます。動画では両者の間の動きが滑らかだったかを確認し、スクリーンショットでは正確なピクセルを保持します。フレーム落ちや、ドラッグ対象が誤ったタイミングで境界を越える現象など、2枚のスクリーンショットの間に不具合がある場合に有効です。

3. AIエージェントのブラウザ操作を監査するプロダクトチーム

AIプロダクトチームは、エージェントがタスクを進めている間、認証済みのアクティブページを30 fpsで録画し、エージェントのコマンド履歴やアサーションと並べて動画を添付できます。レビュー担当者は、計画そのものが悪かったのか、実行中にページが変化したのかを切り分けられます。不透明だった実行結果が、プロダクトマネージャーとエンジニアが一緒に検討できる証跡になります。

4. 状態に依存する不具合を再現するQAエンジニア

QAエンジニアは、不具合の前提条件がそろうまでセッションを準備し、URLを付けずにrecord startを実行できます。録画はその場の状態に接続するため、コールドナビゲーションでページが置き換わることはありません。蓄積されたカートの状態、モーダル、認証済みルートなど、再読み込みすると消える条件に依存する不具合で役立ちます。

5. クライアントへリリースを引き渡す制作会社

Web制作会社は、受け入れ確認用の経路を30 fpsで録画し、判断箇所に短い待機を入れ、自動化ツールではなく人が確認しやすいテンポの動画をクライアントへ渡せます。クライアントはテストランナーへのアクセス権がなくても、同じ経路を確認できます。成果物自体がフローを示すため、制作会社が会議で説明する時間を短縮できます。

6. 長時間実行のタイムラインを残す信頼性チーム

信頼性エンジニアは、動きより順序が重要な長時間ソークを10 fpsで録画できます。30 fpsや60 fpsと比べて、録画時の負荷とファイル増加を抑えられます。目に見える障害発生の瞬間を探す用途には使えますが、静止区間が圧縮されるため、時刻は再生時間ではなくログから確認する必要があります。

7. 難しいブラウザ問題をエスカレーションするサポートエンジニア

サポートエンジニアは、管理されたアカウントで顧客の操作経路を再現し、30 fpsで録画して停止し、エスカレーションに添付できます。開発チームは、文面だけのチケットでは失われがちなタイミングや予期しないオーバーレイまで把握できます。ただし、機密情報や顧客データを録画に含めない仕組みも同時に整えてこそ効果があります。

構築する価値がある3つのプロダクト

最有力：エージェント実行の証跡パック

1回のブラウザエージェント実行から、アサーション結果、コマンド履歴、最終スクリーンショット、MP4、フレームカウンターを1つのレビューパックにまとめ、そのリンクをJiraまたはLinearへ投稿する小規模サービスです。既存の課題管理フローにそのまま収まる出力なら、プロダクトチームとエンジニアリングチームに購入理由が生まれます。

需要は具体的に確認できます。米国のキーワードデータでは、「bug reporting tool」は月間約590検索、CPCは$43.80です。既存製品への支出も明確で、Jam Teamは年払いでクリエイター1人あたり月額$14、BugHerd Standardは月払いで月額$50です。販売可能な最小構成に必要なのは、agent-browserのラッパー1つ、成果物ストレージ、課題管理ツールとの連携1つ、そして墨消しのチェックリストです。

これはコーデックではなく、引き渡しそのものを売るため、最も有望な機会です。ただし、技術的な参入障壁は高くありません。Jiraへの投稿や動画保存は容易に模倣できるため、信頼できる文脈を組み立て、機密データを混入させない点で際立つ必要があります。

制作会社向けQA引き渡しポータル

制作会社がフローを選び、ステージング環境で実行し、アサーション、スクリーンショット、人が確認しやすいテンポの動画を1つの承認リンクで公開できる、クライアント向けレビューページです。技術的な証跡の説明が会議になりがちなクライアント承認の場面に向けて、制作会社や外部QAチームが購入者になります。

米国のキーワードデータでは、「website qa testing」は月間110検索で、前年比55%増、CPCは$23.91です。MVPでは、再利用可能なフローをいくつか用意し、30 fps録画、コメント、承認または却下に対応できます。課題は既存製品の機能の厚さです。BugHerdのStandardプランにはすでに、プロジェクト数とクライアントユーザー数の制限なし、スクリーンショット、メタデータ、動画フィードバックが含まれます。新製品が勝つには、別のコメントピンではなく、エージェントが生成する証跡を強みにする必要があります。

モーションテスト向けプリセット層

テストをtimeline、default、motionに分類し、それぞれを10、30、60 fpsへ割り当て、取得フレーム数と書き込みフレーム数の不自然な差を通知する軽量なCIツールです。アニメーションやインタラクションのリグレッションに対して証跡を標準化できれば、フロントエンド基盤チームに購入価値があります。

米国のキーワードデータでは、「automated browser testing」は月間110検索で、CPCは$14.96です。より購買意図の強い「automated browser testing tools」は月間わずか20検索ですが、CPCは$63.21であり、小規模な買い手層へのリーチに高い費用がかかることを示します。MVPは、テストマニフェスト、agent-browserのコマンドラッパー、失敗時だけ保持する動画、コンパクトな成果物インデックスで構成できます。

課題は勢いの弱さです。広い方のキーワードは前年比18%減で、60 fpsは負荷を増やしてもページの再描画頻度に制限されます。独立した製品ではなく、証跡プロダクトの一機能として始めるべきです。

動画記録だけではブラウザテストの正しさを証明できない

動画は可観測性を高めますが、正しさを保証するものではありません。正しいデータベース行が書き込まれたか、APIレスポンスが妥当か、すべてのブラウザや端末で同じように動くかは判断できません。アサーション、ログ、スクリーンショットも一緒に残してください。

環境面のリスクもなくなりません。録画にはPATH上のffmpegと対応するエンコーダーが必要です。高いフレームレートは負荷を増やし、長時間録画はディスクを消費し、リソースの限られたヘッドレス環境ではコーデックやGPUの制約を受ける場合があります。再描画が遅いページからは、毎秒60枚の異なるフレームを得られません。

プライバシーはプロダクト要件として扱う必要があります。レコーダーはアクティブなビューポートとページ内の状態を取得します。それこそが有用な理由であると同時に、テスト用アカウント、機密情報のマスキング、成果物の保持期間、アクセス制御について明確なルールが必要な理由でもあります。これは運用上の判断であり、標準機能として墨消しが保証されているわけではありません。

さらに、agent-browserは証跡を記録しますが、内容を解釈しません。実行後にモデルで映像を確認するなら、それは別のシステムであり、エージェント型の動画理解に近いものです。そのレイヤーは、決定論的な合否判定とは分けてください。

次の月曜日に試すこと

来週、不具合が起きやすいログイン、チェックアウト、公開処理のいずれか1つを選びます。doctorを実行し、現在のアクティブページを30 fpsで録画し、既存のアサーションを維持し、record stopを呼び出して、MP4をテスト結果に添付します。動きの不具合をレビュー担当者が判断できない場合だけ60 fpsへ上げ、長時間実行で主に順序を追う場合は10 fpsへ下げます。映像が滑らかに見えることではなく、再実行せずに担当者が失敗原因を診断できることが、試行成功の基準です。

チームがレビューしやすい証跡を出力するブラウザエージェントが必要なら、実際のQAワークフローに合わせて構築できます。