ux-audit

UX 監査

実際のユーザーとして、稼働中の Web アプリを操作します。この監査は操作を最優先します。入力、クリック、送信、確認、スクリーンショットの撮影を行います。静的な DOM の一括確認では、判定を下せません。

判定

監査の結果は、必ず次のいずれかになります。

• 合格 — Critical = 0、High = 0、すべてのハードゲートをクリアし、インタラクションマニフェストが完成している。
• 条件付き合格 — Critical = 0、High = 0、すべてのハードゲートをクリアしているが、Medium／Low の指摘がある。
• 不合格 — Critical または High の指摘が少なくとも 1 件ある、またはハードゲートに不合格となっている。
• 未完了 — インタラクションマニフェストに必須の項目がない、フェーズが実施されていない、または監査のメタチェックに抵触している（マニフェストのタイムスタンプが 0.5 秒未満の間隔に集中している、スクリーンショットがルート数の 2 倍未満、コンソールの確認回数がルート数の 1 倍未満、網羅的な監査でフェーズ 3 の所要時間が 1 分未満）。観察結果に問題がなかったとしても、合格に繰り上げることはできません。

作業に完全なインタラクションマニフェストが含まれていない場合、認められる判定は未完了のみです。「問題なさそうだった」は合格ではありません。所要時間に不自然さがあるのに合格とすることはできません。エージェントは実際に操作して監査をやり直す必要があります。

ハードゲート

以下に該当すると監査は自動的に不合格となり、重大度を引き下げることはできません。

ゲート	しきい値	違反時の重大度
操作中のコンソールエラー	> 0	Critical
操作中のコンソール警告	> 0	High
ネットワーク 5xx	> 0	Critical
認証済みページでのネットワーク 403／404	> 0	High
テスト対象のビューポート／ペインの組み合わせでのレイアウト崩れ	> 0	High
監査対象ページでの axe-core の Critical 違反	> 0	Critical
監査対象ページでの axe-core の Serious 違反	> 0	High
代表的なルートでの LCP（実用的なしきい値）	> 4.0s	High
代表的なルートでの CLS	> 0.25	High
代表的なルートでの INP	> 500ms	High
必須のインタラクションマニフェスト項目の欠落	n/a	未完了
マニフェスト項目間の間隔の中央値が 0.5 秒未満	n/a	未完了（実際には操作していない）

コンソール警告の重大度は、最低でも High です。5xx は自動的に Critical となります。「Medium のコンソールエラー」という分類はありません。このスキルにそのカテゴリは存在しません。

axe-core のしきい値はページごとに適用されます（いずれか 1 ページで違反が 1 件を超えると不合格）。パフォーマンスのしきい値は代表的なルートで 1 回適用されます（ページごとに確認するのは過剰です）。実用的なしきい値は、壊れている状態より十分高く、CWV の厳格なしきい値より十分低く設定されています。しきい値の全容とその根拠については、references/performance-budget.md を参照してください。a11y の設定と重大度のマッピングの全容については、references/a11y-automation.md を参照してください。

既知のノイズに対する許可リスト

アプリによっては、バグではないものの、コンソールやネットワークに既知のノイズが発生するカテゴリがあります（Sentry の情報ログ、ブラウザー拡張機能のメッセージ、認証確認プローブで想定される 401 など）。フェーズ 3 の前に監査設定ファイルを読み込み、許可リストを適用してください。ファイルの検索順は .jez/audit-config.yml → audit-config.yml → .audit/config.yml です。許可リストに含まれる項目もインタラクションマニフェストには記録しますが、指摘としては報告しません。判定ブロックには、生の件数と許可リスト適用後の件数の両方を表示します。例：Console warnings: 3 (1 allowlisted, 2 reportable)。

設定ファイルがない場合、すべてのコンソールエラー／警告を指摘として扱います。形式、意味、表示先の上書きについては、references/audit-config.md を参照してください。

フェーズ（順番どおり）

1. 事前確認 — Persona Lock、ブラウザツール、URL、ビューポート、機能テスト
2. 調査 — サイトマップ、スレッド一覧、要素一覧
3. ウォークスルー — Interaction Manifest、スレッド、要素の網羅、複数ペインのストレステスト、初回利用者の視点、実際の操作のスモークテスト
4. 仕上げ — 見た目の仕上げの確認、コンポーネントの完成度チェックリスト
5. ストレステスト — シナリオバッテリー（11 シナリオ）＋拡張ストレステスト手順
6. 判定 — 判定状態、必須ゲートのスコアカード、完成度向上のロードマップ、再現手順付きの指摘事項
7. 修正と検証 — 指摘事項へのパッチ適用、影響を受けた箇所の再確認、レポートの更新

デプロイ前に 30 秒で確認する場合は、このファイルの末尾にあるドッグフードドリルを使用してください。これはプロジェクトレベルのルールであり、スキルの実行ではありません。

フェーズ 1 — 事前確認

5 つのゲートがあります。いずれかに失敗したら停止してください。

