TERM PRIMER
先に知っておく言葉
- DOM
- ブラウザがHTML文書の要素や文字を、木の枝のような構造として扱えるようにした表現です。
- アクセシビリティツリー
- 画面の要素を、名前、役割、状態、階層として支援技術などへ伝えるための構造です。
- ロケーター
- ブラウザ操作で、名前や役割などを手がかりに対象のボタンや入力欄を特定する指定です。
- 再観測
- 操作後の画面や状態をもう一度読み取り、期待した変化が起きたかを確認する工程です。
ブラウザ操作エージェントは、画面画像、DOM、アクセシビリティ情報などからページの状態を観測し、対象要素を特定してクリックや入力を行い、その結果を再び観測して進みます。人の目とマウスだけをそのまま再現する方式に限りません。
一度決めた座標を最後まで押すのでもありません。ページ読み込み、ポップアップ、画面幅、ログイン状態によって表示は変わります。ラボのブラウザ案内所で、読む→選ぶ→動かす→確かめる、という順番を追います。
ブラウザ操作の全体の流れ
AIエージェントとは?で見た観測と行動のループを、Webページへ当てはめます。
- 目標と禁止操作を確認する
- 現在のURLとページ状態を観測する
- 次に必要なリンク、ボタン、入力欄を特定する
- クリック、入力、スクロールなどを一つ実行する
- 読み込みや画面変化を待つ
- URL、見出し、通知、入力値を再観測する
- 成功条件を満たしたか判定する
- 続行、やり直し、人への確認、停止を選ぶ
運転士が車窓、駅名標、路線図を使い分け、停車するたび現在地を確認するたとえです。ただし実際の実装は、画像だけ、構造情報だけ、両方の組み合わせなどさまざまです。
ユイ
AIエージェントのブラウザ操作って、人と同じように画面だけを見てクリックするの?
マコト
ボタンの位置が変わっただけで旧座標を押すなら、次の画面まで間違ってしまうね
ピコ
車窓、駅名標、路線図の三つを並べて、観測と操作を分けよう
AIは画面の何を読む?
観測方法にはそれぞれ得意不得意があります。
- スクリーンショット: 色、配置、アイコン、画像、キャンバスなど見た目を読める
- DOM: HTML要素、属性、階層、テキストなどページ構造を読める
- アクセシビリティ情報: ボタン、見出し、入力欄などの役割と名前を読める
- ブラウザ状態: URL、タブ、読み込み、ダウンロードなどを読める
- 操作履歴: 直前に何を押し、何が変わったかを追える
見た目が同じ青い長方形でも、片方は送信ボタン、片方は装飾かもしれません。逆にDOMには存在しても、画面外、非表示、別要素に覆われていて押せない場合があります。そのため複数の手掛かりを組み合わせます。
アクセシビリティ上の役割と名前は、人に近い意味で要素を探す助けになります。Playwrightの公式文書も、利用者や支援技術が捉える役割に近いロケーターを優先し、変わりやすい長いCSSやXPathへ強く依存しない方法を案内しています。
要素特定と操作の役割
観測後、エージェントは目標に合う要素を選び、ブラウザ操作ツールへ命令します。操作の種類は次のように分けられます。
- リンクやボタンをクリックする
- 入力欄へ文字を入れる
- チェック項目を切り替える
- 選択肢を選ぶ
- ページをスクロールする
- 新しいタブを開く、閉じる
- ファイルをアップロード、ダウンロードする
- キーボード操作を送る
「三番目の青いボタン」のような座標・見た目だけの指定は、広告やレイアウト変更でずれやすくなります。「役割がボタンで、名前が検索」のような意味寄りの指定も、同名要素が複数あれば特定できません。周囲の見出し、フォーム、可視性などで候補を絞ります。
操作前には、対象が表示されているか、有効か、他の要素に覆われていないかを検査できます。Playwrightのactionability checksは、クリック前に可視性、安定性、イベントを受け取れる状態、有効状態などを確かめます。AIの判断が正しくても、ブラウザ側の実行条件が整わなければ操作は失敗します。
操作後になぜ再観測する?
クリック命令がエラーなしで返っても、目的が達成されたとは限りません。検索ボタンを押した後なら、結果一覧が出たか、エラー画面か、ログイン要求かを確認します。

