AIでUIモーフアニメーションを作成する方法
ボタンがローディングインジケーターになり、チェックマークに変化し、チャートへと展開します。ひとつのオブジェクトがシーケンス全体を通して変化し続けるのがポイントです。これが本チュートリアルの狙い：関連性のない画面を切り替えることなく、小さなプロダクトインタラクションを見せるUIモーフアニメーションの作り方を解説します。
この例はiArtでHaiku 5.5を使って作成し、2回リビジョンを行いました。最初のバージョンではチャートのラベルが切れていました。次のバージョンでレイアウトを修正しましたが、動きが遅く感じられました。最終的なアニメーションは8秒で、遷移が速くなり、チャートの保持時間も読みやすくなっています。
本記事では使用したプロンプト、問題点、そして実用的な結果に至ったタイミング調整について解説します。例に登場する分析アプリ「Pulse」は架空のもので、サインアップ数値もサンプルデータです。
作成するもの
アニメーションは短いインタラクションを追います：レポートを見る → ローディング → 成功 → 週間サインアップ数 → レポートを見る。中央のコンテナがサイズ、角丸、色を変化させます。内容も各状態に応じて変わります。
この形式は、レポートの読み込み、決済完了、プロダクト機能の紹介動画などに応用できます。出力は動画デモであり、実際に動作するUIやインストール可能なコンポーネントではありません。今回のテストではAnimationモード、16:9キャンバス、2026年10月22日時点のiArtで選択できるHaiku 5.5を使用しました。ナレーション、音楽、生成映像は依頼していません。
始める前に3つ準備しましょう：表示したい状態、正確なテキストとデータ、シンプルなビジュアル指示。今回のブリーフではオフホワイト背景、ダークUI、アクセントカラー1色を指定。チャート値は24, 38, 31, 52, 46, 68, 84で、月曜から日曜までラベル付けしました。
1. 連続して変化するオブジェクトを記述する
iArtのAnimationモードを開き、モデルを選択します。本例ではHaiku 5.5を通して使用しました。他モデルとの比較や実行コストの計測は行っていません。
プロンプトで重要なのは、状態間の関係性、つまり同じコンテナが形を変えることです。「ボタンのシーンの後にチャートのシーン」とだけ指示すると、カットやクロスフェードになることも。どのオブジェクトが持続し、内部で何がいつ変わるのか、どこで読み取り時間が必要かを明示しましょう。
以下は、英語で実際にテストした元のプロンプトの日本語訳です。後の修正と比較できるように、15秒の指示を残しています。
架空の分析アプリ「Pulse」のための15秒間のシームレスなUIモーフアニメーションを16:9で作成してください。中央のダークな角丸コンテナが連続的に形を変えます：0～3秒は「View report」とラベルされたボタンにカーソルクリック、3～5秒は同じコンテナが円形のローディングスピナーに縮小、5～7秒で緑色の成功チェックに、7～12秒で「Weekly signups」とタイトルされたクリーンな分析カードに展開し、7本のバーにMon–Sunのラベルと値24, 38, 31, 52, 46, 68, 84を表示、12～15秒で元のボタンにスムーズに戻り、最初と最後のフレームが一致。温かみのあるオフホワイト背景、ほぼ黒のUI、エメラルドのアクセント、シャープなタイポグラフィ、抑制されたスプリングモーション。モーフは明確に連続しており、シーンのクロスフェードではありません。全てのラベルは読みやすく、テキストの重なりや切れがないように。ボイスオーバー、音楽、ストック映像、生成画像や動画は不要。アニメーションを直接構築してください。iArtは指定した状態でプレビューを生成しました。これで有用な出発点が得られましたが、「切れなし」と指示してもレイアウトが正しいとは限りません。
2. アニメーションを評価する前にチャートを確認
約10秒地点で、最初のプレビューはチャートの下端が切れていました。曜日ラベルが見えません。形の遷移はできていましたが、データが正しく伝わりませんでした。
生成されたチャートを確認する際は、全ての値がブリーフ通りか、ラベルがコンテナ外に出ていないかをチェックしましょう。安定したチャートだけでなく、展開・縮小中のフレームも確認を。フルサイズで収まっていても、遷移中に切れることがあります。
以下は最初の修正依頼の日本語訳です。見えている問題を特定し、データを保ったまま配色の変更も依頼しました。
10秒時点のプレビューで実際のレイアウトバグがあります：チャートの下部が切れており、Mon–Sunの曜日ラベルが見えません。チャートのレイアウトを修正し、7つの値と7つの曜日ラベルがすべてカード内に24px以上の下パディングを保って完全に表示されるようにしてください（8～12秒のチャート保持中）。また、縮小前の空カードのポーズを削除し、チャート内容が見えたままモーフ開始時にフェードアウトし、切れがないようにしてください。デザイン、データ、15秒の長さ、最初と最後のフレーム一致は維持。アクセントカラーをエメラルドからバイオレット #7C3AEDに変更し、チャット編集も検証できるように。音声や生成メディアは不要。9, 10, 11, 12, 13秒のフレームを確認してから仕上げてください。
リビジョン後のプレビューでは、7つの値と曜日ラベル（Sundayの84も含む）がすべて表示され、色変更も反映されました。これでレイアウト不良に邪魔されず、テンポを評価できるようになりました。チャート中心の例はiArtのアニメーションチャートもご覧ください。
3. 遷移を短縮し、読み取り時間は確保
次のフィードバックはシンプルでした：遷移が遅く感じられる。元のブリーフではボタン、ローディング、確認状態に数秒ずつ割り当てていたため、情報にたどり着くまでが長すぎました。
シーン全体の長さを15秒から8秒に短縮しました。さらに重要なのは、シーケンス内の各部分に異なる役割を持たせたことです：遷移は素早く、完成したチャートは十分な時間静止させて読めるようにしました。
| リビジョン後の時間 | アクション | 目的 |
|---|---|---|
| 0～0.55秒 | ボタンとカーソル到着 | 長い待機なしでアクションを提示 |
| 0.55～0.90秒 | ボタンがローダーに縮小 | クリックに即座に反応 |
| 0.90～2.05秒 | ローディング→確認 | 状態変化を認識できるが短く |
| 2.05～3.20秒 | コンテナ展開、バーとラベル登場 | 一連の動きで結果を提示 |
| 3.20～6.65秒 | チャート保持 | 7つの値を比較する時間を確保 |
| 6.65～8秒 | ボタンに戻り安定 | 空カードの長いポーズなしで終了 |
これらのタイミングはこの小さなデモ用のブリーフであり、UIアニメーションの普遍的なルールではありません。より大きなUIや複雑なチャートでは、さらに読み取り時間が必要です。
以下は同じプロジェクトに送ったタイミング調整の指示の日本語訳です。
ユーザーフィードバックとして、遷移が遅く分断的に感じられるとのことです。タイミング調整：アニメーション全体を8秒に短縮し、実際にシーンの長さを変更してください（再生速度変更ではなく）。バイオレットのデザイン、正確なチャートデータ、修正済みの読みやすいレイアウトは維持。スケジュール：0～0.55秒はボタンと素早いカーソル到着、0.55秒でクリックし、0.55～0.90秒で即座にボタンをローダーにモーフ、0.90～1.45秒はスピナー、1.45～1.70秒で成功チェックにモーフし2.05秒まで保持、2.05～2.50秒で同じコンテナをチャートに展開、3.20秒までに全バーとラベルが40msずつずらし300msで登場、3.20～6.65秒はチャートを完全に保持、6.65～7.15秒でボタンに縮小し内容はモーフ中にスケール/フェード、7.15秒でボタンテキスト復帰、7.15～8秒は最初のフレームと完全一致で静止。形の遷移は250～450msでease-out cubicと抑制された収束、長いリニアトゥイーンや空カードのポーズ、状態間のフェードアウトは不要。カーソルは明確にクリックし、即座にモーフを開始すること。音声・メディア不要。0, 0.75, 1.2, 1.9, 2.3, 3.3, 6.8, 7.3, 最終フレームを確認し、切れや隙間がないか明示的にチェックしてください。更新後のプレイヤーは通常再生速度で8秒の長さを表示しました。1秒付近でローダー、3秒付近で完成チャートを確認。7つの値と曜日ラベルは読みやすいままでした。
イージングと長さは異なる問題を解決します。長さは動きの継続時間、イージングはその中での進行の変化を制御します。実装を理解したい場合は、Remotionの補間ドキュメントやイージングリファレンスが参考になります。チャットで意図するタイミングを記述でき、関数自体を書く必要はありません。
4. 通常速度で結果を確認する
スクリーンショットでテキストの可読性は確認できますが、動きの滑らかさまでは分かりません。1倍速で再生し、クリックの瞬間、ローダーからチェックへの遷移、カード展開、ボタンへの戻りを確認しましょう。
- アクションと反応：カーソルクリック時に形が変化し始めるか？
- 連続性：コンテナを状態間で追えるか、それとも消えて置き換わってしまうか？
- 読み取り：チャート保持前に全ての値が登場し終えているか？
- 戻り：縮小時に内容が一緒に消え、空カードの目立つポーズがないか？
- ループ：終了時が開始時と一致しているか（カーソルやテキスト含む）。フレーム一致を求めても、必ずしもシームレスなループになるとは限りません。
最終プレビューはシンプルで実用的なUIデモです。ただし、どんなプロンプトでも一発で洗練された動きになるとは限りません。タイミングリビジョンも自動修正を経て動作するプレビューが生成されました。フレーム単位の滑らかさ測定や最終フレームのループ継ぎ目の独立検証は行っていません。
5. 実際に確認したバージョンを書き出す
プレビューが完成したら、エクスポートを開き解像度を選択します。アニメーションを後から変更した場合は、必ず最新版を書き出してください。
最終的な8秒バージョンは720pで書き出し、この記事冒頭に埋め込みました。Web版は1280×720、30fps、H.264動画で音声トラックなしです。エディタのプレビューだけでなく、書き出したファイルも必ず確認しましょう。
この演習を応用するには、サンプルアプリ名やラベル、数値を自分のものに置き換え、状態遷移は短く保ちます。より長いストーリーにはプロダクトローンチ動画の作り方ガイドもご覧ください。
FAQ
このアニメーションを作るのにコードを書く必要はありますか？
この例はiArtのチャットインターフェースで作成・修正しました。生成されたアニメーションコードを手動で編集することはありませんでした。重要なのは状態の指定、プレビュー確認、具体的な修正指示です。
どのモデルをテストしましたか？
2026年10月22日時点のiArtで選択できるHaiku 5.5を、初回生成と2回のリビジョンすべてで使用しました。これは1つのプロジェクトであり、モデル間の比較や信頼性ベンチマークではありません。
最初のバージョンが遅く感じたのはなぜですか？
15秒のブリーフでは、初期状態や遷移に対してこのシンプルなインタラクションには長すぎました。全体を8秒に短縮し、形の変化を速め、チャートの読み取りには3秒強を確保しました。
これは実際のインタラクティブなプロダクトUIを作成しますか？
いいえ。この例はインターフェースのアニメーション動画を作成します。ボタンやカーソル、チャートはプロダクトフローを示すものであり、実際に動作するダッシュボードやデプロイ可能なUIコンポーネントではありません。
プロンプトを他のデータで再利用できますか？
はい。サンプルのラベルや値を置き換え、再度結果を確認してください。ラベルが長くなったり、数値やバーが増える場合はカードレイアウトや読み取り時間の調整が必要になることがあります。