ブラウザ自動化は3つの世代を経てきました。各世代は前世代のボトルネックを解消する一方で、新しいボトルネックを別の場所へ移しています。ツール名を覚えるより、各世代に残る課題を理解する方が有用です。
ブラウザ自動化は20年以上にわたって使われ、その主流の方法は3世代にわたって変化してきました。興味深いのは、それぞれの世代が解決している問題の種類が異なり、1つの問題を解決するとボトルネックが別の場所へ移ることです。
第1世代：OSレベルで人がマウスを動かしているように見せる
最初期の自動化は、実際にはブラウザの中ではなくOS上で行われていました。スクリプトがマウスを動かし、キーを押し、ブラウザはその入力を受け取るだけでした。
利点は汎用性です。画面上に表示されるものであれば、Webページ、クライアントアプリ、古いデスクトップソフトウェアのいずれでも操作でき、ブラウザ側に専用インターフェースを用意する必要もありません。代償も明確でした。スクリプトは画面座標を基準にするため、解像度、システムの拡大率、ウィンドウ位置のどれかが変わるだけで、同じ操作が別の場所をクリックしてしまいます。ページの読み込み完了も判断できないので、固定時間の待機に頼るしかありません。並列実行はさらに厄介で、1台のマシンにはマウスとキーボードが1組しかないため、10個の環境には10台のマシンが必要でした。
この世代が残した問題を一言でいえば、ページが見えないことです。
第2世代：画面を介さず、ブラウザと直接対話する
WebDriverの登場により、自動化はピクセル単位から要素単位へ移りました。画面上の800番目のピクセル位置ではなく、ページ内の特定要素を探すようになったのです。同じコードで異なるブラウザを操作でき、さまざまな言語で記述できたことも、後にテスト分野の標準となった理由の1つです。
その後、ブラウザのデバッグプロトコルを利用する方式がこの流れをさらに発展させました。PuppeteerやPlaywrightはブラウザエンジンと直接通信し、ページ内部の状態を取得できます。要素が操作可能になるまで自動で待つ、リクエストを横取りして書き換える、すでに起動しているブラウザインスタンスへ接続する、ヘッドレスで実行する、複数のコンテキストを並列で開く、といった機能です。現在では当たり前に見える多くの能力が、この段階で整いました。
ここで制御性と安定性は改善しましたが、別の2つの問題が残りました。1つ目は、スクリプトが依然として人によって固定的に書かれていることです。ページ構造が変わったりセレクタが無効になったりすれば、コードを修正する必要があり、プロジェクトが大きくなるほど保守コストも上がります。2つ目はさらに根本的です。この方式が扱うのはどう操作するかであり、誰が操作しているように見えるかではありません。プロトコルで直接接続すれば制御は正確になりますが、通信方式を変えただけで自動化の痕跡が消えるわけではありません。どれだけ安定したスクリプトでも、外部からはスクリプトに見える可能性があります。
第3世代：人が手順を書かなくなり、問題の場所も変わる
第3世代で変わったのは制御方法ではなく、意思決定の方法です。最初の2世代では、どのボタンを押すか、どのフィールドを埋めるか、どの順序で進めるかを人がすべて明示する必要がありました。モデル駆動の世代では、与えるのは目標であり、経路はモデル自身が計画します。ページのデザインが変わっても、別の入口を探し直すことができます。
その結果、セレクタをどう書くか、待機時間をどれだけ入れるかといった従来の細かな問題は、徐々に致命的ではなくなります。しかし、新しい問題はすぐに現れます。
重要なのは、モデル自体がWebページへアクセスするわけではないという点です。実際にページを開き、リソースを読み込み、ログイン状態を維持するのは、依然としてブラウザです。そのためタスクが不安定になったとき、原因はモデルの判断ミスではなく、その下にある実行環境であることが少なくありません。複数タスクが1つのブラウザを共有してCookieやキャッシュを汚染する、fingerprintの特徴がよく似ていてプラットフォームから同じマシン由来に見える、アカウントがタスク間で使い回され1つの異常が広く波及する、環境を一時的に作成して利用後に回収する必要があるのに統一されたスケジューリングがない、といった問題です。モデルが「どうやるか」を解決すると、「どこでやるか」が新しいボトルネックになります。
アーキテクチャに加わるもう1つのレイヤー
3世代を並べて見ると、違いは単純にどれがより先進的かという話ではありません。各世代は、前の世代が取りこぼしたものを引き受ける必要があります。最初の2世代で環境が大きな問題にならなかったのは、自分のマシン上のブラウザを操作していたからです。Agentの段階になると、タスクは大量かつ並列に無人で実行されるため、環境を明示的に管理しなければなりません。各タスクを独立した環境で動かし、fingerprintやセッションを混在させない。ログイン状態をタスク間で保持し、毎回ログインし直さない。IP、タイムゾーン、言語を一式として整合させる。さらに、計算資源のように環境を必要に応じて作成・回収します。
PurpleMarkが担うのはこのレイヤーです。ブラウザ環境をスケジュール可能なリソースに変え、Agentがタスクロジックに集中できるようにします。
これにより選択肢も整理しやすくなります。企業のテストスタックや既存のスクリプト資産は従来のルートを続ければよく、リクエスト単位の制御が必要な複雑なWebアプリケーションにはプロトコル駆動の世代が合います。モデルがタスクを計画し、長期間安定して動かす必要がある場合は、最初の2世代の技術も引き続き使えますが、環境レイヤーは別に解決する必要があります。実際のユーザーが操作しているように見せる必要があるなら、それは世代にかかわらず自動化frameworkだけで提供できるものではありません。
技術ルートとは別に、もう1つ境界があります。自動化された操作は、対象プラットフォームの規則と現地の法律に従う必要があります。技術的に実行できることと、ビジネス上適切であることは同じではありません。
