design-review

デザインレビュースキル

ステータス: 本番環境で利用可能 ✅ 最終更新日: 2025-11-20 依存関係: Playwright MCP または Chrome DevTools 方法論: 7 フェーズの体系的なレビュー（Stripe、Airbnb、Linear に着想）

---

クイックスタート

1. 前提条件の確認

デザインレビューを始める前に、ブラウザー自動化ツールが利用可能か確認してください。

オプション A: Playwright MCP（インタラクティブテストに推奨）

• Playwright のセットアップについては、playwright-testing スキルを参照してください
• ブラウザー自動化、スクリーンショット、ビューポートテスト、コンソール監視を利用できます

オプション B: Puppeteer CLI（スクリーンショットとパフォーマンスの代替手段）

• npm install -g puppeteer を実行して Puppeteer を直接インストールします
• スクリーンショットの撮影、パフォーマンス分析、ネットワーク監視を利用できます

ブラウザーツールの全リファレンスについては、references/browser-tools-reference.md を参照してください。

2. レビュー範囲の把握

PR レビューの場合:

# Analyze git diff to understand scope
git diff --name-only origin/main...HEAD

# Read PR description for context

一般的な UI レビューの場合: プレビュー URL とコンポーネント／ページの説明を指定するだけです。

3. 7 フェーズレビューの実施

以下の体系的なチェックリストに従ってください。各フェーズには、具体的な目標とテスト手順があります。

---

7 フェーズのレビューメソドロジー

フェーズ 0: 準備

目標: コンテキストを把握し、テスト環境をセットアップします。

手順:

1. PR の説明またはレビュー依頼を読み、以下を把握します。

   • 変更の動機
   • 実装範囲
   • 開発者からのテストに関するメモ
   • 期待される動作

2. コードの差分を分析します（PR がある場合）。

   git diff origin/main...HEAD
   

   変更されたファイル（コンポーネント、スタイル、テスト）を特定します。

3. ライブプレビュー環境をセットアップします。

   • ブラウザーツールを使ってプレビュー URL に移動します
   • 初期ビューポートを 1440x900（デスクトップ）に設定します
   • 参照用にベースラインのスクリーンショットを撮影します

4. デザイン原則を確認します（プロジェクトに独自のガイドラインがある場合）。

   • プロジェクトの CLAUDE.md でデザイン基準を確認します
   • コンポーネントライブラリのドキュメントを確認します
   • デザインシステムのトークンとパターンを記録します

省略する場合: Git のコンテキストがない、コンポーネントの簡易レビューの場合。

---

フェーズ 1: インタラクションとユーザーフロー

目標: インタラクティブな操作が想定どおりに機能することを確認します。

インタラクションガイドの全文: インタラクティブな状態、フォーム、ボタン、ナビゲーションフロー、マイクロインタラクション、モーダル、またはキーボードナビゲーションをテストする場合は、references/interaction-patterns.md を読み込んでください。

簡易チェックリスト:

• すべての要素について、5 つのインタラクティブな状態（デフォルト、ホバー、アクティブ、フォーカス、無効）をテストします
• 主なユーザーフロー（フォーム送信、ナビゲーション、重要な操作）を実行します
• 破壊的な操作に確認ダイアログがあることを確認します
• 知覚されるパフォーマンスを評価します（読み込み状態、楽観的 UI）

優先度判定: [Blocker] 重要なフローが壊れている | [High] UX が不十分／フォーカス状態が欠落 | [Medium] 仕上げが不十分 | [Nitpick] 軽微なタイミングの問題

---

フェーズ 2: レスポンシブテスト

目標: あらゆるビューポートサイズでデザインが機能することを確認します。

レスポンシブガイドの全文: ビューポート、タッチターゲット、モバイルナビゲーション、画像のレスポンシブ対応、または横スクロールのデバッグをテストする場合は、references/responsive-testing.md を読み込んでください。

3 つのビューポートをテストします。

