MiniMax H3 Max テキスト動画プロンプトのレシピ（開発者向け）

優れたテキスト動画プロンプトは何で構成されるか

テキスト動画プロンプトは一文ではない。自然言語で書かれた小さな設定ファイルだ。生成結果が意図と違うとき、本当に役立つ問いは「このプロンプトは良いか？」ではなく「プロンプトのどの部分が機能しなかったのか？」である。この問いに答えられるのは、書いたプロンプトに指し示せる構成要素がある場合だけだ。

すべてのプロンプトを、互いに独立した6つのブロックとして扱ってほしい：

• 主体（Subject）——画面に誰または何が映るか。複数回の生成で一貫させるため、種、素材、服装、年齢層、識別特徴まで十分に具体的に書く。
• 動作（Action）——主体が何をするか。起こる順に並べる。これはビート表であり、雰囲気ではない。
• 場景（Scene）——場所、時間帯、天気、背景の出来事、光源。
• カメラ（Camera）——カメラがどこにあり、どう動き、どのくらいの速さで動くか。これは場景とは別物であり、独立した行にすべきだ。
• 尺（Duration）——クリップが何秒続くべきか。これによって、その中に収まる動作ビートの数も暗黙に決まる。
• 解像度（Resolution）——今回の生成で狙う出力ティア。

これらのブロックを物理的に分ける——1ブロック1行、または1ブロック1つのラベル付き断片——理由は、動画生成が多変数最適化問題であり、1回の実験では1つの変数しか動かせないからだ。主体、カメラ、尺が流れるような文章の中に絡み合っていると、カメラを変えたときに主体の言い回しや文のリズムも変わってしまい、どの変更が結果の違いを生んだのかもう説明できなくなる。

分かれたブロックは反復編集にも耐える。主体ブロックは同じ場景の10ショットで再利用できる。カメラブロックはレンズを交換するように差し替えられる。尺ブロックは動作を書き換えずに上げ下げできる。散文形式で書かれたプロンプトは毎回ゼロから書き直すことになるが、ブロック形式で書かれたプロンプトは項目ごとに比較できる。

最後に心に留めておく価値があるのは、これらのブロックの効き目は対等ではないということだ。主体と動作の変更はたいてい目に見えて直感的に理解できる。カメラの言い回しと尺の変更こそが予想外の結果の大半を生む源であり、しかも双方向だ——1つの前置詞がフレーミングを反転させ、尺の変更が最後の動作ビートを静かに削ってしまうこともある。それに応じて注意力を配分し、カメラと尺それぞれに調整可能な場所を用意し、形容詞の中に埋もれさせないことだ。

以下のすべてはこの構造に立脚している。レシピとは、構造よく整えられ、コピーして編集できるブロックの組み合わせにすぎない。

そのままコピーできるレシピは何で構成されるか

レシピとは、ラベル付きスロットを持つプロンプトテンプレートだ。コピーし、スロットを埋め、送信すれば、構造が変わらないまま次の版と比較できる結果が得られる。

次の骨格を毎回の実験の土台にしてほしい：

SUBJECT: <who/what, with 2–3 identifying details>
ACTION: <beat 1> -> <beat 2> -> <beat 3>
SCENE: <location>, <time of day>, <light source>, <background activity>
CAMERA: <position>, <movement>, <pace>
DURATION: <target length>
RESOLUTION: <tier for this pass>

このテンプレートを単なる形式ではなく実用的なものにする2つのルールがある。

変わるスロットと固定したままのスロットを分ける

典型的なプロジェクトでは、SUBJECT と SCENE が安定したベースラインだ——多くのショットで同じキャラクター、同じ場所を撮ることになる。ACTION、CAMERA、DURATION、RESOLUTION はショットごとの変数である。心の中で「固定」と「変動」に分類し、実験では変動するものだけを動かすこと。結果が予想外だったのに、その回に主体の記述まで変えていたなら、テストを1回無駄にしたことになる。

