ux-audit

UX 監査

一度に1つのサーフェスを対象にした、再現可能な標準ベースの UX レビューです。ベンチマークは次の2つを組み合わせたものです。

1. Jenifer Tidwell 著『Designing Interfaces』 — 優れたインターフェースが何で 構成されているか を示すパターン言語です。references/pattern-catalog.md を参照してください。
2. ux スキル — フローがどのように 動作すべきか を示す、LobeHub の実行チェックリストです。

監査では、サーフェスがどのパターンを使用しているか（また、それがどの程度うまく機能しているか）、そしてエクスペリエンスのどこに弱点があるか（各ギャップはチェックリスト項目に紐づけられます）を確認します。繰り返し発生するギャップは、新しい ux チェックリスト項目として反映されます。監査そのものが、具体例を示すリファレンスになります。

1回の実行につき、1つのサーフェスを監査してください。アプリ全体を一度に確認するには範囲が広すぎます。製品の成長に合わせてページごとに再実行します。これが「継続的」の意味です。

3つのレイヤー — 検出したい内容に応じて選択

監査は1つの作業ではありません。各指摘は、それを実際に 確認できる レイヤーでのみ信頼できます。各レイヤーには専用の手順ファイルがあります。対象のサーフェスに必要なものを実行してください。

レイヤー	ファイル	内容	検出できること	コスト
L1 静的	layer-1-static.md	コードを読む	状態や分岐の欠落（空・エラー・再試行）、下書きが保持されない、パターンがない、構造上の問題	低コスト、オフライン、すべての監査で実施
L2 ビジュアル	layer-2-visual.md	レンダリングされたサーフェスのスクリーンショット	実際の視覚的階層と主要な操作要素、余白・コントラスト・配置、切り詰め・オーバーフロー、空・読み込み中・エラーの実際の表示、レスポンシブのブレークポイント、ダークモード・ライトモード	中程度。レンダリングが必要
L3 動的	layer-3-dynamic.md	受け入れテストと計測を通じて、実際のユーザージャーニーを進める	進行中・ロック中の状態、強制的に発生させたエラー・空の状態、ステップ N から N+1 に進めるか、フォーカス・キーボード操作、CLS / LCP / INP / 長時間タスクの定量化	高コスト。実行環境と認証が必要

カバレッジマトリクス — 各レイヤーで判断できること

基本ルール：判定は、それを確認できるレイヤーから出す必要があります。 コードだけを見て、視覚的または実行時の判定を下してはいけません。

指摘の種類	L1	L2	L3
空／エラー分岐がない、再試行がない、下書きが保存されない、パターンが存在しない	✅	—	—
実際の視覚的な階層／主要な操作要素が主たるアクションか	❌ 誤解を招く	✅	✅
余白／配置／コントラスト／切り詰め／オーバーフロー／ダークモード	❌	✅	—
画面外の選択状態、空／読み込み中／エラーが実際にどう表示されるか	❌	✅	✅
レスポンシブのブレークポイント（狭い画面／モバイル）	❌	✅	✅
進行中／ロック状態、強制的なエラー／空状態、機能による制御	❌	❌	✅
ジャーニーのつながり（ステップをまたいだ前進の流れ）	弱い	弱い	✅
フォーカス順序／キーボードでの操作可能性	❌	❌	✅
CLS / LCP / INP / 長時間タスクの数値	❌	定性的な評価のみ	✅
2つのバリアントのどちらが 優れている か（A/Bテストの勝者）	❌ 誤解を招く	❌ 誤解を招く	✅（＋分析）

⚠️ このルールで防げる、よくある落とし穴：コード内の variant プロパティだけを見て、「主要なボタンは1つ」や「空状態は実際のページとして存在する」と判断してしまうことです。これらは L2 での判定です。必ずレンダリング結果で確認し、L1だけで判断してはいけません。

ティア分け — 毎回3つすべてを実行する必要はありません

• L1は常に実行 — すべての画面を対象にした、迅速で網羅的なベースラインです。
• 指摘がレイアウト、階層、レンダリングされた状態、またはレスポンシブ対応に関する場合は、L2を追加します。
• ジャーニーをたどる必要がある場合、L1／L2では到達できない状態を強制する場合、またはパフォーマンス（CLSなど）を測定する場合は、L3を追加します。

