MonoKelvin/mono-ui-prototype

高品質 UI プロトタイプデザイン

一、コア目標

全ては、見た目が良く、且つ使いやすい製品インターフェースを作るために。

成果物は、熟練したデザイナーが手掛けた実際の製品のように見えるべきであり、テンプレートを適用したり、カードを積み重ねたり、配色を変えただけの普通のプロトタイプであってはなりません。全体的な雰囲気、視覚的階層、フォントの表現、構成、色彩関係、グラフィック言語、動き、細部の完成度に重点を置きます。

• 美的感覚を優先するが、ユーザビリティを犠牲にしない: ビジュアルと機能を共にデザインし、機能を削減して表面的なシンプルさを得ることはしません。
• スタイルは製品が決める: 抑制的、洗練された、活発な、先進的、華やか、実験的なものなど、様々な表現を許容し、「高級ミニマル」を唯一の答えとはしません。
• 大胆かつ自律的にデザインする: ユーザーが色、フォント、レイアウト、アニメーションパラメータを提供するのを待ってはいけません。要件を理解した後、積極的により良い解決策を探求してください。
• テンプレート感を拒否する: 一般的なSaaSレイアウト、固定配色、統一されたカード、画一的なコンポーネントの組み合わせをデフォルトで使用しません。
• 独立して導出する: 同じカテゴリの製品であっても、その内容とポジショニングに応じて独自の表現を形成し、前回のビジュアル方案を機械的に再利用してはいけません。

デザイン原則の参考

デザインの判断には、以下の確立された原則を参考にできますが、その例をそのままコピーしたり、固定パラメータに変換したりしないでください。

• 視覚的階層、比率、バランス、コントラスト、ゲシュタルト、視覚的な焦点。
• グリッド、構図、リズム、余白、統一性、ブランドアイデンティティ。
• 一貫性、発見可能性、プログレッシブディスクロージャー、フィードバック、アクセシビリティ。
• フォントの個性、字形の品質、読みやすさのシナリオ、フォントの組み合わせ。
• 動きの連続性、自然な加速減速、空間的関係、インタラクションフィードバック。

参考: NNGroup 視覚デザイン原則 · Figma UI デザイン原則 · IBM Design Language · Apple HIG Motion

既存ページを再利用しない

• 新しいページでは、ui/ 配下の既存ページを読み込まず、スクリーンショットを取らず、分析せず、そのHTML/CSS/JSを起点としてコピーしません。
• 前回の色、フォント、レイアウトの骨格、コンポーネントの組み合わせ、動きのパラメータを再利用しません。デザインの違いは、単に色やテキスト、画像を変えるだけでは不十分で、情報構造と視覚表現を再考する必要があります。
• このスキル、skills/ui-metadata/SKILL.md、tools/ の使用方法、およびユーザーが今回提供した参考情報のみを読み取ることが許可されています。
• ユーザーが既存ページの修正を明確に要求した場合のみ、該当ページを読み取ります。

二、製品を理解してからデザインを決める

まず製品のポジショニング、ターゲットユーザー、利用シーン、コンテンツの特性、ブランドの雰囲気を判断し、それからビジュアルの方向性を決定します。以下の分類をテンプレートとして扱わないでください。これらはあくまでデザインの考え方の出発点です。

製品の雰囲気	探求可能なデザイン表現
国際的 / 英語ブランド	簡潔なコピー、表現力豊かなフォント、大規模なタイポグラフィ、字間と余白、写真とシンボル
トレンド / クリエイティブ / 若者向け	大胆な構図、強いフォントの個性、アイコンシンボル、幾何学図形、視覚的な数字、柔軟な色彩関係
プロフェッショナルツール / デスクトップソフトウェア	明確な情報整理、洗練されたフォント、快適な情報密度、繊細な状態フィードバック、控えめな色彩
テクノロジー / AI / データ製品	モダンなフォント、データ可視化、構造的なグラフィック、動的なフィードバック、認識しやすいテクノロジービジュアル
カルチャー / アート / コンテンツブランド	エディトリアルなタイポグラフィ、セリフ体または特徴的なフォント、写真、マテリアル感、余白、感情豊かな色彩
高級消費 / ライフスタイル	洗練されたフォント、プロダクトイメージ、マテリアルとライティング、ディテールの質感、控えめだが印象的なブランド表現

異なる方向性を組み合わせたり、現在の製品により適した独自の方向性を提案することも可能です。特定のスタイル名を機械的に適用しないでください。

成果物のコンテナ

タイプ	判断基準	外枠とスクロール	キャンバス境界
A ソフトウェア	バックエンド、ツール、ダッシュボード	完全なウィンドウ表示；長いリストや長文は部分的にスクロール	ウィンドウ内に固定、オーバーレイははみ出さない
B ウェブページ	ブランド、ランディング、コンテンツサイト、ポートフォリオ	自然なドキュメントフロー；ページ全体を垂直スクロール	ビューポート = キャンバス、境界制限なし
C アプリ	モバイルファースト、指定されたアプリ/スマホ/ミニプログラム	スマホ比率の外枠；枠内のみスクロール	スマホ枠内に固定
D コンポーネント	プレイヤー、ライトボックス、アップロード領域などの単一コントロール	コンテンツの自然なサイズで表示；内部は部分的にスクロール	コンポーネント枠内に固定

ユーザーが明示した場合はその要求に従い、明示しない場合は機能から推測します。コンテナは表示方法を決定するだけで、ビジュアルスタイルを制限するものではありません。

コンテナデザインの要点

A ソフトウェア

