デモなら1つのAgentに1つのブラウザウィンドウで十分です。しかし実運用で数十のタスクを同時実行するには環境の分離が必要で、共有するとログイン状態の混在、タブの競合、障害原因の特定困難が起きます。
AI Agentで何ができるかを示すだけなら、ブラウザウィンドウは1つで足ります。実際の業務に組み込むと、必要なのはすぐに数十のウィンドウになり、しかも互いに干渉してはいけません。原因はAgentそのものではなく、その足元にあるブラウザ環境です。
1つの環境を共有すると何が起きるか
最も分かりやすいのは、Cookieとログイン状態が互いに汚染される問題です。同じブラウザデータディレクトリで2つのタスクが別々のアカウントに順番にログインすると、後からログインした方が先のセッションを上書きすることがあります。片方のタスクがキャッシュを削除すれば、もう片方のページ状態まで失われる可能性があります。
次に起きるのがリソースの奪い合いです。1つのブラウザインスタンスでは、タブ、フォーカス、ダウンロード先、ポップアップが共有リソースになります。2つのタスクが同時に新しいタブを開けば、どのタスクがどのページを操作しているのか分かりにくくなります。片方が開いたダイアログによって、もう片方のスクリプトが停止することもあります。ログイン状態の衝突、データの上書き、操作の相互干渉は、並行実行ではほぼ避けられません。
3つ目の問題は障害発生後に表面化します。スクリプトのロジックが間違っていたのか、それとも途中のどこかで別のタスクが環境を乱したのかを判断しにくくなります。複数のタスクが1つのプロセスと1つのログを共有していると、障害の現れ方まで一定せず、調査コストが大きく増えます。
さらに、少し分かりにくいリスクもあります。複数のIDを同じ環境で長期間動かすと、相互の関連を示す手掛かりが残ります。端末パラメータ、ストレージ状態、ネットワーク出口が同一であるため、プラットフォーム側からは同じ端末で一括操作しているように見えやすくなります。1つのアカウントが異常と判断されると、他のアカウントにも影響が及ぶ可能性があります。
ウィンドウを複数開くだけでは分離にならない
最初に考えがちなのは、手動で複数のウィンドウを開く方法です。見た目は分かれていても、実際には同じブラウザプロファイル、つまり同じCookie、同じローカルストレージ、同じ端末情報を共有しています。ウィンドウ同士で互いのログイン状態が見え、1つのウィンドウでの操作が別のウィンドウに影響することもあります。
本当の分離は、データディレクトリと環境パラメータのレベルで行う必要があります。各環境に独自の保存先、独自の端末パラメータ（解像度、言語、タイムゾーン、フォント、Canvas、WebGLなど）、そして独自のネットワーク出口が必要です。この3つのどれか1つでも欠ければ分離は不完全です。環境を分けても出口を共有していれば、関連付けの判定は依然として有効です。
分離にかかるコストと、その見返り
分離にはコストがかかります。各環境の背後には独立したブラウザプロセスと個別のデータディレクトリがあります。環境数が増えると、まずメモリとCPUへの負荷が目立ちます。1台のマシンで数十の環境を動かすなら、落ちてから対処するのではなく、どれだけ余力が残るかを事前に計算しておくのが一般的です。
調整できる点はいくつかあります。使用頻度の低い環境は回収して必要なときに再起動する、タスクの重さに応じて複数のマシンに分散し1台に集中させない、環境ごとに明確なライフサイクルを設け数百の環境を常時稼働させない、といった方法です。タスクの構成も重要です。同じアカウントで順番に実行するタスクなら複数環境に分ける必要はなく、分けてもリソースを浪費するだけです。
一方で得られるものもあります。分離を正しく行うと、障害の挙動が安定します。問題は特定の環境に属するものとして扱え、原因不明の現象ではなくなります。規模が大きくなるほど、この予測可能性の価値は、共有で節約できる少量のリソースよりはるかに大きくなります。
規模拡大後に環境レイヤーへ置くべき3つの機能
1つ目は一括スケジューリングです。環境は計算リソースのように確保・解放でき、オンデマンド作成、一括起動、同時実行数の制御、失敗時の再試行、自動回収に対応する必要があります。スクリプトの中で1つずつ作成し、1つずつ終了処理する形ではありません。
2つ目は独立したネットワーク出口です。各環境をそれぞれの出口に割り当て、その出口の地域を環境の地理パラメータと一致させます。見落とされやすい項目ですが、分離全体を成立させる前提条件です。
3つ目は状態を照会できることです。どの環境が稼働中で、どれが空いていて、どれに異常があるのかをいつでも確認できる必要があります。Agentは無人で動くため、状態を照会できなければ、問題発生時の調査は推測頼みになります。
この3つをスクリプト内で実装するのは扱いづらく、環境レベルのストレージ、設定、スケジューリングが必要です。複数環境を管理するツールの中には、まさにこのレイヤーを対象にするものがあります。PurpleMarkもその1つで、ブラウザ環境を、分離でき、一括スケジューリングでき、インターフェース経由で呼び出せるリソースとして扱います。
複数環境が不要な場合
Agentが1つのアカウントだけを低頻度で使うのであれば、通常のブラウザで十分であり、追加の分離は保守負担を増やすだけです。ただし、次のいずれかが発生するなら環境レイヤーを独立させるべきです。タスクを並列実行する必要がある、複数のIDで同じプラットフォームへアクセスする必要がある、ログイン状態を長期間維持する必要がある、または今後さらに同時実行規模が拡大する場合です。
これらに共通するのは同じ点です。問題はAgentが十分に賢いかどうかではなく、その足元の環境が十分にクリーンで分離されているかどうかです。
境界
どの構成を選ぶ場合でも、ルール上の境界は変わりません。各プラットフォームの利用規約とrobotsルールを守り、虚偽の本人情報を使用せず、技術的な保護措置を回避せず、リクエスト頻度を制御し、相手方サービスの通常運用を妨げないことが必要です。
