「Claude Codeにブラウザ操作までさせたい」と研修先で言われて、最初は「そういう拡張あったっけ」と曖昧に返してしまった話があります。実はあります。Playwright MCP を使うと、Claude Codeから直接ブラウザを開いて、ページを読んで、ボタンを押せます。
この記事では、Claude CodeとPlaywrightを組み合わせると何ができるのか、最初のセットアップ、非エンジニアでも扱える使い方を整理します。
Playwrightはブラウザを動かす自動化ツール
Playwrightは、もとはMicrosoftがオープンソースで開発しているブラウザ自動化ツールです。Chrome、Firefox、Safariなどを、人間が操作するのと同じようにスクリプトで動かせます。E2Eテストの世界では定番のひとつで、テスト用途で広く使われてきました。
このPlaywrightを、MCP(Model Context Protocol)経由でClaude Codeに繋ぐ仕組みが playwright-mcp です。MCPサーバーとしてPlaywrightが動き、Claude Codeはそのサーバーに「このURLを開いて」「このボタンをクリックして」と話しかけます。
私が初めて触ったとき、「Claudeが自分で勝手にブラウザを開く」絵面に5秒くらい驚きました。デモで人に見せると、いちばん盛り上がるシーンです。
何ができるのか — 3つの使い分け
実際に半年使ってみて、用途は次の3つに収束しました。
第一に、社内ツール巡回。SaaSの管理画面を毎週開いて数字をコピペしているような作業は、Claude Code + Playwrightにそのまま渡せます。「Google Analyticsのこのレポート画面を開いて、PVと直帰率をMarkdownの表にして」のような指示が通る。
第二に、ページのスクリーンショット取得。競合サイトのキャプチャや、自社LPの定期スナップショットを、Claude Codeに任せられます。私はLPのデザイン変更ごとに、5ページぶんのフルページスクリーンショットをClaude Codeに撮らせて、変更前後を比較する流れにしました。
第三に、E2Eテストの自動生成。「このログイン画面を、メールアドレス入力 → パスワード入力 → ログインボタンの順でテストするPlaywrightスクリプトを書いて」と指示すると、Claude Code が動作確認しながらテストコードを生成します。テストエンジニアでなくても、E2Eテストの骨格が手に入る。
研修参加者の中では、第一の「社内ツール巡回」がいちばんウケます。経理担当の方が「クレジットカード会社の管理画面を毎月開いて取引一覧をCSVダウンロードする作業」をClaude Code + Playwrightで自動化したら、所要時間が30分から3分になったと報告してくれました。
セットアップは MCP 設定1行から
Playwright MCPの導入は、ホームディレクトリにあるMCP設定ファイルに数行追加するだけです。
// ~/.claude/mcp.json または .mcp.json
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["-y", "@playwright/mcp@latest"]
}
}
}
設定したあとClaude Codeを再起動すると、/mcp コマンドでplaywrightサーバーが認識されているのが見えます。Playwright本体や対応ブラウザは、初回起動時に自動でダウンロードされるので、明示的な事前インストールは要りません。
初回はブラウザバイナリのダウンロードで数百MBほど時間が掛かります。「動かない」と慌てる前に、ネットワーク状況をチェック。私は初回、Wi-Fiの調子が悪い喫茶店で試して、5分以上待たされて諦めかけた経験があります。
はじめの一歩 — スクリーンショットを撮らせる
セットアップが済んだら、いちばん短い指示で動作確認できるのがスクリーンショット取得です。
https://claude.ai/ をChromeで開いて、トップページのスクリーンショットを screenshots/claude.png に保存して
Claude Codeが内部で browser_navigate → browser_screenshot のような道具を順番に呼んで、画像を保存します。最初の1枚が出てきた瞬間に、「あ、これは生活が変わるやつだ」と腹落ちすると思います。
私はこれを研修の冒頭デモに使っています。コードもターミナル知識も要らず、日本語の指示1行でブラウザが動く絵が、Claude Codeの底力をいちばんわかりやすく伝えます。
注意点とつまずきやすい場面
便利な分、落とし穴もあります。
第一に、ログインの必要な画面はクレデンシャル管理が必須。Playwrightは人間の操作を再現できるので、ログインフォームへの自動入力も可能です。ただし業務システムのIDとパスワードをプロンプトに直接書くのは絶対避けるべきで、.env や macOS Keychain などからシークレットを引いて使う設計にします。
第二に、社内システムの利用規約を確認。スクレイピングを禁止しているサイトに対してPlaywrightで巡回すると、利用規約違反になる可能性があります。社内SaaSであっても、自動化を制限しているプランがあるので、最初に確認を。
第三に、Headlessモードかどうかを意識する。デフォルトでは画面が見えない「Headlessモード」で動きます。動きを目で見ながらデバッグしたい時は、browser_navigate の起動時に headless=false を指定するか、/mcp 経由で設定を変更します。
私の運用ルールは、開発中はheadless=false で動きを目視、本番運用に乗せたらheadless=true に戻す、です。最初はモードの違いで「動いてるのか動いてないのかわからん」という相談を受けました。
E2Eテスト用途は事前のCLAUDE.md整備が鍵
E2Eテスト生成にClaude Code + Playwrightを使うなら、CLAUDE.md にテストの規約を書いておくと、生成されるコードの質が一段上がります。
書いておくと効くのは、
- テストファイルの置き場所(
tests/e2e/など) - 命名規約(
*.spec.ts) - 共通のフィクスチャ場所
- セレクタの優先順位(役割属性 → data-testid → CSS の順、など)
- 環境別の設定ファイルの場所
これらが書かれていないと、Claude Codeは毎回独自スタイルで生成してくるので、レビューで修正コストが膨らみます。一度CLAUDE.md に書けば、それ以降は安定します。
まとめ
- PlaywrightはMCP経由でClaude Codeに接続でき、ブラウザ操作を日本語で指示できる
- 主な用途は「社内ツール巡回」「スクリーンショット取得」「E2Eテスト生成」の3つ
- セットアップは
~/.claude/mcp.jsonに数行追加して再起動するだけ - 認証情報はプロンプトに直書きせず、シークレット管理の仕組みから引く
- E2Eテスト用途は、CLAUDE.md にテスト規約を書いておくと生成品質が安定する
