AIブラウザ検証がホームページやShopifyサイトの表示崩れを自動チェックできる件について

ホームページやLP、Shopifyサイトを更新したあと、「PCでは問題ないのにスマホでCTAが崩れていた」「商品ページの一部だけアプリの表示が重なっていた」といった事故は珍しくありません。公開前に全部のページを目視で確認できれば理想ですが、実務では時間が足りません。

そこで使えるのが、AIブラウザ検証です。AIブラウザ検証とは、Playwrightなどのブラウザ自動操作ツールでページを巡回し、スクリーンショット差分やJSエラーを集め、必要に応じてAIに差分の意味を読ませる運用です。人の確認をなくす仕組みではありません。人が見るべき場所を絞るための仕組みです。

この記事では、LP、WordPress/SWELL、Shopifyを対象に、何を自動チェックできるのか、何は人の目が必要なのか、Claude CodeとPlaywright MCPを組み合わせる場合の考え方まで整理します。

AIブラウザ検証でできること

AIブラウザ検証の基本は、ブラウザを自動で開き、指定したページを見に行き、スクリーンショット、コンソールログ、ページエラー、主要ボタンの反応を記録することです。Playwrightの公式ドキュメントでも、「toHaveScreenshot()」によるスクリーンショット比較が説明されています。

出典: Playwright Visual comparisons

たとえば、昨日のLPと今日のLPを同じ条件で撮影し、ファーストビューの見出しが消えていないか、CTAボタンが折り返していないか、スマホ幅で余白が崩れていないかを差分として自動で拾えます。さらにPlaywrightのPage APIでは、ページエラーやコンソールメッセージを取得するAPIも提供されています。

出典: Playwright Page API

一方で、ブランドらしい余白か、写真の印象が良いか、キャッチコピーが弱くないか、差分が売上に影響するほど重大かは、最後に人が判断する必要があります。AIは検知と要約の補助役であり、公開判断の責任者ではありません。

LP、WordPress、Shopifyで見る場所は違う

同じAIブラウザ検証でも、LP、WordPress、Shopifyで見るべき重点は別物です。LPでは広告流入直後の印象とCV導線を見て、WordPressではテーマ更新やプラグイン更新の影響を確認します。Shopifyでは商品ページ、カート、テーマ編集、アプリ挿入箇所を中心に、変更前後の差分を追います。

対象	重点チェック	自動化の入口
LP	ファーストビュー、CTA、フォーム、スマホ表示	公開前と広告配信前にスクショ差分
WordPress/SWELL	ヘッダー、固定ページ、投稿テンプレート、プラグイン更新後	更新前後の代表ページ巡回
Shopify	商品ページ、カート、テーマ編集、アプリ表示	development themeと本番テーマの差分確認

Shopifyの場合、Theme CheckはLiquidやJSONの静的チェックには有効ですが、実際の表示崩れを画面上で見てくれるものではありません。Shopify CLIでdevelopment themeを使い、Theme Checkでコード側、Playwrightでブラウザ表示を見る三層に分けると実務に乗せやすくなります。

出典: Shopify Theme Check

出典: Shopify CLI for themes

Shopifyのテーマ選びやアプリ追加で迷っている場合は、先にShopifyのテーマ選びの考え方を整理してから、変更前後の検証項目を作ると無駄が減ります。売上が伸びないECでは、表示崩れだけでなく導線そのものの問題もあるため、ネットショップが売れない原因も合わせて確認しておくと判断しやすくなります。

小さく始めるなら三層チェックで十分

最初から全ページ、全ブラウザ、全デバイスを対象にすると運用が続きません。中小企業のサイト保守では、まず三層に分けると現実的です。第一層はスクリーンショット差分、第二層はJSエラー、第三層は人間レビューと分けます。

ホームページ保守の費用対効果を見直すなら、AIブラウザ検証は「毎月の作業報告に何を残すか」とセットで考えるべきです。保守費用の考え方はHP保守費用の内訳と見直しポイントでも整理しています。

Claude CodeとPlaywright MCPで何が変わるか

