要素を特定し、操作可能になるまで待ち、操作を実行し、結果を検証する。自動化の1アクションはこの4ステップです。セレクター、動的読み込み、iframe、Shadow DOMの癖を理解すると、長く動くスクリプトを作りやすくなります。
Web自動化は、プログラムに代わりにボタンを押してもらうものだと考えられがちです。しかし実際に実装すると、1つのアクションには4つのステップがあり、どれか1つでも誤ると、何も起きなかったように見えることが分かります。
まず、混同しやすい2つの概念を分けておきます。Web自動化はより広い概念で、本来なら人がWebページ上で行う作業をプログラムで実行すること全般を指し、リクエストで直接データを取得することも含みます。ブラウザ自動化はその中のより具体的な分野で、プログラムが実際のブラウザを操作してページを開き、JavaScriptを実行し、クリックや入力を再現します。動的コンテンツが多い、または操作が複雑な場面では、基本的に後者が必要です。
1つのアクションを構成する4ステップ
- 要素を特定する：id、name、class、CSSセレクター、XPathなどで対象を見つけます。意味のある属性を優先し、それがない場合にだけ構造やインデックスへ戻ります。
- 操作可能になるまで待つ：要素がDOMに存在していても、クリックできるとは限りません。表示される、クリック可能になる、または特定のリクエストが返るまで待ちます。待つのは秒数ではなく条件です。
- 操作を実行する：クリック、入力、スクロールを行います。カスタムコンポーネントでは、人が操作する順序を再現する必要があることが多く、まず展開し、リストの描画を待ち、その後テキストで選択します。
- 結果を検証する：操作後に結果が正しいか確認します。リンクが変わったか、ページの文言が変わったか、APIが何を返したかを見ます。この確認がないと、失敗を成功として扱ってしまい、その後のリトライやアラートの根拠もなくなります。
4ステップの中で、デバッグに最も時間がかかりやすいのは2番目と4番目です。難しいからではなく、エラーを出さずに静かに誤った結果を作ることがあるためです。
セレクターの安定性がスクリプトの寿命を決める
ページが変われば、固定したロケーターは使えなくなります。文言、位置、インデックスでの特定は変更に最も弱く、ボタンが1つ増えたり案内文が1つ変わったりするだけで全体がずれることがあります。
使えるならid、name、data属性を優先します。構造に依存するロケーターが必要な場合は、1か所にまとめておき、変更時に何十行も直さずに済むようにします。書き終えたら放置できるとも考えない方がよいでしょう。Webサイトの更新は日常的で、スクリプトの保守コストの大部分はここにかかります。
動的読み込み：何秒待つかより、何を待つかが重要
現在は、初回読み込みが終わった時点ですべてが揃うページは多くありません。データは非同期リクエストで描画されるため、要素は想定より遅く現れます。
固定待機はよく使われますが、失敗もしやすい方法です。3秒待つ設定は遅いマシンでは足りず、速いマシンでは単なる無駄になります。正しくは、特定の条件が成立するまで待ち、要素が本当にクリック可能になってから操作します。
要素が見つからないなら、まずiframeとShadow DOMを疑う
要素が画面上には明らかにあるのにスクリプトから見つからない場合、セレクターではなくスコープが原因であることが少なくありません。
iframeは独立したドキュメントです。対象のフレームに切り替えてから要素を探し、操作後は外へ戻る必要があります。戻さないと、その後の検索が誤ったコンテキストで行われます。Shadow DOM内のノードは、外側のCSSセレクターから直接一致させることができません。まずshadow rootを取得し、その中から検索します。この2つはページの改修と誤認されやすく、無駄なデバッグにつながります。
ほかにも見落としやすいことが2つある
1つ目はセッションです。ログインが必要なタスクでは、ログイン状態をどう保存して再利用するかを考える必要があります。そうしないと毎回ログインが必要になり、途中の認証で止まることもあります。
2つ目は環境です。すべてのタスクが同じブラウザ環境を共有すると、セッションやキャッシュが相互に影響します。個別なら問題なく動くタスクでも、一緒に実行すると干渉し始めることがあります。タスクが1つから複数になる段階で、環境分離を独立したレイヤーにすると多くの手間を減らせます。PurpleMarkのようなツールは、環境ごとに独立したフィンガープリントと独立したプロキシを提供し、自動化フレームワークは操作の実行に集中します。
始める前に確認しておきたい境界
自動化で置き換えられるのは反復作業であり、実際の人の参加が必要な工程まで置き換えることはできません。リアルタイムの顔認証や人手による審査が対象フローに含まれる場合、そのフローを100%自動化することはできません。
そこで、まず最も単純な方法で確認します。自分で最初から最後まで手動でフローを実行し、各ステップを記録して、通過できない工程がないか確かめてください。そのうえで、どれだけ開発に投資するかを決めます。技術的に可能であることと、ルール上許されていることも別の話なので、対象プラットフォームの利用規約も事前に確認しておきましょう。
