taste-skillとは｜AIのUIを格上げするスキル集

「AIに作らせると、なんとなく安っぽい」「どのページも似たような見た目になる」——AIでUIを組むと、誰もが一度はこの違和感に行き当たります。

結論から言うと、この「AIっぽさ」には共通したパターンがあり、それを潰すためのルール集をAIに読み込ませると改善します。今回はその一つ、GitHubで公開されている「taste-skill」というスキル集を取り上げます。

株式会社Fyveは普段からAIでLP・コーポレートサイトを制作しており、こうした人気スキルは「中身を読んで、自分のワークフローに合う部分だけ採り入れる」運用をしています。本記事では、私が実際に自社のLP制作で導入を検討した立場から、taste-skill の使いどころと注意点を解説します。

taste-skill とは｜AIが作るUIを格上げするスキル集

taste-skill は、AIエージェント向けに「アンチAIスロップ（Anti-Slop）」を掲げるフロントエンドデザインのスキル集です。MITライセンスで公開されており、「npx skills add」コマンドで導入して、Claude Code・Cursor・Codex などのコーディングエージェントに読み込ませて使います。

ひとことで言えば、「AIに任せると出てくる、テンプレートのような無個性なUI」を避け、レイアウト・タイポグラフィ・モーション・余白の質を一段引き上げるための、ルールの束です。

そもそも「AIスロップ」とは何か

「スロップ（slop）」は、AIが大量生成する中身の薄い成果物を指す言葉です。デザインで言えば、次のような「AIあるある」がこれにあたります。

3つの均等なカードが横に並ぶだけの機能紹介
紫や青のグラデーションが光るボタン（いわゆるAIっぽい配色）
見出しが必ず中央寄せで、どのセクションも同じリズム
「Elevate」「Seamless」「Revolutionize」のような中身のない英単語のコピー
「John Doe」「Acme」といった、ありがちな架空の名前や社名

こうしたパターンは、一見それらしく仕上がる一方で、「どこかで見た感じ」「人の手が入っていない感じ」を読者に与えます。taste-skill は、これらを具体的な禁止ルールとして言語化している点に価値があります。

何ができるのか — 60項目超の「やってはいけない」リスト

taste-skill の中身は、60項目を超える「mandatory（必須）」「banned（禁止）」のチェックリストです。代表的なルールを挙げると、以下のようなものがあります。

タイポグラフィ：サンセリフを既定にする。多用されすぎた「Inter」を既定にしない。見出しの中の強調は、別フォントを混ぜず同じフォントの太字や斜体で行う
レイアウト：ヒーローは最初の画面に収める。小見出し（eyebrow）は3セクションに1回まで。画像左＋テキスト右のジグザグ配置は2連続まで
配色：アクセントは1ページ1色まで。彩度は原則80%未満。純粋な黒（#000000）と純粋な白（#ffffff）は使わない
モーション：自前のスクロール監視は禁止し、IntersectionObserver や GSAP の ScrollTrigger を使う。動かすなら「何を伝えるためか」を必ず説明できること

面白いのは、強度を3つのダイヤルで宣言してから使う設計になっている点です。「DESIGN_VARIANCE（レイアウトの冒険度）」「MOTION_INTENSITY（動きの強さ）」「VISUAL_DENSITY（情報密度）」を1〜10で先に決めることで、案件ごとにルールの効き方を調整できます。すべてのルールが機械的に発火するのではなく、まず案件の性格を読んでから適用範囲を絞る、という考え方です。

どんなときに有効か

私が実際に中身を読んで感じた、taste-skill が力を発揮する場面を整理します。

SaaS・スタートアップ系の英語サイトに強い

taste-skill が想定しているのは、明確にTailwind CSS + React + サンセリフという、いまどきのWebサービス系の技術スタックと美学です。実際、ルールの多くが「text-4xl md:text-6xl」のようなTailwindのクラス名を直接指定する形で書かれています。

つまり、Next.js や React でSaaSのランディングページを組むようなケースでは、ルールがそのまま実装に落ちます。「AIに任せたら無難すぎる仕上がりになった」という典型的な悩みに対して、即効性のある処方箋になります。

「AIっぽさ」を消したいが、判断基準がないとき

デザインの良し悪しは感覚的で、非エンジニアやデザイン専門でない人ほど「なんか違うけど、どこを直せばいいか分からない」状態に陥りがちです。