• デスクトップ (1440px): 最適なレイアウト、すべての機能を利用可能
• タブレット (768px): 適切に調整されること、44×44px のタッチターゲット、折りたたみ式ナビゲーション
• モバイル (375px): 横スクロールなし、最小 16px のテキスト、モバイル向けナビゲーション

簡易テスト:

mcp__playwright__browser_resize(width: 1440, height: 900)  # Desktop
mcp__playwright__browser_resize(width: 768, height: 1024)  # Tablet
mcp__playwright__browser_resize(width: 375, height: 667)   # Mobile
mcp__playwright__browser_take_screenshot(fullPage: true)

優先度判定: [Blocker] レイアウトが壊れている | [High] 横スクロール／要素の重なり | [Medium] 間隔が最適でない | [Nitpick] 軽微な不整合

フェーズ 3：ビジュアルの仕上げ

目的： 美しさとビジュアルの一貫性を評価します。

デザイン原則ガイドについて：タイポグラフィの階層、余白とレイアウト、カラーパレット、配置とグリッド、ビジュアル階層、画像品質、または S ティアのデザイン基準を評価する際は、references/visual-polish.md を読み込みます。

簡易評価（5 つの基準）：

1. レイアウトと余白：グリッドの配置、8px スケール、デザイントークン（17px のような根拠のない数値を使わない）
2. タイポグラフィ：明確な H1>H2>H3 の階層、1.5～1.7 の行の高さ、フォントの太さを限定
3. 色：デザインシステムのトークン、意味に沿った使い分け（赤＝エラー、緑＝成功）、一貫したブランド表現
4. 画像：高解像度（ピクセル化していない）、適切なアスペクト比、最適化されたサイズ、代替テキスト
5. ビジュアル階層：主要な操作が目立つ、視線が自然に流れる、戦略的な余白

優先度の判定： [Blocker] テキストが判読不能／画像が壊れている | [High] 明らかな不整合 | [Medium] 余白や配置の問題 | [Nitpick] 美的な好み

---

フェーズ 4：アクセシビリティ（WCAG 2.1 AA）

目的： すべてのユーザーを対象としたインクルーシブなデザインを実現します。

WCAG 2.1 AA の完全なチェックリストについて：WCAG 準拠の確認、キーボードナビゲーションのテスト、色のコントラストの確認、セマンティック HTML の監査、またはアクセシビリティテストツール（Lighthouse、axe、WAVE）の使用時は、references/accessibility-wcag.md を読み込みます。

WCAG の簡易テスト（4 つの原則）：

1. 知覚可能：画像の代替テキスト、色のコントラスト（テキストは 4.5:1、UI コンポーネントは 3:1）、セマンティック HTML
2. 操作可能：キーボードナビゲーション（Tab の順序が論理的、すべてのインタラクティブ要素でフォーカスが見える、Enter／Space で操作できる、Escape でモーダルが閉じる、キーボードトラップがない）
3. 理解可能：明確なラベル、役立つエラーメッセージ、一貫したナビゲーション／用語
4. 堅牢：有効な HTML、適切な ARIA 属性（ロール、状態、プロパティ）

重要なテスト：

• ページ全体を Tab で移動する（フォーカス状態が見えること、順序が論理的であること、トラップがないことを確認）
• WebAIM Contrast Checker でテストする（すべてのテキスト／UI が ≥4.5:1 または 3:1 であること）
• フォームラベルが入力欄に関連付けられていることを確認する（<label for="id"> または aria-label）
• セマンティック HTML を確認する（h1→h2→h3 の順序を飛ばさない、<div onClick> ではなく <button> を使用する）

優先度の判定： [Blocker] 中核機能をキーボードで操作できない | [High] WCAG AA 違反 | [Medium] セマンティック HTML の問題 | [Nitpick] アクセシビリティの強化

---

フェーズ 5：堅牢性テスト

目的： エッジケースやエラー条件への対応を確認します。

テストシナリオ：

5.1 フォームの検証

• 必須項目を空欄にしてフォームを送信する
• 無効なデータを入力する（形式が正しくないメールアドレス、範囲外の数値）
• 項目単位の検証をテストする（リアルタイムのフィードバック）
• 明確で、対処方法がわかるエラーメッセージであることを確認する
• 送信成功時のフローをテストする（確認メッセージ）

