HiAPI API 上で flux-3-max/image-to-video を使ってショート動画を構築する

ショート動画制作に image-to-video が適している理由

ショート動画の成否は最初の 1 秒で決まる。だからこそ静止画像はあなたの手元で最も価値のある資産となり、image-to-video はこの種の作業における自然なプリミティブとなる。すでに掌握している 1 枚の画——製品画像、人物のポートレート、スタイル化された背景——から始め、モデルにそれを動きへと拡張させる。

text-to-video と比べると、後者はレンダリングのたびにサイコロを振り直すようなものだ。シーンを記述して何らかの結果を得て、頭の中で思い描いた構図を取り戻そうと何度も反復する。一方 image-to-video では、構図、色調、被写体の同一性が最初のフレームの動きを生成する前にすでに固定されている。プロンプトが答えるべき問いはただ 1 つ：ここから何が変わるのか？

この役割分担は、ショート動画コンテンツの実際の制作方法にちょうど対応している。短い映像は 1 回の連続生成で作られることはほとんどなく、いくつかのビートで構成される：フック、デモ、リアクション、エンドカード。各ビートはそれぞれ独自の静止画をシードとした独立した image-to-video 呼び出しにできるため、あるビートを再生成しても他のビートに影響しない。

このプリミティブは納品フォーマットにも適合する。ショート動画は短いため、各リクエストは範囲が明確で推論コストが低く、出力はそのまま編集タイムラインに置ける。下流の工程——トリミング、トランジション、字幕、音声ミックス——は、巨大な 1 回の生成呼び出しに押し込むのではなく、既存のパイプラインに残しておく。

image-to-video が適さないケース：撮影不可能な環境で単一の連続したカメラワークが本当に必要な場合、あるいはショットに安定したアンカーフレームがない場合。こうした場合にはテキスト駆動の方式のほうが正直だ。しかし大半のショート動画制作では、アンカーとなる最初のフレームにモーションプロンプトを加えるほうが、より予測可能で反復もしやすい。

本当に動く最初のフレームを選ぶ

image-to-video で最もよくある失敗は、美しいソース画像なのにモデルがアニメーション化しようがないことだ。平坦で均一な照明、タイトな構図の画は良い写真だが、悪いシードだ。何かをモデルに渡す前に、画質ではなく運動のポテンシャルという観点からこの静止画を評価しよう。

被写体の分離

モデルは何が動き、何が静止すべきかを知る必要がある。被写体の輪郭が明瞭で背景と明確に区別されていれば、明確な答えを与えられる。被写体が背景に溶け込んでいる場合——色調が近い、シルエットの背後に雑多なテクスチャがある、多くの重なりがある——動きは被写体に従うのではなく画面全体に塗り広げられがちだ。

運動の余地

動きには空間が必要だ。被写体が端から端まで画面を埋めていると、パンやズームインの行き場がなくなり、身体の動きはクロップされる。少しのヘッドルーム、見える地面、あるいは片側が開けた背景がある画は、端にアーティファクトを生じさせずに、モデルがカメラワークや身体動作を実行する余地を与える。

単一の明確なフォーカス

ショート動画はスマートフォンで視聴され、最初の 1 秒はしばしばミュート状態だ。単一の支配的なフォーカスを持つ静止画は瞬時に読み取れ、動きに主体を与える。混雑した画はモデルに注意を分散させ、得られるクリップは落ち着きなく見えても実際には動的な感じにならない。

被写界深度の手がかり

前景、中景、背景を備えた画——たとえ定義が緩くても——は視差を支える。階層化された画にわずかなカメラワークを行うと、説得力のある奥行きが生まれる。平坦な画はスライドショーの効果しか生まない。

実用的なチェックリスト

• 明確に、かつ説得力をもって動ける被写体があるか？
• 背景は十分に分明で、静止を保てるか？
• 予想される運動方向に空白の空間があるか？
• 縮小しても画は読み取れるか？
• このシーンの 2 秒のクリップは見栄えがするか？

ある画がこれらのうち 2 項目以上で不合格なら、プロンプトで修復しようとせず、撮り直すか別のシードに変えよう。プロンプトエンジニアリングは運動の余地がない構図を救えない。

flux-3-max/image-to-video のためのモーションプロンプトを書く

弱いプロンプトのほとんどはシーンを描写している。画像がすでにそれをやっている。モーションプロンプトは時間とともに起こる変化——何が動き、どの方向へ、どの速度で、その過程でカメラがどう振る舞うか——を描写すべきだ。

被写体より先に動作を

「赤いジャケットを着た女性が通りに立っている」と書く代わりに、「彼女が肩をカメラのほうへ向けるとジャケットの生地がそれに合わせて動き、やがて静止する」と書こう。前者は静止画を言い換えただけであり、後者はモデルに何をアニメーション化すべきかを伝えている。運動する要素、運動の方向、終点を名指ししよう。

