audit

audit スキルの概要

audit ができること

audit スキルは、ページ・機能・コンポーネントに対して構造化された技術的 UI レビューを実行し、ばらつきのある所感ではなく、スコア付きレポートとして返すスキルです。対象はアクセシビリティ、パフォーマンス、テーマ適用、レスポンシブ挙動、フロントエンドのアンチパターンといった、実装品質を測定しやすい領域です。さらに、検出した問題を P0 〜 P3 の重大度で優先順位付けし、対応順まで示します。

どんな人・チームに audit スキルが向いているか

この audit スキルは、毎回レビュー観点を手作業で作り直さず、再現性のある UX Audit ワークフローを回したいフロントエンドチーム、デザインエンジニア、UX エンジニア、プロダクト開発者に向いています。主観的なデザイン批評ではなく、コードや実装を踏まえたレビューが必要な場合に特に有効です。

このスキルが本当に解決する仕事

多くのユーザーが欲しいのは単なる「フィードバック」ではありません。知りたいのは、たとえば「このページは出荷してよい状態か」「何が最優先で壊れているか」「どれがアクセシビリティ上の blocker で、どれが後回しにできる整理項目か」「次に別の agent や engineer は何を直すべきか」といった判断材料です。audit は、まさにそのトリアージ用途に作られています。

一般的なプロンプトと何が違うのか

通常のプロンプトでも広い観点の助言は出せますが、audit は意思決定に使いやすい形に寄せてあります。理由は次のとおりです。

• 複数領域にまたがる診断スキャンを前提にしている
• 5 つの観点で明示的にスコアリングする
• 問題の発見と修正の提案を分けて扱う
• P0-P3 の重大度で優先順位を出す
• 好みではなく実装上の根拠を求める

導入前に押さえたい重要な依存条件

導入時の最大のつまずきやすさはコンテキスト不足です。このスキルは、先にデザイン文脈を集めることを前提にしています。スキル内の指示でも /frontend-design を呼ぶようになっており、まだデザインコンテキストがない場合は監査前に /teach-impeccable を実行するよう求めています。ここを省くと、出力の精度と一貫性は落ちます。

audit スキルの使い方

audit の導入方法

このリポジトリでは、SKILL.md 内に専用の install コマンドは用意されていません。そのため、GitHub 上の Claude skills を普段インストールしている標準フローを使います。たとえば次のように追加できます。

npx skills add https://github.com/pbakaus/impeccable --skill audit

インストール後は、スキルが audit として利用可能か確認してください。あわせて user-invocable: true が付いているため、直接呼び出せる点も把握しておくとよいです。

最初に読むべきファイル

まずは .claude/skills/audit/SKILL.md を読んでください。このリポジトリでは、実際に使ううえで重要なロジックのほぼすべてがこのファイルに入っています。前提条件、対象範囲、評価軸、スコアリングモデル、出力フォーマットの期待値まで、主要情報はここに集約されています。rules/、resources/、補助スクリプトのような支えはないため、この skill file を丁寧に読むことが成果に直結します。

前提ワークフローを理解する

audit スキルを使う前に、次の順番を守ってください。

1. /frontend-design でデザインとプロダクトの文脈を集める
2. その文脈がまだないなら /teach-impeccable を実行する
3. その後で、対象のページ・機能・コンポーネントに対して audit を実行する

これは重要です。audit 自体は技術寄りのレビューですが、アンチパターン、テーマ整合性、実装品質を正確に判断するには、前提となる文脈が必要だからです。

入力に何を渡すべきか

このスキルの引数ヒントは次のとおりです。

[area (feature, page, component...)]

良い入力例は、監査対象が具体的に切り分けられているものです。たとえば以下のような指定が向いています。

• checkout page
• mobile navigation drawer
• pricing cards component
• settings form validation flow

一方で、the app や the UI のような広すぎる入力は、監査対象のスコープが曖昧になり、浅い出力になりやすいです。

audit スキルがチェックすること

audit ワークフローでは、次の 5 つの観点を診断します。

• accessibility
• performance
• theming
• responsive design
• anti-patterns

その後、各観点を 0-4 でスコアリングし、レポートとしてまとめます。UX Audit 用途で audit を使うなら、この構造が特に有効です。というのも、漠然とした UX 品質の懸念を、実装根拠付きの指摘へ落とし込めるためです。

このスキルがやらないこと

