壊れても困らない作業から始めるブラウザ自動化3段階
ブラウザ自動化に興味はあるけど、「間違って購入ボタン押したらどうしよう」「大事なデータ消えたら怖い」と手が出せない人は多い。
結論から言うと、読み取りだけの作業から始めれば、そういう事故は起きない。スクリーンショットを撮る、一覧を取得する、表示を確認する。これらは「見るだけ」なので、仮にスクリプトが壊れても実害がない。
今回は、リスクの低い作業から段階的に自動化を広げていく方法を、PlaywrightやSeleniumの設計思想を踏まえて整理する。
第1段階：見るだけの自動化（リスクほぼゼロ）
最初に手をつけるべきは「読み取り中心」の作業だ。具体的にはこんなもの：
- 定期的なスクリーンショット取得
- ページ上のテキストや価格の取得
- 表示崩れがないかの確認
- 一覧ページからのデータ抽出
これらは副作用がない。スクリプトが途中で止まっても、データベースが壊れることもなければ、誰かにメールが飛ぶこともない。
Playwrightを使う場合、操作前に「Auto-wait（自動待機）」が働く。要素が見つかるまで、アニメーションが止まるまで、自動で待ってくれる。条件が揃わなければタイムアウトでエラーになるだけ。つまり「待ちが足りなくて変なところをクリックした」という事故が起きにくい設計になっている。
初心者がやりがちなsleep(3)みたいな固定待機を入れなくても、ツール側が適切に待ってくれる。これは地味にありがたい。
この段階でやること：
- ツールのインストールと基本操作に慣れる
- ページを開いてスクリーンショットを撮るスクリプトを書く
- 表示されているテキストを取得してファイルに保存する
失敗しても「あれ、動かないな」で終わる。精神的なハードルが低いので、ここで操作感を掴んでおくといい。
第2段階：軽い操作の自動化（中リスク）
読み取りに慣れたら、次は「軽い副作用がある操作」に進む。
- ログインしてマイページを表示
- フォームに入力して送信（テスト環境で）
- 検索条件を入れて結果を取得
ここで大事になるのが「要素の特定方法」だ。
Playwrightの公式ドキュメントでは、ユーザーの視点に近いロケータ（要素の指定方法）を推奨している。たとえば「ログインボタン」を探すとき、CSSセレクタで#btn-login-v2-newみたいなIDを使うより、roleやlabelで「ログイン」というテキストを持つボタンを探すほうが壊れにくい。
なぜかというと、IDやクラス名は開発者がリファクタリングで変えることがあるが、「ログイン」というラベルはそうそう変わらないからだ。
注意点がひとつ。 Playwrightは、指定したロケータが複数の要素にマッチするとエラーになることがある。「とりあえず最初の要素をクリック」で逃げることもできるが、公式は明確に非推奨としている。ページの構造が変わったとき、意図しない要素をクリックしてしまうリスクがあるからだ。
手抜きセレクタは後で事故る。面倒でも、1つの要素に確実にマッチするロケータを書く習慣をつけておくと、メンテナンスが楽になる。
この段階でやること：
- テスト用のアカウントでログイン自動化を作る
- フォーム入力→送信のフローを組む
- ロケータの書き方を意識して、壊れにくい指定を練習する
本番環境ではなく、ステージング環境やテストアカウントで試すのが鉄則。
第3段階：不可逆操作の自動化（高リスク）
ここからは慎重に進める領域だ。
- ECサイトでの購入処理
- データの削除
- 社内システムの更新処理
- 外部APIを叩いて課金が発生する操作
一度実行したら取り消せない、お金が動く、権限に関わる。こういう操作は、待機戦略とエラーハンドリングの設計が必須になる。
Seleniumの公式ドキュメントでは、待機の種類について詳しく説明されている。
implicit wait（暗黙的待機）： セッション全体に効くグローバル設定。要素が見つかるまで指定秒数待つ。デフォルトは0秒なので、見つからなければ即エラー。
explicit wait（明示的待機）： 特定の条件が満たされるまでポーリング（定期的にチェック）して待つ。タイムアウトを超えたらエラー。
ここで重要な警告がある。implicit waitとexplicit waitを混ぜるな、と公式が明言している。
理由は「予測不能な待ち時間」が発生するから。たとえばimplicit waitを10秒、explicit waitを15秒に設定した場合、単純に足し算で25秒待つわけではなく、条件によっては20秒でタイムアウトすることがある。デバッグが地獄になる。
不可逆操作を自動化するなら、待機の仕組みを理解して、どちらか一方に統一するのが安全だ。個人的にはexplicit waitで必要な箇所だけ明示的に待つほうが、意図が読みやすいと思う。
この段階で考えること：
- 本当に自動化すべきか（手動のほうが安全なケースもある）
- エラー時のリカバリ手順
- 実行ログを残して監査できるようにする
- 二要素認証や権限の確認フロー
正直、この段階まで来ると「壊れても困らない」とは言えない。十分にテストして、最初は監視しながら動かすのが現実的だ。
向かない人・別の選択肢
ここまで書いておいてなんだが、全員がPlaywrightやSeleniumを触る必要はない。
定型作業を自動化したいだけなら、ノーコードツール（ZapierやMake）のほうが早いケースも多い。ブラウザ操作に特化したNotteのようなサービスもある。コードを書かずにワークフローを組めるので、非エンジニアでも使える。
一方で、細かい制御が必要だったり、既存のCI/CDパイプラインに組み込みたいなら、PlaywrightやSeleniumのほうが柔軟性がある。
どちらが良いかは「何を自動化したいか」「誰がメンテナンスするか」で変わる。
まとめると
- まずは見るだけ：スクショ取得や表示確認から始める。壊れても実害なし。
- 次に軽い操作：ログインやフォーム送信。ロケータの書き方を意識する。
- 最後に不可逆操作：購入や削除。待機設計とエラーハンドリングが必須。
「いきなり業務の本丸を自動化しよう」とすると、事故ったときのダメージが大きい。小さく始めて、ツールの挙動を理解してから範囲を広げる。当たり前のようで、意外とこの順番を無視して痛い目を見る人は多い。