sheleg-design

SHELEG デザイン

概要

ページがシネマティックに感じられるのは、アニメーションが多いからではなく、単一の信頼できる情報源（計測されたスクロール位置）が、低コストで、レイヤー化され、個別に劣化可能な多数の反応を駆動するからです。スクロールを一つのストアに集約し、各レイヤーがフレームごとに読み取り、それぞれの方法で反応します。クロスフェードするものはありません。要素は再配置されます。どのレイヤーも、落ち着いた静的状態へ劣化します。

以下の技法に進む前に、まず必ずお読みください： CREATIVE_DIRECTOR.md — 意思決定のレイヤーです。サーフェスの用途と、失敗を証明するもの、レーンとモード（再設計では置き換える対象の計測から始め、更新ではトークンを変更します）、npx sshlg-skills pack design --lane <lane> で計測する使用ツール、互いに異なるツール構成の2つのバリエーションに分岐するタイミング（ルーブリックを先に記述）、アラインメントと計測可能な品質を別々の問いとして扱うこと、そしてそのすべてを記録するディレクター記録について説明しています。エージェントがデザインを行う際の失敗は、醜さではなく、もっともらしさです。このドキュメントは、それを拒むためのものです。

**必須リファレンス — シネマティックな経路の場合：**スクロール駆動型ページを実装する前に SHELEG_DESIGN.md をお読みください — アーキテクチャ、モーフィングの計算式、DOM↔WebGL ブリッジ、ビルド手順（§11）、ファイルマップが記載されています。 プロダクト UI の作業では、この参照は必須ではありません。ただし、該当する唯一のルールをここに繰り返します。パックのモーション・トークンが SHELEG のデフォルトと異なる場合は、パックを優先します。

アニメーションを始める前に必ずお読みください： MOTION_DOCTRINE.md をお読みください。SHELEG_DESIGN.md はモーションの構築方法を説明し、ドクトリンは構築すべきかどうかを説明します — 高頻度で繰り返される経路のアニメーションを無効にする頻度表、イージングのツリーと ease-in の禁止、継続時間の上限、禁止される形式、reduced-motion の契約です。

アクセシビリティに関する主張を行う前に必ずお読みください： ACCESSIBILITY_EVIDENCE.md をお読みください — 主張がどの基準で評価されるか（番号・バージョン・レベル・単位・例外を明示した WCAG 基準、またはプラットフォームのヒューリスティック）、スクリーンショットで DOM や支援技術について証明できることとできないこと、そして判定の契約について説明しています。ツールがない場合は NOT_RUN であり、決して PASS ではありません。また、自己完結のためにスキャナーをインストールするチェックはありません。 連携は対象範囲に限定され、ルーティングは行いません。クラフトゲートのコントラスト行とレンダリング批評は、主張を行う箇所でこれらの判定を利用します — 既存の機能であり、新たなルーターやエントリーポイントは追加しません。また、品質レシートでは2種類の行を分けて扱います。視覚的な評価（レンダリングがどのように見えるか）と、WCAG 適合性（基準を明示した、計算済みで範囲を限定したチェック）です — 批評に基づいて修正されたレンダリングは、限られた予算内で同じ修正前／修正後のマトリクスを用いて評価します（CREATIVE_DIRECTOR.md）。未解決の観察事項は、リリース済みと言い換えず、未解決のままにします。一目見ただけでは適合性の行は作成できません。そのように作られたレシートは却下されます。「アクセシビリティがあるように見えた」というのは、基準名を冠したスクリーンショット上の主張にすぎないからです。

トリガー

「ランディングページを作成」／「сделай лендинг」、「ランディングページをデザイン」／「дизайн лендинга」、「モバイル画面」／「мобильный экран」、「ダッシュボード風」／「стиль дашборда, сделай дашборд, админка」、「スクロールアニメーション」／「скролл-анимация, анимации」、「デザイントークン、スタイルパック」／「дизайн-токены」、「ライト／ダークテーマ」／「светлая/тёмная тема」、「Figma 変数」／「переменные фигмы, фигма в код, макеты」、「パレット、色」／「палитра, цвета」、「タイポグラフィ、フォント」／「типографика, шрифт」、「見た目をどうにかしたい、もっときれいに」／「выглядит, красиво, красивее」、「ビジュアルリファレンス」／「визуальные референсы」、「ウェブページ形式の投資家向けデッキ」／「веб-презентация」、「再設計」／「редизайн, свёрстай, вёрстка」。

使用する場面

