ui-humanizer

UI Humanizer：UIからAIらしさを取り除く

AIサイトが2秒で見分けられる理由

モデルは最も可能性の高いものを選ぶため、あらゆるビジュアル上の判断が平均的な選択になります。どんな製品、どんなユーザー層、どんなセクションにも使える選択です。デザイナーは特定の製品とユーザー層を対象に選ぶため、その判断には偏りがあり、具体性があります。このスキルに挙げたあらゆる特徴は、平均的な選択の一形態です。それを見分ける手がかりは組み合わせです。eyebrow＋グラデーション見出し＋脈打つチップ＋アイコン付きカード3枚＝テンプレートです。

このスレッドから得られた、以下すべての指針となる5つの教訓です。

1. 問題なのは要素ではなく、デフォルトです。「みんなが何か言うことでも、どこかの時点ではUIのベストプラクティスだった」（@marp_sol）。編集系サイトに意図を持って使うeyebrowは問題ありません。すべてのセクションにeyebrowを使うのは違います。
2. ありきたりなものを別のありきたりなものに置き換えると、悪化します。「AIらしさと戦って、もっと人間らしくしようとすると、ほとんどの場合逆効果で、かえって分かりやすいものになってしまう」（@lamarcke_）。紫を取り除いてベージュ＋セリフ体にするのは、別のデフォルト（@Dan3pmが挙げた/frontend-designのもの）に替えるだけです。置き換えはすべて、「逆をやる」のではなく、コンテンツに基づいて行う必要があります。
3. スキルだけでは解決しません。プロセスが解決します。「救ってくれるスキルはない。まずデザインシステムを定義して、そのあと参考例を提示する必要がある」（@DavidMendonca01）。「AIを使わずにデザインについて考え、描き、サイトをどうするか、フォント、レイアウト、画像について本気で考える」（@greco_dev）。そのため、このスキルは単なる禁止事項のリストではなく、段階的なプロセスになっています。
4. **人間が決め、AIが実行します。**センスのある人はAIを「工場の現場で働くデザイナー」として使い、自分は「監督者」になります（@gr33d1sg00d_）。方向性を決める段階では選択肢を提示し、ユーザーに選んでもらってください。
5. **機能が最優先です。**多くの人にとって「見栄えがよく、用途に合っているなら」問題ではありません（@h1ckzz、@geanjeorge）。AIらしさを減らすために、使いやすさ、パフォーマンス、アクセシビリティ、明瞭さを損なってはいけません。

主なルール

すべてのビジュアル上の選択には、この製品に由来する理由が必要です。コンテンツ、ユーザー層、実際の素材（写真、データ、製品、人々）、ブランドなどです。同じ選択をパン屋、フィンテック企業、AI SaaSのサイトすべてにそのまま使えるなら、それはデフォルトです。変更するか、理由を説明してください。

3秒テスト（YC、@junow0z経由）：ヒーローを見た人が、その企業の事業内容を理解できる必要があります。「より良い意思決定のための明瞭さ」「ワークフローを変革」のような抽象的な見出しは、このテストに失敗するうえ、AIらしさも露呈します。

このスキルのファイル

各段階に応じて読み進めてください。

ファイル	読むタイミング
references/tells.md	制作または監査を行うときは必ず読みます。特徴の完全なカタログです。それぞれの見分け方、コード上の特徴、AIがそうする理由、引用元、置き換え方、残してもよい場合を説明します。
references/referencias.md	フェーズ3で読みます。Chromeを使ってPinterest、Dribbble、Awwwardsなどから参考例を探す方法、それぞれから何を読み取り、どう判断に反映するかを説明します。
references/copy.md	UIにテキストがある場合は必ず読みます。AIらしさが露呈するコピーの単語や構成（ポルトガル語と英語）を紹介します。
references/casos.md	目を慣らすために読みます。スレッドで言及された実在のサイト3つを、特徴ごとに分析します。
references/outros-formatos.md	ドキュメント、スライド、ダッシュボード、アプリ、メールを扱うときに読みます。ランディングページ以外に現れる同じ特徴を紹介します。
references/cobertura.md	51件のコメントそれぞれが、このスキルのどこに反映されているかを示す一覧です。
references/comentarios.md	元のコメントをそのまま掲載しています。
scripts/audit.py	grepによる検出ツールです。python3 -I ~/.claude/skills/ui-humanizer/scripts/audit.py <arquivo-ou-pasta>を実行します。

プロジェクトに独自のデザインシステム（トークン、rti-uiのようなブランドスキル、クライアントのガイド）がある場合は、そのほうがこのスキルより優先されます。ここでは、デザインシステムで決められていない部分からデフォルトを取り除くだけです。

プロセス

