design-is

デザインの審査

使用しないケース

• 定型的な UI コードレビュー → /review を使用します
• 純粋なコピーの修正 → 別途コピー編集を行います
• 成果物がまだない、デザイン前のアイデア出し → /make-plan から直接始めます

あなたはオーケストレーターです。Dieter Rams の 10 原則に照らしてデザインを監査し、各原則を根拠とともに採点し、判定（NEW／REFINE／REDESIGN）を決定して、すぐに実行できるプロンプトとともに /make-plan に引き継ぎます。

実装コードは作成しません。根拠を引用したスコア、判定、/make-plan への引き継ぎプロンプトを作成します。

10 原則（Dieter Rams）

以下の順番を厳守して、各原則を監査します。それぞれ 0～3 点で採点し、根拠を 1 つ以上示します（file:line、スクリーンショット内の領域、コピーの抜粋、測定値など）。

1. 優れたデザインは革新的である — 形を進化させていますか、それとも模倣していますか？革新はテクノロジーを基盤としますが、それ自体が目的ではありません。
2. 優れたデザインは製品を有用にする — 主要なタスクに役立っていますか？有用性を重視し、妨げになるものは排除します。
3. 優れたデザインは美しい — 美しいですか？美しくなり得るのは、十分に仕上げられたものだけです。美的品質はウェルビーイングに影響します。
4. 優れたデザインは製品を理解しやすくする — 構造によって機能が明確になっていますか？少なくとも、説明がなくても理解できる状態になっていますか？
5. 優れたデザインは目立たない — 邪魔にならず、控えめですか？装飾品でも芸術作品でもありません。自己表現の余地を残します。
6. 優れたデザインは誠実である — その実態に見合ったことだけを謳っていますか？虚偽の約束、操作、価値の誇張はありません。
7. 優れたデザインは長持ちする — 時が経っても古びず、流行を追わず、時代遅れに見えませんか？
8. 優れたデザインは細部に至るまで徹底している — 端の処理、空の状態、エラー、フォーカスリング、モーションカーブまで考慮されていますか？丁寧さと正確さは、ユーザーへの敬意を表します。
9. 優れたデザインは環境に優しい — リソースを節約していますか？汚染を最小限に抑えます。ソフトウェアの場合は、バンドルサイズ、エネルギー、注意力、認知負荷が対象です。
10. 優れたデザインは可能な限り少ないデザインである — より少なく、より良く。不可欠なものに集中し、純粋さとシンプルさを取り戻します。

ユーザーが「Dieter Braun」と書いていた場合は、Dieter Rams のことを指しています。インラインで訂正せず、正しい原則を使用してください。

委任モデル

根拠の収集（コンポーネントの読み取り、コントラストの測定、要素数のカウント、トークンの調査、agent-browser によるスクリーンショット取得）にはサブエージェントを使用します。採点と判定の統合はオーケストレーターが担当します。根拠を示さずに採点したサブエージェントの報告は却下し、再度タスクを割り当てます。

サブエージェントの報告要件（必須）

根拠収集を行う各サブエージェントの回答には、以下を必ず含めます。

1. 参照した情報源 — 正確なファイルパスと行範囲、またはスクリーンショット内の領域
2. 具体的な所見 — 存在するもの、欠けているもの、および引用や値
3. 原則ごとの事実（意見ではなく）— 採点はオーケストレーターに委ねる
4. 既知のギャップ — 調査できなかった内容と、その理由

成果物

すべての成果物は、リポジトリのルート（またはユーザー指定のプロジェクト）にある DESIGN-IS-<YYYY-MM-DD>/ に格納します。

• 00-scope.md — 監査対象（URL、コンポーネントのパス、画面）と入力資料
• 01-evidence.md — サブエージェントが収集した原則ごとの根拠
• 02-scorecard.md — 原則ごとの 0～3 点のスコア、一行の理由、合計点
• 03-verdict.md — NEW／REFINE／REDESIGN の判定と理由
• 04-handoff-prompt.md — 選択した判定に対応する、コピーして使える /make-plan プロンプト

フェーズ

フェーズ 0：対象範囲の確定（必ず最初に実施）

ユーザーに確認するか、依頼内容から推定し、00-scope.md に記録します。

