開発者向け Kandinsky 6.0 Pro テキスト・トゥ・ビデオ プロンプトレシピ

なぜプロンプトは長さより構造が重要なのか

長いプロンプトは生産的に感じられます。光、雰囲気、背景、車のモデル、空の色を描写します——そして得られるクリップはその半分を無視するか、さらに悪いことに、すべてをぼんやりした妥協の産物に混ぜ込んでしまいます。kandinsky-6.0-pro/text-to-video のようなテキスト・トゥ・ビデオモデルは冗長さを評価しません。評価するのは構造です。

構造化されたプロンプトは、自由形式の段落ではできない3つのことを実現します：

• 関心事を分離します。 ショットタイプ、被写体の動作、カメラの挙動は互いに独立した変数です。それらが1つの文に絡み合っていると、どの部分が悪い出力を引き起こしたのか判断できません。
• 比較を可能にします。 バッチ内のすべてのプロンプトが同じ骨組みに従っていれば、出力の差異は実際に変更した部分に帰属させることができます。
• テンプレート化できます。 固定スロットを持つプロンプトはパラメータ化してプログラムで生成できます——手動テストからパイプライン段階に移行すると、これが極めて重要になります。

本記事では、3部構成のレシピを使用します：

[SHOT] + [SUBJECT & ACTION] + [CAMERA]

短く、順序立てられ、繰り返し可能です。目標は少なく書くために少なく書くことではなく、予測可能に書くことです。そうすれば同じレシピで1つのスロットを置き換えるだけで、別の映画ではなく意味のある比較が得られます。これ以降のすべてはこの骨組みの上に構築されます：コピー&ペースト可能なテンプレート、カメラワークの言い回し、イテレーションループ、そして最後にフロー全体を API 呼び出しに接続します。

テキスト・トゥ・ビデオ プロンプトレシピの解剖

レシピを書く前に、各ブロックの役割を理解しましょう。

ショット（Shot）

ショットブロックはフレーミングと時間の意図を設定します：クローズアップ、ミディアムショット、ワイドな定場ショット、俯瞰、ローアングル。これはプロンプトの中で最もレバレッジの高い行です。構図を固定するからです。ショットが間違っていれば、下流の何もそのクリップを救えません。

1つのフレーズに保ちます。Wide establishing shot は a shot that shows the whole scene from far away so you can see everything in the environment に勝ります。

被写体と動作

このブロックは何が動き、どう動くかを記述します。被写体は具体的に、各クリップには主要な動作を1つだけにします。1つのプロンプトに競合する2つの動作があると、通常どちらも苦手な被写体が生成されます。

• 良い：a cyclist rides left to right across frame
• リスクあり：a cyclist rides while waving and the camera zooms and the crowd cheers

2つ目の動作が必要なら、それは別のクリップに属すべきか自問してください。

カメラワーク（Camera）

カメラワークの言い回しは、視点がどう振る舞うかをモデルに伝えます：静止、パン、ティルト、プッシュイン、オービット。これは開発者が最もよく省略するブロックであり——バッチのクリップが一貫して感じられるかどうかに最も大きく影響するブロックでもあります。短く命令形の言い回しが最もうまく機能します。以下の専用セクションを参照してください。

何を省略すべきか

レシピは長い形容詞の連鎖、感情的な叙述、散文形式の否定指示を意図的に省略します。あるディテールがショット、被写体、カメラワークのいずれにもマッピングできないなら、この段階では通常ノイズです。コアレシピが安定した結果を生み出してから初めて、それを加え戻します。

有用なメンタルモデル：各ブロックは同じ出力フレームに対して異なる方向から入力を提供します——構図、動き、視点。あるブロックが曖昧なとき、モデルは自身の事前分布で空白を埋め、まさにそこで不整合が静かに現れます。

よくあるショットのコピー&ペースト可能なレシピ

各テンプレートは [SHOT] + [SUBJECT & ACTION] + [CAMERA] に従います。角括弧内の値を置き換え、構造はそのまま保ちます。

プロダクトヒーローショット

Close-up product shot of a [PRODUCT] rotating slowly on a seamless surface, soft studio light, camera locked off, shallow depth of field

EC のループ動画やアプリのヒーローセグメントに使用します。回転だけを唯一の動きに保ちます。

定場環境

Wide establishing shot of [ENVIRONMENT] at [TIME OF DAY], light haze in the air, slow forward dolly