1. Persona Lock

監査には、何よりも先にペルソナが必要です。ペルソナを明確に定めないと、指摘事項が「問題なさそう」といった一般論に偏ります。

次の順にペルソナを特定してください。

1. 引数 — ユーザーが指定した場合（「忙しい保険ブローカーの視点で UX 監査」など）
2. プロジェクトのペルソナ — 既存のペルソナファイルを読み込みます（フォールバック順：.jez/audit-personas/<slug>.md → docs/personas/<slug>.md → personas/<slug>.md → .audit/personas/<slug>.md）。最初に一致したものを使用します。
3. 一度だけ質問 — 「このアプリを使うのは誰で、何を達成しようとしていますか？」

役割、技術への習熟度、時間的な切迫度、感情の状態、デバイスの利用状況を記録します。優れたペルソナは、ユーザーが見落としそうなことを予測できます（「電話対応の合間にいる受付担当者は、スクロールしないと見えない部分を確認しません」）。

選んだペルソナを監査レポートの先頭に記載して、ペルソナを確定します。すべての指摘事項は、そのペルソナの視点から正当化できなければなりません。「開発者なら分かるはず……」と思ったら、そこで止めてください。そのペルソナは開発者ではありません。

明示的なペルソナが別のものであっても、複数ページにわたる機能では必ず初回利用者の視点でも確認してください（必須。フェーズ 3 を参照）。これは AI／社内向けツールで最も見落とされやすい点です。

ペルソナライブラリと作成手順については、references/persona-lock.md を参照してください。

2. ブラウザツール

対象	ツール	理由
認証が必要なアプリ	Chrome MCP	実際にログイン済みの Chrome セッションを使用するため、OAuth、Cookie、RBAC がそのまま機能します
公開サイト	Playwright MCP	ログインは不要です
どちらも利用できない場合	停止	Chrome MCP に接続するか、Playwright をインストールするようユーザーに依頼します

認証が必要なアプリで、新しい Playwright セッションへ黙って切り替えないでください。ログインできなければ監査に意味はありません。Chrome MCP が接続されていない場合は、停止して次のように伝えてください。「Chrome を開き、Claude 拡張機能の［接続］をクリックしてから、もう一度実行してください。」

コマンドについては、references/browser-tools.md を参照してください。

3. URL

デプロイ済み／稼働中のバージョンを優先してください。実際の認証、遅延、CDN、CORS を確認できます。URL の特定方法：プロジェクトの CLAUDE.md／README で「URL」を確認 → スタック設定を確認（wrangler.jsonc、vite.config.ts、next.config.js、config/database.yml、manage.py、.env の APP_URL、wp-config.php）→ lsof -i :PORT（よく使われるポート：5173 は Vite、3000 は Next／Rails、8000 は Django／Laravel、8787 は Wrangler、4321 は Astro）→ ユーザーに確認します。スタック別のガイドは references/project-adaptation.md にあります。ローカル環境を使うのは、ユーザーが希望した場合、または機能が未デプロイの場合に限ります。

4. ビューポート

開始時はウィンドウを 1440×900 に固定してください。フェーズ 3 の複数ペインのストレステストでは、375／768／1024／1280／1440／1920 をテストします。2000px を超えないでください。ハーネスが壊れます。

5. 機能テスト

ウォークスルーを始める前に、ツールが動作することを各 1 回の呼び出しで確認してください。

• スクリーンショットを 1 枚撮影
• コンソールを 1 回読み取り
• ネットワークリクエストを 1 回一覧表示
• 要素セレクターを 1 回クエリ

いずれかが失敗した場合は、監査を開始せずに停止して、接続を修正してください。コンソール出力が見えない状態での監査には意味がありません。

フェーズ 2 — 調査

サイトマップのクロール

ページを監査する前に、すべてのページを網羅した一覧を作成します。

1. ルーター設定 — アプリのルート定義を確認します（React Router、TanStack Router、Next.js app dir）
2. ナビゲーションのクロール — サイドバー／メニューのすべてのセクションとサブセクションをクリックして確認します
3. ディープリンク — CLAUDE.md、ドキュメント、または以前の監査レポートにある URL

ルートごとに1行で、用途を記載します：/app/clients — クライアントの一覧、検索、新規追加。

スレッド一覧

ユーザーの日常を構成する実際のタスクを3～5件特定します。これらが監査の軸になります。

見つけ方：ユーザーに尋ねる、CLAUDE.md／READMEを読む、トップレベルのナビゲーションから推測する。例：保険ブローカー → 保険契約の更新、クライアントの作成、本日の作業キューの確認。プロジェクト管理 → 朝のトリアージ、タスクの更新、クライアントへの概要の送信。Spaces／チャットアプリ → スペースの作成、メッセージの送信、スレッドを開く。

要素一覧

