「ブラウザの操作まで任せられるらしい」。そう聞いて調べ始めると、最初に名前が出てくるのがPlaywright MCPです。ところが公式の説明を読み進めても、自社の業務でどこまで動くのかは、なかなか像を結びません。
いちばん引っかかるのがログイン画面です。IDとパスワードを入れる画面を触らせてよいのか。触らせるとして、ログインした状態はどこに残るのか。ここが決まらないと、社内で相談を始めることすらできません。
この記事は、繋ぐ手順と、動く範囲・分からない範囲を切り分けます。素材はWEBMARKSでの接続実行ではなく、公式リポジトリと公式ドキュメントの記述確認（2026-07-29）です。実際に使ってどうだったかという体感は、ここには書きません。
こんなふうに調べていませんか
- ブラウザ操作まで任せたいが、どこまで動くのかが読めない
- ログイン画面を触らせてよいのか、社内でまだ判断できていない
- 繋ぐところまでは分かった。権限をどこまで絞ればよいかが決まらない
この記事を読み終えたときに手に入るもの
- 接続からツール呼び出しまでの流れを、順番で説明できるようになります
- 認証済みの状態を渡す4つのやり方を、状態の持ち主で選び分けられるようになります
- 開けたままにしない権限の絞り方を、3つの段に分けて設計できるようになります
結論30秒でわかる、この記事の結論
- Playwright MCPは、画面の見た目ではなく部品の構造データを手がかりにブラウザを触るMCPサーバーです。
- ログインのフォーム操作そのものは他の画面と変わりません。分かれ目は、認証済みの状態を外からどう渡すかです。
- 公式は「これ自体はセキュリティの境界ではない」と述べています。開ける機能を選ぶ作業は、繋ぐ側に残ります。
進行役は3人です。若葉さんが用語の側から、高梨課長が自分の手で動かす側から聞き、鈴木さん（本誌監修）が答えます。
01Playwright MCPって、AIエージェントに何をさせる道具なんですか？
若葉さんブラウザを操作するというと、画面を見ながらクリックする感じでしょうか。
鈴木さんそこが少し違うんです。目で見て押すのではなく、画面の裏側にある部品の一覧を読んで押しています。人が目視で探すより、取り違えが起きにくい読み方ですね。
Playwright MCPは、Microsoftが公開しているMCPサーバーです（出典: 公式リポジトリ microsoft/playwright-mcp）。MCP（AIに外部ツールを触らせるための共通の口）を通して、ブラウザの操作をAIエージェントの側へ渡します。土台になっているのは、E2Eテスト用フレームワークPlaywrightのブラウザ制御機能です。
大きな設計判断は、操作の根拠をスクリーンショットではなくアクセシビリティツリー（画面を構成する部品の構造データ）に置いたことです。READMEは「LLMフレンドリーで、視覚モデルを必要とせず、構造化データのみで動作する」と説明しています（出典: 公式リポジトリ）。同じ文書は、スクリーンショットを行動の根拠には使えないとも明記しています。
できることの中心は、クリック・入力・フォーム送信・タブ操作です。これらをアクセシビリティスナップショット越しに実行します。
なお、WEBMARKSは本記事の執筆時点で、Playwright MCPを本番業務へ接続していません。ここから先は、公式リポジトリと公式ドキュメントの記述に基づく設計論として読んでください。
02Playwright MCPをAIエージェントに繋ぐには、何から始めるんですか？
接続はローカルプロセス（stdio）で完結します。Claude Codeへ繋ぐ場合は、公式ドキュメントが示すstdio型MCPサーバーの追加構文に沿います（出典: Claude Code公式MCPドキュメント）。
# 1. サーバーを登録する（自分専用のlocalスコープが既定）
claude mcp add --transport stdio playwright -- npx @playwright/mcp@latest
# 2. 接続状態を確認する
claude mcp list登録が終わったら、browser_snapshotを一度だけ呼んでみます。想定していた要素が返ってくるかどうかで、繋がったという事実と、使えるという事実を別々に確認できます。
npxはパッケージを都度取得するため、初回実行時にネットワークアクセスが発生します。オフライン環境や社内プロキシ配下では、--proxy-server・--proxy-bypassを先に設定しておきます（出典: 公式リポジトリ）。ここを飛ばすと、設定の誤りではなく通信の遮断で止まるため、原因の切り分けに時間を取られます。
この章のまとめ
繋ぐ作業そのものは短く終わります。時間が要るのは、通信経路と、次の章で扱う承認の範囲を決めるほうです。
03チームで共有するとき、MCPの承認はAI導入の誰が押すんですか？
高梨課長自分の手元で動いたとして、チームで使うときはどうなるんでしょう。
鈴木さん設定を配る範囲を選ぶことになります。ただ、配れば全員が使えるわけではなくて、受け取った人それぞれが一度は自分で承認します。そこは省略できない作りです。
チームで共有する場合は--scope projectを付け、.mcp.jsonへ書き出します。この考え方は、MCPの選び方｜AIエージェントに任せる範囲から見る5軸で扱ったscope設計と同じです。
project scopeのサーバーは、Claude Codeが起動時に「承認待ち」として一覧に出します。実行者ごとに1回は個別承認が要ります（出典: Claude Code公式MCPドキュメント）。設定ファイルを配ることと、その人の環境で動くことは、別の出来事として数えます。
| 段階 | やること | 済んだと言える状態 |
|---|---|---|
| 登録 | stdio型としてPlaywright MCPを追加する | 追加できた旨の完了行が出る |
| 承認 | project scopeなら対話的に起動して承認する | 接続一覧に接続済みとして並ぶ |
| 挙動確認 | 必要なオプションを引数へ足して呼んでみる | 想定した要素がスナップショットに現れる |
04Playwright MCPで、ログイン画面は、AIエージェントにどこまで任せられるんですか？
フォーム操作そのものに、ログイン画面特有の制限はありません。browser_fill_formやbrowser_typeは、ログインフォームであっても他のフォームと同じ手順で入力します。
分かれ目はその先です。認証済みの状態を、どう維持し、どう再利用するか。公式READMEは、この扱いを4つのやり方で説明しています（出典: 公式リポジトリ）。
| やり方 | 仕組み | 何が要るか | 気をつける点 |
|---|---|---|---|
| 永続プロファイル（既定） | ヘッドあり実行時、ログイン情報を含む状態をOS標準のキャッシュ領域に保存し続ける | 指定は不要（既定動作） | 端末を共有すると前回のログイン状態が残る |
--storage-state | クッキー・localStorageを書き出したファイルを分離セッションへ読み込ませる | 事前に取得済みの状態ファイル | ファイルに機微なクッキー・ヘッダーが残る |
--user-data-dir | ユーザーデータディレクトリを指定し、独自の永続プロファイルを使う | 保存先ディレクトリの用意 | ディレクトリの管理・権限設計が別途要る |
| Browser Extension | 既存のブラウザタブへ接続し、人がログイン済みのセッションをそのまま使う | 拡張機能の導入 | 人の操作中のブラウザと状態を共有する |
4つを並べ替えると、表の行とは別の分かれ目が見えます。状態の持ち主が機械なのか、人なのかです。機械の側に置いた状態は、消し忘れれば残り続けます。人のブラウザに相乗りした状態は、その人が操作をやめれば一緒に終わりますが、動いているあいだは人の画面と同居します。
管理の宛先も、そこで分かれます。前者は保存先と削除の手順を決める話になり、後者は「誰の端末で走らせるか」を決める話になります。
この章のまとめ
選ぶのは機能名ではなく、状態の置き場所です。置き場所が決まれば、誰が片づけるかも決まります。
05Playwright MCPの認証済みの状態を、AI社員にどう渡すのが安全なんですか？
高梨課長状態ファイルは便利そうですが、社内で持ち回っても大丈夫でしょうか。
鈴木さんそこは慎重に見ています。パスワードそのものではないのに、あれば本人として入り直せてしまう。扱いとしては同じ棚に置くようにしています。
Playwright本体のドキュメントは、認証状態の保存ファイルについて明確に警告しています。なりすましに使われかねない機微なクッキーやヘッダーを含む可能性がある、という文言です。そのうえで、リポジトリへコミットすることを強く戒めています（出典: Playwright公式ドキュメント）。
WEBMARKSの社内ルールは、資料に記載されたIDとパスワードでのログインを禁止し、保存も禁止しています。この考え方は、認証状態ファイルにもそのまま当てはまります。状態ファイルはID・パスワードそのものではありませんが、それを使えば本人としてログインし直せる点で、実質的に機微な認証情報と同じ扱いが要ります。
機密の扱いをさらに絞りたい場合、--secretsオプションでdotenv形式の秘密情報ファイルを指定できます（出典: 公式リポジトリ）。機能は用意されていますが、その置き場所を社内のどこにするかは、別途決める必要があります。隔離の設計はAIエージェントに機密情報を渡さない｜3段階の分離と検査で扱っています。
062要素認証やCAPTCHAが出たとき、Playwright MCPのAIエージェントは止まるんですか？
若葉さんログイン画面って、途中でコードを入れる画面が出ることがありますよね。あれはどうなるんでしょう。
鈴木さんそこは、分からないと言うしかない部分です。公式の文書に書かれていないので、書いていないという事実だけをお伝えしています。
READMEには、2要素認証やCAPTCHAをPlaywright MCPがどう扱うかの記述がありません。一般に、ヘッドレスブラウザは自動化ツールとして検知されやすく、ボット判定の対象になりやすいことが知られています。ただしPlaywright MCP自身が検知回避の機能を持つとは、公式文書のどこにも書かれていません。
同じことが、画面の構造にも当てはまります。iframe内やShadow DOM内の要素を、アクセシビリティスナップショットがどこまで拾うかについては、公式READMEに直接の記述がありません。ブラウザ自体のアクセシビリティツリー生成に依存する部分のため、対象サイトごとに確認が要る領域として、ここでは断定を避けます。
書かれていない領域を「たぶん動く」で埋めないでください。図の右側は、検証の予定を立てる場所であって、期待を書き込む場所ではありません。
07動的サイトで要素が取れないとき、Playwright MCPのエージェントは何を見るんですか？
JavaScriptで内容が後から差し込まれる動的サイトでも、アクセシビリティツリーを使う設計自体は有利に働きます。DOMの更新に追随するため、決まった座標の画像を待つやり方より、要素の出現を捉えやすい設計です。
とはいえ、待つ責任は呼び出す側に残ります。browser_wait_forはテキストの出現または時間経過を待つツールです。browser_snapshotは呼び出した瞬間の状態しか返しません（出典: 公式リポジトリ）。描画の完了を待たずに呼べば、まだ現れていない要素はそのまま欠けます。
切り分けに使える道具も用意されています。browser_console_messagesはコンソールログを返します。browser_network_requestsは読み込んだページのネットワークリクエスト一覧を返します（出典: 公式リポジトリ）。想定した要素が取れないとき、この2つで描画やAPI呼び出しが終わっているかを先に確かめられます。
ネットワークリクエストのモック機能（browser_route）は既定では無効で、--caps=networkを指定したときだけ使えます（出典: 公式リポジトリ）。動的サイトを決まった条件で再現したい場合は、この機能の追加検証が視野に入ります。
08Playwright MCPの権限は、AI導入のどこまで絞れるんですか？
公式READMEは、Playwright MCP自体について「セキュリティの境界ではない」と明記しています（出典: 公式リポジトリ）。ファイルアクセス制限のオプションについても、LLMがワークスペース外へさまよい出ることを防ぐ利便性の防御であり、安全な境界ではないと説明されています。
とりわけ注意が要るのが、コード実行系のツールです。browser_run_code_unsafeは、Playwrightサーバーのプロセス内で任意のJavaScriptを実行します。README自身がこの機能をRCE相当と表現しています（出典: 公式リポジトリ）。
Claude Code側は、MCPサーバーのツールをmcp__サーバー名__ツール名という形式で権限ルールの対象にできます。Claude Codeの権限設定｜AIエージェントに任せる範囲と3列の配分で扱った枠組みがそのまま使え、危険度の高いツールだけを狙ってdenyへ回せます。
{
"permissions": {
"deny": [
"mcp__playwright__browser_run_code_unsafe",
"mcp__playwright__browser_file_upload"
],
"ask": [
"mcp__playwright__browser_navigate"
]
}
}09Playwright MCPで使わない機能まで開けたままだと、AI活用は何が困るんですか？
Playwrightの機能は、既定ですべて開いているわけではありません。--capsのオプトイン方式で有効化する分類が用意されています（出典: 公式リポジトリ）。
- ネットワーク：
browser_routeによるリクエストのモック - ストレージ：クッキー・localStorage・sessionStorageの取得や書き換え
- DevTools：トレース記録・録画・要素ハイライト
- 座標クリック：
vision指定によるマウス座標操作 - PDF生成：
browser_pdf_save - テストアサーション：
browser_verify_element_visibleなどの検証系 - 設定確認：
browser_get_configで最終的な設定値を取得
使わない分類を開けないことも、接続設計の一部です。deny・askで危ないものを閉じる作業は目立ちますが、そもそも開けていなければ閉じる手間も生じません。
この章のまとめ
権限設計は引き算です。開けてから閉じるのではなく、開ける分類を選ぶところから始めます。
10ヘッドレスで動かすと、Playwright MCPのAI活用は何が変わるんですか？
ヘッドレス実行は--headlessフラグで有効化でき、Dockerでも稼働します。ただし起動のしかたを変えると、引き継がれるものが変わります。
既定の永続プロファイルは、ヘッドあり実行が前提になっています。 READMEはログイン情報が保存される永続プロファイルを説明していますが、これは--isolatedを付けない場合の話です。分離モードでは、セッションごとに独立したプロファイルを使い、閉じるとストレージは失われると明記されています（出典: 公式リポジトリ）。
Docker実行はヘッドレスChromium限定です。 公式リポジトリは、Dockerによる実装が現時点でヘッドレスChromiumのみをサポートすると明記しています（出典: 公式リポジトリ）。FirefoxやWebKitでの検証をヘッドレスCIに組み込みたい場合は、Docker以外の実行方式を検討することになります。
2軸に置き直すと、ヘッドレスかどうかは片方の軸でしかないことが分かります。もう片方は、前回の続きから始めるのか、毎回まっさらから始めるのかです。この2つは独立しているので、「ヘッドレスにしたら状態が消えた」という現象は、実は縦の軸を一緒に動かした結果です。
区画で考えると、選ぶ順番も変わります。先に決めるのは状態のほうです。続きから始めたいのか、まっさらがよいのか。それが決まってから、画面を見る必要があるかを決めます。
11繋いだはずのMCPが応答しないのは、AIエージェントの何が原因ですか？
高梨課長動いていたのに返ってこなくなることがあると聞きました。まず何を見ますか。
鈴木さん接続の一覧です。落ちていても画面には何も出ないので、こちらから見に行かないと分かりません。気づく手だてを先に決めておく、という話になります。
stdio接続は、切れても自動では戻りません。 Claude Code公式ドキュメントによると、HTTP・SSEサーバーは切断時に最大5回まで自動再接続します。stdioサーバーはローカルプロセスのため、自動では再接続されないと明記されています（出典: Claude Code公式MCPドキュメント）。npx起動のPlaywright MCPは既定でstdio接続なので、プロセスが落ちても次の呼び出しまで気づけないことがあります。
| 症状 | 設計上の原因 | 対処 |
|---|---|---|
| ヘッドレスCIでログイン状態が引き継がれない | 分離モードはセッションを閉じるとストレージを破棄する | 事前に取得した状態を明示的に渡す |
| DockerでFirefox・WebKitが動かない | Docker実装はヘッドレスChromiumのみ対応 | Docker以外のホスト実行に切り替える |
| 途中でツール呼び出しが応答しなくなる | stdio接続はサーバー切断を自動再接続しない | 接続一覧で状態を確認し、必要なら再登録する |
3つに共通するのは、画面上は何も起きないことです。止まっているのか、まだ処理中なのか、待っている側からは見分けがつきません。だから、接続一覧を見る操作を運用の手順に組み込んでおきます。
12生成AIにブラウザを触らせる前に、Playwright MCPで確認するのはどこですか？
ここまでの内容を、繋ぐ前に確認する形へ畳みます。上から順に見て、埋まらない項目が残るなら、そこが検証の対象です。
- 登録に使うコマンドと、通信の経路（プロキシの要否）を確認した
- local・project・userのどの範囲で登録するかを決めた
--capsで開ける分類を、使うものだけに絞ったbrowser_run_code_unsafeのような危険度の高いツールをdenyへ回した- 認証済みの状態をどう渡すか、4つのやり方から1つ選んだ
- 状態ファイルを、Git管理と共有フォルダの対象から外した
- ヘッドレスで動かすなら、分離モードの有無とDockerの対応ブラウザを確認した
- 接続が切れても自動では戻らない前提で、気づく手だてを用意した
埋まらない項目は、放置せずに「まだ分かっていない」と書いておきます。書いていない領域と、確認して問題なかった領域は、見た目が同じになるためです。
13よくある質問
Playwright MCPは無料で使えますか
Playwright MCP自体はオープンソースとして公開されており、npx @playwright/mcp@latestで取得できます。別途費用が生じるとしたら、接続先のクラウド実行環境やプロキシなど、周辺のインフラの分です。ライセンスや提供形態は変わりうるので、導入の判断をする時点で公式リポジトリの記載を見直してください。
ヘッドレスとヘッドあり、どちらで動かすべきですか
用途で決まります。ログイン状態を目視しながら育てたい開発段階はヘッドあり、CIで同じ条件から始めたい場合はヘッドレスと分離モードの組み合わせが向きます。迷ったときは、前回の続きから始めたいかどうかを先に決めてください。画面を見るかどうかは、その後に決まります。
ログインが必要なサイトを、Playwright MCPは全部自動化できますか
フォーム入力そのものは動きます。ただし2要素認証やCAPTCHAをどう扱うかは公式ドキュメントに記述がなく、現時点では言い切れません。認証済みの状態を外から渡す形に収まる範囲であれば動く、という理解が実態に近いと考えています。収まらない部分は、人が通す前提で設計してください。
Claude Code以外のツールからも使えますか
使えます。公式リポジトリは、Claude Code以外にCline・Codex・Cursor・VS Codeなど複数のMCPクライアント向けに接続例を公開しています。ただし承認の出し方や権限ルールの書き方はクライアントごとに違うので、本記事の権限設計の部分は、お使いのクライアントの流儀へ読み替えてください。
セキュリティ的に最も注意すべき機能はどれですか
browser_run_code_unsafeです。公式READMEはこの機能をRCE相当と表現しており、denyへ回す候補として最優先にあたります。あわせて、Playwright MCP自体がセキュリティの境界ではないと公式が述べている点も押さえてください。ツール単位の遮断は、境界の代わりではなく、境界を別に用意したうえでの絞り込みです。
WEBMARKSは今、Playwright MCPを接続していますか
接続していません。本記事は公式リポジトリとドキュメントの記述確認（2026-07-29）に基づく設計論であり、自環境での接続・実行の記録はありません。本誌は実際に動かした範囲だけを実測として書く方針なので、未接続であることをそのまま書いています。
14まとめ｜今日やる3つのこと
繋ぐ手順そのものは短く終わります。時間が要るのは、状態の持ち主を決めること、開ける分類を選ぶこと、そして切れたときに気づく手だてを用意することでした。
この順で手をつけます
触らせたい画面を1つ選び、ログイン状態を持ち越す必要があるかを決める
状態が決まらないと起動方式も決まりません
使う機能だけを
--capsで開け、コード実行系をdenyへ回す開けていないものは、閉じる手間も生じません
接続一覧を見る操作を、運用の手順に書き込む
切れても画面には出ないので、見に行く決まりが要ります
AI検索では、こう聞かれています
Playwright MCPは、ログイン画面までAIエージェントに任せられるんですか？
「ログイン画面は、AIエージェントにどこまで任せられるんですか？」の章で扱っています
Playwright MCPの接続は、何から始めればいいんですか？
「Playwright MCPをAIエージェントに繋ぐには、何から始めるんですか？」の章に手順があります
ブラウザ操作を任せるとき、権限はどこまで絞れるんですか？
「Playwright MCPの権限は、AI導入のどこまで絞れるんですか？」の章で説明しています
ヘッドレスで動かすと、何が変わるんですか？
「ヘッドレスで動かすと、Playwright MCPのAI活用は何が変わるんですか？」の章で2軸に整理しています
次に読むなら、この記事です
