AIが作る「それっぽいだけ」のUIをTasteSkillで直す方法：実践ガイド

はじめに

こんにちは。次世代ベトナム研究室のK.X.Dです。

AIエージェントによるフロントエンド開発は急速に普及しています。プロンプトを一行投げれば、それらしいランディングページが数秒で返ってくる時代です。ところが出てきた画面をよく見ると、中央寄せのヒーロー、3つ並んだ同じカード、絵文字アイコン、紫のグラデーションなど、どこかで見た「テンプレ的」な顔に落ち着きがちです。動くけれど、あと一歩。この「AIっぽさ（slop）」は、いまや開発現場の共通課題になっています。

本記事では、AIコーディングエージェント向けのオープンソース「TasteSkill（design-taste-frontend）」に焦点を当て、スキルを実際にインストールして、あり/なしで出力がどう変わるかを自分の手で検証した実践記録をお届けします。1つのページだけでなく、SaaS・ポートフォリオ・エージェンシー・消費者アプリの4種類で同じ比較を行い、機械的に数えられる指標（em-dashの数、絵文字、実画像の有無、レイアウトなど）で差を確かめました。対象読者は、Claude Code・Cursor・Codexなどをすでに使っている方はもちろん、AIが生成するUIの「あと一歩」に悩むエンジニア全般を想定しています。

2025年のStack Overflow開発者調査では、AIツールに対する最大の不満として66%が「ほぼ正しいが、あと一歩」の出力を挙げました（Stack Overflow, 2025 Developer Survey）。コードだけの話ではありません。AIコーディングエージェントが吐き出すフロントエンドも同じで、動くけれど、どこかテンプレ臭い。中央寄せのヒーロー、3つ並んだ同じカード、絵文字アイコン、紫のグラデーション。本ガイドでは、オープンソースの TasteSkill（design-taste-frontend）を使って、その「あと一歩」を埋める手順を、実際に手元で回したbefore/after検証つきで解説します。

この記事の要点（Key Takeaways）

• AI生成UIの「テンプレ臭さ」は2025年に社会語になった現象で、「slop（スロップ）」はMerriam-Websterの2025年の言葉に選ばれました（PBS, 2025年12月）。
• TasteSkillは公開から約3か月で28,464スターを集めたMITライセンスのスキルファイル群で、npx skills add で既存のAIエージェントに追加できます。
• 本記事独自の検証では、同じ指示でも、スキルなしのUIにはem-dashが3個・絵文字が3個・実画像が0枚だったのに対し、TasteSkill適用後はem-dash 0個・絵文字0個・実画像2枚・専用書体・非対称レイアウトに変わりました。この傾向は4種類のページ（SaaS・ポートフォリオ・エージェンシー・消費者アプリ）すべてで再現しました。

AIに任せたUIが「悪くはないけど、どこかで見た顔」になってしまうのはなぜか。そして、それを設定ファイル数本でどこまで直せるのか。実際の画面を並べて確かめていきます。

なぜAIは「それっぽいだけ」のUIを作るのか？

AIコーディングエージェントの普及で、フロントエンドの初稿はほぼ無料になりました。2025年のStack Overflow開発者調査では、回答者の84%がAIツールを利用中または利用予定と答え、前年の76%から増えています（Stack Overflow, 2025 Developer Survey）。JetBrainsの2025年の調査でも、85%が定期的にAIツールを使っていました（JetBrains, The State of Developer Ecosystem 2025）。さらにGitHubのOctoverse 2025によれば、新規開発者の約80%が登録初週のうちにAIコーディング支援（Copilot）を使い始めています（GitHub, Octoverse 2025）。問題は量ではなく、出てくるものの「顔」が似通うことです。

理由はシンプルです。モデルは学習データの中央値、つまり最も平均的なランディングページを再生産します。誘導しなければ、安全で無難な既定値に落ち着く。中央寄せのヒーロー、Inter、薄いグレーの背景、角丸8pxのカード3枚。どれも間違ってはいませんが、全部同じに見える。