各ルートに到達したら、そのページのインタラクティブ要素をすべて列挙します。一覧は必要に応じて作成します。つまり、最初にすべてをまとめて作るのではなく、ページをたどりながらページごとに作成します。これをカバレッジ指標に使用します：「/app/clients の31要素中29要素をテスト済み」。

フェーズ3 — ウォークスルー（監査そのもの）

インタラクションマニフェスト（必須）

すべてのウォークスルーでマニフェストを作成します。マニフェストがなければ、判定は「未完了」です。

INTERACTION MANIFEST — /dashboard/spaces/marketing-pod
  Persona: SME owner, time-pressed, low tech comfort
  [✓] 14:32:01 Typed "@assistant test" into message input (textarea[placeholder*="message"])
  [✓] 14:32:03 Picked @assistant from autocomplete (li[data-mention-id="assistant"])
  [✓] 14:32:05 Clicked Send (button[aria-label="Send"])
  [✓] 14:32:06 Verified input cleared within 1000ms (textarea.value === "")
  [✓] 14:32:08 Verified message appeared in transcript ([data-message-id] count +1)
  [✓] 14:32:12 Opened thread on the message ([data-thread-trigger])
  [✓] 14:32:13 Verified main column width ≥ 200px after thread open (getBoundingClientRect().width)
  [✓] Console read after each step (0 warnings, 0 errors)
  [✓] Screenshot before + after each step
  [✓] Network requests inventoried (0 5xx, 0 403/404 on auth pages)

各チェック項目には、ツール呼び出し（クリック、スクリーンショット、コンソールの読み取り）が必要です。タイムスタンプとセレクターも記録します。マニフェストが完全でない限り、エージェントは「合格」レポートを作成できません。

監査するページごとに必要な項目：

• 1つ以上の入力欄に入力する（実際のテキストを入力し、クリックだけで済ませない）
• 1つ以上の主要アクションを実行する（送信／保存／送信／作成／公開など、状況に応じたもの）
• 1つ以上のモーダルまたは詳細ペインを開く
• 主要アクションの実行後にコンソールを1回以上確認する
• 主要アクションの実行前と実行後の両方でスクリーンショットを撮る
• アクション後に期待される状態を確認する（入力欄が空になる、成功トーストが表示される、ルートが変わる、リストが更新されるなど）

完全なテンプレートと再生手順については、references/interaction-manifest.mdを参照してください。

スレッドのたどり方

各スレッドで次の手順を行います。

1. アプリの入口から開始する — スレッドの途中から始めないでください。実際のユーザーは/または/dashboardにアクセスします。
2. ペルソナになりきって操作する — ざっと見る人ならざっと見ます。ラベルを読み違える人なら読み違えます。ためらった箇所を記録します。
3. 状態が変わるたびにスクリーンショットを撮る — 初期状態 → ホバー／フォーカス → アクティブ → クリック後 → 読み込み後 → 確認。フィルムストリップが証拠になります。
4. 操作コストを記録する — クリック数、判断箇所、行き止まり、中断からの復帰（手順3でタブを閉じて手順4で戻ったとき、状態は保持されていたか）。
5. 各スレッドの最後に、スクリーンショットをサブエージェントに渡してレビューしてもらう。

各スレッドの最後に、ペルソナの立場で次の質問に答えます：最後まで明確に完了できましたか？また利用したいと思いますか？これを2倍簡単にするために、改善できる点を1つ挙げてください。

references/walkthrough-checklist.mdおよびreferences/workflow-comprehension.mdを参照してください。

要素の網羅

各ルートで、一覧にある要素を操作します。スレッドのウォークスルーですでに操作した要素はスキップします。詳しくはreferences/walkthrough-checklist.mdを参照してください。

すべてのリスト／テーブルについて、データが許す場合は0件／1件／100件／1000件以上のデータ量でテストします。

マルチペインのストレステスト（折りたたみ可能なUIがあるアプリでは必須）

ペインの組み合わせによって、最も深刻なレイアウトのバグが表面化します。2026-04-29のSpacesでの縦書きテキストのバグは、3つすべてのペインを開いた状態で、幅が1024～1280pxの場合にのみ発生しました。サイドバー／メンバー／スレッド／ドロワー／シートがあるアプリでは、次の組み合わせでマトリックスを実行します：1920／1440／1280（バグが発生しやすい）／1024（致命的なバグが発生しやすい）／768／375 × すべて開く、2ペイン、1ペイン、デフォルト。各組み合わせで、最も長いコンテンツをスクロールし、スクリーンショットを撮り、オーバーフロー／クリッピング／縦書きテキストの積み重なりを検出するJSを実行します。マトリックス全体、JSスニペット、自動化についてはreferences/multi-pane-stress.mdを参照してください。

初回利用者の視点（必須）

ロックされたペルソナに加え、複数ページにわたるすべての機能は、初回利用者のチェックに合格する必要があります。これは、社内ツールや AI ツールで最も大きな UX の失敗につながるパターンを検出します。つまり、設計者自身には使える機能でも、まったく新しい利用者が同じ画面にたどり着くと、各コントロールの意味が何もわからないという問題です。

