Agentが判断し、Playwrightがブラウザ操作を担っても、環境レイヤーは見落とされがちです。長時間の収集タスクでは、失敗がこの層に集中しやすくなります。
Agentフレームワークでブラウザを動かしてデータを収集する場合、構成は通常3層です。Agentが計画と判断を行い、Playwrightがクリック、入力、データ取得を担当し、最後に対象サイトへアクセスします。短いタスクなら順調に動き、ローカルテストも通ることが多いでしょう。しかし実行時間を延ばし、タスク数を増やしていくと、あまり真剣に扱われてこなかった場所、つまりブラウザ環境に失敗が集中し始めます。
実際に遭遇した問題を振り返ると、環境レイヤーの失敗は大きく3つの形に分けられます。
環境が異常と判定され、パイプライン全体が止まる
1つ目は、プラットフォーム側が環境そのものに対処するケースです。必ずしも明確なブロックではなく、簡略化されたページが返る、結果が空になる、追加の認証を求められる、といった劣化として現れることがあります。スクリプトはエラーを出しませんが、返ってきたデータには意味がありません。それでも後続処理は通常どおり進み、誤ったデータが最終テーブルまで運ばれます。
問題なのは、このような環境が複数タスクで共有されていることが多い点です。1つの環境に問題が起きると、そこにぶら下がるタスクがすべて止まります。原因はスクリプトではないため、リトライしても解決しません。
複数タスクを1つの環境に詰め込むと、セッションが混ざる
並列タスクが同じブラウザインスタンスを共有すると、Cookie、localStorage、IndexedDBが互いに上書きされ、ログイン状態が押し出されることがあります。短時間では目立ちませんが、数日動かすと理由の分からない再ログインが発生します。
さらに分かりにくいのが環境のドリフトです。長時間動作するブラウザでは、キャッシュ、ストレージ、さらにはWebGLのレンダリング状態まで少しずつ変化が蓄積します。同じ環境でも、今日と3日後では特徴が一致しない可能性があります。Cookieの期限切れだと思われがちですが、実際には環境そのものが以前と同じではなくなっています。そのため、毎回新しいブラウザを立ち上げるより、環境を永続的で再利用可能なオブジェクトとして扱うほうが合理的です。
チェックポイントから再開するとき、元の環境が使えないことがある
収集タスクが1回で完了することはあまりありません。中断後にチェックポイントから再開するのは一般的ですが、ここでも無駄が起こりやすくなります。スクリプト再起動時に新しいブラウザインスタンスを作ってしまいログイン状態を失う、あるいは古い環境を使い続けても、すでにプラットフォームにマークされていて処理を続けるほど消耗する、といった状況です。
重要なのはリトライ回数ではなく、復旧の粒度です。タスクがどこまで進んだか、どのデータを取得済みか、どの環境を使っていたかをスクリプトの外に記録していなければ、再起動時には最初からやり直すしかありません。
環境側でできる対策
この3つをまとめると、考え方は3点に整理できます。
タスクごとに環境をグループ化します。1つのタスクに1組の環境を割り当て、複数タスクを1つのインスタンスに詰め込まないようにします。グループ化すれば、タスクごとにネットワーク出口、タイムゾーン、言語を設定できます。これらのパラメータは個別に手動指定するより、セットとして整合させるほうが安定します。この構成でPurpleMarkが担うのは環境レイヤーです。ブラウザ環境を一括作成し、それぞれに独立したネットワーク出口を割り当て、API経由でタスクオーケストレーション層に渡してスケジュールさせます。
失敗を分離します。ある環境が異常と判断されても、影響を受けるのはその環境に紐づくタスクだけにします。一般的には各環境にヘルス状態を持たせて定期的に確認し、異常を検出したら外して予備環境に切り替えます。上位スクリプトに同じ壊れた環境を何度もリトライさせないことが重要です。こうすると、環境の問題なのか、ページ構造の変更なのかも切り分けやすくなります。
状態を復元可能にします。進捗、重複排除用のフィンガープリント、環境IDはスクリプト外に永続保存します。再起動時にはまず記録を読み、どこから続けるか、どの環境を使うかを決めます。タスクを発見、読み込み、抽出といった段階に分けて個別に障害処理できるようにすれば、1か所の失敗で一連の実行全体が無駄になるのを防げます。リソース面にも注意が必要で、長時間稼働するインスタンスではメモリリーク、ページ停止、接続タイムアウトが起こり得るため、無効なセッションは定期的に回収します。
明確にしておくべき境界
環境が安定していることと、収集してよいことは別問題です。まず対象サイトのrobotsルールと利用規約を確認し、自動アクセスを明確に制限しているサイトが多いことを踏まえる必要があります。相手のサービスに影響しない頻度にリクエストを抑え、個人情報は収集せず、技術的な保護措置に遭遇した場合は迂回を試みるのではなく、方針を変更するか許可を取得します。技術的な安定性はコンプライアンス判断の代わりにはなりません。
本内容は技術研究および開発実務の情報交換のみを目的としています。対象サイトの規約と、利用地域で適用される法令に従ってください。