• ウィンドウ、背景、コンテンツが完全な表示関係を形成するようにします。外枠は製品に奉仕するものであり、浮遊効果のために余分な装飾を追加しないでください。
• 主要な情報とよく使う操作が自然に共存できることを優先します。複雑なコンテンツは適切な区分と局所的なスクロールで対応します。
• 最初にスペースの割り当てとレスポンシブレイアウトを適切に行い、その後スクロール領域を決定します。レイアウトの問題を隠すために、トリミング、スクロールバーの非表示、全体のスケーリングに頼らないでください。
• 狭い画面では、情報の再配置、グループ化、表示調整を優先し、コア機能を消してはいけません。
• ソフトウェアの幅はウィンドウ全体の85%以下、高さは90%以下とし、周囲に間隔を空けて中央に表示します。

B ウェブページ

• コンテンツに応じて、長いページのナラティブ、モジュール式ブラウジング、没入感のあるファーストビュー、またはその他の適切な構造を選択します。
• ページは視覚的なリズムとコンテンツの階層を持つべきであり、各ブロックが同じレイアウトを繰り返さないようにします。
• ナラティブのニーズに応じて、スクロール駆動のアニメーションを追加できます。ルールを満たすためだけに無理にスクロール効果を追加しないでください。

C アプリ

• モバイルデバイスの習慣に合ったナビゲーション、シングルカラムまたはシナリオに適したレイアウト、操作しやすいコントロールを採用します。
• ネイティブコントロールに必要なビジュアルカスタマイズを施しますが、アクセシビリティと操作体験を損なってはいけません。
• タッチ領域、ボトムナビゲーション、コンテンツのスクロールは、実際のモバイル端末の使用習慣に適合させる必要があります。
• iPhoneの画面サイズでデザインすることを推奨します（Dynamic Island、前面カメラコンポーネントは作成しなくても可）。

D コンポーネント

• コンポーネントの用途とコンテンツに応じて自然に形成し、完全なソフトウェアの外殻を適用しません。
• アイドル、ホバー、フォーカス、ローディング、完了、エラーなどの状態を重点的にデザインします。すべての状態変化は明確で、一貫性があり、理解可能である必要があります。

上記4タイプのオーバーレイの境界については、次のセクションで統一します。

コンテナ境界：インターフェースをキャンバス内に閉じ込める（ソフトウェア / アプリ / コンポーネントは強制）

これはハードな制約であり、スタイルの好みではありません。 ウェブページの境界はブラウザのビューポートですが、ソフトウェア、アプリ、コンポーネントには独自の境界があります。キャンバスの外側は「ステージ」（観客席の背景）のみです。ダイアログ、ドロワー、オーバーレイ、ガウシアンブラーがキャンバスの外側にはみ出すと、インターフェースは「ソフトウェア」から「ウェブページのスクリーンショット」に退化します。これは、この種のプロトタイプで最もよく見られる欠点です。

三層構造

製品本体は canvas 内に配置し、stage は中央揃えと背景のみを担当し、製品に関わる意味は一切 stage に配置しません。

body > .stage          ステージ：中央揃え + 背景、製品コンテンツは含まない
       └ .canvas      キャンバス：製品のインターフェース境界
          ├ 製品コンテンツ（タイトルバー / メインエリア / サイドバー…）
          └ .layer     オーバーレイグループ：ダイアログ、ドロワー、ドロップダウン、トースト
              ├ .scrim  オーバーレイ：暗転 + ブラー
              └ .dialog ダイアログ本体

主要なプロパティ（疑似コード）：

.canvas {
  position: relative;    /* オーバーレイの位置基準 */
  contain: paint;        /* クリッピング + fixed 子要素をキャンバスにアンカー、必須 */
  overflow: hidden;      /* はみ出したコンテンツは全てカット */
  isolation: isolate;    /* スタッキングと背景サンプリングをキャンバス内に分離 */
  container-type: size;  /* オプション：内部で cqw/cqh を使用可能 */
  width: min(1440px, 100%);
  height: min(900px, calc(100svh - 2 * var(--stage-pad))); /* container-type を使用する場合は明示的な幅と高さが必要 */
}

.layer  { position: absolute; inset: 0; }              /* キャンバスを基準、fixed は絶対に使用しない */
.scrim  { position: absolute; inset: 0;               /* サイズ = キャンバスサイズ → ブラー範囲は厳密にキャンバス内 */
          background: rgb(8 10 14 / .45); backdrop-filter: blur(10px); }
.dialog { position: relative; width: min(720px, 78cqw); max-height: 82cqh;
          display: flex; flex-direction: column; }
.dialog-body { flex: 1; min-height: 0; overflow: auto; }  /* コンテンツ領域のみスクロール */

contain: paint を明示的に記述する理由

実測（Edge、1400×1200）：overflow: hidden のみの場合、キャンバス内の position: fixed 要素は依然としてブラウザのビューポートを基準に配置され、はみ出します。contain: paint（または transform / filter / will-change: transform / contain: layout）を追加して初めて、fixed 要素がキャンバスにアンカーされ、クリッピングされます。container-type: size 単体では効果がなく、contain: paint と共存させる必要があります。cqw/cqh が不要な場合は container-type を削除しても構いません。

禁止事項

• キャンバス内でオーバーレイの配置に position: fixed を使用すること（基準がビューポートであり、本質的にはみ出す）。
• キャンバス内の要素のサイズ指定に vw / vh / dvh を使用すること（ビューポート単位は必ずキャンバスをはみ出す）。
• オーバーレイ、ブラー、シャドウを body、.stage、またはキャンバス外の要素に適用すること。
• transform: scale() でキャンバス全体を拡大縮小して画面に「収める」こと（テキスト、ブラー、シャドウが全てぼやける）。正しい方法は、min() でサイズを指定し、内部で適応させることです。
• キャンバス外のステージに製品に関わるコンテンツ（説明文、ボタン、装飾グラフィック）を表示すること。

