11分で読めます
  • AI
  • 制作
  • ツール
  • フロントエンド

AIのUIを「いつもの形」から抜け出させるTaste Skill入門

GitHub Trendingで注目を集めるTaste Skillを、最新版の導入コマンドから実ブラウザ検査まで追います。AIが作る画一的なUIを、デザイン判断の手順としてどう変えられるか、向き不向きと日本語画面での注意点も整理します。

カテゴリー: AI · 制作 · ツール · フロントエンド | 公開: 2026年10月30日 | 読了目安: 約11分

📑 目次

「AIにトップページを作って」と頼む。すると、中央に大きな見出し、三つ並んだカード、紫から青へのグラデーション、意味ありげな小さなラベル……。動いてはいるけれど、どこかで見た景色が返ってくることがあります。

ふむふむ。これはAIの技術が足りないというより、最初に選ぶデザインの道が、いつも同じなのかもしれません。

今回、GitHub Trendingの週間一覧で目に留まったのが、Leonxlnx/taste-skill でした。名前からして「AIに味覚を渡す」感じがします。でも、本当にセンスを渡せるのでしょう。実際に入るのは、新しいCSSライブラリでも、完成済みの部品集でもありません。AIエージェントに読ませる、かなり長い設計の手順書です。

ちょっと待って。手順書で画面が変わるなら、私たちが普段「なんとなく良い」と呼んでいるものも、ある程度は手順にできるということなのでしょうか。

Taste Skillは何を変えるのか

Taste Skillの中心にあるのは、SKILL.md というMarkdownファイルです。そこには、ページを作る前に依頼内容を読み、ページ固有の材料を洗い出し、デザインの方向を選び、実際のブラウザで確かめる手順が書かれています。

つまり、AIに「おしゃれにして」とお願いする道具ではありません。AIがコードを書き始める前に、次のような判断を挟むための型です。

  • このページは、何を読ませ、何をしてもらう場所なのか
  • そのプロダクトにしかない材料は何か
  • どのデザイン方向なら、その材料を伝えられるか
  • 画面幅が変わっても、最初の主張は読めるか
  • 使った画像やコードは、実際に存在し、検証できるか

公式READMEによると、現在の標準スキルは、247サイトの調査を土台にしています。ページを作るときは、調査済みの20方向から3つを引き、そこから1つを選ぶ。選んだ方向に合わせて、写真、書体、配色、セクション構成を組み立て、最後に3つの画面幅でブラウザ検査をします。スクリーンショットを見て、最大3回まで上位の問題を直す流れも含まれます。

ここで面白いのは、いきなり「正解のデザイン」を出そうとしないところです。まず候補を並べ、その中からプロダクト固有の材料を一番運べるものを選ぶ。デザインを、ひらめきだけでなく選択の履歴に変えているんですね。

2026年10月時点の注意点。古い紹介記事と少し違う

Taste Skillは更新が速く、日本語で見つかる紹介には古い構成を前提にしたものもあります。ここは先に整理しておきます。

現在のリポジトリで、標準としてインストールする名前は design-taste-frontend です。2026年10月25日の変更履歴にある最新リリースは 2.1.5。以前の実験版や、ミニマル系・ブルータリスト系・画像生成系のスキルは、別リポジトリへ移動しています。

そのため、古い記事に出てくる次のような名前を、現在のリポジトリ内にある前提で追加しない方が安全です。

  • design-taste-frontend-v2-experimental はクラシック版リポジトリに旧実験版として保存されています
  • high-end-visual-design や minimalist-ui などはクラシック版の別リポジトリです
  • image-to-code や画像生成系は画像生成スキルの別リポジトリです
  • redesign-existing-projects の役割は、現在の標準スキルに統合されています
  • full-output-enforcement は削除され、別のプロジェクトが案内されています

なるほどねえ。スキルの名前が変わったというより、「最初に入れるものを一つに絞った」変更なんです。まず標準の design-taste-frontend だけを使い、必要な別スキルは公式READMEの移動先から選ぶ。この順番が、今の仕様には合っています。

導入する

前提は、Node.js 22以上と、Chrome、Edge、またはChromiumです。画像を探すときにはネットワーク接続が必要ですが、APIキーは要りません。Taste Skill自体がアプリに常駐して動くというより、エージェントが作業中に読む指示と、検査用のスクリプトが入っています。

プロジェクトのルートで、標準スキルだけを追加します。

npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"

この npx skills はTaste Skill専用のコマンドではなく、Vercel LabsのAgent Skills用CLIです。インストール後、使っているエージェントを再読み込みしてください。

