AI動画からフレームを抽出する方法

スクロール連動のcanvasアニメーション用にAI動画からフレームを抽出するには、5段階のパイプラインを実行します:ループ可能なクリップを生成する、FFmpegでクリップを連番のフレームシーケンスに書き出す、それらのフレームを選別してWebPに変換する、drawImage()で現在のフレームをHTMLの<canvas>に描画する、そしてGSAP ScrollTriggerを使ってスクロール位置からフレームのインデックスを制御する、という流れです。結果として得られるのは、Apple風の「スクラブ」効果——スクロールするとカクつく<video>要素の代わりに、canvas上でクリップが1フレームずつ再生される仕組みです。

競合するチュートリアル(Codrops、Builder.io、Tympanus)はどれも、すでに手元にある動画ファイルから始まり、FFmpegとGSAPの後半部分しか教えてくれません。Astorieは上流の工程を1つのノードベースのキャンバスにまとめます:開始・終了フレームの制御で完璧にループするAIクリップを生成し、フレームを抽出・選別し、必要ならキービジュアルとなるフレームを4K化する——これらすべてを、コードを1行も書く前に完了できます。GSAPに渡す成果物は、ぼやけた画面録画ではなく、きれいに重複を取り除いたWebPシーケンスです。

このパイプラインは左から右へ4つの工程として読めます:(1) Astorieのキャンバス上で動画モデルを使ってループを生成する、(2) フレームシーケンスを抽出する(キャンバス内でのフレーム抽出、または後述のFFmpegによる代替方法)、(3) キービジュアルとなるフレームを選別し、必要に応じてアップスケールする、(4) GSAP ScrollTriggerでシーケンスを<canvas>にレンダリングする。1〜3はキャンバス上で行うクリエイティブな作業であり、4が実際にリリースするコードです。以下の各セクションでは、そのままコピー&ペーストできるコマンドとともに各段階を解説します。

ループ時にクリップがジャンプカットしてしまうと、スクロールスクラブは破綻して見えます。そのため元の動画は綺麗にループする必要があります。Astorieのキャンバス上で動画ノードを配置し、開始フレームと終了フレームの両方を制御する機能を使います:同じ画像を開始フレームと終了フレームの両方に設定すると、モデルは出発点に戻ってくる動きの軌道を補間します。開始・終了フレームの条件付けに対応しているモデルにはKling、Luma、Runway、Seedanceがあります。VeoやSora、Wanのようなテキストから動画を生成するモデルは、シームレスなループが不要なクリップに向いています。

プロンプトと開始・終了フレームを複数の動画ノードに一度に接続して、一括展開を実行します:1枚の元画像を同時にKling 3、Seedance 2、Runway Gen-4へ送り、それぞれのテイクをバージョントレイに残して、最もきれいにループするものを選びます。これは競合が裸の動画ファイルからではできない部分です——あなたは抽出の前に最良の素材を選んでいるのであって、すでに撮影済みの何かをやりくりしているのではありません。

クリップは短く、動きは連続的に保ちましょう。24-30 fpsで3〜5秒のループはおよそ72〜150枚の元フレームを生成し、これはスクロールシーケンスに適した枚数のオーダーです(ステップ3で間引きます)。クリップ内でのハードカット、速いパン、強いモーションブラーは避けてください。動いている間は問題なく見えても、ユーザーがスクロールを途中で止めて1フレームで静止した瞬間にぼやけて見苦しくなります。

クリップを静止画にする方法は2つあります。Astorieのキャンバス上で、承認済みの動画をフレーム抽出ツールノードに送り、スクラブして個別のキービジュアルフレームを収集する方法——画像編集チェーンや次のショットの開始フレーム用に、少数のきれいな静止画が欲しいときに素早く使えます。スクロールスクラブ用に等間隔の完全なシーケンスが必要な場合は、クリップを書き出してFFmpegを実行します。これは開発者向けの検索結果が当然のように期待する事実上の標準的な方法です。

以下のコマンドは、元のフレームごとに連番のPNGを書き出します。-vf fps=30を使うと、クリップ本来のフレームレートに関係なく固定の秒間30フレームに再サンプリングでき、インデックスをゼロ埋めすることでファイルが正しい順序に並びます。まずPNGにすることで抽出を無劣化に保ち、次のコマンドでWebPに変換します。

PNGシーケンスをWebPに変換すると、スクロールスクラブのサイズであれば目に見える画質劣化なしにデータ量を60〜80%削減できます。実際にブラウザへ渡すのはWebP形式です——150フレームのPNGシーケンスは40MB以上になることがありますが、同じシーケンスを品質80のWebPにすると多くの場合8MB未満に収まります。cwebpでディレクトリ内を一括変換するか、FFmpegに直接WebPを出力させましょう。

完成したシーケンスは、Next.jsプロジェクトのpublic/frames/以下に配置し、安定してキャッシュしやすいパス(例:/frames/frame_0001.webp)から配信されるようにします。連番でゼロ埋めされたファイル名にしておけば、ステップ4で単純な文字列の埋め込みだけで任意のインデックスのURLを組み立てられます。

AI動画には甘いフレームが含まれます:モーションブラーのかかった中割りフレーム、時折発生する歪み、まれなアーティファクトなどです。シーケンスをリリースする前に、Astorieのキャンバス上にフレームを並べて選別しましょう——ぼやけたフレームを削除し、くっきりしたフレームを残し、ループの最初と最後のフレームが一致していてスクラブがきれいに繋がるかを確認します。150フレームの書き出しをきれいな90フレームまで間引くことで、ブラウザが事前読み込みするデータ量も軽くなります。

