1. はじめに
C-RISEの村井です。
当社はクラウドBOTというブラウザ自動化サービスを提供しています。
クラウドBOTは、ブラウザ操作の自動化をよりシンプルに、そして多くの人にとって身近なものにするため開発してきました。
プログラミング不要で誰でも業務自動化ができることを目指し、これまで数多くのアップデートを重ねてきました。
そして、今月プレビュー版として公開したCloud BOT Operatorは、RPAによる定型操作ロボットという枠組みから一歩踏み出し、AIによる自動操作ロボットとしての可能性に挑戦しました。
エージェントが指示を理解し、必要な操作をクラウドBOTを通じて自動実行する。この構造により、これまで人の手を必要としていた判断・操作の一部をAIに委ねられるようになったのです。
そんな中、今週Microsoftから新たにPlaywright MCPが公開されました。OpenAIのCUAモデルとは異なる新たなアプローチを採用しておりとても興味深かったので、色々調べてみるとともに記事として書き起こしてみました。
従来のBrowser useのようなDOM認識、OpenAI Operatorのような画面視認による操作とは異なり、「アクセシビリティツリー」を基軸とした自動操作を採用しているようです。
つまり、ブラウザ利用者のアクセシビリティを向上させる為の情報をAIが画面構成を把握する手段として活用するという画期的な手法でした。
この記事では、このPlaywright MCPの技術的な解説に加え、クラウドBOTへの実装可能性や親和性を検討しつつ、実際の構成やコードの観点からも踏み込んでお伝えしていきます。
2. Playwright MCPとは何か？
Playwright MCP（Model Context Protocol）は、Microsoftが2025年3月に公開したブラウザ自動化ツールです。
従来のAI自動化ツールでは主に以下の手法が採用されてきました。
- DOM認識による操作推論 (Browser use)
- 画面視認による操作推論 (OpenAI Operator)
これらはいずれも強力な手法ですが、DOM構造の肥大化による遅延や画面視認繰り返しによるコスト(トークン量)増大といった課題があります。
これに対してPlaywright MCPが採用するのは、アクセシビリティツリー です。
スクリーンリーダーなどに使われる構造情報を活用し、UIの「意味」に近い視点で要素を認識・操作できます。
この手法により、以下が可能になります：
- UI変更への高い耐性
- テキストや構造ベースの安定した要素特定
- 軽量なプロンプトによるLLM（大規模言語モデル）との連携しやすさ
3. クラウドBOTとの親和性
クラウドBOTは「誰でもノーコードで自動化できる」ことを目的に設計されており、対象サイトの構造や変更に柔軟に対応できる仕組み、HTMLやセレクター、スクリプトといった専門知識がなくてもBOTを作成できる容易性が求められてきました。
✅ Playwright MCPのメリット
- アクセシビリティツリーによる要素特定は、UIの揺れに強く、業務の自動化と非常に相性が良い
- DOM認識や画像認識に依存しないためトークン消費量を削減でき、運用コストを軽減できる
- 「フォームに入力して」などの曖昧な命令でも、適切な要素を自動認識し操作できる。
もし、これらの特徴をクラウドBOTに取り込むことができれば下記のような使い分けが可能となり、自動化の幅が広がります。
- 定型操作は、操作自動記録によるRPA機能
- 曖昧な指示はアクセシビリティ認識による軽快なAI自動操作
- 画面視認による判断が必要な操作はCUAモデルによる高度なAI自動操作
4. Playwright MCPのアーキテクチャ解説
Playwright MCPは以下のディレクトリ構成でモジュールとしては３階層の構造となっています。
📁 ディレクトリ構成
src/
├── server.ts
├── context.ts
├── index.ts
├── tools/
└── resources/
1層目 MCPサーバー(server.ts)
リクエスト受付・ルーティング・レスポンスの生成を担当。
MCPサーバとしてツール/リソース一覧の提供やツール/リソースへの要求を受け付けます。
また、要求に対する結果を応答します。
2層目 ツール／リソース(tools/resources)
操作モジュール（ツール）とデータアクセスモジュール（リソース）を統括。
MCPサーバから呼び出されるツール群とリソース群が実装されています。
- ツール
アクションを実行（クリック、入力、ナビゲーション等） - リソース
状態や情報を取得（コンソールメッセージ等）
3層目 ブラウザ操作(context.ts)
- Playwrightによるブラウザ操作を抽象化。
ツールやリソースの実処理
この構成を見て頂いて分かる通り、Playwright MCPはブラウザ自動操作のツール/リソースを提供するMCPサーバであり、LLM(GPTやClaude)等を呼び出したり推論する処理等は含まれていません。
このMCPサーバは様々なAIエージェントに対してブラウザ操作を行う為のツールやリソースを提供します。
つまり、色々なAIエージェントからMCPのプロトコルで呼び出せるわけですが、逆にいうとLLMモデルと繋ぎこまないと自動化アプリケーションとしては利用できません。
5. 技術的な特徴と利点
アクセシビリティツリーの活用
// src/tools/utils.tsのcaptureAriaSnapshot関数内
const snapshot = await page.locator('html').ariaSnapshot({ ref: true });
このスナップショットによりアクセシビリティツリーを取得しています。
取得時に{ref: true}を指定することで要素(htmlのタグ)の参照（ref）も同時に取得します。
アクセシビリティツリーには下記情報が含まれます。
- ページのURL
- ページのタイトル
- 要素の階層構造
- 要素のアクセシビリティ属性
- 要素の参照（ref）
アクセシビリティツリーは、ブラウザ操作の正確性と信頼性を向上させる重要な役割を果たしています。特に、LLMが要素を正確に特定し、操作できるようにするための基盤となっています。
尚、要素の参照により操作対象を特定することで、クリックやドラッグ&ドロップ、テキスト入力等の指示が可能になります。
LLMモデルに操作ツール(スナップショットやクリック、テキスト入力)と依頼プロンプトを渡すことで次はどのツールを呼び出し、どのような処理をするかという応答指示を受け取る。その指示を実行後、再度LLMモデルに最新の状態を渡すとともに次の指示を要求するということを繰り返し目的の達成を目指します。
この目的に向かってぐるぐる回すのはCUAモデルと似ていますが、プロンプトに都度スクリーンショット画像を渡すかアクセシビリティツリーを渡すかの違いで処理効率が大きく変わってきます。
🔧 ツール群の定義
// index.js
const snapshotTools: Tool[] = [
common.navigate(true),
common.goBack(true),
common.goForward(true),
snapshot.snapshot,
snapshot.click,
snapshot.hover,
snapshot.type,
snapshot.selectOption,
...commonTools,
];
index.jsではMCPサーバが取り扱うツール群を定義しています。
実際のツールは下記のように実装されています。
// src/tools/snapshot.ts
export const click: Tool = {
schema: {
name: 'browser_click',
description: 'Perform click on a web page',
inputSchema: zodToJsonSchema(elementSchema),
},
handle: async (context, params) => {
const validatedParams = elementSchema.parse(params);
return runAndWait(context, `"${validatedParams.element}" clicked`, page => refLocator(page, validatedParams.ref).click(), true);
},
};
このアクセシビリティツリー(画面情報)とツール(手段)、依頼プロンプトをAIに渡して「目的の為の操作手順を考えてもらう」ことによって、RPAのように事前に要素と手順を記録しワークフロー化しなくても自動操作ができるようになります。
このツール群をうまく調整し、充実させることでAIが効率の良い操作手順を考えてくれるようになるでしょう。
6. クラウドBOTでの活用可能性を検討する
- 現時点ではまだ安定性や操作精度も未知数の研究段階
- Playwright MCPをそのまま組み込むのは難しそう。方式として参考にする。
- Playwright MCPには画面視認(スクリーンショット認識)するビジョンモードもあるが、ブラウザ操作用にチューニングされたCUAモデルの方が高精度と思われる
- クラウドBOT内にアクセシビリティを活用したエージェントを組み込む場合、MCPを採用するべきなのか？
- 画面視認方式のCUAモデルと、アクセシビリティ認識方式のエージェントと使い分けることで効率よく、幅広い対応が可能になりそう
- UI変更の激しいWebサービスにおいても、高い自動化成功率を実現できそう
- 自然言語プロンプトによる指示ができるとBOT作成効率も上がりそう
7. まとめと今後の展望
Playwright MCPは、今後のブラウザ自動化においてとても面白い手法であると感じました。
今後、クラウドBOTに取り込むのか別の手段に挑戦するのか未定ですが、今後AIエージェントの普及により「ノーコード」という概念も変化してくるように思えます。
これまでは、プラグラミングやスクリプトといったコードが不要、つまりGUIで作れる＝ノーコードという認識が一般的でした。
GUI環境で変数を定義し、フローチャートを組み立てるような実質プログラミングスキルが求められるようなソフトウェアでもコードを書かなければノーコードと言われてきましたが、今後は依頼内容を自然言語で入力をするとAIが目的への手段を組み立ててくれるロボットが作れる。
これこそ、プログラミング知識すら不要とするノーコードなのでは無いでしょうか。
長文にもかかわらず最後まで読んでいただきありがとうございました。
ご意見・ご質問・いいねなどもお待ちしています！