HiAPI で ltx-2.5-fast/text-to-video を使ってショート動画を制作する

ltx-2.5-fast/text-to-video がショート動画制作に適している理由

ショート動画は量の勝負であり、視聴者の注意力の予算はごく短い。大量のクリップ、素早いターンアラウンド、そして失敗作を躊躇なく捨てられる手段が必要だ。これが、どの生成モデルをパイプラインに組み込む価値があるかを決める。

ltx-2.5-fast/text-to-video は HiAPI API 上のテキスト-to-ビデオモデルで、ここで重要となる 2 つの特性を備えている。映像を生成しながらネイティブ音声も同時に出力し、さらに1080P で出力する。実際の効果として、1 回の呼び出しで返されるクリップはその形態のまま公開できる——無音の映像トラックに別途生成した音楽ベッドを継ぎ足す必要も、低解像度のドラフトを超解像してから見せられる状態にする必要もない。

モデル名の fast が示すのはまさに同じトレードオフだ。極限の忠実度よりもスループットを優先する。ショート動画制作——縦型クリップ、フック、ソーシャルプラットフォーム向けの編集——では、通常はこちら側が正しい。反復回数が増え、反復回数はどの 1 フレームよりも重要だからだ。

シンプルなパイプラインのイメージ：

text prompt ──► ltx-2.5-fast/text-to-video ──► video track (1080P)
                                          └──► audio track (native)

入力は 1 つ、出力は 2 つ、管理するアセットは 1 つ。本ガイドの以降の内容はすべてこの形態に基づいている。

プロンプトを書く前にクリップを設計する

プロンプトからクリップを生成する作業で最もよくある間違いは、動画全体に対して 1 つのプロンプトを書くことだ。モデルに「30 秒の広告を作って」と頼むと、各ビートを平均化し、どれとも言えない出来になる。まず分解する。

動画をショット単位に分割する

スクリプトを書き、視覚的な変化があるたびに切る。各カットポイントが 1 つの生成単位になる。典型的なショート動画は通常 4 から 8 単位に収まる。各単位には次を付ける：

• 番号と、何が起きるかを 1 文で表した説明
• 想定される長さ
• 音声の意図（セリフ、環境ベッド、音楽のみ、無音）
• 前のショットと視覚的に連続させる必要があるかどうかのメモ

各リクエストを小さく保つ

小さな単位は再生成も安く、並べ替えも安い。3 番目のショットが違っていれば、全体ではなく 3 番目のショットだけを再実行する。つなぎ目の作業はモデルの責務から外す。2 つのショットを滑らかにつなぐ必要があるなら、それぞれ別々に生成し、編集ツールでつなぐ。長い連続ショットを 1 回で求めない。

目標とする形態を先に決める

アスペクト比、長さの範囲、クリップの用途が他のすべてを決める。最初のリクエストの前にこれらを確定させる。後から変えるとすべてを再生成することになるからだ。複数のチャネル向けに制作する場合は、1 つのマスターをクロップするのではなく、チャネルごとにショットリストを設計する。構図の差が十分に大きいため、クロップはクロップに見えてしまう。

ショットリストはバージョン管理下のデータとして扱う。良いクリップを生んだプロンプトは資産であり、それを消費するコードと同じ場所でバージョン管理したい。

使えるクリップを生むプロンプトのパターン

プロンプトは散文ではなく、構造化されたショット記述のように書く。安定したテンプレートは再現性をもたらす。リトライが成功したとき、どのフィールドが変わったかが分かるからだ。

5 つのフィールド

[subject]   who or what is on screen, with concrete visual detail
[action]    what happens during the shot — one continuous motion
[camera]    framing, angle, and movement (e.g. slow push-in, static wide)
[lighting]  time of day, source, mood
[audio]     what should be heard: dialogue, ambience, music character

記入例：

subject: a woman in a canvas work jacket, mid-30s, workshop background
action: she lifts a ceramic mug from a shelf and turns it in her hands
camera: static medium shot, slight shallow depth of field
lighting: warm afternoon window light from camera left
audio: quiet room tone, faint hum of a kettle, no music

有効なルール

