avoid-ai-design

AI デザインを避ける：監査と書き換え

フロントエンドのコードを確認し、UI が AI 生成のように見える（「AI スロップ」）パターンを見つけ、意図的に選んだ一つのデザイン方針に沿って書き換えます。

これは avoid-ai-writing スキルのデザイン版です。対象となるスタックは、プレーンな HTML/CSS/JS と React + Tailwind + shadcn/ui の 2 つです。

目指すのは、目新しさを追い求めることではありません。デフォルトを、意図的な選択に置き換えることです。紫のグラデーションが悪いのは、紫が悪いからではありません。誰もそれを選んでいないからです。

デフォルトには 2 つの段階があります。 1 つ目は、平均的なスタイルです。紫のグラデーション、Inter、アイコン付きカード 3 枚。2 つ目は、洗練された脱却スタイルが新たな平均になったものです。テラコッタを合わせたクリーム色、酸味のある緑を 1 色だけアクセントにしたほぼ黒の配色、すべて大文字のモノスペースラベル、見出しの中の 1 語だけを色分け、装飾的な 01/02/03。Anthropic 独自の frontend-design スキルにもこうしたパターンが挙げられており、脱スロップの見直し（このスキルも含みます）では、こうしたスタイルに頻繁に行き着きます。どちらの段階も、定型的な特徴として扱ってください。references/ai-tells-catalog.md の SD セクションを参照してください。

コードに見えるのは半分で、残りはピクセルに表れます。 ソースコードにある特徴もあります（from-indigo-500 の直書き、Inter、lucide のインポートなど）。スキャナーはそれらを見つけます。一方、実際の配色に主役となる色があるか、余白にリズムがあるか、構成が他のあらゆるページと同じかといった、見た目に関する特徴もあります。可能ならレンダリングしてください。できない場合は、どの指摘がコードから確実に判断でき、どれが推測なのかを明記してください。

モード

rewrite（デフォルト）：コードを監査し、デザイン方針を決めてから書き換えます。

detect：監査とスコアリングのみを行います。編集はしません。次の場合にこのモードを使用してください。

• ユーザーが、指摘箇所を確認して自分で修正したい場合。
• 変更すべきでないコード（依存関係、チームメイトの作業、参考資料など）をレビューする場合。
• ユーザーが簡易スキャンを依頼した場合。

ユーザーが「監査だけ」「指摘だけ」「スキャンして」「何が AI っぽいのか」「コードは変更しないで」と言った場合は、detect を使用してください。特に指定がなければ rewrite を使用してください。

スキャナー

scripts/detect.mjs は、モデルの呼び出しや依存関係なしで、コードから確実に判断できる特徴（カタログで ⚙ の印が付いたもの）を見つけます。Node 18 以降が利用可能な場合は、まずこれを実行してください。

node <skill-dir>/scripts/detect.mjs <files or folders>        # grouped report, exit 2 on any P0/P1
node <skill-dir>/scripts/detect.mjs --json <files or folders>  # for your own parsing

出力は、監査のうちコードから確実に判断できる部分として扱ってください。監査全体ではありません。スキャナーでは、配色の比重、リズム、階層、構成レベルの画一性は見えません。--include-examples を指定しない限り、examples/、fixtures/、stories/ と、slop-example の印が付いたファイルはスキップされます。また、要件で指定された選択を示す avoid-ai-design-ignore: <ID> コメントを尊重します。Node が利用できない場合は、カタログを手作業で確認してください。

ワークフロー（書き換えモード）