ゼロから作成するときは、すべてのフェーズを使ってください。既存のものを見直すときは、フェーズ6から始めてください。監査で問題が構造的（SaaSらしい見た目、標準的なレイアウト、画像がない）だと分かった場合は、フェーズ1～4に戻ってください。こうした問題はCSSの変更では解決できません。

フェーズ 0 · トリアージ

• 何を作るのか：ランディングページ、コーポレートサイト、Eコマース、ログイン後のアプリ、ダッシュボード、ドキュメント、プレゼン資料？それぞれ独自の慣習があり、これらはありがちな特徴ではありません（ログイン後のアプリにはサイドバーやカードがある場合があり、ダッシュボードには KPI のグリッドがある場合があります）。
• どれほど重要か：社内向けのプロトタイプなら、フェーズ 3 全体は必要ありません。ブランドの公開サイトには必要です。
• すでにあるもの：デザインシステム、ブランド、写真、コンテンツ、以前のサイト。提案する前に確認してください。

フェーズ 1 · ブリーフ（ピクセルを作る前に書く）

数行で回答し、ユーザーに見せてください。

1. 何を作るのか、誰のためか、ページで何をするのか。 パン屋は SaaS ではありません（@eucaioba）。回答が「ソフトウェアを契約する」でない場合、SaaS の構成は禁止です。
2. その人が 3 秒で理解すべきこと。 その文を書いてください。それが見出しまたはメイン画像になります。
3. 実際に使える素材。 写真、製品のスクリーンショット、データ、人物写真、住所、メニュー、価格、本物の推薦文。「画像がないこと」は、よく挙げられる特徴のひとつです（@joaquimcassano、@vborotoo）。素材がなければ、ユーザーに依頼してください。それでも用意できない場合は、明示的なプレースホルダー（[外観の写真]、[ダッシュボードのスクリーンショット]）を使い、ユーザーに知らせてください。空白をアイコンカード、グラデーション、汎用イラストで埋めてはいけません。
4. 必須のものと、任意のもの。 余分な文章や埋め草のセクションを削ります（@vborotoo）。
5. 制約。 ブランド、必須の色、アクセシビリティ、技術スタック、期限。

フェーズ 2 · コードを書く前に下書き（「AI を使わずに描く」）

コンポーネントを書く前に、テキストまたは ASCII ワイヤーフレームで骨組みを作ってください。セクションの種類と順序、それぞれに含めるもの、このサイトにしかない要素（地図、製品の巨大な写真、実際の価格表、データのグラフ、メニュー）は何かを決めます。それを中心にレイアウトを組み立ててください。

下書きのルール：

• セクションの順序と大きさは、テンプレートの「ヒーロー → ロゴ → 特長 → 仕組み → 推薦文 → 料金 → FAQ → CTA」ではなく、コンテンツの重要度で決めます。
• セクションごとにサイズ、幅、配置を変えて構いません。すべてを中央揃えにする必要はありません。
• 「仕組み」「選ばれる理由」、特長のグリッド、FAQ、最後の CTA は必須ではありません。各セクションには設ける理由が必要です。

下書きをユーザーに見せ、先に進む前に調整してください。変更にかかるコストが最も低い段階です。

フェーズ 3 · 参考資料

references/referencias.md を読んで、その指示に従ってください。要約：

• まずユーザーに参考資料を求めてください（気に入っているサイト、スクリーンショット、Pinterest のボード）。これが最良の情報源です。
• 用意できない場合は、ブラウザーで探してください。Pinterest（「AI が少ない」フィルター）、Dribbble、Siteinspire、Awwwards、Godly、Land-book、Lapa Ninja、One Page Love、Fonts In Use、同じ業界の実際のサイトなどです。
• 6～12 件を集め、カタログ的な特徴があるもの（最近は AI で生成された参考資料も多くあります）を除外し、参考資料ごとにレイアウト、タイポグラフィ、色、画像、密度、記憶に残る細部を記録してください。
• それぞれ 2～3 件の参考資料と選定理由を添えて、ユーザーに 2～3 種類の方向性を提示してください。ユーザーに選んでもらいます。
• 参考資料は発想（構成の仕方、画像の使い方、コントラストの種類）を参考にし、2～3 件を組み合わせてください。レイアウトもブランドも模倣してはいけません。

フェーズ 4 · 最小限のデザインシステム

選んだ方向性から導き出します。デフォルト設定から始めるのではありません。

