taste-skillとは｜AIが量産する"そっくりUIスロップ"を止めるアンチスロップ・スキルの設計思想と使い方

2026年2月19日に公開された無名のGitHubリポジトリが、約4か月でスターを5万近くまで積み上げた。名前は taste-skill。説明文はわずか一行、「あなたのAIに良いセンス（taste）を与える。AIが退屈で平凡なスロップを生成するのを止める」。コーディングエージェントを日常的に使う開発者なら、この一文が刺さる理由が分かるはずだ。Claude Codeに「いい感じのランディングページを作って」と頼むと、十中八九、紫のグラデーション・暗いメッシュ背景・中央寄せのヒーロー・横並び3枚の同じカードが返ってくる。誰が頼んでも、どのプロジェクトでも、同じ顔のサイトが出てくる。その「AIっぽさ」を、ルールとして言語化し、SKILL.mdというファイル一枚に固めて配布可能にしたのがtaste-skillだ。

携帯可能なAgent Skillで、AIが作ったインターフェースを底上げする——定型句のような見た目の代わりに、より強いレイアウト・タイポグラフィ・モーション・余白を。
原文：“Portable Agent Skills that upgrade AI-built interfaces: stronger layout, typography, motion, and spacing instead of boilerplate-looking UIs.”（taste-skill README）

この記事は、taste-skillが何をするツールなのかを、公式リポジトリのREADME・CHANGELOG・SKILL.md本体という一次ソースだけを引きながら解剖する。そして「AIにテイストを持たせる」という挑戦的な命題が、実際にはどんな禁止ルールの束として実装されているのかを、設計思想のレベルまで降りて見ていく。流行りのリポジトリを「スターが多い」で終わらせず、「なぜ刺さったのか」「どう使うのか」「どこが弱点か」まで一気に整理する。

なぜAIは「同じ顔のUI」を量産するのか

taste-skillの存在意義は、AIコーディングの構造的な弱点を理解すると一気に腑に落ちる。大規模言語モデルは、学習データで最も頻出した表現に引っ張られる。デザインも例外ではない。「モダンなSaaSのランディング」と指示すれば、モデルは無数のテンプレートの平均値——最も「それらしい」既定値——へ収束する。結果、出力は驚くほど似通う。

taste-skillの中核SKILL.mdは、この既定値を名指しで列挙し、「ここに逃げるな」と釘を刺す。これは抽象論ではなく、実際にファイルへ書かれている禁止リストだ。

既定で次へ逃げるな——AI紫グラデ、暗いメッシュ背景の上の中央ヒーロー、3枚の等しいフィーチャーカード、何にでもかけるガラス風効果、そこかしこの無限ループ・マイクロアニメーション、Inter＋slate-900。これらはLLMの既定値だ。
原文：“Do not default to: AI-purple gradients, centered hero over dark mesh, three equal feature cards, generic glassmorphism on everything, infinite-loop micro-animations everywhere, Inter + slate-900. These are the LLM defaults.”（SKILL.md §0.D Anti-Default Discipline）

このリストを読んで「自分が生成させたサイトそのものだ」と感じた人は多いだろう。taste-skillが最初にやることは、新しい美学を足すことではない。モデルが何も考えずに落ちていく穴を、先回りして塞ぐことだ。良いデザインを足し算する前に、悪い既定値を引き算する。この引き算の発想こそが、数あるAIデザイン系プロンプトとtaste-skillを分ける一線になっている。

そして引き算には根拠が要る。何を「AIの足跡（Tell）」と判定するかは恣意的でいい話ではない。taste-skillはリポジトリ内に research/ ディレクトリを持ち、スキルを形作った背景調査を残している。最初のトピックが「LLM Laziness（AIの怠惰）」——モデルがプレースホルダーコードや途中で切れた出力、飛ばされたセクションを生む理由とその対策の調査だ。出力を最後まで書かせる output-skill（install名 full-output-enforcement）は、この調査から直接生まれている。「AIっぽさ」を観察して言語化し、ルールに落とすという回路が、リポジトリの設計に組み込まれている。

taste-skillの正体——Agent Skillsの上に載る「テイストのルール集」