ACTION は形容詞ではなくビートとして書く

ビートのリストは尺と突き合わせて数えられるものになる。walks in -> sets down a box -> looks up は3つのビートであり、クリップが戻ってきたときそのうち2つしか含まれていなければ、このショットは詰め込みすぎか、尺が短すぎたとわかる。a busy, dynamic scene は何も確認できない。形容詞は SCENE と CAMERA のリズムに属し、順序ではなく質感を表すものだ。

プロンプトの中にラベルを残す

これらの大文字ラベルはモデルのためであると同時に、自分の記録のためでもある。ログ内の差分を読みやすくし、漏れたフィールドを一目でわかるようにし、プロンプトが度重なる修正の中で散文に退化するのを防ぐ。モデルがラベル付き断片をうまく扱えるなら残せばよい。流れるような文のほうを好むなら、最終回だけラベルを外し、それでも記録にはラベルを残して構造化を保つ。

記入済みの例：

SUBJECT: ceramicist in her 40s, clay-dusted apron, hair tied back
ACTION: lifts a wet bowl off the wheel -> turns it to inspect -> sets it on the shelf
SCENE: small studio, late afternoon, single window light from the left, dust in the air
CAMERA: medium close-up at wheel height, slow push in, unhurried pace
DURATION: short pass
RESOLUTION: draft tier

形式はこれで全部だ。これ以降のすべてのレシピは、この骨格に、テスト対象のスロットを1つ加えたものにすぎない。

レシピ：尺を制御する

尺は場景を引き伸ばすスライダーではない。場景に何を収められるかを変えるものだ。短いクリップは1つの動作。長めのクリップは始まり・中段・終わりを持つシーケンスであり、そのシーケンスを書かなければ、モデルは勝手に埋め草をでっち上げるか、ビートを1つ落とす。

だからこそ、ACTION を要求する尺に合わせ、尺を明示的に書く——デフォルト値に任せない。

短いクリップのレシピ（明確な動作を1つ）

SUBJECT: <consistent subject block>
ACTION: single continuous gesture — <the one thing that happens>
SCENE: <stable scene block>
CAMERA: <fixed position, minimal movement>
DURATION: brief clip, one action beat
RESOLUTION: <current test tier>

短いクリップは抑制に報いる。1つの動作、1つのカメラのアイデア、背景の枝葉はなし。主体がフレームに入る必要があるなら、その入る動きが動作だ。同時に振り向きや手振りまで求めてはいけない。

長めのクリップのレシピ（順序付けられたビート）

SUBJECT: <consistent subject block>
ACTION: beat 1 -> beat 2 -> beat 3 (in this order)
SCENE: <stable scene block, plus any change over time>
CAMERA: <movement that supports the beats>
DURATION: extended clip, three beats
RESOLUTION: <current test tier>

長めのクリップには明確な順序と限られたビート数が必要だ。単一の連続ショットなら3ビートが妥当な目標であり、5つ必要なら、それは実は2ショットを説明しているのではないかまず考えてほしい。同時に、どのビートが余分な時間を使う価値があるかも決める——ふつうは真ん中だ。最初のビートは導入に、最後は締めくくりに使われるからだ。

尺の言い回しがリズムをどう変えるか

これらのレシピを実行して得た実用的な観察が2つある：

• リズムを言葉で表すことは、長さそのものと同じくらい重要だ。unhurried、continuous、in one take、quickly は、同じビートリストがクリップ内でどう配分されるかを変える。同じ3ビートのリストでも、unhurried と付けるのと quickly と付けるのは、2つの異なる長さではなく、2つの異なるショットだ。
• ビートが1つ落ちたときは、まず尺を延ばし、それから動作の削減を検討する。最後のビートがいつも切られるなら、たいていの修正はビートを減らすことではなく時間を与えることだ——3つのビートすべてが不可欠である場合に限るが。

