使用ガイド
Kling 3.0 のイメージ・トゥ・ビデオを HiAPI API で使ってショート動画を制作する
ショート動画は、あらゆるコンテンツパイプラインが最終的に必ず対応しなければならないフォーマットであり、それを安価かつ安定的に量産する最も現実的な方法がイメージ・トゥ・ビデオです。すでに手元で管理できている静止画——製品画像、キャラクターデザイン、生成済みのキーフレーム——を用意し、それを動画モデルに動かしてもらいます。HiAPI 上の Kling 3.0 のイメージ・トゥ・ビデオエンドポイントはこの用途に優れており、さらに多くの i2v モデルが省略している機能を備えています。それは、開始フレームと終了フレームを同時に指定できる点です。こうすることでモデルは単一フレームから動きを外挿するのではなく、2 つの状態の間をアニメーション化します。
本チュートリアルでは、完全にスクリプト化可能なワークフローを構築します。開始フレームを生成し、それを Kling 3.0 の非同期タスク API に送信し、完了までポーリングし、ネイティブで同期された音声付きの完成クリップをダウンロードします。すべてはバッチ処理にそのまま組み込める通常の HTTP 呼び出しで行います。
テキスト・トゥ・ビデオではなくイメージ・トゥ・ビデオを選ぶ理由
テキスト・トゥ・ビデオは毎回驚きをもたらします。イメージ・トゥ・ビデオは、すでに承認済みの出発点を提供します。そのフレームが製品写真やブランドキャラクターなど、動き出す前に特定の見た目である必要があるものの場合、これは重要です。Kling 3.0 のイメージ・トゥ・ビデオモデルは、開始フレーム+終了フレーム制御によってさらに一歩進みます。参照画像を 1 枚渡せば、モデルはそれを単なる出発点として扱います。2 枚渡せば、2 枚目が目標の終了状態となり、モデルはその間の動きを補間します。これは実質的に、タイムラインエディタを一切使わずに 1 回の API 呼び出しで実現するプログラマブルなキーフレームアニメーションです。
リクエスト構造
Kling 3.0 のイメージ・トゥ・ビデオは HiAPI の統一非同期タスクエンドポイントで動作します——POST /v1/tasks を実行し、その後完了するまで GET /v1/tasks/{id} をポーリングします。このモデルの入力スキーマは意図的に簡潔に保たれています:
{
"model": "kling-3.0/image-to-video",
"input": {
"prompt": "a lantern slowly lighting up as the camera pushes in, warm cinematic glow",
"image_urls": ["https://static.hiapi.ai/blog/kling-3-0-image-to-video-short-form-workflow/first-frame-v2.jpg"],
"duration": 3,
"resolution": "720p",
"sound": true
}
}
これを中心に構築する前に、知っておくべきことがいくつかあります:
image_urlsは 1 または 2 個の項目を受け付けます。画像 1 枚は「このフレームからアニメーションを始める」ことを意味します。画像 2 枚は「1 枚目から 2 枚目へアニメーションする」ことを意味し、これが上述の開始フレーム+終了フレーム制御です。別個のtail_image_urlフィールドは存在せず、すべては配列の位置で表現されます。durationは 3 から 15 秒の整数です。ショート動画プラットフォームはほとんどの場合 3〜8 秒の範囲のクリップを求めるため、単一シーンでは通常この範囲の低い側を選びます。resolutionは最大 4K まで対応し、兄弟モデルのkling-3.0-turbo(上限 1080p)より高くなります。ただしコストがかかります——下記の料金を参照——そのため 720p または 1080p で、スマートフォンの画面では誰も気づかない解像度に料金を払わずに、ほとんどのショート動画ユースケースをカバーできます。soundはブール値であり、事後に音楽をかぶせる無音クリップではなく、真の同期音声生成です。シーン内の動きが合理的に音を生む場合(ドアが閉まる、風の音、足音)にオンにすると、結果は無音レンダリングよりも明らかに説得力が増します。aspect_ratioフィールドはありません——出力画面は入力画像が持つアスペクト比に一致します。
エンドツーエンドのスクリプト
Python での完全なフローです:タスクを作成し、完了までポーリングし、結果をダウンロードします。
import requests
import time
API_KEY = "YOUR_HIAPI_KEY"
BASE = "https://api.hiapi.ai/v1/tasks"
HEADERS = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}
def submit_i2v(image_url, prompt, duration=3, resolution="720p", sound=True):
payload = {
"model": "kling-3.0/image-to-video",
"input": {
"prompt": prompt,
"image_urls": [image_url],
"duration": duration,
"resolution": resolution,
"sound": sound,
},
}
resp = requests.post(BASE, headers=HEADERS, json=payload, timeout=60)
resp.raise_for_status()
return resp.json()["data"]["taskId"]
def wait_for_result(task_id, poll_interval=5, timeout_s=600):
deadline = time.time() + timeout_s
while time.time() < deadline:
resp = requests.get(f"{BASE}/{task_id}", headers=HEADERS, timeout=30)
resp.raise_for_status()
task = resp.json()["data"]
if task["status"] == "success":
return task["output"][0]["url"]
if task["status"] == "fail":
raise RuntimeError(task.get("error"))
time.sleep(poll_interval)
raise TimeoutError(f"task {task_id} did not finish in {timeout_s}s")
task_id = submit_i2v(
image_url="https://static.hiapi.ai/blog/kling-3-0-image-to-video-short-form-workflow/first-frame-v2.jpg",
prompt="a lantern slowly lighting up as the camera pushes in, warm cinematic glow",
)
video_url = wait_for_result(task_id)
print(video_url) # temporary signed URL — download immediately, don't store it as a permanent link
これを実際のパイプラインに組み込む際に、つまずきやすいポイントが 1 つあります。返ってくる output[0].url は一時的な有効期限付きリンクです。タスクの出力 URL をどこかに長期的に保存するのではなく、バイトを直ちにダウンロードして自身のストレージに移動してください。
以下はこの例で使用した開始フレームと、sound: true で Kling 3.0 がそこから生成したクリップです:

上記のような 3 秒、720p、音声付きのクリップは $0.40 強のコストです——納品したいバージョンを決める前にプロンプトを何度か反復できるほど安価です。
料金:解像度と音声の両方がコストに影響します
Kling 3.0 のイメージ・トゥ・ビデオは出力時間の秒単位で課金され、解像度と音声のオン/オフの両方が料率に影響します:
| 解像度 | 音声なし | 音声あり |
|---|---|---|
| 720p | $0.10/s | $0.143/s |
| 1080p | $0.129/s | $0.193/s |
| 4K | $0.479/s | — |
計算例:3 秒、720p、音声付きのクリップは約 $0.43 です。5 秒、1080p、音声なしのクリップは $0.645、同じクリップで音声ありは $0.965 です。ほとんどの完成クリップが 3〜8 秒の範囲に収まるショート動画コンテンツでは、720p または 1080p がほぼ常に正しい選択です——4K の料金が正当化されるのは、下流で追加解像度の恩恵を実際に受けるものに合成する場合だけです。大規模に何かを実行する前に、現在の料金を確認してください。1 秒あたりの料率のような詳細は、記憶に頼ってキャッシュするのではなく、ライブページで確認する価値があります。
実際のワークフローへのバッチ処理
どの規模のショート動画コンテンツでも、タスクを 1 つ送信してずっと見張り続けるのではなく、タスクを一括で投入し、結果が届くたびに回収したいはずです。各タスクは独立しており、自身の taskId で識別されるため、パターンはシンプルです。まずすべてのイメージ・トゥ・ビデオリクエストを送信し、返されたタスク ID を保存し、それらをループでポーリングして、各タスクが success または fail になったときだけアクションを起こします。こうすることで、パイプラインは単一の最も遅い生成に直列化されるのではなく、プラットフォームの実際のスループットで動作します。
最初から身につけておくべき習慣がいくつかあります:
- 送信前にソース画像へアクセスできることを検証する。タスク API は URL を素直に受け付けますが、画像を取得できない場合、タスクは後で失敗します——事前に HEAD リクエストで確認すれば、無駄な生成を 1 回回避できます。
fail状態を例外ではなく通常の結果として扱う。モデル出力は特定のプロンプト/画像の組み合わせをたまに拒否します。バッチ全体を中止するのではなく、失敗を記録して次の項目へ進んでください。- 可能な限りバリアント間でクリップを再利用する。同じ生成アニメーションに対して複数の字幕や音楽をテストする場合、動画自体を再生成する必要はありません——それは純粋に下流の編集ステップです。
API キーと認証を初めて設定する場合は、HiAPI のクイックスタートガイドがキーの取得と最初の認証付き呼び出しの基礎をカバーしており、その後で完全なバッチパイプラインをその上に構築できます。
まとめ
Kling 3.0 のイメージ・トゥ・ビデオモデルは、1 回の HTTP 呼び出しで単一の静止画——開始フレーム+終了フレーム制御が必要なら 2 フレーム——を同期音声付きのショート動画クリップに変換し、料金は再生時間、解像度、音声の要否に応じて予測可能にスケールします。ショート動画パイプラインにとって、この制御性、720p/1080p でのクリップあたりの低コスト、そしてわかりやすい非同期タスク API の組み合わせにより、「1 枚の静止画」から「完成クリップのバッチ」へ、動画エディタに触れることなく簡単に移行できます。