HiAPI
ブログ

使用ガイド

flux-3-max キーフレーム動画生成プロンプトのレシピ、コピー&ペーストでそのまま使える

開発者ガイド:予測可能な短編動画を得るために、キーフレームの記述と動きの言い回しをどう組み立てるか

Nov 3, 2026
Cover art of overlapping translucent glass planes casting calm bands of cool blue across a pale field, evoking keyframes flowing into motion.
コピー&ペーストでそのまま使える flux-3-max キーフレーム動画生成のレシピ:雨に濡れた屋上のプッシュイン。自然なわずかなドリフトとネオンの色調変化を伴う。

キーフレーム動画生成ワークフローがプロンプトに期待すること

最初のプロンプトを書く前に、キーフレーム動画生成ワークフローにおける役割分担を把握しておくと役に立ちます。

あなたは 2 枚以上の静止キーフレームを提供します。それらはアンカーです。何が存在するか、それが画面のどこに位置するか、そしてある時点でシーンがどう見えるかを定義します。モデルはそれらの間を補間します。テキストプロンプトは動きのブリーフです。あるアンカーから次のアンカーへどう進むか——何が動くか、どの方向に動くか、おおよそどの程度の強さで動くか、そしてカメラがどう動くかをモデルに伝えます。

この役割分担には実務上の帰結があります。プロンプトは世界全体を再記述する必要はありません。キーフレームにはっきり見えているものはすべてすでに確立されています。プロンプトは、静止画では表現できないもの——動き、テンポ、カメラの意図、そしてアンカー間のあらゆる状態変化(ドアが開く、被写体が振り向く、光が変わる)——に紙幅を割くべきです。

役に立つメンタルモデル:2 枚のキーフレームを説明なしで人間の編集者に渡したら、その人は「A から B へどうやって行くの?」と尋ねるでしょう。あなたのプロンプトはこの問いへの答えです。それ以外のすべて——カラーグレーディング、衣装のディテール、美術——は、テキストに形容詞を詰め込むよりも、キーフレームを改善して解決するほうがはるかに良いです。

本ガイドの残りの部分では、この枠組みを心に留めておいてください。以下のどのレシピも同じ考え方で組み立てられています。キーフレームがアンカーとなり、テキストが動きを導く。

キーフレーム記述の解剖学的構造

安定した出力は安定した入力構造から始まります。各キーフレームを固定の順序で記述すれば、どこかでズレたときにどの行を確認すべきか正確にわかります。

各キーフレームには次の 4 部構成の順序を使ってください:

1. 被写体

誰または何が焦点で、どのような状態か。数量と姿勢を具体的に:「単独の自転車乗り、直立、両手をハンドルに」は「自転車に乗っている人」より優れています。

2. シーンと環境

被写体がどこにいるか、そして位置づけに必要な最小限の文脈:「濡れたアスファルトの通り、背後に低い建物」。通常は一つの節で十分です。

3. フレーミングとカメラ位置

そのキーフレームのショットサイズとアングル:「ミディアムショット、アイレベル、被写体はやや画面左寄り」。これは動画が補間で近づいていくノードなので重要です。

4. 光と雰囲気

時間帯、光の方向、天気、もや。「夕方の逆光、柔らかなもや」は 5 つの情緒的形容詞の羅列よりも実行可能です。

いくつかの経験則:

  • すべてのキーフレームで同じ順序を保つ。 キーフレーム A が被写体から始まり、キーフレーム B が光から始まると、編集は当て推量になります。
  • 見えるものだけを記述する。 推測的な背景ストーリーは、モデルが活用できないノイズを増やすだけです。
  • 各部分は一文で。 ある部分に二文必要なら、それはおそらく二つのアイデアが主導権を争っている状態です。
  • キーフレーム間で語彙を再利用する。 A で「ミディアムショット」なら B でも「ミディアムショット」と呼び、「中距離のフレーミング」とは呼ばない。

この構造は意図的に退屈に作られています。退屈な構造こそが、面白い部分——動き——をデバッグ可能にするのです。

カメラの動きと動きの言い回し

カメラと動きの言い回しは、ほとんどのプロンプトが失敗する場所です。たいていは一文で多くをやりすぎようとするためです。

