Cloudflare Browser Runは、レンダリング済みWebページのアクセシビリティツリーを返す/accessibilityTree endpointを追加した。画面上のrole、name、state、value、階層を構造化データとして取得できるため、AIエージェントはスクリーンショットの画像認識や生HTMLの解析だけに依存せず、操作可能な要素を判断できる。

何が変わったか

REST APIのPOST /accounts/{account_id}/browser-rendering/accessibilityTreeで、URLまたはHTMLを入力し、アクセシビリティツリーを取得できる。interestingOnlyを使うと意味のあるnodeへ絞り、rootを使うとCSS selectorを起点とした部分木だけを返せる。読み込み条件、待機、request制御、認証情報などもBrowser Runのパラメータで設定できる。

変更前後の差

従来はスクリーンショット、HTML、Markdown、/snapshotの複数形式から画面状態を推定する必要があった。単独endpointにより、意味構造だけが必要な処理で不要な画像やHTMLを受け取らずに済む。一方、視覚的な配置、色、重なり、canvas描画はアクセシビリティツリーだけでは判断できない。

誰に影響するか

Web操作エージェント、E2E test、アクセシビリティ監査、フォーム自動入力、RPA、画面内容の構造抽出をBrowser Runで行う開発者が対象である。特にLLMへ画面情報を渡して次の操作を選ばせる構成では、token量、latency、誤クリック率の改善余地がある。

期限

強制移行期限はない。既存の/snapshot、screenshot、HTML取得は継続して使える。新endpointは用途に応じて追加し、既存処理を一度に置き換えず比較評価する。

必要な対応

現在の観測入力を、意味構造、視覚情報、本文情報に分ける。ボタンや入力欄の特定はaccessibility treeを優先し、配置や画像認識が必要な場合はscreenshotを併用する。ページ操作の直前にツリーを再取得し、取得時点と操作時点のDOM差を減らす。認証情報とBrowser Rendering Write権限は最小化する。

実装・移行手順

  1. screenshotまたはHTMLを使う既存agent stepを特定する
  2. 同じページを/accessibilityTreeで取得する
  3. interestingOnlyの有無でnode数と必要情報を比較する
  4. rootでフォームやmain領域だけを限定取得する
  5. roleとnameを使う要素選択ロジックを実装する
  6. 操作直前に再取得し、対象nodeの存在とstateを確認する
  7. canvas、画像、重なりがある画面ではscreenshot fallbackを使う
  8. token量、latency、成功率、誤操作を従来方式と比較する

失敗しやすい点

accessibility treeをDOMの完全な代替と考える、labelのない要素を確実に操作できると思う、古いツリーを保持したまま動的画面を操作する、interestingOnlyで必要nodeまで除外する、といった問題が起きやすい。ページ側のアクセシビリティ実装品質が低い場合、roleやname自体が不十分になる。

リスク

誤ったnode選択、動的更新後のstale state、非表示・無効要素の誤判定、認証情報の過大付与、外部requestによる情報漏えいがある。アクセシビリティツリーは意味情報を強化するが、安全な操作承認やサイト固有の制約を代替しない。

評価方法

  • 1画面当たりの入力token量
  • ツリー取得latency
  • 操作成功率と誤操作率
  • screenshot fallback率
  • role・name欠落node数
  • 動的更新後の再取得率
  • interestingOnlyによるnode削減率
  • task完了までのBrowser Run利用時間
  • HTTP 429とtimeout率

ロールバック

新endpointで成功率が下がる場合は、既存の/snapshotまたはscreenshot・HTML併用へ戻す。要素選択ロジックは入力形式ごとにadapter化し、accessibility treeが空または不十分な場合に従来方式へ自動切替できるようにする。

編集部分析

構造化されたアクセシビリティ情報は、画面操作エージェントの観測コストを下げる有力な入力である。ただしWebの見た目と操作可能性は一致しない。最も実務的なのは、ツリーを第一候補、画像を視覚的検証、HTMLを詳細調査に使い分ける多層観測である。

実務チェックリスト

  • [ ] 既存の画面観測方式を分類した
  • [ ] interestingOnlyとrootを比較した
  • [ ] 操作直前の再取得を実装した
  • [ ] screenshot fallbackを残した
  • [ ] Browser Rendering Write権限を限定した
  • [ ] 動的画面と認証画面を試験した
  • [ ] token、latency、成功率を計測した
  • [ ] stale state時の停止条件を設定した

一次情報