この現象には名前がつきました。2025年12月、Merriam-Websterは「slop（スロップ）」を2025年の言葉に選び、「AIによって大量に生産される低品質なデジタルコンテンツ」と定義しています（PBS NewsHour, 2025年12月）。テキストだけでなく、画像も、そしてUIもその対象です。

AIコーディングツールの利用率（2025年）Stack OverflowJetBrainsGitHub 新規84%85%~80%

2025年のJetBrains調査が示すように、85%の開発者が日常的にAIを使う以上、AIが量産する「平均的な顔」をどう抜け出すかは、もはや個人の好みの問題ではなく、差別化の問題です（JetBrains, The State of Developer Ecosystem 2025）。フロントエンドの初稿の質は、そのまま製品の第一印象になります。

【検証】TasteSkill あり/なしで、同じ指示はどう変わるのか？

同じブリーフを使い、デザイン指示の有無だけを変えて2回ビルドしたところ、出力は別物になりました。スキルなしでは中央寄せ・絵文字・テンプレ的な3カード、TasteSkill適用後は非対称レイアウト・アイコンライブラリ・実画像・専用書体になりました。以下は実際の画面です。

2-1. スキルなし（ベースライン）

誘導なしの一発出力です。動きますし、破綻もしていません。ただ「どこかで見た顔」です。

2-2. TasteSkill 適用後

同じブリーフに design-taste-frontend スキルを足しただけです。非対称のスプリットヒーロー、ダークテック調、ライムの単一アクセント、実画像、Phosphorアイコン、スクロールリビールが入りました。

2-3. 客観的な差分（HTMLから機械的に計測）

主観を排し、ソースから数えられる指標だけを並べました。

指標	スキルなし	TasteSkill適用
em-dash（—、可視テキスト）	3	0
絵文字	3	0
アイコンライブラリの字形	0	15
指定ディスプレイ書体（Inter/system回避）	なし	あり（Geist）
実画像の枚数	0	2
型スケールの段階数（font-size宣言）	8	16
ヒーローの中央寄せ	はい	いいえ（左寄せ・非対称）
非対称frグリッド列	0	2
モーション + prefers-reduced-motion対応	なし	あり
ダークテーマ + 単一アクセント固定	なし	あり

数字のうち、特に効くのはem-dashです。TasteSkillはem-dash（—）を「LLMの最大の手癖（tell）」として完全禁止しています。誘導なしの出力にはコピーに3個混ざっていましたが、スキル適用後はゼロでした。絵文字アイコンがアイコンライブラリの字形15個に置き換わり、テキストだけだった画面に実画像が2枚入った点も、設計の意図がコードに現れた具体例です。

書体やレイアウトの差は、TasteSkillの「Inter回避」「中央寄せ回避（DESIGN_VARIANCE > 4）」といったルールが効いた結果です。では、これは1つのページだけの「たまたま」ではないのか。次でそれを確かめます。

2-4. レプリケーション：他の種類のページで同じことが起きるか

1つの事例では偶然を否定できません。そこで、性質のまったく異なる4種類のブリーフ（このSaaSのSendwell、開発者ポートフォリオ、クリエイティブエージェンシー、消費者向けアプリ）で同じ「なし vs TasteSkill」を実施しました。結果、機械判定できるスロップ兆候は、すべてで同じ向きに反転しました。

上の2枚はエージェンシーの例です。ベースラインは「AIパープルのグラデーション＋中央寄せ＋3つの同じカード」という定番、TasteSkill側は巨大なエディトリアル見出しと非対称レイアウトに変わりました。残りの2種類も、同じ向きの変化が起きています。

ポートフォリオ（開発者向け）。 ベースラインは中央寄せのヒーロー、絵文字の3等分カード、コピーにem-dash。TasteSkill適用後は左寄せの非対称ヒーロー、案件を番号付きのインデックス行で見せる構成、実写真のAboutに変わりました。

