このガイドの前提

短い動画のアイデアを一文の指示に急いでしまうと、残したい要素と変えてよい要素が同じ場所に混ざります。あとから文面を読み返しても、人物を保つのか、画角を変えるのか、場面を進めるのかを分けて確認できません。本稿では、動画のアイデアを実行結果の期待ではなく、レビュー可能な設計メモへ変換します。

ここで扱う MiniMax H3 動画プロンプトは、特定の結果を約束する完成文ではありません。主題、動き、場所、光、カメラ、時間の順序、制約を分けて記録し、生成前に矛盾を見つけるための入力仕様です。

項目の拾い方の参照として、Flaqの無料MiniMax H3ページには subject、action、setting、lighting、camera movement といった入力項目が表示されています。同ページの Free と No Signup Required という表記は、そのページ上の現在の表示であり、利用可否や条件を保証するものとしては扱いません。

開示: このFLAQガイドには、FLAQの公開プロンプト集へのリンクが含まれます。これはMiniMax H3の実機テストではなく、編集ガイドです。

図1：アイデアを項目カードと場面列に分ける編集用イラスト。

この図は設計の説明用に作成した編集イラストであり、生成結果や実機テストの記録ではありません。

MiniMax H3 動画プロンプトを設計仕様として扱う

設計メモの役割は、映像の雰囲気を増やすことではなく、判断の置き場所を固定することです。一つの場面を、次の項目を持つ小さなレコードとして書きます。

目的：その場面で読者や視聴者に何を伝えたいか
主体：誰または何を中心に扱うか
動き：一場面で起こす主な変化を一つに絞る
場所と光：背景、時間帯、光の向きなどの前提
カメラ：画角、視線の方向、移動の有無
開始状態と終了状態：場面の前後で何が変わるか
固定項と可変項：変えてはいけないものと、演出として動かすもの
確認条件：文面だけで検査できる矛盾や不足

この分解をすると、「映像を印象的にする」といった曖昧な要望を、そのまま指示に混ぜずに済みます。まず設計メモで意味を確定し、あとで必要な表現に組み直す順番です。

動画プロンプトの書き方：一文の企画をシーン単位に分解する

たとえば「雨上がりの駅前を歩く人物を短い映像にしたい」という企画があるとします。ここで必要なのは、情報を増やした長文ではなく、場面ごとの状態遷移です。各シーンには主な動きを一つだけ置き、開始と終了を比べられる形にします。

scene_id: S01
目的: 到着前の静かな状況を置く
主体: 赤い傘を持つ人物
動き: 傘を閉じる
場所と光: 雨上がりの駅前、路面に反射するやわらかな光
カメラ: 横からの中距離、右向きの画面方向
開始状態: 傘が開いている
終了状態: 傘が閉じている
固定項: 人物、赤い傘、駅前、画面方向
可変項: 動きの進行、カメラとの距離
確認条件: 一場面に二つ以上の主要動作を書かない

次のシーンでは、前の終了状態を次の開始状態として引き継ぎます。これにより、各場面は独立した説明でありながら、場面列として接続できます。書き出す段階で未決定の項目は、空欄を埋めたふりをせず「未決定」として残すほうが、レビュー時の見落としを減らせます。

シーン設計では固定項と可変項を別々に管理する

シーン設計で混乱しやすいのは、保持したい情報と演出上動かしたい情報を同じ文で扱うことです。固定項は、人物の識別手掛かり、衣服や小道具、場所、画面方向、場面の前提です。可変項は、場面ごとの動き、カメラとの距離、光の変化、切り替えるタイミングなどです。

各項目に fixed、variable、undecided のいずれかを付けると、修正の影響範囲が読み取れます。たとえばカメラを引くことは可変項の変更として扱い、人物や傘の説明まで書き換えない、という境界を残せます。これは出力の性質を断言するためではなく、文面の変更管理をしやすくするための区分です。

図2：同じ要素を保ち、指定した変化だけを別にする編集用イラスト。

この図は設計の説明用に作成した編集イラストであり、生成結果や実機テストの記録ではありません。

プロンプトテンプレートをレビュー可能な入力形式にする

プロンプトテンプレートは、完成文のひな形ではなく、確認漏れを防ぐ入力欄として使えます。次のように、物語の説明と制約を別の欄に置くと、どこを直すべきかが追いやすくなります。

[目的]
[シーンID]
[主体]
[主要動作]
[場所と時間]
[光と色]
[カメラと画面方向]
[開始状態 → 終了状態]
[固定項]
[可変項]
[変更してよい範囲]
[避ける矛盾]
[文面レビューの確認条件]

このプロンプトのテンプレートでは、空欄も情報です。たとえばカメラを決めていないなら、曖昧な形容詞で埋めるのではなく未決定として残します。レビュー担当者は、未決定の欄を質問に変えられますし、固定項と可変項が同じ欄に混ざっていないかも確認できます。

確認項目を「書けたか」ではなく「矛盾がないか」で見る

設計メモは、情報量よりも検査可能性で評価します。生成前に次の確認項目を上から順に見ます。

各シーンに主要動作が一つだけあり、開始状態と終了状態が書かれているか。
同じ主体を指す説明が、別の名前や属性と衝突していないか。
固定項に置いた要素を、可変項の説明で不用意に変更していないか。
画面方向、カメラ、移動の説明が互いに矛盾していないか。
場面の接続で、前の終了状態を次の開始状態として読めるか。
未決定の欄と、今回変更してよい範囲が明示されているか。

このチェックは、文章の表現力を採点するものではありません。企画、制約、時間順序を別々に読めるかを確かめる、短い仕様レビューです。問題を見つけたときも、場面全体を作り直す前に、どの分類に属する問題かを決めます。

修正は一度に一つの失敗分類だけにする

修正の単位を小さくすると、設計メモのどこが変わったかを追えます。たとえば「開始状態と終了状態がつながらない」と判断した場合は、状態遷移だけを直し、同時にカメラ、光、主体まで変えません。

変更ごとに、対象の欄、変更理由、維持する固定項を短く記録します。次のレビューでは、前回の判断を残したまま、今回の変更が別の矛盾を生んでいないかを見られます。この反復は、結果を約束する手順ではなく、文面を制御可能に保つための作業です。

図3：一度にひとつの分類だけを直して、他の決定を保つ編集用イラスト。

この図は設計の説明用に作成した編集イラストであり、生成結果や実機テストの記録ではありません。

結論：MiniMax H3 動画プロンプトは、まず設計メモにする

MiniMax H3 動画プロンプトを扱う前に、アイデアをシーンの状態遷移、固定項、可変項、確認条件へ分けると、曖昧さをレビュー対象にできます。短いテンプレートでも、何を保ち、何を変え、何を未決定のままにするかが読めれば、次の修正は意図的に行えます。

構造の比較対象が必要なときだけ、最後に FLAQのMiniMax H3プロンプト集を参照し、そこで見た表現も同じ入力項目へ分解して検討してください。