このアプリに初めてサインインし、事前知識もソースへのアクセスも社内ドキュメントもない人の視点になってください。各画面で、次の点を確認します。

質問	検出できる問題
コードやドキュメントを読まずにタスクを完了できますか？	フォームに埋め込まれた技術的な知識
フィールドラベルは内部用語ではなく、わかりやすい言葉ですか？	UI に漏れ出した agentClass、slug、webhook_id
ドロップダウンやピッカーには、ID だけでなく各選択肢の機能が表示されていますか？	snake_case の列挙値、生のクラス名、意味のわからないスラッグ
デフォルト値は、変更せずにそのまま進めるだけの妥当なものですか？	デフォルト値のない必須フィールド、必須の ID 入力欄
値を入力する必要がある場合、有効な値の一覧を見つけられますか？	コンボボックスにすべき自由入力欄
設定が理解できず「スキップ」をクリックしたくなるなら、それは UX のバグです。	任意だがわかりにくい設定が主要な入力項目として表示されている

この視点で問題が見つかったら、画面が技術的には動作していても、指摘事項として記録してください。よくある修正方法としては、テキスト入力欄をピッカーに置き換える、メタデータを表示する、値を自動的に導出する、内部 ID を「詳細設定」の下に隠す、入力欄の近くにガイダンスを追加する、などがあります。

まったく新しいペルソナの利用者が、裏でのサポートなしにタスクを完了できれば、その画面はこのチェックに合格です。

ライブ操作のスモークテスト

コードを読めば、ボタンが存在して onClick を持つことは確認できます。しかし、クリックしたときに実際に確認できる動作が起こるかは確認できません。すべてのページにあるすべての操作可能なコントロールについて、次の手順を実行してください。

1. クリックします。 ポインターが移動し、要素がハイライトされ、クリックが届くことを確認します。
2. Network タブを確認します。 リクエストは送信されましたか？正しい URL 宛てですか？メソッドと本文は正しいですか？
3. DOM を確認します。 新しい要素の追加、要素の削除、状態遷移など、目に見える変化がありましたか？
4. （2）または（3）に変化がなければ、それはバグです。

既知のサイレント失敗を起こすコントロール（ツール呼び出しカードの Approve／Deny、ポップアップがブロックされるダイアログ内 OAuth、非同期バリデーションフォーム、楽観的 UI による削除、1 件ずれるページネーション、TanStack Query のデータが古いままのフィルターチップ、Message-ID がない Reply／Forward）については、完全なサイレント失敗のカタログと SDK コントラクトのチェック（@ai-sdk/react、better-auth、TanStack Query、React Router v7、Radix Dialog、zodResolver）をreferences/live-interaction-smoke.mdで確認してください。

ラウンドトリップ・ワークフローの整合性（必須）

バッテリーのシナリオ 10（Phase 5）で確認します。Phase 3 のウォークスルーの一部としても実行してください。スレッドをたどる中で遭遇した、すべての A→B→A フローについて、先に進む前にラウンドトリップをチェックします。プロトコルの全文はreferences/round-trip-workflows.mdを参照してください。

レスポンシブの確認

すべての幅でレイアウト検出用 JS を実行し、オーバーフロー、クリッピング、テキストの非表示を確認します。レイアウトが切り替わる幅も記録します。完全に網羅するには、上記のマルチペイン・ストレステストと組み合わせてください。

監査中に認証が期限切れになった場合

以前に認証済みだったルートへのナビゲーションまたは API 呼び出しで 401／403 が返された場合、セッションが切れています。黙って再認証しないでください。それ以降の観察結果はすべて無効になります。作業を止め、問題が発生した手順を記録し（サイレントな期限切れ自体も指摘事項です）、判定を Incomplete として終了し、再認証して監査をやり直すことを推奨してください。完全なプロトコルと指摘事項の基準はreferences/auth-expired-handling.mdを参照してください。

Phase 4 — 仕上げ

ビジュアルの仕上げ

AIらしさが出やすい10項目を、ページごとに細かく仕上げます。光学的な中央揃え、入れ子の角丸ルール、スケールから外れたスペーシング、雰囲気だけのグレー、ボーダーの太さのばらつき、ドロップシャドウの方向、標準から外れたアニメーションのタイミング、ホバー時の変化量の調整、下線／大文字の字間、対称性とエディトリアルなリズムです。

さらに、ボタン、バッジ、入力欄、ドロップダウン、カード、タブ、アバター、トーストをコンポーネントごとに光学的に調整します。

DevTools を使ったワークフロー、重大度ガイド、調整用の参考アプリを含むプロトコル全体は、references/visual-polish.md をご覧ください。

コンポーネントの完成度チェックリスト

ページ単位の監査では見落とされる、コンポーネント単位の詳細なチェックです。具体的な証拠資料が必要な「はい／いいえ」の確認項目を、6つのカテゴリに分けています。

