従来のやり方は何にコストを払っていたか

Page Agentが何を省いたのかを理解するには、まず外部型ツールが1枚のWebページを操作するためにどれだけのものを背負っていたかを見る必要がある。それらはページの中に入らず、ガラス越しに外から指示するしかない。

この外部駆動型の発想は、クロスサイトでのデータ収集やエンドツーエンドテストの実行では今も有効だ。Page Agentが解決しようとしているのは別の悩みだ——そのWebページがもともと自分のプロダクトで、コードを自由に変更できるなら、なぜここまで大回りする必要があるのか、という点である。

1枚のWebページ全体をテキストのリストに圧縮する

現代のWebページは数千のノードを持ちうる。HTMLをそのままモデルに渡すのは遅くて高くつく。Page Agentのやり方は、まずページを一度「脱水」して、本当に操作できるものだけを残すことだ。

脱水前後で、モデルが見るものはどれだけ違うか

原文のデモページはこの一連の流れをそのまま見せている——「Dehydrated DOM」パネルにモデルが読み取ったリストが表示され、隣の「Action trace」パネルは指示の実行に合わせて1行ずつ更新される。実際にステップごとにクリックしていく様子が見える。

指示が届いてから、内部ではどう動くのか

自然言語の指示から、ページ上で本当にクリックされるまで、間には決まった1本のループがある。汚れ仕事は PageController という部品が引き受ける。

PageController が公開しているのはまさにこうした具体的なアクションで、連番を頼りに要素を操作する。

await this.pageController.updateTree()
await this.pageController.clickElement(index)
await this.pageController.inputText(index, text)
await this.pageController.scroll({ down: true, numPages: 1 })

monorepo全体は役割ごとに3つの小さなパッケージに分かれている。

開発者が手にする3つのガードレール

他のツールと比べて、誰が使うべきか

この比較表が言いたいのは場面の違いであって、速さの違いではない。4つの方式はそれぞれ異なる場所で動き、異なる方法でページを読み、それぞれの得意分野がある。

結論は適用範囲に落ち着く。Page Agentはコードを変更でき自分で決められるプロダクト内部に向いている。他人のサイトをクロールしたり、ロックされた環境で作業したりする場合は、依然として外部駆動型が優位だ。

何に使えるか

アプリケーションの中に住み込んでいるからこそ、ユーザーの代わりに本当に操作を完了させられる——ただ横でどう押せばいいか説明するだけではない。原文では具体例が4つ挙げられている。

最小コストはscriptタグ1行

まず感触をつかみたいなら、script タグ1つで無料のテスト用モデル付き Page Agent を読み込み、ページ上で直接体験できる。

<script src="https://cdn.jsdelivr.net/npm/page-agent@1.10.0/dist/iife/page-agent.demo.js" crossorigin="true"></script>

本番利用ではパッケージをインストールし、エンドポイントを自分のものに差し替える。

import { PageAgent } from 'page-agent'

const agent = new PageAgent({
  model: 'qwen3.5-plus',
  baseURL: 'https://dashscope.aliyuncs.com/compatible-mode/v1',
  apiKey: 'YOUR_API_KEY',
  language: 'en-US',
})

await agent.execute('Click the login button')

model と baseURL は任意のOpenAI互換プロバイダーを受け付ける。モデルを変えるのは基本的にbase-URLとキーを変えるだけだ。

できないことがはっきりしている

この「Webページの中に住み込む」というやり方には当然払うべき代償があり、公式もその限界をはっきり述べている。使う前に、この数点はテーブルの上に出しておくべきだ。

プロンプトに書かれた安全ルールは、あくまで提案にすぎない

「支払いフォームを自動送信しない」といったルールは、システムプロンプトの中に置かれている。それらは説得力のある誘導であって、ハードな保証ではない。機密操作や破壊的な操作に対しては、サーバー側の検証を必ず残しておく必要があり、プロンプト内の指示だけを唯一の防衛線にしてはならない。

コアライブラリが管理できるのは単一ページだけ

コアライブラリが狙っているのは単一ビュー内でのインタラクションであり、それ自体はタブやウィンドウをまたいで動くことはできない。ページをまたいだ自動化をしたければ、任意の Chrome 拡張機能をインストールする必要があり、その拡張機能は個別にインストールと権限の許可が必要になる。ほかにも Beta 段階の MCP server があり、Claude Desktop や Copilot のような外部エージェントが逆に Page Agent を操作できるようにしている。

冒頭の一文に戻ると、Page Agent と主流ツールが歩んでいるのは2つの道だ——一方はWebページの内部に埋め込まれてテキストを読み、もう一方は外側に立ってスクリーンショットとプロトコルでリモート操作する。ブラウザ自動化が地に足をつけられる場所を、「外部スクリプトで他人のWebページを操作する」から、「プロダクトが自ら備える自然言語の操作入口」まで押し広げた形だ。

今回アリババは、エージェントをWebページに直接埋め込む一段のJavaScriptコードとして作った。それは本物のユーザーのようにWebページの中に住み込み、ページのテキスト構造を読んでクリックし、入力する。自社プロダクトに組み込んで操作アシスタントにしやすくするためだ。最も直接的に変わったのは、モデルが一回クリックするたびに見るものだ。

テキストを読む方が画像を見るより正確で、しかも省コストだ。画像を見られる高価なモデルを別途用意する必要もない。では、この連番付きのテキストリストは、雑然とした1枚のWebページ全体からどうやって絞り出されるのか。

お家芸は DOM脱水 と呼ばれる（DOMとはブラウザがWebページを分解して作る要素ツリーのこと。脱水とは、ページ全体の数千の部品の中から本当にクリックできるものだけを選び出し、それぞれに連番を振って、簡潔なテキストリストに圧縮することだ）。同じ場面を従来のやり方と並べて見るのが一番わかりやすい。

普通の人が「どれだけ省けたか」を一番実感しやすいのは、手を動かして準備するものの量だ。「プロダクトにユーザーの代わりに画面を操作できるAIアシスタントを加える」という作業で比べてみる。

これらはプロジェクトが公開している事実——ライセンス、バージョン、導入方法であり、性能テストではない。「テキストのみをやり取りするので推論コストがより低い」というのは設計上の推論であり、公式は第三者によるベンチマークを示していない。本番運用ではモデルを自前のものに置き換え、キーはバックエンド側に置く必要があり、demo用のキーをフロントエンドに埋め込んではいけない。