• 何を監査しますか？（公開 URL、リポジトリのパス、Figma のフレーム、コンポーネント名）
• 主なユーザーと主要なタスクは何ですか？
• 制約（ブランド、技術スタック、期限）
• 参考デザインや競合があれば記載します

まだ存在しないデザインについてユーザーが尋ねている場合は、フェーズ 1～2 を省略し、判定を NEW としてフェーズ 3 に進みます。

フェーズ 1：証拠の収集（並列実行）

サブエージェントを並列で起動します。それぞれ、以下の必須フィールドのみを返してください。文章の段落やスコアは含めないでください。

1. 構造の証拠のサブエージェント（必ず起動） 返す必須フィールド：

• 監査対象画面上のインタラクティブ要素の総数
• 主要コンポーネントツリーの最大ネスト深度
• 繰り返しパターンの数（同じ目的で同じアフォーダンスが複数箇所に現れる数）
• 不要なプロパティ／未使用インポートの数
• 各数値のファイル名と行番号による引用

2. ビジュアルの証拠のサブエージェント（必ず起動） モード：対象がアクセス可能な URL または実行中の開発サーバーの場合は、agent-browser スキルを使ってスクリーンショットを撮影し、計算済みスタイルを調査します。対象が実行中のインスタンスを持たない静的リポジトリの場合は、ソース CSS／トークン／コンポーネントファイルを読み取り、推定した事実のみを報告します（「INFERRED」と明記してください）。 返す必須フィールド：

• 観測されたスペーシングスケール（px 配列）
• 観測された文字サイズスケール（px 配列）
• 色の種類の数（実際に描画または参照されている一意な hex／oklch トークンの数）
• 主要テキストで観測された最も低いコントラスト比
• 存在する状態のチェックリスト：空／読み込み中／エラー／成功／フォーカス／無効。それぞれ存在または欠落

3. コピーと誠実さのサブエージェント（必ず起動） 返す必須フィールド：

• ユーザー向け文字列すべてのリストとファイル名・行番号
• 根拠のない誇大表現としてフラグ付けされた項目
• ダークパターンとしてフラグ付けされた項目（強制的な継続、隠れたコスト、偽の希少性、確認の際に罪悪感をあおる表現）
• 専門用語／不明瞭なラベルとしてフラグ付けされた項目と、平易な表現への置き換え案
• ラベルと動作の不一致、および双方のファイル名・行番号

4. 重量と摩擦のサブエージェント（必ず起動） 返す必須フィールド：

• 初期 JS バイト数（数値）
• 主要画面のネットワークリクエスト数（数値）
• インタラクティブになるまでの時間（ミリ秒。実測または推定し、方法を明記）
• アイドル画面上のアニメーション数（数値）
• 初回読み込み時の通知／バッジ／モーダルの数（数値）

5. アクセシビリティの証拠のサブエージェント（任意。意味のあるインタラクティブ UI 画面が対象にある場合のみ起動し、操作のない静的なランディングページでは省略） 返す必須フィールド：

• テキストトークンごとの WCAG コントラスト合否
• 主要コントロール全体のフォーカス順序リスト
• すべての主要アクションにキーボードでアクセスできるか（アクションごとに「はい／いいえ」）
• ARIA ランドマークの数
• スキップリンクの有無（はい／いいえ）

原則 → サブエージェントの対応関係（オーケストレーターはスコアリング時に使用）：

原則	情報提供元
#1 革新的	オーケストレーターのみ（すべての証拠に基づく判断）
#2 有用	構造、アクセシビリティ
#3 美的	ビジュアル
#4 理解しやすい	構造、コピーと誠実さ、アクセシビリティ
#5 邪魔にならない	構造、ビジュアル
#6 誠実	コピーと誠実さ
#7 長く使える	オーケストレーターのみ（すべての証拠に基づく判断）
#8 徹底している	ビジュアル
#9 環境に優しい	重量と摩擦
#10 必要最小限のデザイン	構造

オーケストレーターは、すべてのサブエージェントのレポートを統合して 01-evidence.md を作成します。出典の引用がない調査結果は却下してください。サブエージェントはスコアリングを明示的に禁止されています。スコアリングを行うのはオーケストレーターのみで、フェーズ 2 の評価基準を使用します。

