Wan 3.0 縦型ショートドラマ向けカメラワークプロンプト完全ガイド：映画級の構図制御と安定性

Wan 2.1の話題から商用実装へ：縦型ショートドラマ制作におけるWan 3.0モデル活用術

本ガイドはSay Action制作チームが執筆し、縦型ショートドラマの制作現場に向けた監督目線のカメラワークプロンプト設計手法を体系化しています。2026年中期以降、オープンソースのWan 2.1モデル（14Bおよび1.3Bアーキテクチャ）は、物理挙動の自然さと滑らかな動きの生成力によって、CivitaiやHuggingFace、Redditなどのコミュニティで大きな反響を呼びました。しかし、ローカル環境での実験的なスクリプトから商業ベースの連続ドラマ制作へと移行するには、安定した制作インフラが不可欠です。オープンソース界隈ではWan 2.1の話題が中心ですが、Say Actionでは検証済みのWan 3.0テキスト・トゥ・ビデオおよびビデオノード（wan3.0-*）を本番環境に実装しており、自前で複数台のGPUサーバーを維持することなく高精細な縦型ショットを直接生成できます。

1話60〜90秒の縦型ショートドラマにおいて、映像の説得力は物理的な整合性に強く依存します。急な振り返り時の衣服の揺れ、視線移動に伴う陰影の変化、カメラが徐々に被写体に寄る際の空間の奥行き感など、従来の拡散モデルでは2次元的な歪みとして破綻しがちだった要素が、Wan 3.0の時空間（Spatio-Temporal）ビデオ構造によって、3次元空間の真の運動軌道として処理されます。体系的なディレクター構文で指示を与えることで、Wan 3.0は縦型構図特有のカメラパスでも高い機械的安定性を発揮し、ドラマの緊迫した対話や決定的な表情のクローズアップを破綻なく描き出します。

実務における重要なポイントは、単一のモデルにすべてのカットを無理に任せないことです。Say Actionの無限キャンバス上では、Wan 3.0は絵コンテ表と連動した独立したビデオ生成ノードとして機能します。繊細な対話クローズアップはMiniMax Hailuo、激しいアクションはKling v3 Turbo、キーフレーム間の遷移はSeedance 2.5、そして空間的な状況提示や安定したカメラワークはWan 3.0へと、ショットごとに最適なモデルを割り当てることが可能です。カット単位で独立してパラメータを調整できるため、1カットの修正のためにシーン全体を再生成するようなリスクを大幅に低減できます。

Wan 3.0のための6層ディレクター構文：決定論的なプロンプト設計

Wan 3.0の動画生成でカメラ制御が失敗する最大の原因は、小説のような情緒的プロンプトをそのまま入力してしまうことです。「哀愁を帯びたカメラが薄暗い室内をゆっくりと彷徨い、窓の外を見つめる若きCEOの孤独を捉える」といった文学的表現は、拡散モデルのクロスアテンション層に曖昧な形容詞を過剰に供給します。AIは抽象的な感情を3次元の物理速度ベクトルに変換できないため、カメラが静止したまま表情だけが引きつったり、照明が不自然に点滅したりします。Wan 3.0を意図通りに動かすには、撮影監督（DP）がショットリストを記述するように、機材の挙動、空間軸、被写体の動作を幾何学的に定義しなければなりません。

再現性の高いカメラワークを得るために、私たちは以下の6層ディレクター構文を採用しています：[カメラ機材・運動ベクトル] + [被写体サイズ・アングル] + [主たる物理動作] + [空間環境] + [照明・雰囲気] + [レンズ・スタイル制約]。構文上の最も重要なルールは、各レイヤーをコンマ（,）ではなくピリオド（.）で明確に区切ることです。Wan 3.0のトークン処理において、ピリオドは意味の独立境界として機能し、被写体の装飾語がカメラの運動指示に干渉するのを防ぎます。プロンプト全体の長さは英語で60〜100語を目安にします。30語未満ではモデルの勝手な補完が発生しやすく、120語を超えると重要指示へのアテンションが希釈されます。

