開発者向け Kling 4.0 テキストtoビデオ プロンプトレシピ

なぜプロンプトは言い回しより構造が重要なのか

ほとんどのチームは言い回しから始めます。形容詞を何度も調整し、類義語に置き換え、次のレンダリングでうまくいくことを期待します。単発のクリップならそれで機能しますが、API パイプラインに入った瞬間——同じプロンプトが数十、数百のリクエストで一貫した結果を出さなければならない状況——では完全に破綻します。

言い回しは表面的な細部です。出力を予測可能にする鍵は構造にあります。

kling-4.0/text-to-video を呼び出すとき、モデルが受け取るのは一つの文字列です。この文字列の内部で、モデルは複数の独立した判断を同時に解決する必要があります。主体は何か、環境はどう見えるか、カメラはどう動くか、そして要求されたクリップの長さにどれだけの物語を収められるか。これらの判断が一つの流暢な文に絡み合っていると、どの文が悪いレンダリングを引き起こしたのか判断できず、他の次元に影響を与えずに一つの次元を調整することもできません。

構造化プロンプトはこれらの判断を安定したスロットに分離します。これには三つの実用的な利点があります:

• 分離性。 カメラがおかしいと感じたら、カメラスロットだけを変えます。シーン記述は変わらないので、比較に意味が生まれます。
• 再利用性。 同じシーンブロックをバッチ内で異なるカメラブロックと組み合わせられます。これこそが低コストでバリエーションを探索する方法です。
• 診断性。 モデルやパラメータの変更後に出力へ回帰が現れたとき、推測ではなくプロンプトのバージョンを比較できます。

構造が勝つ二つ目の理由: 動画生成はイテレーションのコストが高いことです。各レンダリングは時間と予算を消費し、中間状態を見ることはできません。見られるのは最終クリップだけなので、プロンプトは実質的に唯一のデバッグインターフェースです。仕様書のように読めるプロンプトは推論できる対象を与えてくれますが、詩のように読めるプロンプトは何も与えてくれません。

最後に、構造化プロンプトは引き継ぎに耐えます。チームメイトが読んで、埋めて、バージョン管理できるレシピは資産です。巧妙な一度きりのプロンプトは誰かのドラフトファイルに生き、そこで死にます。

だからこそ、本ガイドのレシピは魔法のフレーズのリストではなく、一つの骨格を中心に構成されています。フレーズは重要ですが、あなたが制御できる形に埋め込まれて初めて機能します。

コアとなるプロンプト骨格

本ガイドの各レシピは、同じ四段階テンプレートの埋め込みです。順序を安定させてください。そうすれば diff が読めるものになります。

[SUBJECT] + [SCENE] + [CAMERA] + [PACING]

各スロットに含めるべき内容は以下の通りです:

主体(Subject)

クリップが誰または何についてなのか、動きの中で維持すべき一、二の物理的ディテールを添えて。具体的かつ視覚的に保ちます。「雨に濡れたトレンチコートの女性」は「神秘的な人物」より優れています。抽象的な感情ラベルはここでは避けてください。モデルがレンダリングするのは身体と物体であり、意図ではありません。

シーン(Scene)

環境、照明、時間。シネマティックな品質はここで決まります。ムード語ではなく、光の方向と質感を指定します。「低い角度の陽光がフレーム左側から斜めに差し込み、硬い影、空気中の塵」は「ドラマチックな照明」よりも多くの情報をモデルに伝えます。

カメラ(Camera)

ショットサイズと動きを、独立した節として述べます。独立したスロットなので、丸ごと置き換えられます。固定のロングショットとゆっくりしたプッシュインは同じ主体とシーンを共有しますが、まったく異なるクリップを生み出します。

ペーシング(Pacing)

クリップ内で何が起こるべきか、要求した尺に合わせて。短いクリップは一つのビートを支え、長いクリップは小さな弧を収められます。

埋め込み例は以下の通りです:

SUBJECT: a lone cyclist in a dark windbreaker, water beading on the helmet
SCENE: empty coastal road at dawn, overcast sky, wet asphalt reflecting grey light
CAMERA: wide shot, slow lateral tracking at walking pace
PACING: single continuous action, cyclist pedals steadily, no cuts

kling-4.0/text-to-video に送る一つのリクエスト文字列に平坦化すると:

A lone cyclist in a dark windbreaker, water beading on the helmet, on an empty coastal road at dawn, overcast sky, wet asphalt reflecting grey light. Wide shot, slow lateral tracking at walking pace. Single continuous action, cyclist pedals steadily, no cuts.

この骨格を実践で機能させる二つの約束事があります。第一に、スロット間はカンマではなく句点で区切ること。これがプロンプトに自然なリズムを与え、各判断を分離します。第二に、スロットを誤って空にしないこと。カメラを気にしていなくても、「static medium shot」のような明示的な選択を書いてください。そうすればモデルが即興で埋めることはありません。