1. 対象範囲。 まず実際のファイルを読みます。レビュー対象（コンポーネント、ページ、アプリ全体）、技術スタック、モードを確認します。一貫性を保つためのデザインシステムを探します。たとえば、DESIGN.md（Google のオープン形式で、Stitch などのデザインスキルも作成します）、トークンファイルや :root、コンポーネントライブラリ、関連ページ、ユーザー自身が選んだフォントや色などです。作業が複数のページにまたがるかどうかも確認します。プロンプトだけを見て判断してはいけません。
2. スキャン。 対象ファイルにスキャナーを実行します。
3. レンダリング。 スクリーンショットやプレビューのツールが使える場合は、成果物をレンダリングし、👁 の兆候をピクセルから判断します。ページでシルエットテストを行います。スクリーンショットを白地に黒の小さなブロックのシルエットに縮小し、別の製品のページにも見えてしまわないか確認します（カタログ L9）。25% の表示で、フラットな密度にも目を凝らします。レンダリングできない場合は、視覚的な兆候を推測に基づく、確信度の低い判断として記録します。
4. 監査。 スキャン結果、レンダリング、references/ai-tells-catalog.md のすべてのカテゴリ（SD セクションを含む）を確認した結果を統合します。兆候ごとに、場所、ID、深刻度、「AI らしく見える」理由を一行で記し、コードから確実に判断できるもの、レンダリングで確認したもの、推測に基づくもののいずれかを示します。
5. 根拠に基づいて計画。 デザインシステムが存在する場合、それが進むべき方向です。契約として採用し、正確に合わせます。存在しない場合は、スタイルのメニューから選ぶのではなく、対象から方向性を導きます。製品は何か、誰が使うのか、その世界を構成するもの（素材、場所、時代、その分野固有の成果物や語彙）は何かを考えます。簡潔な計画を作成します。役割を添えた色を4〜6色、書体とその役割、レイアウトのアイデアを一文、そして特徴となるディテールをひとつ記します。references/aesthetic-directions.md は、方向性の名前を付けるための語彙集であり、選択肢のメニューではありません。
6. 計画をデフォルトと照らして確認。 コードに手を加える前に、計画を二次的なクラスター（SD1〜SD8）および直近の自分の作業と照らして確認します。各要素について、「似たページならどれでも、この案にたどり着くだろうか」と問いかけます。そうであれば計画を修正し、変更点を述べます。ユーザーがいる場合は、計画と代替案を1〜2案、一文で示して返答を待ちます。非対話形式で実行する場合は、前提を一行で示して作業を進め、簡単に変更できるようにしておきます。
7. 作業の深さを調整。 小さなコンポーネント、またはデザインシステム内の要素は、的を絞った作業にします。兆候を置き換え、構造とトークンは維持します。単独のページは、方向性に沿って再構築します。ゼロからの構築は frontend-design スキルと重複するため、利用可能な場合は、作業を重複させず、レビュー済みの計画を渡します。
8. 書き換え。 実際のファイルを編集します。機能、props、状態、ルーティング、データフロー、アクセシビリティ、コピーの意味を維持します。依存関係を黙って追加してはいけません。追加する場合は明記します。複数ページにまたがる作業では、references/design-md-template.md をもとに計画を DESIGN.md に記述する（または既存のものを拡張する）うえで、すべてのページをその計画に沿って構築します。
9. 再スキャンして判断。 再度スキャナーを実行し、P0 がなく、依頼で求められていない SD の兆候もないことを確認します。その後、「成功の基準」に照らして結果を判断します。スキャン結果が問題ないことは必要条件ですが、十分条件ではありません。

成功の基準

「いかにも AI らしくない」ことが目標ではありません。色を差し替える（インディゴからティールへ、Inter から今風の書体へ、絵文字を削除）だけなら、P0 はすべてクリアできますが、印象に残らないテンプレートのままです。次の基準で結果を評価してください。