• 1 ショットにつき 1 アクション。 1 つのプロンプトに 2 つのアクションを入れると、その間で妥協した結果になる。ショットに 2 つ目のビートが必要なら、それは 2 つのショットだ。
• 見えるものを描写し、その意味を描写しない。 「彼女はほっとした様子だ」はモデルに何も与えない。「彼女の肩が下がり、息を吐く」はレンダリングできるものを与える。
• カメラの挙動を明示する。 カメラの挙動を指定しないのは、使えないクリップへの最短ルートだ。モデルはあなたが望まないデフォルトを選ぶ。
• 音声の意図を具体的に指定する。 ネイティブ音声とは、プロンプトが音に影響するということだ。セリフ、環境音、音楽、無音のどれが欲しいかを明示し、暗黙に任せない。
• 否定の積み重ねを避ける。 「テキストなし、ウォーターマークなし、余計な人物なし」は名指ししたものを招きがちだ。代わりに望む画面を描写する。

プロンプトのログを残す

送信したすべてのプロンプトについて、完全なテキストとパラメータを保存する。クリップがうまくいったとき、プロンプトは再利用可能な資産になる。失敗したとき、ログはプロンプトがずれたのかパラメータがずれたのかを教えてくれる。

HiAPI API でリクエストを送信する

生成は HiAPI API を通じて行い、モデル識別子は ltx-2.5-fast/text-to-video だ。呼び出しは単一のリクエストで、プロンプトと生成パラメータを送るとジョブが返り、その結果がクリップのアセットになる。

最小のリクエスト形態

正確なフィールド名とサポートされる範囲は、API ドキュメントのこのモデルのリファレンスページから得られる——何かをハードコードする前にまずそこを確認する。以下の構造は動作する呼び出しの形を示している：

curl -X POST "https://api.hiapi.ai/v1/video/generations" \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "ltx-2.5-fast/text-to-video",
    "prompt": "static medium shot, a woman in a canvas work jacket lifts a ceramic mug from a shelf and turns it in her hands, warm afternoon window light from camera left, quiet room tone with a faint kettle hum",
    "duration": <clip length in seconds>,
    "resolution": "1080p"
  }'

duration のプレースホルダはモデルが受け付ける値に置き換える。必要なものだけを送る：プロンプト、長さ、解像度、そしてリファレンスページに記載されたアスペクト比や音声制御項目があればそれら。

最低限送るべきもの

• モデル識別子（公開時と完全に一致させる）
• テンプレートで組み立てた完全なプロンプト
• 長さ（モデルがサポートする範囲から選択）
• 出力解像度（モデルが選択を許す場合）

レスポンスはファイルではなくジョブとして扱う

各レスポンスはジョブレコードとして扱う：識別子、状態、そして完了時にはアセットへの参照。ジョブ識別子をプロンプトやパラメータとともに永続化し、ライブラリ内のすべてのクリップがそれを生んだリクエストへ遡れるようにする。

API キーはサーバー側に保ち、環境から注入する。クライアント側でプロンプトを構築しない。

ネイティブ音声と 1080P 出力の下流処理

呼び出しが返すのは、すでに音声トラック付きの 1080P クリップだ。その次に何をするかが、これに意味があるかどうかを決める。

組み立てる前にレビューする

各クリップをフルサイズ・音声ありで最後まで見る。次の 2 点を具体的に確認する：

• 音画同期。 ネイティブ音声は映像から導出されるのではなく、映像と一緒に生成される。音が動作と一致しているか確認する——カップを持ち上げる音がドアを閉める音に聞こえてはいけない。
• 音声レベルと特性。 生成された音声は想定より大きいことも小さいこともある。ユニティゲインでタイムラインに置く前にピークを確認する。

素早く却下する。レビューで修正が必要なクリップは、通常は修正するより再生成する方が安い。特に修正点がプロンプト内にある場合はそうだ。

再生成ではなく組み立て

チームがすでに使っている編集ツールでショットをつなぐ。各ショットは完全な 1080P アセットとして返ってくるので、組み立ては通常の編集作業だ：前後のトリミング、トランジション点の設定、追加したナレーションの下で音声を下げる。

ネイティブ音声が価値を発揮するところではそれを残す。映像と一緒に生成された環境ベッドやルームトーンは、そのフレームのために生成されているため、重ねた素材音声トラックよりも通常よく馴染む。特定のボイスやライセンス音楽が必要な箇所でのみ音声を差し替える。