骨格を契約として扱ってください。変更するときは意識的に変更し、プロンプトのバージョン番号を上げます。

シネマティックシーンの言い回しレシピ

シネマティックな出力は、映画っぽく聞こえる形容詞ではなく、光と空間の具体的な記述から生まれます。以下のパターンはムード語を物理的事実に置き換えます。

レシピ: 指向性照明

SCENE: interior workshop at night, single warm lamp from upper right casting long shadows across a cluttered bench, dust visible in the light beam, dark background falling into black

何が効いているかに注目してください: 光源、方向、質感、そして光が何を明らかにするか。「Warm」と「night」が色調を設定し、「upper right」が幾何学を固定し、「dust visible in the beam」が奥行きを加えます。ランプを窓に替えれば、主体やカメラを変えずに同じ骨格で異なるシーンを生み出せます。

レシピ: 環境の奥行き

SCENE: narrow alley after rain, foreground puddles with reflections, midground fire escape and hanging cables, distant streetlight haze behind, cool blue-grey palette

前景、中景、背景を明示的に層別化することで、モデルに奥行きの計画を与えます。また、プロンプトが一つの平面しか描写していないときに現れる、ぼやけた中間フレームも減らします。

レシピ: 質感を伴う主体の動作

SUBJECT: a chef in a white apron, flour dusting the forearms, hands working dough
PACING: continuous kneading motion, flour puffing with each press, no cuts

動作は、モデルが持続的に維持できる物理的なループとして記述します。連続的で反復可能な動作は、一度きりの出来事よりもクリップ全体で一貫します——一度きりの出来事はモデルが早めに完了させ、その後空回りする可能性があります。

レシピ: 天気と雰囲気

SCENE: city rooftop at dusk, thin fog moving through the frame, wind pushing loose fabric, distant skyline softened by haze, low contrast, desaturated

雰囲気は動くものとして記述すべきです。動画は動きの手がかりに報いるからです。霧、風、雨、漂う粒子はすべてフレームに持続的な質感を与えます。

避けるべきアンチパターン

• 形容詞の積み重ね。 「Epic, stunning, cinematic, beautiful」はモデルがレンダリングできる情報を何も加えません。
• シーンにカメラ用語を混入させる。 「slow dolly」はシーンスロットの外に置き、単独で調整できるようにします。
• 矛盾。 「Bright night scene」は予測不能に解釈されます。一つの照明計画を選び、それに固執してください。
• 主体が多すぎる。 キャラクターや物体を増やすたびにモデルの注意を奪い合い、どれか一つが歪む確率が上がります。

カメラとショットサイズ制御のレシピ

カメラはレバレッジが最も高いスロットです。内容を変えずにクリップの質感を変えられるからです。バッチ内で置き換えられるよう、独立させておいてください。

ショットサイズの語彙

各カメラ節はショットサイズで始まります: エクストリームロングショット、ロングショット、ミディアムショット、クローズアップ、エクストリームクローズアップ。この一語が、主体がフレームのどれだけを占め、環境がどれだけ見えるかを決めます。

CAMERA: medium close-up, static tripod

動きのレシピ

以下はそれぞれ、そのまま差し替え可能なカメラ節です:

CAMERA: wide shot, slow push-in toward the subject
CAMERA: medium shot, lateral tracking left at walking pace
CAMERA: close-up, slow handheld drift with slight instability
CAMERA: wide shot, static, subject moves through frame
CAMERA: medium shot, slow tilt up from hands to face

重要な規律は、各節に動きを一つだけ含めることです。プッシュイン、俯仰、ロールを同じリクエストで組み合わせると、モデルが相反する動きの計画を混ぜ合わせる必要があるため、たいてい濁った結果になります。

速度修飾語

知覚品質にとって、動きの方向より速度の方が重要です。素朴な修飾語を使ってください: slow、steady、walking pace、gradual。数値の速度はモデルの動きの計画に確実に変換されないため避けます。

ハンドヘルドと安定

ドキュメンタリー風のリアリズムが欲しいなら、「handheld, slight instability」と明示してください。コマーシャル品質の洗練が欲しいなら、「stabilized, smooth motion」と書きます。これを指定しないことが、クリップがおかしいのに明らかな原因が見つからない最もよくある誘因の一つです。

バッチ内でカメラを置き換える

カメラは独立したスロットなので、主体、シーン、ペーシングを固定したまま、制御された比較を生成できます。小さなカメラ節の配列を作り、それをループし、他はすべて固定します:

cameras = [
    "wide shot, static tripod",
    "medium shot, slow push-in",
    "close-up, handheld with slight drift",
]
for cam in cameras:
    prompt = f"{subject}. {scene}. {cam}. {pacing}."
    # send prompt to kling-4.0/text-to-video

出力セットは、その内容に対してどの構図が最もよく読めるかを教えてくれます。一つの変数しか動かしていないので、比較は正直です。

尺とペーシングのレシピ

プロンプトの詳細はクリップの長さに一致しなければなりません。短いクリップで三つのビートを記述するプロンプトは、慌ただしく破綻した結果を生みます。長いクリップで小さな動作だけを書くプロンプトは、死んだ時間を生みます。

短いクリップ: 一つのビート

短い尺には、物語の進展を含まない、一つの連続した動作を記述します。

PACING: one continuous gesture, subject turns head slowly toward the light, nothing else changes

連続を示唆するものはすべて剥ぎ取ります。「then」「after」「finally」といった言葉は、モデルに出来事を圧縮させ、一貫性を失わせる誘因になります。

中程度のクリップ: 一つの動作と環境の動き

二つ目の主体動作ではなく、環境の動きを加えます。

PACING: subject stands still breathing, cloth shifting in the wind, background smoke drifting continuously

環境の動きは、新しい出来事をモデルに演出させることなく、時間を埋めます。

長いクリップ: 小さな弧

尺が許せば、開始状態と終了状態を記述できます。二つのビートに保ち、遷移を物理的なものにしてください。

PACING: subject begins facing away, slowly turns to face camera, expression settles into a neutral gaze by the end

開始、動き、終了位置を述べます。これにより、空白の時間を埋めさせるのではなく、モデルに補間できる軌跡を与えます。

言葉と秒数の対応

経験則として、各ビートは一つの物理的動作を記述し、短いクリップではおおむね一ビートを予算とします。ペーシング部分で二文以上書いていることに気づいたら、クリップが弧を収められるほど長いか、過剰に指定しているかのどちらかです。

よくあるペーシングの誤り

• 暗黙のカット。 「Shot one, then shot two」はほとんど機能しません。単一の生成は連続した一つのショットです。
• 話しながら動く。 台詞と複雑な動きは難しい組み合わせです。どちらかに寄せてください。
• 時間の変化。 クリップ内の日没は制御が難しいので、一つの照明状態を選んで保ちます。
• 群衆の演出。 独立して動く複数の人物は急速に劣化します。群衆は演者ではなく質感として扱ってください。

パイプラインでレシピをテストする

プロンプトレシピはコードです。コードと同じようにバージョン管理し、テストし、記録すべきです。

プロンプトを資産としてバージョン管理する

各レシピをバージョン識別子と埋めたスロットを添えてファイルに保存します。アプリケーションロジックの中に文字列として埋め込まないでください。フレーズを変更したらそれは新バージョンであり、旧バージョンは比較とロールバックのために利用可能なままにします。

{
  "id": "cyclist_coastal_v3",
  "subject": "a lone cyclist in a dark windbreaker...",
  "scene": "empty coastal road at dawn...",
  "camera": "wide shot, slow lateral tracking...",
  "pacing": "single continuous action..."
}

小さな比較バッチを実行する

レシピを本番に昇格させる前に、小さなバッチを生成します——数百ではなく、少数のバリエーション。一度に一つのスロットだけを変えます。気にする次元で出力を採点します: 主体の忠実度、動きの安定性、構図、そしてクリップが尺をどれだけ埋めているか。勝者を昇格させ、判断を記録します。

プロンプト、パラメータ、出力を一緒に記録する

各リクエストは、プロンプトバージョン、埋めたスロット、リクエストパラメータ、出力識別子、品質スコアを含むレコードを書き込むべきです。後で回帰が現れたとき、そのログが五分の診断と一日の当て推量の差になります。

log = {
    "prompt_id": recipe["id"],
    "prompt": flattened_prompt,
    "params": {"prompt": flattened_prompt},
    "output": response_id,
    "score": manual_score,
}

回帰セットを維持する

レシピが本番に入ったら、凍結した小さなプロンプトセットとその受理された出力を保持します。モデルやパラメータの変更後は、そのセットを再実行して比較します。これにより、ユーザーが気づく前に静かなドリフトを捕捉できます。

シンプルな昇格ループ

骨格からレシピを起草し、スロットを埋め、あるスロットの代替案に対して小さなバッチを実行し、採点し、勝者を完全なログ付きのバージョン管理された資産として昇格させます。コンテンツのニーズが変わるたびに繰り返します。

各レシピをテスト可能な成果物として扱えば、パイプラインはもうスロットマシンではありません。kling-4.0/text-to-video エンドポイントから始め、その上に独自のバージョン管理ライブラリを構築してください。