Claude Codeのプラグインとして入れる場合は、公式READMEに次の手順もあります。

/plugin marketplace add Leonxlnx/taste-skill
/plugin install taste-skill@taste-skill

Codexのプラグインとして入れる場合は、こちらです。

codex plugin marketplace add Leonxlnx/taste-skill
codex plugin add taste-skill@taste-skill

Codexでは、追加後に新しいセッションを始めます。どの方法でも、外部リポジトリの指示をエージェントに読ませることになります。いきなり本番リポジトリへ入れるのではなく、SKILL.md と scripts/ を一度確認してから使うのがおすすめです。

最初の依頼は「作って」ではなく「読んで」にする

インストール直後に「全部いい感じにして」と頼むと、Taste Skillを入れた意味が薄くなります。最初は、どんなページを作るのかをエージェント自身に言葉にさせます。

たとえば、次のように依頼します。

このプロジェクトの公開ページを、design-taste-frontendの手順に沿って設計してください。

目的:
- 初めて来た人に、何のサービスかを短時間で伝える
- 最終的にはデモを試してもらう

ページ:
- AIで出典付きのメモを整理する小さなアプリの紹介ページ
- 読者は個人開発者と調査好きな編集者
- 技術スタックは既存の構成を維持する
- 既にあるロゴ、URL、法的文言、主要な導線は変更しない

まずコードを変更せず、次の内容だけを出してください。
1. このプロダクト固有の材料を8〜12個
2. ページの主張と、各セクションが証明すること
3. デザイン方向の候補と、選んだ理由
4. 実在する画像や画面素材の一覧
5. 画面幅が狭くなったときに壊れそうな点

公式の手順でも、最初に名前の意味、場所、数字、制約、素材、習慣のような「その依頼にしかないもの」を棚卸しします。ここを飛ばしてしまうと、Taste Skillを使っても、別の種類のテンプレートに着替えるだけになりやすいんです。

方向を抽選してから作る

スキルのフォルダを直接取得して、方向抽選のスクリプトを試すこともできます。これは記事執筆時点で実際に実行できたコマンドです。

git clone https://github.com/Leonxlnx/taste-skill.git
cd taste-skill

node skills/taste-skill/scripts/draw.mjs --list sectors
node skills/taste-skill/scripts/draw.mjs --list roles

--list sectors では、saas、dev-tool、ai-product、education、culture などの対象分野が表示されます。--list roles では、features、showcase、how-it-works、proof、pricing、faq、cta などの役割を確認できます。

次に、ページの材料を一行で渡して、候補を3つ出します。ヒーローは自動的に含まれるため、--sections には後続の役割を並べます。

node skills/taste-skill/scripts/draw.mjs \
  --sector dev-tool \
  --brief "a small AI tool that keeps source-linked research notes" \
  --sections showcase,features,how-it-works,proof,cta,footer \
  --tone technical \
  --options 3

私が同じ形式で試したときは、文字と余白だけで最初の画面を作る方向、タイルを整然と並べる方向、実際に動く製品画面を主役にする方向が出ました。ここで一番見慣れた案を選ぶのではなく、「このプロダクト固有の材料を運べるか」で選ぶのがポイントです。

選んだ方向のIDを指定して、今度は完全な設計シートを出します。

node skills/taste-skill/scripts/draw.mjs \
  --sector dev-tool \
  --brief "a small AI tool that keeps source-linked research notes" \
  --sections showcase,features,how-it-works,proof,cta,footer \
  --tone technical \
  --direction <選んだ方向のID>

この設計シートをエージェントに読み返させ、配色、書体、画像、各セクションの役割を確認してから実装へ進みます。ランダム性は、AIに丸投げするためではなく、いつもの初期案から一歩外へ出るための補助線として使うわけです。

ブラウザで検査する

Taste Skillのもう一つの特徴は、「作ったと言ったから終わり」にしないところです。対象ページを起動した状態で、実ブラウザを使う検査スクリプトを実行します。作業ディレクトリは対象プロジェクトのルートに置き、<skill> はインストールまたはクローンしたスキルのフォルダに読み替えます。

node <skill>/scripts/inspect.mjs http://127.0.0.1:3000 \
  --out .taste-skill/inspect \
  --widths 1440,768,390

検査対象はデスクトップだけではありません。標準では1440、768、390ピクセル幅でページを開き、タイトルが最初の画面にあるか、文字が隠れていないか、横にはみ出していないか、画像や動きが実際に存在するかを見ます。inspect.mjs は、失敗がなければ終了コード0、FAILがあれば1を返します。

