mcpField
W
web-quality-audit

web-quality-audit

github.com/addyosmaniテスト・品質3.0k33.4k 回インストール9 週間前に更新
リポジトリ

web-quality-audit について

開発者や監査担当者向けのWeb品質レビュー用スキルです。ブラウザーでの実測とソース調査を組み合わせ、パフォーマンス、アクセシビリティ、SEO、ベストプラクティス、エージェントによる閲覧を扱います。

主な機能

  1. 01ブラウザー実測とソースの証拠
  2. 02パフォーマンスとCore Web Vitalsの確認
  3. 03アクセシビリティ、SEO、ベストプラクティスの検査
  4. 04エージェントによる閲覧の評価
  5. 05影響度と確度に基づく所見整理

活用シーン

  1. 01公開前のサイト品質監査
  2. 02ページ品質に関する問題の調査
  3. 03再検査による修正の確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/addyosmani/web-quality-skills --skill web-quality-audit

インストール後、Claude Code で/web-quality-auditを入力して読み込まれたか確認します。

同梱ファイルscripts/analyze.sh

詳細

Web 品質監査

ライブブラウザーの証拠とソースコードの調査を組み合わせた、包括的な品質レビューです。総合スコアを品質の証明として扱うことなく、パフォーマンス、アクセシビリティ、SEO、ベストプラクティス、エージェント型ブラウジングを対象とします。

Lighthouse 13+. パフォーマンスカテゴリでは現在、Lighthouse と DevTools のパフォーマンスパネルで共通の パフォーマンスインサイト が使用されています(発表)。最新のインサイト名と証拠に従ってください。削除された監査 ID を必須にしたり、その推奨事項を自動的に再現したりしないでください。ノイズが多い、実行可能な対応につながらない、または過剰な推奨をしやすいといった理由で廃止されたものもあります。

仕組み

  1. 監査対象を明確にします。代表的な URL、重要な状態と利用の流れ、公開アクセスと認証が必要なアクセスの区別、モバイル/デスクトップの範囲を確認します。
  2. ページを実行できる場合は、広範囲にコードベースを検索する前に、計測ワークフローを読み、最小限のライブベースラインを収集します。
  3. 実行時の問題を手掛かりにソースコードの調査範囲を絞ります。計測で確認した問題と、コード内でのみ見つかった仮説は分けて扱います。
  4. ユーザーへの影響と確度に基づいて分類し、具体的な修正を行うか提案します。
  5. 同等の自動チェックと、影響を受ける手動の操作フローを再実行します。検証済みの内容と、実環境または人による検証が引き続き必要な内容を報告します。

ツールの使い分け

すでに利用できる最適な機能を使い、任意のセットアップによって監査を妨げないでください。

必要なもの推奨する方法代替手段
パフォーマンスと Core Web Vitalsブラウザーのパフォーマンストレースを記録して、関連するインサイトを分析します。Chrome DevTools MCP を使用する場合は、performance_start_trace に続けて performance_analyze_insight を使用しますLighthouse CLI または PageSpeed Insights のラボデータ
実ユーザーのパフォーマンス現在の DevTools トレースのサマリーに含まれる CrUX の値PageSpeed Insights/CrUX Vis。CrUX API を直接使用するのは、キーがすでに利用可能な場合、または自動化が求められている場合に限ります
アクセシビリティ、SEO、ベストプラクティス、エージェント型ブラウジングライブ Lighthouse 監査を実行します。Chrome DevTools MCP を使用する場合は、lighthouse_audit を使用しますカテゴリ別の Lighthouse CLI 監査と手動チェック
レンダリングされたセマンティクスと操作アクセシビリティツリーを調べ、UI を操作します。Chrome DevTools MCP を使用する場合は、take_snapshot と対象を絞った evaluate_script を使用しますブラウザーでのテスト/手動テスト
ソースコードの簡易チェックscripts/analyze.sh <path>ソースコードの直接調査

Chrome DevTools MCP の lighthouse_audit では、意図的にパフォーマンスが対象外になっています。ナビゲーションモードではページが再読み込みされるため、認証済みまたはユーザーが作成した現在の状態を維持する必要がある場合は、スナップショットモードを使用してください。静的アナライザーは迅速な簡易チェックであり、レンダリングされたページの監査に代わるものではありません。

監査カテゴリ

パフォーマンス

