Web Design Reviewer

このスキルは、ウェブサイトデザインの品質を視覚的に検査および検証し、ソースコードレベルで問題を特定して修正することを可能にします。

適用範囲

• 静的サイト (HTML/CSS/JS)
• React / Vue / Angular / Svelte などの SPA フレームワーク
• Next.js / Nuxt / SvelteKit などのフルスタックフレームワーク
• WordPress / Drupal などの CMS プラットフォーム
• その他すべてのウェブアプリケーション

前提条件

必須

1. ターゲットウェブサイトが実行されていること

   • ローカル開発サーバー (例: http://localhost:3000)
   • ステージング環境
   • 本番環境 (読み取り専用レビューの場合)

2. ブラウザ自動化が利用可能であること

   • スクリーンショット取得
   • ページナビゲーション
   • DOM 情報の取得

3. ソースコードへのアクセス (修正を行う場合)

   • プロジェクトがワークスペース内に存在すること

ワークフロー概要

flowchart TD
    A[ステップ1: 情報収集] --> B[ステップ2: 視覚検査]
    B --> C[ステップ3: 問題修正]
    C --> D[ステップ4: 再検証]
    D --> E{問題が残っているか?}
    E -->|はい| B
    E -->|いいえ| F[完了レポート]

---

ステップ1: 情報収集フェーズ

1.1 URL の確認

URL が提供されていない場合は、ユーザーに尋ねます:

レビュー対象のウェブサイトの URL を入力してください (例: http://localhost:3000)

1.2 プロジェクト構造の理解

修正を行う場合は、以下の情報を収集します:

項目	質問例
フレームワーク	React / Vue / Next.js などを使用していますか?
スタイリング方法	CSS / SCSS / Tailwind / CSS-in-JS などはどれですか?
ソースロケーション	スタイルファイルとコンポーネントはどこに配置されていますか?
レビュー範囲	特定ページのみか、全サイトか?

1.3 自動プロジェクト検出

ワークスペース内のファイルから自動検出を試みます:

検出対象:
├── package.json     → フレームワークと依存関係
├── tsconfig.json    → TypeScript の使用
├── tailwind.config  → Tailwind CSS
├── next.config      → Next.js
├── vite.config      → Vite
├── nuxt.config      → Nuxt
└── src/ または app/     → ソースディレクトリ

1.4 スタイリング方法の特定

方法	検出方法	編集対象
Pure CSS	*.css ファイル	グローバル CSS またはコンポーネント CSS
SCSS/Sass	*.scss, *.sass	SCSS ファイル
CSS Modules	*.module.css	モジュール CSS ファイル
Tailwind CSS	tailwind.config.*	コンポーネント内の className
styled-components	コード内の styled.	JS/TS ファイル
Emotion	@emotion/ インポート	JS/TS ファイル
CSS-in-JS (その他)	インラインスタイル	JS/TS ファイル

---

ステップ2: 視覚検査フェーズ

2.1 ページトラバーサル

1. 指定の URL にナビゲーション
2. スクリーンショットを取得
3. DOM 構造/スナップショットを取得 (可能な場合)
4. 追加ページがある場合は、ナビゲーションを通じてトラバーサル

2.2 検査項目

レイアウト問題

問題	説明	重大度
要素オーバーフロー	コンテンツが親要素またはビューポートからはみ出している	高
要素オーバーラップ	意図しない要素の重複	高
配置の問題	グリッドまたはフレックスの配置の問題	中
不一貫なスペース	パディング/マージンの不一貫性	中
テキストクリッピング	長いテキストが適切に処理されていない	中

レスポンシブ問題

問題	説明	重大度
モバイル非対応	小さい画面でレイアウトが崩れる	高
ブレークポイント問題	画面サイズ変更時の不自然な移行	中
タッチターゲット	モバイルでボタンが小さすぎる	中

アクセシビリティ問題

問題	説明	重大度
コントラスト不足	テキストと背景のコントラスト比が低い	高
フォーカス状態なし	キーボードナビゲーション時に状態を判定できない	高
alt テキストなし	画像の代替テキストがない	中

視覚的一貫性

問題	説明	重大度
フォント不一貫性	フォントファミリーが混在している	中
色不一貫性	ブランドカラーが統一されていない	中
スペース不一貫性	同様の要素間のスペースが均一でない	低

2.3 ビューポートテスト (レスポンシブ)

以下のビューポートでテストします:

名前	幅	代表的なデバイス
Mobile	375px	iPhone SE/12 mini
Tablet	768px	iPad
Desktop	1280px	標準 PC
Wide	1920px	大型ディスプレイ

---

ステップ3: 問題修正フェーズ

3.1 問題の優先順位付け

block-beta
    columns 1
    block:priority["優先度マトリックス"]
        P1["P1: すぐに修正\n(機能に影響するレイアウト問題)"]
        P2["P2: 次に修正\n(UX を低下させるビジュアル問題)"]
        P3["P3: 可能であれば修正\n(軽微なビジュアル不一貫性)"]
    end

3.2 ソースファイルの特定

問題のある要素からソースファイルを特定します:

1. セレクタベースの検索

   • クラス名または ID でコードベースを検索
   • grep_search でスタイル定義を探索

2. コンポーネントベースの検索

   • 要素のテキストまたは構造からコンポーネントを特定
   • semantic_search で関連ファイルを探索

3. ファイルパターンのフィルタリング

   スタイルファイル: src/**/*.css, styles/**/*
   コンポーネント: src/components/**/*
   ページ: src/pages/**, app/**
   

3.3 修正の適用

フレームワーク固有の修正ガイドライン

詳細は references/framework-fixes.md を参照してください。

修正の原則

1. 最小限の変更: 問題を解決するために必要な最小限の変更のみを行う
2. 既存パターンの尊重: プロジェクト内の既存コードスタイルに従う
3. 破壊的変更の回避: 他の領域に影響を及ぼさないよう注意する
4. コメントの追加: 必要に応じて修正の理由を説明するコメントを追加する

---

ステップ4: 再検証フェーズ

4.1 修正後の確認

1. ブラウザをリロード (または開発サーバー HMR を待機)
2. 修正された領域のスクリーンショットを取得
3. 修正前後を比較

4.2 回帰テスト

• 修正が他の領域に影響していないことを確認
• レスポンシブ表示が破損していないことを確認

4.3 反復判断

flowchart TD
    A{問題が残っているか?}
    A -->|はい| B[ステップ2に戻る]
    A -->|いいえ| C[完了レポートに進む]

反復制限: 特定の問題で3回以上の修正が必要な場合は、ユーザーに相談してください

---

出力形式

レビュー結果レポート

# ウェブデザインレビュー結果

## サマリー

| 項目 | 値 |
|------|-----|
| ターゲット URL | {URL} |
| フレームワーク | {検出されたフレームワーク} |
| スタイリング | {CSS / Tailwind など} |
| テスト済みビューポート | デスクトップ、モバイル |
| 検出された問題数 | {N} |
| 修正された問題数 | {M} |

## 検出された問題

### [P1] {問題タイトル}

- **ページ**: {ページパス}
- **要素**: {セレクタまたは説明}
- **問題**: {問題の詳細な説明}
- **修正ファイル**: `{ファイルパス}`
- **修正詳細**: {変更の説明}
- **スクリーンショット**: 修正前/修正後

### [P2] {問題タイトル}
...

## 未修正の問題 (ある場合)

### {問題タイトル}
- **理由**: {修正されなかった/できなかった理由}
- **推奨アクション**: {ユーザーへの推奨事項}

## 推奨事項

- {将来の改善のための提案}

---

必須機能

機能	説明	必須
ウェブページナビゲーション	URL へのアクセス、ページ遷移	✅
スクリーンショット取得	ページ画像の取得	✅
画像分析	ビジュアル問題検出	✅
DOM 取得	ページ構造の取得	推奨
ファイル読み取り/書き込み	ソースコードの読み取りと編集	修正に必須
コード検索	プロジェクト内のコード検索	修正に必須

---

リファレンス実装

Playwright MCP での実装

Playwright MCP は、このスキルのリファレンス実装として推奨されます。

機能	Playwright MCP ツール	目的
ナビゲーション	browser_navigate	URL へのアクセス
スナップショット	browser_snapshot	DOM 構造の取得
スクリーンショット	browser_take_screenshot	ビジュアル検査用画像
クリック	browser_click	インタラクティブ要素の操作
リサイズ	browser_resize	レスポンシブテスト
コンソール	browser_console_messages	JS エラーの検出

設定例 (MCP サーバー)

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest", "--caps=vision"]
    }
  }
}

その他の互換性のあるブラウザ自動化ツール

ツール	機能
Selenium	広範なブラウザ対応、多言語サポート
Puppeteer	Chrome/Chromium 専用、Node.js
Cypress	E2E テストとの簡単な統合
WebDriver BiDi	標準化された次世代プロトコル

同じワークフローをこれらのツールで実装できます。必要な機能 (ナビゲーション、スクリーンショット、DOM 取得) を備えていれば、ツールの選択は柔軟です。

---

ベストプラクティス

すべき こと (推奨)

• ✅ 修正前は常にスクリーンショットを保存する
• ✅ 一度に1つの問題を修正し、それぞれ検証する
• ✅ プロジェクトの既存コードスタイルに従う
• ✅ 大きな変更を加える前にユーザーに確認する
• ✅ 修正詳細を十分に文書化する

してはいけない こと (非推奨)

• ❌ 確認なしの大規模リファクタリング
• ❌ デザインシステムやブランドガイドラインの無視
• ❌ パフォーマンスを無視した修正
• ❌ 複数の問題を一度に修正する (検証が困難)

---

トラブルシューティング

問題: スタイルファイルが見つからない

1. package.json の依存関係を確認
2. CSS-in-JS の可能性を検討
3. ビルド時に生成された CSS を検討
4. ユーザーにスタイリング方法について尋ねる

問題: 修正が反映されない

1. 開発サーバー HMR が動作しているか確認
2. ブラウザキャッシュをクリア
3. プロジェクトがビルドを必要とする場合は再ビルド
4. CSS 特異性の問題を確認

問題: 修正が他の領域に影響している

1. 変更をロールバック
2. より具体的なセレクタを使用
3. CSS Modules またはスコープ付きスタイルの使用を検討
4. 影響範囲の確認についてユーザーに相談