1. ボタンとトリガー — 状態の明確さ、意図との一致、マイクロコピー、読み込み状態、階層
2. 入力欄とフォーム — 常時表示されるラベル、マスク、インライン検証、エラーの明確さ、デフォルト設定
3. ナビゲーションと階層 — 現在地の明確さ、クリックの深さ、検索ロジック、固定ヘッダー
4. ビジュアルの一貫性 — アイコンの一貫性、空の状態、角丸、コントラスト比
5. モバイルとタッチ — タップ可能な領域（≥ 48×48）、キーボードの最適化、スワイプジェスチャー
6. パフォーマンスとフィードバック — スケルトン画面、成功トースト、重要度の高い操作に限った確認モーダル

さらに、主要コンポーネントごとに6つのビジュアル状態（デフォルト、スケルトン、空、部分表示、エラー、無効）を確認します。空白画面にスケルトンを表示しただけでは、スケルトンとはみなされません。

レポートの各チェック項目には、証拠資料（スクリーンショット、コンソールの行、DOM セレクター、コード参照）を記載します。証拠がなければ、チェック済みとはみなしません。

チェックリスト全体は、references/perfection-checklist.md をご覧ください。

アクセシビリティの自動チェック（axe-core、必須）

手動のキーボードのみでの操作確認（シナリオ5）では、フォーカストラップやタブ順序の問題を検出できます。一方、構造上のアクセシビリティの問題（見出しレベルの飛び、ホバー／フォーカス時のコントラスト不足、aria-label の欠落、ロールの不一致）の約80％は見逃します。axe-core なら、1ページあたり1秒未満でその80％を確認できます。

監査するすべてのページで、次を実施します。

1. CDN 経由で axe-core を挿入します（script タグ1つ）。
2. ページの読み込みが落ち着いてから axe.run() を実行します。
3. 違反を監査結果に対応付けます（axe の critical は監査の「重大」、axe の serious は監査の「高」など）。
4. ハードゲート：いずれかのページで axe の「重大」が1件以上、または axe の「深刻」が1件以上ある場合、監査は不合格です。

16ルートの監査にかかる合計時間は約16秒です。ビルダーモードの参考ページ（Components、Style guide）は、プロジェクトの audit-config で許可リストに登録します（パスのフォールバック順序については、references/audit-config.md をご覧ください）。完全なスニペット、重大度の対応付け、指摘事項の形式については、references/a11y-automation.md をご覧ください。

パフォーマンス予算（実用重視、必須）

代表的なルート（実際のユーザーが最もよく訪れるページ。通常はダッシュボードかメインの作業画面）で、Performance API の計測を1回実施します。実用的な閾値（LCP < 4.0s、CLS < 0.25、INP < 500ms）は、問題のある状態よりは十分に高く、Google の CWV「良好」基準よりは十分に低い値です。CWV 厳格基準はランディングページやマーケティングチーム向けです。実際のユーザーが長時間利用するアプリの内部画面では、実用的な基準が適切です。

判定ブロックに追加します。いずれかの閾値を超えた場合はハードゲートで不合格にします。Chrome DevTools の Performance トレースを使って原因を診断します（大きなヒーロー画像、遅れて読み込まれるフォント、重いクリックハンドラー、ハイドレーションのコスト）。計測用の完全なスニペット、スロットリング仕様、よくある原因については、references/performance-budget.md をご覧ください。

フェーズ5 — ストレス

シナリオバッテリー（11 シナリオ）

常に 11 個すべてを実施します。画面ごとのテストでは見逃す問題を検出できます。完全なプロトコルはreferences/scenario-tests.mdを参照してください。

1. 初めての利用 — 事前知識ゼロの状態でアプリの使い方を把握し、各スレッドについて英語で 2 分で読める平易なガイドを作成します。
2. 中断されたワークフロー — タスクを開始し、タブを閉じ、更新し、フォーム入力の途中で別のページに移動します。状態は維持されますか？
3. 誤操作からの復帰 — 意図的に誤った項目をクリックします。復帰するには何回クリックする必要がありますか？
4. 再訪ユーザー — スレッドをもう一度実行します。速くなっていますか？ショートカットはありますか？前回の訪問からの変更点がわかりますか？
5. キーボードのみ — すべてのスレッドをキーボードのみで操作します。フォーカスが見えること、タブ順が論理的であること、Escape キーで閉じられることを確認します。
6. 大量のデータ — 500 件以上のレコードを用意します。リストが仮想化され、検索で正しい項目が返され、フィルターで絞り込めることを確認します。
7. 破壊的操作への確信 — 削除／送信／公開／支払い／共有のすべてについて、同意が明確で、文言が具体的で、取り消しが可能であることを確認します。
8. 2 人目のユーザー（ロール） — 権限が制限されたロール（編集者ではなく閲覧者、スタッフではなくクライアント）を使います。読み取り専用ビューと権限エラーを確認します。
9. ライフサイクル上の位置 — 同じロールでも、ユーザー #1（創業者）、#2（最初の招待ユーザー、一部状態のみ）、#N（後から参加したユーザー、データが入力済みのワークスペース）で確認します。それぞれが異なる状況に直面します。
10. 往復ワークフローの整合性 — A→B→A のフローをすべて確認します。B で変更を完了し、リロードせずに戻ったとき、A に新しい状態が反映されていることを確認します。戻る操作が見つけやすいこと、ヘッダーバッジが更新されることも確認します。「戻ったらプロジェクトが空になっている」という問題の最大の原因です。
11. 時間経過を反映したデータ — Day 0／1／7／30 のシード期間を用意します。時間に応じたデータは、件数だけのシードデータでは見逃す問題を検出できます。時間区切り、最新順のソート、cron によって実行される副作用、通知バッジのあふれ、履歴を含む検索のパフォーマンス、グラフの集計単位などが対象です。時間分布のあるデータが存在しない場合に限り、省略できます。

