AgentがWebタスクを実行する際の失敗は、要素の特定、待機とタイムアウト、状態の保存、環境側のブロックという4領域に集中しがちです。各ステップの冪等化、再試行可能な失敗のリトライ、状態の永続化、タスク単位の環境分離によって成功率を安定させやすくなります。
Web自動化を始めたばかりの頃は、処理フローを書いてスクリプトを動かせばよい、と考えがちです。ロジックに問題はなさそうでも、タスクは断続的に失敗し、アカウント状態にも時折異常が出ます。まずコードを疑いますが、詳しく調べると問題は主に4か所に集約されます。
ページが変わると要素の特定が失敗する
多くのスクリプトはセレクターで要素を探します。セレクターを固定してしまうと、ページ上のほぼどんな変更でも無効になる可能性があります。ボタンのクラス名が変わる、文言が1語変わる、ある領域がサーバーサイドレンダリングから非同期読み込みに切り替わる、要素が新しいコンテナで囲まれる、といった変更です。A/Bテストでは、同じページでもアカウントごとに構造が異なる場合さえあります。
典型的な症状は、要素が見つからない、クリック位置がずれる、同じ名前でも別の場所にあるコントロールを押してしまう、といったものです。この種の失敗はネットワークの揺らぎではないため、数回リトライしても改善しません。
現実的な対策は、絶対パスへの依存を減らすことです。アクセシビリティ属性、安定した業務ID、要素同士の相対関係を優先し、同種のページには代替セレクターを用意して、主セレクターが失敗したら自動的にフォールバックできるようにします。ページにiframeやShadow DOMがある場合は、先に正しいコンテキストへ切り替えないと要素特定は失敗します。
待機時間とタイムアウトの範囲が合っていない
待機が短すぎると、要素のレンダリングが終わる前に失敗と判定され、スクリプトのバグのように見えます。長すぎると、1件のタスク時間が無駄に伸び、スループットが低下し、長いタイムアウトが本当のエラーを隠すこともあります。
固定のsleepより信頼できるのは明示的な待機です。対象要素が現れる、リクエストが返る、ローディング表示が消える、といった具体的な条件を待ちます。タイムアウトの予算は、1ステップ、1ページ、タスク全体で別々に階層化し、すべてに同じ値を使うのではなく段階的に絞り込むべきです。
また、「ページが操作可能になった」と「業務結果が生成された」を分けて待つ必要があります。前者はDOMの準備完了を待てば十分なことが多い一方、後者ではAPIコールバックやページ上のステータス文言の変化を待つ必要があります。待つ対象を間違えると、操作は成功したように見えても実際にはデータが書き込まれていない、という状態になります。
複数ステップの途中で進捗が失われる
登録、注文、公開といったタスクは簡単に10数ステップになります。タイムアウトによる終了、ブラウザのクラッシュ、ホストの再起動などでプロセスが途中停止したとき、状態をメモリにしか置いていなければ、次回は最初からやり直すか、直前のステップをもう一度送信することになります。
重複実行は単純な失敗より調査が難しくなります。同じ操作が2回実行され、上流システムに余分なレコードが増え、原因も追いにくくなります。
対策は、各ステップに永続化ポイントを持たせることです。1ステップ完了するごとに、タスクの一意な識別子とともに進捗を永続化できる場所へ書き込み、再起動後は最後に成功した地点から再開します。複雑なフレームワークは不要で、ファイル1つや状態レコード1件でも十分です。
環境側のブロックはコードエラーと同じように見える
最初の3種類はタスク内部の問題ですが、もう1種類は環境側から生じます。サイトはブラウザ特性、アクセス行動、ネットワークの送信元などを組み合わせてアクセス元を判断することがあります。疑わしいと判定されると、確認ページ、空のコンテンツ、あるいは単純なタイムアウトを返す場合があります。タスクログ上では実行エラーとほとんど区別できません。
よくある要因は次のとおりです。
- 送信元IPの地域、タイムゾーン、言語が一致していない
- すべてのタスクが同じブラウザ環境からリクエストを送り、単位時間あたりのリクエスト密度が実ユーザーより明らかに高い
- 環境が頻繁に変わる、またはアカウントが何度も再ログインする
成功率を上げる4つの取り組み
- 各ステップを冪等にする。実行前に前提条件がすでに満たされていないか確認し、同じ操作を繰り返しても追加の副作用が出ないようにします。参照系操作は自然に冪等ですが、書き込み系は一意な識別子や重複排除キーで保護する必要があります。
- 失敗を分類する。要素がまだレンダリングされていない、ネットワークが揺らいだ、APIが5xxを返した、といった一時的な失敗はバックオフ付きで再試行できます。アカウント制限、不正なパラメータ、対象リソースが存在しない、といった確定的な失敗は何度試しても変わらないため、終了扱いにして並行実行枠を占有し続けないようにします。
- 状態を定期的に永続化する。進捗、中間成果物、現在のステップを保存し、タスク再起動後に最初からではなく途中から続けられるようにします。
- タスク単位で実行環境を分離する。各アカウントまたは各タスクに独立したブラウザ環境を割り当て、Cookieとローカルストレージを共有せず、fingerprint特性には妥当な差を持たせ、タイムゾーンと言語は送信元IPの地域に合わせます。
4つ目は、タスク規模が大きくなるほど特に重要です。数十から数百のタスクを並行実行すると、環境レイヤーが安定性の上限を決め、問題発生時の影響範囲も左右します。PurpleMarkはこのような場面で、独立環境を必要に応じて作成し、まとめて回収する機能を提供します。各アカウントが専用環境を持つため、タスク間で状態が汚染されません。
本内容は技術研究および開発実践の共有のみを目的としています。関連技術は法令とルールを守って利用し、対象プラットフォームの利用規約に従ってください。
