Ray 3.2 テキストから動画生成：縦型ショート動画の一括ワークフロー

概要

• これは何か：hiapi API 上の ray-3.2/text-to-video を使い、テキストの行を縦型の Reels/TikTok/Shorts 風ショート動画に変換する、再現可能な一括ワークフロー——入力画像不要、素材の準備も不要。
• 誰向けか：量を必要とするソーシャル・コンテンツチーム——毎月1本の重点動画ではなく、毎週いくつもの新しい 9:16 クリエイティブをテスト用に生成するチーム。
• すべてを決める核心的事実：ray-3.2 t2v は秒数 × 解像度のみで課金される。アスペクト比は無料なので、9:16 縦型と 16:9 横型の価格はまったく同じ。量をコントロールできる唯一のレバーは解像度のティアだ。
• 理論ではなく実証：以下の各ショート動画は、この記事のために単一の一括タスクで生成された——4本の5秒 540p 9:16 ショート動画、1本 $0.2145、合計 $0.858、各本のサーバー側レンダリング時間は37〜87秒。

Ray 3.2（hiapi では Luma のテキストから動画生成モデルとして掲載）は、ショート動画が本当に必要とすることを実現できるため、ショート動画に非常に向いている。つまり、ひとつの説明文からまったく新しい5秒のショットを生み出せる。フレームを提供する必要も、商品写真をアニメーション化する必要も、参照素材を準備する必要もない。フックを書けば、ショート動画が手に入る。これにより、クリエイティブの一括生成において正しいツールとなり、だからこそこのワークフローは、他のモデル向けの画像から動画生成や参照から動画生成のショート動画ガイドとは異なって見える。

テキストから動画生成か画像から動画生成か——まず正しい入口を選ぶ

どちらも同じ非同期タスク API の下に位置するが、解決する問題は異なる：

• テキストから動画生成（本ページ）：プロンプトだけを出発点とする。まったく新しいコンセプト、雰囲気の断片、特定の映像を持っていない——あるいは縛られたくない——B-roll に最適。モデルはショット全体を自由に構図できるため、選択肢を一括で生み出す必要があるときにうってつけだ。
• 画像から動画生成：すでに持っている最初のフレームを出発点とする。重点的な商品写真があり、その物体を動かしたい場合は、ray-3.2/image-to-video を使う——映像をあなたのフレームに固定し、それを基にアニメーション化する。

経験則：求められているのが「このキャンペーン用にまったく新しいオープニングを3つ」なら、テキストから動画生成。「この正確な商品画像を動かす」なら、画像から動画生成。本記事の残りは前者について論じる。

ワークフロー全体を決める価格の事実

以下は ray-3.2/text-to-video の完全かつ最新の価格表（執筆時点で hiapi の価格と照合済み——常にここではなく、そちらで再確認すること）：

秒数	解像度	1本あたりの価格
5s	540p	$0.2145
5s	720p	$0.429
5s	1080p	$1.7145
10s	540p	$0.643
10s	720p	$1.286
10s	1080p	$5.143

表に登場しないものに注目：アスペクト比だ。Ray 3.2 は秒数と解像度のみで課金するため、9:16 縦型は 16:9 横型、1:1、21:9 と同じ価格。この事実だけでもショート動画の一括制作の計画方法が変わる：

• 540p はテスト用ティア。1本 $0.2145 なら、1080p の重点動画1本分の価格で10〜15のコンセプトを生成できる。縦型ソーシャルのフィードはスマートフォンで小さく視聴される——540p（9:16 では 540×960 で出力、後述）は初回の A/B テストには十分鮮明で読み取れる。
• 720p / 1080p は仕上げ用ティア。コンセプトが勝ち抜いたら、そのプロンプトだけを 720p または 1080p で再生成し、実際の公開に使う。
• 秒数は固定ティアであり、スライダーではない。秒数は5秒か10秒の固定選択肢のみで、7秒の選択肢はない——そして10秒のコストは5秒の約3倍。フック駆動のショート動画では、5秒が基本単位となることが多く、その後編集で複数を重ねる。

この「探索は安く、勝者にだけ課金する」という形こそが、このワークフローを 540p で一括実行する理由そのものだ。

1リクエスト、1コードブロック

Ray 3.2 t2v は、小さく閉じた入力フィールド群を受け付ける：

フィールド	必須	値
prompt	はい	シーンの説明
duration	はい	5 または 10（整数秒）
resolution	はい	540p、720p、1080p
aspect_ratio	はい	9:16、16:9、1:1、4:3、3:4、21:9