ダイアログサイズ仕様（ソフトウェアは強制）

デフォルトは横長：幅 > 高さ。 ソフトウェアのダイアログは、ワイド画面デザインを優先する必要があります。

コンテンツ量	比率の方向	推奨サイズ（キャンバス比）	説明
多い（テーブル、チャート、長いフォーム、エディタ）	幅 > 高さ、16:9 または 4:3	幅 60%–80% キャンバス幅、高さはキャンバス高の 75% 以下	コンテンツが多い場合は 16:9 を優先、次に 4:3；横並びが必要な場合にのみ横方向のスペースを有効活用
中程度（設定パネル、多フィールドフォーム）	幅 > 高さ	幅 480–640px、高さ 320–420px	横方向を維持するが、全面にはしない
少ない（確認、単一フィールド、プロンプト）	正方形に近くても可	幅 320–420px、高さ 220–320px	縦長も合理的。比率のために無理に広げない
縦長リスト（長いリスト、ツリー、セレクタ）	高さ > 幅	幅 320–400px、高さ 60%–80% キャンバス高	縦長は許可される例外：単一リストは自然と縦長になる
ワークスペース（スケジュール、カンバン、全画面編集）	キャンバス全面に近い	キャンバス内に 16–24px のマージン	それでも fixed ではなく、キャンバス内に収まる

判定順序：まず「コンテンツは横並びが必要か？」を問う。横並びが必要、または横方向の読みやすさが求められる場合（テーブル、チャート、コード、タイムライン）→ 横方向；単一リスト / ツリー構造 / ステップフォーム → 縦方向でも可。

実装方法：aspect-ratio で比率を指定、max-height で上限を設定、幅は cqw、高さは cqh を使用します。

.dialog--wide   { width: min(72cqw, 860px); aspect-ratio: 16 / 9; max-height: 78cqh; }  /* コンテンツ多い */
.dialog--panel  { width: min(56cqw, 680px); aspect-ratio: 4 / 3;  max-height: 78cqh; }  /* コンテンツ多い・コンパクト */
.dialog--compact{ width: min(32cqw, 380px); aspect-ratio: 5 / 4; }                        /* コンテンツ少ない */
.dialog--tall   { width: min(30cqw, 360px); height: min(72cqh, 620px); }                   /* 単一縦長リスト */

コンテンツが非常に高い場合、max-height が適用され、比率が崩れることがあります。これは意図的です。比率が多少変わっても、コンテンツがキャンバスからはみ出すよりはましです。

その他の制約：

• ダイアログはキャンバス内で中央揃えにし、周囲の余白は 24px 以上確保します。端に寄せたり、キャンバスからはみ出したりしないでください。
• コンテンツが超過した場合は、.dialog-body のみをスクロールさせ、ヘッダーとフッターは固定します。
• 暗転オーバーレイは rgb(0 0 0 / .35) 〜 rgb(0 0 0 / .5)、ブラーは 8–16px とします。作用範囲は厳密にキャンバス内とします。
• 同じソフトウェア内でダイアログがグループとして出現する場合、サイズは体系的である必要があります（同じ種類は同じサイズ）。16:9 のものと細長いものを混在させないでください。

三、デザインプロセス

着手する前に skills/ui-metadata/SKILL.md を読み、その仕様に従ってページディレクトリに metadata.json を書き込みます。

0. 画像入力の出典宣言（imageToUI）

ユーザーが「1枚または複数の画像」を生成の入力として使用する場合（「画像を見てUIを作成」「画像から再現」「AIが画像を認識して一対一で再現」など）、metadata.json に imageToUI フィールドを書き込み、その画像の出典を記録する必要があります。これにより、ギャラリーカードが元の参照画像を遡って表示し、クリックして確認できるようになります。処理方法は入力タイプによって異なります。

• 入力が画像URLの場合（http://、https://、または // で始まるリンク）：そのリンクをそのまま imageToUI に書き込みます。例："imageToUI": "https://dribbble.com/shots/15820088-Furniture-Board-Desktop-concept"。ギャラリーは画像アイコンをレンダリングし、クリックすると新しいタブでその出典を開きます。

• 入力が base64 エンコードまたはローカル画像パスの場合：AI はまずユーザーに以下の二択を尋ねなければならず、静かに処理してはいけません。

  1. その画像のソースリンク先アドレスを提供する（Dribbble/Behance/デザインファイルリンクなど、公開されている出典のある参照画像に推奨）。または
  2. AI がその画像を ui/<slug>/assets/ ディレクトリにコピーして出典としてアーカイブすることを許可する（強く推奨 — 出典がトレース可能で、オフラインでも閲覧でき、プロトタイプと一緒に公開できることを保証）。その後、imageToUI を相対パス（例："./assets/source-<slug>.png"）で書き込みます。

  ⚠️ 禁止: base64 文字列やローカルの絶対パスをそのまま imageToUI に書き込むこと。ローカルパスはギャラリーサーバーから到達できず、base64 はブラウザで開くことができず、カードアイコンが機能しなくなります。ユーザーが明確に選択するまでは、このフィールドを書き込まないでください。

フィールド値のルール（ギャラリー catalog.mjs がこれに基づいて解析します。詳細は skills/ui-metadata/SKILL.md を参照）：

• http:// / https:// / // で始まる → 外部リンクと見なし、クリックでジャンプします。
• その他（./assets/...、assets/...）→ プロトタイプディレクトリ内のリソースと見なし、/prototypes/<slug>/... として解決され、新しいタブで画像を開きます。
• 空欄 / 未記入 → カードはそのアイコンを表示しません。

1. デザインタスクの明確化

