スマホ向けの注文フォームを更新したあと、テスト用の会員と商品でカートから住所入力、注文内容の確認画面まで進む。EC運営の担当者にとって、入力欄を埋め、画面が切り替わるたびに表示内容を確かめる作業です。この操作をAIに手伝ってもらい、担当者が入力条件や結果の確認に時間を使う用途が考えられます。
そのための道具の一つが、Microsoftの公開ツール「Playwright MCP」です。公開リポジトリの説明文書であるREADMEによると、AIエージェントにブラウザを操作する手段を提供し、ページ上のリンクや入力欄を扱えるようにします。ここでは注文フォームの点検を例に、仕事への組み込み方を考えます。実際の導入事例や作業時間の削減を示すものではありません。
ページの情報を読み、次の操作につなげる
入力に当たるのは、AIに伝える点検の目的や条件と、ブラウザに表示されたページの情報です。注文フォームなら、どの情報を入力し、どの画面まで進むかを先に決めておきます。
Playwright MCPがページを読む際に使うのは、アクセシビリティ情報です。リンクや入力欄といった要素の役割などを、支援技術でも扱えるように表した情報を指します。同ツールはこれを構造化して読み取り、操作対象を扱います。「画面を部品として捉える」と考えると理解しやすいでしょう。実際には、画面の画像を切り分けるという意味ではなく、ページが持つ要素の情報を読む仕組みです。
MCPは、AIと外部の道具をつなぐための共通のやり取りの方式です。ここでは、AIが次の操作を判断し、Playwright MCPがブラウザに働きかける手段を提供します。操作を決めるAIと、操作を実行するための道具には、それぞれ役割があります。
出力として生じるのは、ブラウザ上の操作と、その結果として変わるページの状態です。仕事の点検に使うなら、どの情報を入力してどこまで進み、何を確認したかを記録する運用も組み合わせたいところです。報告の形式と合否の基準は、担当者があらかじめ決めます。
READMEが説明する特徴は、常にスクリーンショットの認識だけに頼る方式ではないことです。ページの要素を直接扱う情報があれば、画像から操作対象を読み取る際の問題を避けられる場面は考えられます。ただし、それだけで見た目の崩れを正しく判定できることや、どのページでも操作が成功することまでは保証されません。
確認画面まで進む作業と、表示を評価する作業を分ける
ECの点検で試すなら、テスト会員の情報、テスト商品の一覧、入力用の住所、確認画面に表示されるはずの項目を用意する方法が考えられます。実際の顧客情報を使う必要のないテスト条件を整え、各画面で行う操作と停止する位置を指定します。
たとえば、カートから確認画面まで進む操作をAIに任せ、担当者は記録を見て、住所などの入力内容が引き継がれたか、必要な項目が表示されたかを判断します。画面をたどる作業を任せるには、何をもって点検に合格したとするかを、人が説明できる状態にしておく必要があります。
操作できたことと、利用者にとって使いやすいことも別の確認事項です。リンクや入力欄を構造化して扱えても、スマホで文字を読みやすいか、ボタンを押しやすい位置に置けているかまで確認できたとは判断できません。注文の流れをたどる点検に加えて、表示を目で確かめる工程を設ければ、AIに任せた範囲が明確になります。
確認画面への到達も、購入処理全体の正しさを示すものではありません。入力と画面の切り替わりを点検したのか、取引を確定したあとの処理まで確かめたのかで、結果から言えることは変わります。担当者は到達した画面だけでなく、どこまでを点検対象にした記録なのかを見る必要があります。
途中の状態を見ながら進める仕事に合うか
READMEは、継続した状態の把握が役立つMCPと、コーディングエージェント向けに効率を重視したCLIとSkillsという選択肢を説明しています。CLIは文字のコマンドで道具を動かす方式、Skillsはエージェントに作業の手順などを与える仕組みです。
注文フォームでは、情報を入力すると画面が変わり、その結果に応じて次の操作を選びます。こうした仕事では、途中の状態を把握しながら進める点が、MCPを検討する理由になります。開発作業の中で使う場合には、CLIやSkillsも比較の対象です。どの方式を使うかは、作業の途中で何を読み取り、どう次の操作を決めたいかに照らして考えるとよいでしょう。
これらの説明だけから、方式ごとの成功率や費用の優劣は判断できません。自社で比較するなら、同じテスト条件で確認画面まで到達できた割合と、人が操作を修正した回数を記録する方法が考えられます。到達した割合は高いほど、修正回数は少ないほど、任せやすさの目安になります。
ただし、誤った情報を入力したまま到達していないかも確認が必要です。完了した回数だけで評価すると、点検の目的を満たしたかを見落とします。これらは本記事で提案する評価方法であり、発表元の測定結果ではありません。
ブラウザを動かす権限と、注文を確定する権限
実務で試す際には、購入や送信が起きる操作を別の承認に分ける設計を勧めます。ブラウザのボタンを押せることと、会社として取引を確定してよいことは、異なる権限だからです。注文フォームの点検なら、まずテスト環境で確認画面を停止地点にし、その先へ進む条件は人が決める運用が考えられます。
発表元は、接続先の許可リストが完全な安全境界ではないとも明記しています。許可リストは、接続を認める先を指定するものです。アクセス先を絞っただけで、その先で行う操作まで安全になるとは判断できません。テスト用アカウントにどの権限を持たせるか、確定操作を実行できる条件をどう制限するかも、あわせて確認したい点です。
最初の試行では、自社のフォームで必要な入力欄を読み取れるか、画面が変わったあとも作業を続けられるか、指定した位置で止まれるかを確かめます。その記録をもとに、担当者が任せる範囲を広げるかを判断します。入力内容と操作後の状態を人が評価できる形で残すことが、フォーム点検へ組み込むための具体的な準備になります。