critique

手順

ステップ 1：準備

レビュー対象のインターフェースについて、目的、利用者、関連するソースファイルの場所を把握します。.impeccable.md または .github/copilot-instructions.md 内に ## Design Context ブロックがある場合は、ブランドと対象ユーザーについて理解するために、ここで読みます。既存のデザインシステム（CSS／トークン／テーマと代表的なコンポーネント）を確認し、一般的なデフォルトではなく、プロジェクト独自の規約に基づいて批評します。

ステップ 2：評価を集める

独立した評価を 2 件実施します。偏りを避けるため、どちらの評価者ももう一方の出力を見てはなりません。

認可されており利用可能な場合に限り、評価ごとに別々のサブエージェントへ委任します。利用可能な場合は、現在の環境のサブエージェントまたは委任の仕組みを使用します。サブエージェントには、調査結果を構造化テキストで返すよう依頼します。調査結果は、まだユーザーに出力しないでください。

それ以外の場合は、各評価を順番に完了し、スキャン結果を読む前にデザインレビューを記録します。レポートが分離されたエージェントによるものか、単一コンテキストで順番に実施したレビューによるものかを明記し、実際には行われていない独立性を示唆しないでください。レビュー専用に起動したサーバーは、ユーザーから稼働状態を維持するよう求められていない限り、報告前に停止します。

タブの分離：ブラウザー自動化を利用できる場合、各評価では必ず新しいタブを作成します。目的の URL がすでに開かれている場合でも、既存のタブを再利用しないでください。これにより、2 つの評価が互いのページ状態に干渉するのを防ぎます。

評価 A：LLM デザインレビュー

関連するソースファイル（HTML、CSS、JS/TS）を読み、ブラウザー自動化を利用できる場合は、ライブページを視覚的に確認します。このために新しいタブを作成し、既存のタブは再利用しないでください。ページに移動したら、ドキュメントタイトルを設定してタブに名前を付けます。

document.title = '[LLM] ' + document.title;

次の観点を評価します。

デザインの固有性：構成、インタラクション、視覚表現はこの製品に根ざしていますか。それとも、変更せずに無関係な製品にも使えるものですか。スキャン結果を見る前に判断してください。視覚的なパターンだけを理由に欠陥と見なしてはいけません。

包括的なデザインレビュー：視覚的階層（視線の流れ、主要アクションの明確さ）、情報アーキテクチャ（構成、グループ化、認知負荷）、感情への訴求（ブランドと対象ユーザーに合っているか）、発見しやすさ（操作可能な要素が明確か）、構成（バランス、余白、リズム）、タイポグラフィ（階層、読みやすさ、フォントの選択）、色（目的に沿った使用、一貫性、アクセシビリティ）、状態とエッジケース（空、読み込み中、エラー、成功）、マイクロコピー（明確さ、トーン、有用性）。

認知負荷（cognitive-load を参照）：

• 8 項目の認知負荷チェックリストを実施します。失敗数を報告してください：0～1 = 低（良好）、2～3 = 中程度、4 以上 = 重大。
• 各判断ポイントで、表示されている選択肢の数を数えます。4 を超える場合は指摘してください。
• 段階的開示を確認します。必要になったときにのみ複雑さが明らかになりますか。

感情の流れ：

• このインターフェースはどのような感情を引き起こしますか。それは意図したものですか。
• ピーク・エンドの法則：最も強い感情が生じる場面はポジティブですか。体験は良い形で終わりますか。
• 感情の落ち込み：重要度の高い場面（支払い、削除、コミット）で不安が急激に高まらないか確認します。進行状況の表示、安心させる文言、元に戻すオプションなどのデザイン上の対策はありますか。

ニールセンのヒューリスティクス（heuristics-scoring を参照）： 該当するヒューリスティクスを 0～4 で採点します。本当に該当しないものは、シンプルなマーケティングページにおける熟練者向けのアクセラレーターなど、理由を添えて n/a と記します。満点は採点対象の項目数の 4 倍です。n/a を 0 点や満点として扱わないでください。

次の内容を含む構造化された調査結果を返します：デザイン固有性の判定、ヒューリスティクスのスコア、認知負荷の評価、機能している点（2～3 項目）、優先課題（何が問題か／なぜか／改善案を 3～5 項目）、軽微な所見、挑発的な問い。

評価 B：パターンの自動スキャン

利用可能なツールを使って、AI スロップの兆候と一般的なデザイン品質の問題を決定論的にスキャンします。

静的ファイルのスキャン（ソースファイルにアクセスできる場合）：

HTML、JSX、TSX、Vue、Svelte ファイルを読み込み、以下のパターンを grep で検索します。

