画面が変わったら押さない――ブラウザエージェントの再確認手順

経理や営業企画の責任者がブラウザ操作をAIエージェントに任せるとき、怖いのはクリック失敗より「正しく押せたが、対象が違った」という事故です。本稿では、請求承認やCRM更新の直前に対象を読み直す手順と、そのまま使える「操作意図票」を作ります。

スクリーンショットは実行許可ではない

ブラウザ画面は、観察してから操作するまでの間にも変わります。自動更新で行が並び替わる、別担当者が状態を更新する、モーダルが重なる、といった変化です。Seleniumの公式資料も、ページ更新やDOMの動的変更後は、以前取得した要素参照が使えなくなり、操作前に要素を再取得する必要があると説明しています。[2]

Playwrightはクリック前に、対象が一意か、表示中か、位置が安定しているか、クリックを受け取れるか、有効かを検査します。[1] ただし、これは「押せるボタン」であることの確認です。「請求書A-184を承認するつもりで、その請求書のボタンを押しているか」までは保証しません。

そこで、観察時の座標や要素参照ではなく、業務上の対象と条件を固定します。責任者はまず、取り消しにくい操作を一つ選び、対象ID・重要属性・許可状態・承認者を入力として定義します。

コピーして使える「操作意図票」

次の雛形を、エージェントの実行要求ごとに生成します。targetは画面上の位置ではなく、業務データの一意キーです。preconditionsは一つでも違えば停止する条件にします。

action_intent:
  action: approve_invoice
  target:
    invoice_id: A-184
    supplier: サンプル商事
    amount_jpy: 286000
  preconditions:
    status: 承認待ち
    assignee: 経理チーム
  requested_by: user-42
  expires_in_seconds: 120
  on_mismatch: stop_and_report

金額や宛先のような重要項目は、人が承認時に識別できる形で提示し、実行対象と結び付けます。OWASPも取引承認について、重要データを利用者が識別・確認できること、確認から実行までにデータが変わった場合は承認を無効化またはやり直すことを推奨しています。[3]

Observe→Resolve→Commitの3段階

1. Observe：変更を伴わず読む

一覧から対象を探し、操作意図票の全項目を読み取ります。この段階ではクリック、入力、送信を禁止します。取得値、URL、画面更新時刻、候補件数を実行ログへ残します。候補が0件または2件以上なら停止です。

2. Resolve：直前に同じ対象を引き直す

ボタンを押す直前にDOMを再取得し、invoice_idなどの一意キーから対象行を解決し直します。金額、取引先、状態、担当が操作意図票と完全一致するか比較します。古い要素をそのまま再利用せず、再取得後に別対象へ結び付く可能性もあるため、属性照合を必須にします。[2]

3. Commit：一度だけ実行し、結果を確認する

一致した場合だけ操作します。実行後は、成功表示ではなく対象の状態を再読込し、承認済みなど期待する変化を確認します。同じ操作意図票には一度しか実行できないキーを付け、タイムアウト後や結果不明時の自動再試行は禁止します。

仮想例： エージェントが請求書A-184を観察した後、一覧が更新されて行順が変わったとします。座標クリックなら別の請求書を押す恐れがあります。3段階方式では、A-184を再検索し、金額28万6,000円と取引先、状態を照合します。一項目でも違えば「画面変化により停止」と報告し、人に戻します。完了条件は、A-184の状態だけが承認済みに変わり、同じ実行キーの再送が拒否されることです。

失敗モードと使わない境界

セレクターを頑丈にするだけでは、同じ見た目の別レコードを区別できません。待機時間を長くするだけでも、変更後の画面が落ち着くのを待つだけです。確認ダイアログも、対象IDや金額を再表示しなければ形式的な一手間に終わります。

APIで一意な取引IDと条件付き更新を利用できるという場合には、画面操作を主経路にする方法は向きません。API側で「状態が承認待ちのときだけA-184を更新する」と指定する方が、画面の並び替えに依存しません。ブラウザ操作は、APIがない業務システムの橋渡しとして限定します。

明日から使える実装チェックリスト

• [ ] 取り消しにくい操作を一つだけ対象にした
• [ ] 座標ではなく業務上の一意キーを決めた
• [ ] 対象ID、金額・宛先、状態、担当を操作意図票に入れた
• [ ] Observe中の変更操作を禁止した
• [ ] Commit直前にDOMと対象属性を再取得する
• [ ] 不一致、複数候補、期限切れは停止して人へ返す
• [ ] 実行キーの重複を拒否する
• [ ] 実行後に対象レコードの状態を読み直す
• [ ] 結果不明時は自動再試行せず調査キューへ送る

最初の完成基準は、正常系の成功率ではありません。画面を更新して行順を変える、金額を書き換える、別担当者が先に承認する、という三つのテストで、エージェントが誤クリックせず停止できることです。

参考資料

1. Playwright: Auto-waiting
2. Selenium: Understanding Common Errors
3. OWASP Cheat Sheet Series: Transaction Authorization

本記事はAIを活用して作成し、公開前に自動レビューを実施しています。情報の確認日：2026-10-13。