audit は修正ツールではなく、診断ツールです。設計上、問題を直すことではなく、問題を記録・整理することに主眼があります。再現性のある品質レビューが欲しいなら導入価値がありますが、同じステップで自動的にコード修正、リファクタ、見た目の再設計提案までしてくれる想定で入れると期待がずれます。

ざっくりした依頼を強い audit プロンプトに変える

弱いプロンプト:

• Run audit on my homepage

より強いプロンプト:

• Run audit on the homepage hero and signup flow. Focus on keyboard access, semantic structure, responsive layout between 320px and 1440px, theme token consistency, and obvious performance risks. Return scores by dimension plus P0-P3 findings and a fix order.

こちらのほうが良い理由:

• スコープを定義している
• ユーザージャーニーを明示している
• リスクが出やすい領域を先に示している
• スキル本来の出力形式を指定している

audit 活用のおすすめワークフロー

実務で使いやすい audit の流れは次のとおりです。

1. 1 つのページまたはコンポーネントを選ぶ
2. 先にプロダクトとデザインの文脈を渡す
3. audit を実行する
4. スコアと重大度を確認する
5. P0/P1 の指摘を実装タスクに落とし込む
6. 修正後に再度 audit を実行する

この流れにすると、QA、リリース前レビュー、デザインシステム整理のゲートとして audit スキルを使いやすくなります。

良い audit 出力の条件

有用な audit 結果には、少なくとも次の要素が含まれているはずです。

• 各観点ごとのスコア
• 具体的な実装上の指摘
• P0 から P3 までの重大度ランク
• 次に取るべきアクション
• コードや UI 挙動にひもづく根拠

もし出力が一般論のベストプラクティスばかりで、優先順位付けが弱いなら、原因はスキルの質というより、コンテキスト不足かスコープ過大であることが多いです。

導入判断のためのリポジトリ読解ルート

この audit スキルを入れるべきか見極めたいなら、最短の確認ルートは次の順です。

1. SKILL.md の frontmatter で呼び出し方法と用途を確認する
2. MANDATORY PREPARATION
3. Diagnostic Scan
4. 各スコアリング section
5. 最終的なレポート構造

この順に読めば、一般的な監査プロンプトよりも自分のワークフローに合うかどうかを短時間で判断できます。

audit の品質を上げる実践的なコツ

• 一度に監査する対象は 1 エリアに絞る
• 重要なデバイス幅やレイアウト状態を明示する
• UI がデザインシステムや theme tokens を使っているか伝える
• sign-in、checkout、forms など重要フローを指定する
• 根拠付きの指摘だけを求める
• 純粋なトリアージが目的なら修正提案を不要と伝え、必要なら後段で remediation を分けて依頼する

audit スキル FAQ

audit は UX Audit に向いている？

はい。UX Audit に実装レベルの根拠が必要なら、audit は相性が良いです。audit for UX Audit が特に強いのは、アクセシビリティ上の欠落、レスポンシブ崩れ、テーマ不整合、ユーザー体験に影響するフロントエンド品質の問題を見たいときです。一方で、ブランド戦略、情報設計、定性的なユーザビリティ調査には向きません。

AI にページレビューを頼むのと何が違う？

一般的なレビュー依頼だと、好みの話、プロダクト上の助言、コードの推測が混ざりやすくなります。audit スキルは、観点・スコア・重大度が明示されている分、技術的な品質レビューに用途を絞っていて、より安定して使えます。その構造があるため、出力を engineering に引き渡しやすいのも違いです。

この audit スキルは初心者でも使いやすい？

中程度です。ワークフロー自体はシンプルですが、前提となるコンテキスト収集ステップは見落としやすいです。初心者でも使えますが、WCAG の論点、semantic HTML、responsive behavior、design tokens といった基本的なフロントエンド概念を理解しているほど結果は良くなります。

どんなときに audit を使わないほうがよい？

次のような目的には audit は向いていません。

• ユーザーリサーチの統合
• ビジュアルブランドの批評
• コンバージョンコピーのレビュー
• 同一ステップでの直接的なコード修正
• 対象を絞らないアプリ全体監査

こうしたケースでは、別スキルか、より目的を絞ったプロンプトのほうが適しています。

audit はコードへのアクセスが必要？

コード実装を確認できる状態がベストです。このスキルはコードレベル監査として設計されているためです。レンダリング後の UI 説明だけでも一定の推論はできますが、確信度と指摘の具体性は下がります。

