audit-ux について
audit-ux は、AI コーディングエージェント向けのページ単位の UX 監査スキルです。ニールセンのヒューリスティック、マイクロコピー、Google HEART を扱い、製品やユーザーフローを把握してから、根拠に基づく指摘を分類・評価します。
主な機能
- 01ページ単位の UX ヒューリスティック評価
- 02マイクロコピーと HEART の確認
- 03ユーザーとデータの流れを先に把握
- 04根拠に基づく指摘の分類と評価
- 05報告前のセルフチェック
活用シーン
- 01送信時の状態フィードバックの確認
- 02フォームのエラー防止策の発見
- 03エラーメッセージと復旧案内の確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ kensaurus/ skills --skill audit-uxインストール後、Claude Code で/audit-uxを入力して読み込まれたか確認します。
同梱ファイルreferences/details.md
詳細
UX 監査スキル
自由度:MIXED — ステップ 0、2~5 は [HIGH freedom]、ステップ 1 の調査 JSON とすべての Playwright ステップは [LOW freedom — run exactly] です。
ブラウザーを操作する前に、protocol-browser-anti-stall を読んでください。
関連スキルとの違い
| スキル | 担当範囲 |
|---|---|
| audit-ux(このスキル) | ページ単位の UX 監査:NN/g のヒューリスティクス、マイクロコピーのレビュー、Google HEART |
audit-ux-journeys | ユーザーストーリー、タスク完了、IA のページ横断 UX 監査 |
enhance-web-ux | NN/g に基づく、既存ページ 1 つのフローの改善 |
audit-uiux-design-system | ビジュアルシステムの一貫性:トークン、バリアント、色、タイポグラフィ、余白、ダークモード |
thirdparty-ui-ux-pro-max | スクリプトを使ったサードパーティのスタイルカタログ:配色、タイポグラフィ、UX ガイドライン |
考え方
- 観察する — スクリーンショット、コピー、またはコード行を引用します
- 解釈する — パイプラインのこの時点で、人にどのような影響を与えるかを考えます
- 分類する — ヒューリスティックの不備/法則への違反/マイクロコピー/現状のままで問題なし
- 重大度を判定する — 成功の瞬間を妨げるものは P0、回復可能な摩擦は P1、些細な問題は P2 です
例
観察: 請求書の Submit が有効なままで、トースト通知がなく、
POST /invoicesの処理に 4 秒かかっています。 解釈: 2 回目のクリックで請求書が重複して作成されます(H1 + H5、金銭に関わる処理)。 分類: 信頼が重視される書き込み処理におけるヒューリスティックの不備です。 重大度: P0 — 金銭に関わる二重送信です。 指摘事項:/invoices/new| H1/H5 | P0 | 処理中の状態がない | 無効化 + トースト通知。
報告前の自己批評 [LOW freedom — do not skip]
- 根拠がある — 「わかりにくく感じる」ではなく、スクリーンショットまたは引用したコピーを示します
- ページ単位である — ページ横断の IA/ストーリーは
audit-ux-journeysの担当です - 重大度に根拠がある — P0 は記録された成功の瞬間を妨げるものです
- 担当範囲が適切である — ブレークポイントは
audit-responsive、空状態/エラー状態はaudit-ui-statesの担当です - まずコンテキストを確認する — ステップ 0 で人とパイプラインを確認しないまま指摘してはいけません
コンテキスト優先
ヒューリスティックを評価する前に、どのような人が使うのか(「ユーザー」ではなく、その人の状態)、このページがジャーニーのどこに位置するのか、入力 → API → DB → 画面の間でデータがどう動くのか、そして感情の流れを把握します。ステップ 0 は必須です。
ステップ 0:プロダクトとパイプラインを深く理解する
0a. ビジネスと人のコンテキストを理解する
README、ランディングページ、マーケティングコピー、オンボーディングフローがあればそれらを読み、次の質問に答えます。
- どのような問題を解決するのか?(機能ではなく、軽減する人の苦痛)
- 主な利用者は誰か?(人口統計、技術スキル、利用時の感情状態)
- 代替手段は何か?(このプロダクトがなければ、人々は何をするのか? スプレッドシート? 電話? 何もしない?)
- 成功の瞬間は何か?(「なるほど」と気づく瞬間 — その人が求めていたものを得るとき)
- 信頼モデルはどのようなものか?(金銭、健康データ、ビジネスデータをこのプロダクトに預けることを、利用者は信頼しているか?)
0b. パイプライン、ルート、感情の流れをマッピングする
主要なタスクごとに、人の入力から、クライアント側の検証、API 呼び出し、サーバーでの処理、データベース、応答、クライアントの更新を経て、人が目にするフィードバックに至るまで、データの流れを追跡します(api/、actions/、hooks/use*、lib/、fetch|axios|ky|useSWR|useQuery|trpc の呼び出し箇所から、連携ポイントを特定します)。遅延に敏感な箇所、エラーが起きやすい箇所、信頼が重視される箇所を記録します。H1、H5、H9 の指摘事項はこうした箇所から生まれます。フレームワークに応じてルートを特定し(app/**/page.tsx、pages/**/*.tsx、src/routes/、router.*)、対象ページのナビゲーション構成(フラット/階層型/ハブアンドスポーク)、深さ、相互リンク、行き止まりを記録します。ページ横断の IA は audit-ux-journeys の担当です。主要なフローごとに、開始時の感情、混乱や不安が高まる箇所、プロダクトが信頼を得る箇所、ピークとなる瞬間(最良または最悪)、フローの終わり方を記録します。
0c. 調査結果を記録する
形式は自由ですが、短いブロックにまとめます。プロダクトの種類、人が抱える問題、主な利用者とその感情的なコンテキスト、主要なタスク、成功の瞬間、信頼レベル(金銭/データ/時間/評判)、ページ数、認証パターン、ロケール/i18n、既知の遅延ポイントやエラーが起きやすい箇所を含めます。
ステップ 1:最新の UX 標準を調査する
1a. NN/g — ユーザビリティのヒューリスティックと手法
firecrawl:firecrawl_search
{
"query": "site:nngroup.com heuristic evaluation checklist [current year]",
"limit": 5,
"sources": [{ "type": "web" }]
}
1b. Intuit Content Design — マイクロコピーの原則
firecrawl:firecrawl_search
{
"query": "site:contentdesign.intuit.com UX writing principles",
"limit": 5,
"sources": [{ "type": "web" }]
}
詳細なライティングガイドラインを確認するため、最も関連性の高い検索結果をスクレイピングします。
1c. Laws of UX — インタラクション心理学
firecrawl:firecrawl_scrape
{
"url": "https://lawsofux.com",
"formats": ["markdown"],
"onlyMainContent": true
}
1d. ドメイン固有の UX 調査
firecrawl:firecrawl_search
{
"query": "<PRODUCT_TYPE> UX best practices usability patterns [current year]",
"limit": 5,
"sources": [{ "type": "web" }]
}
ドメイン固有の UX パターンを確認するため、最適な検索結果をスクレイピングします。
ステップ 2:Nielsen のユーザビリティに関する 10 のヒューリスティック(詳細評価)
各ヒューリスティックについて、コードを分析し、実際のブラウザーで検証します。
H1:システムの状態を視認できること
コードで確認する項目:
*.tsx を検索し、フィードバックのパターンを確認します:loading|isLoading|isPending|skeleton|Skeleton|spinner|Spinner
(読み込み状態);progress|Progress|step.*of|currentStep(複数ステップの進行状況);
toast|Toast|notification|Notification|snackbar(ユーザーへの通知)。
ブラウザーで検証する項目:
| シグナル | 合格 | 不合格 |
|---|---|---|
| 読み込み状態 | データ取得中にスケルトン/スピナーが表示される | 画面が空白、または UI がフリーズする |
| フォーム送信 | ボタンに読み込み状態が表示され、成功/エラーのフィードバックがある | フィードバックがなく、ユーザーが再度クリックする |
| 進行状況の表示 | 複数ステップのフローでステップ数が表示される | ユーザーが現在の位置を把握できない |
| アクティブなナビゲーション | 現在のページ/セクションが強調表示される | 現在位置を示すものがない |
| リアルタイム更新 | 楽観的 UI またはポーリングによるフィードバックがある | データが古いままで、更新を示す表示がない |
H2:システムと現実世界の一致
コードで確認する項目:
*.tsx を検索し、コピー品質に関する TODO を確認します:TODO.*wording|TODO.*copy|TODO.*label|TODO.*text(大文字と小文字を区別しない)。
ブラウザーで検証する項目:
| シグナル | 合格 | 不合格 |
|---|---|---|
| ラベルと用語 | ユーザーが期待する、ドメインに適した言葉を使っている | 技術用語や内部コードネームを使っている |
| アイコン | 広く認知されている、またはラベルが付いている | テキストラベルのない、意味が曖昧なアイコン |
| データ形式 | ユーザーのロケールに合わせた日付、通貨、数値 | ISO 形式の日付、生の数値、誤った通貨 |
| 論理的なグループ化 | ユーザーのメンタルモデルに沿って情報を整理している | データベーススキーマや開発上の都合で整理している |
| メタファー | 現実世界のたとえが理解を助ける | 混乱を招く、無理なメタファー |
H3:ユーザーのコントロールと自由
コードで確認する項目:
*.tsx を検索し、緊急退出のパターンを確認します:onCancel|handleCancel|onClose|handleClose|onDismiss
(キャンセル/閉じるハンドラー);undo|Undo|revert|Revert(取り消し操作);
confirm.*delete|confirm.*remove|AlertDialog|ConfirmDialog(破壊的な操作を防ぐ仕組み)。
ブラウザーで検証する項目:
| シグナル | 合格 | 不合格 |
|---|---|---|
| モーダルの終了 | 閉じるボタン、Escape キー、背景クリックで閉じられる | 閉じる方法がなく、操作から抜け出せない |
| フォームの中断 | 戻るボタンが使え、下書きが保存される | ページ移動でデータが失われる |
| 破壊的な操作 | 結果が明確な確認ダイアログがある | ワンクリックで削除され、取り消しもできない |
| 複数ステップのフロー | データを失わずに前のステップへ戻れる | 先に進むことしかできない |
| 取り消し | 重要な操作の後に取り消しができる | 警告なしに変更が取り消せなくなる |
H4:一貫性と標準
ブラウザーで検証する項目:
| シグナル | 合格 | 不合格 |
|---|---|---|
| ボタンの階層 | プライマリー/セカンダリー/ゴーストが一貫して使われている | ボタンのスタイルがばらばら |
| 用語 | 同じ操作には、どこでも同じラベルが使われている | 同じ操作に対して「保存」「送信」「確認」「適用」が混在している |
| レイアウトパターン | 画面間で一貫したページ構成になっている | ページごとに異なるレイアウトロジックを使っている |
| インタラクションパターン | 同じ操作で同じ結果になる | クリックすると、ある場合はページ遷移し、別の場合はモーダルが開く |
| プラットフォームの慣例 | ウェブの慣例に従っている(リンクに下線がある、フォームのパターンが標準的である) | ユーザーの期待を損なう独自パターンを使っている |
H5:エラーの予防
コードで確認する項目:
*.tsx で予防パターンを検索します:disabled.*(!|=.*false)|isDisabled|isInvalid
(無効/不正な状態)、required|min.*length|max.*length|pattern=(入力制約)。
検証ライブラリを package.json で確認します:zod|yup|joi|superstruct|valibot。
ブラウザーで確認する項目:
| シグナル | 合格 | 不合格 |
|---|---|---|
| 入力制約 | 日付ピッカー(自由入力ではない)、既知の選択肢にはドロップダウン | 構造化データを自由入力させる |
| インライン検証 | 送信前にフォーカスアウト/変更時に検証 | 送信時のみ検証 |
| 破壊的操作のガード | 確認を要求し、重大な操作では確認文字列の入力を求める | ワンクリックで取り消せない操作が実行される |
| デフォルト値 | 適切なデフォルト値で必要な入力を減らす | すべてのフィールドが空欄で、ユーザーが推測する |
| 無効状態 | フォームが無効な場合、理由を示してボタンを無効にする | 有効なまま、何も通知せず失敗する |
H6:想起ではなく認識
ブラウザーで確認する項目:
| シグナル | 合格 | 不合格 |
|---|---|---|
| ナビゲーション | 主要なセクションがすべてナビゲーションに表示される | 機能が深いメニューに隠れている |
| 検索 | 大規模なデータセットで検索を利用できる | 見つけるためにスクロール/閲覧する必要がある |
| パンくずリスト | 階層構造のコンテンツにパンくずリストがある | 深い階層のページで現在の位置がわからなくなる |
| 最近使用した項目 | 最近アクセスした項目が表示される | ユーザーが覚えていて、最初から移動する必要がある |
| コンテキストヘルプ | ツールチップやプレースホルダーでフィールドを説明する | ラベルだけで説明がない |
H7:柔軟性と効率性
コードで確認する項目:
*.tsx で効率化パターンを検索します:keyboard|shortcut|hotkey|useHotkeys|Cmd\+|Ctrl\+
(キーボードアクセラレーター)、bulk|batch|selectAll|multiSelect(一括操作)。
ブラウザーで確認する項目:
| シグナル | 合格 | 不合格 |
|---|---|---|
| キーボードショートカット | パワーユーザー向けのショートカットを利用できる | マウス操作のみ |
| 一括操作 | 複数選択、一括操作ができる | 1件ずつしか操作できない |
| フィルターと並べ替え | データ量の多いページでフィルター/並べ替えができる | 手動で確認する必要がある |
| カスタマイズ | ユーザーがビュー/設定を構成できる | 画一的な設定しかない |
| クイックアクション | よく使うタスクに1~2回のクリックでアクセスできる | 主要なタスクがメニューの奥に埋もれている |
H8:美的でミニマルなデザイン
ブラウザーで確認する項目:
| シグナル | 合格 | 不合格 |
|---|---|---|
| 情報密度 | 必要に応じて展開する段階的な情報開示 | すべての情報が一度に表示される |
| 視覚的階層 | 主要/副次/補助のコンテンツが明確 | すべてが同じ視覚的な重み |
| 余白 | セクション間に十分な余白がある | 窮屈で密集したレイアウト |
| CTA | ビューごとに主要なアクションが1つあり、明確に区別されている | 複数のCTAが競合している |
| コンテンツの優先順位 | 最も重要なコンテンツが先頭/目立つ位置にある | 重要な情報がスクロールしないと見えない位置に埋もれている |
H9:ユーザーがエラーを認識し、診断し、回復できるようにする
コードで確認する項目:
*.tsx でエラー処理パターンを検索します:error.*message|errorMessage|Error.*:.*'(エラーメッセージ文字列)、try.*catch|\.catch\(|onError(キャッチ箇所)、fallback|ErrorBoundary|error\.tsx(フォールバックコンポーネント。一致数だけでなく、一致したファイルを一覧表示します)。
ブラウザーで確認する項目:
| シグナル | 合格 | 不合格 |
|---|---|---|
| エラーの表現 | 平易な言葉で、コードを表示しない | 「Error 500」、「ECONNREFUSED」、生のスタックトレース |
| 具体性 | 何が問題だったかを正確に示す | 「問題が発生しました」 |
| 回復方法 | 次にユーザーができることを提案する | 行き詰まり、ユーザーが推測する必要がある |
| インラインエラー | 入力項目の近くにフィールド単位のエラーが表示される | フォームの先頭にエラーが1つだけ表示される |
| 空の状態 | 次のアクションを示す、役立つ空の状態 | 空白のページ、「データがありません」 |
H10:ヘルプとドキュメント
コードで確認すること:
*.tsx を検索して、アプリ内ヘルプを確認します:Tooltip|tooltip|HelpCircle|InfoIcon|help.*text|aria-describedby
(コンテキストヘルプ)、onboarding|tour|walkthrough|guide|Onboarding(ガイド付きフロー)。
ブラウザーで確認すること:
| シグナル | 合格 | 不合格 |
|---|---|---|
| コンテキストヘルプ | 複雑なフィールドや機能にツールチップがある | 説明がなく、ユーザーが推測する必要がある |
| オンボーディング | 初回ユーザー向けのガイダンスがある | 複雑な UI にいきなり放り込まれる |
| ドキュメント | アプリ内からヘルプにアクセスできる | 外部ドキュメントを検索する必要がある |
| 入力ガイダンス | プレースホルダー、ヒントテキスト、形式の例がある | 入力フィールドだけがある |
ステップ 3:UX の法則の評価
| 法則 | 原則 | 確認すること | 違反の修正方法 |
|---|---|---|---|
| ヤコブの法則 | ユーザーは、サイトがほかのサイトと同じように動作することを期待します | ナビゲーション、フォームのパターン、チェックアウトフローがプラットフォームの慣習に沿っている | Firecrawl で競合他社を 3 社調査し、共通のパターンを採用する |
| フィッツの法則 | ターゲットが大きく、近いほど、クリックは速くなります | 主要な CTA が十分に大きく、隅に配置されていない。タッチターゲットは 44px 以上 | CTA を大きくし、モバイルでは主要なアクションを親指が届きやすい領域に移動する |
| ヒックの法則 | 比較検討する 選択肢が多いほど、決定に時間がかかります | ユーザーが評価する必要のある選択肢(プラン、アクション、フィルター)がグループ化または段階化されているか、デフォルトが設定されている。既知の項目の検索(国、都道府県)は対象外です。検索を使います | 選択肢をグループ化し、明確な理由がある場合に 1 つを事前選択し、数の多い選択肢は「さらに表示」の背後に隠し、検索には入力補完を使う |
| ミラーの法則 | ワーキングメモリーが保持できるのは約 4~7 個のチャンクです | 画面間で何かを記憶しておく必要がない。コードはグループ化して表示し、「コピー」できる。フィールドにはラベルが常に表示されている。表示されるメニュー項目数の上限を示す法則ではありません。表示されているメニューは記憶するのではなく、読まれるものです | ラベルを常時表示し、以前の選択内容を要約し、コードをグループ化し、フィールドグループにラベルを付ける |
| フォン・レストルフ効果 | ほかと異なる項目は目に留まります | 1 つのビューにつき、塗りつぶしのアクセント付きアクションは 1 つ | 競合する CTA をアウトラインまたはゴーストのバリエーションに格下げする |
| 目標勾配効果/ツァイガルニク効果 | 目に見える進捗と未完了の作業は、ユーザーに完了を促します | 複数ステップのフローで正確な現在位置と合計数が示され、再読み込みや「戻る」操作後も入力内容が保持される | 実際の状態に基づいて「ステップ 2/3」と表示し、下書きを自動保存する(カード番号やコードは保存しない) |
| 認知負荷 | 精神的な負担を最小限に抑えます | 不要なフィールドがなく、ステップ間で記憶に頼る必要がない | デフォルトビューから任意のフィールドを削除し、今必要なものだけを表示する |
| 美的ユーザビリティ効果 | 美しいものは使いやすいと感じられます | 第一印象から信頼感が得られる | ランディングページと主要なフローの見た目を磨く。正しく動作するだけでなく、個性を持たせる |
| テスラーの法則 | 複雑さはなくせず、移動させることしかできません | 複雑なタスクがユーザーに押し付けられず、簡素化されている | スマートなデフォルト、自動検出、段階的開示によって複雑さを示す |
| ドハティのしきい値 | 応答が 400ms 未満になると生産性が向上します | 操作は瞬時に感じられるか | 楽観的 UI、スケルトンスクリーン、先読み、体感速度を上げるテクニック |
| ポステルの法則 | 受け入れる形式には寛容である | 入力の解析(電話番号、日付、大文字・小文字)が柔軟である | 複数の入力形式を受け入れて自動整形し、有効な表記の違いを拒否しない |
| ピーク・エンドの法則 | 人はピークと終わりで物事を評価します | 成功時の瞬間に満足感があるか。エラー発生時に適切に対処できるか | 完了を祝う(紙吹雪、明確な確認)。エラーを和らげる |
ネイティブモバイルアプリでは、次の項目も評価します:主要なアクションが親指の届く領域にある、ターゲットが 44pt/48dp 以上、タブの移動先が 3~5 個、タップ可能な要素すべてに押下時のフィードバックがある、触覚フィードバックは確認時のみ、本文が 16sp 以上。これらの修正には enhance-mobile-native-feel を使います。
ステップ 4:コンテンツとマイクロコピーの監査(Intuit のコンテンツデザイン原則)
4a. 声とトーン
| 原則 | 合格 | 不合格 |
|---|---|---|
| 会話調 | 友人に話しかけるように読める | 法的文書やロボットのように読める |
| 能動態 | 「変更を保存しました」 | 「変更はシステムによって保存されました」 |
| 二人称 | ユーザーには「あなた」、製品には「私たち」を使う | 三人称や受動態を使う |
| 短縮形 | 自然な短縮形を使う(「don't」、「we'll」) | 堅苦しい形式的な表現を使う(「do not」、「we will」) |
4b. 明快さと正確さ
| 原則 | 合格 | 不合格 |
|---|---|---|
| 具体的な表現 | 「現在、Square に接続できません」 | 「問題が発生しました。後でもう一度お試しください」 |
| 用語の一貫性 | 同じ概念には常に同じ言葉を使う | 「保存」「送信」「確認」「適用」を同じ意味で使う |
| シンプルな動詞 | 現在形・過去形・未来形の単純な時制を使う | 進行形・完了形・複雑な時制を使う |
| 短い文 | 1文あたり20語以下 | 複数の節を含む長い文 |
4c. マイクロコピーの品質
ブラウザーで以下の場所を確認してください:
| 場所 | 評価する内容 |
|---|---|
| ボタンのラベル | 行動を促す具体的な表現(単なる「送信」ではなく「請求書を保存」) |
| エラーメッセージ | 平易な言葉で、具体的な原因と復旧方法を示す |
| 空の状態 | 次の操作を促す役立つ内容にする。「データがありません」だけにしない |
| 確認メッセージ | 結果を明確に示す(「この請求書を削除しますか?この操作は取り消せません」) |
| ツールチップ | 簡潔に1つの質問に答える。段落にしない |
| プレースホルダー | ラベルではなく形式のヒントを示す(「例:[email protected]」) |
| 読み込み中のテキスト | 可能な限り状況を伝える(「請求書を読み込んでいます...」) |
| 成功メッセージ | 実行された内容を確認する(「John に請求書を送信しました」) |
4d. 国際化への対応
| チェック項目 | 合格 | 不合格 |
|---|---|---|
| ハードコードされた文字列 | すべての文字列が i18n ファイルにある | コンポーネント内に文字列が直接書かれている |
| 文化的な慣用表現 | 文化に依存しない比喩を使う | 特定の文化に依存する俗語やユーモアを使う |
| テキストの拡張 | 翻訳後に40%長くなったテキストにも UI が対応できる | 文字列が長くなるとレイアウトが崩れる |
| RTL への対応 | 論理プロパティ(margin-inline-start)を使う | 物理プロパティ(margin-left)を使う |
違反箇所を見つける: *.tsx を検索して >([\w\s]{3,})< を探し、i18n 対応漏れの可能性がある、ハードコードされた表示テキストを見つけます。
ステップ5:感情に訴えるデザインと人間中心の評価
5a. 第一印象テスト(5秒テスト)
ランディングページまたはホームページに移動します。スクリーンショットを見て最初の5秒で、以下を確認します。
| 質問 | 判断材料 |
|---|---|
| この製品が何をするものか分かりますか? | [はい/いいえ — 何が伝わるか] |
| 信頼できますか? | [ビジュアルの洗練度、信頼性の手がかり、ブランドの存在感] |
| 最初に何をすればよいか分かりますか? | [明確な CTA、分かりやすい開始地点] |
| 実際の製品のように感じられますか、それともテンプレートのように感じられますか? | [個性、作り込み、汎用的な Bootstrap との違い] |