消費者向けアプリ。 ベースラインは中央寄せ、絵文字のカード、対称な価格表。TasteSkill適用後はforest系の配色（プレミアム消費財の定番であるベージュ＋真鍮色をあえて避ける）、非対称ヒーロー＋実画像、非対称ベントに変わりました。

ブリーフ全体を集計すると次のとおりです。

指標	スキルなし	TasteSkill
em-dash（—）	3〜4個	0個
絵文字アイコン	3個	0個
アイコンライブラリ字形	0個	3〜15個
systemフォント/Inter依存	全部	0
指定ディスプレイ書体	0	全部
実画像	0枚	1〜2枚
中央寄せヒーロー	全部	0
非対称グリッド列	0	全部
モーション＋reduced-motion対応	0	全部
型スケール段階数	8〜10	10〜16

TasteSkill とは何か？（何を変えるのか）

TasteSkillは、AIエージェントが生成するフロントエンドの「テンプレ臭さ」を抑えるためのオープンソースのスキルファイル群です。GitHub（Leonxlnx/taste-skill）では、2026年2月19日の公開から約3か月で28,464スター・2,106フォークを集め、MITライセンスで配布されています（2026-05-30時点）。リポジトリの説明文はそのまま思想を表しています。

「gives your AI good taste. stops the AI from generating boring, generic slop」。

仕組みはルールブックです。design-taste-frontend というスキルが、エージェントに対して「ブリーフを読んでからデザイン方針を推論する」「既定値に逃げない」「禁止パターンを避ける」という一連の規律を与えます。v2では次のような中身を持ちます。

• ブリーフ推論（brief inference）：コードを書く前に、ページ種別・対象読者・トーンを言語化する。
• 3つのダイヤル：DESIGN_VARIANCE（対称↔非対称）、MOTION_INTENSITY（静的↔シネマティック）、VISUAL_DENSITY（余白↔高密度）で出力を制御する。
• em-dashの完全禁止と、絵文字・AIパープル・「3つの同じカード」などのAI tellの抑制。
• redesign-audit：既存サイトの改修時に、まず現状を監査してから手を入れる。
• strict pre-flight check：出力前にチェックリストで自己点検する。

TasteSkillは2026年2月の公開後わずか3か月で28,464スターを獲得し（2026-05-30時点）、AI生成UIの品質問題が一過性の不満ではなく、開発者コミュニティ全体の共通課題であることを示しました。MITライセンスのスキルファイルとして、Claude Code・Cursor・Codexにそのまま追加できます。

なぜこれが刺さるのか。理由は信頼です。2025年のStack Overflow調査では、AIの正確性を「信頼しない」開発者が45.7%にのぼり、「信頼する」32.7%を上回りました（Stack Overflow, 2025 Developer Survey）。出力の「あと一歩」が積み重なるほど、人は手戻りを覚悟します。デザインのテンプレ臭も同じ「あと一歩」で、TasteSkillはそこを規律で詰めにいきます。

66%「あと一歩」が最大の不満

始める前に（前提条件）

導入は数分で終わります。必要なのはAIコーディングエージェントと、スキルを取得するための npx（Node.js）だけです。

• 対応エージェント：Claude Code、Cursor、Codex（READMEのバッジ準拠）。SKILL.md形式を読めるエージェントが前提です。
• Node.js：npx skills を使うため v18以上を推奨。
• 対象：ランディングページ、ポートフォリオ、リデザイン。ダッシュボードやデータテーブルは対象外です。
• 所要時間：インストールから初回の生成まで約15分。
• 難易度：初級〜中級。

Step 1：TasteSkill をインストールする

まずはインストールです。ターミナルで次のコマンドを1行実行すれば、お使いのエージェントに design-taste-frontend（v2）が追加されます。

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

既定では実験的なv2（design-taste-frontend）が入ります。安定したv1の挙動が必要なプロジェクトでは、明示的にv1を指定します。

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

うまくいけば、エージェントのスキル一覧に design-taste-frontend が表示されます。Claude Codeなら一覧で認識を確認しましょう。

