「設定ボタンを押して、次に『アカウント』タブを開いて、そのあと……」——カスタマーサポートの案内文を、ユーザーの代わりにその場で実行してくれるAIがページの中にいたら。それを<script>タグ1本で実現するのが、Alibabaが公開したオープンソース page-agent です。公開から急伸し、2026年7月時点でGitHubスター 約25,800（週あたり約3,800増）、フォーク約2,400を集めています。

page-agentは「ページに住むGUIエージェント」を掲げます。拡張機能もPythonもヘッドレスブラウザも使わず、すべてページ内のJavaScriptとして動き、ユーザーの自然言語の指示どおりに画面上のボタンを押し、フォームを埋めます。本記事では、このpage-agentが結局何ができて／何を解決し／何を代替するのかを、公式リポジトリとドキュメントという一次情報から読み解きます。

AIエージェントの全体像と主要フレームワークの位置づけは AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 をご覧ください。本記事はその中でも「ブラウザ／ページを操作するエージェント」という一角を深掘りします。

page-agentが自分の公式ドキュメントサイトを自然言語の指示で操作するデモ。マウスカーソルが移動し、要素をクリックし、ページ下部に『Clicked element』の実行ログが出る
page-agentが自身のドキュメントサイトを操作するデモ。要素に番号が振られ、AIが「Docsをクリック」→「Quick Startへ移動」と自走する（出典: alibaba/page-agent）
この記事のポイント
  • ・page-agentはscript1本で任意のWebページにAI操作員を与える“ページ内”GUIエージェント（開発元Alibaba・MIT・npm: page-agent）
  • ・スクショを使わずDOMをテキスト化してLLMに渡す。マルチモーダル不要で速く安いが、視覚的コンテンツは読めない
  • ・browser-use / Skyvern / Nova Act / Claude Computer Use が“外から”ブラウザを操るのに対し、page-agentは“中に組み込む”UX機能で狙う相手が違う

1. page-agentとは何か——「ページに住むGUIエージェント」

page-agent は、Alibabaが公開するMITライセンスのオープンソースです。GitHubの説明文はシンプルに「JavaScript in-page GUI agent. Control web interfaces with natural language.（ページ内で動くJavaScript製GUIエージェント。自然言語でWeb画面を操作する）」。READMEのキャッチコピーは「The GUI Agent Living in Your Webpage.（あなたのWebページに住むGUIエージェント）」です。

page-agentのバナー。ページ内で動くGUIエージェントというコンセプトを示す
page-agentの公式バナー。「One script gives any web page its own AI agent（scriptひとつで、どんなWebページにも専用のAIエージェントを）」（出典: alibaba/page-agent）

ここで重要なのは、page-agentが「誰のための道具か」を明確に定めている点です。公式ドキュメントのOverviewはこう書きます。「page-agentは埋め込み型のGUIエージェントである。従来のブラウザ自動化ツールとは違い、page-agentはWeb開発者とWebアプリケーションを第一に設計されている。あなたのサイトに組み込めば、ユーザーはページと自然言語で対話できる」。

つまりpage-agentは、スクレイピングや業務自動化を組む人のためのツールではありません。自分のサイトに「AIオペレーター」機能を載せたいサイト運営者・Webアプリ開発者のためのライブラリです。この立ち位置の違いが、後述するbrowser-useやSkyvernとの決定的な差につながります。

公式が掲げる核心的な特徴は4つに整理できます。

・🎯 かんたん統合：ブラウザ拡張・Python・ヘッドレスブラウザは不要。すべてがページ内のJavaScriptで完結する
・📖 テキストベースのDOM操作：スクリーンショットを撮らない。マルチモーダルLLMも特別な権限も要らない
・🧠 好きなLLMを持ち込める（Bring your own LLMs）：主要モデルの多く、ローカル配備モデルにも対応する
・🐙 任意でChrome拡張とMCPサーバー：複数ページにまたがるタスクや、ブラウザの外側からの制御にも拡張できる

