AIで見栄えのいいSaaS画面を作るデザインスキルを工程ごとに使い分ける

SaaSのダッシュボードは、利用者が状態を把握し、異常を見つけ、次の操作を決めるための確認画面です。売上、利用状況、未処理件数をカードへ並べるだけでは、数字を見た後に何をすべきかが分かりません。誰が、どの頻度で、どの判断をするのかを決めてから、比較期間、更新時刻、責任者、絞り込み、詳細への導線を置く必要があります。

144件のダッシュボードを調べた研究でも、画面には分析型、物語型、埋め込み型などの型があり、画面面積、操作、表示情報の両立を目的に応じて設計する必要があると整理されています。9 一方でAIエージェント向けのデザインスキルの多くが主目的にするのは、平均的な見た目からの脱出です。Anthropicのfrontend-designとImpeccableは、用途、利用者、トーン、制約、記憶に残る差を実装前に定めさせます。23 見た目の方向づけと、確認画面としての正しさは別の工程です。この二つがどう分かれるかを、まず実際の生成結果で確かめます。

結論を先に見せます。上の画像は、五段階の工程で作った「朝の確認画面」です。カスタマーサクセス管理SaaSを題材に、顧客10社分の固定データを用意し、健康度50未満の4社を対応キューとして上へ、残り6社を表へ置きました。各行の帯は現在の健康度と8週間の推移を一体化した表示で、担当者のいない顧客には割り当て操作、全顧客に「対応を記録」ボタンがあります。

実験の条件をそろえるため、次を固定しました。データは51文字の長い社名、担当者未割り当て2社、45日間未ログイン、30日以内の契約更新2社を含む10社分のJSONです。依頼文は「モダンなSaaSダッシュボードを作ってください。データはdata.jsonの顧客データを使ってください」の一文で、単一の自己完結HTML、外部ライブラリ禁止、日本語UIだけを制約にしました。比較するスキルは、導入数や星数で名前の挙がる公開スキルのうち、2026年8月24日にGitHubで実在と原文を確認できたものから選びました。星8万件超のTasteは、原文の冒頭が「ダッシュボード、データテーブル、複雑な製品UIは対象外」と宣言しているため、対象外宣言そのものを結果として記録し、生成には使っていません。

スキルを使う6本は、Claude Code(Fable 5)のサブエージェントへ毎回まっさらな状態で同じ依頼を渡し、読ませるSKILL.mdだけを差し替えました。Impeccableは本体の指示どおり参照ファイル3枚を追加で読み、生成中に自前の画面検査まで実施したため所要時間が最長です。interface-designとui-ux-pro-maxはGitHubのSKILL.md本文だけを渡したため、ui-ux-pro-maxは同梱の検索データベースなしのフォールバック動作になっています。筆者のCは「判断の一文を決める、視覚方向を決める、情報設計を決める、実装する、実画面を検証する」の順で作りました。Cの機能は七つの中で最も少なく、行数も最少です。判断の一文を「責任者が毎朝10分で、リスクの高い順に確認し、担当のいない顧客へ担当を割り当て、対応を記録する」と先に決めたため、検索、並べ替え、ナビゲーションを全部落とし、割り当てと記録の操作だけを残せました。

七通りに共通する結果が一つあります。データに「リスク顧客」の定義を入れなかったところ、AIが作った6本すべてが健康度50未満を危険の閾値として自分で決め、スキルを読ませた4本は50未満・50〜69・70以上の同じ三段階を画面の脚注へ明記していました。各エージェントは完了報告でも「閾値はデータに定義がないため自分で決めた」と申告しています。どのスキルを使っても、業務の定義を渡さなければAIが同じ既定値で埋めるという点は、この後の議論の前提になります。

今のモデルのAIらしさは、紫のグラデーションや崩れたレイアウトには現れません。スキルなしの画面は、濃紺のサイドバーに角丸の「CS」ロゴ、白いカード、青のアクセント、KPIカードの横並び、健康度バーとスパークライン付きの顧客テーブル、右側の要対応アラートという、破綻のない、そして誰がどのSaaSを頼んでも返ってくる構図でした。「平均ヘルススコア59」のように見ても次の行動が決まらない指標も入っています。この既定の構図からの距離が、上の比較画像で分かるスキルの効き目です。

