UIデザインSkill 4種を実測：同一モデルによる15回の生成と匿名ビジュアルレビュー
Kimi AgentSwarmでkimi-1021-previewを使い、固定バージョンのUIデザインSkill 4種とSkillなし対照群に、CommonShelfツールディレクトリをそれぞれ3回ずつ、合計15回生成させました。機能検証は13回合格、2回失敗で、いずれの失敗も対照群で発生しています。ビジュアル平均は順にOil UI 87.0、frontend-design 88.0、UI UX Pro Max 86.7、Impeccable 88.0、Skillなし84.3です。UIデザインSkillを選ぶ際、特にディレクトリの階層、モバイル操作、モーション、機能の安定性を重視するなら、本記事のデモと失敗の詳細を比較してください。結論は今回の課題とモデルに限られます。
重要なポイント
- 4つのSkillはいずれも生成前にバージョンを固定しました。各回とも新しいエージェントが新しいワークスペースで独立して生成し、一つの方向だけを納品しています。結果の弱い回を強い回で置き換えていません。
- 2回の機能失敗は、どちらもSkillなし対照群のToastの厳密なテキスト検証で発生しました。これだけで保存機能全体が使えなくなったと判断することはできません。
- Oil UI run-3は6/6の機能シナリオに合格しましたが、カードのアニメーションが透明な状態から繰り返し再生され、複数の状態画像がほぼ空白になりました。ビジュアルスコアは83で、この問題もすべて公開しています。
課題とバージョン：同じCommonShelfブリーフ
CommonShelfは、アカウント不要の個人用ツールディレクトリです。ブリーフでは固定の6件のツールデータを提供し、プレーンなHTML、CSS、JavaScriptで、検索、カテゴリーと保存状態のフィルター、ツールの保存、検証付きのツール提案、キーボードで操作できるFAQを実装するよう求めました。ページは、ユーザーが公式ツールのリンクを明示的に開く場合を除き、実行時に外部リクエストを送信しません。各エージェントは複数案を生成して選ぶのではなく、一つの方向だけを納品します。
各Skill条件では、指定されたSKILL.mdだけを1回読み込み、Skillなし条件ではSkillを読み込みません。バージョンは生成前に固定し、グローバルにインストールされた同名版や有料版で置き換えることはできません。ライセンスもバージョンと併せて記載します。
| 条件 | 固定バージョン | ライセンス |
|---|---|---|
| Oil UIオープンソース版 | 0.24.2（tag v0.24.2） | MIT |
| frontend-design | commit-dbd4588f9e1033efb41dad4bef2f7947c8993d44 | Apache-2.0 |
| UI UX Pro Max | 2.15.0（tag v2.15.0） | MIT |
| Impeccable | 4.7.0（tag skill-v4.7.0） | Apache-2.0 |
| Skillなし対照群 | 上流のSkillやバージョンなし | 上流ライセンスの提供なし |
方法：15回の独立した生成、機能とビジュアルの分離評価
すべての生成はKimi AgentSwarmで新しいエージェントが行い、モデルはkimi-1021-preview、thinking effortはmaxに設定しました。異なる条件は並列に実行できましたが、同じ条件内のrun-1、run-2、run-3は順番に進めています。毎回新しいワークスペースを使い、他の実行のページ、スクリーンショット、会話を読まず、結果の弱い回を置き換えることもしませんでした。スケジューリングと復旧は所要時間に影響するため、時間は比較していません。
生成後、独立したPlaywright 1.64.1の検証ランナーがChromiumで6種類のシナリオを確認しました。デスクトップの基準、モバイルの基準、インタラクションと永続化、コンテンツ利用不可、ストレージ利用不可、モーション低減で、ビューポートは1440×900と390×844です。検証結果を同じ版の生成へ修正として戻さず、ビジュアルスコアを機能結果の代わりに使うこともありませんでした。
ビジュアルレビューでは、条件の識別情報と生成過程を隠した15組の匿名資料を使い、実行ファイル、スクリーンショット、検証状態は残しました。各資料を1回ずつレビューし、6つの次元から各回の総合点を計算して、3回の算術平均を取ります。6項の配点は合計100で、追加の重み付けはなく、高得点のrunを選んでグループの代表にすることもありません。
| 評価次元 | 満点 |
|---|---|
| ビジュアル階層と可読性 | 20 |
| プロダクトとの適合性と独創性 | 20 |
| レスポンシブ対応 | 15 |
| インタラクションと状態フィードバック | 20 |
| アクセシビリティ | 15 |
| 細部とモーション | 10 |
結果の総表：各回のスコアと機能結果
15回の生成と15件の匿名ビジュアルレビューはすべて完了し、機能検証は13回合格、2回失敗でした。平均は3回の総合点を3で割って算出し、小数第1位まで表示しています。例えばUI UX Pro Maxは260/3、Skillなしは253/3です。公開JSONには、各回の6次元スコア、機能結果、素材のURLが保存されています。
| 条件 | run-1 | run-2 | run-3 | 3回の総合点 | 平均 | 機能受け入れ |
|---|---|---|---|---|---|---|
| Oil UIオープンソース版 | 88 · 合格 | 90 · 合格 | 83 · 合格 | 261/300 | 87.0 | 3/3 合格 |
| frontend-design | 87 · 合格 | 87 · 合格 | 90 · 合格 | 264/300 | 88.0 | 3/3 合格 |
| UI UX Pro Max | 86 · 合格 | 88 · 合格 | 86 · 合格 | 260/300 | 86.7 | 3/3 合格 |
| Impeccable | 88 · 合格 | 87 · 合格 | 89 · 合格 | 264/300 | 88.0 | 3/3 合格 |
| Skillなし対照群 | 83 · 失敗 | 86 · 合格 | 84 · 失敗 | 253/300 | 84.3 | 1/3 合格、2回失敗 |
Oil UIオープンソース版0.24.2：平均87.0、run-3の透明からの繰り返し再生は減点が必要
3回のビジュアルスコアは88、90、83で、機能検証はいずれも6/6でした。3版とも検索、フィルター、6件のツールをプロダクトの中心に置き、カードの情報順を保っています。保存すると文字、アイコンや形状、塗り、カウントが連動して変化します。結果なしではリセット、読み込み失敗では再試行ができ、フォームエラーには要約と項目ごとの復旧案内があります。
run-1では、モバイルの長いフォームでエラーが出た後、操作ボタンの行全体を見るためにスクロールが必要でした。一部の状態画像でも、後続カードがほぼ透明な入場フレームを捉えています。run-2は共通のインデックス線と保存タブがより一貫しましたが、420msの入場効果により、検索と提案更新のスクリーンショットが一時的に白く淡くなりました。小さな等幅の補助文字も、長いページを読みにくくしています。
run-3では、renderTools()がカードを再構築するたびに、opacity: 0から始まる180msのcard-inアニメーションが再生されました。検索画像には「1 tool」と表示されているのに結果カードが見えず、モバイル検索、保存後の更新、提案更新にもほぼ透明なカードが写っています。機能検証には合格しましたが、通常のフィルター操作で主要コンテンツが繰り返し隠れ、フィードバックが妨げられるため、ビジュアルスコアは83です。これらのフレームは、結果が永続的に失われたことを証明するものではありません。
frontend-design：平均88.0、一貫した作業引き出しの表現と繰り返される強調
3回のビジュアルスコアは87、87、90で、機能検証はいずれも6/6でした。run-1は、寒色のグレー、ラベル紙、手描きの棚線、ブックマーク、ツールごとのシンボルで「作業引き出し」の方向を作り、ツールの概要と利用場面を主役にしています。保存すると文字、ブックマークの塗り、背景色が連動して変わり、モバイルの最初のカードと無効なフォームの操作もすべて見えていました。
run-2も情報階層は明確ですが、ツールカードの6pxの上辺バー、カードの太い下線、フィルターと提案領域の左線が重なり、見た目が重くなりました。モバイルのエラーダイアログでは、キャンセルと保存が844pxの初期画面の外にあり、スクロールが必要です。run-3でも青い左線が繰り返され、ラベルとメタ情報が小さくなりました。平均はImpeccableと同じですが、画面と問題は異なります。
UI UX Pro Max 2.15.0：平均86.7、状態は完全だがモバイル密度と操作位置が減点要因
3回のビジュアルスコアは86、88、86で、機能検証はいずれも6/6でした。3版とも、6件のツールを名前、概要、利用場面、タグ、価格、プラットフォームで整理しています。保存すると、Save/Savedの文字、ブックマーク、カウント、Saved onlyの状態も連動して更新されます。読み込み失敗、ストレージの機能低下、フォームエラーのそれぞれに復旧経路があります。
run-2では、ツールカードの4pxの上部強調バーと、提案項目や仕様領域の左線が繰り返され、12pxのカテゴリー、番号、タグも多く、定型感が出ていました。run-3では、モバイルの最初のツールカードが約712pxから始まるため、高さ844pxのビューポートではカードの上部だけが見え、ページ全体の高さは約4695pxでした。デスクトップとモバイルの長いエラーフォームはどちらも、送信とキャンセルを探すためにスクロールが必要です。機能検証には合格しましたが、完了までの操作は十分に直接的ではありません。
Impeccable 4.7.0：平均88.0、実際の状態と結び付いたディレクトリの細部
3回のビジュアルスコアは88、87、89で、機能検証はいずれも6/6でした。run-1は、チケットのようなパーフォレーション、破線、ステッチマークで一貫した方向を作っています。run-3のCatalog registerは、検索、保存、フィルターに応じて線のスタイルが変わり、装飾と実際の状態が対応しています。保存のフィードバックには文字、マーク、塗り、枠線を組み合わせ、結果なしと読み込み失敗のどちらにも次の操作があります。
減点の中心は密度と小さな画面でのフローです。run-1では、同じ行のカードでコンテンツの長さが違うと、概要、タグ、メタ情報のベースラインがずれ、12pxのメタ情報も弱くなりました。run-2は高いヘッダーと複数層のフィルターにより、モバイルの初期画面に収まるツール操作が減り、ページ全体は3149pxに達しました。複数回のモバイルエラーダイアログでも、キャンセルと保存を表示するには追加のスクロールが必要です。
Skillなし対照群：平均84.3、完全なUIを作れる一方で2回の機能失敗も消せない
3回のビジュアルスコアは83、86、84でした。温かい紙の色、番号、インデックス線でも一貫したツールディレクトリを作れており、デスクトップの3カラムとモバイルの1カラムは概ね明確で、保存と結果なしの状態にも色以外のフィードバックが多く見られました。基盤モデル自体が完全なUIを作れるため、対照群をゼロ点とみなさず、具体的な違いを比較する必要があります。
run-1とrun-3はどちらも、interaction-and-persistenceシナリオのToastの厳密なテキスト検証で失敗しました。契約上の期待値はプレーンテキストの「Suggestion saved.」でしたが、実際のテキストには余分なチェックマークと空白が含まれていました。run-3のチェックマークはHTMLでaria-hiddenと指定されているため、この結果だけで、提案の保存や永続化がすべて機能していないと判断することはできません。ただし、事前に定めた契約では、両方ともfailedのままで、5/6のシナリオ合格です。失敗した検証より後の同じシナリオ内のステップは、検証済みとは数えていません。
補助文字は何度も小さすぎたり薄すぎたりしました。run-3では、局所的な色値の計算でツール番号とプレースホルダーのコントラストが不足し、モバイルエラーダイアログの下部操作は上端だけしか見えていませんでした。run-1では、紹介とフィルターがモバイルの初期画面の大部分を占めています。
付録｜Oil UI 0.24.2最適化候補の復測：1回の追加試験
この付録では、Oil UI 0.24.2を基盤とする独立最適化候補の1回の追加復測を記録します。環境は引き続きKimi AgentSwarm + kimi-1021-previewです。この候補は公式の新バージョンではなく、元の15回のサンプルに含まれず、元の結果を変更・置き換えるものでもありません。1回の試験で普遍的な改善を証明することはできません。
独立した機能検証は6/6、拡張した連続インタラクション検査は11個のチェックポイントを対象に2/2へ合格しました。2名の独立ブラインドレビュアーによるスコアは89点と90点で、平均は179/2 = 89.5です。レビュアーはPlaywrightを再実行せず、機能とビジュアルの証拠は分けて記録しています。直接的な証拠はChromiumの1440×900と390×844に限られ、実際のスマートフォン、すべてのブレークポイント、他のブラウザー、完全なアクセシビリティ監査は対象外です。
- DOMとモーション：連続操作と復元でカード群の再再生は見られなかった
- 11個の連続チェックポイントで、保持されたカードはすべてsameOriginalNode=trueと記録され、カード群を毎回再構築することはありませんでした。カードと提案のanimationstart記録は空で、2名のレビュアーも連続操作の録画を確認しています。保存ボタンだけの局所的なCSS Transitionは別に記録されており、リストの再再生には数えていません。再読み込みによる復元後も、6枚のカードと提案はcssAnimations=0、restoreAnimationStartsは空で、保存状態と提案内容が復元されました。
- モバイル操作とビジュアル階層
- 390×844のビューポートで4件のエラーがある状態でも、キャンセルと送信ボタンは高さ48px、下端819pxでビューポート内に収まっていました。どちらの操作も実際のタッチクリックで、修正後に送信した内容は再読み込み後も復元されました。2名のブラインドレビュアーは、ダイアログとエラー要約に太い上部強調バーがなく、エラーとダイアログの階層が明確であることを確認しています。
- 古いエラー、小さな文字、プレースホルダーのコントラストに残課題
- 項目を修正してから次に送信するまでは、古いエラー要約と項目ごとのエラーメッセージが表示されたままです。これは送信時に検証する契約には合致し、機能の失敗ではありませんが、フィードバックの即時性を損ないます。一部の補助文字は9–11pxのままです。レビュアーAが入力プレースホルダーを局所的に測定したコントラストは約3.76:1で、通常文字の参考値4.5:1を下回っています。これは局所的なスポットチェックであり、完全なコントラスト監査ではありません。
限界：この証拠から分かることと、分からないこと
今回の対象は、英語で書かれた1つの静的なCommonShelfブリーフ、1つのモデル、各条件3つの最終サンプルです。ビジュアルレビューには6次元の規準がありますが、それでも判断が含まれます。1回のレビューは1組の匿名資料に対応し、大規模なユーザー調査や統計的有意性の実験ではありません。課題、コンテンツの言語、フレームワーク、モデルが変われば、結果も変わる可能性があります。
機能検証は、事前に定めた6種類のChromiumシナリオに限られ、完全なプロダクト監査ではありません。通常のタブレットについてはスタイルシート上のブレークポイントの証拠だけで、専用のスクリーンショットはありません。Safari、Firefox、実際のタッチデバイス、スクリーンリーダー、200%ズーム、完全なWCAGチェックは実施していません。静止画像では連続するアニメーションのリズムを完全に表せません。Oil UI run-3の透明なフレームはフィードバックの問題を示しますが、アニメーション終了後に安定した画面の品質を説明するものではありません。
公開デモには生成後の実際のページと機能失敗を残しています。技術的な中断とプロトコル内の復旧は、候補の機能失敗として数えず、所要時間の比較にも使っていません。これらは生成後の独立した機能検証とは別の証拠です。
再現：まず証拠を確認し、自分の実行でも検証する
記事の内容は、15個のデモ、20枚の初期画像、results.jsonで直接確認できます。自分で再テストする場合は、同じブリーフ、固定バージョン、同じモデルを維持し、毎回新しいエージェントを使い、3回分の結果をすべて残した上で、生成後に独立した機能検証を行ってください。公開コンテンツデータは、デモで配信しているコピーとバイト単位で同一です。以下は簡略化した再テスト用ブリーフで、元の凍結タスクファイルそのものではありません。
オープンソースのインストールコマンドは、実行時に解決されるバージョンをインストールするため、必ずしも0.24.2にはなりません。厳密に比較するには、実際にインストールしたバージョンを記録し、表に記載した固定コミットを使用してください。新しいバージョンを使う場合は新たなテストとして扱い、今回の数字を上書きしないでください。
オープンソースのOil UIをインストールし、実際のバージョンを記録する
まず自分の課題でオープンソース版を試してください。今回のテストでOil UI Proは使用していません。
npx skills add oil-oil/oil-ui各条件で3回ずつ独立に生成する
モデルとコンテンツデータを固定し、毎回新しいエージェントとワークスペースから開始して、一つの方向だけを納品します。別の回のページを読み込んだり修正したりせず、結果の弱い回を置き換えないでください。
機能検証と匿名ビジュアルレビューを分ける
1440×900と390×844のページで6種類のシナリオを確認し、すべての合格・失敗を保持します。ビジュアルレビューでは条件の識別情報を隠し、同じ6次元の規準で採点し、平均だけでなく各回の結果を公開します。
Build one complete CommonShelf static web app with plain HTML, CSS and JavaScript. Use the supplied content.json unchanged. Make one coherent direction without asking for a selection. At 1440×900 and 390×844, the first viewport must help a visitor find, understand and save tools. Implement combined search, category and saved-only filters; local-storage saves; a validated suggestion dialog; exactly three keyboard-operable FAQ items; actionable content-unavailable and storage-unavailable states; visible focus; and reduced motion. Keep suggestions outside the curated tool grid. Make no external requests except user-activated official links. Do not import another run or replace a weak result. Preserve every failure, then independently verify the actual page and review anonymized screenshots and runtime files.これは同種の再テストを行うための簡略化したプロンプトです。厳密な再現には、本記事のバージョン固定、6種類の受け入れシナリオ、同じ採点規準も必要です。
実際に動くギャラリー作品とプロンプト
1440pxまたは390pxのライブデモを開き、モデルとプロンプトが最終的なUIにどう表れたかを確認できます。
Kiln
コンポーネントライブラリウェブサイト
製品：Kiln。React開発者向けのオープンソースコンポーネントライブラリ。ボタン、入力、ドロップダウン、コマンドパレット、ダイアログ、ツールチップ、テーブル、日付選択など、40以上のコンポーネントを備え、テーマのカスタマイズに対応する。 ウェブサイトのホームページを構築し、必要に応じてコンポーネント詳細ページも作る： - スクリーンショットではなく、実際に操作できるコンポーネントをホームページに直接表示する。「コンポーネントウォール」には、クリック、入力、切り替えができる動作中のコンポーネントを含める。 - 主要な開発者ツールウェブサイトの精密さと抑制を参考に、ほぼ白黒、アクセントカラーは多くても1色、厳密なグリッド、コードと数字には等幅書体を使う。 - テーマコントローラーを印象的にする。角丸、密度、アクセントカラーの操作をドラッグすると、ページ上のすべてのコンポーネントが即座に変わるようにする。 - コピー可能なインストールコマンド、コードスニペット、コンポーネントカテゴリー別のナビゲーション、GitHubスターや週間ダウンロード数などの現実的な使用数値を含め、過度にきりのよい数字は避ける。
作品とプロンプトを見る →
Dispatch
開発者向けAPIドキュメント
決済またはメッセージングAPI企業の開発者ドキュメントサイト（1440×900を基準とし、幅390までレスポンシブ対応）。左にナビゲーション、中央に記事、右に言語（cURL、Node、Python）を切り替えられるコードサンプルを配置する。クイックスタート、1つのエンドポイントの完全なリファレンス（パラメーター表、リクエスト・レスポンス例、エラーコード）、検索を含める。 読み進める間、コードサンプルは現在のセクションに追随し、選択した言語はサイト全体で記憶されるようにする。クイックスタートページ、エンドポイントのリファレンスページ、検索を開いた状態をデザインする。
作品とプロンプトを見る →
muse
AI画像・動画キャンバス
デザイナーとクリエイティブチーム向けのAI画像・動画生成ツール。すべてのプロンプト、参照画像、生成結果を一つの無限キャンバスに配置する。メインワークスペースを構築する。
作品とプロンプトを見る →
Forge
AIコーディングアシスタント
製品：Forge。デスクトップAIコーディングアシスタント。左側に会話、右側に編集中のコードとターミナルを配置する。ファイルの読み込み、コードの編集、テスト実行を段階的に見られる。 現実的なデータを使ってメインインターフェース（1440×900）を構築し、実際のプロジェクトに見えるファイル名、差分、テスト出力を用意する。 AIの作業を見えやすく、印象的にする。ステップが順に光り、差分行が徐々に現れ、テストが赤から緑へ変わるようにする。 危険な変更についてユーザーの確認を待っている状態も撮影する。
作品とプロンプトを見る →補足：Oil UI Proは今回の比較に参加していません
今回のOil UIのデータはすべてオープンソース版0.24.2によるもので、Proは生成、機能検証、採点のいずれにも関与していません。まずデモを開き、失敗を確認し、オープンソース版を再実行してください。自分のワークフローに、さらに踏み込んだ手法が必要だと確認してから、Proを別途検討してください。
npx github:oil-oil/oil-cli install oil-ui-proよくある質問
この比較だけで、どのSkillをインストールすべきか決められますか？
平均点だけで決めるべきではありません。ディレクトリの階層、モバイル操作、モーション、機能失敗、ソースのライセンスで候補を絞り、該当するデモを開いて、自分の要件に合うかを確認してください。
Oil UI run-3は機能にすべて合格したのに、なぜビジュアルは83点なのですか？
機能検証では、定められた動作が機能することを確認しますが、ビジュアルレビューではフィードバックの明確さも評価します。この回ではカードを再構築するたびに透明からのアニメーションが再生され、検索、保存、提案更新の画像で結果領域が何度もほぼ空白になりました。実際に見えるフィードバックの問題なので83点としていますが、カードが永続的に失われることを証明するものではありません。
Skillなしの2回の失敗は、保存がまったく使えないことを意味しますか？
いいえ。2回とも、実際のToastテキストに余分なチェックマークと空白が含まれ、厳密なテキスト検証に合格しませんでした。これだけで保存や永続化がすべて機能していないと判断することはできませんが、事前に定めた契約を満たしていないため、failedと5/6を保持しています。
記事の数字と画面をどう確認すればよいですか？
まずresults.jsonをダウンロードし、各回の6次元スコア、総合点、機能結果を確認してください。次に、各候補の3枚のデスクトップ初期画像、1枚のモバイル初期画像、3つの実際のデモを開きます。モバイル画像はすべてrun-1を使用し、高得点のrunを選び直したり、フォームのスクリーンショットをメインビジュアルに使ったりしていません。