下表は、Wan 3.0を用いた縦型ショートドラマ向けに実証された6つの基本カメラワークモジュールです。各モジュールには英語構文テンプレート、幾何学的な演出意図、および絵コンテ作成時の注意点を記載しています。これらの定型句を用いることで、仮想カメラが空間座標に強固に固定され、生成前の意図しない画面ブレを抑えることができます。

構文テンプレートはSay Actionキャンバス内のWan 3.0ビデオ生成仕様に基づきます。生成結果には拡散モデル特有の揺らぎがあるため、最終編集前に人間による確認が必要です。

9:16縦型構図：運動ベクトルと外見描写の分離ルール

従来の16:9横型映画と比較して、9:16のスマートフォン画面では構図の幾何学が根本的に異なります。縦型では左右の横幅が狭く制限される一方、上下の空間とZ軸の奥行きが重要な演出要素となります。初心者が陥りやすいミスは、動画生成プロンプトの中に髪型、スーツの生地、カフスボタン、瞳の色といった人物の外見描写を大量に書き込んでしまうことです。Wan 3.0の生成処理において、静的な外見トークンと動的なカメラワーク指示が混在すると、モデルは毎フレームごとに顔の造形を再計算しようとし、結果として顔の変形や衣装のチラつきが生じます。

プロの制作現場における鉄則は「動と静の分離」です。キャラクターの視覚的アイデンティティはリファレンス画像や独立した設定ノードで確定させ、動画プロンプトのトークンは物理的な動作とカメラワークに集中させます。Say ActionキャンバスでWan 3.0ノードを設定する際は、キャラクターが「何を着ているか」ではなく「何をしているか」「カメラがどう動くか」だけを記述します。例えば「濃紺のスーツを着た美青年が鋭い眼光で振り返る」ではなく、「Subject turns abruptly toward camera, sharp eye contact, controlled torso rotation, locked 9:16 vertical framing」と記述することで、動力学計算に最大の計算リソースを集中させます。

また、縦型のカメラワークはスマートフォンのUIセーフゾーンを厳格に考慮しなければなりません。TikTokやショートドラマアプリなどの縦型プラットフォームでは、画面の上下がUIや操作要素で覆われやすいため、役者の顔や主要なアクションを画面中央の安全領域内に収める必要があります。Wan 3.0でカメラの上下移動や寄り引きを設計する際は、役者の視線や決定的な小道具が中央のセーフゾーン内に留まるように制御することが重要です。カメラを大きくティルトアップさせて人物の顔が画面端に寄りすぎてしまうと、実機での再生時にUIと重なり使用不能になります。

撮影監督の術語 vs 画質ワード：レンズを本当に動かす指示とは

AI動画生成において広く見られる誤解の一つが、「映画的最高傑作、8K超高画質、フォトリアル、神光」といった装飾的な単語を並べることで品質が上がるという思い込みです。Wan 3.0のような最新の時空間モデルにおいて、こうした抽象的な形容詞はカメラ制御において全く役に立ちません。それどころか、貴重なプロンプトの文脈長を消費し、肝心なカメラ指示の重みを希釈させてしまいます。生成モデルはすでに十分な高画質表現を獲得しており、演出者が指示すべきは曖昧な美辞麗句ではなく、明確な幾何学的動作です。

仮想カメラを意図通りに制御するには、本物の撮影現場の専門用語を用います。等価焦点距離（自然な遠近感の50mm normal lens、背景をボケさせて感情を凝縮する85mm telephoto、空間の広がりと緊張感を出す28mm wide lens）を指定します。さらに支持機材（台車レールdolly track、油圧雲台fluid-head tripod、3軸ジンバルgimbal、クレーンcrane）や運動速度（微速前進slow steady creep、素早い切り替えbrisk decisive whip）を定義します。Wan 3.0に「Camera: locked-off tripod, 85mm portrait lens, shallow depth of field, steady eye-level angle」と指示することで、物理法則に即した極めて安定した映像が得られます。

