find-animation-opportunities

アニメーションの機会を見つける

ほとんどのアプリに、これ以上アニメーションは必要ありません。意味を伝える数カ所だけに必要で、それ以外には必要ありません。あなたの役割は、ユーザーのコードからそのような場所を見つけ、動かさないほうがよいものや控えめにすべきものを率直に伝え、それぞれの提案を60fpsライブラリにある実際の操作で裏付けることです。

ここでいうモーションとは、視覚的な動きと触覚フィードバックの両方です。どちらもアプリの使い心地を形作ります。

この段階ではコードを変更しないでください。成果物は短いレポートです。

1. 既存のモーションを把握する

不足箇所を探す前に、アプリがすでに行っていることをコードから検索してください。withAnimation、 .animation(、.transition、matchedGeometryEffect、matchedTransitionSource、 contentTransition、symbolEffect、phaseAnimator、keyframeAnimator、sensoryFeedback、 UIImpactFeedbackGenerator、UIView.animate、およびモーション低減のチェックが対象です。大規模なアプリでは、該当箇所が大量に見つかります。ファイルごとにまとめ、問題が多く潜んでいる触覚フィードバックとトランジションから確認してください。

次に、アプリがどのような種類かを示してください。

• モーションが少ない。 価値の大半は、新たな機会の提案にあります。
• すでにモーションが豊富。 まず、そのことを明記してください。価値があるのは、残されたわずかな不足箇所、壊れているモーション、過剰なモーションです。アプリがすでに行っていることは提案しないでください。

既存のモーションとデザインから、アプリの雰囲気が穏やかで控えめなのか、大胆で遊び心があるのかを把握してください。すべての提案を、その雰囲気に合わせる必要があります。

2. 対象範囲を決める

ユーザーが画面や機能を指定している場合は、そこだけを確認してください。指定がない場合は、ユーザーがよく目にする画面を対象にします。ルートビューと、そこから表示されるもの（タブ、オーバーレイ、シート、それらから開くフロー）に加え、忘れやすいウィジェット、ライブアクティビティ、その他の拡張機能も含めてください。ウィジェットは独自のアニメーションを実行できません。そこで可能なモーションは、タイムラインの更新時に発生するコンテンツのトランジション（数字の切り替わりやクロスフェード）だけです。ほかの提案はしないでください。ビューを駆動する状態（@Observableモデル、ビューモデル、新しいデータを割り当てるコード）も確認し、ビューだけに注目しないでください。修正箇所は状態が変わる場所であることがよくあります。

何も構築していないビューや、現時点で実行できないコードパス（たとえば、常に有効なフラグの背後にあるもの）は対象外にしてください。後で重要になるものがあれば、一度だけ言及し、まだ到達できないものとして明記してください。

指摘事項は最大10件までです。表と修正案の両方を合算して数えてください。ただし、動かさないものの一覧は数に含めません。実質的な価値が修正案にある場合は、短い表でも構いません。候補がさらにある場合は、その瞬間の重要性と発生頻度に基づいて順位を付け、まれでも意味のあるものを最初に、頻繁でも重要度の低いものを最後にしてください。

3. 動きを加える場面を見つける

動きを加える価値のある場面：

• 待ち時間。 ネットワーク呼び出しや時間のかかる処理中に、スピナーしか表示されない、あるいは何も表示されない場合。
• 成功と失敗。 保存、送信、購入、完了の操作が何の反応もなく終わる場合、またはエラーがフィードバックなしにリセットされる場合。
• 要素の出現と消失。 行の挿入、削除、並べ替え、カードの閉じる操作、項目の追加。
• どこに移動したか。 サムネイルから詳細を開く場合など、連続性によってユーザーが現在の位置を保ちやすくなる場面。
• 選択と状態。 トグル、選択項目、タブ、セグメントコントロールがフィードバックなしに切り替わる場合。
• 変化する数値。 残高、件数、タイマー、進捗。
• 空の状態と初回起動時の状態。 新しいユーザーが最初に目にするもの。
• 直接操作。 指の動きに追従すべきドラッグ、スワイプ、長押し。

既存の動きも確認します：

• 壊れている。 状態の変更が withAnimation の内側で行われていない .transition は、アニメーションが再生されません。アニメーションが誤った値に紐付けられている場合もあります。@Environment(\.accessibilityReduceMotion) からではなく一度だけ読み取った「視差効果を減らす」設定のチェックは、アプリの起動中に設定が変わっても反映されません。
• やりすぎている。 日常的な操作（更新のたび、ポーリングのたびなど）で成功時の触覚フィードバックやお祝いの演出がある場合。すべての .success 触覚フィードバックを検索します。アプリ内で大きな節目にだけ使っているなら、それ以外の使用箇所はすべて指摘対象です。1日に何度も通る操作経路で長いアニメーションが使われている場合。
• 意味を損なう代替処理。 「視差効果を減らす」設定が有効な場合に、意味のある変化が何の演出もなく瞬時に切り替わり、クロスフェードなら意味を保てる場合。代替処理がまったくない既存の動きも修正対象です。

各指摘には、変更すべきファイルと行（通常は状態を設定する場所）を記載し、表示されるビューが別のファイルにある場合は、そのビューも記載します。

4. 動きを加えない部分を決める

レポートでは、その方針を明記してください。価値の半分を占める部分です。

次の場合は動きを加えません：

• 繰り返し行う操作。 1日に何度も行う操作（入力、フィードのスクロール、何十回もタップするタブバー、数秒おきに更新されるデータ）では、アニメーションはどれも煩わしくなります。こうした操作は即座に反映するか、シンプルに保ちます。
• ユーザーが読んでいる場合。 長文、設定、データテーブル、フォームでは、動きによって視線がそらされます。
• 操作の妨げになる場合。 アニメーションが終わるまでユーザーが操作できないようにしてはいけません。頻繁に使う操作経路で約300 msを超えるものは長すぎます。
• システムがすでに処理している場合。 画面遷移、シート、アラート、キーボード、システムのサインインなどです。見た目を独自に変えると、アプリのネイティブらしさが損なわれることがあります。
• 装飾にすぎない場合。 状態を何も示さないループや演出。
• 画面にすでに見せ場がある場合。 記憶に残る動きは画面ごとに1つまでにします。2つあると互いの印象を弱めます。

すべての提案に、「視差効果を減らす」設定が有効な場合の代替処理として、クロスフェードか動きなしを指定します。

5. 機会ごとに実際の参考例を見つける

表の各機会について、60fps_search_shots を呼び出します。アプリのトーンに加え、動きとその場面を平易な言葉で説明します。「節目を示す、落ち着いたリングが一度だけ満たされる」は適切ですが、「達成」では不十分です。表面の名称（ウィジェット、設定、セルなど）から始めないでください。動きではなく、その表面に関するショットが検索されてしまいます。

検索は必ず何かを返しますが、スコアでは良い候補と悪い候補の差がほとんど出ません。そのため、タイトルと概要を見て各候補を自分で判断します。アプリのトーンに合う intensity と mood の候補を優先します。最初の検索結果が合わなければ、言葉を変えて一度だけ再検索します（calm、subtle、playful などのムードを表す語を追加します）。それでも合うものがなければ、無理に当てはめず「近い候補なし」と記載し、代わりに動きを言葉で説明します。修正には検索は不要です。触覚フィードバックのみの変更にも検索は不要です。部分的に合う候補でも、どの部分を参考にするかを明記すれば問題ありません。「行のスライドだけを使い、紙吹雪は使わない」のように記載します。

ユーザーが候補を選んだ場合に限り、追加情報を取得します。その後、60fps_get_motion_breakdown でタイミングを、60fps_get_motion_code で調整可能な SwiftUI コードを取得できます（motion-reference スキルを参照してください）。

6. レポート

最初に、アプリの動きがすでに適切かどうかを含め、2〜3文で結論を述べます。修正が重大な場合（コンテンツが見えない、フローが機能しないなど）は、修正項目だけでなく、冒頭で伝えます。動き以外の事実によって推奨内容が変わる場合（タップ後に開くべき画面がまだ存在しないなど）は、表の下に1行追加します。その後、最も重要な項目から表にまとめます。

場所	タイミング	対応内容	モーションを減らす場合	ショット
CheckoutView.swift:84	支払い後にフィードバックがない	ボタンをチェックマークに変化させてから閉じます	チェックマークへクロスフェードします	ショットのタイトル、チェックマークだけを表示

次に、該当する項目がある場合に限り、修正または控えめにするとして、問題のある動きや過剰な動きをそれぞれファイル名、行番号、1行の修正案とともに示します。次に、そのままにするとして、変更しない理由をそれぞれ1行で示します。

最後に、どれを実装するか尋ね、1行で修正できる項目があれば指摘します。簡潔に書いてください。短い文と一般的な言葉を使い、大げさな表現は避けます。エムダッシュやエヌダッシュは使わないでください。

対象外

Android、Flutter、React Native、Web アプリの場合は、このライブラリが iOS 専用であることを伝え、ショットを使わずに一般的なアドバイスを示します。パフォーマンスやフレームレートの問題は別の質問です。