AIでWordPress更新前後の画面を自動比較する方法｜Playwright入門

WordPressやテーマを更新した後、トップページは正常でも、スマートフォンの予約ボタンだけが隠れたり、客室ページの表だけが横へはみ出したりすることがあります。

毎回すべてのページを手作業で開くのは大変です。そこで、ブラウザを自動操作できるPlaywrightを使うと、決めたURLを同じ画面幅で撮影し、更新前の画像と更新後の画像を比較できます。

この記事では、宿主さんがPlaywrightのコードを暗記するのではなく、CodexやClaude Codeへ準備と反復作業を手伝わせ、人が合格基準と予約情報を確認する方法を説明します。

結論：AIに任せるのは撮影と差分整理、人が決めるのは正常な見本
Playwrightとは
画面比較で発見しやすい問題
最初は5ページ・3画面幅で十分
初心者が用意するもの
AIへ最初に確認させること
Playwrightの最小構成
テストコードの考え方
基準画像を作るときの注意
毎回変わる部分が差分になる
1. 対応方法
同じ環境で撮影する
差分が出たときの読み方
AIへ画像差分を調べさせる
Basic認証・ログイン画面の扱い
スクリーンショットへ写してはいけないもの
画面比較だけで合格にしない
コピペ用プロンプト1：まだ導入せず計画する
コピペ用プロンプト2：検証環境へ作成する
コピペ用プロンプト3：更新後の差分を調査する
完了チェックリスト
まとめ
参考資料

結論：AIに任せるのは撮影と差分整理、人が決めるのは正常な見本

画面比較の基本は次の流れです。

重要URLと画面幅を決める
  ↓
更新前の正常画面を基準画像として保存
  ↓
検証環境で一つだけ更新
  ↓
同じ条件で更新後を撮影
  ↓
PlaywrightとAIが差分を整理
  ↓
人が予約・料金・使いやすさを確認

AIは違いを速く見つけられます。しかし、更新前の画面自体が間違っていたら、その間違いを基準にしてしまいます。「この画面が正常」と決める作業は宿主と保守担当者に残します。

Playwrightとは

Playwrightは、Chromium、Firefox、WebKitなどのブラウザを自動操作するためのツールです。ページを開く、ボタンを押す、画面幅を変える、スクリーンショットを保存する、といった操作を繰り返せます。

Playwright公式のVisual comparisonsでは、最初に基準スクリーンショットを作り、後の実行画像と比較する方法が案内されています。Screenshotsでは、表示中の範囲だけでなくページ全体を保存できます。

PlaywrightはWordPress専用ではありません。宿の公式サイト、静的ページ、予約案内など、ブラウザで開ける画面の確認に使えます。

画面比較で発見しやすい問題

ヘッダーメニューの位置・折り返し
ロゴや写真の縦横比
見出し、本文、サイドバーの重なり
表や長いURLの横はみ出し
予約ボタンが別部品に隠れる問題
スマートフォンメニューが開かない状態
画像、地図、動画の表示漏れ
フォント変更による改行・高さの変化
Cookie案内が画面を覆う問題

一方、スクリーンショットだけでは、フォーム送信、予約在庫、決済、メール受信、料金の正しさまでは確認できません。

最初は5ページ・3画面幅で十分

全ページから始めると、差分の確認だけで疲れてしまいます。まず予約に近い5ページを選びます。

トップページ
客室・料金
予約案内
問い合わせ
アクセス

画面幅は次を一例にできます。

想定	幅の例	見つけたい問題
パソコン	1440px	横並び、メニュー、サイドバー
タブレット	768px	レイアウトが切り替わる途中の崩れ
スマートフォン	390px	横はみ出し、ボタン、モバイルメニュー

PlaywrightのEmulationでは、画面サイズ、端末、色設定などを再現できます。ただし実際のスマートフォンにはブラウザUI、文字設定、通信速度などの違いがあるため、最後は実機でも確認します。

初心者が用意するもの

VS Codeで開けるテスト専用フォルダ
CodexまたはClaude Codeを使える環境
確認対象の公開URLまたは保護された検証URL
正常だと判断できる更新前画面
実行結果を確認する人