5.2 コンテンツのオーバーフロー

• 長いテキスト文字列：非常に長い名前、メールアドレス、タイトル
• 大量の項目：大きなリスト、数百行のテーブル
• 深くネストされたコンテンツ：返信が多数あるコメント
• 空の状態：表示するデータがない（役立つメッセージを表示）

よくあるオーバーフローの問題：

• テキストによってレイアウトが崩れる（コンテナーからはみ出す）
• 省略記号やツールチップなしでテキストが切り詰められる
• 大きなリストでパフォーマンスの問題が起きる
• 空の状態のデザインがない

5.3 読み込み状態とエラー状態

• 読み込み状態：スケルトン画面、スピナー、進行状況インジケーター
• エラーメッセージ：明確で、対処方法がわかるエラーの説明
• 再試行の仕組み：失敗した操作をユーザーが再試行できるようにする
• タイムアウトへの対応：応答が遅い／失敗したリクエストを適切に処理する
• 楽観的な更新：すぐにフィードバックを返し、失敗時にはロールバックする

テスト手順：

# Simulate slow network
# Check browser DevTools Network tab → throttling

# Force error states
# Test with invalid API responses or network failures

よくある問題：

• 読み込みインジケーターがなく、フリーズしたように見える
• 曖昧なエラーメッセージ（「エラーが発生しました」）
• 失敗後に再試行する仕組みがない
• コンテンツの読み込み時にレイアウトが跳ねる

優先度の判定：

• [Blocker] エッジケースでクラッシュする、または完全に失敗する
• [High] エラー処理が不十分、または状態がわかりにくい
• [Medium] エッジケースへの対応がない、または軽微な問題がある
• [Nitpick] 読み込み状態の見た目、または細かな仕上げ

フェーズ 6：コードの健全性

目的： 保守性が高く、一貫性のある実装を確保します。

コードパターンガイドについて：コンポーネントの再利用（DRY 原則）、デザイントークンの使用（色、余白、タイポグラフィ）、パターンの一貫性（命名規則、ファイル構成、API パターン）を評価するときや、危険信号（重複、マジックナンバー、抽象化の破綻）を特定するときは、references/code-health-patterns.md を読み込みます。

簡易レビュー（3 つの基準）：

1. コンポーネントの再利用：コピー＆ペーストがない、共通コンポーネントが切り出されている、重複よりコンポジションを優先している
2. デザイントークン：色、余白、タイポグラフィに CSS 変数を使用している（margin: 17px のようなマジックナンバーがない）、角丸が一貫している
3. パターンの一貫性：コードベースのパターンに従っている、命名規則が一致している、ファイル構成が整理されている

優先度の分類： [High] 技術的負債を持ち込む／パターンを破る | [Medium] 再利用の機会を逃している | [Nitpick] コードスタイルの好み

---

フェーズ 7：コンテンツとコンソール

目的： 細部が洗練され、技術的に正確であることを確認します。

7.1 コンテンツレビュー

確認項目：

• 文法とスペル：誤字や文法上の誤りがない
• 明確さ：ラベルや手順が曖昧でない
• トーンの一貫性：ブランドの語調（フォーマル／カジュアル）に合っている
• プレースホルダーテキスト：実際のコンテンツに置き換えられている（「Lorem ipsum」が残っていない）
• マイクロコピーの品質：エラーメッセージ、ボタンラベル、ツールチップが役に立つ

よくあるコンテンツの問題：

• UI テキストの誤字
• 本番環境にプレースホルダーテキストが残っている
• 曖昧なラベル（「送信」ではなく「変更を保存」など）
• 用語が一貫していない
• 役に立たないエラーメッセージ（「エラー」ではなく「メールアドレスの形式が無効です」など）

7.2 コンソールの確認

テスト手順：

# Using Playwright MCP
mcp__playwright__browser_console_messages()

# Using Chrome DevTools
# Open DevTools → Console tab

