13分で読めます
  • AI
  • ツール
  • How-to
  • エージェント
  • Web

Page Agent——Webページの中に住むGUIエージェントを、一行から始める

Alibaba発のOSS「page-agent」。Pythonもヘッドレスブラウザも不要で、ページ内JSだけで自然言語操作を足す方法を、デモCDNの落とし穴から本番BYOKまで整理します。

カテゴリー: AI · ツール · How-to · エージェント · Web | 公開: 2026年7月10日 | 読了目安: 約13分

📑 目次

ふむふむ、これはちょっと可愛い発想です。

「AIにブラウザを操作させたい」と言うと、だいたい話はこうなります。Playwright や Selenium を立てて、ヘッドレス Chrome を回して、スクリーンショットを撮って、多モーダルモデルに「このボタンどこ？」と聞く——インフラの厚みが、まず最初に来る。

そこに、少し違う入口が来ました。Page Agent（npm パッケージ名は page-agent）。Alibaba のオープンソースで、GitHub スターは執筆時点で約2.5万。2026年7月の週次トレンドでも大きく伸びています。

面白いのは、道具の置き場所です。ページの外からブラウザを操るのではなく、ページの中にエージェントを住まわせる。Python も、拡張機能も、ヘッドレスブラウザも必須ではない。script タグ一行、あるいは npm install page-agent で、いま開いている DOM に自然言語の操作口を足せる。

でもね、チカちゃん的には「一行で夢が叶う」だけで終わらせたくない。デモ用 CDN は本番に載せちゃダメですし、ページ内エージェントは便利なぶん、誰のデータを、どの LLM に、どの粒度で渡すかがすぐ問題になる。今日はそこまで含めて、How-to としてちゃんと歩いてみます。

本記事は公開情報をもとにした個人的な技術メモです。第三者ツール・AIサービス・モデルの仕様、料金、利用条件、安全性は変わる可能性があります。導入前に公式ドキュメント、ライセンス、利用規約、商用利用条件、データ送信先を確認してください。業務環境や秘密情報を含む環境では、隔離環境で検証してから利用することをおすすめします。

Page Agent って何者？——30秒でつかむ

Page Agent は、ひと言でいうと 「Web ページの中で動く GUI エージェント用の JavaScript ライブラリ」 です。

  • ユーザー（またはアプリ側コード）が自然言語で指示する
  • エージェントがページの DOM をテキストとして読み取る
  • クリック・入力・選択などをページ内で実行する
  • 任意の OpenAI 互換 LLM（クラウドでもローカルでも）に接続できる

公式が強調しているのは、次の三点です。

  1. インフラを増やさない —— Python / ヘッドレスブラウザ / サーバー必須ではない
  2. テキスト DOM 操作 —— スクリーンショット前提ではなく、多モーダル必須でもない
  3. Bring Your Own LLM（BYOK） —— ライブラリ本体はクライアント側。キーとエンドポイントは自分で用意

browser-use 系の「外側からブラウザを自動化する」思想を、DOM 処理まわりで参照しつつも、設計の重心は クライアント側のウェブ強化 に置かれています。スクレイピング用の外部ロボットというより、「SaaS に AI コパイロットを埋め込む」「管理画面の20クリックを一文にする」「音声や自然言語で操作できるようにする」ための部品、という感触が近いです。

browser-use / Playwright と何が違うの？

ここ、いちばん誤解しやすいところなので、いったん並べます。

観点Page AgentPlaywright / browser-use 系
動く場所対象ページの中（in-page JS）ページの外（別プロセスや拡張）
典型用途自社 UI のコパイロット、フォーム補助、アクセシビリティE2E テスト、外部サイト自動化、横断スクレイピング
セッションユーザーがログイン済みの同じタブをそのまま使える別ブラウザ文脈を用意することが多い
セットアップscript / npm でフロントに足すPython/Node + ブラウザランタイム
マルチページ本体は単一ページ。任意で Chrome 拡張もともと複数タブ・複数サイトを扱いやすい

「どっちが上か」ではなく、置き場所が違うんです。外側の自動化は「自分の端末から世界中のページを操る」のに強い。内側のエージェントは「そのアプリを使う人の文脈のまま、同じ画面に住む」のに強い。

チカちゃん的には、ここがちょっと哲学的で好きです。エージェントは「操作する側」に立つか、「一緒に画面を見る側」に立つか——で、信頼の形が変わります。

まず触る——評価用デモ（CDN 1行）

最短ルートは、公式 README のデモ用 script です（執筆時点の README は @1.12.0 を指しています）。

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

中国向けミラーもあります。

https://registry.npmmirror.com/page-agent/1.12.0/files/dist/iife/page-agent.demo.js

ページを開くと、UI パネルが載って、自然言語で操作を試せます。公式サイト（alibaba.github.io/page-agent）でもライブデモがあります。

ここ、重要です。 このデモ CDN は 技術評価専用。無料のテスト用 LLM API を使っており、本番プロダクトへの組み込みは想定されていません。利用規約・プライバシー文書でも、

  • 本番利用禁止
  • 個人情報・機微データの投入禁止
  • 可用性は保証されない（レート制限・停止があり得る）
  • テスト API の処理は中国本土インフラ経由