Playwrightだけでも検証は可能です。ただ、検証対象ページの追加、差分の説明、担当者向けの報告文作成まで含めると、AIエージェントとの組み合わせが実務向きです。MicrosoftのPlaywright MCPは、Playwrightによるブラウザ自動操作を提供するMCPサーバーです。

出典: Microsoft Playwright MCP

Claude Code側もMCP経由で外部ツールやAPIに接続できます。つまり、AIに「この5ページをPCとスマホで開いて、スクショ差分とJSエラーを確認して」と依頼し、結果の要約まで作る運用が組めます。ただし、MCPサーバーは外部コンテンツを扱うため、信頼できるサーバーか、権限を広げすぎていないかを必ず確認してください。

出典: Claude Code MCP

非エンジニアがいきなり設定まで全部やるより、最初は制作会社や保守担当が検証リストを作り、担当者は実行結果を見る形が安全です。制作会社との認識ずれを減らすには、制作会社とのトラブルを防ぐ伝え方のように、変更前後の確認範囲を文章で残すことも大切です。

誤検知を減らすには固定化が必要

スクリーンショット差分は便利ですが、ノイズも出ます。毎回変わりやすい要素をそのまま比較すると、毎回差分が出てしまい、見るべき崩れが埋もれます。

Playwright公式には、スクリーンショット比較はOSやブラウザ、フォント、実行環境の違いで結果が変わるという説明があるため、基準画像を作る環境と毎月チェックする環境をそろえることが重要です。CIで回す場合も同じで、実行環境を固定し、必要に応じてworkersを抑えるなど、再現性を優先します。

出典: Playwright Continuous Integration

よくある運用は、動的要素をCSSで隠す、許容差分を設定する、比較対象ページを代表ページに絞る、差分が出た箇所だけAIに要約させる、という流れです。AIが「これはヘッダーの崩れ」「これは在庫数の違い」と分類してくれれば、人が見るべき差分だけに集中できます。

公開前チェックと月次保守の回し方

AIブラウザ検証は、公開前チェックと月次保守で役割が変わります。公開前チェックでは変更したページと関連する導線を重点的に見て、月次保守では代表ページ、JSエラー、フォームやカートを定点観測します。

タイミング	見るもの	人が判断すること
公開前	変更ページ、CTA、フォーム、カート	意図したデザインになっているか
更新後	テーマ、プラグイン、アプリ影響範囲	軽微な差分を許容するか
月次保守	代表ページ、JSエラー、主要導線	改善提案につなげるか

古いホームページをリニューアルする場合は、公開直後だけでなく、公開後1週間、1か月後にも同じ検証を走らせると安心です。リニューアル時期の判断は古いホームページのリニューアル時期でも詳しく整理しています。URLを変える場合は、301リダイレクトと302リダイレクトの違いも確認してください。

外注先に検証を依頼する場合は、「どのページを、どの画面幅で、どのタイミングで、何をもってOKとするか」を最初に必ず確認してください。制作会社選びの段階なら、良いWeb制作会社を見分ける質問集のように、検証体制を質問に入れておくと失敗しにくくなります。

AIブラウザ検証を入れても人が見るべき場所

AIブラウザ検証を入れるほど、人のレビューは不要になるのではなく、むしろ判断の質が問われます。差分が出たときに「これは問題ない」「これは今すぐ直す」「これは次回改善に回す」と決めるのは人です。

つまり、AIブラウザ検証の価値は、担当者が全部のページを見ることではなく、担当者が見るべきページを絞れることにあります。これは保守作業の効率化であり、同時に制作品質の見える化でもあります。

ノーサイドでは保守運用に組み込んだ検証設計ができます

ノーサイドでは、ホームページ、WordPress/SWELL、Shopify、LPの制作や保守に合わせて、公開前チェックや月次点検に組み込める検証設計を行えます。AIブラウザ検証は、単体の便利ツールとして入れるより、どのページを守るか、誰が判断するか、どのタイミングで報告するかまで設計したほうが効果が出ます。

「更新のたびに表示確認が不安」「Shopifyのアプリ追加後に崩れないか見てほしい」「保守報告をもっと分かりやすくしたい」という場合は、ノーサイドへご相談ください。既存サイトの状況を見たうえで、必要な検証範囲から一緒に整理します。

よくある質問