縦型ショート動画1本は、非同期タスクエンドポイントへの1回の POST にすぎない：

curl -s https://api.hiapi.ai/v1/tasks \
  -H "Authorization: Bearer $HIAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "ray-3.2/text-to-video",
    "input": {
      "prompt": "Vertical 9:16 first-person POV gliding down a neon night market alley...",
      "duration": 5,
      "resolution": "540p",
      "aspect_ratio": "9:16"
    }
  }'

応答は data.taskId を返す。次に GET /v1/tasks/{taskId} を data.status が "success" になるまでポーリングし、output[0].url をダウンロードする。これが仕組みの概要だ——完全なリクエスト/レスポンスの実例、ステータスのライフサイクル、Python 版、エラー処理については、併せて公開している実践ガイドを参照のこと：Ray 3.2 テキストから動画生成 API：curl と Python ガイド。タスク API を初めて触るなら、まずクイックスタートから始めよう。

本当に縦型らしく読めるプロンプトを書く

5秒で入力フレームなしというのは、コンパクトな創作上の要件だ。以下の4つの習慣が、このバッチで大きな違いを生んだ：

1. プロンプトで「vertical 9:16」（縦型 9:16）と明示する——そして縦長構図に合わせ、単一の被写体を中央に積み重ねるように配置し、広い横型画面とトリミングがぶつかり合うようにしない。
2. フックは最初の1秒に費やす。ショート動画は最初のフレームで成否が決まるので、すぐに動き出すものを描写する（「the spiral catches the light in the first second」——螺旋が最初の1秒で光を捉える）。
3. カメラの動きを明示する——プッシュイン、クレーン下降、ゆっくりした周回。Ray 3.2 は明確な運動方向によく反応し、また運動こそがショート動画をスライドショーではなくコンテンツらしく感じさせる鍵だ。
4. 1本のショート動画には1つのアイデアだけ。5秒では物語は語れないが、1つのビートは打ち込める。1つだけ与えよう。

以下はこのバッチの4本のプロンプトで、それぞれが実際に依頼文に書くであろう異なるショート動画縦型ジャンル——飲食、旅行 POV、EC 商品、アウトドアブランドの雰囲気——だ。各ショート動画はモデルの生出力であり、一切の処理を施していない。

1 · 飲料 / 卓上（上のカバーショート動画を参照）。食欲を駆り立てる商品使用シーンのコンテンツ。プロンプトは注ぎと光の当たり方から始まり、フックを最初のフレームに落とし込む：

Vertical 9:16 close-up: a barista's hands pour a slow spiral of golden honey
over a glass of iced coffee, condensation beading on the cup, morning light
raking across a marble counter, shallow depth of field, the honey spiral
catches the light in the first second — crisp appetizing tabletop commercial look

2 · 旅行 POV。人物を映さない一人称のエネルギー——フィードを止める最速の方法。「handheld bounce」（手持ちの揺れ）の指示が Vlog 的な感覚を与える：

Vertical 9:16 first-person POV gliding fast down a neon-lit night market alley,
steam rising from food stalls, string lights streaking into bokeh, the camera
pushes forward with a confident handheld bounce, vibrant saturated colors,
energetic short-form travel vlog feel

3 · 商品主役（EC）。「見せ場」のビートを伴うクリーンな回転台のショット——新製品発表や機能ハイライトのオープニングに適している：

Vertical 9:16 product hero: a single pair of white running shoes rotates slowly
on a seamless gradient pedestal, a ribbon of fine sand swirls around them in slow
motion, soft studio key light with a crisp rim, clean minimalist e-commerce
aesthetic, the sand reveal lands on the opening beat

4 · アウトドア / ブランドの雰囲気。ライフスタイルや旅行ブランド向けのドローン急降下——「最初の1秒で急速に降下し、その後緩やかな周回に移る」という指示が、意図的な2段階の動きを与える：

Vertical 9:16 overhead drone shot snapping down toward a lone kayaker cutting a
clean V-wake across a glassy turquoise lake at sunrise, mist drifting off the
water, the camera descends fast in the first second then eases into a gentle
orbit, cinematic outdoor-brand mood

4つのプロンプト、4つの縦型ジャンル、1つのモデル、合計 $0.858。これが一括1回分だ。

最後まで見張らなくてもバッチを走らせる