--l1 / --l2 / --l3 を指定すると、実行対象を1つのレイヤーに絞れます。デフォルトはL1（スクリーンショットが提供されている場合はL2も追加）です。

基本原則：感覚ではなく証拠

指摘にはすべて、その証拠として file:line（L1）、Read tool で確認したスクリーンショット（L2）、または取得した値／スナップショット（L3）を示します。重要な主張をする前に、それを確認できるレイヤーで確かめてください。「存在しない」という誤った指摘は、指摘がないよりも悪い結果になります。

基本原則：自社の成果物だけでなく、画面の クラス を基準に評価する

コードを読んで見つけられる欠陥は、自分たちが構築したものに限られます。そもそも一度も構築していない機能については、構造上、見つけようがありません。完全に欠けている機能には、grep できる file:line も、使われていない分岐も、配線が中途半端なボタンも残らないからです。チェックリストが守るのは、存在する状態の品質 です。画面のこの クラス にどのような状態が期待されるかまでは教えてくれません。

そこで、コードを読む前に（または並行して）、画面の クラス と、その分野での慣例を明確にしてください。成熟した類似製品は、この画面をどのように構築しているのか、また、初期バージョンで見落とされがちな機能は何かを調べます。たとえば OAuth 同意画面のクラスに求められる慣例（GitHub / Google / Okta）として、どのアカウントで認証を許可するのかを表示し、ユーザーがアカウントを切り替えたり、再認証したりできるようにすること、リクエスト元のアプリ名とスコープを表示すること、拒否できるようにすること、後から許可を取り消す方法を案内することが挙げられます。ファイルピッカー、チェックアウト、共有ダイアログにも、それぞれ独自のクラス慣例があります。まず、期待される機能のリストを書き出し、それに照らして不足を監査してください。そうしないと、監査では既存の経路を磨くだけで、欠けている経路を見落としたまま容認してしまいます。

❌ OAuth 監査の初回では、社内の状態チェックリストだけを基準に同意画面を評価したため、ボタンの優先順位や再試行の不足を指摘する一方で、最大の問題を見逃しました。それは、同意画面で現在のアカウントに固定され、アカウントを切り替える手段がないことです（OAuthConsent/Login.tsx）。これは、同等の OAuth プロバイダーならどこも実装しているクラス慣例です。競合製品の慣例を調べれば最初の数分で見つかりますが、コードだけを調べても決して見つかりません。

基本原則：2 つのバリアントを比較する際、勝者の判定は成果に関するものであり、作り込みに関するものではありません

監査で同じ画面の 2 つのバリアント（「Agent と Classic のオンボーディングでは、どちらが優れているか？」など）を比較するとき、陥りがちなのは、実際の問いであるどちらがユーザーの目標達成により貢献するかではなく、どちらがより優れた作りか（より洗練されている、パターンが豊富、AI をより活用している）を判定してしまうことです。ゲートウェイ／インタースティシャルの画面（オンボーディング、同意画面、ペイウォール、読み込み中のゲート）では、両者に大きな違いが生まれます。多くの場合、最善のバージョンは最も簡素なバージョンです。画面は、ユーザーとユーザーが求めているものとの間に立つからです。作り込みは成果ではなく、成果物が充実しているほうが、かえって劣ることはよくあります。

そのため、バリアントを比較する際は、次の点を守る必要があります。