と明記されています。EU などデータローカライゼーションが厳しい地域では、特に使わない方が安全です。

「とりあえず動いた！」の熱量で本番に載せない。ここが第一の罠です。

自動起動させたくないときは、URL に ?autoInit=false を付けて読み込み、あとから new window.PageAgent(...) で自分の設定を渡せます。

本番寄りの入れ方——npm + 自分の LLM

実利用は npm が推奨ルートです。執筆時点で npm の latest は 1.11.0（2026-07-03 公開）。README の CDN 版番号とズレることがあるので、本番では npm install page-agent で解決されたバージョンを固定するのが安心です。

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',
  // 公式型定義上は 'en-US' | 'zh-CN'（パネル／システム側の言語）
  language: 'en-US',
})

// ユーザー指示そのものは日本語でも試せる（モデルの理解力に依存）
await agent.execute('ログインボタンをクリックして')

公式サンプルは DashScope 経由の Qwen をよく使っていますが、設計は OpenAI 互換エンドポイント 前提です。OpenAI / Claude 系ゲートウェイ / DeepSeek / Gemini 互換 / 自前プロキシなど、model と baseURL と apiKey を差し替えればつなげます。language オプションは執筆時点の公開情報では en-US と zh-CN が明示されており、日本語 UI 向けの専用値が公式に固定されているとは限りません。日本語で指示を出すこと自体は可能でも、パネル文言や内部プロンプト言語は実機確認が必要です。

ローカル LLM（Ollama）のイメージ

開発ガイドでは、Ollama 例として次のような .env が示されています（開発サーバー向けの例）。

LLM_BASE_URL="http://localhost:11434/v1"
LLM_API_KEY="NA"
LLM_MODEL_NAME="qwen3:14b"

「ページ内エージェント」と「ローカル推論」を組み合わせると、クラウドに DOM 要約を送らない運用も狙えます。ただし、ローカルモデルの指示追従力・ツール呼び出し精度はモデル依存です。機密ページほどローカル、公開デモほどクラウド——くらいの使い分けが現実的です。

実践パターン①：管理画面の「一文操作」

Page Agent が刺さりやすいのは、クリックが多い社内 UI です。

await agent.execute(
  '先月の経費から出張費を選び、金額 34250 円、摘要に「大阪出張」と入れて下書き保存して'
)

人間ならタブ移動・プルダウン・日付ピッカーを何往復もする作業が、自然言語一本に寄ります。ERP / CRM / 管理コンソール系は、ここが本丸です。

注意点：

  • ラベルが曖昧な UI（「OK」「実行」が画面に3つ）だと迷いやすい
  • SPA で DOM が遅延描画される場合、タイミングで失敗し得る
  • 破壊的操作（削除・公開・送金）は、確認ダイアログや human-in-the-loop を設計に入れる

公式サイトも「Agent が勝手に走って終わり」ではなく、協働パネルで確認しながら進める思想を前面に出しています。便利さと、止められる余白はセットです。

実践パターン②：SaaS にコパイロットを埋め込む

自社プロダクトに「この画面を自然言語で手伝って」を足したいとき、外側に自動化基盤を立てるより、フロントにライブラリを足す方が距離が短いことがあります。

const copilot = new PageAgent({
  model: process.env.PUBLIC_LLM_MODEL,
  baseURL: process.env.PUBLIC_LLM_BASE_URL,
  // apiKey をフロントに直書きしない。プロキシ経由を推奨
  apiKey: await fetchEphemeralToken(),
  language: 'en-US',
})

// パネルを見せて対話させる / または execute で特定フローを起動
await copilot.execute('新規顧客フォームを、クリップボードの内容で埋めて')

ここでチカちゃんが強く言いたいのは、API キーの置き場です。ブラウザに住むライブラリなので、うっかり apiKey をクライアントバンドルに焼いて公開リポジトリへ……が起きやすい。本番では、

  • 短命トークンを自前バックエンドから発行する
  • もしくは社内専用のプロキシに寄せてキーを隠す
  • デモ CDN のテスト API をそのまま顧客向けに使わない

をセットで考えてください。

実践パターン③：Chrome 拡張と MCP（ベータ）

単一ページだけでは足りないとき、公式は 任意の Chrome 拡張 と MCP Server（Beta） を用意しています。

  • 拡張：複数タブ・複数ページにまたがるタスク
  • MCP：Claude Desktop など外部エージェントから、ユーザーのブラウザを操る橋

npm ワークスペース上では @page-agent/mcp として分かれており、「ページに住むエージェント」を「外のエージェント」から呼ぶ層です。ここまで来ると、browser-use 的な世界観とまた接続が戻ってきます。ただしベータ表記がある機能は、仕様変更を前提に触ってください。

インストール後に確認したいチェックリスト

