LPのスクショ比較で表示崩れを自動検知、レビュー負担を減らすWeb制作フロー

LPは修正のたびに「念のため確認」が増え、ディレクターのレビュー負担が膨らみやすい領域です。

しかも厄介なのが、表示崩れの多くが “意図せず起きる” こと。

• 余白が1つズレる
• ある画面幅だけボタンが折り返す
• フォントや行間の変化でファーストビューが崩れる
• 画像差し替えで高さが変わり、レイアウトが連鎖崩壊する

こういう事故は、コードレビュー（差分）だけでは見落としやすい。

そこで海外の現場で一般化しているのが、スクショ比較でUIの差分を自動検知する（Visual Regression Testing / VRT） という考え方です。

スクショ比較で表示崩れを検知する？

やることはシンプルです。

1. 変更前（または基準ブランチ）のスクリーンショットを 基準（ベースライン） として保存
2. PR/コミットごとに同じ画面を同条件で撮影
3. ピクセル差分を出して「見た目が変わった箇所」だけをレビュー対象として提示
4. 変更が意図したものか、人が承認してはじめて次へ進める

Playwrightはテストランナー内でスクショを生成し、ベースラインと比較する仕組みを公式に提供しています。「初回実行で参照用スクショを生成し、以降は比較する」という挙動が明記されています。

海外では、“レビューの一部自動化”が進んでいる

「CIにUIのチェックを入れる」「PRで見た目差分をレビューする」流れは、複数の主要サービスが“前提”として機能を作っています。

プルリクエストを止める：Chromaticの“必須チェック”

Chromaticは、GitHub等と連携するとPR上にステータスチェックを出し、視覚的変更が検出された／UI Reviewが必要な場合にチェックを“pending”にして、人のレビューが必要であることを明確にしています。^[1]

Storybook公式ドキュメント側でも、ChromaticをCIに組み込むとPRに「UI Tests」のチェックが付き、Gitプロバイダ側でrequired（必須）にして事故を防ぐことが推奨されています。^[2]

ここが重要で、「見た目の変更」が起きたら“とにかく誰かが見て承認しないとマージできない”状態に寄せられる。

“見た目の承認”をワークフロー化：Percyの承認フロー

Percy（BrowserStack）は、スクショ比較のレビュー/承認フローを持ち、承認するとPR/コミットのステータスが「All visual changes have been approved」になることをドキュメントで説明しています。^[3]

つまり「目視チェック」を属人化せず、承認が工程として残る設計です。

実装物（プレビュー）に直接コメント：Vercel / Netlifyの“ブラウザ上フィードバック”

VercelはPreview Deployments上で、Vercel Toolbarを通じてUI上にコメントスレッドを残せる機能を提供しています。

ドキュメントでは、プレビュー上でのフィードバックのための仕組みで、有効化がデフォルト・無料で使える一方、利用にはVercelアカウントが必要と明記されています。^[5]

NetlifyもDeploy Preview上でNetlify Drawerを使い、コメント／スクショ／動画などのフィードバックを“サイト上で”扱えることを公式ドキュメントで説明しています。^[6]

つまり海外では、「PRのコードレビュー」と「UI上の見た目レビュー」が別レーンで整備されつつある。

LP制作に落とすと、何が嬉しいのか（ディレクター視点）

LPでレビュー負担が増える理由は、変更量そのものより “確認範囲が広い” からです。

• 影響範囲が読めない（CSSの副作用）
• 画面幅が多い（PC/タブレット/スマホ）
• 画像・テキスト差し替えが頻繁
• クライアント要望が揺れる（差分が増える）

スクショ比較を入れると、レビューはこう変わります。

• 「全部を目視でなめる」→「差分が出た箇所だけ見る」
• 「レビュー漏れが怖い」→「差分が検知されるので安心」
• 「確認しました（口頭/Slack）」→「PR上で承認が残る」

レビュー工数が落ちるだけでなく、“承認ログが工程として残る” のが大きいです（後で揉めにくい）。

実務で破綻しない“LPスクショ比較”の運用設計

ここからが肝です。

ツール導入より先に、まずは 「何を自動にして、何を人が承認するか」 を決めます。

ルールA：差分検知は“守備範囲”を決める