• グラデーションテキスト（bg-gradient と bg-clip-text、WebkitBackgroundClip）
• グラスモーフィズム（backdrop-blur、bg-white/10、オーバーレイ上の bg-opacity）
• ヒーロー指標のレイアウト（単独で大きく表示された数値、単独の統計値に使われる text-6xl 以上）
• 汎用的な AI カラーパレット（カスタマイズされずにプライマリカラーとして使われている #6366f1、#8b5cf6、#f59e0b）
• 同一カードのグリッド（grid-cols-3 と、3 回以上繰り返される同一構造のカード）
• コピーの重複（表示テキストを繰り返す alt テキスト、同じ内容のラベルとプレースホルダー）
• バウンスイージング（アニメーション用クラス内の bounce、elastic）
• 色付き背景上の灰色テキスト
• 入れ子になったカード（カード内のカード）

ブラウザーでの視覚的確認（ブラウザー自動化ツールが利用可能で、対象が表示可能なページの場合）：

プロジェクトにリンターまたはデザインチェックツールが設定されている場合は（package.json のスクリプトを確認）、それを実行します。設定されていない場合は、ブラウザーの開発者ツールで表示中のページを視覚的に確認します。新しいタブを作成し、既存のタブは再利用しないでください。タブに次のラベルを付けます。

document.title = '[Human] ' + document.title;

結果として、ファイルの場所と件数を含むスキャン結果と、誤検出があればその内容を報告します。

ステップ 3：統合批評レポートの作成

両方の評価をまとめて、単一のレポートを作成します。単純に連結してはいけません。LLM によるレビューと検出器の結果が一致する点、検出器が LLM の見落としを検出した点、検出器の結果が誤検出である点を織り交ぜて説明します。

デザインディレクターの視点でフィードバックを構成してください。率直に伝え、批判を和らげないでください。開発者が優れたデザインをリリースするには正直なフィードバックが必要であり、曖昧な指摘や歯切れの悪い意見は時間の無駄です。

デザイン健全性スコア

heuristics-scoring を参照してください

ニールセンの 10 ヒューリスティックのスコアを、次の表に示します。

#	Heuristic	スコア	主な問題
1	システム状態の可視性	?	[具体的な指摘、または問題がなければ「n/a」]
2	システムと現実世界の一致	?
3	ユーザーの制御と自由	?
4	一貫性と標準	?
5	エラーの防止	?
6	想起よりも認識	?
7	柔軟性と効率性	?
8	美的でミニマルなデザイン	?
9	エラーからの回復	?
10	ヘルプとドキュメント	?
合計		??/[適用可能な最大値]	[評価区分]

スコア 4 を付けるのは、そのヒューリスティックに関してインターフェースに重大な問題がない場合に限ります。通常の問題点がある本番環境向けインターフェースでは、20～32 を標準的な範囲とします。

デザインの固有性に関する評価

ここから始めてください。 この成果物は、この製品のために作り込まれた印象を与えますか？

デザイン評価：スキャン結果を確認する前の評価です。一貫性、他のカテゴリーにもそのまま流用できるような構造、製品らしさを表現する機会の見落としについて述べます。

決定論的スキャン：自動検出器が検出した内容を、件数とファイルの場所を添えて要約します。見落としていた問題を検出器が追加で見つけた場合はその内容を記し、誤検出があれば明示します。

ブラウザーでの確認結果：確認したページと実際の結果を説明します。インジェクションが成功し、ページ内で検出器が実行された場合に限り、オーバーレイが表示されたと報告してください。オーバーレイを作成していない場合は、代わりに通常のスクリーンショットまたは手動確認について報告し、利用できなかった手順や未検証の手順も記載します。

全体的な印象

機能している点、機能していない点、最大の改善機会を、1 つの段落で述べます。

良い点

適切にできている点を 2～3 個挙げます。要素名と目に見える挙動を示し、それらが効果的な理由を説明します。

優先度の高い問題

影響の大きい設計上の問題を3～5件、重要度の高い順に示します。

各問題にP0～P3の重大度を付けてください（重大度の定義はheuristics-scoringを参照してください）。

• [P?] 問題点：問題を明確に示します
• 重要な理由：ユーザーにどのような悪影響を与えるか、または目標達成をどう妨げるか
• 修正方法：具体的な対処方法
• 推奨コマンド：この問題に対処できる利用可能なスキルまたはコマンド

ペルソナの危険信号

personasを参照してください

このインターフェースの種類に最も関連性の高いペルソナを2～3人、自動的に選択してください（リファレンスの選択表を使用してください）。.github/copilot-instructions.mdに## Design Contextセクションがある場合は、対象ユーザーやブランド情報をもとに、プロジェクト固有のペルソナも1～2人作成してください。

選んだペルソナごとに、主要なユーザー操作を順にたどり、見つかった具体的な危険信号を列挙してください。