製品のポジショニング、ユーザーシナリオ、コアタスク、情報の優先順位、ファーストビューの重点を確定します。まず実際のコピーと妥当なデータを準備し、その後で表示方法をデザインします。空虚なプレースホルダーコンテンツは避けてください。

2. ビジュアルの方向性の決定

簡潔なデザイン説明で、このページの雰囲気を明確にします。固定のフォーマットやパラメータシートを記入する必要はありません。少なくとも以下の点を明確に考えてください。

• 全体的な視覚的印象とブランドの性格。
• タイポグラフィ、構成、情報階層がコンテンツをどのように表現するか。
• フォントが個性と品質をどのように確立するか。
• 色彩が雰囲気、識別性、重点をどのように確立するか。
• アイコン、グラフィック、写真、データ可視化が表現にどのように参加するか。
• アニメーションが体験を強化できるか、またどのような動きの言語を採用すべきか。

3. デザインシステムの確立

現在のページのニーズに基づいて、CSS 変数と再利用可能なスタイルを確立します。色、フォント、フォントサイズ、間隔、角丸、境界線、影、動きは一貫したデザインロジックを持つべきですが、固定の数値、値、比率を強制するものではありません。

デザインシステムを創造性を制限するパラメータ表にしてはいけません。 柔軟に調整することは可能ですが、各選択は全体の効果に奉仕する必要があります。

四、ビジュアルデザインの重点

4.1 タイポグラフィと構成

• ユーザーが一目でどこを最初に見るべきかを理解し、その後自然に他の情報を理解できるようにします。
• フォントサイズ、フォントウェイト、フォントの性格、色、位置、余白、配置を利用して階層を確立し、カードや境界線の積み重ねに依存しません。
• コンテンツに応じて、グリッド、非対称、ずらし、段組み、重ね、没入型、エディトリアル、またはその他の構成を探求します。
• 大胆なサイズの対比、特殊な改行、視覚的な緊張感を許容しますが、全体は調和し、読みやすくなければなりません。
• ページには疎密、軽重、リズムの変化が必要であり、すべての領域に均等に力を入れてはいけません。
• デフォルトで中央揃え、対称、等幅カード、または同一のブロック配置にしないでください。
• ビジュアルデザインは、ユーザーが情報を理解しタスクを完了するのに役立つべきであり、スクリーンショットの効果だけを追求するものではありません。

4.2 機能とシンプルさの関係

機能の完全性と視覚的な美しさは共に実現されなければなりません。シンプルさは機能を削除することではありません。

• 製品カテゴリに応じて、ユーザーが合理的に期待する完全な機能を提供します。ページをより空に、よりシンプルに、またはスクリーンショットをより良く見せるために、勝手に機能を削除してはいけません。
• まず情報アーキテクチャ、機能グルーピング、エントリポイントの位置、インタラクションフロー、視覚表現を最適化します。
• プログレッシブディスクロージャー、コンテキストアクション、クイックエントリー、アイコン表現、メニュー、ドロワーなどを使用して、視覚的な負荷を軽減します。
• 高頻度の機能は発見しやすく操作しやすいものであるべきです。低頻度の機能は収納しても構いませんが、見つけにくい場所に不当に隠してはいけません。
• アイコンはテキストを減らすことができますが、理解しやすくなければなりません。重要な操作には、必要に応じてテキストラベルを保持します。
• ユーザーがミニマルを優先し、冗長な機能を削除するよう明確に要求した場合、または特定の機能が確かに製品の範囲外である場合にのみ、削除を検討し、その理由を説明します。
• 機能のエントリ、ステータス、フィードバックは完全でなければなりません。視覚的に存在するが、実際には応答しないコントロールを作ってはいけません。

4.3 コピーライティングと情報表現

• インターフェースは取扱説明書ではありません。簡潔に表現できるのであれば、長い説明文を書く必要はありませんが、必要な情報を損なうほど文字数を減らしてはいけません。
• インターフェース内に「デモ/プロトタイプ/モック」に関する文字やグラフィックを一切表示してはいけません：「デモモード」「サンプルデータ」「Mockデータ」「テストアカウント」「これはプロトタイプです」などと書かない。吹き出し注釈、矢印プロンプト、番号マーク、教育用ハイライトボックスを描かない。「イメージ図」「プレースホルダー画像」「Lorem ipsum」「後日追加」などを使わない。インターフェース内のすべての文字、すべてのアイコンは、製品に実際に存在するコンテンツでなければなりません。
• プロトタイプを正式にリリースされる製品のインターフェースとしてデザインします。コピーは実際のビジネスデータのように、チャートは信頼できる数値関係を持ち、空の状態は製品独自のガイダンスを書き、エラーメッセージはユーザーが実際に遭遇する状況を書きます。実現できない部分（サーバー側インターフェース）は納品説明で述べ、インターフェースには書き込みません。
• 英語ブランドや国際的なページでは、簡潔な単語、短いラベル、大きなフォントサイズのテキスト、視覚的なシンボルを使用できます。
• トレンド、クリエイティブなページでは、アイコン、シンボル、グラフィック、視覚的な数字をより多く使用できます。プロフェッショナルツールでは、情報の明瞭さを優先します。
• 中国語（原文）の表現は自然で正確であるべきです。装飾のために無理に英語や意味のない略語を入れてはいけません。
• コピーは具体的で情報量が多く、空虚なマーケティング用語、繰り返しのタイトル、自己言及的なガイダンスを避けます。
• ステータス、トレンド、プロセス、分類、比率は、理解のコストに応じて、アイコン、チャート、構造図、テキストから選択して表現できます。特定の表現方法を強制するものではありません。

4.4 フォントデザイン（重要）

