メインコンテンツへスキップ
見出し画像

移行後の検証、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. 検証の記録は、お客様に渡すべきか?


    納品報告に添えると、何を確かめて渡したかが残ります。報告の型は、こちらにまとめています。

    ▶ AI駆動開発の納品前チェックリスト、品質を「確かめた記録」で渡すキット──レビュー・テスト・セキュリティ・ライセンス・ドキュメントの確認項目50、判定の記録表、例外の記録、顧客向け納品報告書、チェック工数の計算例


    Q. 検証で見つかった旧サイトからの不具合は、誰が直すか?


    契約の範囲で決まります。既存不具合の扱いは、移行の契約の記事で扱いました。

    ▶ 移行案件の契約不適合責任、「旧サイトの不具合」まで背負わない──移す範囲、既存不具合の扱い、「現状と同等」の決め方。e-Govで確かめた民法の条文と、契約書に足す文例

    最後に

    移行後の検証は、旧サイトで動いていたことの一覧から始まります。


    転送・画面・フォーム・計測タグを、自動と目視に分けて記録を残した会社だけが、公開の後に「届いていなかった」と言われずに済むのです。


    検証チェックの全項目は、受注キットにまとめました。

    ▶ レガシー移行の受注キット、jQuery・古いWordPressからNext.jsへ──調査票、Claude Codeの調査指示書、工程別の見積表、移行計画書、検証チェック40項目、契約の確認点

    これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。


    #Web制作会社 #Playwright #サイト移行 #テスト自動化 #検証 #リダイレクト #制作会社経営 #中小企業 #品質管理 #レガシー移行

     
     
    Web制作・開発会社の「労働集約という病」をAIで冷徹に切除し、利益率を極限化する組織ハッキング術を公開。 人間の感情と作業を排除し、社長一人で莫大な富を搾取する「完全無人ファクトリー」を構築する覚悟を持つ経営者のみ、有料記事で圧倒的な暴利と勝利を手に入れてください。

    あなたへのおすすめ