Webページ埋め込み型AIエージェント「PageAgent」の仕組み

「自社の Web アプリに AI コパイロットを載せてほしい」——生成 AI の実用化が進んだ 2026 年、経営層からこの種の要求を受けたフロントエンドエンジニアは多いのではないでしょうか。しかし、いざ調べ始めると browser-use、CopilotKit、Playwright、そして今回取り上げる PageAgent など、似て非なる選択肢が次々に出てきます。

これらは「AI × ブラウザ」という共通項こそあるものの、動作するレイヤ・対象開発者・導入コストが大きく異なります。特に「既存の React / Next.js プロジェクトに、最小改修で自然言語操作を追加したい」というニーズには、外部ブラウザ制御型のツールは重すぎることが少なくありません。

本記事では、Alibaba がオープンソースで公開している PageAgent（alibaba/page-agent） を取り上げます。PageAgent は「ページ内 JavaScript として動く GUI エージェント」という設計思想を持ち、バックエンド改修不要で既存 Web アプリに自然言語操作を組み込める OSS です。

初見のエンジニアが「自プロジェクトに採用すべきか」を判断できるよう、リポジトリの基本情報、設計思想、技術構成、主なユースケース、導入コード、類似 OSS との違いまでを一次情報ベースで整理します。本記事は動作検証を伴わず、README・公式ドキュメント・公式サイトなどの一次情報のみに基づいて記述しています。

PageAgent とは何か

PageAgent は、Alibaba がオープンソースで公開している「JavaScript in-page GUI agent」です。Web ページ内に埋め込むだけで、そのページを自然言語で操作できる AI エージェントとして機能します。

リポジトリの基本情報

まずは一次情報として、GitHub リポジトリのメタデータを確認します（2026 年 7 月 2 日時点、alibaba/page-agent より）。

Star 21,000 超は「新興 OSS としては強い注目を集めている」水準であり、直近 3 か月でも複数のリリースが行われています（詳細は後述の採用判断のポイントで述べます）。MIT ライセンスであるため商用利用のハードルも低く、ライセンス面での懸念はほぼありません。

一言で言うと「ページ内蔵の GUI エージェント」

公式サイトでは PageAgent を「a purely web-based GUI Agent. Gives your website an AI operator in simple steps」と説明しています（公式 Overview）。日本語で表現するなら「Web サイトに自然言語で動く AI オペレーターを載せるための、ページ内蔵型の GUI エージェント」となります。

伝統的なブラウザ自動化ツールが「エージェント / スクレイパー開発者向け」であるのに対し、PageAgent は「Web サイト開発者・Web アプリケーション向け」に設計されています。この対象開発者の違いが、後述する設計思想の分岐点になっています。

PageAgent が解決する課題と設計思想

「Web ページに AI 機能を載せる」というテーマは、これまで大きく 3 つのアプローチで実現されてきました。外部ヘッドレスブラウザによる自動化、ブラウザ拡張の開発、そして各アプリでの独自 UI 実装です。しかしいずれも、既存 Web アプリへの後付けには保守負荷や UX 上の制約がつきまといます。PageAgent はこの問題領域に対し、「ページ内 JS」「テキストベース DOM」「Bring Your Own LLM」「Zero Backend」 という 4 つの設計選択で答えています。

ページ内 JavaScript として動く選択（Zero Backend）

PageAgent は、ページ内で動作する JavaScript ライブラリとして提供されています。ブラウザ拡張のインストールも、外部の Python プロセスや headless browser も、専用のバックエンドサーバも必要ありません。

この「Zero Backend」設計により、既存の Web アプリに <script> 一行、または npm install で組み込むだけで自然言語操作を追加できます。バックエンドの改修や新規インフラの構築が不要であるため、SaaS プロダクトのフロントエンドチームだけで検証・導入判断を進められる点は、意思決定コスト面で大きな利点です。

テキストベース DOM 分析の設計理由

PageAgent は、ページ理解にスクリーンショットやマルチモーダル LLM を使用しません。DOM 構造をテキストとして解析し、操作対象要素を特定します（公式 Overview の「Smart DOM Analysis」参照）。

この選択には合理性があります。マルチモーダル LLM は入力トークン単価が高く、スクリーンショットを都度送信すると運用コストが跳ね上がります。一方 DOM テキストのみであれば、軽量・安価な LLM（後述する tool call 対応の中小規模モデル）でも十分な精度が得られるという設計判断です。

ただしこの選択は制約と表裏一体で、Canvas / WebGL / SVG のような視覚要素は「PageAgent からは見えない」ことを意味します。この点は「対応 / 非対応の操作範囲」で改めて整理します。