taste-skillを理解する鍵は、これが独立したアプリでもライブラリでもないという点だ。実体は、Anthropicが広めた Agent Skills（SKILL.md形式の携帯可能な指示ファイル）の標準の上に載る、一連のテキストルールである。Agent Skillsそのものの仕組みは Claude Skills（SKILL.md）とは何か——エージェントに「手順書」を持たせる仕組み で詳しく扱っているので、SKILL.mdの基礎から押さえたい場合はそちらを先に読むと位置づけが鮮明になる。

構造を一枚の図にすると、taste-skillが「どの層に効くのか」が見える。

ここで重要なのは、taste-skillがフレームワーク非依存だという点だ。READMEは「ルールはデザインの意図を対象にしており、特定のフレームワークAPIを対象にしていない」と明言する。React・Vue・Svelteのどれでも効くのは、ルールが「3枚の等しいカードを避けよ」「アクセントは1ページに1色」といった判断のレベルで書かれているからだ。だから同じSKILL.mdを、コードを書くClaude Codeにも、画像を生成するChatGPTにも渡せる。

導入経路は3つある。最も手軽なのはvercel-labsの skills CLIを使う方法で、リポジトリの skills/ フォルダを走査して全スキルを取り込む。

# 全スキルをまとめて導入
npx skills add https://github.com/Leonxlnx/taste-skill

# 中核スキルだけを install 名で指定して導入
npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"

--skill に渡すのはフォルダ名ではなく、SKILL.mdのfrontmatterにある name: フィールド（install名）である点に注意が要る。フォルダは taste-skill でも、install名は design-taste-frontend のように異なる。SKILL.mdの冒頭は、ただのMarkdownのfrontmatterだ。

# skills/taste-skill/SKILL.md の frontmatter（抜粋）
---
name: design-taste-frontend          # ← --skill にはこの install 名を渡す
description: Anti-slop frontend skill for landing pages, portfolios, and redesigns. The agent reads the brief, infers the right design direction, and ships interfaces that do not look templated.
---

name: がエージェントから呼ぶときの識別子、description: がエージェントが「いつこのスキルを使うべきか」を判断する手がかりになる。Agent Skillsの作法そのものなので、自前のスキルを書くときの最小テンプレートとしても流用できる。

.claude-plugin/ を備えているため、Claude Codeのプラグイン／マーケットプレイスとしても登録できる。リポジトリの marketplace.json は自身を「Taste skill library for Claude Code」と説明している。さらに原始的には、任意の SKILL.md をプロジェクトにコピーするか、ChatGPTやCodexの会話に貼り付けるだけでも機能する。SKILL.mdはただのMarkdownなので、配布のハードルが極端に低い——これがテイストを「資産」として配れる理由だ。

3つのダイヤル——テイストを数値で操作する

taste-skillの中核スキルを開くと、冒頭に3つの「ダイヤル（1〜10の調整つまみ）」が並ぶ。これがツールの操作インターフェースであり、デザインの方向性を数値で宣言する仕掛けだ。

# skills/taste-skill/SKILL.md の冒頭（抜粋）
DESIGN_VARIANCE: 8   # 1=完全な左右対称  ...  10=アーティスティックな混沌
MOTION_INTENSITY: 6  # 1=静止  ...  10=シネマティック / 物理演算
VISUAL_DENSITY: 4    # 1=美術館のように余白広め  ...  10=コックピット級の高密度
# 既定（Baseline）= 8 / 6 / 4

面白いのは、ユーザーがこのファイルを手で編集することを想定していない点だ。SKILL.mdは「このファイルを編集させるな。上書きは会話の中で起こる」と書く。つまりエージェントは、ユーザーの言葉（「ミニマルに」「Linearっぽく」「Awwwards級に派手に」）からダイヤル値を推論する。SKILL.mdにはその推論表まで載っている。

3つのダイヤルが効くのは、デザインの判断が散らからないからだ。VARIANCEを8にすれば「3枚の等しいカード」は自動的に否定され、非対称グリッドやスクロール連動レイアウトが選ばれる。MOTIONを6にすれば、ホバーだけの寂しい動きではなく、スクロール連動のリビールが入る。一方でMOTIONを高く宣言したのに実際は動かない、という嘘を防ぐルールもある。「モーションを主張したなら、モーションを見せろ。さもなくばダイヤルを3に下げて、潔く静的なものを出荷しろ」。ダイヤルは飾りではなく、出力に対する契約として働く。

まず「空気を読む」——Brief Inferenceという前段

