Agent自動化が規模拡大とともに停止・失敗し始める場合、原因はモデルやスクリプトではなくブラウザ環境レイヤーにあることが少なくありません。ここでは代表的な4つの障害パターンについて、観測できる兆候と対応するエンジニアリング手法を整理します。
LangChain、AutoGen、CrewAIでAgentを構築し、PlaywrightやPuppeteerを使ってWebサイトを操作させること自体はそれほど難しくありません。難しいのは、それを継続して安定稼働させることです。
導入直後は、問題が表面化しないことがよくあります。タスク量が増えると、サイトに処理を止められる、アカウントのログイン状態が突然無効になる、複数のAgentsを同時実行した際に互いの状態へ干渉するといった異常が集中して発生します。多くの場合、最初にコードを見直しますが、最後にはコード自体に問題がなかったと分かります。
原因はブラウザ環境レイヤーにあることがよくあります。大量実行するプロジェクトでは、障害の形は実際にはいくつかのパターンに収束します。見分けられるようになれば、対処そのものはそれほど複雑ではありません。
環境が準備できる前に実行する
新しく作成したブラウザ環境を最初から本番タスクに使うと、ログインできない、ページ要素が完全に読み込まれない、最初の操作で認証が表示されるといった問題が起きがちです。理由は単純で、その環境にはアクセス履歴もCookieもブラウジング履歴もありません。プラットフォームからは完全に未知の端末に見えるため、信頼度が低い状態から始まります。
観測できる特徴は、環境作成直後の数回のタスクに失敗が集中することです。同じタスクを、しばらく利用している環境へ移すと正常に完了する場合があります。
対策は、環境の準備完了を明示的な状態として扱い、最初から利用可能だと仮定しないことです。環境作成後は、まず低負荷のブラウジングを一定期間行い、状態が安定してから本番タスクを割り当てます。スケジューラも、環境を受け取ったらすぐ使うのではなく、タスク配布前にこの準備状態を確認する必要があります。
複数タスクが同じ環境を奪い合う
並列数が増えると、プロセスが積み上がり、メモリを消費し、システムが重くなるという分かりやすい症状が出ます。さらに厄介なのは隠れた問題です。2つのタスクが同じCookieとローカルストレージを順番に使うことで、Aのログイン状態がBを追い出し、ログ上はランダムなタスクが時々失敗しているように見えます。原因の特定は困難です。
ここでは、ブラウザ環境を取得・解放できるリソースとして扱う必要があります。タスク開始時に1つの環境を取得し、終了時に返却し、タスクと環境を1対1に対応させます。環境ごとのストレージは相互に見えないため、あるタスクのログイン状態が別タスクに漏れません。数十のAgentsを並列実行する規模になると、「スクリプトの中で多数のブラウザプロセスを立ち上げる」方式との差が非常に明確になります。
複数アカウントを扱う場合は、さらに厳格な分離が必要です。各アカウントに固定環境を割り当て、フィンガープリント設定とストレージが他のアカウントと重ならないようにします。PurpleMarkは、アカウントと環境の安定した1対1対応を維持するための環境分離と集中スケジューリングのレイヤーを提供します。
セッション切れに気づかない
この障害はエラーが出ないことがあり、特に見落としやすいものです。タスクもログ出力も続いているのに、実際にはログインページや空データが返されています。結果がデータパイプラインに入ってから初めて気づくため、下流からさかのぼって調査することになり、コストが高くなります。
対策は、ログイン状態を明示的な前提条件として確認することです。タスク開始前に現在のセッションが有効かをチェックし、期限切れなら無効な状態のまま処理を続けず、完全なログインフローを実行します。状態自体は環境レイヤーに置き、Cookie、ローカルストレージ、閲覧履歴を環境に保存して、次回起動時に完全復元できるようにします。これにより、アカウントタスクを毎回初期化する必要がなくなります。
実務上の注意点として、長期間稼働するアカウントでは、ログイン状態が頻繁に変わること自体が異常なシグナルと見なされ、追加認証につながる場合があります。不要な再ログインはできるだけ避けるべきです。
ブロック後にバッチ全体が止まる
もう1つの障害は、突然まとまって発生し、多数のタスクが同時に結果を返せなくなるケースです。サイトが明確な拒否を返すとは限らず、むしろ内容を制限したページや空ページを返すことが多くあります。Agentは意味のないデータで処理を続け、データ工程に入ってから問題が表面化します。
この場合、最初にブロックと通常の失敗を切り分けます。同じグループの環境が近い時間帯に一斉に異常になるなら、原因は環境レイヤーにある可能性が高いと考えられます。そのまま再試行を続けると影響範囲が広がるため、まず該当環境を停止・隔離し、その後でトリガーを調べます。
よくあるトリガーは3方向です。複数環境でWebGL、Canvas、フォント一覧、エンジンバージョンなどのフィンガープリント設定がほぼ同じになっていること、出口IP・タイムゾーン・言語が整合していないこと、たとえば米国IPなのにアジアのタイムゾーンを使っていること、そして操作間隔が規則的すぎてリズム自体が特徴になることです。設定を整合させ、操作テンポを管理し、環境状態とタスク結果の両方をログに残すことで、バッチ全体の障害になる前に兆候を把握できます。
このレイヤーを独立させる
成熟したプロジェクトでは、ブラウザ環境をAgentから切り離し、独立したレイヤーとして扱うのが一般的です。Agentは計画と意思決定、環境レイヤーはIDと状態、実行レイヤーは従来どおりPlaywrightまたはPuppeteerを担当します。分離することで、IDが妥当か、状態を復元できるか、タスク同士が隔離されているかを管理する場所が明確になります。
振り返ると、上の4種類の障害には共通点があります。いずれもモデルの中にも、スクリプトのロジックの中にもありません。モデルとコードの改善はもちろん必要ですが、自動化が長期にわたって安定稼働できるかどうかは、より下位にあるこのレイヤーで決まることが少なくありません。
本内容は、技術研究および開発実務の共有を目的としています。自動化は合法かつ適切な範囲で利用し、対象プラットフォームの利用規約および適用される地域の法令を遵守してください。
