AI Browser Testing Tips EN

Shopifyテーマ改修後のAIを使ったブラウザ確認のポイント

Shopifyのテーマを改修した後、「どこか壊れていないか」の確認をAIに任せることができます。ClaudeやCodexなど主要なAIツールはChrome拡張を通じてブラウザを直接操作できるので、ページを開いて・スクロールして・クリックして・確認する、という作業をそのままやらせることができます。

本記事では、Shopifyストアのブラウザテストにどう使えるか、実際に動くプロンプト例とともに紹介します。

AIがChromeを操作するとはどういうことか

AIがChromeを操作してShopifyストアを確認する流れ

Claude(Claude in Chrome拡張)やCodex(Chrome拡張)は、Chrome拡張を通じてブラウザを操作できます。ストアテストに使う場合、AIは次のことをやります:

  • 実際にページを開いて、レンダリングされた画面を「見る」
  • スクロールして、画面外の要素を確認する
  • クリック・入力・ウィンドウサイズ変更などの操作を実行する
  • 気になる点を言語化して報告する

Chrome拡張経由で動くため、普段使っているChromeのセッションやCookieがそのまま使われます。ログイン済みのストアプレビューにもそのままアクセスできます。

DOMの存在確認だけでなく、実際に画面として表示された状態を評価できるのが従来の自動テストとの大きな違いです。

使えるプロンプト例

用途ごとの確認プロンプト例

購入フロー確認

テーマ改修後に最初に走らせる基本テストです。

