ブラウザ操作をAIに任せる — 動くが壊れやすい領域

使える業務

• APIのない社内システムからのデータ取得
• 複数のサイトに同じ情報を入力する作業
• 定期的な画面の確認（在庫、価格、掲載状況）
• ログインが必要なページからの定期取得

共通するのは、APIが提供されていないことである。APIがあるならそれを使う。ブラウザ操作は最後の手段である。

画面の構造に依存しているので、ボタンの位置やラベルが変わると動かない。AIが画面を見て判断する構成では従来の自動化より耐性があるが、完全ではない。

• ボタンのラベルが変わった
• 確認のダイアログが追加された
• 二段階認証が有効になった
• ページの読み込みが遅くなった
• 自動操作の検知で遮断された

認証の扱い

自動操作のために認証情報をどこかに保存することになる。ここが最も注意が必要な部分である。

• 専用のアカウントを作り、権限を最小にする
• 個人のアカウントを使わない（退職で止まる・責任が曖昧になる）
• 認証情報は環境変数や秘密管理の仕組みに置く
• 二段階認証を回避する構成にしない（規約違反になりうる）

規約の確認

外部のサイトを自動操作する場合、相手の利用規約を確認する。自動アクセスを禁止しているサイトは多い。社内システムなら問題にならないが、外部サイトは別である。

取得したデータの使い方にも制限がある場合がある。競合の価格を取得して自社の価格に反映する、といった使い方は規約で禁じられていることがある。

隔離して動かす

ブラウザ操作は、生成されたコードや外部のページを扱うので、自分のマシンで動かすのは避ける。Browserbase のようなサービスか、隔離した環境で動かす。

特に、取得したページの内容をAIに読ませる構成では、プロンプトインジェクションの経路になる。読ませた内容に権限を与えない設計にする。

失敗を前提にした運用

壊れることを前提に、壊れたときに気づく仕組みを作る。「毎日10件取得できるはずが0件」を検知して通知する。壊れたまま数週間動いている状態を避ける。

よくある質問

Q. 従来のRPAとの違いは。

A. AIが画面を見て判断するため、画面の小さな変更に耐えやすいです。ただし判断を間違える可能性が加わるので、確実性が上がったわけではありません。