オープニングやチャプター遷移に適しています。ドリーは奥行きを加えますが、焦点を奪いません。

キャラクターまたは人物の動き

Medium shot of [PERSON OR FIGURE] [PRIMARY ACTION], natural pace, camera static at eye level

動作は1つだけにします。人物がまず入場してから行動する必要があるなら、2つのクリップに分割します。

抽象または背景ループ

Full-frame abstract shot of [SHAPE OR PATTERN] drifting slowly, [COLOR PALETTE], gentle camera drift

シームレスなループ背景向けに設計されています。強い方向性のある動きを避けることで、ループポイントが目立たなくなります。

UI またはスクリーン風素材

Straight-on shot of [DEVICE OR SURFACE] displaying [CONTENT], subtle parallax, camera locked, no rotation

カメラを固定することでテキストや UI 要素が安定します——その上に実際の UI を合成する場合、これは極めて重要です。

自然とテクスチャのディテール

Close-up shot of [NATURAL ELEMENT] moving gently in [CONDITION], macro framing, slow lateral drift

バッチ内では控えめに使用します。テクスチャクリップはモデルの差異が最も顕著に現れるため、比較する際はグループ内でカメラワークを完全に同一に保ちます。

明快で読みやすいカメラワークと言い回し

カメラワークの言語はプロンプトが静かに問題を起こす場所です。モデルは描写散文よりも短く慣習的な言い回しにうまく反応し、バッチ内の一貫性は文才よりも重要です。

小さな語彙セットを使う

固定のカメラワーク用語セットを選び、どこでも繰り返し使います。実用的な入門セット：

• camera static / camera locked off
• slow forward dolly / slow backward dolly
• pan left / pan right
• tilt up / tilt down
• orbit around subject
• handheld drift

モデルが処理できることを検証済みでない限り、「dolly-zoom with a slight arc」のような複合的な動きを発明するのは控えてください。珍しいフレーズはそれぞれ未テストの変数です。

被写体の動きとカメラの動きを分離する

これらは2つの異なる指示であり、別々のスロットに配置すべきです。A cyclist rides left to right は被写体を記述し、pan right はカメラを記述します。the camera follows the cyclist と書くと両者が統合され、モデルがどちらを優先すべきか不明確になります。

速度を指定する

slow、steady、brisk のような1語で通常十分です。速度の語は、動きがクリップの尺のどれだけを消費するかを固定し、固定長のクリップを編集でつなぐ必要がある場合に重要です。

バッチ内で言い回しを一定に保つ

比較のために10個のバリエーションを生成するなら、カメラワークの行をバイト単位で完全に同一に保ちます。実行間で被写体とカメラワークを同時に変えると、差異をどちらにも帰属できなくなります。これはアドホックなプロンプトテストで最もよくある誤りです。

肯定的で観察可能な指示を優先する

カメラが何を避けるかではなく、何をするかを記述します。Camera static は明確な指示です；camera doesn't shake はモデルに否定の推論を要求します。肯定的な言い回しなら、後のプロンプトライブラリの検索も容易になります。

レシピを壊さずに調整する

レシピは出発点であり、固定資産ではありません。規律はそれをどう変えるかにあります。

1回の実行で1つのスロットだけを変える

ベースレシピを選び、ベースラインを生成し、次に1つのブロック——ショット、被写体、カメラワークのいずれか——だけを変更して再生成します。ショットと被写体を同時に変えると、どの調整が効いたのか分かりません。この制約は最初は遅く感じますが、ライブラリが成長すれば多くの時間を節約できます。

すべてを記録する

各実行について以下を記録します：

• 変更されていない完全なプロンプト文字列
• どのスロットを何に変えたか
• 簡潔な判定（採用 / 却下 / 再検討）
• 明らかなアーティファクトやレシピからの逸脱

プレーンテキストファイルかスプレッドシートの列で十分です。要点は、3週間前に気に入ったプロンプトが記憶から再構築されるのではなく、再現可能であることです。

レシピをバージョン管理する

プロンプトテンプレートをコードのように扱います。識別子（product_hero_v1、establishing_city_v2）を付け、各バージョンに変更履歴を1行残します。下流のクリップがおかしく見えたとき、それを生み出した正確なレシピをチェックアウトできます。

レシピがいつ完成したかを知る

同じパラメータで3回連続して実行し、すべての出力を受け入れられるなら、そのレシピは安定しています。その時点で凍結し、タグを付け、次のショットタイプに移ります。機能しているレシピを調整し続けることは、安定性をわずかな利益と交換しているにすぎません。