拡張ストレステストレシピ

シナリオに加えて、該当するすべてのレシピをreferences/stress-test-recipes.mdで実施します。

ストレステスト	検出できる問題
空／飽和／長文コンテンツ	開発時に AI がほとんど目にしない端のケースのレイアウト
競合状態（二重クリック、高速入力後のフォーカス移動、低速ネットワーク）	楽観的 UI のバグ、デバウンスの失敗
低速ネットワーク（3G の速度制限）	読み込み状態、スケルトンのリズム、タイムアウト時の UX
動きを抑制する設定（prefers-reduced-motion: reduce）	設定を無視するアニメーション
i18n（長いドイツ語、RTL のアラビア語、CJK の文字幅）	テキストの長さに関するレイアウト上の前提
オフラインモード	再試行／キュー／未保存状態の UX
印刷用スタイルシート	忘れられたメディアクエリ
ハイコントラストモード	forced-colors メディアクエリの処理
実データ風味のデータバッテリー（フォームを受け付けるアプリでは必須）	文字を黙って削除するバリデーション（アポストロフィ、アクセント記号、RTL）、警告のない文字数切り捨て、エスケープされない SQL／XSS のカナリア、扱えないファイルアップロード（.heic、8000×8000 の PNG、50MB の PDF）。AI が構築した UI は、開発用データがきれいすぎることで知られています。

フェーズ 6 — 判定

判定ブロック（レポート冒頭に必須）

═══════════════════════════════════════════════════════════
VERDICT: [Pass / Conditional Pass / Fail / Incomplete]

Persona: [locked persona slug]
Surfaces audited: N / M routes
Interaction Manifest: complete / incomplete (X of Y required entries)

Hard Gates: console errors [N], warnings [N], network 5xx [N], 403/404 auth [N], layout-collapse [N], axe Critical [N], axe Serious [N]   (all must be 0; allowlisted counts shown in parens)
Performance (on /[route]): LCP [N]s / CLS [N] / INP [N]ms — thresholds 4.0s / 0.25 / 500ms

Findings:
  Critical: [count]    High: [count]    Medium: [count]    Low: [count]

Self-critique pass (sub-agent): Drafted: [N]  Kept: [N]  Generic: [N]  Duplicate: [N]

Time per phase: Phase 3 [N]m / Total [N]m   (Phase 3 ≥ 5m for exhaustive)
Manifest plausibility: [N] entries (≥ 6/route), median gap [N]s (< 0.5s = Incomplete), [N] screenshots (≥ 2/route)

TOP 5 (ranked by impact × ease, senior-designer pick):
  1-5. [F-id] Title — one-sentence reason this edges out the others
═══════════════════════════════════════════════════════════

上位 5 件、自己批評パス、そしてフェーズ 7 の後に置く、実際に手に取れるような締めくくりの段落は必須です。これらがない場合、判定は Incomplete です。完全な規律、形式、アンチパターンについてはreferences/audit-output-discipline.mdを参照してください。

自己批評パス（公開前に必須）

調査結果のドラフトを作成した後、新しいサブエージェントにドラフトの一覧を渡し、次のプロンプトを与えます。

「これらの監査結果を読んでください。それぞれに KEEP／GENERIC／DUPLICATE のいずれかを付けてください。KEEP = このアプリ、このペルソナ、この画面に固有。GENERIC = どの Web アプリにも当てはまる。DUPLICATE = 別の調査結果と同じ根本原因。公開前に GENERIC と DUPLICATE を削除してください。」

新しいサブエージェントを使うのは、元のドラフト作成者が自身の成果に思い入れを持っているためです。コンテキスト内で行う自己批評は、削るよりも擁護する傾向があります。パスの結果を記録します。Drafted: 23 Kept: 14 Generic: 5 Duplicate: 4。

監査の監査トリガー（必須。該当した場合は自動的に Incomplete に変更）