Alex（パワーユーザー）：キーボードショートカットがありません。主要な操作に8回のクリックが必要です。モーダルによるオンボーディングを強制されます。離脱リスクが高いです。

Jordan（初回利用者）：サイドバーのナビゲーションがアイコンのみです。エラーメッセージに「404 Not Found」のような専門用語が含まれています。ヘルプが見当たりません。ステップ2で利用をやめてしまいます。

各ペルソナにとって問題となる、具体的な要素や操作を明示してください。一般的なペルソナの説明を書くのではなく、何が支障になったのかを示してください。

軽微な所見

対処する価値のある、細かな問題について簡潔に記載します。

優先度の高い各問題には、該当する要素、ユーザーへの影響、修正方法を必ず記載してください。軽微な所見は、画面上で確認できる位置または参照元が示されているものに限定してください。

検討すべき質問

より良い解決策につながる、踏み込んだ質問をします。

• 「主要なアクションをもっと目立たせたらどうでしょうか？」
• 「ここまで複雑にする必要はあるでしょうか？」
• 「自信を持って使える状態にするには、どうすればよいでしょうか？」

ステップ4：ユーザーに質問する

所見を提示した後で、実際に見つかった内容に基づいて、的を絞った質問をしてください。推測できない点を明らかにするため、ユーザーに直接確認してください。回答はアクションプランの策定に反映します。

次のような質問をしてください（具体的な所見に合わせて調整し、一般的な質問はしないでください）。

1. 優先する方向性：見つかった問題に基づいて、現時点でどのカテゴリを最も重視するか尋ねます。たとえば、「視覚的な階層、色の使い方、情報過多に問題が見つかりました。まずどの領域に取り組みますか？」と尋ねます。上位2～3件の問題カテゴリを選択肢として提示してください。

2. デザインの意図：批評でトーンの不一致が見つかった場合、それが意図的かどうかを尋ねます。たとえば、「インターフェースから、無機質で企業的な印象を受けます。意図したトーンでしょうか。それとも、より温かみのある、力強い、または遊び心のある印象にすべきでしょうか？」と尋ねます。見つかった問題の解決につながるトーンの方向性を2～3個、選択肢として提示してください。

3. 対応範囲：どの程度の変更を希望するか尋ねます。たとえば、「N件の問題が見つかりました。すべて対応しますか。それとも上位3件に絞りますか？」と尋ねます。「上位3件のみ」「すべての問題」「重大な問題のみ」など、対応範囲の選択肢を提示してください。

4. 制約（任意。関連する場合のみ質問）：所見が複数の領域に及ぶ場合、変更できない箇所があるか尋ねます。たとえば、「現状のままにしておくべきセクションはありますか？」と尋ねます。これにより、ユーザーが完成済みと考えている箇所に計画が及ぶのを防げます。

質問のルール：

• すべての質問で、レポートの具体的な所見に言及してください。「対象ユーザーは誰ですか？」のような一般的な質問はしないでください。
• harnessに構造化された質問の仕組みがある場合はそれを使用し、質問は最大1～3件にしてください。結果を左右する、未解決の対応範囲や意図についてのみ尋ね、既存の許可範囲は維持してください。
• ユーザーが所見を確認できるよう、質問より先にレポートを提示してください。
• 自由回答形式ではなく、具体的な選択肢を提示してください。
• 所見が明確な場合（問題が1～2件だけで、内容も明白な場合など）は、質問を省略してステップ5に進んでください。

ステップ5：推奨アクション

ユーザーの回答を受け取った後で、ステップ4で示されたユーザーの優先事項と対応範囲を反映した、優先順位付きのアクション概要を提示してください。

アクションの概要

ユーザーの回答に基づき、推奨コマンドを優先度順に一覧表示します。

1. /command-name：修正する内容の簡潔な説明（批評結果に基づく具体的なコンテキスト）
2. /command-name：簡潔な説明（具体的なコンテキスト） ...

推奨のルール：

• 現在の環境で実際に利用可能なコマンドまたはスキルのみを推奨する
• まずユーザーが明示した優先順位に従い、次に影響度を考慮して順序を決める
• 各項目の説明には、コマンドが何に重点を置くべきかを把握できるだけの情報を含める
• 各優先課題を適切なコマンドに対応付ける
• 対応する課題がないコマンドは省略する
• ユーザーが対象範囲を限定した場合は、その範囲内の項目のみを含める
• ユーザーが対象外とした領域に触れるコマンドは除外する
• 修正を推奨する項目がある場合は、最後に仕上げまたはクリーンアップのステップを追加する

概要を提示した後、次のようにユーザーに伝えます。

これらは、1つずつ、まとめて、またはお好きな順序で実行するよう依頼できます。

修正後に /critique を再実行すると、スコアの改善を確認できます。