積極的に剪定する

書いたレシピのほとんどは最終的に捨てられます。安定しなかったものは削除またはアーカイブします——手入れされていない中途半端なテンプレートライブラリは、信頼できる小さなライブラリよりも悪いものです。

レシピをパイプラインに組み込む

手動イテレーションは探索に使います。本番では、安定したエンドポイントを通じて送信される、パラメータ化・バージョン管理されたプロンプトが必要です。

テンプレートをパラメータ化する

レシピを完成した文字列ではなく、名前付きスロットを持つテンプレートとして保存します：

{
  "id": "product_hero_v1",
  "template": "Close-up product shot of a {{product}} rotating slowly on a seamless surface, soft studio light, camera locked off, shallow depth of field"
}

レンダリングは単純です：呼び出し時に {{product}} を置き換えます。テンプレートは固定のまま、スロットの値だけが変わります。これは手動テストでの1回に1変数の規律と同じで、プログラム的に適用されるだけです。

1つのエンドポイントに保つ

実験と本番のトラフィックの両方を同じモデルエンドポイント kandinsky-6.0-pro/text-to-video にルーティングします。テスト呼び出しとリリース呼び出しが同じ API にヒットすれば、探索で有効だったプロンプトは本番でもまったく同じように機能します。段階間でインターフェースを切り替えることは、「昨日は動いていた」タイプのバグのよくある原因です。

呼び出し箇所でバージョン管理と記録を行う

生成されたすべてのクリップは、レシピ ID、レンダリングされたプロンプト、タイムスタンプに遡れるべきです。これらを出力参照とともに記録します。あるクリップにフラグが立ったとき、「どのレシピバージョンとどのパラメータがこれを生み出したか？」をフォレンジックなしで答えられるようにしたいはずです。

考えながらバッチ生成する

バリエーションを生成するときは、バッチ内で1つのスロットだけを変え、他はすべて一定に保ちます——カメラワークの行も含めて。これによりバッチの比較可能性が保たれ、自動審査や人手による抜き取り検査が著しく速くなります。

結果をライブラリにフィードバックする

本番で安定したレシピはタグ付けして再利用すべきです。時間とともに、ライブラリはチームの真のプロンプト資産になります：使い捨て文字列のフォルダではなく、検証済みでバージョン管理された構築ブロックの集合です。

テンプレートがパラメータ化されバージョン管理されれば、同じレシピが修正なしで手動テストと本番バッチの両方を駆動できます。

よくある失敗パターンとその読み解き方

弱い出力は通常ランダムではありません。症状を最も責任のあるブロックにマッピングし、そのブロックだけを変えます。

構図が実行間でドリフトする

考えられる原因： ショットブロック。曖昧または複合的なフレーミングフレーズ——a wide shot, somewhat close——はモデルに解釈の余地を与えます。単一の規範的なショット用語に絞り、バッチ内で一定に保ちます。

被写体が間違ったことや多すぎることをする

考えられる原因： 被写体と動作のブロック。1つのプロンプトに複数の動作があるか、曖昧な動詞で記述された動作。主要な動作を1つに減らし、観察可能な言語を使います。

過度または不規則なカメラの動き

考えられる原因： カメラワークの言い回し、またはその欠如。カメラワーク指示がないと、モデルが動きを勝手に発明します。明示的な camera static か名前付きの動きを追加し、動きを示唆する散文——the scene sweeps across はカメラワーク指示として読まれます——を削除します。

要求していないディテールが現れる

考えられる原因： 長すぎるプロンプト。形容詞の連鎖や感情的な言語はモデルに空白を埋めるよう促します。レシピを3つのブロックに削り、コアが機能することを確認してから、ディテールを1つずつ再導入します。

出力は一貫しているが退屈

考えられる原因： 過度に制約されたレシピ。すべてのブロックが固定され結果が平凡なら、解決策は通常、制御された変更——新しいカメラワーク、新しい動作——であり、完全な書き直しではありません。

結果が再現できない

考えられる原因： プロンプトではなくフローの問題。記録されていない編集、実行間でのカメラワークの言い回しの変更、または本番とは異なるエンドポイントでのテスト。対策は上述のバージョン管理されたライブラリと単一エンドポイントの規律です。

このように失敗を解釈することで、すべての悪い生成を、すべてを書き直す理由ではなく、具体的でテスト可能な仮説に変えることができます。