カメラの挙動を明示する

カメラ言語はモーションプロンプトの中で最もレバレッジの効く部分だ。画面全体を制御するからである。有用なパターン：

• 固定カメラ、被写体が動く——最も安全で制御しやすい選択肢。
• ゆっくりしたズームイン——緊迫感を加え、フックに適する。
• 横方向のトラッキング——被写体が静止していても動きとして読める。
• 手持ちの揺れ——エネルギーを加えるが、クロップが必要なブレを持ち込むことがある。

指定しなければモデルが代わりに選び、より頻繁に振り直すことになる。

クリップ内で運動のリズムを組む

状態だけでなく弧を描写しよう。「最初は静止し、振り向きはおよそ 3 分の 1 の地点で始まり、終わりには画面が静けさに落ち着く」と書けばモデルにタイムラインを与えられる。単一の瞬間のように読めるプロンプトは、動きがまったくないか、一定速度の漂いで機械的に見えがちだ。

短く、物理的に保つ

通常 2〜4 文で十分だ。「感じさせる」「伝える」「ドラマチック」といった説明的な語彙より、物理的で観察可能な動詞——回す、持ち上げる、漂う、留まる、広がる——を優先しよう。感情に関する形容詞は運動の描写ではなく静止画に属する。

1 ショットにつき 1 つの運動アイデア

同時に起こる 3 つの動作を描写していることに気づいたら、それは 3 ショットだ。分割すればよりクリーンなレンダリングが得られ、あるビートが失敗したときにそれだけを振り直せる。

API リクエストを組み立てる

各生成は HiAPI API への 1 回のリクエストであり、各リクエストは数か月後に再構築できるよう十分に自己記述的であるべきだ。リクエストのペイロードは下書き用紙ではなく記録として扱おう。

リクエストの構造

flux-3-max/image-to-video の呼び出しには概念上 3 つのブロックがある：ソース画像、プロンプト、出力仕様。おおよそ次のような擬似コードになる：

request = {
    "model": "flux-3-max/image-to-video",
    "input": {
        "image": image_url_or_reference,
        "prompt": motion_prompt,
    },
    "params": {
        "duration": duration_seconds,
        "aspect_ratio": aspect_ratio,
        "seed": seed,
    },
}

画像がアンカーだ——上書きされるローカルファイルではなく、安定したバージョン付きの参照を渡そう。プロンプトは前節の運動の描写だ。残りは意図的に固定すべきパラメータである。

再現したいものを固定する

• シード。プロンプトを磨く間は固定し、出力の変化をサンプリングノイズではなくプロンプトに由来させる。多様性が欲しいときに解放しよう。
• 長さ。ショート動画は短いクリップを好む。シーケンス内の各ショットの長さを揃えれば、タイムラインの計算が簡単になる。
• アスペクト比。プロジェクトレベルで一度決め、すべての静止画と出力をそこから派生させる。

リクエストをショットリストで包む

各生成を 1 行として小さなリストに保存しよう——ショット id、画像参照、プロンプト、パラメータ、出力参照。この単一の成果物があれば、任意のショットを決定的に再実行でき、プロンプト改訂を差分比較でき、どの入力がどのクリップを生んだかを追跡できる。これが反復と当てずっぽうの違いだ。

レスポンスを非同期に扱う

動画生成は瞬時ではない。送信-ポーリング方式でクライアントを設計し、タスク id をショットリストの行と一緒に置き、出力を直ちに永続ストレージへ書き込んで、下流の組み立てがリクエストのアクティブ状態に依存しないようにしよう。

マルチショットシーケンスを組み立てる

ショート動画はシーケンスであり、それを構築する最もクリーンな方法は各ショットを独立した生成として扱い、タイムライン層で組み立てることだ。1 回の長い連続レンダリングを求める誘惑に抗おう。

まずビートを計画する

何かを生成する前に、シーケンスをショットリストとして書き出そう。15 秒のクリップなら、通常 3〜5 ショットが適切だ：最初の 1 秒を勝ち取るフック、アイデアを担う 1〜2 のビート、そして着地する締めの画。各項目に静止画、モーションプロンプト、長さを割り当てる。

ショット間の連続性を保つ

独立した生成はドリフトを生む。連続性を守る 3 つの習慣：

• 視覚語彙を共有する。同じ撮影や同じスタイル参照の静止画を使い、色調と照明をショット間で一致させる。
• アスペクト比と長さを統一する。クリップの長さを揃えれば、カットとトランジションが簡単になる。
• プロンプトの一貫性。同じシーンと感じられるショット間では、同じカメラ言語の記述を再利用する。

