アリババがPage Agentをオープンソース化——スクリーンショットではなくテキストでUIを直接読み書きするエージェントをウェブページに直接埋め込む

従来のやり方はどこにコストがかかるのか

Page Agentが何を省いたのかを理解するには、まず外部ツールがウェブページを操作するために背負っているものを見る必要がある。それらはページの内部に入らず、ガラス越しに外から指示を出すことしかできない。

この外部駆動の発想は、クロスサイトでのデータ取得やエンドツーエンドテストの実行では依然として有効だ。Page Agentが解決しようとしているのは別の面倒だ——そのウェブページがそもそも自分のプロダクトで、コードを自由に書き換えられるなら、なぜそんなに遠回りをする必要があるのか、という点だ。

ウェブページ全体をテキストの一覧に圧縮する

現代的なウェブページは1000を超えるノードを持つこともあり、HTMLをそのままモデルに渡すのは遅くコストもかかる。Page Agentのやり方は、まずページを一度「脱水」し、本当に操作可能なものだけを残すことだ。

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

原文のデモページはこのループをそのまま見せてくれる。「Dehydrated DOM」パネルにモデルが読み取った一覧が表示され、隣の「Action trace」パネルには指示の実行につれて一手ずつ更新が入る。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/[email protected]/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とkeyを差し替えるだけだ。

できないこと

この「ウェブページの中に住み込む」というやり方には、それなりの代償がある。公式もその限界をはっきり示している。使う前に、これらの点をテーブルの上に並べておく必要がある。

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

「決済フォームを自動送信しない」といったルールは、システムprompt内に置かれているだけだ。これらは説得力のあるガイドではあっても、確実な保証ではない。機微な操作や破壊的な操作については、サーバーサイドの検証は必ず残さなければならず、prompt内の指示だけを唯一の防御線にしてはいけない。

コアライブラリが管理するのは単一ページのみ

コアライブラリが狙っているのは単一ビュー内でのインタラクションであり、それ自体はタブやウィンドウをまたいで移動できない。ページをまたいだ自動化を行うには、任意のChrome拡張機能を別途入れる必要があり、この拡張機能にはインストールと権限付与が別途必要になる。さらにベータ段階のMCPサーバーもあり、Claude DesktopやCopilotといった外部エージェントが逆にPage Agentを駆動できるようになっている。

冒頭の話に戻ると、Page Agentと主流ツールは2つの異なる道を歩んでいる。一方はウェブページの内部に入り込んでテキストを読む道、もう一方は外に立ってスクリーンショットとプロトコルで遠隔操作する道だ。これはブラウザ自動化が実際に着地できる場所を、「外部スクリプトで他人のウェブページを操作する」から「プロダクト自身が備える自然言語操作の入り口」へと広げたと言える。