他の何かをテストするときは尺を固定する

この規律こそがレシピを使う価値を生む。尺はリズムを変え、リズムはカメラ運動の見え方を変え、カメラは動作がどう展開して見えるかに影響する。カメラをテストするときに尺を変動させると、因果の帰属を誤る。尺をロックし、記録し、それから次のスロットを動かすこと。

同じ論理が解像度にも当てはまる。それが次のレシピの主題だ。

レシピ：解像度ティアを選ぶ

解像度はまずコストと反復速度の判断であり、画質の判断はその次だ。ティアの間でプロンプトはあまり変わらない。変わるのは、何回試せるか、そしてプロンプトのアイデアが成立するかどうかをどれだけ早く見抜けるかだ。

2つのティアで考えてほしい：探索用のドラフトティアと、納品用の最終ティア。具体的な数値はモデルのパラメータ文書にある——ここでの要点はワークフローであり、数字ではない。

ドラフトティアのレシピ

SUBJECT: <subject block>
ACTION: <beat list>
SCENE: <scene block>
CAMERA: <camera block>
DURATION: <short test length>
RESOLUTION: draft tier

ドラフト実行は構図レベルの問いに答える：主体は判別できるか？カメラ運動は読み取れるか？すべてのビートは揃っているか？低ティアなら、最終レンダリング1回分の時間で複数のバリアントを走らせられ、プロンプトがまだ流動的なときにそれがまさに必要としているものだ。

最終ティアのレシピ

SUBJECT: <locked subject block>
ACTION: <locked beat list>
SCENE: <locked scene block>
CAMERA: <locked camera block>
DURATION: <delivery length>
RESOLUTION: final tier

ロックという言葉に注意してほしい。最終ティアへの引き上げは、検証済みのプロンプトを持ち上げることであり、もう1回の実験ではない。解像度と尺以外は何も変えないこと。最終レンダリングの構図がドラフトと違うなら、プロンプトのどこかが解像度に敏感だとわかる——記録する価値がある。

ユースケース別にティアを選ぶ

• 探索と社内レビュー——ドラフトティア。確認するのは構造であり、精緻さではない。
• プロンプトの回帰チェック——ドラフトティア。十分に安く、変更のたびに走らせられる。
• クライアント向けまたは埋め込み納品——最終ティア。かつ、ドラフトが意図に合致して合格した後に限る。
• 合成画面内の背景や大きくトリミングする要素——その要素が画面のごく一部を占めるだけなら、ドラフトティアで十分な場合がある。

低ティアで先にテストするほうが実は時間を節約できる理由

テキスト動画で高くつく失敗のパターンは、間違ったショットを美しく高精細にレンダリングしてしまうことだ。捨てる予定の構図の磨き上げに費やす1分はすべて無駄であり、高ティアほど試行が遅いため、その無駄は倍増する。ドラフトティアでの反復は、安い判断——主体の明瞭さ、ビート数、カメラの向き——を前倒しし、高いティアは確認のために残す。

1つ注意点がある：細部を判断できないほど低いティアでドラフトしてはいけない。ショットが小さな小道具や表情に依存しているなら、その細部はより高いティアでしか評価できないかもしれず、そうした特定のチェックはより早くティアを上げるべきだ。

レシピ：実際にショットを変えるカメラの言い回し

このガイドから1つだけ持ち帰るなら、これを持ち帰ってほしい：カメラの言い回しは、主体に付け足せるどんな形容詞よりもほぼ確実に結果に影響する。主体、動作、場景が完全に同じで、カメラブロックだけが違う2つのプロンプトは、2つの異なるショットだ。一方、雰囲気の形容詞の山だけが違う2つのプロンプトは、たいてい同じショットのままだ。

このことがカメラブロックを最もてこの効くスロットにし、同時に1回に1フレーズだけテストする価値が最も高いスロットにしている。

運動のパターン