項目見るポイント
用途自社 UI の補助か、外部サイト横断か（後者は外側ツールの方が向くことが多い）
ライセンスMIT（商用利用可。配布時の表記は原文を確認）
データ経路どの LLM エンドポイントに、どの DOM 要約が飛ぶか
デモ API評価以外に使っていないか
キー管理フロント直書きしていないか
危険操作削除・決済・一括更新に確認が入るか
アクセシビリティ自然言語操作が「別ルート」になり、本来の UI が放置されていないか
多言語指示は日本語でも可。language は en-US / zh-CN 中心なので実機確認

うまくいかないときによくある話

  1. 「クリックできない」
    見えているのに操作対象が取れないときは、シャドウ DOM・canvas・iframe 越え・仮想リストが疑わしいです。Page Agent はテキスト DOM 路線なので、画面に見えていても DOM に意味が薄い UI は苦手になりがちです。

  2. 「途中で変なボタンを押す」
    ラベル衝突です。指示を具体化する（「右上の青い『公開する』」「モーダル内の『破棄』」）か、アプリ側で aria-label をちゃんと付けると安定しやすいです。

  3. 「デモでは動くのに自前キーで動かない」
    モデルのツール呼び出し・JSON 追従の差です。軽いモデルは DOM 操作手順でブレやすい。まずは指示追従が強いモデルで土台を作り、あとから軽量化、が無難です。

  4. 「すごい便利になったのに、誰も手順を覚えなくなった」
    これは技術というより運用の話。コパイロットがあると、画面の情報設計の粗さが見えにくくなることがあります。エージェントは絆創膏にも、麻酔にもなります。

チカちゃん的な見立て——「操作」が言葉に戻る

ちょっと待って。ここで一度、技術の外側に目を向けます。

長いあいだ、GUI は「言葉を捨てた操作系」でした。メニューを覚え、アイコンを覚え、ショートカットを覚える。パワーユーザーほど、体が UI を覚える。

自然言語エージェントは、その流れをひっくり返し気味です。操作が、また言葉になる。 便利です。同時に、「言葉にできない人」「指示の上手い人」のあいだに、新しい格差も生まれます。アクセシビリティの夢と、プロンプト格差は、同じ技術の裏表です。

もうひとつ。ページの中に住むエージェントは、ユーザーのログイン状態・表示中の顧客名・下書きの金額を、そのまま文脈にできます。だから強い。だから危険でもある。近いほど便利で、近いほど漏れる。

チカちゃん的には、Page Agent の一番おいしい読み方は「自動化ツール」より 「UI に第二の入口を足す設計素材」 です。ボタンを増やすのではなく、言葉の入口を増やす。そのとき、元の UI を雑にしないこと。エージェントがあるからラベルが雑でいい、にはしたくない。

まとめ——まず一行、でも本番は自分の鍵で

Page Agent は、

  • ページ内 JS で GUI エージェントを足せる
  • デモは CDN 一行、本番は npm + BYOK
  • 外側自動化（Playwright / browser-use）とは置き場所が違う
  • 便利さの核心は「同じセッション・同じ DOM」にいること
  • だからデータ経路と危険操作の設計が本体

という道具です。

「すごい！」だけで終わらせず、デモと本番を分ける、キーを焼かない、壊せる操作に確認を残す——この3つだけでも、かなり事故が減ります。

で、最後にひとつだけ問いを置いておきます。

あなたのプロダクトに自然言語の入口を足すとき、それはユーザーの手を軽くするためですか。それとも、説明不足の UI をエージェントに肩代わりさせるためですか。

どっちも気持ちはわかる。でも、長く健全に育つのはたぶん前者で、後者はしばらくすると「誰も画面を読めないプロダクト」になります。

技術の話から始まって、最後は「界面（インターフェース）を誰と一緒に育てるか」に戻ってくる。チカちゃん的には、そこが一番おいしいところです。思索は冒険です。今日の話も、その入口のひとつでした。

参考URL

Page Agent（GitHub） → https://github.com/alibaba/page-agent

Page Agent 公式サイト / デモ → https://alibaba.github.io/page-agent/

npm: page-agent → https://www.npmjs.com/package/page-agent

README（英語） → https://github.com/alibaba/page-agent/blob/main/README.md

README（中文） → https://github.com/alibaba/page-agent/blob/main/docs/README-zh.md

Terms of Use & Privacy → https://github.com/alibaba/page-agent/blob/main/docs/terms-and-privacy.md

Developer Guide → https://github.com/alibaba/page-agent/blob/main/docs/developer-guide.md

Maintainer note (#349) → https://github.com/alibaba/page-agent/issues/349

browser-use（派生元の参照元） → https://github.com/browser-use/browser-use

GitHub Trending（weekly） → https://github.com/trending?since=weekly

  • インターネット上のツールは第三者が提供するものです。開発工程や配布経路を悪用した攻撃（サプライチェーン攻撃）が仕掛けられる可能性もゼロではありません。ご利用の際は公式リポジトリの情報をご確認いただき、自己責任でお使いください。
  • AIに関する技術や情報は急速に変化します。本記事の内容が公開後に古くなる可能性があります。各サービスの公式ドキュメントや最新情報をご確認ください。

近くの問い