ルールはこうです:短く、単一の意図、独立した節。

良い動きの言い回しは一つの動きだけを名指しして、それをやり遂げさせます:

  • 「カメラがゆっくりプッシュインする。」
  • 「カメラが右へトラックし、被写体を中央に保つ。」
  • 「わずかな手持ちのドリフト、ズームなし。」
  • 「被写体がカメラの方を向いて止まる。」

悪い動きの言い回しは意図を積み重ね、モデルに妥協を強います:

  • 「カメラがゆっくりプッシュインしながら左へパンしやや上を向き、その間被写体が前に歩いて振り向き、同時に繊細なズームがかかる。」

この文には 5 つの指示が含まれています。どれか単一の短編動画がすべてをきれいに満たすことはできず、濁った平均値が得られます。仕事を分割しましょう。ショットを担う動きを一つ選び、残りはキーフレームに任せるのです。

報われる実践的な慣習をいくつか:

  • カメラと被写体を分ける。 「カメラは静止を保つ。被写体は左から右へ歩く。」二つの節、二つの動きの所有者。
  • 速度の言葉を意識的に使う。 「ゆっくりと」「滑らかに」「速く」は有用です。「ドラマチックに」「シネマティックに」は速度の言葉ではなく——願望です。
  • 重要なときは終了状態を名指しする。 「被写体が画面いっぱいになるまでプッシュインする」はモデルに目標を与えます。
  • 否定表現は弱い。 「カメラの動きなし」より「静止カメラ」を優先する。

一つだけ覚えるなら:一つの節、一つの意図。短編がズレたとき、まず確認すべきは、ある動きの節が密かに二つの動きを含んでいないかどうかです。

コピー&ペーストできるレシピのテンプレート

以下は汎用の骨組みです。コピーしてスロットを埋め、ラベルは残してください——ラベルはあなたのためのものでモデルのためのものではないので、望むなら送信前に削除してもかまいません。

[KEYFRAME A]
Subject: {{subject_a}}
Scene: {{scene_a}}
Framing: {{framing_a}}
Light: {{light_a}}

[KEYFRAME B]
Subject: {{subject_b}}
Scene: {{scene_b}}
Framing: {{framing_b}}
Light: {{light_b}}

[MOTION]
Camera: {{camera_move}}
Subject: {{subject_move}}
Pacing: {{pacing}}

短いプロダクト風の短編動画向けに埋めた例:

[KEYFRAME A]
Subject: a single ceramic mug, handle facing right, steam rising
Scene: on a wooden desk, blurred window behind
Framing: close-up, slightly above eye level, mug centered
Light: soft morning side light from the left

[KEYFRAME B]
Subject: the same ceramic mug, steam thinner, handle facing right
Scene: same wooden desk, window still blurred
Framing: close-up, slightly above eye level, mug centered
Light: slightly warmer morning light from the left

[MOTION]
Camera: slow push in
Subject: steam drifts upward and fades
Pacing: steady, unhurried

特に注意すべきスロットが二つあります。{{camera_move}} はあなたの短いリストの中の単一の動きであるべきです。{{pacing}} は短編全体のエネルギーを設定します——結果が速すぎる、または遅すぎると感じたときに最も安価に調整できるツマミです。

これらの埋めたテンプレートを小さなライブラリとして保管しておきましょう。十分にテストされスロットが明確な骨組みがいくつかあれば、書き捨てのプロンプトにほぼ常に勝ります。変数が分離され可視化されたままになるからです。

異なる動きの意図に向けたレシピのバリエーション

テンプレートはそのまま。変わるのはモーションブロックだけです。以下は同じキーフレームブロックの上に構築された 3 つのバリエーションで、それぞれ異なる意図を狙っています。

バリエーション 1:リビール(カメラが仕事をする)

[MOTION]
Camera: slow push in from medium to close-up
Subject: holds pose, breathing only
Pacing: slow, even

被写体こそが報酬で、画面をそれに向かって引き締めたいときに使います。被写体の動きを最小限に抑え、カメラの動きがはっきり伝わるようにします。

バリエーション 2:横断(被写体が仕事をする)

[MOTION]
Camera: static, locked off
Subject: walks left to right across frame, steady stride
Pacing: moderate, continuous