1. 成功指標を最初に明示し、それを基準に評価します。 オンボーディングなら、パターンの豊富さではなく、完了率＋価値実感までの時間＋離脱率です。チェックアウトなら、コンバージョンです。評価を始める前に指標を記載しないと、作り込みを評価してしまいがちです。
2. 勝者の判定は L3／分析データを条件とします。 「どちらのバリアントが優れているか」は行動上の成果に関する問いであり、カバレッジマトリクスでは CLS／INP と並ぶ L3 の項目に該当します。L1／L2 から比較できるのは、仕組み（「A のエラー復旧はより充実している」「B のほうが手順が少ない」など）です。勝者を宣言してはいけません。ファネルデータがなければ、「根拠が不十分です。判断に必要な情報は次のとおりです」と述べ、そこで止めます。「勝者はこれです」と自信を持って判定したうえで、但し書きとして「L3 が必要」と付け加えるのは失敗です。但し書きが判定を正当化するわけではありません。
3. ユーザーの負担を主要な評価軸とし、ゲートウェイ画面では逆方向に重み付けします。 時間、手順数、トークン数、レイテンシです。ユーザーが通り抜けたい画面では、一定の閾値を超えると、充実度はユーザーを引き込むものではなく、負担になります。
4. 意味感は、機能の充実度ではなく、ユーザーの実際の目標に照らして評価します。 ユーザーの目標が別のところにあるのに、フロー自体にユーザーを引き留めるのは、たとえエンゲージメントが高くても、意味感が低くなります。正しく評価すれば、そうした場面では意味感と自然さはファストパスを支持します。「会話的／AI 活用度が高い／作り込みがある」ことを、「より意味がある」ことと取り違えないでください。
5. 組織が実際に示している選好を証拠として読み取ります。 機能フラグ、どちらのバリアントがフォールバックになっているか、最も制約の厳しいプラットフォーム（デスクトップ）でどちらが使われているか、最近のロールバックなどです。全環境共通のフォールバックがバリアント B なら、B が信頼されているベースラインであり、A 側に立証責任があります。こうしたシグナルを「上限と下限」の違いとして片付けないでください。
6. 適切な比較対象を選び、実際の意図の分布に応じて重み付けします。 AI ツールの初回利用時のベンチマーク対象は、オンボーディングがほぼなく、すぐに入力欄へ進める ChatGPT／Claude／Cursor です。手厚いオンボーディングを評価する SaaS のセットアップウィザード（Notion／Linear）ではありません。理想的な熱心なユーザーではなく、最も多いユーザー（スキップしたいユーザー）を評価します。

❌ このスキル自体の誤り：L1 の評価で、Agent のオンボーディングは Classic より洗練され、会話的である（完了画面が充実している、名前の候補を提案する、画面遷移がある）という理由から、Agent のほうが「優れている」と判断しました。そして、意味感 ≳ 自然さ > 確実性だと結論付けました。しかし、本番環境での Agent の有効なガイダンスの完了率は高くなく、ユーザーは遅すぎると感じていました（チャットではなく、ツールを求めていました）。そのため、組織はClassic にロールバックしました。上記の誤りはすべて当てはまっていました。作り込みを成果と取り違え、意味感を逆方向に評価し、コストを脚注に追いやり、L3／分析データが必要な指標について L1 から勝者を宣言し、機能フラグで制御されていること／Classic にフォールバックすること／デスクトップでは除外されていることを示すシグナルを説明して退けていました。

基本原則：「冗長な」コントロールは、削除する前に構成の問題として考える

L1 が同じことをしているように見えるコントロールを 2 つ見つけたとき、反射的に削除しようとしがちです。片方を削除する、隠す、統合する、複製したほうに違いを持たせる、といった対応です。そうするのはやめましょう。同じ 意図 を持つ 2 つのコントロールでも、対象範囲が異なることはよくあります。その範囲の違いを正直に表すには、削除するのではなく、レイアウトで表現します。対象範囲が広いほうを、タイトル付きの兄弟要素として見える形に昇格させます。削除は 動作 層での対応です。よりよい解決策はたいてい構成層にあります。これは、ux のチェックリストをたどりながら references/pattern-catalog.md を開かない監査が、ベンチマークの半分を取りこぼすまさにその部分です。チェックリストで扱うのは状態、操作の勢い、下書きの安全性です。タイトル付きセクション／均等グリッド／センターステージ を表す語彙はないため、チェックリストだけを読むと毎回「重複排除」に手を伸ばすことになります。「冗長／重複」という指摘に対する対応策を書く前に、パターンカタログの確認（L1 のステップ 2）を行い、こう問いかけてください。意図は同じでも、対象範囲は異なるのか？ → 対応策は削除ではなく、兄弟要素にすることです。