この4点を一言でまとめると、page-agentは「サイト側が主体的に組み込む、ページ内完結・テキストベースのAI操作レイヤー」です。ユーザーに拡張機能をインストールしてもらう必要もなく、サーバー側に重い自動化基盤を用意する必要もありません。開発者が<script>を1行足すか、npmでimportするだけで、そのページに自然言語の操作口が開きます。

なお、リポジトリはAlibabaの公式アカウント配下で公開されており、Trendshift（GitHubの急上昇リポジトリを可視化するサービス）にも取り上げられています。開発が活発で、コミットも継続的に積まれている点は、実運用を検討するうえで安心材料と言えるでしょう。

2. page-agentは結局、何ができるのか

当サイトの読者がまず知りたいのは「このOSSは結局何ができるのか」です。page-agentの答えは明快で、「ユーザーの一文を、ページ上の実際の操作に変える」こと。デモを見るのが一番早いので、まず先ほどのGIFで何が起きていたかを分解します。

page-agentが操作中の画面。ページ上の各リンク・ボタンに数字の番号が振られ、下部に『Clicked element（[2]<a>Docs/>）』という実行ログのトーストが表示されている
操作の実像。page-agentはページの操作可能要素に番号（[6] [7] [8]…）を振り、LLMが「[2]のDocsリンクをクリック」と決めて実行、結果をトーストで返す

デモでpage-agentは、自分自身の公式ドキュメントサイトを題材に、次のように動いていました。まずページ全体を読み取り、クリック・入力できる要素すべてに番号を付与します。次に「Docsを開く」というゴールに対して[2]のリンクを選び、実際にクリック。画面下部には「✅ Clicked element（[2]<a>Docs/>）」という実行ログが出ます。続けて「Quick Startへ移動」と自走し、ページ内に埋め込まれたパネルで思考過程（Thinking…）を見せながら、目的を達成するまで反復します。

この一連の動きから、page-agentができることが見えてきます。

・要素の操作：ボタンのクリック、テキスト入力、セレクトボックスの選択、フォーム送信
・ページの移動・探索：縦横スクロール、フォーカス移動、同一オリジンの単層iframe内の操作
・多段の手順の自走：「ログインしてから、ユーザー名をJohnにして送信」のような複数ステップの指示を、途中経過を評価しながら順に実行
・状況のフィードバック：どの要素を操作したか、成功したか失敗したかをユーザーに返し、行き詰まったら人間に助けを求める

言い換えると、page-agentは「操作代行」と「操作案内」を兼ねたエージェントです。カスタマーサポートのボットが「設定を押してください」と言葉で案内するのではなく、page-agentは実際に設定を押してくれる。ここに、単なるチャットボットとの本質的な差があります。

use case（想定シーン）として公式が挙げるのは、以下のようなものです。

・SaaSのAIコパイロット：自社プロダクトに数行でAIコパイロットを載せる。バックエンドの作り直しは不要
・スマートなフォーム入力：20クリックの作業を一文に。ERP・CRM・管理画面のような業務システムに最適
・アクセシビリティ：任意のWebアプリを自然言語で操作可能に。音声コマンドやスクリーンリーダーと組み合わせ、操作の障壁をゼロに近づける
・マルチページのエージェント：Chrome拡張を使えば、自前のWebエージェントの手を複数タブへ広げられる

3. どう動くのか：DOMを“脱水”してLLMに渡すエージェントループ

page-agentの心臓部は、「観測→思考→行動→評価」をdoneまで繰り返すエージェントループです。ここが理解できると、なぜスクショが要らないのか、なぜセマンティックなHTMLが効くのかが腑に落ちます。

page-agentのエージェントループ。観測（browser_state・番号つき要素）→思考（LLMがnext_goalを決定）→行動（click/input/scroll）→評価（成否を判定）をdoneまで反復するサイクル図
page-agentの反復ループ。毎ステップ、ページ状態を読み、LLMが次の一手を決め、実行し、成否を評価する