Phase 2: スコアカード（ORCHESTRATOR）

オーケストレーター自身が10項目すべてを採点します。採点を委任してはいけません。

各原則について、02-scorecard.md に次のように記入します。

N. Good design is <principle> — Score: X/3
   Evidence: <one-line summary citing 01-evidence.md anchors>
   Justification: <one sentence on why this score, not the one above or below>

原則ごとの採点基準（そのまま適用してください。監査対象の画面に最も当てはまるシグナルのレベルを選んでください）：

#1 革新性 — 3：5つ以上の類似製品で見られないパターンを導入し、節度をもって実装している。2：既存のパターンを明確に改善している。1：競合他社をわずかに変えて模倣している。0：競合他社のフローを丸ごとコピーしている。 #2 有用性 — 3：主要タスクを最少の手順で完了でき、ユーザーを迷わせる操作がない。2：主要タスクは完了できるが、隣接する画面で手順が増える。1：主要タスクの完了に不要な回り道が必要。0：監査対象の画面では主要タスクを直接サポートしていない。 #3 美しさ — 3：余白、文字組み、色が一貫したシステムに従っており、孤立したスタイルがない。2：監査対象の画面全体で軽微な不整合が2つ以下。1：不整合が3～5つ、または違和感のある逸脱が1つある。0：視覚的なシステムがない、または視覚的なノイズが目立つ。 #4 わかりやすさ — 3：初めて使うユーザーが主要なコントロールをすべて正しく説明できる。2：1つのコントロールにツールチップが必要。1：2～3つのコントロールが不明瞭で、専門用語もある。0：ヘルプなしでは主要な操作を特定できない。 #5 目立たなさ — 3：UI要素が背景に退き、コンテンツが主役になっている。2：UI要素は見えるが控えめ。1：装飾がコンテンツと競合している。0：UI要素がコンテンツより目立つ。 #6 誠実さ — 3：すべての主張、バッジ、ラベルが実際の動作と1対1で対応している。2：軽微な誇張が1つ以下（例：「強力」を1回だけ使用）。1：誇張が2つ以上、またはダークパターンが1つある。0：誤解を招くフローがある（強制的な継続、隠れた費用、偽の希少性）。 #7 長く使えること — 3：視覚表現に古びたトレンドの要素がなく、3年後も現代的に見える。2：古びた要素が1つある。1：古びた要素が2～3つある（スキューモーフィズムの残滓、流行のグラデーション、トレンドのタイポグラフィ）。0：特定の年のトレンドとして見えるデザイン。 #8 十分な配慮 — 3：空、読み込み中、エラー、成功、フォーカス、無効のすべての状態が用意され、適切に設計されている。2：1つの状態が欠けている、または粗い。1：2～3つの状態が欠けている。0：4つ以上の状態が欠けている、またはブラウザーのデフォルト状態になっている。 #9 環境への配慮 — 3：初期 JavaScript が100KB未満で、アイドル時のアニメーションがなく、ダークモードに対応し、prefers-reduced-motion を尊重している。2：500KB未満で、モーションが制御されている。1：500KB～2MBで、モーションが常に有効。0：2MB超、または自動再生動画がある、またはダークモードを無視している。 #10 デザインは必要最小限に — 3：すべての要素に存在意義があり、どれかを削除するとタスクに支障が出る。2：削除可能な要素が2つ以下。1：削除可能な要素が3～5つある。0：ページが装飾または重複する操作要素に支配されている。

採点ルール：

• 同点時のルール：2つのスコアで迷った場合は、低い方を選びます。寛大さより評価の一貫性を優先します。
• 平均ではなく最悪のケースを採点：監査対象の画面に代表的な事例が複数ある場合、平均ではなく最悪の事例を採点します。
• ボーナスなし、重み付けなし：スコアは0～3の整数です。各原則の重みは同じです。10項目の合計が総合スコアとなり、最大30点です。

Phase 3: 評価（ORCHESTRATOR）

次のルールに従って3つの評価のいずれかを選び、03-verdict.md に記入します。

