
移行後の検証、Playwrightで「旧サイトと同じか」を確かめる──転送・画面・フォーム・計測タグの4つの確認、公式で確かめた機能、目視と自動の分け方と計算例
この記事は、サイト移行の後の検証を、Playwrightで旧サイトと新サイトを比べながら進める方法を扱います。
「公開しました」の3日後に、フォームが届いていなかった
移行したサイトを公開し、トップと主要ページを目で確かめた。
3日後、お客様から「問い合わせが1件も来ていない」と連絡がありました。
フォームは画面上では送れていました。届け先の設定だけが、旧サイトのまま残っていたのです。
目で見る検証は、見た目が同じかは分かっても、裏で動くものの抜けは拾えません。
移行後の検証とは、旧サイトで動いていたことの一覧を先に作り、新サイトで同じように動くことを、自動と目視に分けて記録を残す作業である
黒字化の外科医です。移行後の検証を、納品の品質の証拠として解剖します。
一覧から検証すべき理由は、三つあります。
第一に、移行で壊れやすいのは、見えない部分だから。
転送、フォームの届け先、計測タグは、画面を開いただけでは確かめられません。
第二に、同じ確認を、公開の前と後で何度も繰り返すから。
公開前の検証環境、公開の当日、公開の翌週。手作業だと毎回同じ時間がかかります。
第三に、記録が残れば、責任の線が引けるから。
「公開の時点で、この項目は動いていた」と示せれば、後から起きた不具合の原因を切り分けやすくなります。
自動テストを見積もりと月額に載せる考え方は、こちらで扱いました。この記事は、それを移行の検証に絞った形です。
▶ テスト自動化(Playwright等)を見積もりに入れる制作会社へ──「タダの社内作業」にせず、初期構築と月額の回帰テストに分けて売る手順と、手作業との比べ方の計算例
Playwrightの公式ドキュメントで確認したこと
2026年10月29日に、Playwrightの公式ドキュメント(Visual comparisons、Network、PageAssertions、APIRequestContext、APIResponse)で確認した内容です。
画面の比較(toHaveScreenshot)
・初回の実行で基準の画像を作り、2回目以降はそれと比べる
・ページを変えたときは --update-snapshots で基準を作り直す
・maxDiffPixels(違ってよい画素数)、threshold(色の違いの許容、初期値0.2)を指定できる
・mask で変わる部分を隠せる。animations は初期値で止める設定
・表示はOS・版・設定・機器で変わるため、基準を作った環境と同じ環境で実行するよう案内されている
通信の確認
・page.on('request') で、ページが出した通信を記録できる
・page.waitForResponse で、特定の通信の応答を待てる
・page.route で、通信を差し替えたり止めたりできる
転送の確認
・request の get などで maxRedirects に 0 を渡すと、転送を追わない
・応答の status() で状態コード、headers() で応答ヘッダーを読める今すぐ試せる:検証の一覧を作るプロンプト
私はWeb制作会社のディレクターです。サイト移行後の検証の一覧を作ってください。
(顧客名や個人情報は入力しません)
【材料】
・旧サイトのURL一覧とURL対応表:〔貼り付け〕
・フォーム、検索、外部サービス、計測タグの一覧:〔記載〕
・公開の予定日と、検証環境の有無:〔記載〕
1. 確認項目を「転送」「画面」「フォーム」「計測タグ」に分ける。
2. 各項目を「Playwrightで自動にする」「人が目で見る」に分け、理由を書く。
3. フォームは、本番で実際に送ってよいか、検証環境で確かめるかを質問の形で挙げる。
4. 公開前・公開当日・公開の翌週のどの時点で実行するかを表にする。検証工場:4つの確認とテストの雛形
1. 転送(URL対応表の全件)
import { test, expect } from '@playwright/test';
const map = [
{ from: '/old/about.html', to: '/about' },
// URL対応表から貼り付ける
];
test('旧URLの転送', async ({ request }) => {
for (const r of map) {
const res = await request.get(r.from, { maxRedirects: 0 });
expect([301, 308]).toContain(res.status());
expect(res.headers()['location']).toContain(r.to);
}
});転送先の先でさらに転送されていないか、転送先のURLでも同じ確認を回します。
2. 画面(見た目を変えない移行の場合)
test('トップの見た目', async ({ page }) => {
await page.goto('/');
await expect(page).toHaveScreenshot('top.png', {
fullPage: true,
mask: [page.locator('〔お知らせの日付など、変わる部分〕')],
maxDiffPixels: 〔許容する画素数〕,
});
});旧サイトに向けて基準の画像を作り、同じ名前で新サイトに向けて比べます。
デザインも変える移行では、画面の比較は公開の後の「崩れの見張り」に使い、旧新の比較は人が目で見ます。
3. フォーム
・検証環境:テスト用の宛先に実際に送り、届いた内容と自動返信を人が確かめる
・本番:送信は人が1回だけ行い、届いたことをお客様と確かめる
・入力チェック(必須・形式)の表示は、自動テストで確かめる4. 計測タグ
test('計測タグの送信', async ({ page }) => {
const sent = page.waitForResponse(res => res.url().includes('〔送信先のURLの一部〕'));
await page.goto('/');
await sent;
});送信先のURLは、ブラウザの開発者ツールで旧サイトの通信を見て、実際のものを入れます。
計算例:手作業と自動の比べ方(数字はすべて例)
手作業:画面30 × 旧新2回 × 5分 = 300分 = 5時間
転送120URL × 1分 = 120分 = 2時間
1回の検証:5 + 2 = 7時間 × 3回(公開前・当日・翌週)= 21時間
自動化:構築10時間 + 結果の確認1時間 × 3回 = 13時間
構築の費用:10時間 × 7,645円(例)= 76,450円手作業の差は 21 − 13 = 8時間です。移行が1回きりなら差は小さく、公開後の保守で回し続けるほど差が広がります。
構造的なリスク
逆説を指摘しておきます。
自動テストが全部通ると、検証が終わった気になります。
しかし、テストが確かめるのは、書いた項目だけです。一覧から抜けた機能は、通っても守られていません。
だから、最初の一覧づくりに時間をかけ、目視の項目と、確かめた日と人を記録に残してください。
よくあるQ&A
Q. 画面の比較で、毎回わずかな違いが出て落ちる。
表示は環境で変わると公式も書いています。基準を作った環境と同じ環境で実行し、変わる部分は mask で隠します。
Q. 検証の記録は、お客様に渡すべきか?
納品報告に添えると、何を確かめて渡したかが残ります。報告の型は、こちらにまとめています。
Q. 検証で見つかった旧サイトからの不具合は、誰が直すか?
契約の範囲で決まります。既存不具合の扱いは、移行の契約の記事で扱いました。
▶ 移行案件の契約不適合責任、「旧サイトの不具合」まで背負わない──移す範囲、既存不具合の扱い、「現状と同等」の決め方。e-Govで確かめた民法の条文と、契約書に足す文例
最後に
移行後の検証は、旧サイトで動いていたことの一覧から始まります。
転送・画面・フォーム・計測タグを、自動と目視に分けて記録を残した会社だけが、公開の後に「届いていなかった」と言われずに済むのです。
検証チェックの全項目は、受注キットにまとめました。
▶ レガシー移行の受注キット、jQuery・古いWordPressからNext.jsへ──調査票、Claude Codeの調査指示書、工程別の見積表、移行計画書、検証チェック40項目、契約の確認点
これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。
#Web制作会社 #Playwright #サイト移行 #テスト自動化 #検証 #リダイレクト #制作会社経営 #中小企業 #品質管理 #レガシー移行