Claude Code に Playwright MCP を繋いだら、E2E テスト前の準備が3時間消えた

先週、Claude Code に「うちのブログのトップページ、ヘッダーのリンクが全部効いてるか確認しといて」って雑に投げた。普段ならここで Claude が「Playwright のテストコードを書きました」って返してきて、僕がそれをコピペして実行して、エラーを Claude に貼り直して……という往復が始まる。だいたい1時間は溶ける作業だった。

でもその日は違って、Claude Code が勝手にブラウザを開いて、リンクを順番にクリックして、「3つ目のリンクが 404 になってる」って報告だけ返してきた。間に僕の手作業は1回も挟まってない。Playwright MCP を繋いだ直後の体験で、正直「あ、これもう戻れないやつだ」と思った。

ここまでに踏んだセットアップと、3時間くらいハマった詰まりどころを全部書く。Windows 11 + Node v24 + Claude Code（CLI）の構成。

なぜ Playwright MCP を入れることにしたか

きっかけは、ブログのデプロイ後の動作確認がしんどかったから。記事を push するたびに、本番の URL を開いて、OGP が出るか、リンクが効くか、モバイル表示が崩れてないか、ぽちぽち確認していた。1回5分でも、週に4〜5本記事を出していると地味に積み重なる。

Claude Code には WebFetch ツールがあるけど、これは HTML を取ってくるだけで、JS で描画される部分は見えない。OGP みたいに meta タグだけならいいけど、「実際にクリックしてみてどうなるか」は確認できない。

Playwright MCP は、Claude Code から Playwright を MCP プロトコル越しに叩ける仕組み。ブラウザを起動して、ページを開いて、クリックして、スクショを撮って、コンソールログを読む、までを Claude が直接やってくれる。E2E テストの「テストを書く前段の探索フェーズ」が一気に消える、というのが導入の動機。

セットアップ手順（実際にやったやつ）

公式の手順は @playwright/mcp を npm で入れて、Claude Code の設定ファイルに登録するだけ。本来は3分で終わるはずだった。

npm install -g @playwright/mcp@latest
npx playwright install chromium

そのあと、~/.claude.json（Windows だと C:\Users\<user>\.claude.json）の mcpServers に追記する。

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest"]
    }
  }
}

Claude Code を再起動して /mcp を打つと、繋がっているサーバー一覧が出てくる。ここに playwright が connected で表示されれば終わり。

……というのが理想で、僕の環境では3箇所で詰まった。

詰まりどころ3つ（合計3時間ロスト）

1. npx のパスが解決できない

Windows + Node v24 で、Claude Code から npx を呼ぶと「コマンドが見つからない」エラーで落ちた。PowerShell から手打ちで npx -y @playwright/mcp@latest を叩くと動く。つまり Claude Code 側の環境変数で PATH が拾えていない。

command を npx.cmd に書き換えたら通った。Windows だと .cmd 拡張子の明示が必要なケースがある。これは Playwright MCP 固有の話じゃなくて、Windows + MCP 全般のあるある。

"command": "npx.cmd",

2. Chromium のインストール先がずれる

npx playwright install chromium を別ディレクトリで先に叩いていて、Claude Code 経由で起動した Playwright MCP は別のキャッシュ先を見にいっていた。「Executable doesn't exist at ...」というエラーがログに出ていた。

PLAYWRIGHT_BROWSERS_PATH を環境変数で明示してから入れ直したら直った。Windows のユーザープロファイル配下に固定。

$env:PLAYWRIGHT_BROWSERS_PATH = "C:\Users\<user>\.cache\ms-playwright"
npx playwright install chromium

mcpServers の env フィールドにも同じパスを書いて、Claude Code 側からも同じ場所を見るようにした。

3. ヘッドレスのまま動いてて確認できない

繋がってから最初に「sumi.blog のトップ開いて」って投げたら、Claude が「開きました」と返してきたけど、画面には何も出てこない。デフォルトでヘッドレスモードだから、当然なんだけど、初見だと「動いてるの？」って不安になる。

args に --headless=false を追加したらブラウザが目に見える形で開いた。デバッグ中はこっちが安心。

"args": ["-y", "@playwright/mcp@latest", "--headless=false"]

合計で3時間くらい溶けた。原因の半分は Windows、半分は MCP 全般の挙動把握不足。

実際に何が変わったか

導入してから1週間運用してみて、明確に変わったのが3つある。

1つ目：記事公開後の動作確認が、5分→30秒になった。「sumi.blog 開いて、新着記事のリンクが効くか、OGP 画像が出てるか確認して」で終わる。Claude が勝手にスクショを撮って「OGP 出てます、リンク全 OK」と返してくる。

2つ目：E2E テストの初期コードを書くスピードが上がった。Playwright のテストコードって、セレクタの調整で何度もリロードするのが面倒なんだけど、Claude Code が探索しながら書くから、最初から動くコードが出てくる。体感、テスト1本あたり20分→7分。

3つ目：UI のバグ報告が具体的になった。「モバイル表示でヘッダーが崩れる」って曖昧な状態じゃなくて、「375px のとき、ナビゲーションの3つ目以降が画面外に出ます。スクショ添付」まで Claude が出してくる。

逆に注意点：ブラウザを起動するから、当然 Claude Code のセッションが重くなる。並列で何個もタブを開かせると、メモリが 2GB くらい持ってかれた。常時起動はせず、必要なときだけ MCP を有効化する設計にした方がいい。

まとめ

Playwright MCP は、Claude Code を「コードを書く AI」から「ブラウザを触る AI」に拡張する一手だった。E2E テストを書く前の探索、デプロイ後の動作確認、UI バグの再現、このあたりが全部 Claude の領域に入ってくる。

セットアップでハマる箇所は Windows なら3つ。npx.cmd 表記、PLAYWRIGHT_BROWSERS_PATH の明示、--headless=false の指定。この3つを最初から知っていれば、たぶん30分で終わる。

次は Figma MCP と組み合わせて、「Figma のデザインを取ってきて、実装したコンポーネントと見比べて差分を Claude に指摘させる」までやってみたい。やったらまた書く。