Bring Your Own LLM（OpenAI 互換 + tool call）

PageAgent は特定のクラウド LLM に縛られておらず、開発者が「自分で選んだ LLM」を組み込む「Bring Your Own LLM」方式を採用しています。要件は「OpenAI API 規格準拠、かつ tool call に対応していること」の 2 点のみです（Models ページ）。

これにより、Alibaba の Qwen、OpenAI の GPT、Anthropic の Claude、Google の Gemini、DeepSeek などを自由に切り替えられます。既に社内で契約している LLM プロバイダをそのまま流用できるため、追加調達や新規契約の判断を省略できます。

PageAgent の技術構成と主要機能

続いて、PageAgent の内部構成と主要機能を確認します。「自プロジェクトの技術要件と合うか」を、パッケージ・モデル・拡張形態・制限事項の 4 側面から見ていきます。

モノレポの内訳（packages/）

PageAgent はモノレポ構成を採っており、packages/ ディレクトリに以下のパッケージが並んでいます。

分割の粒度から、Agent 実行、ページ操作、LLM 接続、UI といった責務が独立していることが読み取れます。自社の要件に合わせて @page-agent/llms だけを個別利用する、といった発展的な組み込みも可能な構成です。

対応 LLM とモデル要件

前述のとおり、PageAgent は「OpenAI API 規格 + tool call 対応」のモデルであれば基本的に利用できます。公式の Models ページ では、テスト済みモデルとして以下のカテゴリが列挙されています。

• Qwen（Alibaba）: qwen3.7-max / qwen3.6-max / qwen3.5-plus（推奨 Baseline）/ qwen3.5-flash（Baseline） など
• OpenAI: gpt-5.5 / gpt-5.4 / gpt-5.4-mini（Baseline）/ gpt-5.1（Baseline） など
• Anthropic: claude-opus-4.8 / claude-sonnet-4.5 / claude-haiku-4.5（Baseline） など
• Google Gemini: gemini-3.5-flash（Baseline）/ gemini-3-pro など
• DeepSeek: deepseek-v4-pro / deepseek-v4-flash（Baseline） など
• その他: MiniMax / xAI Grok / Moonshot Kimi / Z.AI GLM

推奨されるのは「ToolCall 能力の強い軽量モデル」です。小型すぎるモデルや複雑な Tool 定義に対応できないモデルでは、期待どおりの精度が出ないと明記されています。実運用では Baseline モデルから始め、精度不足があれば上位モデルへ切り替える手順が現実的です。

PageAgent.js と PageAgentExt（Chrome 拡張）の使い分け

PageAgent には、ライブラリ本体である「PageAgent.js」と、Chrome 拡張として提供される「PageAgentExt」の 2 形態があります。

自社サービスに「エンドユーザ向けの AI コパイロットを載せる」目的では PageAgent.js が主軸となります。一方、「複数タブをまたぐ社内業務エージェント」を作りたい場合には、PageAgentExt（Chrome 拡張ドキュメント）が候補になります。

MCP Server（Beta）

Beta 機能として、外部の Agent クライアントからブラウザ制御を委譲するための MCP Server も提供されています（MCP Server ドキュメント）。Claude Desktop などの MCP 対応クライアントから、PageAgent を経由してブラウザを操作させるユースケースが想定されます。

現時点で Beta 表記であるため、本番用途に載せる場合は仕様変更リスクを織り込んで検証する必要があります。

対応 / 非対応の操作範囲（Limitations）

「何ができるか」と同じくらい「何ができないか」を把握することが、意思決定には重要です。公式の Limitations ページ には、対応 / 非対応が明確に列挙されています。

前述のとおり PageAgent は視覚認識を持たないため、Canvas / WebGL / SVG など視覚専用要素は基本的に扱えません。逆に言えば、セマンティック HTML で構築された B2B 業務アプリ・管理画面のような領域は得意分野です。ページのセマンティクス品質とアクセシビリティが、そのまま PageAgent の精度に直結する点は覚えておく価値があります。

PageAgent の主なユースケース

公式は Overview と README の中で、PageAgent の代表的なユースケースをいくつか挙げています。ここでは技術ブログ読者にイメージが湧く粒度で整理します（詳細は 公式 Overview 参照）。