デフォルトのシステムフォントを最終的な解決策にしてはいけません。 長文の本文、情報密度の高いエリア、読みやすさを優先するシナリオを除き、積極的にフォントを選んでください。

• 高級感/デザイン性/ブランド性を求める場合は、積極的にディスプレイフォントやフォントの組み合わせを探し、デフォルトフォントでごまかさないでください。
• 見出し、ワードマーク、重要な数字、本文、補助情報には異なる性格のフォントを使用できますが、組み合わせは調和し、フォントを多用しすぎないようにします。
• 英語（原文の内容）：幾何学的サンセリフ、ヒューマニストサンセリフ、Grotesk、セリフ、ナロー/ワイドボディ、Display、手書き、実験的なもの。雰囲気に応じて選び、デフォルトでInterを使用しないでください。
• 中国語（原文の内容）：モダンなゴシック体、宋体/セリフ体、丸ゴシック体、筆記体、特徴的なディスプレイ体。ディスプレイ体は見出しなどの短いテキストにのみ使用し、長文の本文は読みやすさを優先します。
• 数字：ベースライン、字面高さ、幅、配置を統一し、幅の不均一なアートフォントを使用しないでください。
• フォントウェイト、フォント幅、字間、大文字小文字、イタリック、改行はすべてデザイン性を生み出すことができます。フォント名を変えるだけに頼らないでください。
• デフォルトの最小フォントサイズは 12px（下限であり、厳格なルールではありません）。小さなロゴ/パターン内のテキストは必要に応じて小さくできます。タイポグラフィは幅に応じて自動的に折り返すようにし、積極的に改行しないでください。

フォントの出典、CDN参照、読み込みが遅い場合の処理については、第六節「フォント」を参照してください。

4.5 配色デザイン

特定の色のセット、配色比率、アクセントカラーを固定して使用しないでください。まず製品の雰囲気を判断し、その後、大胆に適切な色彩関係を探求してください。

高級グレー、ニュートラルカラー、低彩度色、自然色、寒暖対比、ブランドカラー、明るい対比色、ダークラグジュアリー、モノクロームシステムなどの方向性を検討できます。色彩は控えめにも鮮やかにもできます。重要なのは、調和、階層、識別性、感情表現です。

モスグリーン、ブルーグリーン、ミストブルーのような寒色系の青緑系の色調は、配色の探求の先頭に並べないでください。今日のAIが生成するインターフェースのほとんどはこの系統であり、類似しやすく、最後の手段として残しておくのが良いでしょう。

• 色には明確な役割が必要であり、背景、コンテンツ、テキスト、重点、ステータスの間に明確な関係を形成します。
• アクセントカラーは特定の色に固定する必要はなく、ブランドとページコンテンツに応じて選択する必要があります。
• グラデーション、透明度、マテリアル、ライティングを使用できますが、デザイン上の目的が必要です。グラデーション、発光、ガラス効果をデフォルトの高級感として扱わないでください。
• 色のコントラストは、テキストと重要なコントロールが識別可能であることを保証する必要があります。雰囲気のために読みやすさを犠牲にしてはいけません。
• 低彩度や高級グレーを追求するあまり、ページが重点、階層、活気を失わないようにしてください。

4.6 アイコン、グラフィックとイメージ

• アイコン、シンボル、幾何学図形、イラスト、写真、データ可視化はすべて主要なビジュアル言語になり得ます。テキストとカードに限定する必要はありません。
• 製品の雰囲気に応じてグラフィックスタイルを選択し、線、比率、質感、表現方法が調和していることを確認します。
• 機能アイコンは識別のしやすさを優先します。ブランドやクリエイティブなグラフィックは、より個性的であっても構いません。
• スタイルが明らかに異なるアイコンライブラリを混在させたり、絵文字を正式な機能アイコンの代わりに使用したりしないでください。
• グラフィックには表現目的が必要です。識別の補助、関係の説明、ステータスの伝達、ブランド形成、視覚的緊張感の強化。
• イメージは明確な構図、色彩、コンテンツのロジックを持つ必要があり、無造作なコラージュや無関係な素材でページを埋めることを避けます。

4.7 ディテールと完成度

• フォントレンダリング、字間、配置、境界、アイコンの比率、階層、インタラクション状態、コンテンツのディテールに注意を払います。
• 境界線、区切り線、影、角丸、テクスチャ、透過効果は必要に応じて使用し、装飾のために装飾しません。
• コンポーネント間の一貫性を保つと同時に、重要な領域に合理的な視覚的差異を持たせることも許容します。
• ページはファーストビューだけが洗練されているのではなく、スクロール領域、ポップアップ、メニュー、空の状態、エラー状態も完全にデザインする必要があります。
• 「デザインファイルらしさ」のために、実際の使用時の読みやすさ、操作性、応答速度を犠牲にしてはいけません。

4.8 境界線は切り取られてはいけない（クリッピングコンテナ必読）

境界線を持つコンポーネントをコンテンツをクリッピングする親コンテナ内に配置する場合、親コンテナのパディングは、コンポーネントのすべての状態における最大境界線幅以上でなければなりません。 そうしないと、境界線が一部切り取られ、境界の欠損は直接「レンダリングが壊れている」と解釈されます。

メカニズム

overflow: hidden はコンテナの パディングボックス（コンテンツボックス + パディング）をクリッピングします。

• コンテナのパディングは、子要素のはみ出しを吸収できます → 十分なパディングを確保すれば、境界線を露出できます。
• しかし、box-shadow の広がりと outline は境界ボックスの外側に描画されるため、パディングでは救えません。

解決策（優先順位順）

1. グローバルな box-sizing: border-box（推奨） —— 根本からはみ出しを排除します。

*, *::before, *::after { box-sizing: border-box; }