CAMERA: static, locked off
CAMERA: slow push in
CAMERA: slow pull out
CAMERA: lateral tracking left to right
CAMERA: handheld follow behind the subject
CAMERA: orbit around the subject, quarter turn

上のそれぞれが完全で、そのままコピーできるカメラブロックだ。意図的に短く書いてある。冗長なカメラの文はしばしば競合する2つの指示を含み（push in while orbiting）、それらが衝突するとき、出力は半ば無作為に一方を選ぶ。

アングルのパターン

CAMERA: eye level, medium shot
CAMERA: low angle, close on hands
CAMERA: high angle, wide, subject small in frame
CAMERA: over-the-shoulder from behind the subject

アングルこそがフレーミングの意図そのものだ。「Close on hands」も「subject small in frame」も雰囲気ではなく、視聴者に何を見せるかの決定であり、cinematic よりもはるかに大きくショットを変える。

ペースのパターン

CAMERA: unhurried, deliberate movement
CAMERA: brisk, follows the action closely
CAMERA: settles and holds on the final beat

ペースは動作ブロックではなくカメラブロックに属する。カメラがどう振る舞うかを表すものであり、長回しのショットをふらつきではなく章立てのあるものに見せる最も明快な手段だ。

1回に1フレーズだけ差し替える

カメラの言い回しを読み解けるものにする方法：

1. ベースプロンプトを1つ書き、主体、動作、場景、尺を固定する。
2. CAMERA: static, locked off でそのベースプロンプトを実行する。
3. カメラの行だけを変える——1回の実行で1か所だけ差し替える。
4. 各実行のクリップを保存し、使ったカメラフレーズでタグ付けする。

4〜5回実行すれば、自分専用のフレーズ帳ができる：slow push in が自分の主体で、自分の場景で何をするかを知っている。これはどんな汎用リストよりも価値がある。プロジェクトごとに1度やれば、このフレーズ帳は以後のすべてのショットに持ち越せる。

2つの失敗パターン

• 指示の積み重ね。短いクリップで push in, then orbit, then pull out と書くのは、尺に収まらない3つのカメラ運動を要求することと同じだ。1ショットに与える運動は1つだけ。
• 形容詞での代替。雰囲気の言葉（dramatic、dynamic、epic）でカメラ運動を置き換えても、カメラを指定したことにはならない。カメラブロックにカメラがどこにあり何をしているかの記述がなければ、最も重要なスロットを空けたままだ。

実際の出力を埋め込んで比較する

レシピが役立つのは、バージョンBがバージョンAに勝るかどうかを判断できるときだけだ。それには試験装置——小さくて地味な定型手順——が必要で、出力を並べて比較が勘ではなく機械的に行えるようにする。

必要なのはツールではなく、規律と1つのフォルダだ。

試験装置、5つのステップ

1. テストしないものすべてを固定する。baseline.md を書き、この実験で変えない主体、動作、場景、尺のブロックを入れる。バッチ内の各実行はこれらのブロックを逐語的にコピーする。
2. 変数を指定する。1回の実行で変えるスロットは1つだけ。カメラの言い回しをテストしているなら、ファイル間で違うのはカメラの行だけだ。
3. バッチを生成する。すべてのバリアントを同じドラフトティア、同じ尺で実行し、比較が公平になるようにする。
4. 並べる。毎回同じ順序でクリップを連続再生するか、シンプルなグリッドで横に並べる。順序は重要だ——位置が視聴のたびに安定していると、目は比較しやすい。
5. 各バリアントの結論を記録する。バリアントごとに1文：何を変えたか、それが望んだ変更だったか、それを残すか。

比較時に見るべきもの

• ビートの完全さ——動作リストのすべてのビートが順番に現れたか？
• カメラの読み取りやすさ——説明を見ずに視聴者がカメラの動きを説明できるか？
• 主体の一貫性——実行間で、主体が同じ主体ブロックとして判別できるか？
• 意図しない変更——カメラのフレーズを差し替えたことで場景が静かに変わっていないか？これはブロック間の漏れの兆候だ。