スキルはそれぞれ別の方向へ画面を動かしました。frontend-designは契約更新までの残り日数を軸に取る散布図「更新ランウェイ」を主役にした独自構図です。emil-design-engは装飾を抑えた明るいグレー基調で、入場の動きを初回表示の一度だけに限定し、毎朝何度も押す絞り込みは動き無しの即時反映にするという、頻度で動きを決める規則が画面へそのまま出ました。Impeccableは「大きな数字と小さなラベルを並べるKPIタイル格子」を同梱の品質規則が禁じているため、要約をやめて「今日の対応」キューへ推奨アクションの文章を添え、総MRRを危険・注意・良好の帯で分解した「63.5%が危険域」という一文を主役にしています。interface-designは「夜の港と灯台」という世界観を先に決め、色トークンへ港や灯火の名を付けたダークUIで、画面で唯一の面的アクセントを危険MRRのセルへ置きました。ui-ux-pro-maxは6枚のKPIと優先対応リストを持つ青系の標準的な管理画面で、44pxの操作領域、コントラスト比、読み上げ属性といったアクセシビリティ既定を最も丁寧に実装しています。

変わった点はもう一つあります。4本とも並べ替えと絞り込みが実際に動き、押しても何も起きない飾りのボタンをほぼ置きませんでした。frontend-design単独の生成では「押しても動かないボタン」の自己申告があったので、操作の実装度はスキルの規則で引き上げられています。一方で変わらなかった点が本題です。リスクの閾値は4本とも同じ50を自分で決め、担当者のいない顧客へ担当を割り当てる操作は、七つのうち工程で作ったCにしかありません。ダークUIや散布図には軸や配色の読み方という学習コストも残ります。見た目の方向づけを作るスキルは、業務の判断と操作の完了条件までは面倒を見ません。ここが方向づけと情報設計を別工程に分ける理由です。

公開されているデザインスキルは、得意な工程が異なります。導入数やGitHubの星だけで順位を付けると、最初の画面を作るスキルと、完成後の不具合を探すスキルを同じ物差しで比べることになります。

Anthropic frontend-design

Anthropicのfrontend-designは、短いSKILL.mdで強い方向を与える入口です。用途、トーン、技術制約、差別化をコードより前に決め、AI生成に頻出する既定の見た目を名指しで避けさせ、大胆さは署名要素の一点に集中させます。2 実験で確認したとおり、既定の管理画面の構図から離れる効果は確実に現れます。日常的に使う製品画面では、この大胆さが情報密度や毎朝の操作と衝突しないかを、次の情報設計の工程で確かめる必要があります。

Impeccable

Impeccableは、単発の生成指示を、製品文脈が残る設計運用へ広げたスキルです。PRODUCT.mdへ利用者、目的、製品の約束を置き、DESIGN.mdへ色、文字、部品、視覚規則を残したうえで、新規制作、批評、監査、磨き込み、情報の削減、堅牢化、端末対応を別のコマンドとして扱います。34 SaaSで効くのは、画面をOperate、つまり利用者が仕事を完了する面として扱う判断です。既存製品で色や部品が定まっている場合は、先に現在の設計を文書化してから修正することで、ページごとに別の雰囲気になる問題を抑えます。

interface-designとui-ux-pro-max

interface-designは、ダッシュボード、管理画面、設定、データ画面へ範囲を限定した設計技能です。読んでみると規則はかなり具体的で、一画面に焦点を一つだけ置く、文字サイズではなく太さと不透明度で階層を作る、表示待ち、空、エラーを含む状態を省かない、動きは変形と不透明度だけに限る、といった判断を、実装時の確認手順として要求します。5 生成の独自性より、細部が同時に正しいことを競争力と定義している点で、frontend-designと補完関係にあります。

ui-ux-pro-maxは、79種の様式、119件のUX指針、25種の図表型などを収めた検索可能なデータベースをスキルとして配る構成です。付属の検索スクリプトへ製品種別を渡すと配色、書体、避けるべき型を返し、余白の密度をダッシュボード向けの詰まった設定へ切り替える指定もあります。6 日本語圏でもfrontend-designとの併用例が公開されています。15 知識の検索は速い一方、返ってくるのは一般的な推奨であり、どの指標で何を判断するかは依頼側が決める必要があります。

Emil Kowalskiのデザイン技能