• NEW DESIGN — まだデザインが存在しない、または既存の成果物がスタブ／ワイヤーフレームで、維持すべき実際の設計上の決定がない。
• REFINE — 総合スコアが20点以上で、個別の原則に0点がない。基盤は良好なので、改善を重ねます。
• REDESIGN — 総合スコアが20点未満、または重要な原則（通常は#2 有用性、#4 わかりやすさ、#6 誠実さ）に0点がある。目的から見直してやり直します。

評価を1文で述べます。その後、次のフェーズの計画の軸となる、効果の高い改善策を3～5つ挙げます。それぞれを特定の原則と根拠となる証拠に結び付けてください。

評価において避けるべきアンチパターン：

• コードベースが大規模だからという理由でREFINEを推奨する（サンクコストはデザイン原則ではありません）
• 1つの画面が見苦しいからという理由でREDESIGNを推奨する（対象範囲を絞ってください）
• 適切なREDESIGNが必要なのにNEWを推奨する（批評から逃げないでください）

フェーズ 4：/make-plan への引き継ぎ

04-handoff-prompt.md を作成し、判定に一致する /make-plan プロンプトをフェンス付きコードブロックでちょうど 1 つ記載します。プロンプトは自己完結している必要があります。次のセッションでは、この監査内容が引用されていない限り確認できません。

該当するテンプレートを使用してください。すべての <bracket> を埋めます。フェーズ 3 の上位 3〜5 件の改善策を、それぞれ根拠となる箇所とともに、一字一句そのまま記載します。

引用の手順（必須。以下の 3 つのテンプレートすべてに適用）： 引き継ぎを出力する前に、すべての <bracket> プレースホルダーを監査内容に基づく具体的な内容に置き換えます。03-verdict.md の判定段落と上位 3〜5 件の改善策を、テンプレートにそのまま埋め込みます。「DESIGN-IS-.../03-verdict.md を参照」のような、参照先のみの記述は残さないでください。次のセッションでは監査ファイルにアクセスできません。出力する引き継ぎは、外部情報を一切参照せずに読めて、実行に移せる内容でなければなりません。

テンプレート：新規デザイン

/make-plan Design <product/screen/component name> from scratch.

Primary user: <who>
Primary task: <one sentence>
Constraints: <brand, stack, deadline, accessibility floor>

Non-goals (do not design these now):
- <explicit out-of-scope item 1>
- <explicit out-of-scope item 2>
- <explicit out-of-scope item 3>