• モーションが明確な目的となっているランディングページ／マーケティングページ／ヒーローページ。スクロールに連動するパーティクルや WebGL 背景（3D エンジン：web3d-dev）、スクロール連動のチャート、ステップフロー、レール、パララックス
• 既存のスクロールサイトが落ち着かない、ぎくしゃくする、または位相がずれているように感じられる場合
• 視覚システムを統一する必要がある製品 UI — ダッシュボード、管理画面、社内／開発者向けツール、トークン、ライト／ダーク — スタイルパックのみを適用し、workbench を使用します
• AI 製品の画面：チャットやエージェント UI、ストリーミング出力、実行ログ、モデルエラー、生成コンテンツや確認の状態（AI_PRODUCT_PATTERNS.md）
• 視覚システムを Figma の境界を越えて双方向に移行する場合（FIGMA_BRIDGE.md）
• レンダリング済みファイルとしてページ外に持ち出す必要があるモーション — ローンチ動画、機能紹介ループ、SNS 向け動画（MOTION_PRODUCTION.md）。プログラムによる動画制作ツールの両方を明記します

シネマティックモーションレイヤーを適用してはいけないもの： 製品 UI、ドキュメントサイト、静的コンテンツサイト、または視覚システムやコピーがまだ完成していないページ。製品 UI で使用するのはスタイルパックの部分のみで、それ以外は適用しません。

コアパターン — 5つの原則、順番どおりに

1. 単一のクロック。 すべてのモーションは、計測された単一のスクロール状態を基準にします。各レイヤーが独自にスクロールを計測することはないため、位相がずれることはありません。
2. フレームごとに読み取り、通知は控えめに。 高頻度で更新されるコンシューマー（WebGL／canvas／レール）はストアを命令的に読み取り、フレームワークの再レンダリングはゼロにします。フレームワークに通知するのは、大まかなアクト／セクションの変更時のみです。
3. 静止させてから、再配置する。 セクションの約80%はフォーメーションを保ち、その後、位相をずらし、弧を描く短いウェーブで変形します。クロスフェードは禁止です。
4. 意味のあるモーション。 スクラブは、時間経過に伴う状態を伝えるインストゥルメントに限ります。ホバーと押下はドクトリンの範囲内に保ち、計測に基づく場合はエントランスがその範囲を超えてもかまいません。いずれもコンテンツの表示を妨げてはいけません。
5. 落ち着いた表示に切り替える。 視差効果の低減／粗いポインター／WebGL 非対応の場合は、静的で完全に読み取れるページに切り替えます。エフェクトは付加価値であり、依存要件ではありません。

スタイルパック

視覚的なアイデンティティはスタイルパックによって決まります。選ぶ前に スタイルパックのインデックスを読み、その後、選んだパックの全体に目を通し、styles/tokens/<pack>.css からトークンレイヤーをコピーしてください。トークンの表を書き写したり、スクリーンショットから値を推測したりしないでください。

具体化されたキットは、コンポーネントの状態を提供します：

npx sheleg-design-skill --kit <pack>

生成された src/styles.css は、コアパックで未定義のまま残されている状態の正となる情報源です。拡張パックのキットと ## Components セクションの内容は一致している必要があります。npx を利用できない場合 — Node がない、またはレジストリにアクセスできない場合 — 何も妨げにはなりません。選んだパックと styles/tokens/<pack>.css 内のトークンレイヤーから、読み取ってルールを確認できます。ただし、キットで具体化されるコンポーネントの状態は未検証となるため、キットで確認済みの状態として提示せず、その旨を伝えてください。パックを作成する場合は、styles/STYLE_PACK_TEMPLATE.md を基にし、同じ変更でトークンファイルも追加してください。

キャリブレーション — まず観察可能な目標を定め、数値は略記として使う

パックが示すのは、どのレジスターかです。どの程度かまでは示しません。同じパックを使ったランディングページでも、規制対象の保険会社向けとデザインスタジオ向けでは、同じページにはなりません。

主な取り決めは、このシナリオでの観察可能な目標のセットです — レンダリングを見た別の読み手が確認できるもの、たとえば、読みやすい横幅、CTA が属するファーストビューを越えてスクロールしなくても届くかどうか、一度に表示される選択肢の数、キーボード操作時の状態、そして意図的に設けた空白がそれぞれ何のためのものか、などです。同じブリーフに取り組む独立した実行者は、同じ観察可能な基準を通じて密度や差異を説明できなければなりません — 数字だけではそれができないため、基準を伴わない数字は根拠になりません。