❌ CC AskUserQuestion の監査では、質問ごとの「自分で入力する」ボックスと全体の「または直接入力する」という選択肢を冗長だと判断し、隠す／統合するという削除策を提案しました。 これらは冗長ではありません。質問ごとのボックスは 質問単位 が対象で、もう一方は フォーム全体 が対象です。構成層での解決策は、質問が 1 つならもう一方を隠し、複数ある場合は質問ブロックの見える対等な要素として表示することです。これは、チェックリストだけの確認では見つからなかった タイトル付きセクション の対応です。カタログを確認しなかったため、よりよい答えを逃しました。

基本原則：不足だけでなく、よい点も報告する

壊れている点だけを列挙する監査は、バグ報告にすり替わっています。求められているのは使用されているパターン と、その出来栄えです。つまり、強みも表面的な表の飾りではなく、正式な指摘事項です。よく設計された状態機械、保存に失敗しても残る下書き、オープンリダイレクト対策、賢いデフォルト設定は、いずれもよい事例です。それらを名前で示し、file:line を記載して、特に優れたものには ✅ 注目点 の印を付けてください。理由は 3 つあります。

• 学びにつながります。 よい事例は、フィードバックループにおける ✅ 側の要素です。ギャップが ❌ の例になるのとまったく同じように、ux のチェックリスト項目で参照される肯定的な例になります。よい事例を報告しない監査では、チェックリストの ❌ 側ばかりを改善することになります。
• 品質を守ります。 「これを後退させない」ことも指摘事項です。次のリファクタリングでは、どの動作が重要な基盤なのかを把握する必要があります。example/task-detail.md の維持すべき強みのブロック（読み込み／見つからない状態の状態機械、失敗しても保持されるコメントの下書き、すべて実行のプレビュー → 確認フロー）と、example/home.md の ✅ 注目点 の行（空のまま送信したときの「今日のヒント」へのフォールバック、ドロワーでは画面遷移しないという表面上の契約）が、まさにその一覧です。
• 重大度を調整できます。 全体的に優れた画面にあるギャップと、全体的に弱い画面にあるギャップでは、受け止め方が異なります。よい事例は、ギャップの優先順位を付ける際の基準になります。

❌ これによって防げるのは、「使用されているパターン」の ✅ の行が「永続的」「優れている」「模範的」といった一語だけのチェックになり、すべてのギャップには段落を割くという偏りです。つまり、よい事例がチェックボックスに格下げされてしまいます。example/task-detail.md を手本にしてください。特に優れたパターンにはそれぞれ file:line と ✅ 注目点 の注記があり、強みがギャップと同じくらい明確に示されています。

重大度の基準（共通）

• 🔴 信頼を損なう — データ／入力の消失、停止状態／永久状態、失敗を隠す誤解を招く「空」の表示、送信のサイレントな失敗。
• 🟠 行き詰まらせる、または誤解を招く — 次に進む手段がない、状態が曖昧、処理中のフィードバックがない、実際のページではない空の状態。
• 🟡 使いづらさ／一貫性の欠如／惜しい改善点 — 予測可能性、冗長な操作、段階的な情報開示の不足、CLS によるガタつき。この段階は最も見落とされやすいものです。正確性を探すチェックでは 🔴／🟠 に偏り、細かな一貫性のズレ（選択肢には番号チップがあるのに、自由記述の行にはないなど）や、ラベルのない操作要素を見過ごしがちです。それ以外はしっかりしている画面では、1 回は意識してインターフェースの細部に注目してください。そうしないと、こうした点が記録されないままになります。

出力（共通）

作成例 references/example/home.md を参照してください。まず、どのレイヤーを実施したかを記し、そのうえで次の項目を記載します。

1. 使用されているパターン — パターンファミリー別にまとめた表（L1/L2 より）。各項目の所見を 1 行で記載し、目立った項目には ✅ の行として 亮点 を付け、実際の根拠（file:line）を示します。単に 1 語だけでチェックを付けてはいけません。
2. 強み／良い事例（後退させないこと） — 表の脚注ではなく、専用のセクション（## … — Strengths / good cases）を設けます。箇条書きの ✅ 亮点 項目では、それぞれ、この画面で_うまくできている_振る舞い、その根拠（file:line）、そしてそれが_なぜ重要な土台となるのか_を示します。これは回灌ループの ✅ 側であり、次回のリファクタリングで「後退させない」ためのリストです。ux の ✅ examples として採用できるほど優れたものには、→ landed as ux <ref> ✅ と注記し、Skill-feedback セクションに結び付けます。すべての監査でこのセクションを作成してください。画面全体が本当に弱い場合は、省略せず、そのことを明記します。形式は example/fleet.md §2 を参照してください。
3. エクスペリエンスのギャップ — 優先度順に並べます。各項目には、問題点、違反している ux チェックリスト項目／カタログパターン、発見元のレイヤー＋根拠、1 行の改善策を記載します。
4. スキルへのフィードバック — 既存のチェックリスト項目に該当する実例と、ux への追加に値する新たな汎用的なギャップ、および ✅ examples として採用する価値のある良い事例を記載します（下記の回灌を参照）。