公式のシステムプロンプトを読むと、この設計思想がはっきり見えます。プロンプト冒頭は「あなたはブラウザのタスクを自動化するため、反復ループの中で動作するAIエージェントである」と宣言し、毎ステップの入力を3つに定義しています。

・<agent_history>：これまでの行動とその結果の時系列（各ステップの評価・メモリ・次の目標・行動結果）
・<agent_state>：現在のユーザー要求とステップ情報
・<browser_state>：現在のURL、操作用に番号付けされたインタラクティブ要素、可視のページ内容

そして<browser_state>の要素表記が肝です。プロンプトは「インタラクティブ要素は [index]<type>text</type> の形式で与えられる」と規定し、例として次のように示します。

[33]<div>User form</div>
	*[35]<button aria-label='Submit form'>Submit</button>

ここで[33]のような数字インデックスが振られた要素だけが操作対象であり、インデントのタブ（\t）は親子関係、*[は「前ステップ以降に新しく出現したクリック可能要素」を意味します。page-agentは、この番号付きのテキスト表現＝DOMを“脱水（dehydration）”した状態をLLMに渡し、LLMは「どの番号に何をするか」を決めるだけでよくなります。

LLMが返す構造化された「一手」

LLMの出力もプロンプトで厳密に定義されています。毎ステップ、モデルは次のJSONを返します。

{
  "evaluation_previous_goal": "直前の行動の成否を一文で。成功／失敗／不確実を明言する",
  "memory": "進捗の記憶（訪れたページ数・見つけた項目数など）を1〜3文で",
  "next_goal": "次に実行する目標と行動を一文で",
  "action": { "Action name": { } }
}

actionに入るのが実際の操作です。クリック・テキスト入力・スクロール（num_pagesで半ページ・2ページ単位も可）・wait（未ロード時の待機）・そしてdone（タスク完了・報告）といったアクションが、ページ内のエグゼキュータで実行されます。ループは、LLMがdoneを呼ぶか、最大ステップ数に達するまで回り続けます。プロンプトには「同じ行動を条件が変わらないのに3回以上繰り返すな」「行き詰まったら別のアプローチを試すか、ユーザーに助けを求めよ」といった、暴走を防ぐガードも書き込まれています。

page-agentがQuick Startページを読みながら『Thinking…』パネルを表示し、次のタスクを入力する欄が画面下部に出ている様子
ページ内に埋め込まれる操作パネル。思考中（Thinking…）の表示と、次のタスクを自然言語で入力する欄がユーザーに見えている

アーキテクチャは「4層」で捉える

page-agent全体を層で捉えると、下から順に次の4層になります。

page-agentの4層アーキテクチャ。L1 BYO LLM（OpenAI互換・tool call対応）／L2 DOM脱水（browser-use由来・番号つけ）／L3 エージェントループ（system prompt＋アクション実行）／L4 ページ内実行レイヤー（script1本・バックエンド不要）
page-agentの4層。モデルは差し替え可能、DOM脱水とループが中核、最上層はすべてページ内JSで完結する

この構造をシーケンスとして描くと、次のようになります。

flowchart TD U["ユーザーの自然言語指示
execute で受け取る"] --> S["browser_state を構築
可視要素に番号を付与しDOMをテキスト化"] S --> L["LLM が思考
evaluation・memory・next_goal・action を出力"] L --> A["ページ内エグゼキュータが実行
click・input・scroll など"] A --> C{"done か"} C -->|"未完了・条件変化"| S C -->|"完了・最大ステップ"| D["done で結果をユーザーへ返す"]

この設計の帰結として、page-agentはマルチモーダルLLMを必要としません。ページの意味はHTML構造から取れるからです。裏を返せば、画像・Canvas・WebGL・SVGといった純粋に視覚的な内容は認識できないという限界も、この構造から直接導かれます。公式が「ページのセマンティックの質とアクセシビリティが、AIの理解精度を直接左右する」と明言しているのは、このためです。

なお、DOM処理コンポーネントとプロンプトの一部はbrowser-useから派生しており、READMEはCopyright表記とともに謝辞を掲げています。page-agentは車輪の再発明ではなく、実績あるDOM操作パターンを「ページ内・サイト開発者向け」という文脈に移植したプロジェクトだと理解すると、その素性がよく見えます。browser-use自体の解説は AIエージェントとは？仕組み・種類・代表的OSSフレームワークを初心者向けに解説【2026年版】 でも触れています。

4. browser-use / Skyvern / Nova Act / Claude Computer Useとの違い

page-agentを評価するうえで最も混乱しやすいのが、「browser-useやComputer Useと何が違うのか」です。これらは俗に「ブラウザ操作 AI」とひとくくりにされがちですが、結論から言えば、動く場所（ページ内 vs 外部）と、狙うユーザー（サイト開発者 vs 自動化開発者）が根本的に違います。

外部型（browser-use/Skyvern）と、ページ内型（page-agent）の対比図。外部型はPython・ヘッドレスブラウザ前提でブラウザ全体を操りスクレイパー向け、page-agentはページ内JSだけでSPAページを操りサイト開発者向け
ポジショニングの違い。browser-use/Skyvernは“外から”ブラウザを操る自動化ツール、page-agentは“中に住む”UX機能。用途がそもそも別

公式ドキュメントのOverviewにも、browser-useとの比較表が載っています。それを軸に、代表的な「Web／GUIを操作するエージェント」を並べると次のように整理できます。

ツール 動作場所 前提・依存 操作範囲 認識方式 主な狙い
page-agent ページ内（埋め込みJS） scriptタグ1本 / npm 現在のSPAページ（拡張版は複数タブ） テキスト（DOM） サイトにAI操作機能を組み込む
browser-use 外部（Python） Python + ヘッドレスブラウザ ブラウザ全体 DOM中心（視覚併用可） スクレイピング・自動化開発
Skyvern 外部（サーバー/SDK） Python + クラウド ブラウザ全体 視覚 + DOM ワークフロー自動化
Nova Act（Amazon） 外部（SDK/ブラウザ） SDK + API ブラウザ全体 エージェント型ブラウザ操作 自律的なブラウザ操作
Claude Computer Use 外部（VM/画面） API + スクリーンショット OS／画面全体 視覚（座標クリック） 汎用GUI操作

この表から読み取れる要点は3つあります。

第一に、page-agentだけが「ページの内側」で動きます。他の4つはいずれも、ブラウザやOSを「外側」から制御する前提です。browser-useやSkyvernはPythonとブラウザドライバでWebページを操り、AmazonのNova Actはブラウザを自律操作するSDK、AnthropicのClaude Computer Useはスクリーンショットを撮って画面上の座標をクリックする、いわば「AIに画面とマウスを渡す」方式です。page-agentはこの系譜と真逆で、サイト側が自分の意思でエージェントを内蔵するアプローチを取ります。

第二に、認識方式が違います。Claude Computer UseやSkyvernは視覚（スクリーンショット）を核に据えますが、page-agentはあくまでテキスト（DOM）ベース。視覚モデルは「人間が見るのと同じ画面」を扱えて汎用性が高い反面、コストと遅延が大きく、page-agentのような軽量・高速・低コストの方向とはトレードオフの関係にあります。

第三に、セットアップの重さが桁違いです。外部型はランタイム・ドライバ・（多くは）クラウド環境の用意が要りますが、page-agentは<script>1行、あるいはnpm installのみ。「自社Webアプリのユーザー体験を上げたい」という目的に対しては、page-agentの導入コストの低さが決定的な魅力になります。

したがって、両者は競合というより棲み分けです。「他社サイトを含むブラウザ全体を自動操作したい」「バックグラウンドで大量のタスクを回したい」ならbrowser-useやNova Act。「自分のサイトのユーザーに、その場で操作を代行するAIを提供したい」ならpage-agent。この線引きさえ押さえれば、選定で迷うことはほぼありません。

5. page-agentの導入方法：script1本からNPM・本番運用まで

「何ができるか」に続く読者の関心は「どう入れるか」です。page-agentは導入の敷居を極端に下げており、用途に応じて3つの形態が用意されています。

page-agentの3つの導入形態。PageAgent.js（ページに埋め込む中核ライブラリ）／Chrome拡張（複数タブ・任意ページを操作）／MCPサーバー（外部エージェントから指示）
同じエンジンを「組み込み（PageAgent.js）／拡張（PageAgentExt）／MCP」の3面で使い分ける

① まず試す：CDNのscript1行

いちばん手軽なのは、公式の無料デモLLMを使ったワンライン導入です。任意のページに次を貼るだけで、デモ用エージェントが立ち上がります。

<script
    src="https://cdn.jsdelivr.net/npm/[email protected]/dist/iife/page-agent.demo.js"
    crossorigin="anonymous"
></script>

ただしこのデモCDNは技術評価専用です。無料テストAPI（データは中国大陸のサーバーを経由）を使うため、公式も「個人情報や機微データを入力しないこと」「本番環境で使わないこと」を明記しています。?autoInit=falseを付ければ自動起動を止め、new window.PageAgent(...)で自分で初期化できます。

② 本命：NPMで組み込む

プロダクトに載せるなら、npmインストールが基本です。

npm install page-agent

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／apiKeyで好きなLLMを指すだけ。あとはagent.execute('自然言語の指示')を呼べば、page-agentがループを回して操作を完了します。

本番の鍵：APIキーをフロントに置かない

ここが実運用で最重要のポイントです。公式は「本物のLLM APIキーを絶対にフロントエンドのコードにコミットするな」と警告し、Webアプリに組み込む場合はバックエンドのLLMプロキシを立てて、customFetchでCookie等の認証を付ける構成を推奨しています。

const agent = new PageAgent({
  baseURL: '/api/llm-proxy',
  model: 'gpt-5.1',
  customFetch: (url, init) =>
    fetch(url, { ...init, credentials: 'include' }),
});

こうすればブラウザにはキーが露出せず、認証・レート制限・ログをサーバー側で握れます。個人アシスタント用途で自分だけが使うなら直接接続でも構いませんが、不特定多数に配るならプロキシ経由が事実上の必須だと考えてください。

③ 業務ロジックを渡す：カスタムツール

page-agentは、内蔵の操作（クリック等）だけでなく、あなたのアプリのAPIをエージェントの「道具」として登録できます。入力スキーマはZod（v4）で定義します。

import { z } from 'zod/v4'
import { PageAgent, tool } from 'page-agent'

const pageAgent = new PageAgent({
  customTools: {
    add_to_cart: tool({
      description: 'Add a product to the shopping cart by its product ID.',
      inputSchema: z.object({
        productId: z.string(),
        quantity: z.number().min(1).default(1),
      }),
      execute: async function (input, { signal }) {
        await fetch('/api/cart', {
          method: 'POST',
          body: JSON.stringify(input),
          signal,
        })
        return `Added ${input.quantity}x ${input.productId} to cart.`
      },
    }),
  },
})

同じ名前で内蔵ツールを上書きしたり、scroll: nullのように無効化したりもできます。これにより「DOMを手探りで操作させる」のではなく、「安全に定義された業務APIを叩かせる」という、より堅牢な設計が可能になります。加えて、Chrome拡張（PageAgentExt）を使えばタブの新規作成・切り替え・クローズなど複数ページにまたがる操作ができ、MCPサーバー（Beta）を使えばローカルのエージェントクライアントから自然言語のブラウザタスクを送り込めます。

6. 対応モデルと、page-agentでできること・できないこと

動くモデルの条件

page-agentの「Bring your own LLMs」は看板どおり幅広いですが、条件があります。公式ドキュメントは「OpenAI APIの仕様に準拠し、tool call（関数呼び出し）に対応したモデル」を要件として挙げています。公式がモデル一覧に載せているブランドは以下のとおりで、パブリッククラウドでもプライベート配備でも構いません。

・Qwen（qwen3.5-plus / qwen3.5-flash ほか）
・OpenAI（GPT-5系・GPT-4.1系）
・Anthropic（claude-sonnet-5 / claude-haiku-4-5 ほか）
・Google（Gemini 3系・2.5系）
・DeepSeek・MiniMax・xAI（Grok）・Moonshot（Kimi）・Z.AI（GLM） など

公式のTipsは実務的で、「ToolCall能力の高い軽量モデルを推奨」「ToolCallが弱いモデルは不正な形式を返すことがあるが、よくあるエラーは自動回復する」「小型モデルや複雑なツール定義を扱えないモデルは概して精度が出ない」としています。速度・コスト・ツール精度のバランスが取れた“軽量だが賢い”モデルが、page-agentのループには向くということです。モデル選定そのものの基礎は ローカルLLMを動かす方法｜2026年6月最新オープンウェイト・ランタイム・VRAM要件まで総まとめ が参考になります。

ローカルLLMで動かす

Ollama・LM StudioなどローカルのOpenAI互換ランタイムにも接続でき、オフラインや社内LANでの運用が可能です。要件は明確です。

・CORSを有効化する（そうしないとブラウザからローカルLLMを直接叩けない）
・コンテキスト長を8000以上に設定する（一般的なページは約15kトークンを要し、既定の4kでは切り詰められる）
・tool_call対応のモデルを使う。10B未満は概して非力

# Ollama: 文脈窓を広げ、CORSを許可して起動
OLLAMA_CONTEXT_LENGTH=64000 OLLAMA_HOST=0.0.0.0:11434 OLLAMA_ORIGINS="*" ollama serve

公式はOllama 0.15 + qwen3:14b（RTX3090 24GB）での動作確認に言及しています。LM Studioを使う場合はdisableNamedToolChoiceの有効化が要る、といった細かな注意もドキュメントに整理されています。

できること・できないこと

最後に、テキスト（DOM）ベースゆえの能力の境界を押さえておきましょう。ここを誤解すると「なぜかうまく動かない」につまずきます。

page-agentの得意・不得意。対応：クリック・入力・選択・スクロール、フォーム送信・同一オリジンiframe、意味づけされたHTMLほど高精度。非対応：ホバー・ドラッグ・右クリック、画像/Canvas/WebGLの視覚認識、跨ドメインiframe・座標操作
DOMベースの得意・不得意。純粋に視覚的な操作や跨ドメインの領域は苦手だが、セマンティックなHTMLほど精度が上がる

対応する操作は、クリック・テキスト入力・選択・縦横スクロール・フォーム送信・フォーカス移動・同一オリジンの単層iframe・（オプトインで）JavaScript実行。非対応は、ホバー・ドラッグ＆ドロップ・右クリックメニュー・キーボードショートカット・座標指定操作・描画（Canvas）操作、そしてネスト／跨ドメインのiframeや、Monaco・CodeMirrorのようにJSインスタンス経由でしか制御できないエディタです。

理解の面でも制約があります。page-agentはスクショを撮らず視覚能力を持たないため、画像・Canvas・WebGL・SVGの中身は読めません。「反直感的な操作ロジック」「視覚だけで示される操作ヒント」「一瞬で出て消える要素」なども成功率を下げます。逆に言えば、セマンティックなHTMLとアクセシビリティを整えるほど、page-agentは賢くなる。これは、AI時代に「アクセシブルなマークアップ」の投資対効果が上がることを示す好例でもあります。

7. page-agentは何を代替できるのか——ユースケースと使いどころ

3つ目の読者質問「何を代替できるのか」に答えます。page-agentが置き換えるのは、大きく分けて「言葉だけの操作案内」と「作り込みの重いガイド機能」です。

page-agentのユースケースと数字のダッシュボード。scriptタグ1行でAIオペレーターを付与、答弁ボットのエージェント化・B2B管理画面の入口・自然言語アクセシビリティ、GitHub25.8kスター・fork2.4k・週間3.8kスター増、npm page-agent・MIT・browser-use継承・Alibaba公式
page-agentの使いどころと勢い。「案内する」を「その場で操作する」に変える。1行で導入でき、リポジトリの伸びも急

具体的には、次のような場面でpage-agentは既存の作り込みを不要にします。

・答弁ボットの“エージェント化”：「設定→アカウント→…と押してください」と案内する従来のFAQボットを、実際に操作してくれるエージェントに変える。サポートコストの削減に直結する
・レガシー／B2Bアプリの近代化：20クリックを要する管理画面の作業を「経費精算を申請して」の一文に。UIを作り直さず、1行のscriptで“操作の入口”を新設できる
・対話的なプロダクト教育：「経費精算の申請フロー」をAIが実際に操作しながら見せる、ライブのオンボーディング
・自然言語アクセシビリティ：視覚障害・高齢のユーザー向けに、音声やスクリーンリーダーと連携した自然言語の操作口を提供する

こうした用途で従来使われてきたのは、driver.js的なプロダクトツアー、独自に組んだガイド付きウィザード、あるいは「クリックする場所を矢印で示す」タイプのオンボーディングツールでした。page-agentはこれらを、「ユーザーの意図をその場で実行する」というより上位の体験で置き換えられる可能性があります。ツアーは決められた1本道しか案内できませんが、page-agentはユーザーがやりたい任意のタスクに応じて動けるからです。

page-agentが要素をクリックした直後の画面。ページ下部に緑のチェックと『Clicked element』の実行ログが表示されている
操作のたびに「何をしたか」がユーザーに可視化される。これがオンボーディングやサポート用途での信頼につながる

一方で、使いどころを見誤らないことも大切です。page-agentは「自社サイト・自社Webアプリのユーザー体験を上げる」ためのもの。他社サイトを含むブラウザ全体の自動操作や、バックグラウンドでの大量ジョブ実行が目的なら、browser-useやSkyvern、Amazon Nova Actのような外部型が適します。逆に「ユーザーに拡張機能を入れさせず、サイト側でAI操作を完結させたい」なら、page-agentはほぼ唯一解に近い選択肢です。

運用面では、コミュニティの状況も判断材料になります。開発者は「ボットやAIだけで人の関与なく生成された貢献は受け付けない」とREADMEで明言し、プロジェクトの原則と現状についての注記（Issue #349） を残しています。急成長中のOSSでありながら、品質と方向性を保とうとする姿勢がうかがえます。MCPサーバーがまだBetaであるなど発展途上の部分はありますが、コアのユースケース——「サイトに自然言語の操作口を1行で足す」——はすでに実用段階にあると言ってよいでしょう。

AIエージェントを本番投入する際の一般的な設計指針は 12-Factor Agents徹底解説：本番投入できる信頼性の高いAIエージェントを作る12の設計原則 も併せて参照すると、page-agentの制御機構（許可リスト・データ脱敏・カスタムツール）の意味がより立体的に理解できます。

まとめると、page-agentは「ページに操作の口を1行で開ける」ツールです。 AIエージェントの潮流の中で、page-agentは明確な独自ポジションを取っています。browser-useやClaude Computer Useが「AIに画面とブラウザを渡して外から操らせる」方向を追うのに対し、page-agentは「サイト側が自分のページにAIオペレーターを埋め込む」という逆張りの発想です。スクショを使わずDOMをテキスト化する軽量設計、<script>1行という導入の軽さ、そしてサイト開発者という明確なターゲット——この3点が噛み合い、公開直後から2.5万スターを超える支持を集めました。

「サポートの案内文を、ユーザーの代わりに実行してくれるAIがページの中にいたら」。その問いに、page-agentはawait agent.execute('...')という一行で答えます。自社プロダクトのUXを次の段階へ進めたい開発者は、まずデモCDNで手触りを確かめてみる価値があります。

参照ソース

・alibaba/page-agent（公式リポジトリ・README）
・Overview / Models / Limitations（page-agent 公式ドキュメント）
・browser-use（page-agentがDOM処理・プロンプトを継承した元プロジェクト）
・プロジェクトの原則と現状についての注記（Issue #349）
・Hacker News での議論