Shopifyストア(https://xxx.myshopify.com)の購入フローを確認してください。

以下の順番で実際に操作し、各ステップで気になる点があれば指摘してください:

1. トップページを開き、レイアウト・ヘッダー・フッターに問題がないか確認
2. コレクションページで商品一覧を確認(画像の読み込み・価格表示・グリッドの崩れ)
3. 商品詳細ページを開く(画像・バリアント選択・カートボタンの視認性)
4. カートに追加し、カートページを確認(商品情報・数量・合計金額の表示)
5. チェックアウトに進む(この先は操作せず、画面の状態だけ確認)

特に以下の観点で確認してください:
- ボタン・リンクが視覚的に押せる状態か(色・サイズ・重なり)
- テキストが読める色・サイズか
- 画像が正しく読み込まれているか
- モバイル幅(390px)でレイアウトが崩れていないか

※チェックアウトページは操作不要です。表示確認のみ。

テーマ改修後の差分確認

特定のブロックや機能を追加した後に使えます。「追加したものが表示されているか」「既存のレイアウトに干渉していないか」を確認できます。

テーマを改修したので、以下のページで問題が出ていないか確認してください。

改修内容:商品ページにコレクションリンクブロックを追加しました。

確認ページ:https://xxx.myshopify.com/products/sample-product

確認ポイント:
1. 追加したコレクションリンクが表示されているか
2. ラベル「この商品を含むコレクション」とリンクボタンが正しく出ているか
3. 既存のレイアウト(商品画像・タイトル・価格・カートボタン)に干渉していないか
4. モバイル幅(390px)で崩れていないか
5. コレクションリンクをクリックして正しいページに遷移するか

レスポンシブ確認

PC・モバイル両方の幅での表示確認に使えます。

以下のページをPC・モバイル両方の幅で確認し、レイアウト崩れを報告してください。

URL:https://xxx.myshopify.com/collections/all

確認手順:
1. ウィンドウ幅 1280px で全体を確認
2. ウィンドウ幅 390px(iPhone相当)に変更して再確認
3. 両方で以下を確認:
   - ナビゲーションが使えるか(ハンバーガーメニューの動作含む)
   - 商品グリッドが正しく並んでいるか
   - テキストがはみ出していないか
   - 商品画像が正しいアスペクト比で表示されているか
   - フィルターや並べ替えのUIが操作できる状態か

フォーム操作確認

お問い合わせページなど、フォームが絡む画面の確認に使えます。

お問い合わせフォームページ(https://xxx.myshopify.com/pages/contact)を確認してください。

1. フォームが視覚的に正しく表示されているか
2. 必須項目の区別が分かりやすいか
3. 各フィールドに実際に入力して、フォーカス時のUI変化(枠の色変わり等)を確認
4. 空欄のまま送信ボタンを押し、バリデーションエラーが正しく表示されるか
5. エラーメッセージが目立つ場所に出ているか

※実際の送信はしないでください。バリデーション確認まで。

ナビゲーション・リンク切れ確認

メニュー構造を変更した後や、新しいページを追加した後に使えます。

サイトのナビゲーションをすべて確認してください。

対象:https://xxx.myshopify.com のヘッダーメニュー

確認内容:
1. ヘッダーの各メニュー項目をクリックして、正しいページに遷移するか
2. ドロップダウンがある場合、その中の項目も全て確認
3. モバイル幅(390px)でハンバーガーメニューを開いた状態で同様に確認
4. 404になるリンクがあれば報告

フッターのリンクも同様に確認してください。

テストレポートの生成

一連の確認が終わったら、最後にレポートを生成させることができます。確認内容・問題点・推奨対応が整理された状態で残るので、チームへの共有や次回改修時の参照に使えます。

ここまで確認した内容をもとに、以下の形式でテストレポートをまとめてください。

---
## 表示テストレポート

**実施日時**:(本日の日時)
**テスト対象**:https://xxx.myshopify.com
**改修内容**:(確認の背景・何を変更したか)

### 確認結果サマリー
| 確認項目 | 結果 | 備考 |
|---|---|---|
| トップページ表示 | ✅ / ⚠️ / ❌ | |
| コレクションページ | ✅ / ⚠️ / ❌ | |
| 商品詳細ページ | ✅ / ⚠️ / ❌ | |
| カート操作 | ✅ / ⚠️ / ❌ | |
| レスポンシブ(モバイル) | ✅ / ⚠️ / ❌ | |
| ナビゲーション | ✅ / ⚠️ / ❌ | |
| フォーム | ✅ / ⚠️ / ❌ | |

### 発見した問題
(問題がない場合は「問題なし」と記載)

| 重要度 | 問題の内容 | 該当ページ / 箇所 |
|---|---|---|
| 🔴 高 | | |
| 🟡 中 | | |
| 🟢 低 | | |

### 推奨対応
(修正が必要な項目と対応方針を箇条書きで)

### 次回確認時の注意点
(今回確認できなかった範囲や、次回テスト時に重点的に見るべき点)
---

こんな問題が見つかる

画面を見ないと見つけにくい問題

「Playwrightでは全部グリーンだったのに」という問題が見つかることがあります。

z-index の重なりでボタンが押せない
DOM上はボタンが存在し、クリックイベントも発火するのに、実際の画面では別の要素が上に被さっていて押せない状態になっているケースがあります。スクリーンショットを見て初めて気づける問題です。

モバイルでカートボタンがフッターに隠れている
スティッキーフッターがカートに追加ボタンと被っていて、モバイルでは実質押せない状態になることがあります。PC幅では全く問題なく、自動テストでも検出できません。

フォントカラーが背景と同化している
特定のカラースキームで、テキストカラーと背景色がほぼ同じになるケースがあります。テキストは存在するので自動テストは通過しますが、視覚的には読めない状態です。

改修規模に応じた使い方

改修規模に応じた確認範囲

毎回全項目を走らせるとトークンコストが上がるので、改修の規模に応じてスコープを絞るのが現実的です。

【軽微な修正(テキスト・色変更など)】
  → 該当ページだけを確認プロンプトで確認

【特定ブロック・セクションの追加・変更】
  → 差分確認プロンプト + レスポンシブ確認

【大きな改修(ヘッダー・フッター・テンプレート変更)】
  → 購入フロー確認 + レスポンシブ確認 + ナビゲーション確認

Claude と Codex で試してみた

ClaudeとCodexの比較観点

同じプロンプトをClaudeとCodexに渡して、同じHorizonストアのモバイルテストを実施したときの比較です。

両方が見つけた問題

モバイルでも通常ナビゲーションが表示されヘッダーが高い(112px)
「Home / Catalog / Blog / About / Contact」のナビゲーションがハンバーガーメニューと並んで表示されており、モバイルのファーストビューを圧迫しています。

それぞれだけが見つけた問題

Codex Claude(devtools-mcp主軸)
ユニーク発見 メニュードロワー幅が95%(356px)で全幅でない
スウォッチが22×22pxでタップターゲットとして小さい
コレクション一覧が1カラム。PDPのYou may also likeは2カラムで不統一
スティッキーATCバーがスクロールしても起動しない
技術的な深掘り カートドロワーがnative <dialog>(トップレイヤー)で動作しており、z-indexの重なり事故が構造的に起きない
横スクロール確認 scrollWidth === viewport を実測確認(横スクロールなし)

「コレクション一覧が1カラム」の指摘はClaudeのレポートにしかありませんでした。バグではなく設計の問題で、「PDPのレコメンドは2カラムなのにコレクション一覧だけ1カラムで体験が不統一」という観点はUXの視点が入った発見です。

カートドロワーについてCodexは「表示OK」で終わりましたが、Claudeはnative <dialog> のトップレイヤー構造まで踏み込んで「z-indexに依存せず前面に出るため重なり事故が原理的に発生しない」と説明しました。同じ「問題なし」という結論でも、根拠の深さが異なりました。

PlaywrightとAIブラウザ確認の使い分け

Playwrightとの使い分け

Playwrightは「知っている問題を確認するツール」、Claude in Chromeは「知らない問題を発見するツール」です。テーマ改修後の探索確認はClaude in Chrome、「この機能が毎回動いているか」の継続確認はPlaywrightという使い分けがうまく機能します。探索で問題を洗い出してから、定点確認したいフローをPlaywrightに落とす流れが現実的です。

注意点

AIブラウザテストの注意点と使いどころ

購入フローの自動テストは慎重に
カート追加からチェックアウトまでの自動テストは、Cloudflareのボット検知を回避するための設定変更が必要になります。この設定を広く適用するとストアフロント全体の防御が弱まるリスクがあるため、購入フローのテストは手動で行うのが現実的です。ShopifyのBogus Gateway(テスト決済)を使えば実際のカード情報なしに注文完了まで確認できます。

実機テストの代替にはならない
iOS SafariやAndroid Chromeでの実機動作は別の話です。フォント描画・スクロール挙動・タップターゲットのサイズ感は実機で確認するしかありません。

まとめ

AIにブラウザを操作させてストアテストをすると、「とりあえず動いているからOK」ではなく「実際に見て問題がないか確認する」レベルの確認ができるようになります。

特にテーマ改修後の「何か変な見た目になっていないか」という探索的な確認に向いています。ClaudeでもCodexでも同じプロンプトがそのまま使えます。URLだけ自分のストアに変えて、改修後のルーティンに組み込んでみてください。

Back to blog