Core Web Vitals — 良好なページエクスペリエンスを実現するには、次の基準を満たす必要があります。

  • LCP(Largest Contentful Paint)< 2.5s。 表示領域内で最も大きな要素をすばやく描画する必要があります。画像、フォント、サーバーの応答時間を最適化してください。
  • INP(Interaction to Next Paint)< 200ms。 ユーザーの操作に即座に応答する必要があります。JavaScript の実行時間を短縮し、長時間のタスクを分割してください。
  • CLS(Cumulative Layout Shift)< 0.1。 コンテンツが予期せず移動しないようにしてください。画像、埋め込みコンテンツ、広告には明示的なサイズを設定してください。

リソースの最適化:

  • 画像を圧縮します。 WebP/AVIF をフォールバック付きで使用します。srcset を使って適切なサイズの画像を配信します。
  • JavaScript を最小限にします。 未使用のコードを削除します。コード分割を使用します。重要度の低いスクリプトは遅延読み込みします。
  • CSS を最適化します。 クリティカル CSS を抽出します。未使用のスタイルを削除します。@import は避けてください。
  • フォントを効率的に使用します。 font-display: swap を使用します。重要なフォントをプリロードします。必要な文字にサブセット化します。

読み込み戦略:

  • オリジンに事前接続します。 サードパーティのドメインに対して <link rel="preconnect"> を追加します。
  • 重要なアセットをプリロードします。 LCP 画像、フォント、ファーストビュー内の CSS を対象にします。
  • ファーストビューより下のコンテンツを遅延読み込みします。 画像、iframe、負荷の大きいコンポーネントが対象です。
  • キャッシュを効果的に使用します。 静的アセットには長いキャッシュ TTL を設定します。ハッシュ付きファイルにはイミュータブルキャッシュを使用します。
アクセシビリティ

知覚可能:

  • テキストによる代替手段。 すべての <img> に意味のある alt テキストを設定します。装飾画像には alt="" を使用します。
  • 色のコントラスト。 通常のテキストでは最低 4.5:1、大きなテキストでは 3:1(WCAG AA)を確保します。
  • 色だけに頼らない。 色による表示とあわせて、アイコン、パターン、テキストを使用します。
  • キャプションとトランスクリプト。 動画にはキャプションを付けます。音声にはトランスクリプトを用意します。

操作可能:

  • キーボードで操作可能にします。 すべての機能をキーボードで利用できるようにします。キーボードトラップを作らないでください。
  • フォーカスを表示します。 すべての操作可能な要素に、明確なフォーカスインジケーターを表示します。
  • スキップリンク。 キーボードユーザー向けに「メインコンテンツへスキップ」を用意します。
  • 十分な時間を確保します。 ユーザーが制限時間を延長できるようにします。操作手段のない自動進行コンテンツは使用しないでください。

理解可能:

  • ページの言語。 <html> に lang 属性を設定します。
  • 一貫したナビゲーション。 ページ間で同じナビゲーション構造を使用します。
  • エラーの特定。 フォームのエラーを明確に説明し、該当するフィールドと関連付けます。
  • ラベルと説明。 すべてのフォーム入力に、関連付けられたラベルを設定します。

堅牢:

  • 有効な HTML。 ID を重複させず、要素を正しく入れ子にします。
  • ARIA を正しく使用します。 ネイティブ要素を優先します。ARIA ロールを実際の動作と一致させます。
  • 名前、ロール、値。 操作可能な要素に、アクセシブルな名前と正しいロールを設定します。
SEO

クロール可能性:

  • 有効な robots.txt。 重要なリソースをブロックしないようにします。
  • XML サイトマップ。 重要なページをすべて一覧にし、Search Console に送信します。
  • 正規 URL。 重複コンテンツの問題を防ぎます。
  • 重要なページに noindex を設定しない。 meta robots とヘッダーを確認します。

オンページ SEO:

  • 一意の title タグ。 各タイトルを説明的かつ簡潔にします。表示時の切り捨て方は、デバイスや検索結果の種類によって異なります。
  • メタディスクリプション。 ページごとに役立つ要約を記述します。検索エンジンが別のスニペットを選ぶこともあります。
  • 見出しの階層。 主見出しは内容を説明するものとし、構造を論理的にします。<h1> が複数あるという理由だけで、有効な HTML を不適合として扱わないでください。
  • 説明的なリンクテキスト。 「ここをクリック」や「続きを読む」は避けます。

