Claude Code × Playwright で UI レビューを自動化する記事を読んだ。やっていることは、改修した画面のスクショを Playwright で 3 種類撮って、Claude にチェックリストで見させて、改修→レビュー→改修のループを人手なしで回す、というもの。75 分の手動スクショ作業を 0 分にした、と書いてある。
これを見て真っ先に思ったのは、「Chrome DevTools MCP でも同じことができる」だった。普段ブラウザでデバッグするときに我々が叩いているのと同じ DevTools が、MCP 経由で Claude Code からも叩ける。スクショも、コンソールエラーも、ネットワーク 404 も、JS 実行で要素サイズを測るのも、全部できる。Playwright じゃないと無理な部分は本当にあるのか、を整理しておきたかった。
「Playwright じゃないとできないこと」はほとんど無い
記事のステップを Chrome DevTools MCP に置き換えると、こうなる。
| 記事のステップ | Chrome DevTools MCP の対応 |
|---|---|
| 3種類のスクショ（PC ファーストビュー / PC 全体 / モバイル） | resize_page + emulate + take_screenshot |
| コンソールエラー検出 | list_console_messages |
| 404 検出 | list_network_requests |
| タップターゲット 44px 未満チェック | evaluate_script で getBoundingClientRect を走査 |
| Claude が画像を読んで 7 観点で評価 | 同じ（評価部分はツール非依存） |
技術的には、たぶん完全に代替できる。ここに差は無い。
記事の本当の価値はツール選択じゃない
では記事は何を提供しているのか。読み直してみると、優れているのは Playwright を選んだ部分ではなくて、その上に乗せている設計のほうだった。
ひとつは評価軸を言語化して SKILL.md に固定したこと。7 観点（ファーストビュー / レイアウト / タイポグラフィ / インタラクション / 画像 / モバイル / AI 感）を文章で書き出して、Claude にそれを使わせる。なかでも「AI 感チェック」という項目は独自で、H1 直上の uppercase + letter-spacing の eyebrow text、「◯◯が選ばれる理由」テンプレ、アイコン＋タイトル＋説明の 3 枚グリッド、といったテンプレート臭の出やすいパターンを検出させる。これはツールに依存しない知見で、Chrome DevTools MCP でそのまま使える。
もうひとつは改修→レビュー→改修のループを自走させる配線。コードレビュー側のスキルから layout-check を自動で呼び、dev サーバまで自動で起動する。これも MCP 側で同じワイヤリングを書けば成立する。
判定基準のチューニングも記事の手柄で、「タップ 44px」を装飾用セカンダリボタンには 24px に緩和する、という運用知が紹介されている。最初に決めた閾値を画面のノイズに合わせて下げる、という作業は、ツールを変えても発生する。
Playwright を選ぶ実利は 4 点だけある
「ほとんど同じ」と言いつつ、自走ループに乗せる前提なら効いてくる差はある。
- 決定論性: Playwright は固定ビューポート・クリーンプロファイル・拡張機能なしで起動できる。Chrome DevTools MCP は自分の Chrome に繋いでいることが多いので、ログイン状態・拡張・他タブの影響で「同じ URL でも違うスクショ」が出る。改修ループを毎日回すなら、ここが効く。
- CI 実行可能性: Playwright は GitHub Actions に乗る。Chrome DevTools MCP はローカル Chrome 依存なので CI 不向き。PR ごとに自動 UI 回帰チェックを走らせたいなら、Playwright 一択になる。
- コンテキスト効率: MCP は呼び出すたびに結果が Claude のコンテキストに積まれる。Playwright は外部スクリプトで完結して、Claude に渡るのは画像パスと判定結果だけ。連続ループで回すと、トークン消費の差がそのままコストの差になる。
- 接続の安定性: Chrome 136+ のデフォルトプロファイル制約、9222 ポートの残骸居座り問題、Windows で既存 Chrome に勝手にアタッチして即終了する罠、と DevTools MCP は地味に詰まる。Playwright は自前で Chromium を立ち上げるので、このクラスの事故が起きない。
逆に言うと、上の 4 つが要らない場面では Chrome DevTools MCP のほうが手軽で十分だ。自分のログイン済みセッションでそのまま画面を見たい、たまに 1 ページ確認するだけ、という単発用途なら MCP の勝ちになる。
我々が DevTools でデバッグしているのと何が違うか
ここが個人的にいちばん腑に落ちた点だった。普段 Chrome DevTools を開いてデバッグしているのに、なぜ記事のような「UI レビューの自動化」という話が独立して存在するのか。同じツールを使っているのに、運用モードが違うからだ。
- 手動デバッグ: 仮説検証型・ホットスポット調査。「ここのレイアウトが崩れてる」と当たりがついている対象を、DevTools で掘る。
- 記事の自動レビュー: 網羅スキャン型・回帰検査。当たりがついていない未知の問題を、固定チェックリストで毎回スキャンする。
人間が DevTools で網羅スキャンをやらないのは、飽きるからだ。同じ画面を 7 観点で 75 分かけて見続けることはできない。Claude にやらせる前提に変わった瞬間、チェックリストの固定が本質になって、ツールは後ろに退く。記事が「7 観点 + AI 感チェック」を書き出している部分が本体で、その手足としての Playwright は交換可能、というのはそういう意味だ。
まとめ
- 「Chrome DevTools MCP でも同じことができる」は正しい。代替できない部分はほぼ無い。
- 記事の優れた点は、7 観点 + AI 感チェックという評価軸の言語化と、改修との自走ループ化にある。ツール選択ではない。
- Playwright を選ぶ実利は 決定論性・CI 実行・コンテキスト効率・接続安定性 の 4 点。ローカル単発なら DevTools MCP で十分、自走/CI に乗せたくなったら Playwright 優位、という棲み分けで足りる。
自分の運用に持ち込むなら、まず .claude/skills/ 配下に7 観点 + AI 感チェックを SKILL.md として固定して、実行系は Chrome DevTools MCP のまま回す。それで困ったら Playwright に切り替える。順序を逆にして「まず Playwright を入れる」をやると、肝心のチェックリストが固まる前にツール周りで時間を溶かす。