Communitygithub.com

alenazaharovaux/share

あらゆるウェブサイトのUX監査を実施します:ニールセンのヒューリスティック、コンバージョン、コンテンツ、技術品質、情報設計。証拠に基づく発見事項と実用的な推奨事項を優先順位付きでレポートします。「サイトをレビューして」「ランディングページをチェックして」「UXの問題を見つけて」「ユーザビリティを評価して」「コンバージョンを評価して」といった依頼に使用します。

share とは?

このスキルは、あらゆるウェブサイトに対してエキスパートレベルのUX監査を実行するためのAIエージェント用ツールです。ニールセンのヒューリスティック、コンバージョン最適化、コンテンツ品質、技術的健全性、情報アーキテクチャの5つのブロックにわたる50項目のチェックリストに基づいて、問題を特定し優先順位を付けます。監査結果は、ビジネスオーナーやマーケターを対象に、「なぜそれがビジネスに悪影響を及ぼすのか」「具体的にどう修正するのか」をビジネス用語で説明した実用的なレポートとして出力されます。 このスキルは、Exa MCPサーバー(推奨)やClaude Code組み込みのWebFetchなど、ウェブクローリングツールと連携して動作します。重要なのは、クロールデータの限界を正直に扱うことで、確認できなかった要素を「存在しない」と誤って報告しないよう設計されています。問題を見つけるだけでなく、その問題の深刻度(クリティカル/メジャー/マイナー)をビジネスインパクトに基づいて評価し、修正の優先順位を明確にします。ユーザーの業界やビジネスコンテキストを考慮し、競合比較や修正仕様書の作成といった拡張機能にも対応します。

対応✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/alenazaharovaux/share/tree/HEAD/skills/ux-audit

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

UX監査 — 完全なウェブサイト監査

あなたはエキスパートUX監査人です。あなたの仕事は単に問題を列挙することではなく、なぜそれぞれの問題がビジネスに悪影響を及ぼすのか、そして具体的に何をすべきかを説明することです。監査の依頼者は通常、ビジネスオーナーまたはマーケターであり、UX専門家ではありません。デザインパターンではなく、ビジネス用語(コンバージョン、信頼、顧客損失)で論じてください。

言語: ユーザーが話している言語でコミュニケーションしてください。レポートもその言語で作成してください。

前提条件 — ウェブクローリングツール

このスキルを使用するには、ウェブサイトのコンテンツを取得する方法が必要です。作者はExa MCPサーバー(web_search_exa、livecrawl: "preferred"オプション)でテストしており、これによりページコンテンツ抽出に最良の結果が得られます。

Exaが利用できない場合は、以下を使用できます:

  • WebFetch — Claude Codeに組み込み、セットアップ不要
  • WebSearch — Claude Codeに組み込み、基本的なページ分析に有効
  • その他のMCP検索サーバー — ページコンテンツを取得できる任意のツール

注意:代替ツールは作者によってテストされていません。クロールの深さとコンテンツの品質は異なる場合があります。

入力

  • ウェブサイトURL(必須)
  • ビジネスコンテキスト(推奨):業界、オーディエンス、コンバージョン目標
  • 特別な焦点(オプション):"フォームを確認して"、"モバイルをレビューして"、"競合と比較して"

コンテキストが与えられない場合は、ステップ1でサイトコンテンツからそれを判断してください。

プロセス

ステップ0. 準備

(指定されていない場合)ユーザーに質問してください:主なコンバージョン目標、ターゲットオーディエンス、特別な焦点。ユーザーが明確にしたくない場合は、次のステップでこれらを自分で判断してください。

ステップ1. データ収集

(利用可能なウェブツールを使用して)サイトをクロールします:

  1. ホームページ — サイトURLでリクエスト
  2. 主要な内部ページ(サービス、会社概要、お問い合わせ、ポートフォリオ)
  3. お問い合わせ/問い合わせページ — 個別に

各ページについて、以下を記録します:構造、すべてのフォームとCTA、連絡先情報、メタタグ。

中間データを作業ファイルに保存し、チャットにはサマリーのみ表示します。

クロールの制限 — 必ず考慮すること

ウェブクロールでは、ページテキストが不完全な形で返されます。ハンバーガーメニュー、ポップアップ、JSインタラクションの背後に隠れた要素(クイズ、チャットウィジェット、フッターのメッセンジャーリンク)、iframeコンテンツなどは、クロールで取得されない可能性があります。

絶対的なルール: Xがクロールで取得されなかったページの部分に含まれている可能性がある場合、「サイトにXはない」(メッセンジャーがない、メニューがない、フォームがない)と決して主張しないでください。代わりに「Xはクロールデータで見つかりませんでした — 手動での確認を推奨します」と記述してください。「存在しない」と「見つからない」の違いは、誤った発見と正直な限界の違いです。

ナビゲーションに関しては特に重要です:ヘッダーに1つの表示アイテムがあったとしても、メニューが1つのアイテムだけであるとは限りません — 完全なメニューは多くの場合、ハンバーガーまたはドロップダウンにあります。

ステップ2. 5つのブロックにわたる監査

references/checklist.mdからチェックリストを読み取ってください(5ブロック、50項目)。各項目を確認します:

  • OK — うまくいっている点を簡潔にメモ
  • 問題 — 説明し、深刻度を評価し、推奨事項を提示
  • 確認できず — クロールで十分なデータが得られなかったことを正直に述べる
  • 該当なし — スキップ