2. 親コンテナに境界線の余裕を持たせる —— padding ≥ 境界線幅 + 1px。実測：境界線 4px の場合、padding ≤ 6px で右の境界線が切り取られ、≥ 7px で完全に表示されます。境界線幅と等しい 4px でもまだ切り取られる可能性があるため、必ず余裕を持たせてください。

3. inset シャドウで境界線を代用する —— スペースを取らず、決して切り取られません。

.card { border: 0; box-shadow: inset 0 0 0 1px var(--line); }

禁止事項

• 常時表示の境界線として、外側に広がる box-shadow / outline を使用すること（境界ボックスの外側に描画されるため、クリッピングされると即座に消える）。
• 負のマージンで隣接する境界線を結合すること（クリッピングがある場合、必ず切り取られる）。

ホバー時のみ境界線が現れる場合

最も頻度の高いシナリオ：デフォルト状態は正常だが、ホバーすると境界線の一部が欠ける。透明な境界線でスペースを確保し、色のみを切り替えることで、切り替え時のジャンプやはみ出しを防ぎます。

.item { border: 1px solid transparent; transition: border-color .18s; }
.item:hover { border-color: var(--line); }

各コンポーネントの確認は、第九節のセルフチェック第13条を参照してください。

4.9 ネイティブコントロールのスタイル統一

ブラウザのネイティブコントロール（スクロールバー、select ドロップダウン、input / textarea フォーカス状態、checkbox / radio / range のアクセントカラー、日付ピッカーなど）はシステムによってレンダリングされ、その外観は自前のUIと一致しません。これらは最も見落とされがちで、かつ全体的な統一感を損なう弱点です。ページ内に現れるすべてのネイティブコントロールは、製品のビジュアル言語に収束させ、システムのデフォルトの外観を保持しないでください。

• スクロールバー: WebKit では ::-webkit-scrollbar* シリーズ、Firefox では scrollbar-width / scrollbar-color を使用して、トラックとサムの色、角丸、ホバー状態を統一します。局所的なスクロール領域にのみ適用し、幅は控えめに（約 8–10px）、グローバルに太くしないでください。
• 入力フィールド: input / textarea / select は appearance: none を使用して独自の境界線、角丸、focus-visible フォーカス状態を描画し、ブラウザのデフォルトの境界線と内側の影を継承しないようにします。
• select ドロップダウン: ネイティブの option パネルは深くカスタマイズできません。appearance: none + 独自の展開矢印を使用し、--control-* 変数でボタンや入力フィールドと一貫性を保ちます。検索、グループ化、カスタムハイライトが必要な場合は、独自のドロップダウンでネイティブの select を置き換えます。
• アクセントカラー: checkbox / radio / range / progress は accent-color: var(--brand) を使用し、システムの青を保持しないでください。
• 複合入力: カラー、日付、時間などのパネルはカスタマイズできません。重要な製品では、独自のコントロールで置き換えるか、入力形式を制限します。

要点：すべてのネイティブコントロールのパディング、フォントサイズ、角丸、フォーカス状態をデザイン変数（例：--control-bg / --control-border / --control-radius / --control-focus）に組み込み、カードやボタンと同じビジュアル体系にし、「二つの言語」を排除します。

五、アニメーションデザインと実装

アニメーションはUIデザインの一部であり、単にボタンにホバー効果を追加するだけではありません。製品の雰囲気とユーザーニーズに応じて、インターフェースにおけるアニメーションの役割を積極的に判断する必要があります。

5.1 まずアニメーションの必要性を判断する

• ユーザーが優れたアニメーション、高度な動き、滑らかなアニメーション、クール、派手、没入感、映画のような、ダイナミックなビジュアル、または類似の要求を明確に述べた場合、アニメーションをデザインの主要な要素として扱い、GSAP などのプロフェッショナルなアニメーションライブラリを積極的に使用して複雑な効果を実現します。単純な CSS transition でごまかさないでください。
• ブランドサイト、クリエイティブショーケース、プロダクトローンチ、ポートフォリオ、インタラクティブストーリーテリングなど、動的な表現に適したページでは、リズミカルなエントランス、スクロールナラティブ、パララックス、テキストアニメーション、グラフィックの変形、マスクのリビール、レイヤードモーション、シームレスなトランジションを積極的にデザインできます。
• プロフェッショナルツール、バックエンド、高頻度操作インターフェースでは、アニメーションは状態の理解、空間関係の構築、フィードバックの提供に役立つべきです。洗練されスムーズであることは許容されますが、効率を妨げてはいけません。
• ユーザーが複雑なアニメーションを明確に要求していない場合は、製品の雰囲気に応じて適度にデザインします。テクニックを誇示するために意味のない動きを追加しないでください。
• すべての要素を同じフェードイン＆上昇の動きにしたり、すべてのコンポーネントが独立して動作したりしないでください。

5.2 アニメーションの質感

• 機械的なリニアモーションを避ける: 空間移動、スケーリング、インターフェーストランジションには、通常、自然な加速、減速、非対称イージング、またはスプリング効果を使用します。Linear は、回転、プログレスバー、持続的なスクロールなど、本当に必要なシナリオにのみ適しています。
• 質感のあるイージングを使用する: 移動距離、要素の質量感、シナリオに応じて、ease-out、ease-in-out、power、expo、back、spring などのカーブを選択します。派手な弾性は控えめにし、安っぽい反復バウンスを避けます。
• 適度な減衰感を加える: 大きなパネル、オーバーレイ、ドラッグ、フォロー、マグネット、空間トランジションには、慣性、減衰、反発、またはスプリング感を持たせ、動きをより自然にします。
• 動作には因果関係が必要: エントリー、退出、展開、収納、切り替え、ドラッグ、状態変化は、ユーザーの空間と物体に対する直感に適合する必要があります。
• 演出にはリズムが必要: タイミングをずらす、重ねる、連続して繋ぐ、レイヤードモーションを使用できますが、主従が必要であり、すべての要素が同時に無秩序に動いてはいけません。
• アニメーションはコンテンツと操作に応答する: 意味のない永久ループ、継続的な浮遊、注意を奪うバックグラウンドアニメーションを避けます。
• パフォーマンスを優先: transform、opacity など、コンポジットに適したプロパティを優先的に使用します。複雑なフィルター、ブラー、大面積のリアルタイムエフェクトは慎重に扱い、フレーム落ちを避けます。