1. 根拠があること。 すべての変更が、明確に定めた方向性に沿っており、その方向性が題材に根差していること。
2. 一貫していること。 書体、配色、レイアウト、特徴的なディテールが互いを引き立てていること。アイデアは一つに絞り、最後まで実現します。大胆さを発揮する場所は一つに集中させます。
3. 二次的な定番に陥らないこと。 ブリーフで求められていない SD のクラスターに当てはまらず、最近の制作（クリーム色とテラコッタの組み合わせ、ほぼ黒とライムの組み合わせ、モノクローム）を繰り返さないこと。同じようなページならどれにでも使っていたと思うなら、それは失敗です。
4. 一貫性があること（ページが複数ある場合）。 関連するページとトークン、ナビゲーション、フッター、書体のスケールを共有し、同じ製品の一部として認識できること。プロジェクト間では変化をつけます（テスト 3）。プロジェクト内では変化させません。

スキャナーを通過したページでも、これらの基準すべてに失敗することがあります。カタログは陳腐な表現を見つけますが、これらの基準は凡庸さを見抜きます。

重大度の段階

段階分けは、パターンがどれだけ気になるかではなく、誰が気づくかを基準にしています。状況によって、特徴の重大度は上下します。

• P0、一般の人でも AI が作ったとわかるもの。 紫から青へのグラデーション、すべてに Inter を使うこと、手を加えていない shadcn の基本テーマ、グラデーション（bg-clip-text）を使った見出し、中央寄せのヒーローの下に 3 つのカードを置くテンプレート。いわゆる定番ネタです。
• P1、デザイナーや開発者なら気づくもの。 二次的なクラスター（SD）、すべての面に rounded-2xl shadow-lg を使うこと、標準のページシェル、角丸四角形に入ったアイコン、標準の 4 列フッター、既製の Aceternity / Magic UI エフェクト、機能しないホバー状態やフォーカス状態、CTA に付け足した矢印記号、「ワークフローを次のレベルへ」といったコピー。
• P2、技術や仕上げの不足。 リズムのない平坦な間隔設定、すべてに同じフェードアップを使うこと、バウンスするイージング、汎用的な CTA ラベル。

状況が重要です。汎用的な SaaS ページでは中央寄せのヒーローは P0 ですが、高級感のあるレイアウトなら問題ありません。:focus-visible の欠如、AA 基準を下回る薄いテキスト、動きを抑える設定を無視するアニメーションはアクセシビリティ上の欠陥です。そのため、どの段階に当てはまる場合でも優先度を高くしてください。

コンテキストプロファイル

UI が使われる場所に応じて、厳しさを調整してください。スタックと構造から自動判定し、使用するプロファイルを明記してください。

プロファイル	対応方法
landing / artifact	妥協せず対応します。大胆な表現を推奨します。明確な方向性が最も重要になる場面です。
marketing-page	書体、色、レイアウト、コピーを妥協せず対応します。
app-component	必要な箇所だけを修正します。コンポーネントの契約と構造は維持します。
inside-design-system	必要な箇所だけを修正します。既存のトークンとプリミティブを尊重します。デザインシステムに逆らわず、システムレベルの問題は別途アドバイスとして指摘します。
dashboard	装飾よりも、情報の密度、読みやすさ、情報の階層を重視します。

ガードレール

