AIにブラウザ操作を任せて分かった「越えない線」と壊れ方
PR・アフィリエイトについて
当サイトはアフィリエイトプログラムを利用しており、紹介リンク経由での申込により報酬を得る場合があります。記事内で紹介するサービスには筆者が実際に使用しているものと、客観情報として比較掲載しているもの（未使用・PR表記あり）が含まれます。
世の中の業務システムには、APIがありません。正確に言うと、一部の大手SaaS以外はだいたい無いか、あっても欲しい数字が取れません。
そうなると残る道は1つで、ブラウザで画面を開いて読むしかありません。人がやっている作業とまったく同じことを、機械にやらせる。いわゆるRPAの考え方です。
結論
ブラウザ自動操作は、定型のWeb作業を本当に消せます。ただし他の自動化より壊れやすく、壊れ方に癖があります。そして「やらせてはいけない操作」がはっきり存在します。この記事は、毎日動いている自動化が実際に壊れた4パターンと、その線引きの記録です。
対象は、管理画面から毎日の数字を取る、定型のフォームを出す、SNSに決まった文面を投稿する、といった作業です。判断が要らず、手順が決まっていて、毎日か毎週やるもの。ここが一番効きます。
まず線引き：自動化してよい操作／人が押す操作#
作る前にここを決めておかないと、あとで事故ります。実運用で落ち着いた線はこうです。
| 操作 | 誰がやるか | 理由 |
|---|---|---|
| 画面を開いて数字を読む | AI | 取り消す必要が無い |
| 一覧を検索する・絞り込む | AI | 同上 |
| 決まったフォームを送信する | AI（内容は事前に固定） | 取り消せる範囲なら |
| ログインの2要素認証 | 人 | 本人確認そのもの。代行させない |
| 支払い・課金の確定 | 人 | 取り消せない。金額に触る |
| 本人確認・契約の同意 | 人 | 法的に本人の意思表示 |
基準は1つで、取り消せる行為は渡し、取り消せない行為は人が押す。これはメールのAI仕分けで送信だけ人が押すのと同じ線です。全部の自動化に同じ基準を使うと、迷う時間が消えます。
もう1点、当然ですが相手のサービスの利用規約を確認してください。自分のアカウントで、自分がやっている作業を、同じ頻度でやらせる範囲に留めるのが基本です。人がやるより速く連打すれば相手のサーバーに負荷をかけますし、それは自動化ではなく迷惑です。
壊れ方1：本人のブラウザに相乗りすると、設定1つで死ぬ#
最初に作った版は、普段使っているブラウザをそのまま操作する方式でした。すでにログイン済みなので楽です。楽なのですが、これが8日連続で失敗しました。
原因の特定に時間がかかりました。結論はこうです。
実際の原因
ブラウザ側の「外部からのスクリプト実行を許可する」設定が、プロファイル（利用者）ごとの設定だった。プロファイルAではON、既定のプロファイルではOFF。対象のタブが既定側のウィンドウで開かれていると、命令が拒否される。
つまり、どのウィンドウでそのタブを開いたかで成否が変わるという状態でした。しかもブラウザのアップデートやプロファイルの切り替えで再発します。原因が自動化のコードの外にあるので、ログを見ても分かりません。
対処は「相乗りをやめる」でした。 自動化専用のプロファイルを別に用意し、画面を出さずに動かす方式へ切り替えました。普段使いのブラウザには一切触りません。
これで副次的に良かったことが3つあります。
- 作業中に自分がブラウザを操作していても邪魔されない（勝手にタブが切り替わらない）
- 自動化側のログイン状態が専用プロファイルに保存されるので、通常は再ログインが不要
- 普段使いの設定変更やアップデートの影響を受けない
自動化のために日常環境を触らせない。これは事故を減らす原則としてかなり強いです。
ログイン情報の置き場所#
専用プロファイルにしても、初回や期限切れではログインが要ります。IDとパスワードはOS標準のパスワード保管庫（キーチェーン等）から実行時に取り出す形にしています。
守っているのは次の2つです。
- コードにもファイルにも平文で書かない（設定ファイルに書くのが一番多い事故です）
- ログにも画面出力にも出さない（デバッグ中の出力から漏れます）
壊れ方2：確認しすぎて、自分でレート上限を使い切る#
これは自分でも意外だった壊れ方です。
SNSへの自動投稿で、「二重投稿を防ぐために、投稿する前と後にプロフィールを見て確認する」という作りにしていました。慎重な設計のつもりでした。ところが投稿が通らなくなりました。
調べると、1回の投稿につき最大12回もプロフィール画面を読んでいました（前チェックと後検証のリトライを含む）。そしてそのプロフィール取得には15分あたり50回という上限がありました。
上限を使い切ると、画面にはエラーが出て投稿が1件も表示されません。すると自動化側は「投稿できたか確認できない」と判断して、安全のために投稿を見送ります。そして再確認のためにまた読みに行き、上限をさらに食う。 完全な自滅ループでした。
直し方は、確認方法を変えることでした。 投稿を送った直後の応答そのものに投稿IDが含まれていたので、それを使って結果を確定するようにしました。画面を読みに行く回数は12回から0回になりました。あわせて、上限に当たったら即座に降りる（再試行しない）ようにしています。
教訓
ブラウザ自動操作では、「念のためもう一度見る」が一番のコストです。人間は無料で目視できますが、機械の目視は回数制限のある通信です。検証は「送った結果の中に答えが無いか」を先に探す。
もう1つ、この件でついでに直したものがあります。一時的な失敗が、再試行の回数を消費していました。3回失敗すると「恒久的な失敗」として捨てる作りだったので、ネットワークが一瞬切れただけの投稿が永久に消えていました。一時的な失敗と、内容が原因の失敗を分けて数える。これは自動化全般で効きます。
壊れ方3：クリックが「画面の上の何か」に奪われる#
別のSNSでは、投稿欄が見つからないという失敗が続きました。
要素は存在していて、自動化側もそれを見つけています。それでもクリックが効かない。原因は、フィードの読み込み中に表示される半透明のオーバーレイが、クリックを横取りしていたことでした。人間なら「あ、まだ読み込み中だな」と一拍置きますが、機械は0.1秒で押しに行きます。
対処は3段構えです。
- まず通常のクリックを試す
- 効かなければ、要素を直接指定した強制クリックに切り替える
- それでも駄目なら一拍おいて最初からやり直す
「見えているのに押せない」はブラウザ自動化で最も多い失敗です。要素が見つからないのではなく、手前に何か乗っているを疑ってください。
壊れ方4：仕様を「故障」と勘違いする#
最後は、コードのバグではないのに壊れて見えるパターンです。
管理画面から広告の成果データを取る自動化で、表示回数が毎日ゼロで返ってきました。当然、取得に失敗していると思いました。
実際には、そのサービスはテキスト形式のリンクの表示回数を計測していない（画像バナーだけ計測する）という仕様でした。こちらはテキストのリンクしか使っていないので、ゼロが正しい値です。
これは笑い話ですが、自動化を監視する仕組みを作ると必ず起きます。「値がゼロなら異常」というルールを入れた瞬間に、毎日誤報が飛びます。
対処は、仕様として正しいゼロをコードのコメントに書いておくことでした。半年後の自分が同じ調査をやり直さないためです。数字を扱う自動化では、「その数字が取り得る正常な値」を先に確認する。これは数字を扱う自動化全般に共通する話です。
壊れる前提で作る：3つの実装ルール#
4つの壊れ方に共通する対策としてやっているのは、次の3つです。
1. 失敗しても止まらない・二重にしない#
自動化は毎日動きます。1日失敗しても、翌日動けば実害はほとんどありません。例外で全体を止めない、そして同じことを二度やらない（実行済みの記録を残す）。この2つがあれば、たいていの失敗は自然に回復します。
失敗した枠に対して、20分後・40分後に自動で再試行する予定を入れておくと、一時的な不調はだいたい吸収されます。
2. 失敗の中身をそのまま残す#
「失敗しました」だけのログは役に立ちません。エラー本文・そのときのURL・画面の写しを残しておくと、原因の特定が数分で終わります。壊れ方1の設定の話も、壊れ方2の上限の話も、画面の写しと通信の応答を見て初めて分かりました。
3. 目で見られる逃げ道を用意する#
普段は画面を出さずに動かしていますが、画面を出して動かすオプションを必ず用意しています。画像認証が出た、ログインが切れた、レイアウトが変わった——このあたりは、一度自分の目で見ないと絶対に分かりません。
なお画像認証については、時間を置いた再試行で通ることが多いというのが実感です。突破しようとするのではなく、条件を変えて素直にやり直す。
FAQ#
ノーコードのRPAツールでもできますか？#
できます。この記事で書いた4つの壊れ方は、ツールに関係なく起きます。ノーコードツールを使う場合に確認しておきたいのは、失敗時のログがどこまで見えるかと画面の写しが残るかです。ここが弱いツールだと、壊れたときに手が出せません。
相手のサイトのデザインが変わったらどうなりますか？#
止まります。これは避けられません。だから画面の構造に依存する部分を1か所にまとめておくのが大事です。直す場所が散らばっていると、毎回そこを探すところから始まります。
AIエージェントに任せれば、変更にも自動で追従してくれるのでは？#
ある程度は追従します。ただし毎回同じ操作をするのに毎回AIに考えさせるのは、遅くて高くて不安定です。実運用では「手順が固まったら決め打ちのコードにする」ほうが安定します。AIに考えさせるのは、壊れたときの原因調査と手順を最初に作るときに効かせるのが良い分担です。
どこから作り始めるのが良いですか？#
毎日やっていて、判断が要らず、失敗しても取り返しがつく作業です。管理画面から数字をコピーしてスプレッドシートに貼る、あたりが最初の1本に向いています。逆に、金額の確定や送信を伴う作業を最初に選ぶと、事故ったときのダメージで続かなくなります。
まとめ#
- APIが無いWeb作業はブラウザ自動操作で消せる。ただし壊れやすい前提で作る
- 線引きは取り消せる行為は渡し、取り消せない行為は人が押す。2要素認証・支払い・契約の同意は渡さない
- 普段使いのブラウザに相乗りしない。専用の環境で動かすと、設定1つで死ぬ事故が消える
- 「念のためもう一度確認」が一番のコスト。送った結果の中に答えが無いか先に探す
- 「見えているのに押せない」は手前に何かが乗っているを疑う
- ゼロが返ってきたら、まず仕様として正しいゼロではないかを確認する
- 認証情報は保管庫から実行時に取り出し、ログにも出さない
ブラウザ自動化は、AI活用の中でいちばん「働いている感」が出る領域です。ただし線を越えると、取り返しがつかない事故に直結します。渡すのは目と手であって、意思決定と本人確認ではない。この一線だけは、最初に決めておいてください。
自動化全体をどう組み立てているかは個人で回している自動化20件の全体像、AIに毎回説明し直さずに済ませる方法は「忘れられる」問題を解く5段階にまとめています。