ソースコード側の静的チェックは、次のコマンドです。

node <skill>/scripts/lint.mjs src/

こちらは、グラデーション、装飾的な番号、細すぎる罫線、意味のない小見出し、絵文字によるUI、プレースホルダー文言など、スキルが避けるパターンをソースから探します。もちろん、検出されない問題もあります。日本語の改行、実際の読みやすさ、キーボード操作、スクリーンリーダーの解釈は、人間が確認する領域です。

画像が必要なときは、プロジェクト固有の素材を最優先にします。用意できない場合、公式スクリプトはWikimedia CommonsやOpenverseなどのオープンなコレクションから、利用条件を確認できる画像を探し、クレジットを残す流れを持っています。CC BYなど、表示が必要なライセンスは必ずページに残します。見つけた写真を、プロダクト自身の写真や利用者の声のように見せてはいけません。

ここは過信しない

「美しいUI」が常に正解ではない

Taste Skillの標準版は、ランディングページ、製品ページ、ポートフォリオのように、ページの印象や物語が重要な場面と相性が良いです。

一方、管理画面やデータ表では、反復するパネル、静かな境界線、数字の揃い方が価値になります。現在のv2.1には、ダッシュボードや設定画面向けの別ルートもありますが、公開ページのルールをそのまま管理画面へ貼るものではありません。画面の目的を最初に分けてください。

デザインの判断を、別のテンプレートにしない

247サイトの調査を土台にしているからといって、結果が必ず独自になるわけではありません。候補を抽選しても、入力する材料が薄ければ、抽選された方向をなぞるだけです。

「自社にしかないものは何か」「その画面で読者に何をしてほしいのか」を、人間が決める必要があります。Taste Skillが渡すのは完成品ではなく、判断を始めるための制約です。

日本語の画面は別に読む

スキルの本文は英語です。日本語の見出しは英語より長くなったり、漢字とひらがなの混ざり方で密度が変わったりします。欧文の書体や英語前提の行長をそのまま採用すると、日本語だけ窮屈になることもあります。

少なくとも次は、生成結果を見ながら調整したいところです。

  • 390ピクセル前後で見出しが何行になるか
  • 日本語のボタンが折り返さないか
  • 英数字と日本語のベースラインが揃っているか
  • 画像のクレジットや法的文言が読めるか
  • prefers-reduced-motion の設定で内容が隠れないか

ここを人間が引き受けるなら、英語の設計手順を日本語の現実へ翻訳する道具として、かなり使いやすくなります。

まとめ。味覚は、禁止事項ではなく選ぶ力

Taste Skillが面白いのは、AIに「もっと個性的に」と叫ぶのではなく、作る前に材料を集め、方向を選び、ブラウザで失敗を見つける順番を持ち込んだことです。

ただし、AIのUIが似てしまう理由は、AIだけにあるとも限りません。私たち人間も、成果が見えやすいカードやグラデーションに寄りかかります。禁止リストを増やすだけでは、今度は「禁止を守っただけの画面」が生まれるかもしれません。

だから、チカちゃん的には、Taste Skillをデザインの先生というより、下書きの前に机を片づける編集者として使うのがよさそうです。まず自分のプロダクトにしかないものを探す。そのあとで、AIに別の道を歩かせてみる。

AIが作る画面から「AIっぽさ」を消したいとき、本当に消したいのは、見た目の記号でしょうか。それとも、私たち自身がまだ選んでいないことなのでしょうか。

参考URL

GitHub週次Trending → https://github.com/trending?since=weekly

Taste Skill公式リポジトリ → https://github.com/Leonxlnx/taste-skill

Taste Skill最新版の変更履歴 → https://github.com/Leonxlnx/taste-skill/blob/main/CHANGELOG.md

design-taste-frontendの手順書 → https://github.com/Leonxlnx/taste-skill/blob/main/skills/taste-skill/SKILL.md

Taste Skill公式ガイド → https://www.tasteskill.dev/guide

Agent Skills用CLI → https://github.com/vercel-labs/agent-skills

  • インターネット上のツールは第三者が提供するものです。開発工程や配布経路を悪用した攻撃(サプライチェーン攻撃)が仕掛けられる可能性もゼロではありません。ご利用の際は公式リポジトリの情報をご確認いただき、自己責任でお使いください。
  • AIに関する技術や情報は急速に変化します。本記事の内容が公開後に古くなる可能性があります。各サービスの公式ドキュメントや最新情報をご確認ください。