キーフレームが経路や位置の変化を描いているときに使います。カメラを固定すると横断が明確に読み取れます。二つの競合する動きはそれを曖昧にします。

バリエーション 3:雰囲気(環境が仕事をする)

[MOTION]
Camera: very slow lateral drift
Subject: mostly still, slight sway
Pacing: slow, ambient

エスタブリッシングショットや背景用で、光、もや、パーティクルが短編を担います。被写体が画面をアンカーし、環境が変化を提供します。

変わらないものに注目してください:キーフレームの記述です。これが構造の意義です。アンカーが安定してしまえば、動きの意図の切り替えは書き直しではなく 2 行の編集になります——これにより同じシーンでの短編の A/B テストが本当に実行可能になります。

失敗モードと、ズレた短編のデバッグ方法

短編がズレたとき、慌ててプロンプトを書き直さないでください。ズレは情報です。一度に一つの変数だけを変え、再実行し、それから他の何かに触れてください。

以下はよくある失敗モードと、それぞれの単一変数の修正方法です。

短編が混乱している、または「平均化」されているように感じる

原因:一つの節に二つ以上の動きの意図がある。 修正:モーションブロックを個別の行に分割し、主導的な動き以外をすべて削除する。

被写体が変形する、または同一性を失う

原因:テキストが被写体を過剰に記述し、キーフレームと競合している。 修正:両方のキーフレームの被写体行を、数量、姿勢、決定的なディテール一つに削ぎ落とす。同一性はアンカーに担わせる。

カメラを動かさないよう頼んだのに動いた

原因:どこかに暗黙の動きがある、またはテンポの言葉がエネルギーを示唆している。 修正:「カメラは静止を保つ」を独立した節として書き、テンポの言葉を柔らかくする。

動きが速すぎる、または遅すぎる

原因:テンポが未指定、または自己矛盾している。 修正:{{pacing}} だけを変える。再実行する。同じラウンドでカメラの節を調整しない。

短編が 2 枚目のキーフレームを無視する

原因:キーフレーム B が A からあまりに多くの次元で同時に逸脱している。 修正:二つの記述を行ごとに比較し、最も重要でない行で差を縮める。一行変えて再実行し、繰り返す。

規律は単純です:イテレーションごとに一つの変数、そして変えた内容を简潔に記録する。3〜4 ラウンドを経れば、たいてい犯人の行を特定でき、レシピ自体についても再利用可能な学びが得られます。

バージョン管理とチーム内でのレシピ共有

一度レシピが機能すれば、それはもはやプロンプトではなく、プロジェクトの資産になります。資産として扱いましょう。

軽量なシステムで十分です:

  • レシピをリポジトリに保管する。 prompts/ ディレクトリ、レシピ一ファイルずつ、それらを使うコードのそばに置く。レシピはリクエストコードと一緒にバージョン管理する。
  • シーン名ではなく意図で命名する。 reveal-product-closeup.md は見つけやすい;prompt-final-v3-really.md はそうではない。
  • 骨組みと埋めたものを分ける。 テンプレートは一度だけ保存し、埋めた例はそれに対する小さな差分として保存する。そうすればレビュアーはどのスロットが変わったか正確に見られます。
  • 何を変え、何が起きたかを記録する。 各レシピ 2 行の変更履歴——変えた変数、観察された効果——は、長い散文の説明よりも価値があります。
  • コードのようにレシピをレビューする。 チームメイトは差分を読んで短編を予測できるべきです。できないなら、動きの節がやりすぎです。
  • 意識的に退役させる。 レシピが置き換えられたら、削除するのではなくマークし、代替品にリンクする。そうすれば古い短編も再現可能なままです。

これはワークフローの中の地味な部分であり、まさにこれが、一貫した短編を届けられるチームと、チケットごとにプロンプトで議論し直すチームを分けます。これらのレシピを単一の統合インターフェースから実行する準備ができたら、リクエストをエンドツーエンドで接続し、flux-3-max キーフレーム動画生成モデルのページから始めてください。

永続的なAIアーティファクトで開発を始める

APIキーを取得して、タスクベースの1つのAPIで画像・動画・音声モデルを呼び出せます。

APIドキュメントを読む