LP全ページ・全状態を毎回撮ると、ノイズが増えます。最初は例えば：

• ファーストビュー
• CTA周辺
• 料金表／フォーム周辺
• サンクス導線

のように「壊れると致命傷な領域」から始めるのが現実的。

ルールB：比較条件を固定して“差分ノイズ”を減らす

VRTは条件がブレると差分が出続けます（=誰も見なくなる）。

• アニメーションを止める
• 日付/乱数/ABテスト表示など“変動要素”を無効化する
• フォント読み込み差を減らす（同環境で撮る）
• スクロール位置やviewportを固定する

ここをサボると、VRTはすぐ形骸化します。

ルールC：PRを止める（＝承認の強制）で初めて効く

「差分が出たけど、まあいいか」で流れる運用だと、ただの手間が増えるだけ。

Chromaticのように“視覚変化があればチェックがpendingになり、人がレビューするまで進めない”という設計が、事故防止として明文化されています。^[1]

具体的な実装パターン（海外で一般的な組み合わせ）

LP制作フローに落とすなら、現場では大きく3系統です。

パターン1：Storybook + Chromatic（コンポーネント中心のチーム向け）

• Storybookでコンポーネントの状態を整備
• Chromaticがスクショを撮り、プルリクエスト（PR）上で差分レビュー & チェックを提供
• 変更があれば人が承認しないと進めない（required checks運用が可能）^[1][2]

LPがコンポーネント化されている（共通CTA、フォーム、料金表など）制作体制なら強い。

パターン2：E2E（Playwright等）で“ページ”を撮る（LP直撃型）

• Playwrightで実ページ（Preview URLなど）にアクセス
• toHaveScreenshot() 等でベースラインと比較して差分検知^[4]
• 差分レポートをPRに出す（GitHub Actions等）

LPの“ページとしての崩れ”を取りたいならこの型がわかりやすい。

パターン3：Percy等のVRT SaaSで“承認”まで含める

• CIからスクショを上げ、差分レビューUIで承認
• 承認するとPR/コミットのステータスが更新される（承認が工程として残る）^[3]

それでも重要な人の目、Revoolでの最終レビュー承認

スクショ比較やPRチェックが強くなるほど、逆に現場では次の問題が出ます。

• 差分は分かるが、誰が何を直すか が別管理になりがち
• 承認はPR上に残るが、クライアントの指示・合意 と結びつかない
• “見た目”以外の指示（文言、要件、優先度、期限、差し戻し理由）が散らばる

つまり、VRTは 「見た目の変化を見逃さない」 には強いけど、「修正指示の運用ログ（担当・期限・進捗・差し戻し・最終承認）」 を一箇所に集約するのは苦手です。

Revoolが役立つのはここからです。

役割分担の結論

• VRT/PRチェック（Chromatic / Playwright / Percy等）：
  「見た目が変わった」という事実を検知し、レビューを強制する
• Revool：
  変更要求をタスクとして固定し、担当・期限・ステータス・差し戻し理由・最終OKを“運用ログ”として残す

自動検知（VRT）で“漏れ”を減らし、
Revoolで“運用”を破綻させない。
これが、変更量が増えるほど効く組み合わせです。

まとめ：LPのレビューは「全部見る」から「差分だけ見る」へ。その上でログを一本化する

LPは変更が増えるほどレビューが破綻します。
海外の現場では、PR/Previewに スクショ比較と承認を組み込み、UIレビューを工程化する流れが明確にあります。^[1][3][5][6]

ただし、見た目の差分検知だけでは、制作会社案件で必要な 修正指示の一元管理（担当・期限・進捗・差し戻し・最終承認） までは担えません。

だからこそ、

• 差分検知で“抜け漏れ”を減らし
• Revoolで“レビューと承認ログ（運用ログ）”を一本化する

という設計が、これからの「変更量が増えるWeb制作フロー」にフィットします。

Revoolでウェブ制作フローのレビューログを一元化してみませんか？

RevoolのChrome/Edge拡張機能 Revoolでは、画面キャプチャ撮影から修正指示付きのタスク投稿ができる拡張機能を提供しています。Revoolのアカウントなしのゲストモードで、指示コメントを書き込んだキャプチャを保存することもできます。

参照リンク