5.3 優先的に gsap-skills と GSAP を使用する

GSAP アニメーションを作成する前に、まず判断します。現在のシステム/エージェントが gsap-skills スキルをインストールしている場合、アニメーションデザインは可能な限りそれを呼び出して最新のAPIと記法を取得します。インストールされていない場合、積極的にユーザーに確認を求め、npx skills add https://github.com/greensock/gsap-skills の実行を推奨します（インストールするかどうかはユーザーが決定）。インストール後にアニメーションデザインに使用します。 記憶だけで古い GSAP の使い方を書き写さないでください。

複雑なアニメーション（エントリーナラティブ、スクロール駆動、タイムライン編集、インタラクティブドラッグ、複数要素の協調）は、優先的に GSAP を使用します。

• Timeline を使用してアニメーションのグループを統一的に編集します（ラベル、オーバーラップ、ネスト、コールバック）。相互に関連のない delay の集まりにしないでください。
• スクロール駆動には ScrollTrigger を使用します。スムーズスクロール、一文字ずつ、パス、フリップなどは、必要に応じてプラグインをインポートします。
• 単純な状態フィードバックには CSS transition / keyframes で十分です。ライブラリを使用するためだけにインポートしないでください。
• CDN（例：gsap@3）を介して導入し、第八節の技術的取り決めに従います。アニメーションはモジュール管理し、再生/一時停止/逆再生/リセット/クリーンアップを容易にします。

5.4 連続操作、中断と復帰

インタラクティブアニメーションは、ユーザーの連続操作を考慮する必要があります。新しい操作が来たときに、現在の視覚状態から自然に接続し、ちらつかず、初期位置にジャンプせず、アニメーション状態が実際のUIから乖離しないようにします。

• 可逆的な状態（展開/収納、オン/オフ）：同じ Timeline を再利用し、reverse() / play() で自然に逆方向に再生し、新たに作成しません。
• 連続的に変化する目標値（ドラッグ、カーソルフォロー）：gsap.quickTo() を使用して、常に最新の入力に追従するようにし、毎回新しいトゥイーンを作成しません。
• 複数のシーケンスの接続：Timeline / ネストされた Timeline / コールバック / ステートマシンで統一的に管理し、互いに同じプロパティを争う独立したアニメーションを作成しません。
• インタラクションのセマンティクスに応じて「シーケンスの継続 / 逆再生 / 新しいターゲットへの切り替え / 他のプロパティとの並列実行」を区別し、一律に追加したり一律に終了したりしないでください。実際に競合するプロパティのみを上書きします（GSAP では overwrite: "auto" を使用し、無差別に kill() したり、グローバルに overwrite: true にしたりしないでください）。

5.5 アクセシビリティとパフォーマンス

• prefers-reduced-motion: reduce を尊重し、動きの効果を減らすためのオプションをユーザーに提供します。アニメーションを減らす場合でも、情報と機能は完全でなければなりません。
• 重要なコンテンツを隠したり、ユーザーが即座に得るべき情報を遅延させるためにアニメーションを使用しないでください。
• 高頻度の点滅、高速で大規模なズーム、不快感を引き起こす可能性のあるパララックスを避けます。
• スクロールアニメーションは、通常のスクロール、キーボード操作、タッチ操作に影響を与えてはいけません。
• ページが離脱するかコンポーネントが破棄される際に、イベントリスナー、ScrollTrigger、不要になったアニメーションインスタンスを適切にクリーンアップします。
• ファーストビューの重要なコンテンツは、アニメーションライブラリの読み込みが完了するのを待ってから表示されてはいけません。

参考：

• GSAP ドキュメント
• GSAP Timeline
• GSAP Tween / overwrite
• Apple HIG Motion
• Material Motion

六、素材

素材の取得は一律 tools/resource-getter/get.py を使用し、サイトのURLを手動で組み立てたり、ページ内に多数の出所不明な外部リンクを散在させたりしないでください。完全な提供元マトリックス、ライセンス、トラブルシューティングについては tools/resource-getter/README.md を参照してください。

選定優先順位

1. 透明ベクターイラスト: unDraw / Storyset / DiceBear / Doodle Ipsum
2. 切り抜き PNG: Pixabay（--transparent）/ pngimg
3. 写真: Pixabay / Picsum / Unsplash / Pexels
4. 手書き SVG（幾何学、装飾、チャート）
5. AI 生成画像（最も優先度が低い、ルールは以下）

デフォルトはホットリンク、遅ければローカルに保存。 get の auto モードは実際に TTFB を測定します。> 0.9s または読み取りに > 2.5s かかる場合は「遅い」と判断し、ui/<page>/assets/ にダウンロードする必要があります。それより速くても、大量のリモート画像をファーストビューに詰め込まないでください。

[翻訳のため省略]

七、フォント

7.1 フォント選択