タスク API は非同期なので、効率的なパターンはまず扇状に配信し、まとめて回収すること——1本生成して待ち、また次を生成する、という形にしない。まずバッチ全体を一度に送信し、各ショート動画を上流で並列にレンダリングさせ、各 taskId を手に入れた瞬間に保存し、それからポーリングを始める：

for each prompt:
    taskId = POST /v1/tasks  (model=ray-3.2/text-to-video, input=...)
    persist taskId to disk immediately   # it's billed at submit

for each saved taskId:
    poll GET /v1/tasks/{taskId} until status == "success"
    download output[0].url

今回の実行で学んだ（あるいは再確認した）フローに組み込むべき2つのこと：

• ポーリングするのは保存済みの taskId であり、絶対に再送信しない。id は POST した瞬間に課金されるため、一時的なネットワークエラーでポーリングが失敗したら、それを捕捉して同じ id でリトライすること——再送信すると二重課金される。id をディスクに永続化しておけば、クラッシュした実行も再作成ではなくポーリングで復旧できる。
• 1本あたりの 540p ショート動画は約40〜90秒を見込む。このバッチでは、4本のショート動画がサーバー側でそれぞれ37、38、70、87秒で完了した。扇状配信とは、セット全体が合計時間ではなく、最も遅い1本とほぼ同じ時間で完了することを意味する。

540p 9:16 のリクエストでは、540×960、24fps、約5.04秒の H.264 MP4 が得られる——つまり「540p」は短辺を指し、縦型映像はそのまま縦長で出力されるので、こちら側でトリミングする必要はない。

生のショート動画から公開済みのショート動画へ

事前に計画しておくべき現実的な制約が2つある：

• ショート動画は無音だ。Ray 3.2 t2v は映像のみを出力し、音声トラックはない。これはショート動画にとっては問題ない：ショート動画を編集ソフトに取り込み、そこで流行の音楽、ナレーション、字幕を加えればよい。編集工程を計画すること。API がそのまま公開可能なファイルを生み出すことを期待してはいけない。
• 5秒は1つのビートであり、1本の動画ではない。再現可能な方法は、いくつもの5秒ショート動画を生成し（上述のとおり）、そのうち3〜4本を重ねて15〜20秒の編集に仕上げ、ビートの位置でハードカットすること。各ショート動画は1つのフックであり、編集が物語だ。

したがってエンドツーエンドのループは次のとおり：540p でコンセプトを一括生成 → 勝者を選ぶ → そのプロンプトだけを 720p/1080p で再生成 → 編集ソフトで編集して音楽を付ける → 公開。探索は安く、勝者にだけ一度課金し、最後は手作業で仕上げる。

よくある質問

ray-3.2 テキストから動画生成は音声を生成しますか？いいえ——出力は無音の MP4 です。編集ソフトで音声を追加してください。

入力画像は必要ですか？いいえ。これこそがテキストから動画生成の意味です：プロンプトのみ。既存のフレームをアニメーション化したい場合は、ray-3.2/image-to-video を使ってください。

ソーシャルメディアにはどの解像度を使うべきですか？大量のコンセプトテストには 540p（9:16 では 540×960——スマートフォンで鮮明に読み取れます）、実際に公開するショート動画には 720p または 1080p を使ってください。

トリミングせずに本当の縦型を得られますか？はい。aspect_ratio: "9:16" を渡せば、モデルはネイティブな縦長（540p では 540×960）でレンダリングします。アスペクト比は価格に影響しません。

1本のショート動画はどれくらいの長さにできますか？5秒または10秒——固定の選択肢であり、連続的な範囲ではありません。フック駆動のショート動画では、5秒ずつ生成して編集で重ねるのが通常はより割の良い使い方です。

これは実践ガイドとどう違うのですか？実践ガイドは単一のリクエスト（curl、Python、エラー処理）をエンドツーエンドで扱います。本ページはその上のワークフローです：縦型コンセプトを一括でどう生み出すか、どの段階でどの解像度ティアを使うか、9:16 用のプロンプトをどう書くか。

生成を始める

Ray 3.2 テキストから動画生成は、非同期タスク API で利用可能になりました。キーを取得し、ray-3.2/text-to-video モデルページで完全なパラメータリファレンスと現在の価格を確認し、540p で最初の縦型コンセプト群を一括生成してください——1ドル未満で1週間分のショート動画アイデアを試せます。同じタスクでモデルを比較していますか？seedance-2.0-fast と Kling 3.0 画像から動画生成のショート動画ワークフローガイドも同じループをたどりますが、トレードオフが異なります。