リリース判定は audit だけで足りる？

通常は足りません。技術レビューの層としては強力ですが、runtime testing、browser/device checks、analytics review、human QA の代わりにはなりません。唯一の品質ゲートではなく、構造化された audit パスの 1 つとして扱うのが適切です。

audit スキルを改善するには

audit 結果を良くするには、まずスコープを狭くする

最もよくある失敗は、対象範囲を広げすぎることです。プロダクト全体を一度に audit すると、優先順位が平坦になり、根拠の密度も落ちがちです。より良いのは、1 フロー、1 ページ、あるいは 1 コンポーネント群ずつ監査することです。

audit 実行前にコンテキストを渡す

このスキルは /frontend-design、場合によっては /teach-impeccable を前提にするため、その依存条件をきちんと満たすことが最も手軽で効果的な改善策です。共有するとよい情報は次のとおりです。

• 対象ユーザー
• ページ上の主タスク
• 想定レスポンシブ breakpoints
• デザインシステムのルール
• 既知の制約や意図的な tradeoffs

意見ではなく根拠を求める

最初の出力が曖昧に感じたら、次のプロンプトでは条件を絞ってください。

• Cite the element or pattern causing each issue
• Separate verified implementation issues from inferred risks
• Do not include subjective visual preferences

こうすると、audit の内容が実装に根差したものになり、信頼しやすくなります。

重大度ランクの精度を上げる

すべての指摘が同じ重さとは限りません。P0-P3 を実務で使いやすくするには、自分たちの文脈で何を重大とみなすかを先に伝えるのが有効です。たとえば以下のような条件です。

• 法務上または WCAG 上のリスク
• タスク完了を妨げる blocker
• mobile 限定の崩れ
• 共有コンポーネントでの回帰
• checkout や auth flow に影響する問題

audit は 2 パスで回すと精度が上がる

質の高い進め方は次の 2 段階です。

1. 1 回目: 広めの diagnostic scan
2. 2 回目: 最低スコアだった観点を深掘りする

たとえば accessibility の点数が最も低かったなら、次は keyboard flow、semantics、forms、contrast にだけ絞って再度 audit します。大きな 1 回の監査で全部済ませるより、修正計画に落とし込みやすい結果になりやすいです。

audit の後に修正ステップをつなぐ

audit 自体は問題を直さないため、改善はワークフローの連結で生まれることが多いです。

• audit を実行する
• P0/P1 の問題を抜き出す
• それぞれを修正用プロンプト、engineer、または code-editing agent に割り当てる
• 変更後に再度 audit を実行する

こうすると、audit スキルは単なるレポート作成ツールではなく、品質改善ループの起点になります。

レスポンシブと theming のチェックは入力で強化する

responsive や theming の品質を重視するなら、その点を明示的に伝えてください。追加すると有効な指定例は次のとおりです。

• Check behavior at 320px, 768px, and 1440px
• Check dark mode and token consistency
• Flag hard-coded colors, spacing drift, and component state inconsistencies

ここまで具体化しないと、audit 側が言及はしても、深く検査しないまま終わることがあります。

引き継ぎやすい audit 出力形式に調整する

レポートを engineers に渡す予定なら、次の項目を含めるよう依頼すると効果的です。

• issue title
• severity
• affected area
• why it matters
• suggested fix direction
• validation method after fix

この形式なら、情報として読むだけでなく、そのまま backlog に載せやすくなります。

最初の audit が弱かったと判断できるサイン

次のような結果なら、audit をやり直す価値があります。

• 例のない抽象的な助言ばかり
• 観点別のスコアがない
• P0-P3 の優先順位付けがない
• 技術レビューというよりデザイン批評に見える
• 指定した対象エリアへの言及がない

こうした症状は、たいていスキル自体の問題ではなく、プロンプトかコンテキスト設計の問題です。

最初のレポート後にどう改善していくか

最初の audit のあとに、単に anything else? と聞くのはおすすめできません。代わりに、次のような切り方をしてください。

• Expand only the P0 and P1 issues
• Re-audit the form flow for accessibility only
• Convert findings into an engineering checklist
• Challenge the performance score with stronger evidence
• Rerun audit after fixes and compare score changes

このように具体的な再依頼をすると、同じ広い依頼を繰り返すよりも、audit スキルから得られる価値が大きくなります。