最後のチェックこそが試験装置の本当の見返りだ。ブロックがきれいなら、1つのスロットを変えると1つのことだけが変わる。漏れているときには、1回の視聴では決して気づかないクロストークが生まれる——そしてクロストークこそがプロンプトの反復を運任せに感じさせる原因だ。

試験装置は小規模に保つ

判断を下すには4〜5のバリアントで十分だ。より大きなバッチは注意力を薄め、ざっと流し見するよう誘う。最初のバッチで結論が出ないなら、答えはたいてい選んだ変数が細かすぎたことであり、さらに20回走らせる必要があることではない。

最後に、結論をレシピファイルに書き戻すこと。勝ち残ったカメラフレーズはベースラインテンプレートに昇格させるべきで、そうすれば何度も再発見せずに済む。

再現可能なプロンプト反復ワークフロー

以下は、これまでのレシピを組み合わせた完全なループだ。意図的にまったく派手さはないが、プロンプトライブラリが着実に成長するか、徐々に漂流するかを決めるのはこれだ。

ステップ1——ブロックを起草する

テンプレートを1回埋める：主体、動作ビート、場景、カメラ、尺、解像度。磨かないこと。初版の存在意義は修正されることにある。

ステップ2——安く、短く走らせる

ドラフトティアで短い尺で生成する。手に入るのは構図、ビート数、カメラの読み取りやすさに関する情報——それだけだ。変動スロットの1つだけが異なる2〜3のバリアントを走らせる。

ステップ3——勝者を選び、ロックする

あるバリアントが望んだ効果を出したら、その正確なテキストを locked/ ファイルにコピーする。ロックとはそのファイルを以後編集しないということであり、以後の実験はそこから分岐し、その上で直接書き換えない。この小さな習慣が最もよくある退化——その場で微調整を続けて良いバージョンを失うこと——を防ぐ。

ステップ4——最終設定に引き上げる

尺と解像度だけを納品値に変えてレンダリングする。最終結果がドラフトと影響のある違いを見せたら、その違いを記録する——そのプロンプトが解像度や尺に敏感だということであり、次のプロジェクトの前にどのスロットが脆いかを知っておきたいからだ。

ステップ5——すべてを記録する

各実行に1件の記録。ログはこのワークフローに複利効果を生む産物だ。最低限のフィールドは次のとおり：

id: shot03_v2
template: studio-ceramics
variable_tested: camera
prompt: <full prompt text, verbatim>
duration: <value used>
resolution: <tier used>
verdict: <one sentence — what changed, keep or discard>
artifact: <clip path>

ログを信頼できるものにする3つのルール。逐語原文のプロンプトだけを記録する——言い換えでは再現できない。各記録には変数を1つだけ含める——そうでなければログは「なぜこれが効いたのか？」に答えられない。各記録にクリップパスを付ける——産物のない結論は単なる意見だ。

ステップ6——フレーズ帳に抽出する

数プロジェクトごとにログを読み返し、繰り返し勝ち残ったもの——カメラフレーズ、ビートリストの形、場景ブロック——を共有のフレーズ帳ファイルに抽出する。フレーズ帳は再利用可能な知識であり、ログはその背後にある証拠だ。

なぜ順序が重要なのか

まず安く反復し、次にロックし、次に引き上げ、次に記録する：各ステップは前のステップの規律に依存している。ロックがなければ、引き上げテストは動く標的を狙うことになる。記録がなければ、ロックには根拠がない。安いドラフトがなければ、ロックする価値のある何かを生み出すのに十分な回数を走らせる余裕がない。

HiAPI.ai の統合 API で MiniMax H3 Max テキスト動画にこのループを回し、プロンプトテキストとパラメータ値を自分のリポジトリに保存して、すべての成功を再現可能に保とう。