3 つのダイヤルは、同じ意図を任意の略記として表します — 品質の測定値ではなく、好みのヒントです（Leonxlnx/taste-skill、MIT、告知より）。

• DESIGN_VARIANCE 1～10 — 1 は完全な対称性、10 は意図的な非対称性で、どのセクションも同じではありません。
• MOTION_INTENSITY 1～10 — 1 は静的、10 は映画的で身体感覚に訴える表現です。
• VISUAL_DENSITY 1～10 — 1 はギャラリーの壁、10 はコックピットです。

ベースラインは 7 / 5 / 4 です。 制作を始める前に数値とその理由を一文で述べてください。ユーザーにファイルの編集を求めたり、告知した内容から黙って逸脱したりしないでください。告知する数値にはそれぞれ、具体例または反例を添えるか（「密度 5 — パック独自のダッシュボード参考例のように。マーケティング用ヒーローのようにはしない」など）、最初のレンダリング後に受け入れられた方向性から導き出してください — 何も存在しないうちに固定された数字には、何の拘束力もありません。同じ数字でも、プラットフォームごとの異なるタスクが同じになるわけではありません。落ち着いたダッシュボード、一般消費者向けチャット、アクセシビリティに配慮した大きな文字の画面は、どれも密度 5 を掲げられますが、基準が異なるため、それぞれ異なるレンダリングが求められます。また、明示的なユーザー要件はベースラインやスタイルの下限より優先されます — ダイヤルはデフォルトを調整するものであり、ブリーフを覆すものではありません。トークンの取り決めは変わりません（値はパックから取得します）。その範囲内の構成は自由な選択であり、これらのヒントは判断材料となりますが、採点尺度ではありません。

ブリーフから数値を読み取る

ブリーフの表現	VARIANCE	MOTION	DENSITY
ミニマリスト、落ち着いた、エディトリアル、「Linear のように静か」	5–6	3–4	2–3
プレミアムな一般消費者向け、ブランド主導、「高級感がある」	7–8	5–7	3–4
エージェンシー、ポートフォリオ、実験的、賞狙い	9–10	7–9	3–4
ランディングページ／マーケティングページ、特に指定なし	7	5	4
プロダクト UI：ダッシュボード、管理画面、社内ツール	4–5	2–3	6–8
信頼性優先：規制対象、公共部門、臨床用途	3–4	2–3	4–5
プレゼンテーション資料	5–6	1–2	3–4
リデザイン、既存のアイデンティティを維持	一致	一致	一致
リデザイン、明示的な刷新	+2	+2	一致

2 つの行が該当して内容が食い違う場合 — 画面の種類をムードより優先し、モーションと装飾に限ってスタンスを優先します。また、頻度表によって MOTION_INTENSITY の上限を定めます： CALIBRATION.md。

クラフトの基準 — 「完了」の意味と、その順序

誰もがプロンプトだけでプロトタイプを作れる今、最後に残された差別化要因はクラフトだけです。背景情報：デザイナーが「WORD」という言葉から連想するものの順位（Figma、『State of the Designer 2026』、n=906、連想調査 — https://www.figma.com/blog/state-of-the-designer-2026/）：ビジュアルの洗練度 58% · 思慮深い問題解決 47% · 明快で直感的な UX 36% · 感情と喜び 35% · 一貫性 15%。**これらの割合が示すのは、その定義が選ばれた頻度です。58%が証明するのは調査における連想であり、因果関係や作業順序では決してありません。**以下のゲートの順序は依存関係から導き出したもの（前のゲートが満たされない限り、次のゲートには意味がありません）で、このパックが定めた判断であり、調査から導かれた結論ではありません。

1. タスク — ブリーフに記された中核の作業が実際に機能することです。主要タスクが壊れているブリーフでは、トークンが完璧かどうかにかかわらず、まずそれを修正します。
2. 状態 — フローと状態が決定されていることです。決まっていなければ、まず作業を止めて決定します（構造は super-ux の担当範囲の半分です）。
3. 利用可能性 — インターフェースを実際に使えることです。キーボード、コントラスト、テキストの拡大は、このファミリーが委ねる領域であり、決して省略しません。
4. システム — ビジュアルに関する判断が一か所（トークンレイヤー、SCENES レジストリ）にあり、それ以外のすべてがそこから読み取ることです。
5. 仕上げ — 例外なくパックを適用することです。リテラルではなくトークンを使い、差分のどこにも場当たり的な16進数、角丸、フォントサイズを使いません。
6. 感情 — 価値のある動きだけを使うことです（原則4）。1〜5を犠牲にすることは決してありません。
7. 一貫性 — すべての画面で、イージング、時間設定、アクセント、各役割につき1つのアトムを統一することです。