再観測では、次のような証拠を組み合わせます。
- URLが期待したページに変わった
- 目的の見出しや一覧が現れた
- 入力値が保存後も残っている
- 成功通知またはエラー通知が出た
- 対象データの件数や状態が変わった
- ダウンロードしたファイルが存在する
WebArenaのような研究環境は、現実的なWebタスクを通してエージェントを評価します。Web操作は一回の要素認識だけでなく、長い手順、サイト間移動、状態変化を最後まで正しく扱えるかが難所です。
ログインや削除では確認する
ブラウザには、閲覧だけでなく外部に影響する操作があります。便利だからと同じ権限で連続実行させず、影響に応じて止まる場所を設けます。
- ログイン情報や個人情報の入力
- メッセージやフォームの送信
- 商品やサービスの注文
- 支払い方法の確定
- ファイルやアカウントの削除
- 公開範囲の変更
- 契約、予約、解約
- セキュリティ設定の変更
下書き作成までは自動、送信直前は人が宛先と内容を確認、という分割ができます。確認画面で表示された外部文書が、エージェントへ別の命令を埋め込む可能性もあるため、ページ内の指示を利用者の依頼と同じ権限で扱いません。
画面変更でつまずく例
失敗原因を「AIが賢くない」で一括りにせず、観測・特定・操作・確認に分けます。
- レスポンシブ表示でボタンがメニュー内へ移った
- Cookie通知が対象要素を覆った
- 同じ名前のボタンが二つあった
- 別タブが開いたのに元タブを読み続けた
- 読み込み途中の古いDOMを使った
- 無限スクロールで候補がまだ現れていない
- ログイン期限が切れた
- 成功通知を見ず、同じ操作を再実行した
固定座標の再利用より、各手順で新しい状態から要素を探し直す方が変化に対応しやすくなります。それでも意味が変わった、確認文が曖昧、対象が複数ある場合は、人へ質問して止まる設計が必要です。
安全なテストのクイズとワーク
ワーク: 「検索→三候補を比較→下書きに保存」を、読み取り・操作・確認の三列に分けます。本番アカウントではなくテスト環境を使い、送信や購入は操作候補から外します。各操作後に確認するURL、見出し、値を一つずつ書いてください。
Q1. 見た目が同じボタンなら意味も同じ?
保証できません。役割、名前、周囲の構造、現在ページを合わせて特定します。
Q2. DOMが読めれば画像は不要?
実装とページによります。キャンバス、画像内情報、重なり、視覚配置はスクリーンショットが役立ち、構造と意味はDOMやアクセシビリティ情報が役立ちます。
Q3. クリック成功なら作業完了?
目的の外部状態を再観測します。ボタンが反応しても、入力エラーや権限不足で処理が完了していない場合があります。
観測ループから次へ進む
ブラウザから得た情報を次の判断へどう残すかはコンテキストエンジニアリングとは?へ進みます。検索側がページを発見し、索引に入れる別の流れはAI検索はWebサイトをどう読んでいるの?で確認できます。
ブラウザ操作の要点は、クリックの器用さだけではありません。現在状態を複数の手掛かりで読み、操作対象を絞り、一手の結果を再確認し、影響の大きな場面では人に戻すことです。
操作の前後に、観測と確認がある
AIエージェントは画面を観測し、対象を特定して一手を実行し、変化した画面をもう一度観測します。画面変更や読み込み遅延で狙いが外れることもあるため、送信・購入・削除など影響の大きな操作は、人の承認へ戻すところまでが仕組みの一部です。
LAB WHITEBOARD
自分の言葉で説明してみよう
「観測、要素特定、操作、結果確認、例外処理、承認の流れと、画面変更で起きる失敗を説明できるようになる。」を、いまの自分の言葉で一文にしてみてください。途中の説明でも大丈夫です。




