Playwrightのビジュアル回帰テストを保守メニューに組み込む──更新のたびに画面を目で全部見る作業を、スクリーンショット比較とClaude Codeの下調べに置き換える手順
この記事は、Playwrightのビジュアル回帰テスト（スクリーンショット比較）を、Webサイトの保守メニューに組み込む方法を扱います。
更新のあと、全ページを目で見ている
プラグインやテーマを更新したあと、担当者がトップから下層まで、1ページずつ開いて確かめる。
見落としがあれば、顧客から「表示が崩れている」と連絡が来ます。
目で見る作業は、ページが増えるほど長くなり、急ぐほど見落とします。
しかも、確かめた記録が残りません。
テスト自動化を見積もりに入れる考え方は、別の記事で扱いました。
▶ テスト自動化（Playwright等）を見積もりに入れる制作会社へ──「タダの社内作業」にせず、初期構築と月額の回帰テストに分けて売る手順と、手作業との比べ方の計算例
この記事は、その中でも保守と相性のよい「画面の比較」に絞った組み方です。
ビジュアル回帰テストとは、正しい状態の画面を基準画像として保存し、更新のあとの画面と機械で比べ、違いが出た箇所だけを人が確かめる仕組みである
黒字化の外科医です。Playwrightのビジュアル回帰テストを、保守の作業として解剖します。
保守に組み込むべき理由は、三つあります。
第一に、違いが出た箇所だけを見ればよくなるから。
全ページを目で見る代わりに、差分の画像が出たページだけを確かめます。
第二に、確かめた記録が残るから。
いつ、どのページを、どの基準と比べたかが、テストの結果として残ります。保守報告の根拠になります。
第三に、違いが「意図した変更か」は、人にしか決められないから。
機械は違いを見つけますが、それが不具合か、顧客の依頼どおりの変更かは判断しません。ここに人の時間を集めます。
Playwrightのスクリーンショット比較で確認できたこと
2026年10月29日に、公式ドキュメント（playwright.dev の Installation、Visual comparisons、PageAssertions の toHaveScreenshot）で確認した内容です。
・導入：npm init playwright@latest、実行：npx playwright test、結果：npx playwright show-report
・比較：await expect(page).toHaveScreenshot()
・初回は基準画像がないためテストが失敗し、その時の画面が基準として保存される
・基準を更新するとき：npx playwright test --update-snapshots
・基準画像の名前には、ブラウザと実行環境（OS）が入る
・描画はOS、版、設定、ハードウェアなどで変わるため、基準を作った環境と同じ環境で実行するよう案内されている
・主な設定：
mask（指定した要素を塗りつぶして比較から外す）
maxDiffPixels（違ってよい画素の数）、threshold（色の違いの許容、既定0.2）
animations（既定は "disabled" で動きを止めて撮る）
fullPage（既定は false。ページ全体を撮るなら true）
stylePath（撮影のときだけ当てるCSS。動く要素を隠すのに使える）スライダー、日付、広告、お知らせの一覧のように毎回変わる部分は、mask か stylePath で外しておきます。外さないと、毎回「違いあり」になります。
Claude Codeに任せる部分、人が見る部分
【Claude Code】ページの一覧からテストのファイルを書く／動く要素の候補を挙げる／
失敗したテストの差分画像とログを読み、どの要素が変わったかを要約する
【人】基準画像を最初に目で確かめる／差分が意図した変更かを判断する／
基準の更新（--update-snapshots）を承認する基準の更新をAIに任せてはいけません。崩れた画面を基準にすると、以後の比較がすべて無意味になります。
今すぐ試せる：比較テストの雛形を作るプロンプト
私はWeb制作会社のエンジニアです。保守中のサイトに、Playwright のスクリーンショット比較を入れます。
（顧客名は伏せています）
【前提】
・比べるページ：〔URLの一覧〕
・毎回変わる要素：〔スライダー、日付、お知らせ一覧 など〕
・見る画面幅：〔スマホ・PC〕
1. 各ページで expect(page).toHaveScreenshot() を使うテストを書く。fullPage は true。
2. 毎回変わる要素は mask で外す。セレクタが分からないものは「要確認」と書き、推測で作らない。
3. 基準の更新は人が行う前提で、手順をコメントに書く。保守メニュー工場：月次の流れと時間の計算
初期（単発）：テストの作成、外す要素の調整、基準画像の確認と保存
毎回の更新後：テスト実行 → 差分の出たページだけ確認 → 意図した変更なら基準を更新
月次報告：実行日、比べたページ数、差分の件数、対応の記録計算例（数字はすべて例）：
今：更新のあとの目視 40ページ × 1.5分 ＝ 60分 ＝ 1時間／回
比較後：実行の待ちは別作業、差分の確認 4ページ × 5分 ＝ 20分／回
月2回の更新：(60 − 20) × 2 ＝ 80分 ≒ 1.33時間／月・サイト
初期の作成：3時間 × 7,645円（例）＝ 22,935円浮いた時間を保守の月額にどう返すかは、こちらで扱っています。
▶ 保守にClaude Codeを入れたら、月額はどう見直すか──値下げだけで返さず「範囲・速さ・一部還元」の3つから選ぶ、1サイトの原価の計算例
構造的なリスク
逆説を指摘しておきます。
比較を入れると、「テストが通ったから大丈夫」と考えるようになります。
しかし、比べているのは撮ったページと画面幅だけです。フォームの送信や、撮っていないページの崩れは拾えません。
だから、保守報告には「比べた範囲」を必ず書き、範囲の外は従来の確認を残します。
よくあるQ&A
Q. 担当者のPCとサーバーで結果が違うのはなぜか？
描画は環境で変わるため、公式は基準を作った環境と同じ環境で実行するよう案内しています。実行する場所を1つに決めます。
Q. WordPressの保守の手順のどこに入れるか？
ステージングでの更新のあと、本番に出す前の確認に入れます。
▶ Claude CodeでWordPressの保守を回す、制作会社の手順──更新前の調べ、ステージングでの検証、記録はAIに、本番に出す判断と目視は人に残す線の引き方
Q. 何ページを比べればよいか？
テンプレートごとに代表のページを選び、問い合わせなど売上に近いページを足します。
最後に
更新のたびの目視は、ページが増えるほど見落としと残業を生みます。
違いの発見を機械に任せ、意図した変更かの判断と基準の更新を人が担った会社だけが、確かめた記録の残る保守を、少ない時間で回せるのです。
テストの雛形と、保守報告の型は、計測・改善の自動化レシピ集にまとめました。
これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。
#Web制作会社 #ClaudeCode #Playwright #テスト自動化 #ビジュアルリグレッション #保守 #制作会社経営 #中小企業 #WordPress #AI駆動開発