必要に応じて読み込む — パックレイヤーが決めないこと

• シーンの奥行き — 6つのレイヤー（SURFACE_COMPOSITION.md）は、シネマティックなページの CSS を書く前に確認します。すべてを一つの平面に置く失敗は、どんなイージングでも修正できません。

• チャート — 役割の契約と dataviz への引き継ぎは、どのパックでもチャートを描く前に同じファイルで確認します。パック間でトークン名が統一されておらず、未定義のカスタムプロパティはエラーにならず、暗黙のうちにフォールバックするためです。

• モバイルのサーフェス（MOBILE_SURFACES.md）は、ブリーフがネイティブアプリの画面またはモバイルウェブのビューであり、モバイル対応が折りたたみだけのデスクトップページではない場合に確認します。プラットフォームのターゲットとプロトタイプのレンダラーを分けること、ブラウザーのモックアップをネイティブの証明として認めないことを示し、どのパックも答えていない第6のルールも示しています。タイプランプはユーザーのテキストサイズではなく、ビューポートの幅に従います。

• レイアウトとタイポグラフィのクラフト（LAYOUT_CRAFT.md、TYPE_CRAFT.md）は、ページを構成したりタイプランプを設定したりする前に確認します。持ち運び可能な要素は、調整値ではなく観測値です。校正されていない軸は、誰にも検証できない数値です。

• ビジュアルレビュー（VISUAL_REVIEW.md）は、スクリーンショットやレンダリング済みの成果物を承認する前に確認します。フレームを検証し、表示テキストがプロジェクトのポリシーに沿っているかを確認します。

• ビジュアルの最低基準（SLOP_MARKERS.md）は、出荷前にパックの使用有無を問わず確認します。理由と例外を添えたマーカーには、3つのデフォルトの見た目も含まれます。npx sheleg-design-skill --lint <dir> で機械的なチェックを行います。

• ディレクター記録とアワード基準（templates/director-record.md、ADA_RUBRIC.md）は、フラッグシップをレンダリングする前に確認します。--check-record <file> でチェックします。

• 知識の出所（KNOWLEDGE_PROVENANCE.md）は、ルールに異議が唱えられた場合や、コピーされた場合に確認します。

ビジュアル言語の設定 — 不変要素を固定し、軸は開いておく

ブランドを維持したままビジュアル言語を設定または改訂するときは、まず VISUAL_EXPLORATION.md の分割を実行します。固定する不変要素（ブランドカラー、ロゴ、アクセシビリティ）と、開いておく軸（構成、タイポグラフィの階層、コントロールの構造、モーションの目的）を分けます。要件が十分に定まっていない場合は方向性を2〜3案レンダリングし、明確な決定がある場合は1案だけレンダリングします。Figmaをそのまま再現する場合は、何も生成しません。既存のトークンファイルがあるからといって、それだけで何かが確定するわけではありません。

パックの選び方 — 想像するのではなく、適用する

複数のパックが製品に適用できる場合、議論で決めないでください。レンダリングします。

候補のパックを既存の、コンテンツが入ったページに適用します。実際のヘッダー、実際のデータ、実際の情報密度を使用し、?variant=<pack> 検索パラメーターで切り替えて、ブラウザーで見比べます。変わるのはトークンレイヤーだけで、マークアップはそのままです。

プレースホルダーのコンテンツを使った使い捨てのルートは空っぽの状態です。どのパックも問題なく見えてしまうため、何も決まりません。実際にコンテンツの入ったページがまだない場合、選択するのは時期尚早です。要件の方向性に合ったパックでページを作り、切り替えられる実物ができてから見直してください。要件から何の手がかりも得られない場合は、製品UIには workbench、マーケティングページには showroom をデフォルトとします。どちらも落ち着いたデザインなので、後から切り替えても変わるのはレイアウトであり、アイデンティティではありません。（以前は「デフォルトのパック」とだけ書かれていて、名前が挙げられていませんでした。それでは代替案になりません。）