テクニカル SEO:

  • モバイルフレンドリー。 レスポンシブデザインを採用します。タップ対象は 48px 以上にします。
  • HTTPS。 安全な接続が必要です。
  • ページエクスペリエンスのシグナル。 実ユーザーデータの Core Web Vitals を根拠として使用し、ランキングが変化するとは約束しないでください。
  • 構造化データ。 リッチスニペット(Article、Product、FAQ など)には JSON-LD を使用します。
ベストプラクティス

セキュリティ:

  • 常に HTTPS を使用します。 混在コンテンツをなくし、HSTS を有効にします。
  • 脆弱なライブラリを使用しません。 依存関係を最新の状態に保ちます。
  • CSP ヘッダーを設定します。 クロスサイトスクリプティング(XSS)を防ぐコンテンツセキュリティポリシーを使用します。
  • ソースマップを公開しません。 本番ビルドでは公開しないでください。

最新の標準:

  • 非推奨の API を使用しません。 document.write、同期 XHR などを置き換えます。
  • 有効な doctype を使用します。 <!DOCTYPE html> を使用します。
  • 文字セットを宣言します。 <head> の最初の要素として <meta charset="UTF-8"> を指定します。
  • ブラウザーエラーをなくします。 コンソールをクリーンな状態に保ち、CORS の問題がないようにします。

UX パターン:

  • 煩わしいインタースティシャルを表示しません。 特にモバイルでは避けてください。
  • 権限リクエストを明確にします。 必要な場合に限り、理由を説明して求めます。
  • 誤解を招くボタンを設置しません。 ボタンの表示どおりに動作するようにします。
エージェントによるブラウジング

Lighthouse Agentic Browsing の結果を、アシスタントがレンダリングされたページをどの程度理解し、操作できるかを示す技術的な指標として使用します。

  • アクセシブルな操作サーフェスを用意します。 セマンティック HTML、ラベル、名前、ロール、状態によって、アクセシビリティツリー内の意味のあるコントロールを識別できるようにします。
  • WebMCP 統合は、存在する場合に有効です。 登録済みのツール、スキーマ、フォームのカバレッジを確認します。監査スコアを上げることだけを目的として WebMCP を追加しないでください。
  • llms.txt は任意です。 有効なファイルがあれば、対応するツールが厳選されたコンテンツを見つけやすくなる場合があります。ただし、Lighthouse の合格は、検索サービスや AI 製品がそのコンテンツを取り込み、ランキングし、引用することを保証するものではありません。
  • このカテゴリを SEO に関する主張と混同しないでください。 エージェントによるブラウジングのしやすさは、検索順位や AI での可視性を示す根拠にはなりません。

重大度レベル

レベル説明対応
Criticalセキュリティ上の脆弱性、完全な機能不全直ちに修正
HighCore Web Vitals の不合格、重大なアクセシビリティの障壁リリース前に修正
Mediumパフォーマンス改善の機会、SEO の改善スプリント内に修正
Low軽微な最適化、コード品質都合のよいときに修正

監査出力形式

監査を実施する際は、次の形式で指摘事項をまとめます。

## Audit results

### Evidence
| Signal | Scope/conditions | Result | Source |
|--------|------------------|--------|--------|
| LCP | URL, phone, p75/28 days | 3.1s (needs improvement) | CrUX |
| Accessibility | URL, mobile navigation | 92 | Lighthouse |

### Critical issues (X found)
- **[Category]** Issue description. File: `path/to/file.js:123`
  - **Impact:** Why this matters
  - **Evidence:** Measured failure, runtime observation, or source hypothesis
  - **Fix:** Specific code change or recommendation

### High priority (X found)
...

### Summary
- Performance: measured status and X findings
- Accessibility: automated status, X findings, manual checks pending/passed
- SEO: X findings
- Best Practices: X findings
- Agentic Browsing: X findings or not available

### Recommended priority
1. First fix this because...
2. Then address...
3. Finally optimize...

### Verification
- Re-run results under the same conditions
- Manual checks completed
- Field validation still pending

クイックチェックリスト

デプロイの前に毎回
  • Core Web Vitals に合格している
  • アクセシビリティエラーがない(axe/Lighthouse)
  • コンソールエラーがない
  • HTTPS が動作している
  • メタタグが存在する
毎週のレビュー
  • Search Console で問題を確認する
  • Core Web Vitals の傾向を確認する
  • 依存関係を更新する
  • スクリーンリーダーでテストする
毎月の詳細レビュー
  • Lighthouse の完全な監査
  • パフォーマンスのプロファイリング
  • 実際のユーザーによるアクセシビリティ監査
  • SEO キーワードのレビュー

参考資料

各分野の詳細なガイドライン:

コメント