キービジュアルとなるフレームが画面いっぱいの幅で静止表示される場合——タイトル表示の瞬間や商品のクローズアップなど——は、4KにアップスケールしておくとRetinaディスプレイでもシャープさを保てます。選んだフレームをアップスケールツールノードに通し、結果をシーケンスに戻します。解像度の計算やユースケース別のガイドは、姉妹ガイド「画像を4Kにアップスケールする方法」を参照してください。単一フレームではなくクリップ全体をアップスケールしたい場合は「動画を4Kにアップスケールする方法」を参照してください。

参照品質のきれいなフレームは、スクロールスクラブ以外にも再利用できます:Nano Banana 2の画像編集チェーンに戻したり、次の動画ノードの開始フレームとして使い、次のショットに全く同じ見た目を引き継がせたりできます。これはクリップを延長する際に使うのと同じフレーム収集のテクニックです——最後のきれいなフレームを抽出し、次の画像から動画への生成の開始フレーム入力として使います(「動画クリップを延長する方法」を参照)。

ここからはコードの部分です。WebPシーケンスをImageオブジェクトの配列として事前読み込みし、drawImage()で現在のフレームを<canvas>に描画し、GSAP ScrollTriggerにスクロールの進捗をフレームのインデックスへマッピングさせます。ユーザーが縦に長い固定セクションをスクロールすると、インデックスが0から最後のフレームまで進み、canvasが再描画されます——これがスクラブの全てです。

シャープなスクラブと、ぼやけて残像の残るスクラブを分ける細部が2つあります。1つ目は、window.devicePixelRatioに合わせてcanvasを拡大し、Retina画面でもネイティブ解像度で描画されるようにしてからCSSでサイズを縮小することです——高DPI画面で論理ピクセルのまま描画すると画像がぼやけます。2つ目は、drawImage()のたびにctx.clearRect()を呼ぶ(またはcanvas全体を覆う不透明なフレームを描画する)ことです。そうしないと半透明のフレームが重なって残像が残ります。

以下のコードは、この仕組みを支える基本パターンです:render(index)関数、setupCanvas()ヘルパー内でのdevicePixelRatioによる拡大、描画のたびに呼ばれるclearRect、そしてonUpdateでself.progressを最も近いフレームにスナップさせるScrollTriggerです。frameCountと/frames/のパスは、ステップ2での書き出し内容に合わせて調整してください。

スクロールスクラブの本質はプリロードの問題です。ブラウザは途切れなく再描画できるだけのフレームを取得する必要があるため、フレーム数はデバイスに応じて調整します:デスクトップではおよそ90〜150フレーム、帯域とメモリがより厳しいモバイルでは間引いて30〜60フレームです。スマートフォンにデスクトップ用のシーケンスを無理に読み込ませるのではなく、小さいビューポート向けには別途小さいWebPセットを配信しましょう。

プリロードは方向性を持たせ、段階的に行いましょう。最初の10〜20フレームを積極的に読み込んでセクションをすぐに操作可能にし、残りはバックグラウンドでストリーミングします。ユーザーが下にスクロールしていると分かっている場合は、均等にではなく現在のインデックスより先を優先的にプリロードします。対応している環境ではcreateImageBitmap()を使ってメインスレッド外でフレームをデコードし、drawImage()がスクロールをブロックしないようにします。

データ量の面で大きく貢献しているのがWebPです。品質75〜85であれば1フレームあたりのサイズは十分小さく、150フレームのデスクトップ用シーケンスでも1桁台のメガバイトに収まります。これによって、長い空白状態を作らずに積極的なプリロードが可能になります。それでもシーケンスが重く感じる場合は、画質を下げる前にフレーム数を減らしましょう——人間の目は、スクロール途中で止まった甘い低画質のフレームよりも、フレーム数が少ないことのほうがずっと許容できます。

GSAPを<video>に向けてスクロールからcurrentTimeを設定することもでき、開発機では問題なく見えます——しかし実機ではカクつきます。ブラウザは動画をフレーム精度でシークしません:currentTimeを設定すると最も近いキーフレームにスナップされるため、強く圧縮されたクリップをスクラブするとジャンプしたりガタついたりします。モバイルブラウザは自動再生ポリシーの下でプログラムによる再生を制限またはブロックすることもあり、スクロールのたびにキーフレームをデコードするのはコストが高くつきます。

canvas画像シーケンスはこの問題すべてを回避します。各フレームは独立した完全にデコード済みの画像なので、render(index)は構造上フレーム精度になります——47%までスクロールすれば、キーフレームへのスナップなしに、毎回正確にそのフレームが得られます。何も「再生」していないので自動再生ポリシーと戦う必要もありません。あなたはただ静止画を描画しているだけです。その代償が前もって必要なデータ量(フレームの事前読み込み)であり、これこそWebPとデバイス別のフレーム数調整が解決するものです。

だからこそ、スクロールスクラブアニメーションに関する開発者向けの検索結果は、こぞってcanvas方式を推しています。Astorieが貢献するのは上流工程です:生成・抽出・選別のステップを一手に引き受けることで、このcanvasパターンに渡すフレームは、既存ファイルから画面録画した何かではなく、きれいで、ループ可能で、必要な箇所は4Kになっているものになります。