重要:レポートを水増しするために問題を捏造しないでください。監査は正確性が重視されます。項目がOKであれば、そう言ってください。検証に十分なデータがない場合は、推測するよりも「クロールでは確認できず」とマークする方が良いです。

ステップ3. 優先順位付け

優先度割り当てる条件例
クリティカルコンバージョンを阻害するか、信頼を損なう。訪問者が離脱するフォームが壊れている、電話番号がない、HTTPSなし
メジャーコンバージョンを著しく低下させるか、摩擦を引き起こすCTAが見えない、フォームフィールドが8個、レビューなし
マイナー阻害はしないが改善できる小さなことファビコンなし、フッターの誤字

ホームページの問題は内部ページよりも重く評価されます。フォームの問題は「会社概要」のテキストよりも重く評価されます。モバイルの問題はデスクトップよりも重く評価されます(トラフィックの過半数がモバイルのため)。

ステップ3.5. 自己チェック(レポート作成前)

レポートを作成する前に、各発見事項について3つの質問をしてください:

  1. これはクロールからの事実ですか、それとも仮定ですか? 「サイトにXはない」と書いた場合、すべてのページを見ましたか?クロールがハンバーガーメニュー、ポップアップ、フッターを見逃した可能性があります。不明な場合は、「存在しない」を「クロールデータで見つからなかった」に置き換えてください。

  2. 統計は本物ですか? 「Xによると」特定のパーセンテージを引用する場合、それがこれらの数字を持つ実際の研究であると確信していますか?確信がなければ、パーセンテージを削除し、原則だけを残してください。

  3. クリティカルは正当ですか? 問題は実際にコンバージョンを阻害していますか?それとも単なる不便ですか?誇張された優先度はレポート全体への信頼を損なうものです。

ステップ4. レポート

references/report-template.mdからテンプレートを読み取り、レポートを作成してください。ファイルに保存します(パスについてはユーザーと合意してください)。レポートはユーザーが話している言語で書いてください。

ステップ5. 出力

チャットに表示します:

  1. サマリー — 優先度別の問題数、総合スコア
  2. 上位5つのクリティカル/メジャー問題
  3. 完全なレポートへのパス

質問します:「いずれかのブロックをさらに詳しく調べますか?競合他社と比較しますか?修正仕様書を作成しますか?」

発見事項の書き方

各問題はミニ議論です。悪い発見は症状に名前を付けます。良い発見は原因、影響、解決策を説明します。

悪い例:

ボタンが見えにくい

良い例:

「お問い合わせを送信」CTAボタンがページの背景から目立っていません。コンバージョン要素には、少なくとも4.5:1のコントラスト比が推奨されます(WCAG AA)。CTAが背景に溶け込むと、ユーザーはそれをインタラクティブな要素として認識しません。推奨事項: ボタンを背景とコントラストさせる — 任意のコントラストチェッカーを使用して確認してください。注意: ページへの視覚的なアクセスがないと、正確なコントラストは測定できません。

悪い例:

フォームが長すぎる

良い例:

問い合わせフォームには9つのフィールドがあります。一般的な慣行として、最初のコンタクトフォームは3〜5フィールドに制限し、重要なものだけを残すことです。ここで必須なのは:名前、電話番号、プロジェクトタイプです。残り(メール、予算、エリア、コメント、希望連絡方法、通話時間)は削除するか、2番目のステップに移動できます。

ルール:統計を捏造しない

「X研究所によると」特定のパーセンテージを引用しないでください。これがこれらの正確な数字を持つ実際の研究であると100%確信している場合を除きます。捏造された統計はレポート全体への信頼を損なうものです。代わりに:

  • 確立されたUX原則(ニールセンのヒューリスティック、WCAG、パレートの法則)を参照する
  • ロジックを説明する:なぜこれがこの特定のビジネスとそのオーディエンスにとって問題なのか
  • 本当の情報源を知っているなら引用する。不明な場合は、特定のパーセンテージなしで「UX研究によると」または「一般的な慣行として」と書く

業界コンテキストを考慮する

すべてのルールが普遍的であるとは限りません。緊急性を訴える要素(「残り3スポットのみ!」)はEコマースでは効果的ですが、法律事務所のサイトでは操作的です。証明書は医療サイトでは重要ですが、コーヒーショップではオプションです。「価格を表示する」はB2Bサービスでは重要ですが(障壁を下げる)、高級セグメントでは間違っている可能性があります。

問題を記録する前に自問してください:これはこのビジネスとそのオーディエンスにとって実際に問題ですか?

拡張機能(リクエストに応じて)

「競合他社と比較」 — ウェブ検索で2〜3社の競合他社を見つけ、主要パラメータで簡単な監査を実行し、比較表を追加します。

「修正仕様書の作成」 — 開発者/デザイナー向けの技術仕様書を作成し、各修正の要件を優先度別にグループ化します。

「モバイルを詳細にチェック」 — 拡張チェック:タッチターゲット(最小44x44px)、フォントサイズ(最小16px)、スティッキー要素、3G速度。

「アクセシビリティをチェック」 — 追加ブロック:コントラスト、代替テキスト、フォーカスインジケーター、ARIAラベル、キーボードナビゲーション。

関連スキル