Step 2：用途に合うスキルのバリアントを選ぶ

TasteSkillは1つのスキルではありません。実装系と画像生成系を合わせて11以上のスキルがあり、案件に応じて選びます。

• design-taste-frontend（v2・既定）：汎用のアンチスロップ。まずはこれ。
• minimalist-ui / industrial-brutalist-ui：振り切った美学が欲しいとき。
• redesign-existing-projects：既存サイトの改修向け。
• high-end-visual-design：プレミアム寄りの仕上げ。
• imagegen-frontend-web / brandkit：画像・ブランドキット生成。

目安として、新規ランディングのほとんどは既定の design-taste-frontend で足ります。迷ったら既定から始め、美学を振りたいときだけ別バリアントへ切り替えましょう。

Step 3：3つのダイヤルを調整する

出力のトーンは、数値で指示できます。TasteSkillは3つのダイヤルでレイアウト・モーション・密度を制御し、会話の中で値を伝えるだけで連動して変わります。

• DESIGN_VARIANCE（1〜10）：1は完全対称、10は非対称・実験的。4を超えると中央寄せヒーローを避けます。
• MOTION_INTENSITY（1〜10）：1は静的、10はシネマティック。3を超える動きは必ず prefers-reduced-motion を尊重します。
• VISUAL_DENSITY（1〜10）：1は余白多めのギャラリー調、10は高密度のダッシュボード調。

SaaSランディングの既定プリセットは 7 / 6 / 4 です。

今回の検証では、技術読者向けに 7 / 5 / 4 に寄せました。

試しに「DESIGN_VARIANCEを8に上げて」と頼んでみてください。ヒーローが中央寄せから非対称スプリットに変われば、ダイヤルが効いています。

Step 4：ブリーフを書く（推論を効かせる）

ここが効きどころです。TasteSkillの核は「ブリーフ推論」で、コードの前に「誰のための、どんなページか」を読み取らせると、AIは既定値に逃げにくくなります。

良いブリーフには次が含まれます。ページ種別（ランディング/ポートフォリオ/改修）、対象読者（B2Bの技術バイヤーか、消費者か）、トーンを表す語（「Linear風」「ミニマル」「ブルータリズム」）、既存のブランド資産（ロゴ・色・書体）。

生成前にエージェントが「Reading this as: …」と一行のデザイン読み取りを宣言すれば、推論が働いている合図です。曖昧なときは1問だけ質問を返してきます。

Step 5：既存プロジェクトを監査してから直す

既存サイトはどうするか。TasteSkillはいきなり書き換えず、まず現状を監査します（redesign-audit）。狙いは作り直しではなく「壊さない改修」です。

監査では、ブランドトークン（色・書体・角丸）、情報設計（URL・ナビ・導線）、残すべき要素と捨てるべき要素、そしてSEOの基準値を記録します。リデザインの最大のリスクはSEOの毀損なので、URLやナビのラベルは勝手に変えません。

改修を頼んだとき、「保持するか、ゼロから作り直すか」を一度だけ確認してきたら、監査プロトコルが動いています。

Step 6：出力を検証する（テンプレ臭が消えたか）

最後は人間の目です。TasteSkillは出力前にstrict pre-flightチェックを走らせますが、納品前の最終確認はあなたが行います。

検証の勘所は、本記事の検証で数えた指標とそのまま重なります。

1. em-dash（—）がゼロか。1つでもあれば書き直し対象です。
2. 絵文字ではなくアイコンライブラリを使っているか。
3. ヒーローが中央寄せの定番でないか（DESIGN_VARIANCEが高い場合）。
4. 実画像が入っているか。テキスト＋グラデーションだけの「偽ヒーロー」になっていないか。
5. モーションが理由を説明できるか。動きのための動きになっていないか。

検証から得た気づき： 機械的に数えられる指標（em-dash、絵文字、実画像、書体）は、人間がレビューするより速く、ブレません。本記事のbefore/afterも、目視の印象ではなくHTMLからの実数で差を確認しました。

よくある失敗と回避策

