kf-g-css-tak-animations

这段内容是审核时保存的快照。外部来源才是完整且最新的版本。

---
name: kf-g-css-tak-animations
description: UI animations necessity judgment, recommendations for motion design, implementation strategies, and performance/accessibility reviews. Targets include hover, active, focus, popover, tooltip, dropdown, dialog, tab, segmented control, card, button, toast, accordion, carousel, scroll-linked animation, View Transitions, and more.
---

# Animations Skill

以下のようなタスクでこの Skill を使うこと。

- UI にアニメーションを追加する
- モーションデザインの品質をレビューする
- hover, popover, tooltip, dropdown, dialog, tab, segmented control, card, button, toast, accordion, scroll-linked animation, View Transitions などの動きを改善する
- アニメーションを削除すべきか判断する
- property, easing, duration, transform-origin などを選定する
- `prefers-reduced-motion` を尊重すべきかどうかを判断する
- `@starting-style`, `transition-behavior`, `interpolate-size` などの出現・退場アニメーション手法を選定する
- `@keyframes` の命名規則・スコープ管理・API 的カスタムプロパティ設計を行う

---

## 基本原則

1. アニメーションは目的ではなく手段である
1. そのアニメーションが「機能的」か「装飾的」かを常に区別する
1. 最良のアニメーションは「アニメーション無し」である場合もある
1. UI の動きは速く、応答的に感じられるべきである。ユーザーが求めているのは「すぐ反応した」という知覚速度である
1. 高頻度で操作される UI では装飾的なアニメーションを避ける
1. イージングはアニメーションにおいて最重要である。同じ duration でもイージング次第で体感速度は大きく変わる
1. 視覚変化はトリガーとの因果関係が感じられるべきである
1. 複数の視覚変化を同期させたい場合、個別の `transition` では不十分なことがある。`@keyframes` animation、Web Animations API、あるいは CSS トランジションと `transition-behavior` の組み合わせなど、適切な手法を選ぶこと
1. アニメーションはパフォーマンスに大きく影響する
1. アクセシビリティのため、`prefers-reduced-motion` を尊重しているユーザーにどう見せるかを常に考える

## 必須の評価順序

### Step 1: そのアニメーションは必要か？

必ず次を確認する。

- この動きは何の問題を解決するのか
- 状態、因果関係、フィードバックを明確にしているか
- 機能的なのか、装飾的なのか
- ユーザーはどれくらい頻繁にこれを見るのか
- キーボード操作や高速操作の邪魔にならないか

#### 判断基準

| 目的                               | 判断               | 例                                             |
| ---------------------------------- | ------------------ | ---------------------------------------------- |
| 状態遷移の因果関係を示す           | 必要               | アコーディオン開閉、タブ切替                   |
| ユーザーの注意を新出要素に誘導する | 必要               | toast 通知、バリデーションエラー               |
| 操作のフィードバックを返す         | 必要               | ボタンの `:active`、チェックボックスのチェック |
| 空間的連続性を保つ                 | 条件付き           | ページ遷移の View Transitions、ドリルダウン    |
| ブランド個性の表現                 | 低頻度 UI のみ許容 | LP のヒーロー、初回訪問のオンボーディング      |
| 単に見た目の華やかさ               | 高頻度 UI では不要 | ダッシュボードのカードがスライドして現れるなど |

強い理由がない場合は、削除を提案すること。

### Step 2: どの実装形が適切か？

#### Step 2A: イージング・タイミングの選定

**イージング**

- `ease-in` 系や `linear` 系は物理的に不自然で機械的な印象を与えがちである。`linear` は一定速度を表現したい連続運動（marquee やプログレスバー）にのみ適用する。
- 出現・退場では `ease-out` 系を使用する
- すでに画面上にあるものの移動では `ease-in-out` 系を使用する
- CSS 標準のイージングキーワード（`ease`, `ease-in-out` など）はメリハリが弱い。プロジェクトにアニメーショントークンがある場合はそれを参照し、`quint` 系か `expo` 系のイージングを使用する
  - トークンが存在しない場合は以下を推奨する

```css
/* ease-out 系（出現・退場向き） */
--ease--out-quint: cubic-bezier(0.22, 1, 0.36, 1);
--ease--out-expo: cubic-bezier(0.16, 1, 0.3, 1);

/* ease-in-out 系（移動向き） */
--ease--in-out-quint: cubic-bezier(0.86, 0, 0.07, 1);
--ease--in-out-expo: cubic-bezier(0.87, 0, 0.13, 1);
```

- 全てのプロパティに同一の `transition-duration` と `transition-timing-function` を適用するのは雑である。プロパティごとにカーブを選び分けること

**タイミング**

- 例外: dialog, drawer, sheet など大型 UI の遷移は `300ms〜500ms` を許容する
- 日常的に何十回も触る UI では、1 回あたり `100ms` の差でも体感負荷が大きくなる

#### Step 2B: transform-origin と空間的整合性

- `transform-origin` は常にトリガーとの位置関係を考慮して設定する
- Popover はトリガー要素を起点として拡大・縮小させる。デフォルトの `center` は多くの場合に不適切である
  - CSS Anchor Positioning を使用している場合は、Popover の配置方向に応じて `transform-origin` を動的に切り替えることを検討する
- `scale: 0` からのスケールインは物理的に不自然である。「そこにあったものが少し離れた位置から立ち上がる」ほうが自然であるため、要素のサイズに応じた起点値を選ぶこと

| 要素種別              | スケールイン起点 |
| --------------------- | ---------------- |
| tooltip, popover      | `0.95〜0.98`     |
| dropdown menu         | `0.92〜0.96`     |
| dialog, drawer, sheet | `0.85〜0.92`     |

#### Step 2C: インタラクション種別ごとの指針

**ホバー**

- ホバーの視覚変化は `150ms〜200ms` を目安とする
- タッチデバイスでは hover が存在しないため、`@media (any-hover: hover)` で切り分けることを検討する
  - カレントリンクなど `href` が存在しないアンカーリンクでホバーが起こるのは避ける。必ず `:any-link:hover` のように定義すること
  - 有効ではないボタンでホバーが起こるのは避ける。必ず `:enabled:hover` のように定義すること

**active（押下フィードバック）**

- ボタン等の押下時