v2で最も思想が出ているのが、コードを一行も書く前に置かれた §0 Brief Inference（ブリーフ推論） だ。SKILL.mdは「ほとんどのLLMのデザイン出力が悪いのは、空気を読まずに既定の美学へ飛びつくからだ」と前提を置き、生成の前に必ず一行の「Design Read（デザインの読み）」を宣言させる。

この一行宣言が効くのは、生成の前提を可視化して固定するからだ。「ページの種類は何か」「読者は誰か」「競合はどこか」「既存のブランド資産はあるか」を読み取り、一行に凝縮してから手を動かす。ブリーフが曖昧なときは「質問を一つだけ投げ、決して当て推量しない」とまで指定される。複数質問の連射も、勝手な思い込みも禁止だ。生成AIにありがちな「とりあえずそれっぽく作って全部やり直し」を、入口で断つ設計になっている。

そして§2では、ブリーフがMaterial / Fluent / Carbon / Polaris / shadcn / Tailwindのような既存デザインシステムを指していると読めたら公式パッケージに手を伸ばせ、ブリーフがガラスモーフィズムやベント、ブルータリズムのような「美学」を指しているならWeb標準で実装し、正直にラベリングしろと分岐する。Apple風のLiquid Glassは「公式パッケージではなく近似だ」と明記して扱う、という誠実さまで書き込まれている。

v1からv2へ——「AI Tells」を潰すハードルール群

taste-skillの設計思想が最も濃く出ているのが、CHANGELOGに記録されたv1→v2（experimental）の差分だ。v2は中核スキルの大幅な書き直しで、ダイヤル駆動の哲学は保ちつつ、エージェントが実際に従える構造・ハードルール・具体的な実装パターンを足した。CHANGELOGはその動機をこう説明する。「v2以前のtaste-skillは方向性は正しかったが、エージェントが読み飛ばしやすかった。本番テストで同じTellがビルドのたびに現れた——至るところのem-dash、セクション番号のeyebrow、『Quietly in use at』、装飾的なドット、styled divで作った偽スクリーンショット、壊れたGSAPスクロールトリガー」。

つまりv2は、「禁止リストを書いても守られない」という運用上の失敗に対する答えだ。守らせるために、ルールをハード化し、正典コードの骨格を与え、出荷前チェックリストを義務化した。中でも象徴的なのが em-dash（—）の全面禁止 である。

なぜem-dashなのか。生成AIの英語出力は、人間が手で打つより圧倒的に高い頻度でem-dashを使う。だからem-dashの濫用は、コンテンツが機械生成であることのほぼ確実な指紋になる。taste-skillはこの一点を「最重要のTell」と位置づけ、ゼロ容認で潰す。皮肉なことに、この厳格さこそがtaste-skillの本質をよく表している。テイストとは曖昧な感性ではなく、観測可能な失敗パターンの集合を一つずつ禁止していく工学なのだ。

v2が禁止・矯正したルールは多岐にわたる。代表的なものを「AIが”デザインした風”に振る舞うときに出る癖」として整理する。

加えてv2は、技術スタックの推奨も更新した。CSSはTailwind v4を既定とし、アニメーションは Motion（Framer Motionの改称、motion/react）に標準化。GSAPについては「Sticky-Stack」「Horizontal-Pan」「Scroll-Reveal Stagger」の正典コード骨格を用意し、逆に window.addEventListener('scroll') での自前スクロール計算や、Reactのstateを触る requestAnimationFrame ループは禁止パターンとして名指しした。MOTION_INTENSITY > 3 のアニメーションには useReducedMotion() か prefers-reduced-motion を必須化——派手さとアクセシビリティの両立まで規約に落ちている。デザインの判断と、その判断を裏切らない実装の両方を、ファイル一枚で縛るのがv2の到達点だ。

13種のスキルをどう使い分けるか

taste-skillは単一のスキルではなく、単機能のスキルを束ねたライブラリだ。READMEは「各スキルは一つの仕事をする。全部を一度に入れる必要はない」と明言する。実装スキル（コードを出す）と画像生成スキル（参照画像だけを出す）に分かれ、それぞれにinstall名が割り当てられている。主要なものを対比する。