シグナル	示唆すること
Phase 3 が 1 分未満／網羅的な監査で manifest の最初から最後までが 5 分未満	ウォークスルーが省略されたか、急いで行われた
manifest のエントリー間の中央値が 0.5 秒未満	エントリーが一括出力されており、実際の操作がない
スクリーンショットがルート数の 2 倍未満／コンソールの読み取りがルート数の 1 倍未満	ページが実際に確認されていない
上位 5 件がない、または水増し用の枠で埋められている	規律が崩れている（audit-output-discipline.md を参照）
自己批評のパスが記録されていない	水増しが取り除かれていない
調査結果に「Suggested fix」／「Consider X」／「Improve Y」が含まれている	水増しに見える、コミットできない修正案
[✓] の PASS 行に、1 文の根拠と成果物がない	雰囲気だけの PASS
「手に取ってみたいか」の段落がない	総合的な判断が行われていない

調査結果の形式（各調査結果で必須）

各調査結果には、ID（重大度を示す英字＋番号）、Layer（Architecture / Interaction / Visual / Feedback / Delight）、Severity、Surface（ルート＋ビューポート＋ペイン）、Persona、Reproduce（番号付きの手順）、Observed、Expected、Evidence（スクリーンショットのパス＋コンソール／ネットワークのキャプチャ）、Suspected location（file:line）、Smallest possible patch（具体的でコミット可能な内容。「Suggested fix」／「Consider X」は不可）を必ず含めてください。再現手順＋証拠＋疑わしい箇所が記載されていない調査結果は却下されます。「X を改善する」「Y を検討する」「Z をより良くする」といった水増し修正案は、自己批評のパスで Incomplete に変更されます。記入例と Five-Layer Hierarchy は references/report-template.md と references/perfection-checklist.md にあります。規律に関するルールは references/audit-output-discipline.md を参照してください。

手に取ってみたいか（最後の段落として必須）

各監査の最後に、テンプレートを使わずに 1 段落で、このアプリが物理的なオブジェクトだったら、手に取ってみたいと思うか？に答えてください。ここだけは雰囲気が主題です。チェックリストでは表せない総合的な判断を記します。形式と記入例は references/audit-output-discipline.md にあります。

完璧さへのロードマップ（必須）

調査結果を次のように分類してください。

• すぐにできる改善（24～48 時間） — マイクロコピー、ホバー状態、コントラストの修正、CSS の 1 行調整
• 構造的な改善（1～2 週間） — プリミティブの置き換え、ルートの再構成、複数ペインのリファクタリング
• 高度な仕上げ（ローンチ後） — マイクロアニメーション、スケルトンのバリエーション、パーソナライズされた空の状態

レポートの全体構成は references/report-template.md にあります。

Phase 7 — 修正と検証

レポートの後に、次のループを提案します。

「Critical が N 件、High が M 件見つかりました。今すぐ修正して再検証しますか？」

はいの場合：

1. 調査結果をファイル／領域ごとにまとめる
2. それぞれ修正する
3. 影響を受ける範囲だけを再確認する（アプリ全体ではなく）。バグが見つかった元の操作も含め、新しいスクリーンショットを撮る
4. レポートを更新し、✓ fixed、✗ still present、または ⚠ new issue found のいずれかを記す
5. 「このセッションで修正済み」の概要で締めくくる

翌日の監査を待たず、1 回のセッションでループを完了できます。

ux-extract と brains-trust との相互参照

パターンライブラリがある場合（フォールバック順：.jez/artifacts/ux-extracts/<ref>.md → docs/ux-extracts/<ref>.md → audits/extracts/<ref>.md）、開始前に読み、調査結果の基準として使用してください。

判定の後、セカンドオピニオンによるレビューとして、任意で dev-tools:brains-trust を実行してください（4～6 週間ごと）。調査結果を統合する際は、(reproduction-steps, suspected-location) で重複を除去してください。別のモデルで見つかった同じバグは、確認が 2 件ある 1 つの調査結果であり、2 つの調査結果ではありません。Confirmed by: 行を追加してください。2 つ目のレポートをそのまま追記しないでください。ノイズが増え、重大度が実際より高く見えてしまいます。

30秒のドッグフーディングテスト（プロジェクトレベルのルール）

監査には時間がかかります。変更ごとのデプロイ前チェックには、CLAUDE.md にプロジェクトルールを追加することをおすすめします。

UI の変更を「完了」と宣言する前に、30秒のドッグフーディングテストを実行してください：

1. 該当するページを開く
2. 入力欄に何か入力する
3. 主なアクションをクリックする
4. 次の状態を2秒間確認する
5. 関連するビュー（スレッド、モーダル、詳細）を開く
6. コンソールを確認する いずれかの手順で予期しない動作があれば、その変更はまだ完了ではありません。

6つの手順で、約30秒です。すぐに表面化する動作上のバグを発見できます。週次の完全な ux-audit と併用してください。

Playwright の主要フローテスト