確認項目：

• JavaScript エラー：捕捉されていない例外、null 参照
• React の警告：key プロパティの警告、ライフサイクルの問題
• ネットワーク障害：API リクエストの失敗、404
• 非推奨の警告：古い API の使用に関する警告
• パフォーマンスの警告：レンダリングの遅延、メモリリーク

優先度の分類：

• [Blocker] 機能を損なうコンソールエラー
• [High] ユーザー向けテキストの文法ミスやわかりにくい内容
• [Medium] コンソールの警告や軽微なコンテンツの問題
• [Nitpick] コンテンツの仕上げ、軽微なコンソールノイズ

---

コミュニケーションの原則

1. 解決策ではなく問題を伝える

解決策ではなく、問題とその影響を説明します。実装方法は開発者に委ねます。

❌ 解決策を指示する（避ける）： 「マージンを 16px に変更してください」

✅ 問題に焦点を当てる（推奨）： 「余白が隣接する要素と一貫しておらず、視覚的な雑然さが生じて、主要な CTA の妨げになっています。現在の余白は、デザインシステムで確立されたリズムを崩しています。」

2. 優先度マトリクス

すべての問題を明確な優先度に分類します：

優先度	基準	必要な対応
[Blocker]	重大な障害、中核機能の破損、重大なアクセシビリティ違反	マージ前に必ず修正
[High-Priority]	重大な UX の問題、明白なデザインの不整合、WCAG 違反	マージ前に修正すべき
[Medium-Priority]	改善点、軽微な不整合、エッジケースへの対応	後続の PR での対応を検討
[Nitpick]	美的な好み、軽微な仕上げ、主観的な意見	任意の改善

重要： 優先度が低いことを示すため、すべての指摘の先頭に「Nit:」を付けます。

3. 根拠に基づくフィードバック

視覚的な問題には必ずスクリーンショットを添付します。スクリーンショットは次の要件を満たす必要があります：

• 問題が明確にわかる
• 関連するコンテキスト（周囲の要素）が含まれている
• 確認箇所がわかるように示されている（必要に応じて矢印やハイライトを使用）

例：

### [High-Priority] Poor contrast on disabled button

**Problem:** Disabled button text has insufficient contrast (2.1:1), failing WCAG AA
standard (requires 4.5:1). Users with low vision may not recognize the button as disabled.

**Screenshot:** [Attach screenshot showing disabled button]

**Impact:** Accessibility violation, potential confusion for users with visual impairments.

4. 良い点から始める

問題を挙げる前に、うまくできている点を必ず認めます。これにより：

• 良い仕事を認識していることが伝わる
• バランスの取れたフィードバックになる
• 前向きな協力関係を保てる

例：

### Design Review Summary

The new checkout flow shows excellent attention to user experience. The step indicator
is clear and well-designed, error messages are helpful and actionable, and the overall
layout feels spacious and uncluttered. The loading states with skeleton screens are
particularly well-executed. Great work on the form validation feedback!

However, there are a few accessibility and responsiveness issues to address before merge...

---

レポート構成テンプレート

完全なテンプレートについて：すべてのセクションと例を含む完全な Markdown テンプレートを確認するには、assets/review-report-template.md を読み込みます。

基本的な構成：