• 見出しや短いテキストには、製品の雰囲気に合ったディスプレイフォントや特徴的なフォントを積極的に使用します。
• 長文の本文には、読みやすく可読性の高いフォントを選択します。
• 日本語/中国語のフォントと欧文フォントを組み合わせる場合、それぞれの文字セットに適したフォントを選び、グローバルなトーンが調和していることを確認します。
• Google Fonts、Adobe Fonts、Fontsource などの信頼できるソースからフォントを取得します。疑わしいソースや違法に配布されているフォントは使用しないでください。

7.2 CSS でのフォント読み込み

• @font-face または CSS @import を使用してフォントを読み込みます。パフォーマンスを向上させるために、font-display: swap または font-display: optional を設定します。
• 使用するフォントファイルの形式（woff2、woff など）が適切であり、ファイルサイズが大きすぎないことを確認します。
• 遅延読み込みやフォントのサブセット化を検討して、初期ページ読み込み時間を短縮します。

八、技術的実装

8.1 ファイル構造

ui/
  <page-slug>/
    index.html
    style.css
    script.js
    assets/          # 画像、フォント、その他のローカルリソース
    metadata.json    # ページメタデータ（skills/ui-metadata/ の仕様に従う）

8.2 HTML 構造

• セマンティックなHTMLタグを使用します（<header>, <nav>, <main>, <section>, <footer> など）。
• id と class には明確で一貫性のある命名規則（BEM など）を使用します。
• アクセシビリティに配慮し、適切な aria-* 属性、ラベル、フォーカス管理を実装します。
• CSS と JS ファイルを適切にリンクします。

8.3 CSS 実装

• カスタムプロパティ（CSS 変数）を活用して、デザイントークン（色、フォント、間隔など）を管理します。
• contain: paint と overflow: hidden を使用して、コンテナの境界を強制します（第二節の「コンテナ境界」を参照）。
• box-sizing: border-box をグローバルに適用します。
• レスポンシブデザインの原則に従い、min()、max()、clamp() などの関数を適切に使用します。
• cqw / cqh を使用したコンテナクエリ（container queries）は、必要に応じて使用します。

8.4 JavaScript 実装

• モジュール化されたクリーンなコードを作成します。
• アニメーションには GSAP を優先的に使用します（「5.3 優先的に gsap-skills と GSAP を使用する」を参照）。
• DOM 操作、イベント管理、状態管理を適切に行います。

8.5 パフォーマンス

• 画像を最適化し、適切な形式とサイズを使用します。
• CSS と JavaScript のファイルを可能な限り縮小（minify）します。
• クリティカルレンダリングパスを考慮し、レンダリングをブロックするリソースを最小限に抑えます。

九、セルフチェック（品質保証）

プロトタイプの提出前に、以下の項目を確認してください。

1. 全体的な印象: プロトタイプは、テンプレート感や未完成感がなく、完成された製品のように見えますか？
2. ブランドの一貫性: ビジュアルスタイル、色、フォントは、製品のポジショニングとブランドアイデンティティと一致していますか？
3. 情報階層: 情報は明確に構造化され、ユーザーは重要な要素にすぐに気づき、コンテンツを自然にナビゲートできますか？
4. タイポグラフィ: フォントは意図的に選択され、適切に使用されていますか？フォントの組み合わせは調和し、読みやすいですか？
5. 配色: 色は調和し、目的があり、テキストとコントロールのコントラストは十分ですか？
6. アイコンとグラフィック: アイコンとグラフィックは一貫性があり、目的を持って使用され、製品の雰囲気を高めていますか？
7. アニメーション: アニメーション（存在する場合）は目的があり、スムーズで、ユーザーエクスペリエンスを向上させていますか？prefers-reduced-motion は尊重されていますか？
8. 機能の完全性: コア機能はすべて存在し、視覚的に表現されていますか？機能が欠落していたり、意味のないプレースホルダーで置き換えられていたりしませんか？
9. コンテンツ（コピー）: すべてのテキストは具体的で、製品コンテキストに適しており、「デモ」や「プロトタイプ」に関連するものはありませんか？
10. コンテナ境界: プロトタイプは正しいコンテナタイプ（ソフトウェア/ウェブ/アプリ/コンポーネント）で表示されていますか？contain: paint と overflow: hidden は正しく適用されていますか？オーバーレイやブラーはキャンバス内に収まっていますか？
11. ダイアログサイズ: ダイアログ（ソフトウェアタイプの場合）は、指定されたサイズ仕様に従っていますか？
12. ネイティブコントロール: スクロールバー、入力フィールド、セレクト、チェックボックスなどは、製品のビジュアル言語に合わせてスタイル設定されていますか？
13. 境界線のクリッピング: 境界線のあるコンポーネントがクリッピングされる親コンテナ内にある場合、境界線は切り取られずに完全に表示されていますか？（「4.8 境界線は切り取られてはいけない」を参照）
14. 画像とその他のメディア: すべての画像とメディアは適切なソースから取得され、最適化され、正しく表示されていますか？
15. コード品質: HTML、CSS、JavaScript はクリーンで、整理されており、効率的ですか？
16. アクセシビリティ: プロトタイプは、キーボードでナビゲート可能で、スクリーンリーダーに適切な情報を提供していますか？
17. 応答性: プロトタイプは、異なる画面サイズに対して適切に応答しますか？（適用可能な場合）
18. パフォーマンス: プロトタイプはスムーズに読み込まれ、実行されますか？不必要なパフォーマンスのボトルネックはありませんか？

十、納品

• 成果物は、指定されたファイル構造（第八節を参照）に従って整理されている必要があります。
• すべてのファイル（HTML、CSS、JS、画像、フォント）が存在し、正しくリンクされていることを確認します。
• 開発者またはレビュー担当者が理解できるように、明確なコメントとドキュメントを提供します。
• このスキルのすべてのルールとガイドラインに従っていることを確認するために、最終チェックを実行します。