Emil Kowalskiの公開リポジトリは、VercelとLinearでの経験をもとに、動きと細部の判断を複数のスキルへ分けています。中心のemil-design-engに加え、既存アニメーションの批評、改善候補の探索、動かすべき場所の発見などがあります。2026年8月24日の確認時点で、GitHubでは3万件を超える星を集めていました。7

実務で価値があるのは、何でも動かす指示ではありません。毎日100回以上使う操作は動かさず、たまに開くモーダルや通知だけ標準的に動かすという頻度からの判断と、入る要素は速く反応してゆっくり止まる曲線、押下は軽い縮小で応えるという具体値です。7 実験のCでもこの基準を使い、入場アニメーションを全て外して、ホバー、押下、状態変化だけへ動きを絞りました。

実ブラウザーで見る視覚QA

frontend-visual-qaは、完成した画面を実ブラウザーで開き、構成、文字、余白、折返し、切れ、端末幅、状態遷移を調べる検査用スキルです。ビルドの成功、DOM上の存在、撮っただけで見ていない画面画像を、視覚的な証拠とは扱いません。8 後述する実行記録のとおり、今回の実験でもこの工程だけが4件の実不具合を見つけました。表示の検査が合格しても、指標名が伝わるか、次の操作が分かるかという意味の検査は別に残ります。

知能圏の作業環境には、Impeccable、emil-design-eng、動きの実装用animate、アニメーション批評用review-animationsが導入済みでした。2026年8月24日に各SKILL.mdと同梱ファイルを読み、役割と規則の粒度を確認しました。interface-designとui-ux-pro-max、そして星数で最上位級のTaste(taste-skill)はGitHub上の原文を読んでいます。16 Tasteは本体だけで1206行ありますが、冒頭でランディングページ、ポートフォリオ、再設計に範囲を絞り、ダッシュボードを名指しで対象外にしていました。

Impeccableは巨大な文章を毎回読み込むのではなく、入口で作業を振り分けて必要な参照だけを開く構造でした。OpenAIの公式文書でも、スキルはSKILL.mdに名前、発動条件、手順を置き、必要に応じて参照、スクリプト、ひな型、素材を同梱できると説明されています。1 Anthropicも長い参照資料は必要時だけ読み、SKILL.md本体を短く保つよう案内しています。11

出典の実在確認も実査の一部です。この記事の初稿では、判断中心の設計規則を含むとされるui-ux-designという公開スキルを候補に挙げていましたが、公開前の照合でGitHubのリポジトリごと404になっており、実在を確認できませんでした。該当の記述を落とし、実在を確認して原文を読んだui-ux-pro-maxへ差し替えています。スキル名だけが紹介記事から紹介記事へ伝言される状況では、原文へ戻る確認を省けません。

ここからは筆者の見立てです。デザインスキルの質は、規則の多さだけでなく、いつ何を読むか、実画面をどう確かめるか、失敗をどの成果物へ戻すかで決まります。長い美学の文章だけを追加しても、利用者の仕事、実データ、端末幅、状態、検証手順がなければ再現性は上がりません。

筆者の版Cは五つの工程を順番に通しました。各工程の成果物と所要時間、見つかった問題をそのまま残します。

1. 判断の一文を決めます。「カスタマーサクセス責任者が毎朝10分で、解約リスクの高い顧客から順に確認し、担当者のいない顧客へ担当を割り当て、対応を記録する。デスクトップ中心、スマートフォンでは確認だけできればよい」としました。ここで完了条件に「割り当て」と「記録」の操作が入ったことが、画面から検索やナビゲーションを削る根拠になりました。
2. frontend-designの手順で視覚方向を決めます。世界観は毎朝の当直、色は地と面の明るいグレーに墨色の文字、危険、注意、良好、操作の4色だけを意味へ割り当て、署名要素は健康度の現在値と8週間の推移を段階色で一体化した帯としました。避ける既定値も先に書き出しました。
3. 情報設計を決めます。interface-designの焦点を一つに絞る規則とダッシュボード設計研究の型を参照し、危険域4社を対応キューとして上へ、残り6社を表へ、サマリーは「危険域の顧客数と対象収益」「担当者がいない顧客」「30日以内の契約更新」の3枚だけにしました。各行には理由と次の操作を並置し、危険域ゼロの空状態、長い社名の折返し、担当未割り当ての強調を先に決めました。
4. 実装します。動きはemil-design-engの頻度基準で、入場アニメーションなし、ホバー120ミリ秒、押下は3%の縮小、状態変化150ミリ秒だけにし、視差や演出は入れませんでした。設計メモと実装で約20分です。
5. ヘッドレスChromeで1480px、800px、390pxの画面画像を撮り、目視で検査します。往復3回で4件の不具合を見つけ、すべて修正しました。