Reference principles to optimize for, in order:
1. Useful (#2) — <what useful looks like here>
2. Understandable (#4) — <what clarity looks like here>
3. As little design as possible (#10) — <what restraint looks like here>

Deliverables for the plan:
- Information architecture (one screen map or component tree)
- Primary flow wireframe (low-fi, labeled)
- Token decisions (type scale, spacing scale, color count cap)
- States checklist (empty, loading, error, success, focus, disabled)
- Honesty audit on every user-facing string before ship

Anti-patterns to guard against (specific to NEW):
- Decoration without function
- Novel interactions without precedent
- Copy that overpromises
- Designing for screens the Non-goals list excluded

テンプレート：デザインの改善

/make-plan Refine <product/screen/component name> based on a Dieter Rams audit (total <X>/30).

Verdict paragraph (quoted from 03-verdict.md):
> <paste the one-sentence verdict here>

Keep (already strong, do NOT touch in this pass):
- Principle #<N> (<name>) scored 3 — Evidence: <file:line or anchor>. Regression check: <what to grep / re-test to confirm it still scores 3 after the refine>.
- <repeat for every principle that scored 3>

Fix in priority order (top 3–5 moves from the audit, verbatim):
1. <Principle # — short name>: <specific move>. Evidence: <file:line or anchor>.
2. <Principle # — short name>: <specific move>. Evidence: <file:line or anchor>.
3. <Principle # — short name>: <specific move>. Evidence: <file:line or anchor>.
4. <optional 4th>
5. <optional 5th>

Out of scope for this refine pass: <explicit list — what NOT to touch>

Deliverables for the plan:
- Per-fix: target files, exact change, verification step
- Token/spec changes consolidated in one place
- Regression checklist for every "Keep" item above

Anti-patterns to guard against (specific to REFINE):
- Adding new abstractions where a direct change suffices
- Restyling areas that already scored 3
- Scope creep into structural redesign (if structure must change, this should be REDESIGN, not REFINE)
- Letting fixes mutate principles outside the priority list

テンプレート：デザインの再設計

/make-plan Redesign <product/screen/component name>. Current design failed audit at <X>/30 with critical gaps in principles <comma-separated list of 0-scored or 1-scored load-bearing principles>.

Verdict paragraph (quoted from 03-verdict.md):
> <paste the one-sentence verdict here>

Why redesign and not refine: <one sentence — usually a load-bearing principle (#2, #4, or #6) scored 0, or total is below threshold>

Preserve from current design (MUST be non-empty — at minimum, name the brand tokens):
- <specific element 1, with file:line>
- <specific element 2, with file:line>
- (if structurally nothing survives, write: "Brand tokens only — color palette and logo. Discard everything else.")

Discard (MUST be non-empty — name the structural patterns causing the failures):
- <pattern 1>. Evidence: <file:line>. Caused failure on principle #<N>.
- <pattern 2>. Evidence: <file:line>. Caused failure on principle #<N>.

Top 3–5 moves from the audit (verbatim):
1. <Principle # — short name>: <specific move>. Evidence: <file:line>.
2. <Principle # — short name>: <specific move>. Evidence: <file:line>.
3. <Principle # — short name>: <specific move>. Evidence: <file:line>.

Redesign principles in priority order:
1. <Principle # — name> — <what success looks like>
2. <Principle # — name> — <what success looks like>
3. <Principle # — name> — <what success looks like>

Deliverables for the plan:
- New information architecture (not derived from old)
- New primary flow (low-fi, labeled, compared side-by-side to current)
- States checklist (empty, loading, error, success, focus, disabled)
- Migration path for users currently on the old design
- Cutover criteria (when is the old design retired)

Anti-patterns to guard against (specific to REDESIGN):
- Porting old structure under new styling
- Keeping both designs behind a flag indefinitely
- Redesigning to follow a trend rather than the principles above
- Treating the Preserve list as optional — it must be filled before this handoff is valid

重要な原則（監査担当者向け）

• 好みより根拠を重視する — すべてのスコアに出典を示します。「なんとなく違和感がある」は指摘ではありません
• 意図ではなく、実際の状態を評価する — デザインとは、描かれたものではなく、実際にリリースされるものです
• 監査にも誠実さを貫く — 合計が 28/30 なら、ユーザーが再設計を望んでいても「改善」と判定します。12/30 なら、ユーザーが改善を望んでいても「再設計」と判定します
• 判定は 1 つに絞る — 「新規」「改善」「再設計」のいずれか 1 つを選び、判断を濁さないでください
• 実装ではなく、引き継ぎを行う — design-is の役割は /make-plan プロンプトまでです。その先は /make-plan と /do が担います
• 判定を確定する — 02-scorecard.md を作成したら、フェーズ 3 のルールに従って機械的に判定します。望ましい判定に合わせるため、再採点してはいけません。スコアカードが「再設計」なら、引き継ぎも「再設計」です

防ぐべき失敗

• コードを読まず、スクリーンショットだけをもとに採点する — 構造を調査するサブエージェントを再実行します
• デザインではなく、コードベースを採点する — ユーザーに見える根拠に立ち返ります
• 判定を和らげるため、安易に 3 点を付ける — フェーズ 2 の原則ごとの基準に照らして再調整します
• 判定と上位の改善策を引用しない引き継ぎプロンプトを作成する — それらがなければ、次のセッションは状況を把握できません
• フェーズ 0 のスコープ確定を省略する — 誤った対象の監査により、フェーズ 1 が無駄になります
• サンクコストにとらわれる — コードベースが大きいからと「改善」を推奨してはいけません。サンクコストはデザイン原則ではありません
• 複数の判定を曖昧に示す — 「状況によっては『改善』または『再設計』」のような表現は避け、どちらか 1 つを選びます
• 望ましい判定に合わせてスコアを水増しする — 根拠を採点し、その後、ルールに照らして判定します
• フェーズ 0 でのユーザーの希望をフェーズ 3 の根拠より優先する — ユーザーは判定に異議を唱えられますが、監査では根拠が示す内容を報告します