• タイポグラフィ： 理由のある書体を1〜2種類（ブランド、業界、参考資料に基づく）選びます。サイズにしっかり差をつけたスケールにします。「標準フォント＋ミニマルな見出し」（@Lukekw_）や、10種類ものフォント（@El_Sinisttro）は避けます。
• 色： 色の由来を明確にします（建物の外観、パッケージ、製品、業界、メインの写真など）。アクセントカラーは控えめに使います。デフォルトのTailwindの紫（@Cirilorde）、デフォルトのグラデーション、要素ごとに異なる色を使うことは避けます。
• 形状： 小さく一貫性のある角丸のスケールにします。理由がある場合に限り、ピル型を使います。境界線と影のルールは1つにし、何種類も使いません。
• アイコン： アイコンセットは1種類だけ使うか、使わないかのどちらかです。アイコンとして絵文字を使うのは避けます。
• モーション： 存在するアニメーションを少数に絞り、それぞれが何を説明するのかを記載します。それ以外は静的にします。

トークン（CSS variablesまたはTailwindの設定）として記述し、ライブラリのコンポーネントにも適用します（工場出荷時のテーマのshadcnはtellです。@metalheadlost）。

フェーズ 5 · 構築

references/tells.mdとreferences/copy.mdを参照しながら、スケッチとデザインシステムに沿って構築します。簡単なルールは次のとおりです。

• 書面での説明なしに、クラスAのtellを使わないでください。
• 実際の画像がある場合は、必ず最初のビューポートに配置します。
• 何かをする要素にだけホバー効果を付けます（@Fagner_Souza）。
• 状態の変化を説明する場合に限り、アニメーションを使います。
• 具体的な事実に基づくコピーにします。何であるか、誰向けか、価格、場所を、ユーザーから提供された実際の数値や名称とともに記載します。顧客、数値、推薦文、ロゴ、受賞歴を決して捏造しないでください。

フェーズ 6 · 監査

1. 検出： ファイルまたはフォルダーに対してscript/audit.pyを実行します。tellのコード上の特徴（アイブロウ、テキストのグラデーション、側面の境界線、パルス、絵文字、紫、グラスモーフィズム、ホバー、ピル型、背景のグラデーション、流行のフォント、テンプレート風コピー）を検出します。これは出発点です。検出箇所を確認してください。正当なものもあります。
2. ビジュアル： 可能であれば、Chromeでページを開き、デスクトップとモバイルの両方で、上部・中部・下部のスクリーンショットを撮ります。レンダリング後に初めてわかるtellも多くあります。たとえば、ありきたりなレイアウト、すべて同じカード、画像の不足、SaaSらしさ、同じリズムのセクション、浮かんだモックアップなどです。
3. カタログ： references/tells.mdを確認し、見つかったtellに印を付けます。まずは影響の大きいものから確認します。Aは出現が1回でも変更を正当化します。Bは他のtellと組み合わさったときに問題になります。CはAまたはBがある場合に限ります。
4. コピー： references/copy.mdを確認します。長い段落にはhumanizerスキルを組み合わせます。
5. 最終チェックリスト（以下）。

フェーズ 7 · 反復

• CSSクラスだけでなく、その背後にある判断を変えてtellを修正します。セクション全体がテンプレートなら、セクションを作り直します。
• 検出を再実行し、別の決まり文句に置き換えていないか確認します（紫 → ベージュ、Inter → 斜体のPlayfair、グラデーション → グラスモーフィズム、絵文字 → 色付きの四角いアイコン）。
• 好みが分かれる場合は、2つの案を並べて提示し、質問します。

最終チェックリスト

1. ヒーローを見て、3秒でビジネスの内容がわかりますか？
2. ページ、特に上部に実際の素材（写真、スクリーンショット、データ、製品）がありますか？
3. サイトの種類に合った構成になっていますか。それともデフォルトでSaaSになっていませんか？
4. クラスAのtellが残っていませんか？ 残っているクラスBにはすべて理由がありますか？
5. ある決まり文句を別の決まり文句に置き換えていませんか？
6. 何もしない要素にホバー効果、ポインターカーソル、アニメーションを付けていませんか？
7. コピーにcopy.mdの用語が含まれていませんか？
8. 数値、顧客、推薦文、ロゴ、受賞歴を捏造していませんか？ していた場合は、削除するかプレースホルダーとして明記してください。
9. AIらしさを減らすために、使いやすさ、コントラスト、パフォーマンス、モバイル対応を損なっていませんか？ 損なっていた場合は元に戻してください。
10. 方向性の決定（スケッチ、参考資料、デザインシステム）をユーザーが確認し、承認しましたか？

返す内容

• 構築する場合: brief、ドラフト、参考資料付きの方向性、デザインシステム、その後にコードを返します。ユーザーがそのまま進めるよう依頼していない限り、ドラフトの後と参考資料の後に、ユーザーの承認を待ちます。
• 監査する場合: 見つかった tell の一覧を、強いものから順に ファイル:行 またはスクリーンショットとともに示し、それぞれに提案する変更と、理由を添えて意図的に残すものを説明します。ユーザーが監査のみを依頼した場合は、編集しません。
• 修正する場合: 実施した変更、変更前後の検出結果、可能であればスクリーンショットを返します。