指摘事項を反映する（共通）

指摘事項を書き出しただけでは、監査は完了していません。反映して初めて完了です。監査を完了するには、以下の3つのステップすべてが必須です。

• 具体的なバグ → 同じ実行中に修正します。最低でも 🔴 はすべて修正してください。未対応の項目は、その理由（プロダクト上の判断が必要、サーバーの変更が必要、確認用のレンダリングが必要など）とともに、レポートのギャップ一覧に残します。
• 一般化できるギャップ → ux にフィードバックする（必須）。 毎回の実行で、ux スキルに必ずフィードバックを反映します。この画面に限らず一般化できる指摘ごとに、該当するモジュールへ ux チェックリストの項目（ルールと、該当箇所を❌例として示す✅／❌例）を追加または強化します。既存の項目で要件を網羅できていない場合に限り、ux のクイックレビューに短い補足を追加します。例と実装の詳細はモジュールに残してください。これにより監査は_継続的_なものになります。実行のたびに、チェックリストが開始時よりも鋭くなります。一般化できるギャップが本当に見つからなかった場合は、その旨をレポートの Skill-feedback セクションに明記してください（既存ルールの適用を検証した事例に限ります）。何も記載せずに終えることは認められません。
• 特に優れた事例 → ux にフィードバックし、ルールを洗練させる（単に例を添えるだけではありません）。 フィードバックのループには2つの側面があります。ギャップはチェックリスト項目の❌例を強化し、優れた事例は✅例を強化します。ただし、優れた事例を反映する価値があるのは、ルールに新たな学びをもたらす場合だけです。✅例を加えるのは最低限であり、目標はルールの文面を洗練するか、現在のルールにまだ明記されていない潜在的なサブルール／チェックリスト項目を抽出することです。監査で特にうまくできているパターンを見つけたら、「この実装が行っている手法のうち、ルールがまだ求めていないものは何か？」と問い、それを反映します。文面を洗練し、単一のトリガーとしてまとめられているルールを実際のケースに分割し、チェックリスト項目を追加するなどして、該当箇所を✅例として示してください。すでに完成しているルールをただ再度例示するだけでは、ほとんど価値がありません。新たな区別の必要性を明らかにする事例こそが重要です。（例：Fleet のスクロール表示では、「再実行のトリガーには非同期の到着と、命令的な追加後の描画という2種類がある」「スクロール方向はリストの方向に合わせる」という点を抽出し、Read §1.3 に反映しました。また、スケルトンでは「高さだけでなく、テキストの幅の比率を合わせる」という点を抽出し、Feedback §4.1 に反映しました。どちらも、それまでは明記されていませんでした。）
• 監査結果 → references/example/<page>.md として保存し、次回の実行でテンプレートとして使えるようにします。

監査と ux スキルは閉じたループです。監査の評価基準となるのが ux であり、ux の実効性を保つ仕組みが監査です。フィードバックを省略するとループが途切れ、監査は一度限りのレビューに成り下がります。

関連スキル

• ux — この監査で評価する実行チェックリストと、一般化できる指摘を反映する場所です。
• acceptance — L3 が実行する自動化フレームワーク（agent-browser CDP：スナップショット／eval／スクリーンショット／GIF）です。L3 では、Step 0 の環境と認証が正常であることを前提とします。
• deep-review — コードレベルのレビューです。このスキルはその設計レベルの姉妹スキルです（deep-review の ux の観点ではコードレビュー内のフローを確認し、このスキルでは画面全体を監査します）。
• skills-audit — 同じ「定期的に、根拠に基づいて監査する」という形式を、スキルカタログに適用します。