taste-skill の真価は、その「なんか違う」をチェック可能な項目に変換してくれるところにあります。「中央寄せのヒーローをやめる」「均等3カラムのカードをやめる」「嘘くさい完璧な数字（99.99%など）を書かない」といった具体的な指示は、AIに対しても人間に対しても、ぶれない判断基準として機能します。

モーションの「作法」を学べる

個人的に最も納得したのが、モーションの扱いです。taste-skill は「すべての動きには動機が必要」と明言し、階層・物語・フィードバック・状態変化のいずれかを伝えていないアニメーションを認めません。「かっこいいから」は理由として不採用、というわけです。

さらに、自前のスクロール監視を禁止し、IntersectionObserver や GSAP の ScrollTrigger といった正しい仕組みへ誘導します。これは私自身が普段から大切にしている考え方と一致しており、フロントエンドの実装作法としても理にかなっています。

逆に向かないケース — 私が「丸ごと導入」を見送った理由

ここからが本題です。私はこのスキルを検討した結果、丸ごと導入はしないと判断しました。優れたスキルですが、自社の制作スタイルとは前提が噛み合わない部分があったためです。

作り込んだ「ハウススタイル」とは衝突する

ちょうど私は、手描きのイラストと明朝体を主役にした、和の世界観のコーポレートサイトを制作している最中でした。暖かみのある紙のような背景色に、真鍮色のアクセント、しっとりとした明朝の見出し。土地の風土をモチーフにした、意図的に作り込んだ世界観です。

ところが taste-skill は、まさにこの「クリーム系の背景＋真鍮色のアクセント＋暖かいニアブラックの文字」という組み合わせを、AIが最も多用するクセの一つとして名指しで禁止していました。加えて、明朝・セリフ体を既定にすることを推奨せず、手描きの装飾SVGも避けるよう指示します。

これらは、私が作っているサイトの「核」そのものです。汎用的なアンチスロップのルールに従えば、せっかく積み上げた個性が削られてしまう。ここに気づいたのが、見送りの決め手でした。

ただし、その指摘は「逆に有用なシグナル」でもある

とはいえ、この衝突は単なる障害ではありませんでした。「クリーム＋真鍮＋セリフがAIのデフォルト＝すでに手垢がついている」という指摘自体は、正しいのです。

裏を返せば、その配色を使うなら、その土地や素材に由来する固有のモチーフと、手描き・独自実装の表現を上に重ねることが、デフォルトの配色を「ありがち」から救い出す行為になります。私が手描きイラストやオリジナルのアニメーションで個性を足していた作業は、まさにこの「救済」だったと再確認できました。批判をくれるツールは、自分の判断を言語化する鏡にもなります。

前提のスタックが自社と違う

もう一つの理由は技術的なものです。taste-skill は Tailwind + React を前提にしていますが、私が制作しているサイトは素のCSSで組んでいます。ルールの多くがTailwindのクラス名で書かれているため、そのまま適用できる箇所は限られます。日本語の和文タイポグラフィに関する配慮も、英語圏のサイトを想定したこのスキルにはほとんど含まれていません。

私の使い方 — 「読んで、原則だけ拾う」

では無価値かというと、まったく逆です。私は taste-skill を統治ルールとしてではなく、セカンドオピニオンのチェックリストとして一度通読し、技術や美学に依存しない普遍的な原則だけを拾い上げました。具体的には、以下のような項目です。

モーションは必ず「何を伝えるか」から設計する（目的のない動きは入れない）
自前のスクロール監視を避け、正しい仕組み（IntersectionObserver / ScrollTrigger）を使う
レイアウトの冒険度・動きの強さ・情報密度を、制作の最初に数値で宣言しておく
動きを入れるなら、reduced-motion（動きを減らす設定）への対応を必須にする
プロジェクトごとにフォントや配色を意図的にローテーションし、自分の制作物が似通うのを防ぐ

この使い方は、私の従来の方針とそのまま地続きです。私は以前から、GitHubで人気のスキルは中身を読んで理解し、自分のワークフローに合うよう改良して使うというスタンスを取ってきました。また、かつて接続していたデザイン系の外部連携ツール（MCP）はあえて外し、「プロンプトやスキルでガイドラインを定め、コード上でデザインを整える方が、トータルの作業コストが下がる」と判断しています。

taste-skill への向き合い方も、これと同じです。デザインスキルは「採用する」より「読んで盗む」方が、自社の個性を保ったまま品質を底上げできるというのが、私の結論でした。

スキルを自分のワークフローに取り込む実務的な手順は、こちらの記事で詳しく解説しています。