• サポートボットの拡張: 従来の「案内型」チャットボットに操作能力を持たせ、ユーザに代わってフォーム入力や設定変更まで代行させる用途。
• レガシー B2B アプリのモダン化: 複雑な業務システムに、自然言語入力から目的の画面・操作へジャンプする UI を後付けする用途。UI 全体のリニューアルなしで UX を改善できる点が特徴です。
• インタラクティブトレーニング: 「精算申請の一連の操作」といった業務手順を、実際の画面上でエージェントに操作させながらデモ表示する用途。
• アクセシビリティ: 視覚障害者や高齢者に向けて、自然言語入力（音声アシスタント経由を含む）から Web アプリを操作できる導線を提供する用途。
• スマートフォーム入力: ERP / CRM / 管理画面など「20 クリックの入力作業」を、1 センテンスの自然言語指示に置き換える用途。
• マルチページ Agent（PageAgentExt 経由）: Chrome 拡張版を使い、複数タブを跨いだ業務タスクをエージェントに任せる用途。
• MCP 経由の外部制御（Beta）: MCP 対応の Agent クライアントから、ブラウザを間接的に制御させる用途。

いずれのユースケースにも共通するのは「既存の Web UI をそのまま活かしつつ、自然言語という別レイヤの入口を追加する」という発想です。既存 UI を書き換えたくない、あるいは書き換えのコストが正当化できない状況で真価を発揮する設計と言えます。

PageAgent の導入と最小構成コード

公式 Quick Start と README に沿って、PageAgent の導入経路を整理します。本記事では動作検証は行わず、公式ドキュメントの記述をそのまま引用しています。

CDN 一行導入（Demo）

もっとも軽量な導入方法は、CDN 経由の Demo スクリプトです。以下の一行を HTML に追加するだけで、Alibaba がホストする無料のテスト用 LLM API を利用しつつ、ページ上に PageAgent の UI パネルが表示されます。

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

出典: alibaba/page-agent README

Demo CDN は無料のテスト用 LLM API 前提となっており、本番運用ではなく評価・検証用途に位置づけられています。URL に ?autoInit=false を付けると、自動初期化なしで new window.PageAgent(...) を手動生成することも可能です。

NPM 経由の本格導入

本格導入には NPM 経由のインストールが推奨されます。以下は README で示されている最小構成です。

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')

出典: alibaba/page-agent README

LLM 設定と agent.execute() の呼び出し

上記コードのポイントは、baseURL と apiKey を明示的に指定している点です。前述の「Bring Your Own LLM」設計により、baseURL を自社の LLM ゲートウェイに向ければ、既存の API キー・監査ログ基盤をそのまま流用できます。

agent.execute() に渡すのは自然言語のコマンド文字列で、上記の例では「Click the login button」というシンプルな指示を渡しています。より複雑なタスクをどこまで一貫して処理できるかは、選択したモデルの tool call 能力と、対象ページのセマンティクス品質に左右されます。

PageAgent と類似 OSS との違い

「PageAgent は良さそうだが、browser-use や CopilotKit と比べてどう選べばいいのか」——これが検索者の関心の中心にある問いです。ここでは代表的な類似 OSS 2 件に加え、参考として Playwright / Selenium との位置づけの違いを整理します。

browser-use との違い（設計思想の分岐点）

browser-use（browser-use/browser-use） は、Python + Playwright ベースの外部ブラウザ自動化ツールです。実は PageAgent の README「Acknowledgments」には、DOM 処理コンポーネントとプロンプトが browser-use から派生している旨が明記されており、両者は技術的な系譜を共有しています。しかし設計思想は真逆で、両者は「同じ問題領域を、異なる方向から解く」関係にあります。

PageAgent が有利な点: バックエンド不要で導入コストが低い、モデルコストが低い（テキストのみ）、Web アプリの UX を直接強化できます。

browser-use が有利な点: マルチページ・複雑タスクの外部自動化に強い、Vision フォールバックで視覚専用要素にも一定対応できます。

「自社サービスに載せたい」なら PageAgent、「外部からのブラウザ自動化基盤を組みたい」なら browser-use、と用途で棲み分けるのが実務的な判断軸です。

CopilotKit との違い（フレームワーク依存とプロトコル指向の差）

CopilotKit（CopilotKit/CopilotKit） は、React / Angular / モバイル向けに Generative UI やエージェントアプリを構築するための SDK 群で、AG-UI Protocol を中核に据えたエコシステムです。

PageAgent が有利な点: 既存 Web アプリ（フレームワーク不問）に後付けできる、専用プロトコル不要、バックエンド改修不要。

CopilotKit が有利な点: Generative UI や複雑なチャット体験の構築、マルチプラットフォーム展開（Web / モバイル / Slack / Teams）に強みがあります。