最も多い失敗は、ダッシュボードや管理画面にTasteSkillを使ってしまうことです。これは適用範囲外で、結果は出ません。以下の3点に注意してください。

1. 対象外の画面に使う。 TasteSkillはランディング・ポートフォリオ・改修向けです。データテーブルや多段フォームには、Fluent UIやCarbonなど専用システムを使います。
2. ブリーフを省く。 「ランディングを作って」だけでは、推論の材料がありません。読者・トーン・参照を一行でも添えると、出力が安定します。
3. ダイヤルを既定のまま放置する。 プリセットは出発点です。本記事の検証で気づいた通り、DESIGN_VARIANCE を意識的に動かすだけで、中央寄せの定番から抜け出せます。動かさなければ、平均的な顔のままになりがちです。

成功の状態

うまくいけば、初稿の時点で「テンプレ臭」が消えています。具体的には、ヒーローが定番の中央寄せでなく、書体がInterやsystem既定でなく、絵文字がアイコンに置き換わり、実画像が入り、em-dashがゼロになっているはずです。

本記事の検証では、これらが同じブリーフのまま、スキルの有無だけで切り替わりました。次の一歩として、自分のプロジェクトのブリーフで同じbefore/afterを撮り、grep -c "—" でem-dashを数えてみてください。差が数字で見えます。

よくある質問（FAQ）

どのAIコーディングエージェントで使えますか？

READMEのバッジ準拠で、Claude Code・Cursor・Codexに対応します。いずれもSKILL.md形式のスキルファイルを読み込めるエージェントです。npx skills add でリポジトリを指定して追加します。

v1とv2、どちらを使うべきですか？

既定は実験的なv2（design-taste-frontend）で、ブリーフ推論・em-dash禁止・3ダイヤルなどの強化ルールを持ちます。安定した従来挙動が必要なら、--skill "design-taste-frontend-v1" でv1を明示します。新規案件はまずv2で試すのがおすすめです。

React以外（Vue / Svelte）でも使えますか？

設計ルール自体はフレームワーク非依存です。スキルはReact/Tailwind/Motionを既定の実装スタックとして想定しますが、レイアウト・配色・書体・モーションの規律は、Vue・Svelteや素のHTML/CSSにも応用できます。本記事の検証も、単一HTMLファイルで実施しました。

既存のUIコンポーネントライブラリと何が違いますか？

コンポーネントライブラリは部品を提供しますが、TasteSkillは「判断」を提供します。中央寄せを避ける、Interを既定にしない、em-dashを禁じる、といった意思決定の規律です。2025年のStack Overflow調査で開発者の45.7%がAIの正確性を信頼しないと答えた背景には、こうした「判断の欠如」があり、TasteSkillはそこを補います（Stack Overflow, 2025 Developer Survey）。

まとめ

AIが作るUIの「あと一歩」は、コードの「あと一歩」と同じ根を持ちます。誘導しなければ、モデルは最も平均的な答えに落ち着くからです。TasteSkillは、設定ファイル数本でその既定値を上書きし、本記事の検証で見た通り、同じ指示のまま顔つきを変えました。次のビルドで、まずは npx skills add して、自分のプロジェクトでbefore/afterを撮ってみてください。違いは印象ではなく、数字で確かめられます。

出典

出典（取得日：2026-05-30）

• Stack Overflow, 2025 Developer Survey（AIセクション）, 2025年
• JetBrains, The State of Developer Ecosystem 2025, 2025年10月
• GitHub, Octoverse 2025, 2025年10月28日
• PBS NewsHour, Merriam-Webster’s word of the year for 2025 is AI’s ‘slop’, 2025年12月15日
• Leonxlnx/taste-skill, GitHub リポジトリおよび GitHub API メトリクス

最後に

グループ研究開発本部 次世代システム研究室では、最新のテクノロジーを調査・検証しながらインターネット上の高度なアプリケーション開発を行うエンジニア・アーキテクトを募集しています。募集職種一覧 からご応募をお待ちしています。