見つかった4件は、8週間差分の「-8 / 8週」が途中で折り返す、備考と自動生成の理由文が「未解決の問い合わせ7件」を二重に表示する、幅800pxでデスクトップ用の格子がはみ出して操作ボタンが画面外へ消える、幅390pxで2列の格子が最小幅を超える、というものです。上の画像は3件目の修正前後です。設計と実装をどれだけ丁寧に進めても、この種の問題はレンダリング後にしか現れませんでした。

検査の道具にも落とし穴がありました。ヘッドレスChromeはウィンドウの最小幅が500pxのため、390pxを指定した最初の撮影は「500pxで組んだ画面を390px幅に切り抜いた」偽の画像になっており、存在しないはみ出しを疑って時間を使いました。500pxの窓の中へ390px幅のiframeを置く撮影用HTMLを作って解決しています。撮っただけの画像を証拠と扱わないというfrontend-visual-qaの注意は、撮影方法自体にも当てはまります。QAと修正、撮影環境の調査を合わせて約25分でした。

X上では、スキルを専門知識の再利用単位として評価する投稿と、増えすぎたスキルの重複や陳腐化を警戒する投稿が並んでいます。Kaxil Naikは、制作、レビュー、ブラウザーでの一連の操作、画面画像や録画までを技能と道具の組み合わせにし、決定的な出力にはスクリプトとフックを使う運用を紹介しました。12 デザイン分野でも、指示文だけでなく、画面を開いて確認し、失敗を規則へ戻す流れが重要だと読めます。

Simon Smithは、Skills.shに8万5千件を超えるスキルがある状況で、組織内の重複、整理、更新が新しい負債になると指摘しています。13 数字は投稿者による当時の観測ですが、同種のfrontend-designを何本も入れ、どれが発動したか分からない状態への警告として妥当です。実在しないスキル名が紹介記事を巡回する今回の経験も、この規模の副作用と読めます。Aaron Levieも、AIによって専門性が不要になるのではなく、専門家がエージェントを正しく方向づける力の倍率が上がると述べています。14

研究からも、スキルを入れれば自動的に成績が上がるとは限りません。SWE-Skills-Benchは49件の公開ソフトウェア技能を実際のリポジトリ課題へ適用し、39件で合格率の改善がなく、平均改善も1.2ポイントだったと報告しました。10 対象はデザイン専用評価ではありませんが、人気、長さ、名前だけで採用せず、自分の画面と完了条件で比較する必要を示します。今回の実験でも、スキルなしの生成は十分に整った画面を出しており、スキルの価値は壊れた出力を直すことにはありません。既定の構図から画面を引き離し、動きや品質の下限のような決めていなかった規則を先に与えるところに現れました。そして星数最上位級のTasteがダッシュボードを対象外と宣言しているように、人気順とその画面への適合は別の話です。

新規のSaaSダッシュボードなら、interface-designを主担当にし、Anthropicのfrontend-designを視覚方向の補助へ置く構成が小さく始められます。既存製品を継続して改善するなら、ImpeccableでPRODUCT.mdとDESIGN.mdを作り、批評、磨き込み、堅牢化を同じ文脈で回す方が向いています。Emil Kowalskiの技能は動きと細部、視覚QAは実装後の検査に限定すると責任が重なりません。ui-ux-pro-maxは迷ったときの検索辞書として補助に置けます。

ただし今回の実測では、スキルより先に効いた要素が二つあります。一つは判断の一文で、これがないとリスクの閾値も優先順位もAIが埋めます。実際、スキルを読ませた4本はすべて同じ閾値50を自分で決めていました。もう一つは実画面の検証で、五段階のうち不具合を実際に見つけたのはこの工程だけでした。スキルを増やす前に、一つのダッシュボードで「判断の一文、方向づけ、情報設計、実装、検証」を一度通し、どの工程の品質が上がったかを記録するところから始めるのが安全です。比べるときは、同じ画面、同じデータ、同じ成功条件で一つの構成だけを変え、最重要の異常を見つけるまでの時間、次の操作の発見、横はみ出しや未定義状態の件数で判断すると、採用理由を説明できます。