画像生成で使っていた
extra fingers, blurry, text を、動画APIにもそのまま渡す。これは手軽ですが、設計としてはかなり危ういやり方です。画像のネガティブプロンプトが主に「1枚の中へ何を出さないか」を扱うのに対し、動画では「途中で何に変わらないか」「フレーム間で何を保つか」まで考える必要があります。しかも、専用フィールドを持つAPIもあれば、否定表現そのものを避けるよう案内しているモデルもあります。
先に結論を書くと、除外語の文字列を使い回すのではなく、除外したい意図を共通化し、モデルごとに変換するのが安全です。本稿では、その理由をAPI、従量課金、レート制限、データ保持、制作ワークフローの順に整理します。
※仕様と料金は2026年8月17日に公式情報で確認しました。以下は公開仕様をもとにした設計例であり、特定モデルの生成品質を実測比較した記事ではありません。
ネガティブプロンプトを「禁止語リスト」と考えると崩れる
画像生成では、ネガティブプロンプトを禁止語の一覧として扱っても、それなりに運用できます。たとえば人物画像なら、余分な指、文字、透かし、強いぼけなど、1枚の中で見つけやすい欠陥を列挙できます。
動画で同じ発想を続けると、見落とすものがあります。最初のフレームでは正常だった指が途中で増える、服の色が少しずつ変わる、固定したはずの背景が呼吸するように揺れる。問題は「あるか、ないか」ではなく、時間の途中で状態が変わることです。
ここで分けたいのは、次の2種類です。
-
空間的な欠陥：余分な物体、文字、ロゴ、形の破綻、ぼけ
-
時間的な欠陥：ちらつき、人物同一性の変化、形状の変形、露出の揺れ、動きの飛び
後者は、単に
flicker や identity drift をネガティブ側へ足せば終わるとは限りません。モデルが否定指定を受け取れるか、時間方向の条件をどこまで解釈するか、参照画像や先頭・末尾フレームを使えるかによって、取るべき手段が変わります。画像用と動画用の除外指定は、同じ欄に入れない
画像と動画の違いを、運用上の観点で並べるとこうなります。
|
比較軸
|
画像生成
|
動画生成
|
|
評価単位
|
1枚の画面
|
複数フレームと時間変化
|
|
主な除外対象
|
余分な物体、文字、透かし、解剖学的破綻
|
ちらつき、同一性の変化、形状変化、急なカメラ移動
|
|
一貫性
|
画面内の整合性
|
フレーム間一貫性と動作の連続性
|
|
修正方法
|
ネガティブ指定、マスク、インペイント
|
ネガティブ指定、肯定的な保持条件、参照フレーム、ショット分割
|
|
seedの使い方
|
同条件で構図差を見やすい
|
同条件で文言差を追えるが、時間方向の完全一致を保証するものではない
|
|
API対応
|
専用フィールドが比較的見つけやすい
|
モデル単位で対応が違い、同じサービス内でも統一されていない
|
たとえばStability AIの画像APIには、出したくない内容を渡す
negative_prompt があります。一方で、同社の Stable Video Diffusion APIはすでに提供終了 となっており、画像側のパラメーターを動画側にも当然使えるとは言えません。つまり、「画像生成サービスがネガティブプロンプトに対応している」と「その会社の動画モデルも同じ方法で対応する」は別の話です。実装前に確認すべき単位は、サービス名ではなくエンドポイントとモデルIDです。
時間軸での崩れは、除外指定だけでは止めにくい
動画の失敗を考えるときは、1枚ずつの欠陥ではなく「何が、いつ変わったか」を見ます。次の表は実測結果ではなく、レビュー項目を決めるための概念例です。
|
シーン
|
画像用の除外語だけを流用
|
動画で残りやすい問題
|
追加したい条件
|
|
人物が歩く
|
extra limbs, deformed hands |
途中で腕の長さや服の色が変わる
|
same person, consistent clothing, continuous walking motion |
|
卓上の商品を撮る
|
text, logo, blur |
背景や反射がフレームごとに揺れる
|
locked-off camera, fixed lighting, stable reflections |
|
車が旋回する
|
extra wheels, distorted body |
見えない側から車体形状が変わる
|
参照画像、短いショット、角度ごとの分割
|
|
顔のクローズアップ
|
asymmetrical face, artifacts |
まばたきの前後で顔つきが変わる
|
同一人物の保持条件、動作を1つに絞る
|
重要なのは、除外と保持を分けることです。
no flicker は除外ですが、stable exposure throughout the shot は保持条件です。no identity drift に対して、the same person with consistent facial features and clothing は、モデルに残してほしい状態を説明しています。動画では後者のほうが効く場面があります。少なくとも、否定語を理解しないモデルへ
no を増やすより筋が通っています。さらに、長い1本を無理に生成するより、動作を1つに限定した短いショットへ分けたほうが、どこで崩れたかも追いやすくなります。APIではモデルごとに別物として扱う
2026年8月17日時点で、代表的な実装差は次の通りです。
|
API／モデル
|
専用の除外指定
|
実装時の注意
|
|
Google Veo 3.1
|
negativePrompt |
長時間処理として呼び出す。モデルID、秒数、解像度、出力本数も一緒に検証する
|
|
Runway APIのVeo系
|
negativePrompt |
2026年7月にVeo 3／3.1／3.1 Fastへ追加。最大1,000文字。省略時はRunway既定値
|
|
Amazon Nova Reel
|
否定語の使用を避ける
|
no、not、without が意図と逆の結果を招く可能性があるため、肯定的な映像要約へ変換する |
|
Stability AIの画像API
|
negative_prompt |
画像側の対応例。Stable Video Diffusion APIは提供終了しており、動画へ同じ設計を流用できない
|
GoogleのVeo APIは、生成したくない内容を
negativePrompt として別フィールドで渡せます。RunwayもVeo系については、2026年7月10日の更新で 最大1,000文字の negativePrompt を追加しました。しかしRunwayの対応は「Runway APIにある全動画モデル」ではなく、更新履歴に明記されたVeo系が対象です。同じAPIの中でも、Gen-4.5など別モデルへ同じフィールドを無条件に送る設計は避けるべきです。
対照的なのがAmazon Nova Reelです。プロンプトは命令文ではなく映像の要約として書き、
no、not、without を使わないよう、動画生成プロンプトの注意点 に明記されています。「バナナのない果物かご」と書いた結果、バナナが出る可能性がある、という分かりやすい例も示されています。ただし、Nova Reel 1.0は一部リージョンでLegacy扱いとなっており、EOLは2026年9月30日の予定 です。ここでは否定表現を肯定条件へ変換する実装例として扱っています。新規採用時は、利用するリージョンと後継モデルの仕様を改めて確認してください。
ここまで差があると、共通フィールドをそのまま各社へ転送する方式は成立しません。
共通化するなら、文字列ではなく意図を保存する
除外指定を複数モデルで使い回したいなら、データの持ち方を変えます。保存するのは完成した英文ではなく、「何を避けたいか」「何を保ちたいか」という構造です。
TypeScript
type NegativeSpec = {
spatial: string; // extra limbs, text, watermark など
temporal: string; // flicker, identity drift, exposure shift など
preserve: string; // same subject, fixed lighting, locked camera など
};type TargetModel =
| "vertex:veo-3.1"
| "runway:veo3.1"
| "aws:nova-reel";function compilePrompt(
model: TargetModel,
positivePrompt: string,
spec: NegativeSpec
) {
if (model === "vertex:veo-3.1" || model === "runway:veo3.1") {
return {
prompt: [positivePrompt, ...spec.preserve].join(", "),
negativePrompt: [...spec.spatial, ...spec.temporal].join(", "),
};
}
これは最小例です。本番では、モデルごとの最大文字数、対応言語、許可するアスペクト比、秒数、音声の有無も同じ能力表へ持たせます。APIの更新でフィールドが増減したとき、アプリ全体ではなくアダプターだけを直せる形が理想です。
もう一つ大事なのは、プロンプトの版を残すことです。少なくとも次をジョブIDへひも付けます。
-
共通仕様のバージョン
-
変換後のpositive promptとnegative prompt
-
provider、model ID、seed、秒数、解像度
-
生成日時と料金計算用の単価スナップショット
-
レビュー結果と失敗分類
「同じプロンプトなのに結果が違う」と見えたとき、実際にはモデルIDや既定のネガティブ指定が変わっているかもしれません。変換後の文字列まで保存しないと、原因を追えなくなります。
従量課金は「秒数×本数×再試行」で考える
動画APIの費用は、入力プロンプトの長さよりも出力秒数と本数の影響が大きいサービスが目立ちます。基本式は次の形です。
生成費用 = 1秒あたりの単価 × 出力秒数 × 出力本数 × 実行回数
たとえばRunway APIでは、1 creditが\$0.01です。2026年8月17日時点の `gen4.5` は12 credits/秒なので、8秒を2本生成すると次の計算になります。
12 credits × 8秒 × 2本 = 192 credits = $1.92
veo3.1_fast は音声なし10 credits/秒、音声あり15 credits/秒です。同じ8秒を2本なら、音声なしは$1.60、音声ありは$2.40になります。単価は Runway APIのモデル別料金 で更新されるため、コードへ直接埋め込まず、設定値として管理したほうが安全です。Google Cloudでは、Veo 3.1 Fastの動画のみ・720pが$0.08/秒、1080pが$0.10/秒です。8秒を2本なら、720pで$1.28、1080pで$1.60です。音声、4K、通常版では単価が変わるため、解像度と音声の有無を含むVeo料金表 から該当行を選びます。
Amazon Nova Reelは、AWSが公開している サーバーレス構成の試算例で生成動画1秒あたり$0.08 とされています。6秒を10本なら$4.80です。ただし実運用では、生成結果を置くS3、状態管理、転送、長期保管も別の費用になります。
ネガティブ指定との関係で見落としやすいのは再試行です。除外語を1個ずつ足して毎回生成すれば、品質は追いやすい一方、実行回数は増えます。そこで試作段階では、低い解像度や高速モデルでプロンプトの方向を決め、採用候補だけを本番条件で生成する二段階に分けます。
なお、失敗・キャンセル・モデレーション時の課金条件はサービスごとに違います。成功レスポンスだけ課金されると決めつけず、エラー種別と請求結果をジョブ台帳で突き合わせる必要があります。
レート制限はRPMだけ見ても足りない
動画生成は非同期処理が基本です。APIへリクエストを送った直後にMP4が返るのではなく、ジョブIDを受け取り、完了まで状態を確認します。そのため制限も、単純な「1分に何回呼べるか」だけではありません。
Runway APIは、最大RPMを置かず、同時実行数・24時間の生成数・30日間の支出上限で管理しています。同時実行枠を超えたタスクは
THROTTLED となり、サーバー側のキューへ入ります。日次上限を超えると429です。つまりクライアント側で無理に一定間隔へ丸めるより、同時実行枠とキューの状態 を監視するほうが実態に合います。Veo 3.1の現行モデル情報では、リージョン、プロジェクト、ベースモデル単位で1分あたり50リクエスト、1リクエストにつき最大4本です。4本をまとめて依頼するとリクエスト数は減りますが、費用とレビュー待ちの本数は増えます。Veo 3.1の秒数・本数・クォータ を一緒に見ないと、キュー設計を誤ります。
Amazon Bedrockはモデルとリージョンごとのクォータです。初期値はリージョンやアカウント条件で変わる可能性 も案内されているため、本番前にService Quotasで対象アカウントを確認します。資料に書かれた数字を固定値として実装するのではなく、429、スロットル、タイムアウトを通常の状態遷移として扱うほうがよいでしょう。
ワーカー側は、少なくとも次の状態を分けます。
queued → submitted → running → succeeded
↘ throttled → running
↘ failed / moderated / expired
リトライは指数バックオフだけでなく、同じジョブを二重作成しない仕組みも必要です。動画は1回の再送でも費用が大きいため、クライアント側のタイムアウトを「生成失敗」と誤認して新しいジョブを作る事故は避けたいところです。
データ保持は「URLの寿命」と「学習利用」を分ける
動画ワークフローでは、データ保持という言葉が複数の意味で使われます。
-
入力画像やプロンプトをサービスが何日保持するか
-
出力動画のダウンロードURLがいつ失効するか
-
自社のS3やCloud Storageへ何日残すか
-
入出力がモデル学習に使われるか
-
障害調査や不正利用監視のログが残るか
これらは別の設定です。
Amazon Bedrock上のNova Reelは、プロンプトと動画出力を保存・レビューせず、学習にも使わない と説明しています。出力は利用者側のS3へ書き込まれるため、実際の保存期間はS3のライフサイクル設定で決まります。この構成では、サービス側の非保持だけ確認しても不十分で、自分のバケットに削除ルールがなければ動画は残り続けます。
Google Cloudは、許可なく顧客データを学習へ使わない一方、契約や利用機能によって不正利用監視、Grounding、24時間のメモリキャッシュなどに限定的な保持条件があります。Vertex AIでゼロデータ保持を実現する条件 を読み、対象機能を使っているかまで確認する必要があります。
Runway APIの出力URLは、APIへアクセスしてから24〜48時間で失効します。これは便利な一時配布URLですが、期限内に自前ストレージへ保存する前提 です。また、アップロード用の
runway:// URIは24時間で失効します。URLが消えることと、契約上のデータ保持や学習利用の条件は同じ意味ではありません。制作システムでは、入力、出力、プロンプト、ジョブログの4種類に別々の保持期間を決めると整理しやすくなります。案件素材を扱うなら、生成サービスの規約だけでなく、自社ストレージ、バックアップ、レビュー用CDNまで削除対象に含めます。
制作ワークフローへ入れるなら、品質判定を先に決める
ネガティブプロンプトの改善を始める前に、「何を失敗とするか」を固定します。ここが曖昧だと、生成するたびに違う点を見てしまい、除外語だけが増えます。
実装は次の5段階に分けると扱いやすくなります。
-
共通仕様を作る
-
空間的な除外、時間的な除外、保持条件を別々に保存します。
-
モデル能力で変換する
-
専用フィールドがあれば除外側へ渡し、否定表現を避けるモデルでは肯定的な保持条件へ書き換えます。
-
短い候補を生成する
-
長尺を一度に作らず、1ショット1動作でプロンプト差を確認します。
-
時間軸でレビューする
-
先頭、中間、末尾だけでなく、形が変わる瞬間やカメラ移動の境目を見ます。指、顔、商品形状、背景、露出、速度を別項目にします。
-
採用条件だけ本番化する
-
プロンプト、モデルID、seed、秒数、単価、結果を記録し、同じ条件で再生成できる状態にします。
共通仕様のたたき台は、次のように分けられます。
negative_spec:
spatial:
- extra limbs
- unwanted text
- watermark
temporal:
- flicker
- identity drift
- geometry morphing
- abrupt exposure changes
preserve:
- same subject throughout the shot
- consistent clothing and colors
- continuous natural motion
- stable lighting
- locked camera
このYAMLをそのまま全モデルへ送るのではありません。Veo系なら
spatial と temporal を negativePrompt へ、preserve を通常プロンプトへ展開します。Nova Reelなら否定欄を作らず、必要な preserve だけを映像の説明へ自然に織り込みます。除外語を共通化する目的は、同じ文字列を送ることではなく、同じ品質基準を別のモデルでも再現できるようにすることです。
ネガティブ指定より先に、モデルの入口を確認する
動画生成のネガティブプロンプトは、画像用リストへ
flicker を足したものではありません。1枚の中の欠陥と、時間の途中で起きる変化を分け、さらにAPIが否定指定をどう受け取るかまで確認して初めて、運用できる形になります。新しいモデルを追加するときは、まず次の3点だけ確認するとよいでしょう。
-
専用のnegative promptフィールドがあるか
-
否定語ではなく肯定的な保持条件へ変換すべきか
-
秒課金、同時実行数、出力の保存先をどう記録するか
この3点が能力表に入っていれば、プロンプト集が古くなっても、ワークフロー全体を作り直さずに済みます。動画で使い回すべきものは除外語そのものではなく、崩れを見つけるための基準です。