フォルダを開く意味や拡張機能の導入が分からない場合は、先に宿主さんのためのVS Code入門を確認してください。

本番サイトのテーマフォルダへ直接テストを置く必要はありません。サイト運用用とは別のテストフォルダに置き、何を実行するか確認できる状態にします。

AIへ最初に確認させること

Playwrightを導入する前に、AIへ次を調べさせます。

既にNode.jsやPlaywrightが使われているか
既存のテストや設定ファイルがあるか
対象は本番かステージングか
Basic認証などアクセス制限があるか
ログインしなくても確認できるページはどれか
スクリーンショットへ個人情報が写らないか
基準画像とテスト結果をどこへ保存するか
既存ファイルや設定へ影響しないか

AIに「とりあえずインストールして」と頼まず、変更されるファイル、必要容量、削除方法を先に示してもらいます。

Playwrightの最小構成

公式のInstallationでは、Playwright Testのプロジェクトを作り、必要なブラウザを導入する流れが案内されています。

AIに作成を依頼すると、一般的には次のような構成になります。

website-check/
├─ package.json
├─ playwright.config.js
├─ tests/
│  └─ visual.spec.js
└─ tests/visual.spec.js-snapshots/
   └─ 基準画像

ファイル名や保存場所は環境により異なります。基準画像は「合格と判断した画面」なので、勝手に毎回作り直さず、変更理由と承認者を記録します。

テストコードの考え方

次は仕組みを理解するための架空サイト用の例です。そのまま本番へ実行する前に、AIや担当者へ自分の環境に合わせてもらってください。

import { test, expect } from '@playwright/test';

test('トップページのスマートフォン表示', async ({ page }) => {
  await page.setViewportSize({ width: 390, height: 844 });
  await page.goto('https://example.com/', { waitUntil: 'networkidle' });
  await expect(page).toHaveScreenshot('home-mobile.png', {
    fullPage: true,
  });
});

このテストは、指定URLを390px幅で開き、ページ全体を基準画像と比較する考え方を示しています。

基準画像を作るときの注意

最初の実行で作られた画像が、自動的に正しいとは限りません。

人が公開ページを確認する
宿名、料金、写真、予約先が正しいか確認する
PC・スマホの見た目を確認する
その画像を基準として承認する
承認日と確認者を記録する

間違った料金、古い予約ボタン、既に崩れたレイアウトを基準にしないでください。

毎回変わる部分が差分になる

画面比較では、問題でなくても変わる部分があります。

今日の日付と天気
空室・料金・残室数
スライドショーや動画
SNS埋め込み
アクセス数・ランキング
ランダム表示の記事
Cookie案内
Webフォントの読み込み時間
カーソルやアニメーション

これらを放置すると、テストのたびに失敗します。

対応方法

動きが止まってから撮影する
アニメーションを検証時だけ無効にする
日付や在庫など変動部分をマスクする
Cookie案内の状態を固定する
本番データではなく安全な検証データを使う
ページ全体でなく重要な部品だけ比較する

差分を減らす設定は、問題を隠すためではありません。「毎回変わる正常部分」と「更新で変わった異常部分」を分けるために使います。予約ボタン自体をマスクして確認対象から外さないよう注意してください。

同じ環境で撮影する

Playwright公式資料では、スクリーンショットはOS、ブラウザ、設定、ハードウェアなどで異なる場合があると説明しています。

比較するときは次を揃えます。

Playwrightとブラウザのバージョン
OSまたは実行環境
画面幅と高さ
フォント
言語・タイムゾーン
色設定
ログイン状態
URLとテストデータ

宿主のPC、制作会社のPC、サーバー上で別々に撮影すると、小さな文字差が大量に出る場合があります。定期実行する場所を一つ決めます。

差分が出たときの読み方

差分は、次の3種類に分けます。

判定	例	対応
問題	ボタン消失、重なり、横はみ出し	追加更新を止めて原因調査
意図した変更	新しい見出し、承認済みデザイン	人が確認後に基準画像を更新
判断保留	フォント、動的在庫、外部埋め込み	条件を揃えて再確認