監査では現在の問題を見つけます。テストはリグレッションを防ぎます。主要なフローを対象とする Playwright テストを10～15件作成することをおすすめします。スターター例（送信後に入力欄がクリアされる、マウント時にコンソール警告がない、スレッドを開いた後のメッセージ列の幅が200px以上、@-メンションがちょうど1つのピルになる、など）はreferences/playwright-killer-flows.mdを参照してください。CI 経由ですべてのデプロイ時に実行します。

自律性

• そのまま実行してよいこと：ページの移動、スクリーンショットの撮影、ページの読み取り、レイアウト検出用 JS の挿入、偽のテストデータを使ったフォームの送信、レポートファイルの作成、スクリーンショットレビュー用サブエージェントの起動。
• 事前に確認すること：破壊的な操作（削除、送信、公開、支払い）。破壊的操作の信頼性テストを行う場合は、そのシナリオを実行する前に一度確認してください。
• 停止して確認すること：外部の人にメールを送信したり、通知したりする操作。

実行時の規律

1. サブエージェントではなく、メインセッションから監査を進めてください。 操作をまたいだ状態は監視を続けているセッションに保持されています。新しいサブエージェントは初期状態から始まるため、二次的な発見を見逃します。
2. ブラウザツールを直接使ってください。 メインセッションから Chrome MCP または Playwright MCP を使います。新しいエージェントにスクリーンショットを渡して意見を求めないでください。
3. バリエーションを加えて、新たな発見がなくなるまで繰り返してください。 各パスの後に、新しい観点（異なるペルソナ、異なるワークフロー、異なる入力量、異なる開始地点）を試します。完全なパスを実行して新たな発見がなくなった場合にのみ終了します。

30分を超える見込みの監査では、メインセッションと並行して15分ごとの /loop チェックインを設定してください。これにより発見内容が記録され、セッションの状況が整理され、自然な終了の合図が得られます。詳しくはreferences/long-running-check-in-pattern.mdを参照してください。

参照ファイル

タイミング	読むもの
スキル横断の出力規律（Top 5、自己批評、最小パッチ、証拠によるPASS、保留事項）	references/audit-output-discipline.md
プロジェクトへの適応 — デフォルト以外のスタック（NextAuth/Lucia/Devise/Django auth、Prisma/TypeORM/ActiveRecord のシード、WordPress/Rails/Django の URL 検出、アプリ種別ごとのペルソナライブラリ）	references/project-adaptation.md
ペルソナライブラリ＋執筆プロトコル＋ペルソナ過剰適用パターン	references/persona-lock.md
監査中に認証が期限切れになった場合 — プロトコル＋ヘッドレスのテスト認証再開	references/auth-expired-handling.md
データのシーズニング期間（Day 0 / 1 / 7 / 30）＋プロジェクトのシードスクリプト構成	references/data-seasoning.md
監査設定の許可リスト形式＋セマンティクス＋画面ごとの上書き	references/audit-config.md
Interaction Manifest のテンプレート＋再生プロトコル	references/interaction-manifest.md
複数ペインのストレステストマトリクス＋自動化スニペット	references/multi-pane-stress.md
画面ごとの評価項目、レイアウト検出用 JS	references/walkthrough-checklist.md
目的地の見つけやすさ、メンタルモデル、ページ間の連続性	references/workflow-comprehension.md
11 シナリオそれぞれの完全なプロトコル	references/scenario-tests.md
拡張ストレステストの手順（競合、低速ネットワーク、モーション軽減、i18n）	references/stress-test-recipes.md
コンポーネントレベルの完全性チェックリスト（6 カテゴリー＋6 状態）	references/perfection-checklist.md
AI らしさのカタログ、視覚的な中央揃え、デザイントークンの規律	references/visual-polish.md
サイレント失敗の防止策＋SDK コントラクトチェック	references/live-interaction-smoke.md
Playwright の重要フローテストのひな形	references/playwright-killer-flows.md
レポート形式、判定ブロック、重大度の基準、再現手順の形式	references/report-template.md
ブラウザツールのコマンドとビューポートに関する注意事項	references/browser-tools.md
往復ワークフローの整合性（A→B→A パターン）	references/round-trip-workflows.md
アクセシビリティの自動テスト（axe-core の挿入＋重大度のマッピング）	references/a11y-automation.md
実用的なパフォーマンス予算（Performance API による LCP/CLS/INP）	references/performance-budget.md
15 分の /loop による長時間監査の監督	references/long-running-check-in-pattern.md

ヒント

• ためらいはすべて発見事項です。 何をクリックすればよいか考えるために手が止まったなら、報告する価値のある摩擦です。
• スポイトツールを積極的に使いましょう。 くすんだグレー、トークンにない色、デザインシステムのずれを見つける最速の方法です。
• カバレッジは計算できます。 棚卸し済み ÷ テスト済みです。レポートには比率を記載しましょう。
• スクリーンショットのレビューにはサブエージェントを使い、発見事項は逐次記録しましょう。 ブラウザーを操作しながら、1 回のループで 200 枚のスクリーンショットを分析してはいけません。レポートファイルは、コンテキストよりも安価なメモリです。