• 動作しているコードを壊さないでください。 Props、state、ルーティング、データ取得、アクセシビリティはそのまま維持します。動作を変更してはいけません。
• ありきたりな表現を別のありきたりな表現に置き換えないでください。 二次的なデフォルトも、やはりデフォルトです。紫をクリーム色やテラコッタに変えれば解決するわけではなく、クリーム色をほぼ黒やライム色に変えても解決しません。実行ごとに変化をつけ、すべての選択に対象に基づく根拠を持たせてください。
• 依頼内容を最優先してください。 既存のデザインシステム、ブランドガイドライン、指定されたフレームワーク、ユーザーが選んだフォントや色は、たとえSD風の見た目を求めている場合でも、あなたの好みに優先します。それに合わせ、上書きせず、スキャナーがフラグを立てなくなるよう無視コメントを付けてください。
• ページ間で同じデザインシステムを維持してください。 複数ページにまたがる作業では、色、書体、余白、角丸、ナビゲーション、フッター、共有コンポーネントを含む単一のルールをDESIGN.mdに定め、記載どおりに再利用してください。各ページを一から作り直すと、学習データの中央値へと戻り、2ページ目が1ページ目からずれていきます。これがデザインシステムのドリフト（カタログX1）であり、単独の兆候と同じくらい明白にAIらしさを感じさせます。必要なトークンがない場合は、ルールに追加するか、確認してください。その場限りのものを作らないでください。
• 非難ではなく、証拠を示してください。 兆候からわかるのは、誰も選んでいないデフォルトが使われていることです。そのページをモデルが作った証拠にはならず、多くはインストール時のTailwindやshadcnの設定です。デフォルトを報告し、作者について憶測しないでください。
• 問題をでっち上げないでください。 UIがすでに個性的で意図が明確なら、その旨を伝えて終了してください。問題なしという監査結果も有効です。
• コピーの意味を維持してください。 汎用的なマイクロコピーをより明確にすることはできますが、主張を作り上げたり、製品が自らについて述べている内容を変えたりしないでください。

自己言及に関する例外

コードがAIデザインパターンそのものを扱う場合（デモ、教材用の例、「避けるべき例」のギャラリー、またはこのスキル独自のドキュメントなど）、例示的なスロップは意図的なものです。具体的な根拠がある場合に限り、例外として扱ってください。根拠とは、該当箇所に付随するコメントでの明示（slop-example）、examples/、fixtures/、__mocks__/、stories/以下のパス、または例示であると明記されたテキストです。スキャナーにも同じルールが適用されます。実際のインターフェースにあるパターンだけを指摘してください。

HTMLやReact以外の場合

このカタログは、AIツールが最も多く出力するHTML/CSSとReact/Tailwind/shadcn向けに書かれています。原則はフレームワークに依存しません。手を加えずに残されたデフォルトが兆候です。手を加えていないMUI（Robotoと青）、Chakra、Bootstrap（青いbtn-primary）、Mantineのデフォルトも、同じ理由でAIらしく見えます。同じ監査を適用し、具体的なクラス名とトークン名を読み替えてください。

出力形式

rewriteモード

1. 監査。 検出した兆候をすべて、重大度ごとにまとめ、各項目にID、場所、1行の理由、code-certain／rendered／inferredのタグを付けます。スキャナーを実行した場合は、まずスキャナーの概要を示します。
2. 計画。 方向性と、それが対象のどこに由来するか、簡潔なトークン計画、デフォルトレビュー（ステップ6）で修正した内容、1、2文で述べる代替案を示します。インタラクティブな場合は、ここで一旦停止します。
3. 書き換え。 調整した深さで編集済みコードを提示し、複数ページの作業ではDESIGN.mdも含めます。
4. 変更点。 意味のある変更を簡潔にまとめます。行ごとの差分説明にはしません。
5. 再スキャンと評価。 スキャナーによる2回目のチェックを行い、その後、4つの成功基準を確認します。基準を満たさないものがあれば修正します。

detectモード

1. 監査。 検出した兆候をすべて、重大度（P0/P1/P2）ごとにまとめ、ID、場所、code-certain／rendered／inferredのタグを付けます。
2. 評価。 各フラグについて、明確な問題か判断が分かれるものかを示します。文脈によっては問題にならないパターンもあります（グラデーションは1つだけなら、使い方次第でスロップではありません。依頼で指定されたクリーム色の配色は選択です）。修正するものと、そのままにするものを明記してください。

過剰にデザインしない

目指すのは、この題材に詳しいセンスのある人が作ったように見える UI であり、目立つことだけを目的とした UI ではありません。むやみに極端なデザインにするより、節度をもって丁寧に仕上げるほうが効果的です。元のデザインがすでに優れているなら、必要な箇所だけを少し整えて、そこで止めましょう。成果物に合わせて変更の強度を調整してください。設定パネルにヒーローアニメーションは必要ありません。