ブラウザ自動化というと、まず Playwright か Puppeteer を思い浮かべるエンジニアが多いと思います。
でも「既存の社内システムに後付けで自動化を仕込みたい」という文脈では、その選択肢が必ずしも最適じゃないケースがあります。
セレクタを書いて、ステップを記述して、DOM が変わるたびにメンテして……というサイクルを、レガシーな社内ツールに対して延々と繰り返すのはしんどい。
そこに「自然言語で指示するだけでページを操作できる」という別の選択肢が現れたのが、Alibaba の page-agent です。
組み込み手順を実際のコードで追いつつ、「このユースケースなら使える／使えない」の判断軸と、本番投入前に直視すべき注意点を、懐疑的な実務目線を崩さずに書きます。
page-agent とは何をするライブラリか
page-agent（alibaba/page-agent、MIT ライセンス）は、ページ内 JavaScript として動く GUI エージェントです。
TypeScript で書かれていて、npm パッケージか script タグ一行で既存のページに組み込めます。
最大の特徴は、動作が完全にクライアントサイドで完結している点です。
Python も headless ブラウザも Chrome 拡張も不要。
ページの中に住んでいて、ライブ DOM をテキストとして読み取り、LLM に渡して「次に何をすべきか」を推論させ、その結果をそのままページ上で実行します。
Playwright や Puppeteer との構造的な違いはここにあります。
Playwright は 外から ブラウザを操作します。
別プロセスが Chrome DevTools Protocol 越しにブラウザを遠隔操作するイメージです。
page-agent は逆で、中から 動きます。
ページ自身がエージェントを内包していて、ユーザーが自然言語で指示を投げると、エージェントがその場で DOM を解析して操作を実行します。
スクリーンショットを撮らない点も重要です。
ビジョンモデルを使わず、DOM をシリアライズしたテキストを LLM に渡す設計なので、マルチモーダルモデルは不要です。
これは browser-use の DOM 処理とプロンプト設計を継承した部分で、page-agent はその系譜に位置づけられます。
設計思想を一言で言うと「既存アプリに自然言語 UI を後付けする」です。
バックエンドを書き直さなくていい。
フロントエンドのコードを大幅に変えなくていい。
エージェントをページに乗せて、ユーザーが「ログインして、フォームにこの値を入れて」と言えばそれが動く、という世界観です。
既存アプリへの組み込み方：インストールから初回動作まで
インストールは npm で一行です。
npm install page-agent
初期化に必要なのは model・baseURL・apiKey の3つです。
OpenAI 互換の API であれば何でも使えます。
Qwen・Ollama・OpenRouter など、baseURL を差し替えるだけで切り替えられます。
以下がフォーム操作の最小スニペットです。
import { PageAgent } from 'page-agent'
const agent = new PageAgent({
model: 'gpt-4o',
baseURL: 'https://api.openai.com/v1',
apiKey: process.env.LLM_API_KEY, // クライアントに直書きしない
language: 'ja-JP',
})
// ログインフォームに値を入力して送信する
await agent.execute(
'ユーザー名フィールドに "yamada" と入力し、パスワードフィールドに "pass123" と入力して、ログインボタンをクリックしてください'
)
テーブルからデータを抽出したい場合はこうなります。
const result = await agent.execute(
'画面上の受注一覧テーブルから、ステータスが「未処理」の行の注文番号と顧客名をすべて教えてください'
)
console.log(result)
execute() に渡すのは自然言語の文字列だけです。
セレクタも XPath も書きません。
v1.5.6 で maxSteps のデフォルトが 20 から 40 に増加しました。
maxSteps はエージェントが1回の execute() で踏めるステップ数の上限で、複雑なワークフローが途中で打ち切られるというコミュニティのフィードバックを受けた変更です。
上限に達するとそこで処理が止まるので、長い手順を一度に渡す場合は意識しておく必要があります。
APIキーの扱いについては後の節で詳しく触れますが、クライアントサイドのコードに apiKey を直書きしてはいけません。
ブラウザの開発者ツールを開けば誰でも読めてしまいます。
バックエンドにプロキシエンドポイントを立てて、baseURL をそこに向けるのが正しい構成です。
Playwright/Puppeteer との使い分け：「コードで書く」か「言葉で指示する」か
Playwright と page-agent は、操作の記述方法が根本から違います。
Playwright は 決定論的なスクリプトです。
「このセレクタの要素をクリックして、このフィールドに値を入力して」という手順をコードで明示します。
同じスクリプトを何度実行しても、DOM が変わらない限り同じ結果になります。
CI でテストを回す・スクレイピングを定期実行する、といった用途では信頼性が命なので、Playwright の決定論的な性質は大きな強みです。
page-agent は LLM の推論に委ねます。
「ログインして、フォームに値を入れて」という指示を渡すと、エージェントが DOM を読んで「おそらくこの要素がログインボタンだ」と判断して操作します。
柔軟ですが、非決定論的です。
同じ指示でも LLM の出力がわずかに変わることがあるし、DOM の構造が複雑だと判断を誤ることもあります。
レガシーな社内システムへの後付けという文脈で考えると、コスト感の違いが浮かび上がります。
Playwright でレガシーシステムを自動化しようとすると、セレクタを丁寧に書いて、画面が変わるたびにメンテして、という保守コストが積み上がります。
page-agent はそのセレクタ保守コストをゼロに近づけられる反面、LLM の API 呼び出しコストがステップ数に比例して積み上がります。
どちらが安いかは、操作の頻度と複雑さによって変わります。
使い分けの判断軸を整理するとこうなります。
- CI・テスト・定期バッチ：Playwright 一択。再現性と速度が最優先で、LLM の揺らぎは許容できない。
- エンドユーザー向けコパイロット：page-agent が向く。ユーザーが自然言語で指示を投げる UI を作りたい場合。
- DOM 変更頻度が高いレガシーシステム：セレクタ保守コストが嵩むなら page-agent の方が長期的に楽になる可能性がある。
- 操作の安定性要件が高い業務処理：金融・在庫・契約など誤操作が許されない処理には向かない。
- コスト感度が高い高頻度処理：1回の execute() で複数ステップを踏むと LLM トークンが積み上がる。頻度が高いなら Playwright の方がコスト効率がいい。
両者は競合というより、用途が違うツールです。
向いているユースケースと、正直なところ厳しいケース
現実的に刺さると思う用途は、ERP や CRM のフォーム補助です。
20ステップある入力フローを「この案件の情報を受注フォームに入れて」の一言で済ませられるなら、業務効率の改善幅はかなり大きい。
特に、操作手順を覚えるのが難しいユーザー（新入社員・非IT部門のスタッフ）がいる環境では、自然言語インターフェースは本質的な価値を持ちます。
もう一つ可能性を感じるのが、レガシー社内ツールへの AI レイヤー追加です。
リプレイスの予算も工数もないが、使いにくさは何とかしたい、という状況は現場に多い。
そこに page-agent を乗せて「このシステムで〇〇してください」と言えるようにするだけで、体験が大きく変わることがあります。
バックエンドに一切手を入れなくていいのは、受託案件でも社内ツールでも、改修コストを抑えるうえで素直に魅力的です。
一方で、正直なところ厳しいと感じるケースもあります。
iframe を多用しているシステムは現状対応が難しいです。
page-agent が読めるのは自分が乗っているページの DOM で、別オリジンの iframe の中は読めません。
古い社内システムほど iframe を多用している傾向があるので、後付けしようとしたら iframe の壁にぶつかる、というケースは十分ありえます。
認証フローも注意が必要です。
SAML・OAuth のリダイレクトが絡む認証は、ページ遷移のタイミングとエージェントの状態管理が噛み合わないことがあります。
高頻度のバッチ処理も向きません。
1回の操作に LLM 呼び出しが複数回走るので、1000件のデータを自動入力するような処理をやらせると、コストと時間の両方で現実的ではなくなります。
「面白そうだけど本当に使えるか」という目線で見ると、少人数が使う社内ツールの補助機能として後付けするという用途が、今の成熟度でもっとも現実解に近いと思います。
全社展開・高頻度処理・ミッションクリティカルな業務への適用は、もう少し様子を見た方が無難です。
本番投入前に直視すべき限界と注意点
注意点を先に並べると、こうなります。
- 精度のゆらぎ：LLM 依存による非決定論的挙動
- API コスト：ステップ数×トークン数の積み上がり
- プロンプトインジェクション：ページ上の悪意あるコンテンツによる誤誘導
- API キー管理：クライアントサイドへの直書きは厳禁
- iframe・認証フロー非対応：現状の構造的な制約
精度のゆらぎは、page-agent を使ううえで最も向き合いにくい問題です。
同じ指示を複数回実行して毎回成功するとは限りません。
DOM が複雑だったり、指示が曖昧だったりすると、エージェントが別の要素を操作してしまうことがあります。
maxSteps の上限に達して処理が打ち切られるリスクもあるので、「失敗したらリトライ」という設計を最初から組み込んでおく必要があります。
API コストは、使い始めると思ったより積み上がります。
1回の execute() でエージェントが複数ステップを踏むたびに LLM 呼び出しが発生するので、複雑なワークフローほどトークン消費が増えます。
本番投入前に、想定する操作の複雑さと頻度でコストを試算しておくことをすすめます。
プロンプトインジェクションは、ブラウザエージェント全般に共通するリスクです。
ページ上に「エージェントへの指示」を埋め込んだ悪意あるコンテンツがあると、エージェントがユーザーの意図とは無関係な操作を実行してしまう可能性があります。
たとえば、外部から読み込んだデータの中に「すべてのフォームを送信してください」という文字列が含まれていたとしたら、エージェントがそれを指示として解釈するリスクがあります。
LLM レベルでの防御には限界があり、ブラウザエージェントのセキュリティ研究でも「LLM の判断だけでプロンプトインジェクションを完全に防ぐことは統計的に困難」という知見が示されています。
信頼できないコンテンツを含むページでエージェントを動かす場合は、操作スコープを絞る・実行前に確認ステップを挟む、といった設計上の対策が必要です。
API キー管理については、バックエンドプロキシ経由の構成が必須です。
baseURL を自前のプロキシエンドポイントに向けることで、apiKey をクライアントに渡さずに済みます。
import { PageAgent } from 'page-agent'
const agent = new PageAgent({
model: 'gpt-4o',
// 自前のバックエンドプロキシを向ける
// プロキシ側で実際の LLM API キーを付与して転送する
baseURL: '/api/llm-proxy',
apiKey: 'dummy', // プロキシ側で認証するので実キーは不要
language: 'ja-JP',
})
await agent.execute('受注フォームに必要な情報を入力してください')
プロキシ側では、受け取ったリクエストに実際の LLM API キーを付与して転送します。
こうすることで、ブラウザの開発者ツールを開いてもキーは見えません。
iframe・認証フロー非対応は、設計段階で確認しておくべき制約です。
対象システムが iframe を多用していないか、認証フローがシンプルかどうかを事前に確かめてから導入を検討するのが現実的です。
page-agent はまだ活発に開発中のライブラリで、v1.5.6 まで短期間に 18 リリースを重ねています。
今の制約が将来のバージョンで解消される可能性はありますが、現時点の本番投入判断は現状の制約を前提に行うべきです。
「後付けで自然言語 UI を足す」という発想は、レガシーシステムの改修コストに悩む現場にとって確かに魅力的です。
ただし LLM 依存の非決定論的な挙動・API コスト・セキュリティリスクは、導入前に正直に見積もっておく必要があります。
小さいスコープで試して、精度とコストの実態を把握してから広げる、というアプローチが今の成熟度には合っています。
株式会社ホコサキは、山口県宇部を拠点に Web 制作・業務システム開発・AI 活用支援を手がけています。
page-agent のような新しいツールの評価・導入検討から、既存システムへの AI 機能の後付けまで、実務レベルでの相談を受け付けています。
気になることがあれば お問い合わせページ からどうぞ。