Say Actionキャンバスで複数カットの対話シーン（切り返し・肩越し構図）を組み立てる際、こうした体系的構文が威力を発揮します。カット1では50mmで話者にゆっくり寄るドリーイン、カット2では聞き手の背中越しに固定三脚でリアクションを記録、カット3では85mmで握りしめた拳のクローズアップを配置します。絵コンテ表の行ごとに個別のWan 3.0ノードが対応しているため、監督はカットごとのテンポとリズムをより安定して統制でき、ブラックボックス的な一括生成に頼るリスクを抑えることができます。

生成破綻のトラブルシューティングと計算コスト・クレジット管理

構文を忠実に守っていても、生成AIモデルの性質上、特定の状況で画面の崩れが発生することがあります。最も頻度の高い不具合は手足の溶解や体型の変形です。これはほぼ例外なく、1カットの中に欲張って多すぎる動作を詰め込みすぎたことが原因です。例えば4秒のカットの中で「椅子に座っていた人物が立ち上がり、窓辺まで歩いてタバコを取り出す」といった一連の流れを一度に生成させようとすると、限られたフレーム内でモデルの骨格推論が破綻します。解決策はシンプルで、絵コンテ表で2つのカットに分割することです。カットAで立ち上がる動きを捉え、カットBで窓辺を歩く姿を捉えます。

画面の高周波な揺れや背景の小刻みなブレもよくある問題です。これは「猛烈な暴風雨と飛び交う紙吹雪」といった激しい環境描写と「静かな前進」というカメラ指示が衝突した際に発生します。モデルが天候の乱れをカメラの振動と混同してしまうのです。カメラを安定させるには、プロンプトの末尾にCamera: steady linear dolly on heavy track, zero hand tremor, locked horizon lineと防振条件を追加します。意図的にドキュメンタリー的な手持ち感を出す場合も、曖昧なshakeではなくsubtle organic handheld drift, professional operator movement, steady horizonと記述します。

短劇の継続的な商業生産には、計算資源の厳格な予算管理が欠かせません。Say Actionキャンバス上での台本執筆、絵コンテ表の分割、秒数調整、プロンプトの推敲作業はすべて完全無料です。クレジットは実際に動画ノードを実行する際、選択した解像度と秒数に応じて事前見積もりの上で消費されます。利用できるモデル、解像度、生成前のクレジット見積もりは制作画面で確認できます。最終的な消費クレジットは送信前に表示されます。 モデル提供元が生成の失敗を明確に確認した場合、仮確保されたクレジットを返還します。通信が途切れるなど結果や料金が確認できない場合は、二重精算を避けるため確認待ちになります。 信頼できる提供元だけに接続し、本番環境ではHTTPSを使用してください。リクエストはログイン認証されたバックエンドを経由し、必要なプロンプト、参考素材、認証情報が送信に使われます。APIキー、パスワード、秘密情報を含むヘッダーを公開キャンバスやスクリーンショット、サポートへの申請に載せないでください。 キャンバス上でリズムと構図を十分に練ってから動画生成を行うことで、無駄な再生成コストを最小限に抑えることができます。

自分のAPIと外部のAPI中継サービスを接続する

モデルの接続設定でBase URLとAPIキーを入力し、提供元のドキュメントに従ってAPIの方式、モデルID、必要なヘッダーを設定します。生成前に、使いたい画像・動画の生成方式に対応しているか確認してください。パス、解像度、開始・終了フレームの指定方法は接続先によって異なります。未対応サービスの接続リクエストは、対応を保証するものではありません。

BYOKではAPIの接続先、モデルのキー、カスタムヘッダーを設定できます。OneAPIやNewAPIなどを使う場合は、実際のAPIに合うOpenAI・Gemini・Claudeの方式を選び、モデルIDと画像・動画APIの対応状況を確認してください。すべての中継サービスや独自仕様に自動対応するわけではありません。BYOKでのモデル利用にはプラットフォームの上乗せ料金や生成クレジットの消費はありませんが、ワークスペースとモデル提供元の利用料金は別途かかります。

信頼できる提供元だけに接続し、本番環境ではHTTPSを使用してください。リクエストはログイン認証されたバックエンドを経由し、必要なプロンプト、参考素材、認証情報が送信に使われます。APIキー、パスワード、秘密情報を含むヘッダーを公開キャンバスやスクリーンショット、サポートへの申請に載せないでください。