編集のために設計する

ショットは接合部で完全に一致する必要はない——きれいにカットできればよい。各クリップの先頭と末尾を少し多めに生成し、トリミングできる余裕を持とう。ショットを動きの中で終わらせて新しいアングルへカットするほうが、すべてのフレームを一致させようとするより、微妙な連続性の誤りをはるかによく隠せる。

モデルの外で組み立てる

連結、トランジション、字幕のオーバーレイは編集層で行う——スクリプト駆動のパイプラインかタイムラインツールだ。モデルの仕事は良いクリップを生むことであり、タイムラインの仕事はそれらを動画にすることだ。ショットリストと編集を同期させておけば、再生成したクリップをシーケンスを再構築せずにそのまま当てはめられる。

ネイティブオーディオを扱う

flux-3-max/image-to-video は映像を生成すると同時にオーディオも生成する。これは便利だが、シーケンスの計画方法を変える：オーディオは生成の一部であり、ポストプロダクションの追加物ではない。

動きだけでなく音のためにプロンプトする

あるショットに特定の音の特徴があるべきなら——街の環境騒音、機械の唸り、生地の擦れ——プロンプトに記述しよう。運動の描写はしばしば音を暗黙に含むが、明示的に名指しすればモデルがオーディオイベントを視覚的なビートに揃えやすくなる。あるショットが静かであるべきなら、それも記述しよう。無音は有効なデザイン上の選択であり、有用なコントラストにもなる。

オーディオイベントを中心にカットを計画する

ショットごとに生成されたオーディオはショット間で連続しない。これにより各カットが潜在的なオーディオの跳びとなる。有効な 2 つの戦略：

• 動きの箇所でカットする。トランジションを運動の大きい瞬間に置き、音の不連続をエラーではなくインパクトとして読ませる。
• ベッドトラックへカットする。シーケンスの下に連続した音楽や環境音のトラックを敷き、生成オーディオをその下の質感として位置づけることで、ショットごとの不連続を覆い隠す。

何を残すかを早めに決める

生成されたオーディオのすべてが使えるわけではない。クリップが返ってきたらすぐに評価し、リスト上でオーディオを残す・下げる・差し替えるのいずれかにマークし、編集はその決定に従わせよう。最終組み立ての段階で半分のクリップのオーディオを差し替える必要があると気づくのは高くつく。

ミックス用の余裕を残す

生成オーディオは控えめな音量に保ち、その上にナレーションや音楽のための空間を確保しよう。ネイティブオーディオは密度が高くなりがちだ。ミックスに余裕を残せば、映像を再レンダリングせずに後から解説を加える選択肢を保てる。

反復とコスト規律

磨き上げは動画プロジェクトが静かに高くつく場所だ。品質と出費の両方を予測可能にする規律は単純である：変わった部分だけを再実行する。

一度に 1 つの変数だけ変える

あるショットがうまくいかないとき、問題が画にあるのかプロンプトにあるのかを判断しよう。まず画を直す——評価が安く、下流のすべてを制約するからだ。画が正しくなったら、シードを固定したままプロンプトを反復し、差異をプロンプトのテキストに帰属させられるようにする。画像、プロンプト、パラメータを同時に変えても、どの変更が効いたかはわからない。

ショットリストを差分ツールとして使う

各リクエストがその入力とパラメータを記録しているため、再実行は機械的な操作になる：プロンプトが変わった行を選び、それらを送信し、残りはそのままにする。5 ショットのシーケンスで 1 つのプロンプトを修正したら、生成コストは 1 回分であるべきで、5 回分ではない。

安価なプレビュー、意図的な最終版

構図とリズムを決めるための探索的レンダリングは低い忠実度や短い長さで行い、ショットリストが確定したら最終版をレンダリングしよう。探索的レンダリングは意思決定のため、最終レンダリングは納品のためだ。両者を混同することが予算の蒸発する道だ。

シーケンス全体をバージョン管理する

シーケンスを確定するときにショットリストへタグを付けよう。後続の変更が連続性を壊した場合、記憶からプロンプトを再構築するのではなく、既知の良好なバージョンへ戻れる。バージョン付きのパラメータが「再実行可能なパイプライン」と「使い捨てレンダリングの山」の違いだ。

分単位ではなくショット単位で予算を組む

各ショットが独立したリクエストであるため、コストはショット数と改訂数に比例して拡大する——どちらもあなたが直接制御できる。ショットリストで計画すれば、生成の出費はビートを追加すると決めたその瞬間に見え、月末になって初めて見えることはない。現在の価格は HiAPI の価格パネルを参照。

1 枚の静止画と 1 つのモーションプロンプトから始め、HiAPI API 上の flux-3-max/image-to-video に向けて、ショットリストをそこから育てていこう。