使い分けの指針もREADMEに明快に書かれている。まずは taste-skill（v2）を安全な既定として始める。GPTやCodexで厳格なルールを効かせたいなら gpt-taste。グリーンフィールドではなく既存コードベースを改善したいなら redesign-skill。視覚の方向性がすでに決まっているなら soft / minimalist / brutalist を足す。エージェントが出力を途中で切るなら output-skill。成果物が「コード」ではなく「画像」（コンプ・フロー・アイデンティティボード）なら imagegen-* や brandkit で参照画像を作り、それをコーディングエージェントへ渡す——という流れだ。

この単機能・組み合わせ式の設計は、Agent Skillsの思想とよく噛み合っている。巨大な万能スキルを一つ抱えるより、目的別の小さなスキルを必要なだけ合成するほうが、文脈を軽く保て、挙動も読みやすい。taste-skillは「テイスト」という曖昧な対象を、用途別に切り分けて配布可能にした点で、Skillエコシステムの実用的なショーケースにもなっている。

ブリーフから出荷まで——taste-skillの一周

ここまでの部品（ダイヤル・Brief Inference・AI Tells禁止・出荷前チェック）が、実際の生成でどう一周するのかを流れにまとめる。これはSKILL.mdの§0→§1→§9→§14という章立てを、そのまま処理フローに直したものだ。

注目すべきは、フローの最後に置かれた §14 Final Pre-Flight Check（出荷前チェック） が、ループの出口を絞る関門になっている点だ。SKILL.mdはこれを「ハードなチェックリスト。出荷前にすべての項目が正直にパスしなければならない」と書く。チェック項目には「§9のAI Tellsが残っていないか（Interが既定、AI紫、3枚等しいカード、Jane Doe、Acme、『Quietly in use at』）」が機械的に含まれる。生成して終わりではなく、自分の出力を既定の失敗リストと照合してから出す——この自己点検の一手が、「それっぽいが結局スロップ」と「本当にテイストのある出力」を分ける。

既存の「AIデザイン」アプローチとの違い

「AIに綺麗なUIを作らせる」手段はtaste-skillだけではない。代表的な選択肢と並べると、taste-skillの立ち位置がはっきりする。

差は「アンチスロップの規律を、どこに、どの粒度で固定するか」に集約される。素のプロンプトは規律が揮発し、毎回ゼロから書き直しになる。生成サービスは規律をサービス内に閉じ込め、外のエージェントには持ち出せない。taste-skillは規律をテキストファイルに外出しし、どのエージェントにも携帯させる。Anthropic純正の Claude Design Guide（クロードでデザインする実践ガイド） がClaude本体の使いこなしに寄っているのに対し、taste-skillはエージェント非依存の「持ち運べるルール」として補完関係に立つ。両者は競合ではなく、レイヤーが違う。

この「規律をファイルに固める」発想は、エージェント設計の潮流とも地続きだ。手順や判断をプロンプトの一回性から救い出し、再利用可能な部品にする動きは、AIエージェント設計パターン入門 で整理した諸パターンと同じ方向を向いている。taste-skillは、その「テイスト」版だと言える。

なぜ「テイスト」をスキルとして配るのか

最後に、このリポジトリの名前そのものに込められた賭けを考えたい。なぜ「taste（テイスト）」なのか。手がかりは、OpenAI共同創業者のGreg Brockman氏が掲げた一文だ。

taste is a new core skill

— Greg Brockman (@gdb) February 16, 2026

「テイストは新しいコアスキルだ」。コードを書くこと自体がボトルネックでなくなった時代に、何を良しとするかの判断こそが希少資源になる、という主張である。AIが10個のUIを30秒で出せるなら、価値は「作れること」から「どれが良いかを見分け、なぜ良いかを言語化できること」へ移る。当サイトでも ループエンジニアリングとは何か の結論として、自律ループの最後のボトルネックはモデルの賢さではなく人間の「テイスト」だと整理した。taste-skillは、まさにその主張に対する一つの実装解答になっている。

ここにtaste-skillの本質がある。テイストは天賦の感性ではなく、観測可能な失敗パターンの否定の集合として、かなりの部分を言語化できる——という賭けだ。「紫グラデを避けよ」「3枚の等しいカードを避けよ」「em-dashをゼロにせよ」。一つひとつは小さな禁止だが、束ねれば「AIっぽさ」というぼんやりした概念がくっきり輪郭を持つ。そしてテキストに落ちた瞬間、テイストはコピーでき、配布でき、バージョン管理できる資産に変わる。CHANGELOGがv1→v2の差分を律儀に記録しているのは、テイストをソフトウェアのように進化させられる、という確信の表れだ。