## Design Review Summary
[2-3 sentences: positive acknowledgment + overall assessment]
**Review scope:** [PR #, pages, components]
**Viewports tested:** Desktop (1440px), Tablet (768px), Mobile (375px)
**Methodology:** 7-phase comprehensive review

---

### Findings

#### 🚨 Blockers
[Critical issues requiring immediate fix before merge]
- **[Blocker] [Title]**: Problem + Screenshot + Phase

#### ⚠️ High-Priority Issues
[Significant issues to fix before merge]
- **[High] [Title]**: Problem + Screenshot + Phase

#### 📋 Medium-Priority / Suggestions
[Improvements for follow-up PR]
- **[Medium] [Title]**: Problem + Phase

#### ✨ Nitpicks
[Minor aesthetic details - optional]
- **Nit:** [Issue] - [Brief description]

---

### Testing Evidence
**Screenshots:** Desktop (1440px) + Tablet (768px) + Mobile (375px)
**Console output:** [Errors/warnings or "Console clean"]
**Accessibility:** Keyboard nav + Focus states + Color contrast

---

### Next Steps
1. Fix Blockers
2. Address High-Priority issues
3. Consider Medium-Priority items

**Overall assessment:** [Ready to merge after blockers fixed / Needs revisions / Ready to merge!]

---

参照ファイルを読み込むタイミング

デザインレビューの特定の側面に取り組む際は、参照ファイルを読み込みます。

accessibility-wcag.md

次の場合に読み込みます：

• 標準ベース：本番環境へのデプロイに向けて、WCAG 2.1 AA への準拠を確認する
• 問題ベース：アクセシビリティ違反（色のコントラスト、キーボードナビゲーション、セマンティック HTML、フォーカス状態、ARIA 属性）に遭遇する
• テストベース：体系的なチェックリストを使って、包括的なアクセシビリティ監査を実施する
• ツールベース：自動テストにアクセシビリティテストツール（Lighthouse、axe、WAVE、Pa11y）を使用する
• トリアージベース：アクセシビリティの問題（WCAG 違反）の深刻度（Blocker／High／Medium）を判断する

browser-tools-reference.md

次の場合に読み込みます：

• セットアップベース：テスト用の Playwright MCP または Chrome DevTools CLI をインストール、設定する
• コマンドベース：特定の Playwright コマンド（ページ遷移、ビューポートのサイズ変更、スクリーンショット、クリック、入力、ホバー、コンソール出力の取得）が必要になる
• ワークフローベース：一般的なテストワークフロー（3 つのビューポートでのレスポンシブレビュー、フォーム操作テスト、キーボードナビゲーションテスト）を実装する
• セレクターベース：要素の指定に使う CSS セレクター、テキストセレクター、アクセシビリティセレクターで問題が発生する
• トラブルシューティングベース：Playwright MCP が要素を検出できない、Chrome の依存関係が不足している、スクリーンショットの取得に問題がある

code-health-patterns.md

次の場合に読み込みます：

• パターンベース：コンポーネントの再利用パターンや DRY 原則への準拠を評価し、共有コンポーネントを抽出する
• トークンベース：デザイントークンの使用状況（色、間隔のスケール、タイポグラフィのスケール、角丸の一貫性）を確認する
• 一貫性ベース：パターンの一貫性（命名規則、ファイル構成、API パターン、状態管理）をレビューする
• 例ベース：良いパターンと悪いパターンを比較するコード例（インラインスタイルとトークン、重複とコンポジション）が必要になる
• 危険信号ベース：コードの健全性に関する問題（コピー＆ペーストによる重複、17px のようなマジックナンバー、一貫性のない状態管理、壊れた抽象化）を特定する

design-principles-s-tier.md

次の場合に読み込みます：

• 標準ベース：S-Tier の SaaS ダッシュボード品質（Stripe、Airbnb、Linear、Vercel レベルの仕上がり）を確保する
• システムベース：デザインシステムの基盤（カラーパレットの構成、タイポグラフィのスケール、間隔のスケール、主要な UI コンポーネント）を評価する
• モジュールベース：特定のモジュール（マルチメディアモデレーションインターフェース、データテーブル、設定パネル、ダッシュボード）をレビューする
• 理念ベース：デザインの基本理念（ユーザー第一、スピードよりも細部へのこだわり、複雑さよりもシンプルさ、一貫性）を適用する
• アーキテクチャベース：CSS とスタイリングのアーキテクチャ（デザイントークン、コンポーネントパターン、レスポンシブ戦略）を評価する

interaction-patterns.md

次の場合に読み込みます：

• 状態ベース：ボタン、入力欄、リンクのインタラクティブな状態（デフォルト、ホバー、アクティブ、フォーカス、無効）をテストする
• フォームベース：フォーム操作、バリデーションパターン、エラー状態、成功状態、読み込み状態をテストする
• ボタンベース：ボタンの読み込み状態、破壊的な操作の確認パターン、プライマリーアクションとセカンダリーアクションを評価する
• フローベース：ナビゲーションフロー、ユーザージャーニー、複数ステップのプロセス、モーダル操作をテストする
• アニメーションベース：マイクロインタラクション、アニメーションのタイミング（200～300ms）、体感パフォーマンス（楽観的 UI、スケルトンスクリーン）をレビューする
• モーダルベース：モーダル操作、キーボードトラップ、フォーカス管理、Escape キーの動作をテストする

responsive-testing.md

次の場合に読み込みます：

• ビューポートベース：Playwright MCP を使用して、特定のビューポート（デスクトップ 1440px、タブレット 768px、モバイル 375px）でテストする場合
• タッチベース：モバイルでの使いやすさに必要な最小サイズ 44×44px を、タッチターゲットが満たしているか確認する場合
• オーバーフローベース：モバイルで横スクロールが発生する問題やレイアウトのオーバーフローをデバッグする場合
• モバイルベース：テキストの読みやすさ（フォントサイズ 16px 以上）、モバイルナビゲーションのパターン、レスポンシブ画像を確認する場合
• ブレークポイントベース：ブレークポイント戦略を実装またはテストする場合（一般的なブレークポイント：640px、768px、1024px、1280px）
• ナビゲーションベース：レスポンシブナビゲーションのパターン（ハンバーガーメニュー、折りたたみ式ナビゲーション、モバイルドロワーメニュー）をテストする場合

visual-polish.md

次の場合に読み込みます：

• タイポグラフィベース：フォント階層（H1>H2>H3）、フォントサイズの基準（16/18/24/32/48/64px）、行の高さ（1.5-1.7）、読みやすさを評価する場合
• スペーシングベース：8ポイントグリッドへの準拠（8/16/24/32/40/48/64px）、一貫したスペーシングスケール、コンポーネントのパディング／マージンを確認する場合
• カラーベース：カラーパレットの一貫性、セマンティックカラーの使用（赤＝エラー、緑＝成功）、デザイントークンの使用（16進数値のハードコーディングなし）を確認する場合
• 配置ベース：グリッドベースのレイアウト、正確な配置（0.5px の精度）、垂直方向のリズム、視覚的なバランスを確認する場合
• 階層ベース：視覚的階層の手法（サイズのコントラスト、太さのコントラスト、色のコントラスト、位置、計画的な余白）を評価する場合
• 品質ベース：画像の品質（ピクセル化がないこと）、正しいアスペクト比、ウェブ向けに適切に最適化されているかを評価する場合
• コンポーネントベース：デザインシステムのコンポーネント（ボタンのスタイル、フォーム入力のスタイル、カードコンポーネント、一貫した角丸）を確認する場合

---

既知の問題の防止

このスキルは、記録されているデザインレビューの問題 8 件を防止します：

問題	課題	影響	防止策
#1: アクセシビリティの欠如	レビューが見た目だけに集中し、キーボード操作やスクリーンリーダーを無視する	WCAG 違反が本番環境にリリースされ、障害のあるユーザーが排除される	フェーズ 4 で、キーボードテストを含む WCAG 2.1 AA の完全なチェックリストを必須とする
#2: レスポンシブテストの不備	デスクトップのビューポートのみでレビューし、モバイルでの表示崩れを見逃す	モバイルレイアウトの崩れ、モバイルユーザーの不満	フェーズ 2 で、1440px、768px、375px のビューポートでのテストを必須とする
#3: 曖昧なフィードバック	スクリーンショットや具体的な説明なしに、「何か違う」といったコメントをする	時間の浪費、曖昧な対応事項、開発者の不満	エビデンスに基づくフィードバックの原則により、スクリーンショットを必須とする
#4: 解決策の押し付け	UX への影響を説明する代わりに、実装方法を指定する（「マージンを 16px に変更する」など）	デザインと開発の摩擦、より良い解決策を見逃す	「解決策の押し付けより問題の指摘」の原則を徹底する
#5: トリアージの優先度なし	すべてのフィードバックを同等に扱い、些細な指摘でマージを妨げる	デリバリーの遅延、優先度の不明確化	トリアージマトリクス（ブロッカー／高／中／軽微）の使用を必須とする
#6: エッジケースの見落とし	正常なケースでは動作するが、エラー状態やオーバーフローでレイアウトが崩れる	エッジケースに起因する本番環境のバグ	フェーズ 5 で堅牢性テストを必須とする
#7: コンソールエラーの無視	ビジュアルデザインは問題ないが、コンソールに JavaScript エラーが存在する	実行時の障害、ユーザー体験の低下	フェーズ 7 でコンソールの確認を必須とする
#8: 方法論の不統一	レビュアーの気分によって、場当たり的なレビューで重要な領域を見落とす	不完全なレビュー、問題の見落とし	7 フェーズのチェックリストにより、包括的で再現性のあるレビューを実現する

---

依存関係

必須

ブラウザー自動化ツール（以下のいずれか）：

1. Playwright MCP（推奨）

   • インストール方法はplaywright-testingスキルを参照してください
   • 提供機能：ブラウザー自動化、スクリーンショット、ビューポートテスト、コンソールの監視
   • 最適な用途：インタラクティブテスト、キーボードナビゲーション、フォームテスト

2. Puppeteer CLI

   • npm install -g puppeteerでインストールします
   • 提供機能：スクリーンショットの取得、パフォーマンス分析、ネットワークの監視
   • 最適な用途：ビジュアルテスト、パフォーマンス監査

ライブプレビュー環境：

• テスト用にアクセスできるURL
• モックアップではなく、実際の実装を反映していること

任意

• Git/GitHub：PRの背景情報や差分分析用
• デザインシステムのドキュメント：確立されたパターンとの一貫性を確認するため
• プロジェクトのCLAUDE.md：プロジェクト固有のデザインガイドライン用

インストール方法

ブラウザーツールが利用できない場合、このスキルでは次の手順を実行します：

1. 不足しているツールを検出します
2. インストールに適したスキル（playwright-testing）へのリンクを提示します
3. 手動テストの代替手順を案内します

---

関連スキル

• playwright-testing：Playwrightを使ったE2Eテスト、ブラウザー自動化のセットアップ
• frontend-design：高品質なデザインで新しいフロントエンドインターフェースを作成するスキル（補完的なスキル）
• tailwind-v4-shadcn：UIフレームワークの実装（レビュー対象のデザインで使用されている場合があります）

---

公式ドキュメント

• WCAG 2.1ガイドライン：https://www.w3.org/WAI/WCAG21/quickref/
• WebAIMコントラストチェッカー：https://webaim.org/resources/contrastchecker/
• Playwrightドキュメント：https://playwright.dev/
• インクルーシブデザインの原則：https://inclusivedesignprinciples.org/
• A11y Projectチェックリスト：https://www.a11yproject.com/checklist/

---

本番環境での検証

このスキルは、以下で使用されている実際のデザインレビューワークフローに基づいています。

• 手法の着想元：Stripe、Airbnb、Linear（体系的な7段階のアプローチ）
• テスト方法：Playwright/Puppeteerを使った自動ブラウザーテスト
• アクセシビリティ標準：WCAG 2.1 AA準拠（業界標準）

推定トークン効率：

• スキルなし：約25kトークン（試行錯誤と繰り返しの修正）
• スキルあり：約8kトークン（ガイド付きの方法論と体系的なアプローチ）
• 節約：約68%（チェックリストのカバー率100%）

---

質問や問題がありますか？

1. WCAGチェックリストの全容はreferences/accessibility-wcag.mdを確認してください
2. Playwright/Chrome DevToolsのコマンドはreferences/browser-tools-reference.mdを参照してください
3. デザイン原則はreferences/visual-polish.mdを確認してください
4. ブラウザーツールがインストールされていることを確認してください（playwright-testingスキルを参照）
5. プレビューURLが稼働中で、アクセス可能であることを確認してください