この記事について
動画生成モデルをプロダクトや社内ツールに組み込むとき、モデル側の操作が1種類か3種類かで、ジョブテーブルの設計がまったく変わる。本稿では2026年9月28日に発表されたモデルの公開仕様を題材に、その設計上の論点を概念レベルで整理する。コードは扱わない。
題材とするモデル
Kling AI(快手傘下)のKling 4.0。正式版は2026年10月リリース予定で、軽量版のKling 4.0 Flashが発表日から早期アクセス中。公開されている仕様のうち、設計に直接響くものを抜き出す。
- 1ショット3〜30秒(Flashは3〜20秒)、720p/1080p/4K
- プロンプト最大8,000トークン
- キーフレーム画像 最大10枚(画像→動画)
- Omni Reference:1リクエストあたり最大15入力(画像≤10、動画≤5本かつ合計≤30秒、音声を含み得るエレメント≤7)
- 操作:生成 / 前後への延長 / 部分編集(表情・動き・カメラ・スタイル・背景のみ変更、入力動画≤5本・メイン1本含む)
- ステレオ音声を映像と同時生成、9言語でリップシンク
- 同時実行数:プランにより1 / 4 / 8
論点1:ジョブは3種類、系譜を持つ
従来のモデルは「生成」の1操作だったので、ジョブ1行=プロンプト1つ=出力1つで済んだ。ユーザーの修正は無関係な新規ジョブとして積まれる。
このモデルでは延長と部分編集が既存出力を入力に取る。つまりジョブに親子関係が生まれる。kind(generate / extend / edit)と、nullableなparent_output_idを持たせるのが素直な形だ。generateは親を持たず、extendとeditは必ず持つ。これだけでリビジョンツリーが自然に表現でき、ユーザーが「3つ前の版に戻す」操作を実装できる。
論点2:参照アセットはフラットなリストではない
Omni Referenceの15入力は「何でも15個」ではなく、種別ごとの上限と動画の合計秒数制約がある。したがって参照セットは型付きスロットを持つ構造体として保存し、送信前に種別別の個数と動画合計秒数をクライアント側で検証したい。失敗した生成もラウンドトリップのコストはかかる。
プロンプト内では@image1、@video1のようなハンドルで役割を指定するので、ハンドルとアセットIDの対応表は自分側で持つ。プロンプトテンプレートに「@image1はキャラクター」と書いておき、送信時に実ファイルを差し込む構造が再現性を確保しやすい。
キーフレーム(最大10枚)は順序が意味を持つので、集合ではなく順序付きリストとして扱う。
論点3:8,000トークンをUIにどう映すか
テキストボックス1つでは予算を使い切れない。ベンダーのガイドは被写体・動作・背景・カメラ・照明・音・参照の役割という順序を推奨している。セクション分けしたフォームから1本のプロンプト文字列にコンパイルする設計のほうが、自由入力より結果が安定し、フィールド単位の検証もできる。
論点4:同時実行数はプラン依存
スターター1、スタンダード4、プレミアム8。キュー投入時にアカウントのプランを読み、アカウントごとの同時実行上限をかける。上限を超えて投げてもエラーにはならず、ベンダー側で直列化されるだけなので、ユーザーには理由不明のレイテンシばらつきとして見える。
論点5:音声は後処理ではなく成果物の一部
ステレオ音声が映像と同時に出る。TTS→ミックスのワーカーがあるなら、音声を出さないモデル向けにフラグで残しつつ、既定では走らせない。
料金と容量計画
年払い換算で月21ドル(180クレジット、約11本)、56ドル(580クレジット、約36本)、90ドル(1,300クレジット、約81本)。1本あたりおよそ16クレジットだが、延長と編集の単価は公開ページに記載がない。従量課金オプションがあるので、利用曲線が読めない初期はそちらが妥当。全プランでウォーターマークなしのため、プラン別の後処理分岐は不要。
未公開事項
レート制限、ポーリングやWebhookの仕様、操作別のクレジット消費は公開ページにない。Flashは720pで20秒までなので、ベンチマークは正式版で数値が動く前提で行う。参照先のkling4.krは独立運営のサービスでKling AIの公式サイトではない旨が明記されている。デモカードに入力・プロンプト・使用モードが例ごとに載っており、3種類のジョブが実際に何を出すかを確認するには最短の資料だった。