アプリを「速く感じさせる」4つの動きのルール：ease-out・300ms以内・独自イージング・スピナーを速く
実際の読み込み時間はそのままでも、UIの反応と動きの設計だけで「速いアプリ」に感じさせる。ease-inはやめてease-out、ほとんどのUIアニメは300ms以内、スピナーは速く回す。
どんな問題を解決するか / いつ使うか
AIやエージェントに動きを任せると、ease-inでゆっくり始まり、長めのトランジションや遅いスピナーになりがちで、操作がもたついて感じるとき。公開前のモーション点検や、AIが作ったアプリの「もたつき」は動きの盛りすぎ。先に消して、残った動きだけを整えさせるプロンプトのあとに残す動きの基準に使う。
具体手順
エージェントや自分のCSS／モーション指定に、次の4つをルールとして書く。
- フィードバックには ease-out を使う（ease-in は使わない）
タップやホバーの直後はすぐに動き始め、終わりで減速する。ease-inだと「押したのに反応が遅い」と感じやすい。 - ほとんどのUIアニメは 300ms 以内
画面遷移や大きな演出以外の、ボタン・メニュー・トーストなどは短く。 - スナップの効いた操作には独自のイージング曲線を使う
既定の ease だけに頼らず、立ち上がりが速い曲線を指定する（投稿の動画ではカスタム曲線の比較あり）。 - ローディングスピナーは速く回す
同じ待ち時間でも、遅い回転より速い回転の方が処理が進んでいる印象になる。
コーディングエージェント向けの一文例：
Make interactions feel snappy: use ease-out (not ease-in) for feedback,
keep most UI animations under 300ms, use a custom easing curve for
primary interactions, and spin loading indicators faster.注意点
- 「速い」と「せわしない」は違う。説明用の長いストーリーボードや、複数の要素を一緒に動かすときは、役割（主役・脇役・飾り・静止）を先に決める：Emil Kowalski の /choreograph スキルでは、主役以外を短く・脇役を控えめに保つ。
prefers-reduced-motionがオンのときは動きを減らす・止めるルールもセットで書く（AIに動きを頼むときは、見た目の名前に加えて「描画コスト・対応ブラウザ・reduced-motion」まで指定する）。