テストを通すためだけに基準画像を更新してはいけません。何が変わったか説明し、宿主が承認した後に更新します。

AIへ画像差分を調べさせる

AIには次を報告させます。

失敗したURLと画面幅
変化した位置
消えた・増えた・移動した部品
予約や問い合わせへの影響
意図した変更の可能性
HTML、CSS、JavaScriptの原因候補
修正前に追加確認すること

画像だけで原因を断定させず、ブラウザエラー、読み込み失敗、変更ファイルも確認します。Trace Viewerを使うと、テスト中の操作、画面、ネットワーク等を追える場合があります。トレースへ認証情報や個人情報を保存しないよう、対象ページと保存期間を決めてください。

Basic認証・ログイン画面の扱い

ステージングがBasic認証で保護されている場合、AIやテストへ認証情報を渡す経路が必要になります。

パスワードをコードへ直接書かない
Gitやスクリーンショットへ含めない
環境変数など安全な保存方法を使う
ログへ認証ヘッダーを出さない
作業者と有効期間を限定する

WordPress管理画面や予約者情報が見えるページから始めず、まず一般公開ページだけをテストします。WordPressログインのBASIC認証・2段階認証も参照してください。

スクリーンショットへ写してはいけないもの

予約者名、メールアドレス、電話番号
問い合わせ本文
管理画面のユーザー一覧
APIキー、決済情報、バックアップコード
非公開料金や契約情報
ブラウザのパスワード通知

テスト結果やトレースをAIへ渡す前に、個人情報と秘密情報がないか確認します。公開ページでも、予約確認URLに個人情報が含まれる場合は対象にしません。

画面比較だけで合格にしない

スクリーンショットが一致しても、次は別途確認します。

予約ボタンが正しい施設・プランへ進む
問い合わせを送信できる
宿側通知と自動返信が届く
電話番号と地図が正しい
料金・休館・看板猫情報が最新
キーボードや読み上げでも操作できる
実際のスマートフォンで押しやすい

画面比較は表示崩れの検査であり、宿の営業情報や機能全体の保証ではありません。

コピペ用プロンプト1：まだ導入せず計画する

宿のWordPress更新前後をPlaywrightで画面比較したいです。
私はITに詳しくありません。まだインストールやファイル変更はしないでください。

読み取りだけで次を確認し、導入計画を作ってください。
- Node.js、Playwright、既存テストの有無
- 追加・変更されるファイルと必要容量
- テスト専用フォルダと削除方法
- 最初に確認する5ページ
- PC 1440px、タブレット768px、スマートフォン390pxの撮影方法
- 日付、在庫、スライドなど毎回変わる部分
- 個人情報や認証情報が写る危険
- 基準画像を人が承認する手順
- 更新後の差分報告形式

本番サイト、WordPress、予約、決済は変更しないでください。
不明点は推測せず、実行前に私へ確認してください。

コピペ用プロンプト2：検証環境へ作成する

承認済みのテスト専用フォルダへ、Playwrightの画面比較を作成してください。
本番WordPressやテーマのファイルは変更しないでください。

対象は検証環境の一般公開ページだけです。
- トップ
- 客室・料金
- 予約案内
- 問い合わせ
- アクセス

PC 1440px、タブレット768px、スマートフォン390pxで撮影してください。
動的部分は一覧にし、何を待機・固定・マスクするか変更前に説明してください。
予約ボタンと問い合わせ導線は確認対象から外さないでください。

基準画像は自動承認せず、私が確認するまで候補として保存してください。
最後に追加ファイル、実行方法、削除方法、秘密情報の有無を報告してください。

コピペ用プロンプト3：更新後の差分を調査する

検証環境で一つの更新を行った後のPlaywright結果を調べてください。
まだ修正、追加更新、基準画像の更新、本番反映はしないでください。

失敗を次に分けてください。
- 問題
- 意図した変更の可能性
- 動的表示などによる判断保留

各差分についてURL、画面幅、変化した位置、予約導線への影響、
HTML・CSS・JavaScriptの原因候補、追加確認を示してください。
個人情報や認証情報を出力しないでください。

最後に、人が確認する画像とURL、修正案、戻し方を報告してください。