新規のエージェントアプリを 0 から作るなら CopilotKit、既存の Web アプリに「操作代行」を後付けしたいなら PageAgent という住み分けが妥当です。

Playwright / Selenium との位置づけの違い

参考として、Playwright / Selenium との位置づけの違いも触れておきます。これらはあくまで開発者・QA 向けの E2E テスト自動化 / 外部ブラウザ制御基盤であり、エンドユーザーが本番機能として触るツールではありません。同じ「AI × ブラウザ」領域に見えても、Playwright / Selenium と PageAgent では解決する課題のレイヤが異なるという理解が重要です。

PageAgent の採用判断のポイント

ここまでの内容を踏まえ、「自プロジェクトに PageAgent を採用すべきか」を判断するための整理を行います。

PageAgent が向いているケース

• SaaS / 業務 Web アプリへの AI コパイロット組み込み: 既存 UI を活かしつつ、自然言語入力から操作を代行させたいケース。バックエンド改修が不要という点が意思決定を大きく後押しします。
• B2B 業務システム・管理画面の自然言語 UI 化: セマンティック HTML で構築されたフォーム中心のアプリケーションは、DOM ベース理解と相性が良い領域です。
• アクセシビリティ向上: 視覚障害者や高齢者向けの「自然言語による操作入口」を、既存アプリに後付けで追加したいケース。
• 既存 LLM 契約の流用: 社内で既に OpenAI / Anthropic / Alibaba などの契約があり、その API キーをそのまま流用したいケース。

PageAgent が向いていないケース

• Canvas / WebGL / SVG ベース UI: 描画系や視覚専用インタラクションが中心のアプリケーション。PageAgent はマルチモーダル LLM やスクリーンショットを使用しないため、視覚要素は基本的に扱えません。
• クロスオリジン iframe / ネスト iframe の頻繁な操作: Limitations ページ にあるとおり、同一オリジン単層 iframe までしか対応していません。
• ホバー・ドラッグ・キーボードショートカットが必須の UI: これらは非対応操作として明示されています。ドラッグ&ドロップ主体のダッシュボードなどは要注意です。
• Monaco / CodeMirror などのリッチエディタ制御: JS インスタンス経由での制御が必要なエディタは非対応と明記されています。
• 外部プロセスからの自動化: 外部からタスクを流し込みたい場合は、browser-use や Playwright の方が適しています。

メンテナンス状況とライセンス

意思決定に不可欠な「継続性」の指標を確認します。

• ライセンス: MIT（商用利用可）
• Star / Fork: 21,834 / 1,869（GitHub リポジトリ より、2026-07-02 時点）
• 最終 push: 2026-07-02
• リポジトリ状態: archived=false / fork=false / disabled=false（アーカイブされておらず、フォーク版でもなく、無効化もされていない現行プロジェクト）
• 直近リリース: CHANGELOG によれば、直近 3 か月で 4 リリース。v1.10.0（2026-06-15）では Agent の run lifecycle の全面リワーク、execute_javascript の AbortSignal 対応、MultiPageAgent の安全性向上などが行われており、機能追加と安定化が並行して進んでいます。

Star 数・リリース頻度・ライセンスの 3 点から、少なくとも「メンテナンスが止まったプロジェクトを踏む」リスクは現時点で低いと評価できます。ただし v1.x 系である以上、破壊的変更を含むアップデートが継続する可能性はあり、本番投入時にはバージョン固定と CHANGELOG 追跡の運用は必要です。

まとめ

PageAgent は、「Web ページ内で動く JavaScript 製 GUI エージェント」という設計に振り切ることで、既存 Web アプリへの AI 組み込みを バックエンド不要・フレームワーク不問 で実現する OSS です。DOM テキストベースの理解、OpenAI 互換 + tool call モデルの Bring Your Own LLM 方式、<script> 一行から始められる導入経路、といった選択が全て「Web サイト開発者が自サイトに載せる」というユースケースに最適化されています。

一方で、視覚専用要素（Canvas / WebGL）や、外部プロセスからのマルチページ自動化には向かず、そうしたケースでは browser-use / CopilotKit / Playwright など別の OSS が候補になります。「自社の Web UI にコパイロットを載せたい」という初期条件が明確なプロジェクトほど、PageAgent の設計思想が刺さります。

次に読むべき公式ドキュメントは以下の 3 点です。導入判断の解像度を上げたい場合は、まず Overview で設計思想を確認し、Quick Start で導入コストを見積もり、Limitations で自プロジェクトの UI 要件との適合性を検証する流れが効率的です。

• PageAgent 公式 Overview
• PageAgent 公式 Quick Start
• PageAgent 公式 Limitations