ターゲットチャネル向けにエクスポート

ターゲットプラットフォームが期待するコーデック、アスペクト比、長さでエクスポートし、大量生産の前にサンプルエクスポートをそのプラットフォームの要件と照合して検証する。1080P のソースは異なるアスペクト比へ再構成する余地を与えるが、再構成後は構図を再確認する——承認した画面がクロップに耐えられないことがある。

反復コストと品質を管理可能な範囲に保つ

生成はリクエストした作業量に応じて課金される——クリップの長さと解像度の両方が 1 回の呼び出しのコストに影響する。つまり反復の規律こそがコスト管理だ。意図的な 3 つの実践：

まず再生成、次に書き直し

クリップが近いが違う場合、同じプロンプトをもう一度実行する。生成は完全に決定論的ではなく、2 つ目のサンプルが軽微な瑕疵を取り除くことがある。同じプロンプトでの 2 回の再実行が同じように失敗するなら、問題はプロンプトにある——それを変える。

一度に 1 か所だけ変える

プロンプトを編集するときは、1 つのフィールドだけを編集する。主体、カメラ、ライティングを同時に変えて結果が良くなっても、再利用できるものは何も学んでいない。単変量の反復は収束する。散発的な編集は再現できないクリップを生む。

プロンプトの問題とパラメータの問題を区別する

失敗がどちらの軸で起きたかを問う。構図、動作、ムードはプロンプトの問題だ。長さ、解像度、形式はパラメータの問題だ。構図の問題をクリップを短くして直すのは 1 回の呼び出しの無駄であり、長さの問題をプロンプトを書き直して直すのも同じだ。

順番にエスカレートする

1. 同じプロンプトを再実行する。
2. プロンプトのフィールドを 1 つ調整する。
3. パラメータを 1 つ変更する（長さ、解像度）。
4. ショットを再設計する。

修正可能なクリップのほとんどはステップ 1 かステップ 2 で解決する。ステップ 4 に飛ぶのは、安い反復を高くする方法だ。

最後に、試行回数を制限する。ジョブ層でショットごとにリトライ上限を設定し、達したら止める——そのショットは別のサンプルではなく、再考が必要だ。

よくある失敗パターンとデバッグ方法

プロンプトからクリップへの問題のほとんどは、少数のカテゴリに収まる。以下は各カテゴリで最初に見るべき場所だ。

クリップがプロンプトと一致しない

まずプロンプトの具体性を確認する。曖昧な主体と未指定のカメラ挙動がよくある原因だ。5 フィールドテンプレートでショットを書き直し、カメラ挙動を明示する。

動作が混乱または分裂する

1 つ以上のことを同時に起こすよう要求した可能性がある。ショットを 2 つの生成単位に分割し、それぞれに連続した 1 つの動作だけを含める。

音声が映像と合わない

プロンプトの audio フィールドを確認する。暗黙に任せたなら、モデルがデフォルトを選んでいる。音声の意図——環境音、セリフ、音楽の特性、または無音——を直接指定する。

クリップの長さや形態が違う

これはプロンプトの問題ではなくパラメータの問題だ。送信した値がモデルのリファレンスページに記載された範囲内であることを検証し、クライアントが意図通りにシリアライズしている（捨てていない）ことを確認する。

リクエストが失敗する、またはタイムアウトする

順に確認する：モデル識別子の綴りが公開時と完全に一致しているか。API キーが存在し有効か。リクエストボディが有効な JSON か。レート制限を超えていないか。生成は非同期作業なので、遅いレスポンスは必ずしも失敗ではない——再送信ではなくジョブをポーリングする。そうしないと同じクリップに 2 回支払うことになる。

複数回の実行で結果が一致しない

ある程度は想定内だ。各プロンプトとパラメータセットを記録し、本当のリグレッションと通常の変動を区別できるようにし、リトライ上限はそのまま維持する。

最速のデバッグループは常に同じだ：ジョブレコードを取得し、実際に送信した正確なプロンプトとパラメータを読み、クリップが設計したショットと一致するまで一度に 1 フィールドずつ変える。