もちろん限界もある。禁止リストは「悪い既定値からの脱出」を保証するが、「本当に優れたデザイン」を保証はしない。スロップでないことと、良いことは違う。taste-skillが配れるのは「平均以下に落ちない床」であって、「傑作に届く天井」ではない。それでも、AIが床下まで沈みがちな現状では、床を上げるだけで十分な価値がある。テイストの全部はファイルにできなくても、最も多く破られる失敗の半分はファイルにできる——taste-skillはその実証だ。

注意点・既知の課題

実戦投入の前に、押さえておくべき制約がいくつかある。

総じて、taste-skillは「銀の弾丸」ではなく「規律の外部化」のツールだ。AIに丸投げして傑作が出るわけではないが、AIが必ず落ちる穴を先回りで塞ぎ、出力の下限を引き上げる。LP・ポートフォリオ・既存改修という限定された土俵では、無料・MIT・エージェント非依存という三拍子が効いてくる。まずは npx skills add で design-taste-frontend を一つ入れ、いつものプロンプトと出力を比べてみるのが、最も手早い評価方法だろう。

関連記事——Skillとデザインを深掘りする

taste-skillは、Agent Skillsの仕組みとAIデザインの潮流の交点に立つ。位置づけを深めるには次の記事が役立つ。

・Claude Skills（SKILL.md）とは何か：taste-skillが載っている土台。SKILL.mdの仕組みと作り方を押さえると、taste-skillが「なぜファイル一枚で配れるのか」が腑に落ちる
・Claude Design Guide（クロードでデザインする実践ガイド）：Claude本体でデザインを詰める実践。taste-skillと補完関係にあるレイヤー
・AIエージェント設計パターン入門：判断や手順を再利用可能な部品にする発想の地図。taste-skillはその「テイスト」版
・ループエンジニアリングとは何か：自律ループの最後のボトルネックが「テイスト」だと整理した記事。本記事のBrockman論と直結
・OpenAI Codex CLI 完全ガイド：taste-skillが対応するCodex側の使いこなし。gpt-taste を効かせたいとき

まとめ——テイストは、ファイルにできる

taste-skillは、AIコーディングが抱える静かな弱点——誰が頼んでも同じ顔のUIが出てくる「スロップ」——に、真正面から名前を付けたツールだ。紫グラデ、中央ヒーロー、3枚の等しいカード、Inter＋slate-900、em-dashの濫用。これらをSKILL.mdの中で一つずつ禁止し、3つのダイヤルで方向を宣言させ、出荷前チェックで自己点検させる。賢いモデルを足すのではなく、愚かな既定値を引くことで、出力の下限を引き上げる。

公開から約4か月でスター約5万という反応は、この弱点が多くの開発者の実感と一致していたことを示す。v1→v2の書き直しは、「禁止リストを書いても読み飛ばされる」という運用上の壁を、ハードルールと正典コードと出荷前チェックで突破しようとする試みだった。一方で、既定スキルはまだv2 experimentalであり、対象もLP・ポートフォリオ・改修に限られる。テイストの良し悪し自体は主観で、ルールはあくまで床を上げる足場だ。当サイト（AI Heartland）はこのツールの提唱者ではなく、公式リポジトリの一次ソースを整理する観察者の立場で、READMEとCHANGELOGとSKILL.mdに書かれた事実だけをここまで並べてきた。

それでも、Greg Brockman氏の「テイストは新しいコアスキルだ」という言葉が示すとおり、判断の質が希少資源になる時代に向かっているのは確かだ。taste-skillが投げかけた問い——「テイストは、ファイルにできるのか」——への答えは、まだ実験の途中にある。だが「最も多く破られる失敗の半分はファイルにできる」という一点だけでも、AIにUIを任せる人にとっては十分に試す価値がある。

参照ソース

・Leonxlnx/taste-skill — GitHub リポジトリ
・taste-skill — README（The Anti-Slop Frontend Framework for AI Agents）
・taste-skill — CHANGELOG（v1 → v2 experimental の差分とAI Tells）
・taste-skill — SKILL.md（design-taste-frontend, v2 experimental）
・taste-skill 公式サイト（tasteskill.dev）
・vercel-labs/agent-skills — npx skills add CLI
・Greg Brockman（@gdb）— taste is a new core skill