適用にはセマンティックトークンの契約を使用します。 トークン名はパックごとに異なるため、比較で生のCSSを切り替えることはありません。各パックのトークンファイルは @adapter ブロックで終わり、10個のセマンティックロール（--sem-surface、--sem-surface-raised、--sem-text、--sem-text-muted、--sem-line、--sem-primary、--sem-on-primary、--sem-positive、--sem-caution、--sem-negative）をパック独自のトークンに対応付けます。パックに該当する概念がない場合は、ロールを @absent と宣言します。ロールがマッピングも宣言もされていない場合、レンダリング前に比較を中止します。未定義のカスタムプロパティはエラーにならず、気づかないうちにフォールバックするためです。気づかないうちにフォールバックした状態で構築した比較は、結局フォールバック同士の比較になります。CSSを切り替えるという約束はありません。コンポーネントは引き続き、各パック独自のトークンを使用します。

比較で記録する内容と、比較全体が未準備となる条件については、STYLE_PACK_INDEX.mdを参照してください。

比較用ハーネスは足場であり、納品物ではありません。決定を記録する変更と同時に取り除きます。

AI駆動の製品サーフェス

AIサーフェスは通常のサーフェスとは異なります。モデルはストリーミングで応答し、誤ることもあります。インターフェースは、どちらについても誤解を招くことなく示す必要があります。ストリーミング状態、確信度、引用、修正、拒否の形式については、これらの情報を一元的にまとめた AI_PRODUCT_PATTERNS.mdを参照してください。製品にモデルが組み込まれている場合は、こちらを読み込んでください。

コンポーネントレイヤー — パックがトークンを決め、キットがそれを描画します

スタイルパックはトークンレイヤーと一連のルールです。ボタンは含まれません。 そのため、すべてのプロダクト UI では、パックが意図的に決めていない、どのコンポーネントキットでコントロールを描画するかという、もう一つの選択が必要です。

デフォルトは shadcn/ui で、この質問はプロジェクトごとに一度だけ行います。 ux-foundation が Figma について質問するのと同じように、デザイン作業を始める時点で一度だけ尋ね、画面ごとに尋ねることはありません。そして、スタイルパックを記録する場所に回答を記録します。super-ux がインストールされている場合は、画面記録のデザインシステムの行に、インストールされていない場合は、パックを記録するファイルに記入します。デフォルトの回答ははいです。すでにコンポーネントレイヤーがあるプロジェクトは、すでに回答済みです。好みでそれを移行することは、デザイン上の判断ではありません。

競合するのではなく、組み合わせて使います。問題が起きるのはマッピングです。未定義のカスタムプロパティはエラーにならず、黙ってフォールバックします。また、トークンの再マッピングは6つある軸のうちの1つにすぎないため、色だけでキットを組み込んでも、スターターの見た目のまま描画されます。仕組みと作業の担当者については、こちらをご覧ください。 COMPONENT_LAYER.md。

境界 — シネマティックな表面ではなく、プロダクト UI が対象です。 ダッシュボード、管理パネル、社内ツール、チャット、エージェントのインターフェースには適用します。デフォルトの回答は「はい」です。スクロール駆動型のランディングページには適用しません。再利用するコントロールがなく、スクロールや WebGL を使った独自の制作が必要です。コンポーネントキットに手を伸ばすと、ヒーローが設定画面のようになってしまいます。

オプション — Figma（デザイン ↔ コード）

Figma ファイルに触れる場合（パックを変数として公開する場合、またはデザインから構築する場合）は、FIGMA_BRIDGE.md から始めてください。ここでは契約と、ツールを開く前に知っておくべき一つのルールを定めています。フレームはデザイナーやステークホルダーが読むため、フレームに描画することは公開を意味します。また、ファイルを作成するには、推測ではなく、名前を指定した保存先が必要です。

オプション — Claude Design（design-sync）

/design-sync を利用できる場合、パックを claude.ai/design にプッシュして、デザインエージェントが独自のデフォルトではなく、このパックのトークンを使って構築できます。契約とその制約については、こちらをご覧ください。DESIGN_SYNC_BRIDGE.md。

実際の参考事例（Refero、Lazyweb、Mobbin）

パックが決めるのは見た目であり、優れた画面に何を含めるかではありません。新しいデザインやブランドの刷新では、まず実際のプロダクトを幅広く調査します。対象はコンテンツと構造であり、模倣するビジュアルではありません（DESIGN_SYNC_BRIDGE.md §4）。調査で何も見つからなかった場合も記録します。

適用方法と繰り返し起きる問題

パックと調整方法を決めた後の作業順序と、繰り返し起きる失敗の一覧については、こちらをご覧ください。 APPLYING.md。